In the wM IS Built-In Services Guide (for 7.1.1), a note under the pub.publish:waitForReply service mentions -
“If the waitTime interval elapses before the pub.publish:waitForReply service executes, the service immediately returns a null document which indicates that the wait time has expired.”
Does this mean that if the reply has been received within the waitTime, but the waitForReply was invoked after the waitTime, the reply document is ignored?
I tried to emulate the above mentioned scenario and my reply document is always null :(. This is what I basically did -
Why do you have a sleep step in the FLOW service? With pubAndWait using 400ms (which is probably too short) and then putting the thread to sleep for 400ms, you’re guaranteeing that the thread will miss the response.
Thx for your response, devexpert. I’m still not quite clear about this.
In this case, the response is sent back within the wait time. The problem is that its being picked up after the wait time has elapsed, by the waitForReply. This is what’s confusing me. Why should a document that is received on time be discarded because it wasn’t picked up on time? Is that expected behavior?
Thanks for your response, Rob. I was just trying to create a scenario where the waitForReply is invoked after the waitTime has elapsed. The easiest way I could think of was to put in a sleep. The document is received within 400ms, and for any sleep time less than 400ms, the document is picked by the waitForReply. I just wanted to know if its correct behaviour for a document received within the waitTime, to be discarded if it isn’t picked within the waitTime.
AFAIK, that is normal behavior. IS may have received the reply but the thread that is waiting, and will timeout, has not. Effectively, the waiting thread does not care if the reply is “in transit” when it times out. Even if the reply is waiting on the IS temp doc storage, it is considered in transit and too late.
Is that expected behavior?