Hi all,

We’re using webMethods 6.1. On our system we have the problem that the threads always get more and more (last time the system needed a restart, because we had 480 Threads). In the Thread List in Administrator i have many threads like “HTTP Handler 10.127.1.12” (30 or more…)

Why are they increasing? Should they not get killed from the JVM?
Sometimes i get “Session lost / Session restored” messages while working with developer or TN Console. Maybe that’s the reason?

Please Help,
Thanks in advance
alex

Alex,
There was a bug in 6.0 that caused this situation with Session lost when a IS was restarted while developers where connected. But I believed it was fixed with either 6.0.1 Sp1 or Sp2. Is it always the same thing causing the excess threads? ie HTTP Handler?

markg
http://darth.homelinux.net

hi

thanks for your answer…
now i have 195 threads. and they daily become more and more…
30 threads called “Service Thread Pool”
and ca. 60 threads called “Thread-105”

but the “HTTP Handler 10.127.1.21” threads become more…

thanks
alex

Hello Alex,

Were you able to resolve the issue of increase in the number Threads.

Thanks,
Sunny

If you are using pub.remote:Invoke to invoke serverices on other Integration Servers and have the timeout set to “-1” this behavior may occur. In essence, you are telling the server to never timeout those remote sessions.

Also, if you have the IS session timeout set to an excessively high value (default is 10min) I think then your session threads may not be reclaimed in a reasonable period of time.

Mark

We had customer with same symptom, but different cause. They we using a network management package (ala CA UniCenter or HP OpenView) to hit IS’s URL (something like http://host:port/invoke/wm.server/ping) with quite short interval. Since the interval is way shorter than the default session timeout, there were a lot of sessions. Just something to watch out for.

The easiest solution is to come up with a polling interval short enough to fit customer’s monitoring requirements, but long enough to avoid excessing load on IS. Also you need to call something that doesn’t leave a session behind if you’re monitoring IS.

Hi Alex

I think it’s necessary to identify what is causing that increase of threads and if they are decreasing or always increasing.
It’s important to understand if they are released

My suggestion is to check the number / name of the threads with the service usage for some period.
Also making some thread dumps could give an help when comparing with number / name of the threads and service usage

Probably there will be much more info about the “HTTP Handler” threads like
HTTP Handler xx.xx.xx.xx" prio=5 tid=0x00a06340 nid=0xc30 runnable [6595f000…6595fd88]
at com.wm.dd.jdbc.oracle.net8.OracleDataProvider.readBytes(Unknown Source)
at com.wm.dd.jdbc.oracle.net8.TTIDataPacket.readCLRInBuf(Unknown Source)
…

“Forcing” the JVM system.gc could be a solution. But it’s important to understand who is causing the threads.

Q: Why are they increasing? Should they not get killed from the JVM?
A: Yes if they are already finalized.

Q: Sometimes i get “Session lost / Session restored” messages while working with developer or TN Console
A: Do you have any firewall between the developer/ TN Console and the IS ? That could be a reason.

Hope this helps

Mourao @ WRIGHTIA
The Right Integration Attitude
http://www.wrightia.com

Sigh. Here we go again…

The urban legend that forcing System.gc() improves performance in any Java application including Integration Server has been long ago proven to be false.

Extensive discussion on the “System.gc() fairy tale” can be found elsewhere on wMUsers by searching for “old wives tale”, “dead horse society” or “garlic cloves”. Those posts contain links to technical articles from Sun and other JVM vendors which assert that forcing use of System.GC() can actually degrade performance with modern JVM versions.

Mark

I think there was a bug in 6.0.1 and 6.1 (not sure if its resolved in new releases) with indicating the number of threads in Admin Page. There was a discussion about this long time ago. To determine if the count is correct or not you can click on the number from IS Admin or do a thread dump and count the number of threads. When I encountered this problem, we noticed that the number shown on the page was not even close to the real number of threads in the JVM.