NUM-6977
Events may appear “stuck” in a channel with named subscribers,
especially if filters are being used.
If a named priority object is used (or an IS serial trigger),
and filters are used to select events from a channel, then
events may remain on this channel, even after they’ve been
received by a consumer. The Enterprise Manager’s snoop
utility could be used to confirm this activity.
This issue is now resolved. The UM server will now properly
remove events from a channel (in all cases).
The fixed issue is maybe related to the one we’re talking about in this thread but it’s not the same IMO. The issue of this thread is that the message is not delivered at all. The fixed issue is that the channel is not cleared. But the message does get delivered.
pub.trigger:resumeRetrieval does not work as assumed. Only pub/sub concurrent trigger are affected.
In IS Admin UI Messaging - webMethods Trigger Management - set Retrieval State for a concurrent trigger to “Suspended”
In IS Admin UI Messaging - webMethods Trigger Management - set Retrieval State for a concurrent trigger to “Active”
OR run pub.trigger:suspendRetrieval with pub/sub concurrent trigger name as input.
publish some according documents - your clients will not acknowledge. Your published message still pending.
Doesn’t matter if you change Processing State at same time or not.
A critical Support Request is running. Jonathan Heywood is informed.
Workaround:
Reload package - helps without missing data - even if you have only one IS node. If you are running a cluster, other “heathy” nodes will process your data. This workaround requires manually changes. Time-critical processing of messages still be unpossible!
Our Version:
Product webMethods Integration Server
Version 9.12.0.0
Updates IS_9.12_Core_Fix4
IS_9.12_SPM_Fix1
TNS_9.12_Fix3
Build Number 91
The workaround we follow in here is refreshing the trigger through designer instaed of reloading the package as it happens to subscribe docs again multiple times which tends to redundant delivery.
What do you mean with “refreshing the trigger through designer”? Do you mean disable and enable? If so, it is circuitous for us, because we have 4 productive nodes. On each we have to lock and unlock triggers.
But you are right, it can happen. If a trigger delivers the message to a handling service and is not able to set the acknowledge state on UM anymore.
Yes, I meant disable and enable from designer as refresh, however the same activity from IS console has no effect.
And I dont think you need to touch all four nodes, any one node should fix it temporarily.
To test this, check the connection tab(If its working properly) of your channel, where the connection established from one IP. Once you refresh the trigger in one node, the connection page is upadted with that refreshed node IP and it subscribes fine but for sure the issue will hit again.
SAG Support can’t reproduce this issue. Can anyone try this:
Please inbound Package: “DEV_lowag” on your IS-testsystem and synchronize your document types to universal messaging.
Please check for attendance of webMethods-Triggers:
dev_lowag.triggers:repoDocTrigger and
dev_lowag.triggers:repoDocTriggerSerial on your IS Interface. Check if both
triggers are enabled for the features: “Document Retrieval” and “Document
Processing” on IS Interface per default.
Check the attendace of the respective queues for the above mentioned
triggers on your UM-Manager/Realm.
Now, please set the “Retrieval State” to “Suspended” for both triggers.
Please keep “Document Processing” enabled.
Run dev_lowag.services.pub:publishMultipleRepoDocs - provide any number for input
After firing this service, enable the “Document Retrieval”-Setting on
IS-Interface by setting it to active. Check IS server.log concerning serial
trigger handling.
Concerning the concurrent triggers, you will notice that the amount of
pending documents equals the Max Pending amount of documents. The Queue
keeps stuck - not handling a single process anymore. The Relaunch of
processing any document is missed.
In Eclipse-Designer, we performed a package reload. After this, you can
break out of this issue. Please perform a package reload to notice, that
processing continues.