I wanted to end/ timeout one of my flowservice (A) as it calls some webservice I have no control (Z) and that often hangs. The flow time out property will not work as my service will wait for 5 min if Z takes 5 min even if I specify timeout 30s in property of A . At the end of 5 min it will give the exception though. WM even smartly states it in the doc.
The work around-
1) Convert A to accept a published doc as input and reply a doc as output (O) using pub.publish:reply
2) Create a trigger and set the service and doc type
3) Create a wrapper service which calls pub.publish:publishandWait and specify waitime in milisecs.
If you specify wait time 10000 i.e 10 secs and the webservice Z took 5 min after 10 secs the pub.publish:publishandWait will end and then look into the O. If that is null then then Z timed out.
Hello
This workaround looks great, but if I understand well, the publishAndWait will work OK and the calling process will continue, but the Z process will STILL be running, and therefore you won’t be able to call it again as long as it still runs?
I ask because I have a problem with a “pub.client.ftp:login” method that may hang, and I’m trying to find a way to kill the login service in such a case (the “timeout” parameter of the login method doesn’t work)…
yes, you are correct the thread of Z will still keep running . As far as I know only way to kill/terminate a hanging thread is to reload the package via IS admin site.
You may call another instance of Z though . But I would suggest you look at the root cause of why login is hanging.
The login methods hangs when the FTP server is starting or stopping. It has happened twice in the last two weeks.
The problem is that we can’t have two instances of the login process running at the same time (the calls are just stacked, waiting for the first one to finish)
It shouldn’t happen much but when it does it blocks all the Integration PlatForm since most services end up in the service that uses the login…
At least with your method we can receive a warning when the login takes too much time.
“The problem is that we can’t have two instances of the login process running at the same time (the calls are just stacked, waiting for the first one to finish)”
Why is this happening? There isn’t anything implicit in the FTP services that will cause this to happen (depending on your IS version). What is your IS version?
Sorry I explained myself badly.
The problem is that the service that uses the login is a service that is triggered when we publish a document. The service that subscribed to this document is frozen on the login call, and therefore the other published documents that should be caught by this trigger stay in the queue.
I don’t see how we could change that without seriously modifying our architecture…
Yes it’s configured to be serial because we have limits on the quantity of connections we can open to our communication platform (the target of the login is almost always the same, and it “could” be used hundreds of times at the same moment).
Besides, we also use
I’ll see if we can manage the number of connections available with a retry or something else…
Oh and I will also check that we don’t have concurrency problems.
Thanks for the tip!
Hi hi,
I’ve decided to implement the publishAndWait thing, and it seems to work when the IS that publishes is the same as the IS that replies.
However I seem to have a problem when I use this with two IS: the publishAndWait method hangs until it times out.
The service that is supposed to answer executes corretly, and sends the reply in less than 5 seconds.
The publishAndWait is set to wait 5 minutes and the service sends the reply in less than 5 seconds so the timeout doesn’t seem to be the problem…
Here are the settings for the publish and wait:
local: false
waittime: 300000
async: false
documentTypeName: set to the type name of my request
document: mapping of an instance of above type
receiveDocumentTypeName: set to the type name of the answer expected (if I don’t set it the result is the same)
Here are the settings of the reply in the other service:
receivedDocumentEnvelope: mapping of the “_env” attribute in the received document
documentTypeName: set to the type name of the answer expected by the other service
document: mapping of an instance of the above type
delayUntilServiceSuccess: not set