Hello to all, I’m having some issues while using the the pub.sync:wait and pub.sync:notify

The scenario goes like this:
A process is triggered by catching a document, next step takes some info from that original document and creates another document.
The document is create to the outside system, in which someone will see that document, take some actions and later when it’s done it changes the document status. (You may see it as sort of trouble ticketing system)
After creating the document I want to wait for the status change of that document. For that, the flow step I’m using is the pub.sync:wait.
Meanwhile there is a trigger that picks up documents with the changed status and delivers them to a service that will use the pub.sync:notify to tell the parent service to continue.
To match the documents I’m using the internal ID of the document as a the key parameter.

My problem now is that while waiting, other documents can change it’s status and they get picked up by the trigger. And when that happens the process fails with a time out, before the time limit is reached (which is around 180).
So when right document changes status everything works fine.
If I change the status of a wrong document, the process fails with a timeout. Shouldn’t the pub.sync:wait keep waiting for the correct notify?

I hope I explained myself, any questions please do. Thanks in advance for any help

It’s a little difficult to be precise about your scenario, but if I have understood correctly, I’d be tempted to do what you are looking at completely with the messaging - if you are already using triggers and so on, then the sync and asynch pub-reply mechanisms might be more appropriate. Have a look at the JMS Client Developer’s Guide or the Pub-Sub Developers Guide if you are not planning on using JMS.

Also, if you do have long duration waits (not sure how long your status changes can take to come through, but you can’t hold threads open indefinitely), you might want to rethink the design more generally and consider having completely asynchronous communication which would allow for the IS to go down and come back up again, with messages appearing on persistent queues. You wouldn’t use a pub-reply approach for this as the context for the reply is lost when IS goes down. Use pure publish-subscribe approaches instead if you need a more resilient solution or the duration of the wait can be long.

Regds,
Rob.