We have a issue with more number JMS ID at destination application.
First let me explain the integration flow:
JMS notification → subscriber service → canonical Publish document → subscriber service → sent to JMS Broker topic
We have counted the execution of subscriber services to confirm that number of notification documents published is same as canonical document published. We don’t have access to see documents in mywebmethods.
As per destination application they are processing more number of requests than the count of subscriber service executed.
We are not able to see the content of requests, but we can see that count is 25% more than published by subscriber service.
I have also checked, JMS ID is not getting created in flow service. My understanding generating JMS ID is integration server internal process.
Can somebody please help me understand, how the JMS ID is generated by IS or JMS broker.
What should we check to verify that more JMS ID are processed at destination than published by subscriber services.
once you publish your data using pub.jms:send keep JMSMessage document in pipeline.
and log value of JMSMessage/header/JMSMessageID to see JMSMessageID of published document. On subscriber log same field to see if you got the same document which was published.
There could be multiple reasons for your duplicate messages received in subscription service… Following are few… Pls cross verify…
If you have more than one trigger subscribing at same ‘TOPIC’, messages will be delivered to all the trigger client queue
If it is only one JMS trigger, and if you are in IS cluster, make sure you set the ‘Durable Subscriber Name’ in ‘JMS Trigger’. This will create only one client queue for this trigger
By logging into MWS,
Administration > Messaging > Broker Servers > Document Types
search for JMS Topic
click on the ‘Topic’ link and go to ‘Clients’ tag. if you have more than one client listed, this means you have multiple triggers listening on the same topic. You will also see DefaultDLQ_ as one of the client if you have configured it. Messages that doesn’t pass the filter criteria (if there is any), those messages will be sent to ‘DefaultDLQ_’.
Actually TOPIC subscriber is not a webMethods IS, it is subscribed by a WebSphere application.
We tried to reproduce this problem in Acceptance env but no luck.
We only have this issue in production.
We have also observed that when the number of JMS messages in topic are more, load at IS is more than usual. But not sure how load could create more JMS messages in TOPIC, than number of times pub.jms:send service is invoked.
Pavan,
Load is ‘not the culprit’ here. As I explained before, there could be many susbcribers or IS/Broker gets disconnects frequently which could potentially create duplicates.
As you say this is happening only in Production, you have to try to replicate this scenario in another environment by replicating Production system. Did you try? The issue is not going to go anywhere unless the root cause is found and fixed once for all…