Trigger chokes on subscriber hung threads

, , ,
1

Hi,
We have a 6.5.2 IS and broker running on windows server. We have a trigger that runs concurrently at 20 threads. The issue we are facing is that for some reason we are having hung threads of the subscriber service and ultimately if all the 20 threads get hung, the documents are getting stacked up in the broker queue.

The only we are able to get rid of this by restarting our IS as we dont have a way of killing those subscriber service hung threads alone.

The subscriber it self is in a Main,Try, Catch pattern so any exception should be handled gracefully. At this point I believe it happening because we are not getting any response from a customer webservice(not even a time out and hence the service is just waiting). However i do not have any concrete proof for that.

Is there any way we can set up a timeout on the subscriber service invoked by the trigger so that if the service doesnt completes in a set time, it will close off with out resulting in a hung thread.

Thanks,
Manju

2

Short answer is no on the killing of threads. You could write a Java service that spawns a background thread that you keep control of and exit the thread when the timer on the thread expires but that is not the optimal way.

Have you tried setting your Outbound HTTP Timeout to something small? How about your soapHTTP or soapClient call timeout parameter(don’t remember which one is present in 6.5)?

Anything else going on in that subscriber service?

3

You mean the server level property for the soapHttp and Http calls right…and also there’s nothing else going in that subscriber except for one db update service.

Just to confirm, is watt.net.timeout the property you are referring to. Also is this for the HTTPRequests in which the IS is acting as client?

watt.net.timeout
Specifies the number of seconds the server waits for an HTTP request to be fulfilled before
the request times out. The default is 0.

Thanks,
Manju

4

Yep that’s the one. try something like 120. 0 means forever.

5

Thanks griffima… we decided on going with the server property watt.net.timeout and that seems to have solved our issue…

Admin has bailed out on applying 6.5 SP3 patch which would have given us a more granular control for each http call, instead of a server level setting…