Menu
▾
▴
Re: [Wrapper-user] Classload problems with inner classes. Was Re: Classes unloaded too early on process termination
|
From: Chuck W. <ch...@ma...> - 2006-11-11 07:55:48
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Cool, thanks. I didn't realize that would work with wrapper. The way
I've handled it is to generate wrapper.conf automatically from a
wrapper.conf.template that contains a marker for where the classpath
gets inserted. Your way is cleaner!<br>
<br>
I've tried a bunch of times but don't yet have the classloading failure
when running debug. They happen occassionally, once today, but before
switching on wrapper.debug.<br>
<br>
I'll post it when as as it happens.<br>
<br>
In case it is helpful, here is the one that happened earlier without
debug. This was after running the application for a while with no
problem from the console, then typing control-C:<br>
<br>
<blockquote type="cite">STATUS | wrapper | main | 2006/11/05
15:55:06 | INT trapped. Shutting down.<br>
INFO | jvm 1 | main | 2006/11/05 15:55:06 | Error in
WrapperListener.stop callback. java.lang.NoClassDefFoundError:
com/metalincs/analysis/framework/Main$1<br>
INFO | jvm 1 | main | 2006/11/05 15:55:06 |
java.lang.NoClassDefFoundError: com/metalincs/analysis/framework/Main$1<br>
INFO | jvm 1 | main | 2006/11/05 15:55:06 | at
com.metalincs.analysis.framework.Main.stop(Main.java:493)<br>
INFO | jvm 1 | main | 2006/11/05 15:55:06 | at
org.tanukisoftware.wrapper.WrapperManager$12.run(WrapperManager.java:3134)<br>
STATUS | wrapper | main | 2006/11/05 15:55:08 | <-- Wrapper
Stopped<br>
</blockquote>
<br>
Main is the class that implements WrapperListener. Main$1 is an inner
class containing the Runnable for a thread that is launched to do some
of the shutdown activity. Here is the method, Main.stop(), Line 493
is what you'd expect, the first code line of the method, which creates
an instance of the inner class. (And yes, I know that wrapper can
accomplish the same thing using the configured shutdown timeout).<br>
<br>
<blockquote type="cite">
<pre> public int stop(int exitCode) {</pre>
<pre> </pre>
<pre> Thread cleanStop = new Thread(new Runnable(){</pre>
<pre> public void run() {</pre>
<pre> ComponentManager.getComponentManager().shutdown();</pre>
<pre>
stopHttpServer(bootstrapServer);</pre>
<pre> bootstrapServer = null;</pre>
<pre> if (adminServer!=null) {</pre>
<pre> stopHttpServer(adminServer);</pre>
<pre> adminServer = null;</pre>
<pre> }</pre>
<pre> if (indexServer!=null) {</pre>
<pre> stopHttpServer(indexServer);</pre>
<pre> indexServer = null;</pre>
<pre> }</pre>
<pre> if (searchServer!=null) {</pre>
<pre> stopHttpServer(searchServer);</pre>
<pre> searchServer = null;</pre>
<pre> }</pre>
<pre> }</pre>
<pre> });</pre>
<pre> cleanStop.setDaemon(true);</pre>
<pre> cleanStop.start();</pre>
<pre> </pre>
<pre> try {</pre>
<pre> cleanStop.join(hardRestartTimeout);</pre>
<pre> } catch (InterruptedException e) {</pre>
<pre> throw new RuntimeException(e);</pre>
<pre> }</pre>
<pre> if (cleanStop.isAlive())</pre>
<pre> logger.warn("Hard restarting AnalysisService because soft restart timed out after " + hardRestartTimeout + " millis.");</pre>
<pre> </pre>
<pre> return exitCode;</pre>
<pre> }</pre>
<pre>
</pre>
</blockquote>
<br>
<br>
<br>
Thanks for your help,<br>
<br>
Chuck<br>
<br>
<br>
Leif Mortenson wrote on 11/10/2006 08:54 PM:
<blockquote cite="mid...@ta..." type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->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.
</pre>
<blockquote type="cite">
<pre wrap=""> 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.
</pre>
</blockquote>
<pre wrap=""><!---->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?
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->Ok, I'll take a look at your debug log when you post it.
Cheers,
Leif
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
<a class="moz-txt-link-freetext" href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642</a>
_______________________________________________
Wrapper-user mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Wra...@li...">Wra...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/wrapper-user">https://lists.sourceforge.net/lists/listinfo/wrapper-user</a>
</pre>
</blockquote>
<br>
<div class="moz-signature"><br>
</div>
</body>
</html>
|
