We recently had this problem in our production system:
Here is the description:
There is Package A and Package B.
Package B refers to some flow services from Package A due to some common logic. (e.g. A-Flow-1, A-Flow-2 etc). When tested in TEST, everything worked fine. When deployed in PROD, Package B kept reprocessing the message over and over and also the message for Package A was touched. We had to bring Package B down in order to stop this from happening.
We are not able to reproduce this in TEST environment and are running out of ideas to figure out what might have happened to cause it.
Does referring a service from a package can cause issue to the original package?
Calling a service in a particular package from another package, in and of itself, will not cause the behavior you’re seeing.
Please provide some details about what the service in package B is doing. You’ll also need to explain what “the message for Package A was touched” means exactly.
Thanks Raemon for your response. I’ll try to explain what is happening and please let me know if that does not do the job and I’ll try in a different way.
Package A:
This package has all the code:
When a message is received for Package A, it does all the translation, mapping as per the logic
Package A has the flow services defined in it to perform all the logic
After translation, Package A sends the data to the destination
Package B also qualifies to accept the same message as for Package A
Package B’s destination needs the output exactly same as that for Package A’s destination
Package B refers to the flow services from Package A for translation, mapping etc. logic
Package B sends the data to the destination upon translation
This all worked as expected in TEST environment. Since there was no way we could do load testing in TEST, we had to move the Package B to PROD to perform load testing. We queued around 2000 messages for Package B.
When the trigger for Package B was enabled, the message for Package A and Package B began to reprocessed even when they had already being translated and delivered to the destinations. So this additional translation caused extra characters to get added in the message (This is what I meant by the message in Package A was touched).
I know this is a little long…but I couldn’t think anything better.
Please let me know if this does not help understand.
Please check the triggers and Queue listners they might be causing the problem by triggering both A and B process when the message is supposed to be handled by B only.
If A and B are both subscribing to the same document type, then they will both process the message. When you queued messages for B, they also went to the A trigger.
You said this worked in test. Compare the configuration of all components between test and prod.
Thanks Reamon.
So, if the messages are queued for Trigger B, once enabled, can they also go to Trigger A?
Because the way I looked at it is that the messages will only be processed for Trigger B if they are queued for Trigger B. Is that understanding not correct?
Please let me know.
I’m running out of options to look into for Triggers…I’m not very sure about the queues.
We have had situations where there were around 8000 messages queued for a trigger and upon enabling, they all went through only that trigger.
Is there anything you can point out to that can may be cause this weird behavior?
Thanks for your help.
When the documents are published, Broker delivers to all subscribers based on document type (you haven’t mentioned that there are content filters so I assume there are none). Since triggers A and B subscribe to the same document type, both will get all published docs of that type.
My point was, unless you did something special, there isn’t a way to queue document for only B. When you published the 2000 messages intended to test B, they also went to A because A has a subscription for that same doc type.
I’m new to webMethods so I’m not sure if this is a new feature but yes, we can queue messages for a trigger. So when that trigger is enabled, the messages queued gets processed only for that trigger.
And we did this in the past for some other triggers and never came across something like this. That is why we are a little confused at the moment to understand what might have happened!
This is not weird if two triggers point to same document type then when the document is published it will be processed by both of them…so please make sure that you have some filters on the content of document to differentiate which document is to be processed by which trigger.Please try to have some sort of condition incoming message content to differentiate processing of A and B.
Okay, let’s not get too wrapped up in queuing details. Let’s focus on what you did exactly and what symptoms you’ve seen. You said: “Package B kept reprocessing the message over and over and also the message for Package A was touched.”
How did you determine that B was “reprocessing a message over and over?”
We tried to cover this earlier, but what exactly do you mean by “the message for Package A was touched?” What exactly did you see? Did you see log entries? MWS entries?
We’ll need more info about the specifics of each package if we’re going to resolve this.
Thanks for your response Savanigadda.
Yes, the filter conditions are there on the two triggers and they are slightly different than one another. And the messages are actually queued for the Trigger B exclusively. Same messages were already processed by Trigger A because it was already enabled.
I am sure you filter conditions are not working as expected and may be some configuration is still missing test vs prod…and thus the behaviour of processing same doc twice by two triggers.
Can you check a close view and see what differences in each environment to analyze?