wrapper-user — User issues for Wrapper. (Support questions, etc.)

Re: [Wrapper-user] Getting transport error 202: bind failed: Address already in use error starting service

[David H. <dho...@gm...>]

Also I should mention I do have this new dev app in a different folder and
it has a different name, e.g. dev_ prefixed to name.  Everything else I
think is the same.

-Dave

On Thu, Nov 13, 2014 at 7:50 PM, David Hoffer <dho...@gm...> wrote:

> I'm not sure I understand.  We do have the production app running...no
> idea what ports the wrapper is using there.  I need this to run at the same
> time...for debugging.
>
> -Dave
>
> On Thu, Nov 13, 2014 at 7:02 PM, Leif Mortenson <
> lei...@ta...> wrote:
>
>> David,
>> Looking at the command line, the Wrapper has bound and is listening on
>> port 32002, and the JVM will then use a port in the 31000-31999 range will
>> be used.  There are no other ports being used by the Wrapper.
>>
>> As 32002 was used rather than 32000, that means that 32000 and 32001 are
>> in use or were recently in use.   Could you check to make sure that another
>> instance of your application is not currently running?  That would explain
>> the application level port failing to bind.
>>
>> Cheers,
>> Leif
>>
>>
>>
>> On Fri, Nov 14, 2014 at 10:34 AM, David Hoffer <dho...@gm...>
>> wrote:
>>
>>> I'm using 3.5.15-pro version.  I have the production service on this VM
>>> working but I need to standup a second instance so I can debug a problem.
>>> I'm getting the following error with the second instance.  What is causing
>>> 'ERROR: transport error 202: bind failed: Address already in use'?  I have
>>> my app configured to use different ports so as to not conflict with the
>>> production app...is JSW using the same port?
>>>
>>> How can I fix this?
>>>
>>> wrapper  |
>>> ---------------------------------------------------------------------
>>> wrapper  | The JVM is being launched with a debugger enabled and could
>>> possibly
>>> wrapper  | be suspended.  To avoid unwanted shutdowns, timeouts will be
>>> wrapper  | disabled, removing the ability to detect and restart frozen
>>> JVMs.
>>> wrapper  |
>>> ---------------------------------------------------------------------
>>> wrapper  | Command[0] : /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java
>>> wrapper  | Command[1] : -Djava.util.Arrays.useLegacyMergeSort=true
>>> wrapper  | Command[2] : -Xdebug
>>> wrapper  | Command[3] :
>>> -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
>>> wrapper  | Command[4] : -Xms64m
>>> wrapper  | Command[5] : -Xmx1024m
>>> wrapper  | Command[6] : -Djava.library.path=./
>>> wrapper  | Command[7] : -classpath
>>> wrapper  | Command[8] :
>>> ../lib/activation-1.1.jar:../lib/aopalliance-1.0.jar:../lib/asm-3.3.1.jar:../lib/bcmail-jdk15-1.44.jar:../lib/bcprov-jdk15-1.44.jar:../lib/commons-codec-1.5.jar:../lib/commons-email-1.2.jar:../lib/commons-lang-2.6.jar:../lib/commons-logging-1.1.1.jar:../lib/commons-math-1.2.jar:../lib/commons-net-3.1.jar:../lib/cxf-api-2.7.10.jar:../lib/cxf-rt-bindings-soap-2.7.10.jar:../lib/cxf-rt-bindings-xml-2.7.10.jar:../lib/cxf-rt-core-2.7.10.jar:../lib/cxf-rt-databinding-aegis-2.7.10.jar:../lib/cxf-rt-databinding-jaxb-2.7.10.jar:../lib/cxf-rt-frontend-jaxws-2.7.10.jar:../lib/cxf-rt-frontend-simple-2.7.10.jar:../lib/cxf-rt-management-2.7.10.jar:../lib/cxf-rt-transports-http-2.7.10.jar:../lib/cxf-rt-transports-http-jetty-2.7.10.jar:../lib/cxf-rt-transports-local-2.7.10.jar:../lib/cxf-rt-ws-addr-2.7.10.jar:../lib/cxf-rt-ws-policy-2.7.10.jar:../lib/dhs-commons-1.6-SNAPSHOT.jar:../lib/dom4j-1.6.1.jar:../lib/fluent-hc-4.3.1.jar:../lib/fontbox-1.8.2.jar:../lib/geronimo-servlet_3.0_spec-1.0.jar:../lib/guice-3.0.jar:../lib/guice-assistedinject-3.0.jar:../lib/httpclient-4.3.1.jar:../lib/httpcore-4.3.jar:../lib/ifreelance-pn27284-webservice-1.5-SNAPSHOT.jar:../lib/itext-2.1.7.jar:../lib/javax.inject-1.jar:../lib/jaxb2-basics-runtime-0.6.1.jar:../lib/jaxb-api-2.2.jar:../lib/jaxb-impl-2.2.4.jar:../lib/jdom-1.0.jar:../lib/jempbox-1.8.2.jar:../lib/jetty-continuation-8.1.14.v20131031.jar:../lib/jetty-http-8.1.14.v20131031.jar:../lib/jetty-io-8.1.14.v20131031.jar:../lib/jetty-security-8.1.14.v20131031.jar:../lib/jetty-server-8.1.14.v20131031.jar:../lib/jetty-util-8.1.14.v20131031.jar:../lib/jetty-xml-8.1.14.v20131031.jar:../lib/joda-time-1.6.2.jar:../lib/jsr173_api-1.0.jar:../lib/jsr250-api-1.0.jar:../lib/jsr305-1.3.9.jar:../lib/log4j-1.2.16.jar:../lib/mail-1.4.1.jar:../lib/mortgage-tools-1.4-SNAPSHOT.jar:../lib/neethi-3.0.3.jar:../lib/pdfbox-1.8.2.jar:../lib/poi-3.9.jar:../lib/poi-ooxml-3.9.jar:../lib/poi-ooxml-schemas-3.9.jar:../lib/runtime-0.4.1.jar:../lib/slf4j-api-1.7.5.jar:../lib/stax2-api-3.1.1.jar:../lib/stax-api-1.0-2.jar:../lib/stax-api-1.0.1.jar:../lib/woodstox-core-asl-4.2.0.jar:../lib/wrapper-3.5.15.jar:../lib/wsdl4j-1.6.3.jar:../lib/xml-apis-1.0.b2.jar:../lib/xml-resolver-1.2.jar:../lib/xmlbeans-2.3.0.jar:../lib/xmlschema-core-2.1.0.jar
>>> wrapper  | Command[9] : -Dwrapper.key=RI8htg3WrkuGSLCkOHiJ-0Dkk4OtOvbe
>>> wrapper  | Command[10] : -Dwrapper.port=32002
>>> wrapper  | Command[11] : -Dwrapper.jvm.port.min=31000
>>> wrapper  | Command[12] : -Dwrapper.jvm.port.max=31999
>>> wrapper  | Command[13] : -Dwrapper.pid=20122
>>> wrapper  | Command[14] : -Dwrapper.version=3.5.15-pro
>>> wrapper  | Command[15] : -Dwrapper.native_library=wrapper
>>> wrapper  | Command[16] : -Dwrapper.cpu.timeout=10
>>> wrapper  | Command[17] : -Dwrapper.jvmid=5
>>> wrapper  | Command[18] : -Dwrapper.lang.domain=wrapper
>>> wrapper  | Command[19] :
>>> com.qsd.service.jsw.JavaServiceWrapperWebServiceLauncher
>>> wrapper  | Launching a JVM...
>>> jvm 5    | ERROR: transport error 202: bind failed: Address already in
>>> use
>>> jvm 5    | ERROR: JDWP Transport dt_socket failed to initialize,
>>> TRANSPORT_INIT(510)
>>> jvm 5    | JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No
>>> transports initialized [../../../src/share/back/debugInit.c:750]
>>> jvm 5    | FATAL ERROR in native method: JDWP No transports initialized,
>>> jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197)
>>> wrapper  | JVM received a signal UNKNOWN (6).
>>> wrapper  | JVM process is gone.
>>> wrapper  | JVM exited while loading the application.
>>> wrapper  | There were 5 failed launches in a row, each lasting less than
>>> 300 seconds.  Giving up.
>>> wrapper  |   There may be a configuration problem: please check the logs.
>>> wrapper  | <-- Wrapper Stopped
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> Comprehensive Server Monitoring with Site24x7.
>> Monitor 10 servers for $9/Month.
>> Get alerted through email, SMS, voice calls or mobile push notifications.
>> Take corrective actions from your mobile device.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Wrapper-user mailing list
>> Wra...@li...
>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>
>>
>

Re: [Wrapper-user] Getting transport error 202: bind failed: Address already in use error starting service

[David H. <dho...@gm...>]

I'm not sure I understand.  We do have the production app running...no idea
what ports the wrapper is using there.  I need this to run at the same
time...for debugging.

-Dave

On Thu, Nov 13, 2014 at 7:02 PM, Leif Mortenson <
lei...@ta...> wrote:

> David,
> Looking at the command line, the Wrapper has bound and is listening on
> port 32002, and the JVM will then use a port in the 31000-31999 range will
> be used.  There are no other ports being used by the Wrapper.
>
> As 32002 was used rather than 32000, that means that 32000 and 32001 are
> in use or were recently in use.   Could you check to make sure that another
> instance of your application is not currently running?  That would explain
> the application level port failing to bind.
>
> Cheers,
> Leif
>
>
>
> On Fri, Nov 14, 2014 at 10:34 AM, David Hoffer <dho...@gm...> wrote:
>
>> I'm using 3.5.15-pro version.  I have the production service on this VM
>> working but I need to standup a second instance so I can debug a problem.
>> I'm getting the following error with the second instance.  What is causing
>> 'ERROR: transport error 202: bind failed: Address already in use'?  I have
>> my app configured to use different ports so as to not conflict with the
>> production app...is JSW using the same port?
>>
>> How can I fix this?
>>
>> wrapper  |
>> ---------------------------------------------------------------------
>> wrapper  | The JVM is being launched with a debugger enabled and could
>> possibly
>> wrapper  | be suspended.  To avoid unwanted shutdowns, timeouts will be
>> wrapper  | disabled, removing the ability to detect and restart frozen
>> JVMs.
>> wrapper  |
>> ---------------------------------------------------------------------
>> wrapper  | Command[0] : /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java
>> wrapper  | Command[1] : -Djava.util.Arrays.useLegacyMergeSort=true
>> wrapper  | Command[2] : -Xdebug
>> wrapper  | Command[3] :
>> -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
>> wrapper  | Command[4] : -Xms64m
>> wrapper  | Command[5] : -Xmx1024m
>> wrapper  | Command[6] : -Djava.library.path=./
>> wrapper  | Command[7] : -classpath
>> wrapper  | Command[8] :
>> ../lib/activation-1.1.jar:../lib/aopalliance-1.0.jar:../lib/asm-3.3.1.jar:../lib/bcmail-jdk15-1.44.jar:../lib/bcprov-jdk15-1.44.jar:../lib/commons-codec-1.5.jar:../lib/commons-email-1.2.jar:../lib/commons-lang-2.6.jar:../lib/commons-logging-1.1.1.jar:../lib/commons-math-1.2.jar:../lib/commons-net-3.1.jar:../lib/cxf-api-2.7.10.jar:../lib/cxf-rt-bindings-soap-2.7.10.jar:../lib/cxf-rt-bindings-xml-2.7.10.jar:../lib/cxf-rt-core-2.7.10.jar:../lib/cxf-rt-databinding-aegis-2.7.10.jar:../lib/cxf-rt-databinding-jaxb-2.7.10.jar:../lib/cxf-rt-frontend-jaxws-2.7.10.jar:../lib/cxf-rt-frontend-simple-2.7.10.jar:../lib/cxf-rt-management-2.7.10.jar:../lib/cxf-rt-transports-http-2.7.10.jar:../lib/cxf-rt-transports-http-jetty-2.7.10.jar:../lib/cxf-rt-transports-local-2.7.10.jar:../lib/cxf-rt-ws-addr-2.7.10.jar:../lib/cxf-rt-ws-policy-2.7.10.jar:../lib/dhs-commons-1.6-SNAPSHOT.jar:../lib/dom4j-1.6.1.jar:../lib/fluent-hc-4.3.1.jar:../lib/fontbox-1.8.2.jar:../lib/geronimo-servlet_3.0_spec-1.0.jar:../lib/guice-3.0.jar:../lib/guice-assistedinject-3.0.jar:../lib/httpclient-4.3.1.jar:../lib/httpcore-4.3.jar:../lib/ifreelance-pn27284-webservice-1.5-SNAPSHOT.jar:../lib/itext-2.1.7.jar:../lib/javax.inject-1.jar:../lib/jaxb2-basics-runtime-0.6.1.jar:../lib/jaxb-api-2.2.jar:../lib/jaxb-impl-2.2.4.jar:../lib/jdom-1.0.jar:../lib/jempbox-1.8.2.jar:../lib/jetty-continuation-8.1.14.v20131031.jar:../lib/jetty-http-8.1.14.v20131031.jar:../lib/jetty-io-8.1.14.v20131031.jar:../lib/jetty-security-8.1.14.v20131031.jar:../lib/jetty-server-8.1.14.v20131031.jar:../lib/jetty-util-8.1.14.v20131031.jar:../lib/jetty-xml-8.1.14.v20131031.jar:../lib/joda-time-1.6.2.jar:../lib/jsr173_api-1.0.jar:../lib/jsr250-api-1.0.jar:../lib/jsr305-1.3.9.jar:../lib/log4j-1.2.16.jar:../lib/mail-1.4.1.jar:../lib/mortgage-tools-1.4-SNAPSHOT.jar:../lib/neethi-3.0.3.jar:../lib/pdfbox-1.8.2.jar:../lib/poi-3.9.jar:../lib/poi-ooxml-3.9.jar:../lib/poi-ooxml-schemas-3.9.jar:../lib/runtime-0.4.1.jar:../lib/slf4j-api-1.7.5.jar:../lib/stax2-api-3.1.1.jar:../lib/stax-api-1.0-2.jar:../lib/stax-api-1.0.1.jar:../lib/woodstox-core-asl-4.2.0.jar:../lib/wrapper-3.5.15.jar:../lib/wsdl4j-1.6.3.jar:../lib/xml-apis-1.0.b2.jar:../lib/xml-resolver-1.2.jar:../lib/xmlbeans-2.3.0.jar:../lib/xmlschema-core-2.1.0.jar
>> wrapper  | Command[9] : -Dwrapper.key=RI8htg3WrkuGSLCkOHiJ-0Dkk4OtOvbe
>> wrapper  | Command[10] : -Dwrapper.port=32002
>> wrapper  | Command[11] : -Dwrapper.jvm.port.min=31000
>> wrapper  | Command[12] : -Dwrapper.jvm.port.max=31999
>> wrapper  | Command[13] : -Dwrapper.pid=20122
>> wrapper  | Command[14] : -Dwrapper.version=3.5.15-pro
>> wrapper  | Command[15] : -Dwrapper.native_library=wrapper
>> wrapper  | Command[16] : -Dwrapper.cpu.timeout=10
>> wrapper  | Command[17] : -Dwrapper.jvmid=5
>> wrapper  | Command[18] : -Dwrapper.lang.domain=wrapper
>> wrapper  | Command[19] :
>> com.qsd.service.jsw.JavaServiceWrapperWebServiceLauncher
>> wrapper  | Launching a JVM...
>> jvm 5    | ERROR: transport error 202: bind failed: Address already in use
>> jvm 5    | ERROR: JDWP Transport dt_socket failed to initialize,
>> TRANSPORT_INIT(510)
>> jvm 5    | JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports
>> initialized [../../../src/share/back/debugInit.c:750]
>> jvm 5    | FATAL ERROR in native method: JDWP No transports initialized,
>> jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197)
>> wrapper  | JVM received a signal UNKNOWN (6).
>> wrapper  | JVM process is gone.
>> wrapper  | JVM exited while loading the application.
>> wrapper  | There were 5 failed launches in a row, each lasting less than
>> 300 seconds.  Giving up.
>> wrapper  |   There may be a configuration problem: please check the logs.
>> wrapper  | <-- Wrapper Stopped
>>
>>
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>

Re: [Wrapper-user] Getting transport error 202: bind failed: Address already in use error starting service

[Leif M. <lei...@ta...>]

David,
Looking at the command line, the Wrapper has bound and is listening on port
32002, and the JVM will then use a port in the 31000-31999 range will be
used.  There are no other ports being used by the Wrapper.

As 32002 was used rather than 32000, that means that 32000 and 32001 are in
use or were recently in use.   Could you check to make sure that another
instance of your application is not currently running?  That would explain
the application level port failing to bind.

Cheers,
Leif


On Fri, Nov 14, 2014 at 10:34 AM, David Hoffer <dho...@gm...> wrote:

> I'm using 3.5.15-pro version.  I have the production service on this VM
> working but I need to standup a second instance so I can debug a problem.
> I'm getting the following error with the second instance.  What is causing
> 'ERROR: transport error 202: bind failed: Address already in use'?  I have
> my app configured to use different ports so as to not conflict with the
> production app...is JSW using the same port?
>
> How can I fix this?
>
> wrapper  |
> ---------------------------------------------------------------------
> wrapper  | The JVM is being launched with a debugger enabled and could
> possibly
> wrapper  | be suspended.  To avoid unwanted shutdowns, timeouts will be
> wrapper  | disabled, removing the ability to detect and restart frozen
> JVMs.
> wrapper  |
> ---------------------------------------------------------------------
> wrapper  | Command[0] : /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java
> wrapper  | Command[1] : -Djava.util.Arrays.useLegacyMergeSort=true
> wrapper  | Command[2] : -Xdebug
> wrapper  | Command[3] :
> -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
> wrapper  | Command[4] : -Xms64m
> wrapper  | Command[5] : -Xmx1024m
> wrapper  | Command[6] : -Djava.library.path=./
> wrapper  | Command[7] : -classpath
> wrapper  | Command[8] :
> ../lib/activation-1.1.jar:../lib/aopalliance-1.0.jar:../lib/asm-3.3.1.jar:../lib/bcmail-jdk15-1.44.jar:../lib/bcprov-jdk15-1.44.jar:../lib/commons-codec-1.5.jar:../lib/commons-email-1.2.jar:../lib/commons-lang-2.6.jar:../lib/commons-logging-1.1.1.jar:../lib/commons-math-1.2.jar:../lib/commons-net-3.1.jar:../lib/cxf-api-2.7.10.jar:../lib/cxf-rt-bindings-soap-2.7.10.jar:../lib/cxf-rt-bindings-xml-2.7.10.jar:../lib/cxf-rt-core-2.7.10.jar:../lib/cxf-rt-databinding-aegis-2.7.10.jar:../lib/cxf-rt-databinding-jaxb-2.7.10.jar:../lib/cxf-rt-frontend-jaxws-2.7.10.jar:../lib/cxf-rt-frontend-simple-2.7.10.jar:../lib/cxf-rt-management-2.7.10.jar:../lib/cxf-rt-transports-http-2.7.10.jar:../lib/cxf-rt-transports-http-jetty-2.7.10.jar:../lib/cxf-rt-transports-local-2.7.10.jar:../lib/cxf-rt-ws-addr-2.7.10.jar:../lib/cxf-rt-ws-policy-2.7.10.jar:../lib/dhs-commons-1.6-SNAPSHOT.jar:../lib/dom4j-1.6.1.jar:../lib/fluent-hc-4.3.1.jar:../lib/fontbox-1.8.2.jar:../lib/geronimo-servlet_3.0_spec-1.0.jar:../lib/guice-3.0.jar:../lib/guice-assistedinject-3.0.jar:../lib/httpclient-4.3.1.jar:../lib/httpcore-4.3.jar:../lib/ifreelance-pn27284-webservice-1.5-SNAPSHOT.jar:../lib/itext-2.1.7.jar:../lib/javax.inject-1.jar:../lib/jaxb2-basics-runtime-0.6.1.jar:../lib/jaxb-api-2.2.jar:../lib/jaxb-impl-2.2.4.jar:../lib/jdom-1.0.jar:../lib/jempbox-1.8.2.jar:../lib/jetty-continuation-8.1.14.v20131031.jar:../lib/jetty-http-8.1.14.v20131031.jar:../lib/jetty-io-8.1.14.v20131031.jar:../lib/jetty-security-8.1.14.v20131031.jar:../lib/jetty-server-8.1.14.v20131031.jar:../lib/jetty-util-8.1.14.v20131031.jar:../lib/jetty-xml-8.1.14.v20131031.jar:../lib/joda-time-1.6.2.jar:../lib/jsr173_api-1.0.jar:../lib/jsr250-api-1.0.jar:../lib/jsr305-1.3.9.jar:../lib/log4j-1.2.16.jar:../lib/mail-1.4.1.jar:../lib/mortgage-tools-1.4-SNAPSHOT.jar:../lib/neethi-3.0.3.jar:../lib/pdfbox-1.8.2.jar:../lib/poi-3.9.jar:../lib/poi-ooxml-3.9.jar:../lib/poi-ooxml-schemas-3.9.jar:../lib/runtime-0.4.1.jar:../lib/slf4j-api-1.7.5.jar:../lib/stax2-api-3.1.1.jar:../lib/stax-api-1.0-2.jar:../lib/stax-api-1.0.1.jar:../lib/woodstox-core-asl-4.2.0.jar:../lib/wrapper-3.5.15.jar:../lib/wsdl4j-1.6.3.jar:../lib/xml-apis-1.0.b2.jar:../lib/xml-resolver-1.2.jar:../lib/xmlbeans-2.3.0.jar:../lib/xmlschema-core-2.1.0.jar
> wrapper  | Command[9] : -Dwrapper.key=RI8htg3WrkuGSLCkOHiJ-0Dkk4OtOvbe
> wrapper  | Command[10] : -Dwrapper.port=32002
> wrapper  | Command[11] : -Dwrapper.jvm.port.min=31000
> wrapper  | Command[12] : -Dwrapper.jvm.port.max=31999
> wrapper  | Command[13] : -Dwrapper.pid=20122
> wrapper  | Command[14] : -Dwrapper.version=3.5.15-pro
> wrapper  | Command[15] : -Dwrapper.native_library=wrapper
> wrapper  | Command[16] : -Dwrapper.cpu.timeout=10
> wrapper  | Command[17] : -Dwrapper.jvmid=5
> wrapper  | Command[18] : -Dwrapper.lang.domain=wrapper
> wrapper  | Command[19] :
> com.qsd.service.jsw.JavaServiceWrapperWebServiceLauncher
> wrapper  | Launching a JVM...
> jvm 5    | ERROR: transport error 202: bind failed: Address already in use
> jvm 5    | ERROR: JDWP Transport dt_socket failed to initialize,
> TRANSPORT_INIT(510)
> jvm 5    | JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports
> initialized [../../../src/share/back/debugInit.c:750]
> jvm 5    | FATAL ERROR in native method: JDWP No transports initialized,
> jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197)
> wrapper  | JVM received a signal UNKNOWN (6).
> wrapper  | JVM process is gone.
> wrapper  | JVM exited while loading the application.
> wrapper  | There were 5 failed launches in a row, each lasting less than
> 300 seconds.  Giving up.
> wrapper  |   There may be a configuration problem: please check the logs.
> wrapper  | <-- Wrapper Stopped
>
>

[Wrapper-user] Getting transport error 202: bind failed: Address already in use error starting service

[David H. <dho...@gm...>]

I'm using 3.5.15-pro version.  I have the production service on this VM
working but I need to standup a second instance so I can debug a problem.
I'm getting the following error with the second instance.  What is causing
'ERROR: transport error 202: bind failed: Address already in use'?  I have
my app configured to use different ports so as to not conflict with the
production app...is JSW using the same port?

How can I fix this?

wrapper  |
---------------------------------------------------------------------
wrapper  | The JVM is being launched with a debugger enabled and could
possibly
wrapper  | be suspended.  To avoid unwanted shutdowns, timeouts will be
wrapper  | disabled, removing the ability to detect and restart frozen JVMs.
wrapper  |
---------------------------------------------------------------------
wrapper  | Command[0] : /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java
wrapper  | Command[1] : -Djava.util.Arrays.useLegacyMergeSort=true
wrapper  | Command[2] : -Xdebug
wrapper  | Command[3] :
-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
wrapper  | Command[4] : -Xms64m
wrapper  | Command[5] : -Xmx1024m
wrapper  | Command[6] : -Djava.library.path=./
wrapper  | Command[7] : -classpath
wrapper  | Command[8] :
../lib/activation-1.1.jar:../lib/aopalliance-1.0.jar:../lib/asm-3.3.1.jar:../lib/bcmail-jdk15-1.44.jar:../lib/bcprov-jdk15-1.44.jar:../lib/commons-codec-1.5.jar:../lib/commons-email-1.2.jar:../lib/commons-lang-2.6.jar:../lib/commons-logging-1.1.1.jar:../lib/commons-math-1.2.jar:../lib/commons-net-3.1.jar:../lib/cxf-api-2.7.10.jar:../lib/cxf-rt-bindings-soap-2.7.10.jar:../lib/cxf-rt-bindings-xml-2.7.10.jar:../lib/cxf-rt-core-2.7.10.jar:../lib/cxf-rt-databinding-aegis-2.7.10.jar:../lib/cxf-rt-databinding-jaxb-2.7.10.jar:../lib/cxf-rt-frontend-jaxws-2.7.10.jar:../lib/cxf-rt-frontend-simple-2.7.10.jar:../lib/cxf-rt-management-2.7.10.jar:../lib/cxf-rt-transports-http-2.7.10.jar:../lib/cxf-rt-transports-http-jetty-2.7.10.jar:../lib/cxf-rt-transports-local-2.7.10.jar:../lib/cxf-rt-ws-addr-2.7.10.jar:../lib/cxf-rt-ws-policy-2.7.10.jar:../lib/dhs-commons-1.6-SNAPSHOT.jar:../lib/dom4j-1.6.1.jar:../lib/fluent-hc-4.3.1.jar:../lib/fontbox-1.8.2.jar:../lib/geronimo-servlet_3.0_spec-1.0.jar:../lib/guice-3.0.jar:../lib/guice-assistedinject-3.0.jar:../lib/httpclient-4.3.1.jar:../lib/httpcore-4.3.jar:../lib/ifreelance-pn27284-webservice-1.5-SNAPSHOT.jar:../lib/itext-2.1.7.jar:../lib/javax.inject-1.jar:../lib/jaxb2-basics-runtime-0.6.1.jar:../lib/jaxb-api-2.2.jar:../lib/jaxb-impl-2.2.4.jar:../lib/jdom-1.0.jar:../lib/jempbox-1.8.2.jar:../lib/jetty-continuation-8.1.14.v20131031.jar:../lib/jetty-http-8.1.14.v20131031.jar:../lib/jetty-io-8.1.14.v20131031.jar:../lib/jetty-security-8.1.14.v20131031.jar:../lib/jetty-server-8.1.14.v20131031.jar:../lib/jetty-util-8.1.14.v20131031.jar:../lib/jetty-xml-8.1.14.v20131031.jar:../lib/joda-time-1.6.2.jar:../lib/jsr173_api-1.0.jar:../lib/jsr250-api-1.0.jar:../lib/jsr305-1.3.9.jar:../lib/log4j-1.2.16.jar:../lib/mail-1.4.1.jar:../lib/mortgage-tools-1.4-SNAPSHOT.jar:../lib/neethi-3.0.3.jar:../lib/pdfbox-1.8.2.jar:../lib/poi-3.9.jar:../lib/poi-ooxml-3.9.jar:../lib/poi-ooxml-schemas-3.9.jar:../lib/runtime-0.4.1.jar:../lib/slf4j-api-1.7.5.jar:../lib/stax2-api-3.1.1.jar:../lib/stax-api-1.0-2.jar:../lib/stax-api-1.0.1.jar:../lib/woodstox-core-asl-4.2.0.jar:../lib/wrapper-3.5.15.jar:../lib/wsdl4j-1.6.3.jar:../lib/xml-apis-1.0.b2.jar:../lib/xml-resolver-1.2.jar:../lib/xmlbeans-2.3.0.jar:../lib/xmlschema-core-2.1.0.jar
wrapper  | Command[9] : -Dwrapper.key=RI8htg3WrkuGSLCkOHiJ-0Dkk4OtOvbe
wrapper  | Command[10] : -Dwrapper.port=32002
wrapper  | Command[11] : -Dwrapper.jvm.port.min=31000
wrapper  | Command[12] : -Dwrapper.jvm.port.max=31999
wrapper  | Command[13] : -Dwrapper.pid=20122
wrapper  | Command[14] : -Dwrapper.version=3.5.15-pro
wrapper  | Command[15] : -Dwrapper.native_library=wrapper
wrapper  | Command[16] : -Dwrapper.cpu.timeout=10
wrapper  | Command[17] : -Dwrapper.jvmid=5
wrapper  | Command[18] : -Dwrapper.lang.domain=wrapper
wrapper  | Command[19] :
com.qsd.service.jsw.JavaServiceWrapperWebServiceLauncher
wrapper  | Launching a JVM...
jvm 5    | ERROR: transport error 202: bind failed: Address already in use
jvm 5    | ERROR: JDWP Transport dt_socket failed to initialize,
TRANSPORT_INIT(510)
jvm 5    | JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports
initialized [../../../src/share/back/debugInit.c:750]
jvm 5    | FATAL ERROR in native method: JDWP No transports initialized,
jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197)
wrapper  | JVM received a signal UNKNOWN (6).
wrapper  | JVM process is gone.
wrapper  | JVM exited while loading the application.
wrapper  | There were 5 failed launches in a row, each lasting less than
300 seconds.  Giving up.
wrapper  |   There may be a configuration problem: please check the logs.
wrapper  | <-- Wrapper Stopped

[Wrapper-user] RUN_LEVEL

[Lars S. <la...@if...>]

Hi

I am using the wrapper in version 3.5.25 on Linux 32-bit (RHEL 6.3). I 
try to get my application to start after another application is started 
which is started at run level 50, so I set the RUN_LEVEL parameter to 
60. If I now look in the /etc/rcX.d directories I can see that my 
application is started as S24 and stopped as K80. How can I get my 
application to be started after run level 50?

Lars

Re: [Wrapper-user] Problem with RUN_AS_USER and nologin-shell

[Dannes W. <da...@ex...>]

hi,

On Tue, Nov 11, 2014 at 9:21 AM, O.Pax <o....@we...> wrote:

> I agree the use of launchctl is the preferred way to use the wrapper on
> Mac OS X systems.


a preview of the upcoming changes can be found on
http://sourceforge.net/p/wrapper/code/1896/tree//trunk/wrapper/src/bin/sh.script.in?diff=1876
; as you see quite some suggestions from the community are put in.....
great work!

regards

Dannes


-- 
eXist-db Native XML Database - http://exist-db.org
Join us on linked-in: http://www.linkedin.com/groups?gid=35624

Re: [Wrapper-user] Problem with RUN_AS_USER and nologin-shell

[O.Pax <o....@we...>]

Hello,

I agree the use of launchctl is the preferred way to use the wrapper on
Mac OS X systems. This leaves the question of how the problem with
RUN_AS_USER users with restricted shells should be handled on other
platforms. As I wrote, on Linux systems, "su -s /bin/sh ..." can be
used. With OS X out of the mix, we do not need to care about
compatibility there, but what about other supported UNIX variants? I
unfortunately do not have the means to test it myself.

I still do think that it would be preferrable for the wrapper script to
fix the shell that is used to execute RUN_AS_USER commands. This not
only alleviates problems with restricted shells as in my original mail,
it also renders behavior of the wrapper script more deterministic.

Is there any chance you might consider this for a future version?

Thanks for your great work,
Opax

On 21.10.14 05:18, Alexandre Klein wrote:
> Hi,
> 
> Thank you for your message.
> 
> On Mac OS X, we should not use "sudo" or "su" to interact with a daemon.
> We should use "launchctl".
> In the current version of the script file, we are correctly using
> "launchctl" to install, start and remove the daemon.
> Unfortunately, we are using "su - $RUN_AS_USER ..." to stop the daemon,
> which is not correct.
> 
> In the next version of the Wrapper (3.5.26), we will fix this and use
> "launchctl stop". By doing so, this will avoid the issue described by Opax.
> 
> If you have any comments or suggestions, please don't hesitate to
> contact us via our mailing list or directly via our support email
> su...@ta... <mailto:su...@ta...>
> 
> Regards,
> Alexandre Klein
> 
> On Mon, Oct 20, 2014 at 5:38 AM, Dannes Wessels <da...@ex...
> <mailto:da...@ex...>> wrote:
> 
>     Hi,
> 
>>     On 11 Oct 2014, at 0:27 , o....@we... <mailto:o....@we...> wrote:
>>
>>     I noticed that the checkUser function uses "su - $RUN_AS_USER -c
>>     ..." to switch to the target user. This fails if that user does
>>     not have a valid login shell, e.g. /bin/false or
>>     /usr/sbin/nologin. On the other hand, such "shells" are usually
>>     the default for daemon accounts in many UNIX systems. For
>>     GNU/Linux, this is easily fixed by using "su -s /bin/sh",
>>     overriding the user's default shell. Unfortunately, OS X's su does
>>     not have this option, so this is not a portable solution.
>>
>>     The only portable way I found to circumvent the problem is to use
>>     "sudo -u $RUN_AS_USER ...", but I do not know whether this may
>>     cause problems on some systems/configurations.
>>
>>     I think it would be nice to be able to use such restricted system
>>     accounts for Java services, so what do you think would be the best
>>     solution? Using the "-s" switch on systems that support it and
>>     ignore the problem on others? Or fall back to sudo on systems
>>     where the switch is missing?
> 
>     I can not think of a good work around either, I hope some one can…….
> 
>     regards
> 
>     Dannes
> 

Re: [Wrapper-user] JVM restarts "Wrapper Process has not received any CPU time for 69 seconds"

[Tu T. N. <ttn...@ra...>]

Hello All,

An update on my issue, I had two sites that has this CPU Time issue.  One I sent the wrapper debug log in and it did indeed end up being an application issue, which was fixed.  There were millions of files waiting to be picked up and it caused the OS/app to hang.

At the other site, we continue to have this issue even after upgrading from 3.2.3 to 3.5.25 and trying the PIPE logging option.
I am in the middle of working with them to get logs with wrapper debug on.

Finally is there a way to get priority support, pay support?


Thank you,

Tu Nguyen | FTPC Support Engineer | Office: 408.271.3464 | Mobile: 408.464.3252 | Rockwell Automation | Mission Viejo, CA (GMT -8)



From: Alexandre Klein [mailto:ale...@ta...]
Sent: Wednesday, October 01, 2014 10:54 PM
To: wra...@li...
Cc: Elaine M. Julius
Subject: Re: [Wrapper-user] JVM restarts "Wrapper Process has not received any CPU time for 69 seconds"

Tu,

Since version 3.2.3, the Wrapper has evolved  a lot.
Please take a look at the release notes which contains all bug fixes and new features for the Java Service Wrapper.
http://wrapper.tanukisoftware.com/doc/english/release-notes.html

As you can see, the list is long.  Here are  some changes that might resolve your issue:
- we have fixed memory leaks
- we have improved the way to write large amounts of output (otherwise the Wrapper thought the JVM was frozen)
- we have fixed heap corruption
- we have improved the way the Java side of the Wrapper behaves when the Wrapper fails to ping the JVM for an extended period of time. (This was causing problems on systems which were heavily IO bound because the Wrapper could block for a while while trying to write to the log file and the JVM was exiting)

As Leif mentioned, we haven't received any log file.
Can you send it to: su...@ta...<mailto:su...@ta...>
We would be happy to have a look. If possible, please send us the configuration file (wrapper.conf) as well.

Regards,
Alexandre Klein


Alexandre Klein
Tanuki Software, Ltd.
6-16-7-1001 Nishi-Kasai, Edogawa-ku
Tokyo 134-0088 Japan
Tel: +81-3-3878-3211
Fax: +81-3-3878-0313
http://www.tanukisoftware.com<http://www.tanukisoftware.com/>

On Thu, Oct 2, 2014 at 9:21 AM, Tu T. Nguyen <ttn...@ra...<mailto:ttn...@ra...>> wrote:
What we are looking for is some justification that we can give our customer that upgrading even might resolve the issue they are seeing.

Based on what you see in the logs, is there anything that would point to an upgrade being likely to resolve the problem?


From: Leif Mortenson [mailto:lei...@ta...<mailto:lei...@ta...>]
Sent: Wednesday, October 01, 2014 6:33 AM
To: Wrapper User List
Cc: Elaine M. Julius
Subject: Re: [Wrapper-user] JVM restarts "Wrapper Process has not received any CPU time for 69 seconds"

Tu,
Is the machine you are running on a physical or a virtual machine?  We have seen cases where a loaded host causes the VM to freeze up when the guest itself does not show any load.
3.2.3 is also a VERY old version of the Wrapper.  There have been a lot of improvements over the years in this area.  Please try 3.5.25 and see how that works for you.
You mentioned log files, but there was nothing attached to your mail.

Cheers,
Leif

On Wed, Oct 1, 2014 at 10:23 PM, Tu T. Nguyen <ttn...@ra...<mailto:ttn...@ra...>> wrote:

Hello,

I have an issue where the wrapper restarts the JVM multiple times a day.  We are using version 3.2.3 on Windows 2003 SP2.  The duration always varies.  We checked the CPU usage and its always very little when this happens .  We have about 6 services that use the wrapper on this machine and they restart at different times.  The suggestion is that if there was a CPU bottle neck they would all have this error at the same time.  We also have other sites which use the same configuration but do not have this problem.

We have collected logs with wrapper debugging enabled.  Please have a look, any help would be much appreciated!

Thank you,

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Wrapper-user mailing list
Wra...@li...<mailto:Wra...@li...>
https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] Problem with RUN_AS_USER and nologin-shell

[Alexandre K. <ale...@ta...>]

Hi,

Thank you for your message.

On Mac OS X, we should not use "sudo" or "su" to interact with a daemon. We
should use "launchctl".
In the current version of the script file, we are correctly using
"launchctl" to install, start and remove the daemon.
Unfortunately, we are using "su - $RUN_AS_USER ..." to stop the daemon,
which is not correct.

In the next version of the Wrapper (3.5.26), we will fix this and use
"launchctl stop". By doing so, this will avoid the issue described by Opax.

If you have any comments or suggestions, please don't hesitate to contact
us via our mailing list or directly via our support email
su...@ta...

Regards,
Alexandre Klein


Alexandre Klein
Tanuki Software, Ltd.
6-16-7-1001 Nishi-Kasai, Edogawa-ku
Tokyo 134-0088 Japan
Tel: +81-3-3878-3211
Fax: +81-3-3878-0313
http://www.tanukisoftware.com

On Mon, Oct 20, 2014 at 5:38 AM, Dannes Wessels <da...@ex...> wrote:

> Hi,
>
> On 11 Oct 2014, at 0:27 , o....@we... wrote:
>
> I noticed that the checkUser function uses "su - $RUN_AS_USER -c ..." to
> switch to the target user. This fails if that user does not have a valid
> login shell, e.g. /bin/false or /usr/sbin/nologin. On the other hand, such
> "shells" are usually the default for daemon accounts in many UNIX systems.
> For GNU/Linux, this is easily fixed by using "su -s /bin/sh", overriding
> the user's default shell. Unfortunately, OS X's su does not have this
> option, so this is not a portable solution.
>
> The only portable way I found to circumvent the problem is to use "sudo -u
> $RUN_AS_USER ...", but I do not know whether this may cause problems on
> some systems/configurations.
>
> I think it would be nice to be able to use such restricted system accounts
> for Java services, so what do you think would be the best solution? Using
> the "-s" switch on systems that support it and ignore the problem on
> others? Or fall back to sudo on systems where the switch is missing?
>
>
> I can not think of a good work around either, I hope some one can…….
>
> regards
>
> Dannes
>
>
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>

Re: [Wrapper-user] Wrapper issue MacOSX 10.10 / Yosemite

[Mike P. <MP...@np...>]

Thanks for sharing this. I implemented the suggested solution from ElasticSearch and it is working for me. This is the second time I’ve had issues with JSW not recognizing OS X version numbers. I think last time was an issue with the regular expression used with the sw_vers command. Note that if you use this solution the vercomp function (line 270) needs to be included and the logic changes slightly (line 306) so make sure you edit the right bits.

-mike



NPR | Mike Pilone | Software Architect, Distribution | 1111 North Capital St., NE | Washington, DC 20002





<https://twitter.com/PRSS_NOC>
<https://twitter.com/PRSS_NOC>

On Oct 19, 2014, at 4:36 PM, Dannes Wessels <di...@ex...<mailto:di...@ex...>> wrote:

answering myself….

On 19 Oct 2014, at 22:22 , Dannes Wessels <di...@ex...<mailto:di...@ex...>> wrote:

I found out today that our application does not start anymore on the latest MacOSX 10.10 Yosemite;
After some debugging (with the console option) I found:

+ DIST_ARCH=universal
+ [[ 10.10 < 10.5.0 ]]
+ DIST_BITS=32

the newest OS is detected as an older version :-) Do you know an way to work around this elegantly?

http://www.snip2code.com/Snippet/200005/OSX-Yosemite-10-10-elasticsearch-service/ might be a nice route (line 270)

regards

Dannes


------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] Problem with RUN_AS_USER and nologin-shell

[Dannes W. <da...@ex...>]

Hi,

> On 11 Oct 2014, at 0:27 , o....@we... wrote:
> 
> I noticed that the checkUser function uses "su - $RUN_AS_USER -c ..." to switch to the target user. This fails if that user does not have a valid login shell, e.g. /bin/false or /usr/sbin/nologin. On the other hand, such "shells" are usually the default for daemon accounts in many UNIX systems. For GNU/Linux, this is easily fixed by using "su -s /bin/sh", overriding the user's default shell. Unfortunately, OS X's su does not have this option, so this is not a portable solution.
> 
> The only portable way I found to circumvent the problem is to use "sudo -u $RUN_AS_USER ...", but I do not know whether this may cause problems on some systems/configurations.
> 
> I think it would be nice to be able to use such restricted system accounts for Java services, so what do you think would be the best solution? Using the "-s" switch on systems that support it and ignore the problem on others? Or fall back to sudo on systems where the switch is missing?

I can not think of a good work around either, I hope some one can…….

regards

Dannes

Re: [Wrapper-user] Wrapper issue MacOSX 10.10 / Yosemite

[Dannes W. <di...@ex...>]

answering myself….

> On 19 Oct 2014, at 22:22 , Dannes Wessels <di...@ex...> wrote:
> 
> I found out today that our application does not start anymore on the latest MacOSX 10.10 Yosemite; 
> After some debugging (with the console option) I found:
> 
>> + DIST_ARCH=universal
>> + [[ 10.10 < 10.5.0 ]]
>> + DIST_BITS=32
> 
> the newest OS is detected as an older version :-) Do you know an way to work around this elegantly?

http://www.snip2code.com/Snippet/200005/OSX-Yosemite-10-10-elasticsearch-service/ <http://www.snip2code.com/Snippet/200005/OSX-Yosemite-10-10-elasticsearch-service/> might be a nice route (line 270)

regards

Dannes

[Wrapper-user] Wrapper issue MacOSX 10.10 / Yosemite

[Dannes W. <di...@ex...>]

Hi,

I found out today that our application does not start anymore on the latest MacOSX 10.10 Yosemite; 
After some debugging (with the console option) I found:

> + DIST_ARCH=universal
> + [[ 10.10 < 10.5.0 ]]
> + DIST_BITS=32

the newest OS is detected as an older version :-) Do you know an way to work around this elegantly?

regards

Dannes


eXist-db Native XML Database
http://www.exist-db.org

[Wrapper-user] Problem with RUN_AS_USER and nologin-shell

[<o....@we...>]

Hello list,

I noticed that the checkUser function uses "su - $RUN_AS_USER -c ..." to switch to the target user. This fails if that user does not have a valid login shell, e.g. /bin/false or /usr/sbin/nologin. On the other hand, such "shells" are usually the default for daemon accounts in many UNIX systems. For GNU/Linux, this is easily fixed by using "su -s /bin/sh", overriding the user's default shell. Unfortunately, OS X's su does not have this option, so this is not a portable solution.

The only portable way I found to circumvent the problem is to use "sudo -u $RUN_AS_USER ...", but I do not know whether this may cause problems on some systems/configurations.

I think it would be nice to be able to use such restricted system accounts for Java services, so what do you think would be the best solution? Using the "-s" switch on systems that support it and ignore the problem on others? Or fall back to sudo on systems where the switch is missing?

Thanks for your great work,

opax

Re: [Wrapper-user] JVM restarts "Wrapper Process has not received any CPU time for 69 seconds"

[Tu T. N. <ttn...@ra...>]

I have one site that gets this issue multiple times a day.  Each time it happens the JVM # gets bumped up in the wrapper log, and theirs goes up into the triple digits.  A second site has this issue about 2-3 times a week.  Running without the wrapper, just from the command line, they have gone 2 weeks without a problem now.

From: Mike Pilone [mailto:MP...@np...]
Sent: Friday, October 03, 2014 5:15 AM
To: wra...@li...
Subject: Re: [Wrapper-user] JVM restarts "Wrapper Process has not received any CPU time for 69 seconds"

I would say we have under 20 threads in the application and the vast majority should be idle. When we do have a service get killed this way it is almost always between 12AM and 3AM which is when we run a lot of nightly background jobs and batch processing. However the component that gets killed (usually 1 out of 12) varies and the load of that component also varies so we haven't been able to tie the issue to load on any one specific component at any particular time. We can sometimes go weeks without the issue and then have different processes killed 3 nights in a row. That's what makes debugging this so hard.

At one point I was thinking it might be a paging issue where some process was swapped out and couldn't be swapped back in fast enough to answer the wrapper's ping but I don't have any hard evidence other than using swap on a VM guest is usually bad news. Hopefully with some more metrics I'll be able to find some correlations to other activities on the guest or host boxes.

-mike


NPR | Mike Pilone | Software Architect, Distribution | 1111 North Capital St., NE | Washington, DC 20002





<https://twitter.com/PRSS_NOC>
<https://twitter.com/PRSS_NOC>

On Oct 2, 2014, at 6:10 PM, Tu T. Nguyen <ttn...@ra...<mailto:ttn...@ra...>> wrote:


Mike,

Does your Java process have many threads and is very busy?  Our industrial application creates many threads to go out and reads tags from Programmable Logic Controllers (PLC).  I'm just collecting data points for how to possibly to and reproduce this issue in house.  For us it only seems to happen on Windows 2003.  I'm surprised to see that its happening to you on linux.  The other data point I am collecting is vmware hardware versions for the guest machines.


Regards,

Tu Nguyen | FTPC Support Engineer | Office: 408.271.3464 | Mobile: 408.464.3252 | Rockwell Automation | Mission Viejo, CA (GMT -8)



From: Mike Pilone [mailto:MP...@np...]
Sent: Thursday, October 02, 2014 9:08 AM
To: wra...@li...<mailto:wra...@li...>
Subject: Re: [Wrapper-user] JVM restarts "Wrapper Process has not received any CPU time for 69 seconds"

It doesn't look like a memory issue with the wrapper because we'll see it at different times on different nodes with different services even though we tend to start all of our services at the same time on a given node. The logs also indicate that the wrapper detected a problem and is attempting to restart the service (not just getting killed). I attached the logs from our most recent occurrence where we saw the same service get killed on two different guest VMs which are on two different physical hosts. The only thing the two physical nodes have in common is storage and network IO.

-mike



--



<image001.png>
 | Mike Pilone | Software Architect, Distribution | 1111 North Capital St., NE | Washington, DC 20002 | 202-513-2679 office |  703-969-7493 cell | mp...@np...<mailto:mp...@np...>


<http://www.prss.org/>
<image002.jpg>
<image003.png>
  <http://www.nprss.org/>
<image004.png>
  <https://www.facebook.com/pages/Public-Radio-Satellite-System-PRSS/225044460846999>
<image005.png>



<https://twitter.com/PRSS_NOC>
<https://twitter.com/PRSS_NOC>

On Oct 2, 2014, at 11:06 AM, Tim Lammens <tim...@gm...<mailto:tim...@gm...>> wrote:



Mike,

Are you sure the process is being killed by the wrapper and not by the linux kernel?
A memory leak in glibc was causing our wrapper to consume a lot of memory (bug in appending to a file) but the linux oom killer decided to kill to process which was protected by the wrapper.
Memory shortage than prevented the process being restarted by the wrapper.

Regards,
Tim

On Thu, Oct 2, 2014 at 4:22 PM, Mike Pilone <MP...@np...<mailto:MP...@np...>> wrote:
I can tell you that I'm using 3.5.24 and I see the problem on a Linux guest VM as I described earlier. So while I always recommend updating to the latest version, I wouldn't have much confidence that it is going to fix this specific issue. I'm wondering if the issue has something to do with and interaction between how the wrapper pings the JVM and VMWare guests. I think the ping is done by sending a packet over a socket from the wrapper process to the JVM and getting a simple packet reply. Maybe when the VM guest or host are under load (or something else) the ping packet gets buffered or something. So it might not be a CPU issue but some kind of IO or networking/socket issue.

I'd like to have more time to investigate but when the issue only happens a couple of times a week at 2AM it is hard to get any good data.

-mike

--

<unknown.png> | Mike Pilone | Software Architect, Distribution | 1111 North Capital St., NE | Washington, DC 20002


<https://twitter.com/PRSS_NOC>
<https://twitter.com/PRSS_NOC>

On Oct 1, 2014, at 8:21 PM, Tu T. Nguyen <ttn...@ra...<mailto:ttn...@ra...>> wrote:

What we are looking for is some justification that we can give our customer that upgrading even might resolve the issue they are seeing.

Based on what you see in the logs, is there anything that would point to an upgrade being likely to resolve the problem?


From: Leif Mortenson [mailto:lei...@ta...]
Sent: Wednesday, October 01, 2014 6:33 AM
To: Wrapper User List
Cc: Elaine M. Julius
Subject: Re: [Wrapper-user] JVM restarts "Wrapper Process has not received any CPU time for 69 seconds"

Tu,

Is the machine you are running on a physical or a virtual machine?  We have seen cases where a loaded host causes the VM to freeze up when the guest itself does not show any load.

3.2.3 is also a VERY old version of the Wrapper.  There have been a lot of improvements over the years in this area.  Please try 3.5.25 and see how that works for you.
You mentioned log files, but there was nothing attached to your mail.

Cheers,
Leif

On Wed, Oct 1, 2014 at 10:23 PM, Tu T. Nguyen <ttn...@ra...<mailto:ttn...@ra...>> wrote:

Hello,

I have an issue where the wrapper restarts the JVM multiple times a day.  We are using version 3.2.3 on Windows 2003 SP2.  The duration always varies.  We checked the CPU usage and its always very little when this happens .  We have about 6 services that use the wrapper on this machine and they restart at different times.  The suggestion is that if there was a CPU bottle neck they would all have this error at the same time.  We also have other sites which use the same configuration but do not have this problem.

We have collected logs with wrapper debugging enabled.  Please have a look, any help would be much appreciated!

Thank you,
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________
Wrapper-user mailing list
Wra...@li...<mailto:Wra...@li...>
https://lists.sourceforge.net/lists/listinfo/wrapper-user


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Wrapper-user mailing list
Wra...@li...<mailto:Wra...@li...>
https://lists.sourceforge.net/lists/listinfo/wrapper-user

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________
Wrapper-user mailing list
Wra...@li...<mailto:Wra...@li...>
https://lists.sourceforge.net/lists/listinfo/wrapper-user

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________
Wrapper-user mailing list
Wra...@li...<mailto:Wra...@li...>
https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] JVM restarts "Wrapper Process has not received any CPU time for 69 seconds"

[Mike P. <MP...@np...>]

I would say we have under 20 threads in the application and the vast majority should be idle. When we do have a service get killed this way it is almost always between 12AM and 3AM which is when we run a lot of nightly background jobs and batch processing. However the component that gets killed (usually 1 out of 12) varies and the load of that component also varies so we haven’t been able to tie the issue to load on any one specific component at any particular time. We can sometimes go weeks without the issue and then have different processes killed 3 nights in a row. That’s what makes debugging this so hard.

At one point I was thinking it might be a paging issue where some process was swapped out and couldn’t be swapped back in fast enough to answer the wrapper’s ping but I don’t have any hard evidence other than using swap on a VM guest is usually bad news. Hopefully with some more metrics I’ll be able to find some correlations to other activities on the guest or host boxes.

-mike



NPR | Mike Pilone | Software Architect, Distribution | 1111 North Capital St., NE | Washington, DC 20002





<https://twitter.com/PRSS_NOC>
<https://twitter.com/PRSS_NOC>

On Oct 2, 2014, at 6:10 PM, Tu T. Nguyen <ttn...@ra...<mailto:ttn...@ra...>> wrote:

Mike,

Does your Java process have many threads and is very busy?  Our industrial application creates many threads to go out and reads tags from Programmable Logic Controllers (PLC).  I’m just collecting data points for how to possibly to and reproduce this issue in house.  For us it only seems to happen on Windows 2003.  I’m surprised to see that its happening to you on linux.  The other data point I am collecting is vmware hardware versions for the guest machines.


Regards,

Tu Nguyen | FTPC Support Engineer | Office: 408.271.3464 | Mobile: 408.464.3252 | Rockwell Automation | Mission Viejo, CA (GMT -8)



From: Mike Pilone [mailto:MP...@np...]
Sent: Thursday, October 02, 2014 9:08 AM
To: wra...@li...<mailto:wra...@li...>
Subject: Re: [Wrapper-user] JVM restarts "Wrapper Process has not received any CPU time for 69 seconds"

It doesn’t look like a memory issue with the wrapper because we’ll see it at different times on different nodes with different services even though we tend to start all of our services at the same time on a given node. The logs also indicate that the wrapper detected a problem and is attempting to restart the service (not just getting killed). I attached the logs from our most recent occurrence where we saw the same service get killed on two different guest VMs which are on two different physical hosts. The only thing the two physical nodes have in common is storage and network IO.

-mike



--


<image001.png>
 | Mike Pilone | Software Architect, Distribution | 1111 North Capital St., NE | Washington, DC 20002 | 202-513-2679 office |  703-969-7493 cell | mp...@np...<mailto:mp...@np...>


<http://www.prss.org/>
<image002.jpg>
<image003.png>
  <http://www.nprss.org/>
<image004.png>
  <https://www.facebook.com/pages/Public-Radio-Satellite-System-PRSS/225044460846999>
<image005.png>



<https://twitter.com/PRSS_NOC>
<https://twitter.com/PRSS_NOC>

On Oct 2, 2014, at 11:06 AM, Tim Lammens <tim...@gm...<mailto:tim...@gm...>> wrote:


Mike,

Are you sure the process is being killed by the wrapper and not by the linux kernel?
A memory leak in glibc was causing our wrapper to consume a lot of memory (bug in appending to a file) but the linux oom killer decided to kill to process which was protected by the wrapper.
Memory shortage than prevented the process being restarted by the wrapper.

Regards,
Tim

On Thu, Oct 2, 2014 at 4:22 PM, Mike Pilone <MP...@np...<mailto:MP...@np...>> wrote:
I can tell you that I’m using 3.5.24 and I see the problem on a Linux guest VM as I described earlier. So while I always recommend updating to the latest version, I wouldn’t have much confidence that it is going to fix this specific issue. I’m wondering if the issue has something to do with and interaction between how the wrapper pings the JVM and VMWare guests. I think the ping is done by sending a packet over a socket from the wrapper process to the JVM and getting a simple packet reply. Maybe when the VM guest or host are under load (or something else) the ping packet gets buffered or something. So it might not be a CPU issue but some kind of IO or networking/socket issue.

I’d like to have more time to investigate but when the issue only happens a couple of times a week at 2AM it is hard to get any good data.

-mike

--

<unknown.png> | Mike Pilone | Software Architect, Distribution | 1111 North Capital St., NE | Washington, DC 20002


<https://twitter.com/PRSS_NOC>
<https://twitter.com/PRSS_NOC>

On Oct 1, 2014, at 8:21 PM, Tu T. Nguyen <ttn...@ra...<mailto:ttn...@ra...>> wrote:

What we are looking for is some justification that we can give our customer that upgrading even might resolve the issue they are seeing.

Based on what you see in the logs, is there anything that would point to an upgrade being likely to resolve the problem?


From: Leif Mortenson [mailto:lei...@ta...]
Sent: Wednesday, October 01, 2014 6:33 AM
To: Wrapper User List
Cc: Elaine M. Julius
Subject: Re: [Wrapper-user] JVM restarts "Wrapper Process has not received any CPU time for 69 seconds"

Tu,

Is the machine you are running on a physical or a virtual machine?  We have seen cases where a loaded host causes the VM to freeze up when the guest itself does not show any load.

3.2.3 is also a VERY old version of the Wrapper.  There have been a lot of improvements over the years in this area.  Please try 3.5.25 and see how that works for you.

You mentioned log files, but there was nothing attached to your mail.

Cheers,
Leif

On Wed, Oct 1, 2014 at 10:23 PM, Tu T. Nguyen <ttn...@ra...<mailto:ttn...@ra...>> wrote:

Hello,

I have an issue where the wrapper restarts the JVM multiple times a day.  We are using version 3.2.3 on Windows 2003 SP2.  The duration always varies.  We checked the CPU usage and its always very little when this happens .  We have about 6 services that use the wrapper on this machine and they restart at different times.  The suggestion is that if there was a CPU bottle neck they would all have this error at the same time.  We also have other sites which use the same configuration but do not have this problem.

We have collected logs with wrapper debugging enabled.  Please have a look, any help would be much appreciated!

Thank you,
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________
Wrapper-user mailing list
Wra...@li...<mailto:Wra...@li...>
https://lists.sourceforge.net/lists/listinfo/wrapper-user


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Wrapper-user mailing list
Wra...@li...<mailto:Wra...@li...>
https://lists.sourceforge.net/lists/listinfo/wrapper-user

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________
Wrapper-user mailing list
Wra...@li...<mailto:Wra...@li...>
https://lists.sourceforge.net/lists/listinfo/wrapper-user

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________
Wrapper-user mailing list
Wra...@li...<mailto:Wra...@li...>
https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] JVM restarts "Wrapper Process has not received any CPU time for 69 seconds"

[Tu T. N. <ttn...@ra...>]

Alexandre,

I have tried sending it again to both emails.  I did get this reply:


Your mail to 'Wrapper-user' with the subject



    RE: [Wrapper-user] JVM restarts "Wrapper Process has not received any CPU time for 69 seconds"



Is being held until the list moderator can review it for approval.



The reason it is being held:



    Message body is too big: 121187 bytes with a limit of 100 KB



Either the message will get posted to the list, or you will receive notification of the moderator's decision.  If you would like to cancel this posting, please visit the following URL:



    https://lists.sourceforge.net/lists/confirm/wrapper-user/960a8d94be5aa9ed0b0ce620b5f76edc98d73fef




From: Alexandre Klein [mailto:ale...@ta...]
Sent: Wednesday, October 01, 2014 10:54 PM
To: wra...@li...
Cc: Elaine M. Julius
Subject: Re: [Wrapper-user] JVM restarts "Wrapper Process has not received any CPU time for 69 seconds"

Tu,

Since version 3.2.3, the Wrapper has evolved  a lot.
Please take a look at the release notes which contains all bug fixes and new features for the Java Service Wrapper.
http://wrapper.tanukisoftware.com/doc/english/release-notes.html

As you can see, the list is long.  Here are  some changes that might resolve your issue:
- we have fixed memory leaks
- we have improved the way to write large amounts of output (otherwise the Wrapper thought the JVM was frozen)
- we have fixed heap corruption
- we have improved the way the Java side of the Wrapper behaves when the Wrapper fails to ping the JVM for an extended period of time. (This was causing problems on systems which were heavily IO bound because the Wrapper could block for a while while trying to write to the log file and the JVM was exiting)

As Leif mentioned, we haven't received any log file.
Can you send it to: su...@ta...<mailto:su...@ta...>
We would be happy to have a look. If possible, please send us the configuration file (wrapper.conf) as well.

Regards,
Alexandre Klein


Alexandre Klein
Tanuki Software, Ltd.
6-16-7-1001 Nishi-Kasai, Edogawa-ku
Tokyo 134-0088 Japan
Tel: +81-3-3878-3211
Fax: +81-3-3878-0313
http://www.tanukisoftware.com<http://www.tanukisoftware.com/>

On Thu, Oct 2, 2014 at 9:21 AM, Tu T. Nguyen <ttn...@ra...<mailto:ttn...@ra...>> wrote:
What we are looking for is some justification that we can give our customer that upgrading even might resolve the issue they are seeing.

Based on what you see in the logs, is there anything that would point to an upgrade being likely to resolve the problem?


From: Leif Mortenson [mailto:lei...@ta...<mailto:lei...@ta...>]
Sent: Wednesday, October 01, 2014 6:33 AM
To: Wrapper User List
Cc: Elaine M. Julius
Subject: Re: [Wrapper-user] JVM restarts "Wrapper Process has not received any CPU time for 69 seconds"

Tu,
Is the machine you are running on a physical or a virtual machine?  We have seen cases where a loaded host causes the VM to freeze up when the guest itself does not show any load.
3.2.3 is also a VERY old version of the Wrapper.  There have been a lot of improvements over the years in this area.  Please try 3.5.25 and see how that works for you.
You mentioned log files, but there was nothing attached to your mail.

Cheers,
Leif

On Wed, Oct 1, 2014 at 10:23 PM, Tu T. Nguyen <ttn...@ra...<mailto:ttn...@ra...>> wrote:

Hello,

I have an issue where the wrapper restarts the JVM multiple times a day.  We are using version 3.2.3 on Windows 2003 SP2.  The duration always varies.  We checked the CPU usage and its always very little when this happens .  We have about 6 services that use the wrapper on this machine and they restart at different times.  The suggestion is that if there was a CPU bottle neck they would all have this error at the same time.  We also have other sites which use the same configuration but do not have this problem.

We have collected logs with wrapper debugging enabled.  Please have a look, any help would be much appreciated!

Thank you,

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Wrapper-user mailing list
Wra...@li...<mailto:Wra...@li...>
https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] JVM restarts "Wrapper Process has not received any CPU time for 69 seconds"

[Alexandre K. <ale...@ta...>]

Tu,

Since version 3.2.3, the Wrapper has evolved  a lot.
Please take a look at the release notes which contains all bug fixes and
new features for the Java Service Wrapper.
http://wrapper.tanukisoftware.com/doc/english/release-notes.html

As you can see, the list is long.  Here are  some changes that might
resolve your issue:
- we have fixed memory leaks
- we have improved the way to write large amounts of output (otherwise the
Wrapper thought the JVM was frozen)
- we have fixed heap corruption
- we have improved the way the Java side of the Wrapper behaves when the
Wrapper fails to ping the JVM for an extended period of time. (This was
causing problems on systems which were heavily IO bound because the Wrapper
could block for a while while trying to write to the log file and the JVM
was exiting)

As Leif mentioned, we haven't received any log file.
Can you send it to: su...@ta...
We would be happy to have a look. If possible, please send us the
configuration file (wrapper.conf) as well.

Regards,
Alexandre Klein


Alexandre Klein
Tanuki Software, Ltd.
6-16-7-1001 Nishi-Kasai, Edogawa-ku
Tokyo 134-0088 Japan
Tel: +81-3-3878-3211
Fax: +81-3-3878-0313
http://www.tanukisoftware.com

On Thu, Oct 2, 2014 at 9:21 AM, Tu T. Nguyen <ttn...@ra...>
wrote:

>  What we are looking for is some justification that we can give our
> customer that upgrading even *might* resolve the issue they are seeing.
>
>
>
> Based on what you see in the logs, is there anything that would point to
> an upgrade being likely to resolve the problem?
>
>
>
>
>
> *From:* Leif Mortenson [mailto:lei...@ta...]
> *Sent:* Wednesday, October 01, 2014 6:33 AM
> *To:* Wrapper User List
> *Cc:* Elaine M. Julius
> *Subject:* Re: [Wrapper-user] JVM restarts "Wrapper Process has not
> received any CPU time for 69 seconds"
>
>
>
> Tu,
>
> Is the machine you are running on a physical or a virtual machine?  We
> have seen cases where a loaded host causes the VM to freeze up when the
> guest itself does not show any load.
>
> 3.2.3 is also a VERY old version of the Wrapper.  There have been a lot of
> improvements over the years in this area.  Please try 3.5.25 and see how
> that works for you.
>
> You mentioned log files, but there was nothing attached to your mail.
>
>
>
> Cheers,
> Leif
>
>
>
> On Wed, Oct 1, 2014 at 10:23 PM, Tu T. Nguyen <ttn...@ra...>
> wrote:
>
>
>
> Hello,
>
>
>
> I have an issue where the wrapper restarts the JVM multiple times a day.
> We are using version 3.2.3 on Windows 2003 SP2.  The duration always
> varies.  We checked the CPU usage and its always very little when this
> happens .  We have about 6 services that use the wrapper on this machine
> and they restart at different times.  The suggestion is that if there was a
> CPU bottle neck they would all have this error at the same time.  We also
> have other sites which use the same configuration but do not have this
> problem.
>
>
>
> We have collected logs with wrapper debugging enabled.  Please have a
> look, any help would be much appreciated!
>
>
>
> Thank you,
>
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>

Re: [Wrapper-user] JVM restarts "Wrapper Process has not received any CPU time for 69 seconds"

[Tu T. N. <ttn...@ra...>]

What we are looking for is some justification that we can give our customer that upgrading even might resolve the issue they are seeing.

Based on what you see in the logs, is there anything that would point to an upgrade being likely to resolve the problem?


From: Leif Mortenson [mailto:lei...@ta...]
Sent: Wednesday, October 01, 2014 6:33 AM
To: Wrapper User List
Cc: Elaine M. Julius
Subject: Re: [Wrapper-user] JVM restarts "Wrapper Process has not received any CPU time for 69 seconds"

Tu,
Is the machine you are running on a physical or a virtual machine?  We have seen cases where a loaded host causes the VM to freeze up when the guest itself does not show any load.
3.2.3 is also a VERY old version of the Wrapper.  There have been a lot of improvements over the years in this area.  Please try 3.5.25 and see how that works for you.
You mentioned log files, but there was nothing attached to your mail.

Cheers,
Leif

On Wed, Oct 1, 2014 at 10:23 PM, Tu T. Nguyen <ttn...@ra...<mailto:ttn...@ra...>> wrote:

Hello,

I have an issue where the wrapper restarts the JVM multiple times a day.  We are using version 3.2.3 on Windows 2003 SP2.  The duration always varies.  We checked the CPU usage and its always very little when this happens .  We have about 6 services that use the wrapper on this machine and they restart at different times.  The suggestion is that if there was a CPU bottle neck they would all have this error at the same time.  We also have other sites which use the same configuration but do not have this problem.

We have collected logs with wrapper debugging enabled.  Please have a look, any help would be much appreciated!

Thank you,

Re: [Wrapper-user] JVM restarts "Wrapper Process has not received any CPU time for 69 seconds"

[Leif M. <lei...@ta...>]

Tu,
Is the machine you are running on a physical or a virtual machine?  We have
seen cases where a loaded host causes the VM to freeze up when the guest
itself does not show any load.

3.2.3 is also a VERY old version of the Wrapper.  There have been a lot of
improvements over the years in this area.  Please try 3.5.25 and see how
that works for you.

You mentioned log files, but there was nothing attached to your mail.

Cheers,
Leif

On Wed, Oct 1, 2014 at 10:23 PM, Tu T. Nguyen <ttn...@ra...>
wrote:

>
>
> Hello,
>
>
>
> I have an issue where the wrapper restarts the JVM multiple times a day.
> We are using version 3.2.3 on Windows 2003 SP2.  The duration always
> varies.  We checked the CPU usage and its always very little when this
> happens .  We have about 6 services that use the wrapper on this machine
> and they restart at different times.  The suggestion is that if there was a
> CPU bottle neck they would all have this error at the same time.  We also
> have other sites which use the same configuration but do not have this
> problem.
>
>
>
> We have collected logs with wrapper debugging enabled.  Please have a
> look, any help would be much appreciated!
>
>
>
> Thank you,
>

Re: [Wrapper-user] JVM restarts "Wrapper Process has not received any CPU time for 69 seconds"

[Tu T. N. <ttn...@ra...>]

Hello,

I have an issue where the wrapper restarts the JVM multiple times a day.  We are using version 3.2.3 on Windows 2003 SP2.  The duration always varies.  We checked the CPU usage and its always very little when this happens .  We have about 6 services that use the wrapper on this machine and they restart at different times.  The suggestion is that if there was a CPU bottle neck they would all have this error at the same time.  We also have other sites which use the same configuration but do not have this problem.

We have collected logs with wrapper debugging enabled.  Please have a look, any help would be much appreciated!

Thank you,

Tu Nguyen | FTPC Support Engineer | Office: 408.271.3464 | Mobile: 408.464.3252 | Rockwell Automation | Mission Viejo, CA (GMT -8)

Re: [Wrapper-user] Contribution: smaller fixes for test wrapper script (unix)

[Alexandre K. <ale...@ta...>]

Hi Dannes,

Thank you again for message.
We were aware of this problem on different platforms and fixed it for the
next version.

Please let me know if you see any problem or part of the code that could be
improved.

Regards,
Alexandre Klein

Alexandre Klein
Tanuki Software, Ltd.
6-16-7-1001 Nishi-Kasai, Edogawa-ku
Tokyo 134-0088 Japan
Tel: +81-3-3878-3211
Fax: +81-3-3878-0313
http://www.tanukisoftware.com

On Sat, Sep 20, 2014 at 11:49 PM, Dannes Wessels <da...@ex...>
wrote:

> Hi,
>
> On 16 Sep 2014, at 4:39 , Alexandre Klein <
> ale...@ta...> wrote:
>
> And thank you for your contribution. We always welcome suggestions.
>
>
> one addition: since macosx does not support the -o option for uname,
> please could you write
>
> # check if we are running under Cygwin terminal
> CYGWIN=`uname -o 2> /dev/null`
>
>
>
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.  Video for Nerds.  Stuff that Matters.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>

Re: [Wrapper-user] Contribution: smaller fixes for test wrapper script (unix)

[Dannes W. <da...@ex...>]

Hi,

On 16 Sep 2014, at 4:39 , Alexandre Klein <ale...@ta...> wrote:

> And thank you for your contribution. We always welcome suggestions.

one addition: since macosx does not support the -o option for uname, please could you write

# check if we are running under Cygwin terminal
CYGWIN=`uname -o 2> /dev/null`

Re: [Wrapper-user] Contribution: smaller fixes for test wrapper script (unix)

[Alexandre K. <ale...@ta...>]

Dannes,

Thank you very much for your email.

And thank you for your contribution. We always welcome suggestions. We are
always curious to know how users are using the Wrapper so we can
add/edit features to make the Wrapper easier to use.

If you see any problem in the code, or if you have ideas for new features,
please let us know.

Regards,
Alexandre Klein

Alexandre Klein
Tanuki Software, Ltd.
6-16-7-1001 Nishi-Kasai, Edogawa-ku
Tokyo 134-0088 Japan
Tel: +81-3-3878-3211
Fax: +81-3-3878-0313
http://www.tanukisoftware.com

On Tue, Sep 16, 2014 at 5:00 AM, Dannes Wessels <di...@ex...> wrote:

> Hi,
>
> please find attached a modified version of the unix test wrapper script,
> containing some smaller modification to have the script better working for
> MacOSX (and a typo fix)
>
> I have the changes in use for a long time now, I'd like to contribute by
> ideas and hope you can use it.
>
> Kind regards
>
> Dannes
>
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>

[Wrapper-user] Contribution: smaller fixes for test wrapper script (unix)

[Dannes W. <di...@ex...>]

Hi,

please find attached a modified version of the unix test wrapper script, containing some smaller modification to have the script better working for MacOSX (and a typo fix)

I have the changes in use for a long time now, I'd like to contribute by ideas and hope you can use it.

Kind regards

Dannes