we have requirement,and for the past few days i am wrking on that,still i am unable to do,i thought better to approach WmUsers and posting the thread.
we have a service which is doing publishandwait and waiting for 10sec for the reply doc,after 10sec it will continue through a publishwait time out error.
now problem is we are unable to track when the reply document is coming(in case of responces greater than 10sec),here reply is giving by other external system,which is also a webMethods(via broker terittory).
If the reply has came in 10sec its fine.if its greater than 10sec we need to track the reply docs
Can any one suggest a way for tracking the reply Doc
i have tried using testclient and deadletter queue
normally when a timeout reply comes to our server we are able to see a messahe in server log saying no waiting therad for document ID:12345(for ex)
now where that rejected docment will go?? can we create dead letetr queue??
how can we track those replied timed out documents?
I am not sure I understood your requirement completely, but you can do the following:
In case of a time-out, log the document id to a custom DB table/temp repository store
Create a trigger subscribing to the reply document, and check the document ID exists in the table. If yes execute the logic, else do nothing.
Can you increase the duration of the timeout? 10 secs is fairly short, depending on what the responding server is doing, network traffic, etc. A timeout of 30-90 secs might work out.
You might consider this principle: if the response has not been received within the timeout period, the requestor gives up on it completely. No tracking. No trying to record it somewhere else or attempt to recover it. Why? Because the requestor gave up waiting for it. Trying to recover late responses seems like the wrong path.
For all intents and purposes, a timeout means there is no response. Possible actions are give up entirely or attempt the request/reply again (up to X times) until it succeeds or all retries fail. Trying to capture late/failed responses adds unnecessary complexity to the overall solution.
Another item to consider–not using a pub/sub mechanism for a request/reply operation.
Dead letter queues are for published messages that have no subscribers. A reply is not a published message. (Though there is an option to have a responder publish a reply instead of deliver–but then you wouldn’t use publishAndWait on the requestor side).
we even thought of the procudure which u have suggested(storing the document ID).
but even if we store docuemnt ID from the envelope,we can’t subscribe for the document as in reply the document is not published to broker,it will be directly sent to waiting thread(can we say this waiting thread as dynamic client Queue??)
now i ahve only ways to reduce the time out either by increasing the wait time or some other procudures.
if we cant then i will try to ruduce the time outs atleast.
you have asked me to increase the time out period from 10 to 30-90 but we will be having 20 requests each second(to the server) means around 1200 per minute approx(performance Issues might arrise if we have such long timeout).
will increase to 15 and will see.
And one more Observation which i am thinking might be the reaosn for timeouts.
Here we have two systems(say X and Y)
X is doing publish and wait and Y is replying with response to X.
transmission is via broker terittory.
now some times i observed in MWS that Both Brokers of X and Y are not linked to each other, it will happen for 10 min and then again connect each other.
My observation is in this time only Max time outs is happening.
means as the brokers are not interlinked ther is no connection and then docs are getting queued up in X…Resulting in Timeouts
Now how can we ensure 100% Broker to Broker Connectivity in a Territory??
Reply documents are not published but are delivered. You cannot subscribe to replies.
Increasing the waitTime in the publishAndWait call is the first approach I would investigate.
You’re right that increasing the waitTime has performance implications as more threads may exist at any one time waiting for replies. Measure this to see if it is a problem.
Unfortunately, there isn’t a way to guarantee 100% connectivity between Brokers. So you’ll want your code to be as resilient as possible in the face of transient errors.
One approach would be to retry X number of times and dynamically increase the waitTime for each successive retry. It has been my experience with HTTP interactions, that implementing a simple retry addresses the majority of transient failure issues. The same should hold true for Broker-based interactions. It is likely that a retry after a timeout will work right away.
A variation on this approach would be to wait for a short period of time between retries.
Request.
Wait for reply.
On timeout:
–Wait X seconds.
–Repeat request.
You could dynamically increase the wait between retries too. Most times, there is no point in retrying 5 times within 1 minute. Spread those 5 times out over a longer period and you’re more likely to see success. For example:
00: Request.
10: Timeout.
10: Wait 10.
20: Request
30: Timeout.
30: Wait 20.
50: Request.
60: Timeout.
60: Wait 40.
100: Request
110: Timeout.
etc.
And one more Observation which i am thinking might be the reaosn for timeouts.
Of course these approaches assume that the integration is allowed to take up to max time that all retries and timeouts may take. If the integration cannot take that long, then you have no real choice but to fail the integration.
If we wann we can log the published documents and replied docs to IS Core Audit.
i have tried this and each time
When i check Log Documents in MWS and selected docs for Logging.
i’m able to log published and replied docs in WMDOCUMENT.
But the thing is in that table one BLOB Object in which we will store the DOC. Point is how to see the BLOB Objects??
Can we use any tools for reading BLOB Objects?? so that i can track the docs.
here this tracking is jus for analysis tahts why i will enable the document logging for 10 min(other wise i Might get database memory out).
this is all about Logging
Hi Reamon we will try to implement the solution(Dynamically increasing wait time and retrying)
Thx u for u r response.