Re: [Wrapper-user] Classload problems with inner classes. Was Re: Classes unloaded too early on process termination

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

Chuck,
    A note on your large classpath.   You can make your app much easier 
to maintain by
changing it to the following:
wrapper.java.classpath.1=../dist/AnalysisService.jar
wrapper.java.classpath.2=../lib/*.jar
wrapper.java.classpath.3=../classes

Chuck Williams wrote:
> Hi Leif,
>
> Thanks for your response.  My latest wrapper.conf is attached.
>
> I user "Method 3" integration, i.e. a class that implements 
> WrapperListener.
>
> Here are a couple more anomalies I've noted:
>
>    1. wrapper.restart.delay is not always honored.  If the application
>       does Runtime.getRuntime().halt() then it works, but if the jvm
>       halts on its own (e.g., because of a SIGSEGV, which I was
>       getting for a while), or if wrapper does kill -9 on the jvm due
>       to a ping timeout (see below) then the restart delay is not
>       honored.  When the restart delay is not honored, the restart
>       frequently does not work.  This is why I've changed
>       wrapper.on_exit.default to RESTART, which causes the failure to
>       start the jvm without restart delay to then get trapped for
>       subsequent jvm launch.  Fortunately the restart delay is then
>       honored and the second launch attempt succeeds.
>
Could you please show me an example wrapper.log with wrapper.debug=true 
enabled
that shows an example of the wrapper ignoring the restart delay?  I 
tried the examples
that you gave me, but they all worked correctly for me.

>    1. The jvm evidently does not respond to pings during a full gc. 
>       I've gotten cases where the jvm is waiting too long to start
>       full vc, with little space left.  This causes an abnormally long
>       gc cycle, and unloads some classes (although not the ones
>       subject to the inner class problem), ending up taking longer
>       than the default 30 seconds.  This is why wrapper.ping.timeout
>       is increased to 5 minutes.
>
Do you have enough physical  memory to keep the entire JVM + OS in 
memory without
any disk swapping?   In my experience, Java gets VERY SLOW when it is 
forced to do
disk swapping.   Your memory settings are in 
../conf/wrapper.memory.properties which
you did not send.   How much memory are you using?
>
> I'll have to do a run with wrapper debug logging until I get one of 
> the occasional inner class problems.  I've now noted these both on 
> start-up and shut-down.  Occasionally the app is unable to load many 
> classes after start-up.  This appears binary.  Either many classes are 
> missing, or all is fine.  If all is fine, there is never a subsequent 
> problem until shutdown, when the inner class issue can arise again.
>
> This problem first arose on the upgrade from wrapper 3.1.2 to 3.2.3.  
> I don't believe any other changes were involved, although it could be 
> coincidental of course.  I.e., the issue could also exist in wrapper 
> 3.1.2.
>
> The app does not use any native libraries other than wrapper.  The 
> rest is pure java.
>
> Thanks for your help!  I'll post a debug log file with the inner class 
> issue as soon as I can generate one.
Ok, I'll take a look at your debug log when you post it.

Cheers,
Leif