tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dawid Weiss <dawid.we...@cs.put.poznan.pl>
Subject Shuttind down an embedded server does not clean up properly.
Date Wed, 19 Apr 2006 18:57:12 GMT

Hi there,

Is there any special way to 'clean up' after an Embedded server is 
started? Because at the moment it simply doesn't work properly -- when 
shutting down an instance of Embedded (.stop()) and starting a new 
instance of Embedded (.start()) for a short period of time (one or two 
seconds) the requests are served with the old mapper. This causes HTTP 
400 (No Host matches server name...). In StandardEngineValve we have:

     public final void invoke(Request request, Response response)
         throws IOException, ServletException {

         // Select the Host to be used for this Request
         Host host = request.getHost();
         if (host == null) {
             response.sendError
                 (HttpServletResponse.SC_BAD_REQUEST,
                  sm.getString("standardEngine.noHost",
                               request.getServerName()));

host is null because in Mapper:

         if (mappingData.host == null) {
             Host[] hosts = this.hosts;

the hosts variable correctly indicates there is a 'localhost' 
initialized and ready, but in a later check the list of contexts is 
empty (!) and the method returns immediately without further 
initializations.

I'm guessing the problem is in static collections somewhere (Registry?) 
being shared by different engines and reusing the stopped instance's 
list of contexts, but I just can't figure out how to cleanup properly on 
shutdown. Is there any (undocumented :) requirement to spawn Engine 
instances in separate class loaders? It seems perfectly justified and 
reasonable to shutdown one embedded Engine and spawn another one bound 
to the same host/port combination from within the same class loader, so 
to me the current behavior appears to be a bug.

I realize the question goes quite deep in Tomcat internals, so if 
developers mailing list is more adequate, let me know and I'll repost it 
over there.

Thanks,
Dawid






---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message