Life cycle issue in Jetty 5.1

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Life cycle issue in Jetty 5.1

Tony Thompson
I am not sure how much detail I need to get into here without confusing the issue so if I need to provide more I can.  I have an application that runs instances of Jetty inside their own classloader.  If I need to restart one of those instances, I shut it down and start a new instance inside of a new classloader (that may or may not be the best way to do it on my side but that is currently how it is being done).  In the Jetty configuration (done programatically), I have one or more instances of org.mortbay.jetty.Server.  The issue that I am having is this, when one of the org.mortbay.jetty.Server instances starts, if its listener fails to start (say a BindException is thrown), all of the WebApplicationContexts within that Server have already been started.  If I call Server.stop() it obviously thinks it is not started so stop() on the WebApplicationContext is not called either (even though start() was).  I am also attempting to call destroy() on the Server instance that failed to start but that doesn't seem to have any affect either.
 
Because of that and how I am loading things in their own classloader, when I am in that failed state and I cannot go through the stop() and destroy() steps on Server (and its WebApplicationContexts), there is an instance of org.mortbay.http.ContextLoader that keeps a reference to its parent classloader in _parent.  That reference is preventing my classloader from being garbage collected.  Ultimately to fix my issue, I need destroy() to be called in the ContextLoader to release the reference.  OK, so maybe it got confusing after all....
 
Anyway, bottom line is Jetty starts the WebApplicationContexts in the Server instance but doesn't give me a way to clean things up properly if the Server fails to start at some point after the WebApplicationContexts have been started.  Any way that can be fixed in 5.1 because it is causing me some headache (servers run out of memory)?
 
Thanks for any info.
Tony
 
This message (and any associated files) is intended only for the
use of the individual or entity to which it is addressed and may
contain information that is confidential, subject to copyright or
constitutes a trade secret. If you are not the intended recipient
you are hereby notified that any dissemination, copying or
distribution of this message, or files associated with this message,
is strictly prohibited. If you have received this message in error,
please notify us immediately by replying to the message and deleting
it from your computer. Messages sent to and from Stoneware, Inc.
may be monitored.


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Life cycle issue in Jetty 5.1

Shef
Tony Thompson wrote:

> I am not sure how much detail I need to get into here without confusing
> the issue so if I need to provide more I can.  I have an application
> that runs instances of Jetty inside their own classloader.  If I need to
> restart one of those instances, I shut it down and start a new instance
> inside of a new classloader (that may or may not be the best way to do
> it on my side but that is currently how it is being done).  In the Jetty
> configuration (done programatically), I have one or more instances of
> org.mortbay.jetty.Server.  The issue that I am having is this, when one
> of the org.mortbay.jetty.Server instances starts, if its listener fails
> to start (say a BindException is thrown), all of the
> WebApplicationContexts within that Server have already been started.  If
> I call Server.stop() it obviously thinks it is not started so stop() on
> the WebApplicationContext is not called either (even though start()
> was).  I am also attempting to call destroy() on the Server instance
> that failed to start but that doesn't seem to have any affect either.
>  
> Because of that and how I am loading things in their own classloader,
> when I am in that failed state and I cannot go through the stop() and
> destroy() steps on Server (and its WebApplicationContexts), there is an
> instance of org.mortbay.http.ContextLoader that keeps a reference to its
> parent classloader in _parent.  That reference is preventing my
> classloader from being garbage collected.  Ultimately to fix my issue, I
> need destroy() to be called in the ContextLoader to release the
> reference.  OK, so maybe it got confusing after all....
>  
> Anyway, bottom line is Jetty starts the WebApplicationContexts in the
> Server instance but doesn't give me a way to clean things up properly if
> the Server fails to start at some point after the WebApplicationContexts
> have been started.  Any way that can be fixed in 5.1 because it is
> causing me some headache (servers run out of memory)?

How about trapping the BindException (or any other exception) and
removing the WebApplicationContexts manually? Possible?

Also -- I don't know what your application architecture is, but
classloader problems can lead to madness. Using multiple classloaders
when you don't need to is generally a bad idea. If there's any way you
can clean things up and have everything use a single classloader you'll
likely be better off.

I know, the theory is that if different webapps use different
classloaders then they are less likely to conflict. It doesn't work very
well in practice, though. If you have genuinely different apps, I'd put
them in different JVMs.







-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Life cycle issue in Jetty 5.1

Tony Thompson
> How about trapping the BindException (or any other exception) and
removing the WebApplicationContexts manually? Possible?

I do trap the BindException.  The issue is Jetty has things partially
started but won't let me shut things down (I try when I catch the
exception).  I shouldn't have to try to figure out what parts Jetty
already started and shut them down individually.  That would pretty much
be a duplicate of the shutdown code already in Jetty.  As I remember,
there is a _started flag that is being checked in the Jetty code that is
only true if the startup completes entirely.  The problem is that is not
granular enough since there are actually pieces that have successfully
started that can't be shut down now.
 
This message (and any associated files) is intended only for the
use of the individual or entity to which it is addressed and may
contain information that is confidential, subject to copyright or
constitutes a trade secret. If you are not the intended recipient
you are hereby notified that any dissemination, copying or
distribution of this message, or files associated with this message,
is strictly prohibited. If you have received this message in error,
please notify us immediately by replying to the message and deleting
it from your computer. Messages sent to and from Stoneware, Inc.
may be monitored.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support