Threading Issues in IS 60l

We have an Issue that every IS service that get invoked, is opening a new system thread and not closing it. Our System threads go up into the thousands and never decrease. our IS service is very simple service with:

Success (exit on success)
|__Try (exit on failure
|__Publish to Broker
|__Catch (exit on Done)
|__smtp emails

The servicis invoked from wM-Mainframe package publishing and is flowing smoothly at runtime-- no errors and publishing to Broker is going well.

Are there anything from programming perspective that would cause the threading issue? Any bugs or things to be aware of on IS for threading? We left everything as default for our IS Server configuration, including thread configurations. We left defaults for our services as well. Thanks in advance!


By any chance is there a remote invoke involved in your process? I have seen this in IS4.6 when the timeout setting on the remote server definition was set to -1. The sessions never ended and the thread count increased as in your case.



Along the same lines with remote invoke, if the remote invoke $scope variable is set to default or set to session, session thread will not go away. Use of the “global” $scope parameter will work here.


No Remote Invokes.

I’m also thinking the IS Admin Stats page could be giving us the wrong numbers. Afterall, how could the thread count reach 2,000, when we capped it at 75 (default) for the Thread Pool. But, we did witness each service invocation increment the threads, so at this point I’m not 100% sure. We also witnessed a memory leak in the 6.0.2 WmMainframe package and had to schedule the System.gc(), which isn’t uncommon in IS, but still frustrating knowing the memory leaks still exist. I gave the IS a min/max of 1 gig/1.5 gig in server.bat, but it seemed to allocate to only 1.1 gig and not get anything more after startup and load (btw, we made the server quite light by disabling a lot of the unecessary packages and it still chewed up 1.1 gigs for package load). And then IS performance slowly degraded with the leak and possible mis-threading on WmMainframe publshes and eventually brought the CPU’s and machine to its knees (transactions running through the system until the server maxed out).

Still investigating, so all feedback is appreciated…

Ok, webMethods Tech Services just identified this as a bug in WmMainframe 6.0.2 and we are awaiting a fix.