Yup, already have the sipxrest at debug. I was surprised but the lacl of
activity in the log. With a clean log and starting the process after waiting
about 5 minutes here all that has been recorded.
"2012-09-13T23:43:13.054000Z":1:JAVA:WARNING:voice:main:00000000:sipxrest:"using
default tls security policy"
"2012-09-13T23:46:24.583000Z":1:JAVA:INFO:voice:main:00000000:StackLoggerImpl:"StackProperties
{}{gov.nist.javax.sip.LOG_STACK_TRACE_ON_MESSAGE_SEND=false,
gov.nist.javax.sip.IS_
BACK_TO_BACK_USER_AGENT=true,
gov.nist.javax.sip.RFC_2543_SUPPORT_ENABLED=false,
gov.nist.javax.sip.RECEIVE_UDP_BUFFER_SIZE=65536,
gov.nist.javax.sip.MAX_FORK_TIME_SECONDS=180, g
ov.nist.javax.sip.TRACE_LEVEL=INFO,
gov.nist.javax.sip.STACK_LOGGER=org.sipfoundry.commons.log4j.StackLoggerImpl,
javax.sip.STACK_NAME=sipxrest, javax.sip.ROUTER_PATH=org.sipfoun
dry.commons.siprouter.ProxyRouter, gov.nist.javax.sip.REENTRANT_LISTENER=true,
gov.nist.javax.sip.SERVER_LOGGER=org.sipfoundry.commons.log4j.ServerLoggerImpl,
gov.nist.javax.sip.
THREAD_POOL_SIZE=1}"
"2012-09-13T23:46:24.585000Z":2:JAVA:INFO:voice:main:00000000:sipxrest:"value
-1000 will be used for reliableConnectionKeepAliveTimeout stack property"
"2012-09-13T23:46:24.585000Z":3:JAVA:INFO:voice:main:00000000:sipxrest:"Setting
Stack Thread priority to 10"
"2012-09-13T23:46:24.623000Z":4:JAVA:WARNING:voice:main:00000000:sipxrest:"using
default tls security policy"
"2012-09-13T23:46:24.631000Z":5:JAVA:INFO:voice:main:00000000:sipxrest:"BuildTimeStamp
= Date = 20120813 Time = 1138"
"2012-09-13T23:46:24.636000Z":6:JAVA:INFO:voice:main:00000000:sipxrest:"the sip
stack timer gov.nist.javax.sip.stack.timers.DefaultSipTimer has been started"
"2012-09-13T23:48:10.051000Z":1:JAVA:INFO:voice:main:00000000:StackLoggerImpl:"StackProperties
{}{gov.nist.javax.sip.LOG_STACK_TRACE_ON_MESSAGE_SEND=false,
gov.nist.javax.sip.IS_
BACK_TO_BACK_USER_AGENT=true,
gov.nist.javax.sip.RFC_2543_SUPPORT_ENABLED=false,
gov.nist.javax.sip.RECEIVE_UDP_BUFFER_SIZE=65536,
gov.nist.javax.sip.MAX_FORK_TIME_SECONDS=180, g
ov.nist.javax.sip.TRACE_LEVEL=INFO,
gov.nist.javax.sip.STACK_LOGGER=org.sipfoundry.commons.log4j.StackLoggerImpl,
javax.sip.STACK_NAME=sipxrest, javax.sip.ROUTER_PATH=org.sipfoun
dry.commons.siprouter.ProxyRouter, gov.nist.javax.sip.REENTRANT_LISTENER=true,
gov.nist.javax.sip.SERVER_LOGGER=org.sipfoundry.commons.log4j.ServerLoggerImpl,
gov.nist.javax.sip.
THREAD_POOL_SIZE=1}"
Perhaps setting the call control log to debug isnt actually getting set to
debug.
I'll check it out.
-M
>>> "M. Ranganathan" <[email protected]> 09/14/12 9:09 AM >>>
kill the process, tail a debut log of it. It will tell you more useful
information.
On Fri, Sep 14, 2012 at 9:00 AM, Matt White <[email protected]> wrote:
> Yes, the latest jain-sip has fixed our issue with sipxbridge. We have
> tested this on 4.2.1 and 4.4
>
> Here is the process we followed.
> 1. Shutdown sipx
> 2. Replace the current jain-sdp under the Sipxcommons and openfire
> directories with the new one.
> 3. startup sipx
>
> As soon as sipx starts (and sipxrest by extension) there is one java process
> that will stay at 100%.
> ps -ef indicated it was the sipxrest process.
>
> If we restart the "call control" service in sipx via the webgui, the process
> will disappears for a second and then come back at 100%
> If we kill the process from the cli then the process disappears and
> utilization drops, but then sipxsupervisor starts it back up and it stays at
> 100% again.
>
> Here is the ps -ef output of the process, you can see it is loading the
> jain-sdp:
>
> /usr/bin/java -Dcom.ibm.tools.attach.enable=no -Dconf.dir=/etc/sipxpbx
> -Dplugin.dir=/usr/share/java/sipXecs/sipXrest/plugins -Djav
> ax.net.ssl.trustStore=/etc/sipxpbx/ssl/authorities.jks
> -Djavax.net.ssl.trustStoreType=JKS
> -Djavax.net.ssl.trustStorePassword=changeit
> -Djavax.net.ssl.keyStore=/etc/sipxpbx/ssl/ss
> l.keystore -Djavax.net.ssl.keyStorePassword=changeit
> -Djetty.x509.algorithm=SunX509 -Djetty.ssl.password=changeit
> -Djetty.ssl.keypassword=changeit -Dorg.apache.commons.logging.Lo
> g=org.apache.commons.logging.impl.Log4JLogger -Dsipxrest.command=start -cp
> /usr/share/java/sipXecs/sipXrest/sipxrest.jar:/usr/share/java/sipXecs/sipXcommons/Stun4J.jar:/usr/share
> /java/sipXecs/sipXcommons/ant-launcher.jar:/usr/share/java/sipXecs/sipXcommons/ant.jar:/usr/share/java/sipXecs/sipXcommons/bcel.jar:/usr/share/java/sipXecs/sipXcommons/com.noelio
> s.restlet.ext.servlet.jar:/usr/share/java/sipXecs/sipXcommons/com.noelios.restlet.jar:/usr/share/java/sipXecs/sipXcommons/commons-beanutils.jar:/usr/share/java/sipXecs/sipXcommon
> s/commons-cli.jar:/usr/share/java/sipXecs/sipXcommons/commons-codec.jar:/usr/share/java/sipXecs/sipXcommons/commons-collections.jar:/usr/share/java/sipXecs/sipXcommons/commons-di
> gester.jar:/usr/share/java/sipXecs/sipXcommons/commons-io.jar:/usr/share/java/sipXecs/sipXcommons/commons-lang.jar:/usr/share/java/sipXecs/sipXcommons/commons-logging-api.jar:/us
> r/share/java/sipXecs/sipXcommons/commons-logging.jar:/usr/share/java/sipXecs/sipXcommons/commons-net.jar:/usr/share/java/sipXecs/sipXcommons/cpptasks.jar:/usr/share/java/sipXecs/
> sipXcommons/dnsjava.jar:/usr/share/java/sipXecs/sipXcommons/dom4j.jar:/usr/share/java/sipXecs/sipXcommons/jain-sip-sdp.jar:/usr/share/java/sipXecs/sipXcommons/javamail.jar:/usr/s
> hare/java/sipXecs/sipXcommons/javax.servlet.jar:/usr/share/java/sipXecs/sipXcommons/jaxen.jar:/usr/share/java/sipXecs/sipXcommons/jce.jar:/usr/share/java/sipXecs/sipXcommons/jdom
> -1.0.jar:/usr/share/java/sipXecs/sipXcommons/jetty.jar:/usr/share/java/sipXecs/sipXcommons/jibx-bind.jar:/usr/share/java/sipXecs/sipXcommons/jibx-run.jar:/usr/share/java/sipXecs/
> sipXcommons/junit.jar:/usr/share/java/sipXecs/sipXcommons/log4j.jar:/usr/share/java/sipXecs/sipXcommons/not-yet-commons-ssl.jar:/usr/share/java/sipXecs/sipXcommons/org.restlet.ja
> r:/usr/share/java/sipXecs/sipXcommons/postgresql-jdbc.jar:/usr/share/java/sipXecs/sipXcommons/sipxcommons.jar:/usr/share/java/sipXecs/sipXcommons/smack.jar:/usr/share/java/sipXec
> s/sipXcommons/smackx.jar:/usr/share/java/sipXecs/sipXcommons/ws-commons-util.jar:/usr/share/java/sipXecs/sipXcommons/xmlrpc-client.jar:/usr/share/java/sipXecs/sipXcommons/xmlrpc-
> common.jar:/usr/share/java/sipXecs/sipXcommons/xmlrpc-server.jar:/usr/share/java/sipXecs/sipXcommons/xpp3.jar:/usr/share/java/sipXecs/sipXrest/plugins/sipXcallController.jar:/usr
> /share/java/sipXecs/sipXrest/plugins/sipxcdrLog.jar
> org.sipfoundry.sipxrest.RestServer --start
>
> -M
>
>>>> "M. Ranganathan" <[email protected]> 09/14/12 8:34 AM >>>
>
> Please describe the sequence of events that leads to the 100% CPU situation.
>
> When you say they are "working fine" does that imply your sipXbridge
> issues are fine now?
>
>
>
> On Thu, Sep 13, 2012 at 7:56 PM, Matt White <[email protected]>
> wrote:
>> Just thought I'd give an update on updating the jain-sip
>>
>> I've put this latest jain-sip in production on 3 system for several weeks
>> now. One 4.2.1 and the other 2 are 4.4
>>
>> They are working fine and there is no useability issues. However the
>> sipxrest java process pegs at 100%.
>>
>> Our systems are multi-core so it doesnt affect system usage.
>>
>> Setting the call control logs to debug dont show any additional detail.
>>
>> Is there a good way to debug the sipxrest process.
>>
>> -M
>>
>>>>> Matt White 08/13/12 12:14 PM >>>
>> Thanks, you just answered the questions in my last reply!
>>
>> -M
>>
>>>>> "M. Ranganathan" <[email protected]> 08/13/12 11:57 AM >>>
>> Attached is a jar file for jain-sip. Replace the jar and tested it out
>> before posting traces please.
>>
>> Don't be too nervous - you can always revert.
>>
>>
>>
>> _______________________________________________
>> sipx-users mailing list
>> [email protected]
>> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>
>
>
> --
> M. Ranganathan
> _______________________________________________
> sipx-users mailing list
> [email protected]
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>
--
M. Ranganathan
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/
