On Mar 9, 2010, at 10:07 AM, Robert Joly wrote: > Hi guys, > I have been investigating XX-7634 which reports high CPU utilization by > java processes after an ISO install of the commercial version (SCS) > which uses the IBM JVM. > > Basically, after an ISO install I'm seeing that *all* the java-based > processes chew up between 50% and 100% of one processor and remained > like that for as long as I kept the box up (few hours). The processes > in question are sipXpage, sipXivr, sipXrelay, sipXconfig, sipXrest and > sipXprovision. Using jconsole I was able to find that the hot thread > for each of these services is called 'Attach Handler' > (com.ibm.tools.attach.javaSE.AttachHandler.run()) and I also found that > I can eliminate the high CPU condition completely on a fresh install by > hand-editing the launch command for each of these java processes to add > the following property: -Dcom.ibm.tools.attach.enable=no > > If I add this property then all the processes are well-behaved but I do > not understand the fundamental reason why the hot thread is there in the > first place. I'm therefore turning to the Java gods that are tuned in > to this list to see if they had previous encounters with this. > > Thanks in advance, > bob
I would like to know why this issue has all of a sudden shown up on the radar. The Attach API and supporting AttachHandler thread was introduced, as a result of an upgrade to the IBM JVM, back on 2009-11-14 Is it possible that the high CPU utilization has been there since then but no one had noticed it until now? If the AttachHandler thread is of a low priority then it would merely be consuming idle CPU time and be preempted when there was real work to be done. If that is the case then it has no real impact on the product other than to possibly disqualify us for Green certification. We're not using the Attach API for anything so I do not see any harm in disabling it by default. There should also be no portability issues should we choose to blanketly define the property as a non-IBM JVM will quietly ignore it. -Mardy _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
