I am annoyed with the wait & notify synchronisation.
The problem is the following :
I have noticed that if I launch the sync:notify service before the sync:wait service, and then launch the wait with the same key, the synchronisation is made.
In my case, I can have a global service that stops before a wait step, whereas the notify service is launched.
If another process cames to the wait step with the same key, the synchronisation is made with the wrong notify.
I guess that the sync:notify service locks some information somewhere that can be catch by a sync:wait service even if it’s launched after.
Has somebody encountered this problem ?
Is there a way to unlock the notified information ?
Using the same key for synchronization implies that there is some commonality between the two ‘processes’. From what you’re describing it sounds like you are getting two application ‘errors’: i) the real process is not getting the data, and ii) the wrong process is getting incorrect data.
Do you have the ability to build a unique key based on data for each process? This ensures that each process is self contained and does not ‘steal’ data from another process. To be safe I would also utilize the timeout on the wait service to ensure that you do not get any threads waiting indefinitely.
The key used for both the notify and the wait steps must be unique across all of the services running concurrently on a given Integration Server in order to function properly. An exception would be for cases in which you desire for multiple waiting services to receive notification when a single threaded service completes.
On a recent project, we created the key using a combination of a transaction ID supplied by the partner and an internal sequence number. In cases where this was not sufficient to guarantee uniqueness, we appended additional information such as a service name or a generated random number.
Don’t forget to notify your waiting services when exceptions occur in your threaded service. If you don’t do a notify, the waiting service will time out and will be unable to handle the specific error that occurred in the threaded service. We created dedicated Flow and Java services to ensure consistent handing of exceptions in services to be invoked on seperate threads.
We used threaded invocation of both Flow and Java services extensively with very good experience with regard to reliability and performance.
Thanks for your time.
Let’s go further in my explanations :
In fact I am working on a project where webMethods is sending and receiving SMS (through a specific java adapter).
I have a autonomous service (of the java adapter) which is getting SMS responses in queues, decoding these SMS and sending these messages using a notify service to the process that launched the SMS request which is waiting for the response.
The correlation can only be made with the Mobile Phone Number.
And I have several processes that are using this kind of correlation.
I know that a unique key would be better but as far as I have no data preservation through the SMS communication, I can’t use any other data than the Mobile Phone number as the key.
So when a process stops before the wait Step but after having sent the SMS request, the autonomous service is getting the response and launching its notify step.
And this notification will be caught by another wait step from another process instance which using the same Phone number as the key.
I would have liked to give a timeout information to the notify step as well, so the the notify information would be unlocked if not delivered to a wait step.
As a solution, I would like to empty the notify “queue” when it’s not used, but don’t know how to get it right.
Is the notififcation stored somewhere in webMethods database ?