tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brent Verner <>
Subject problem with start/stop of CoyoteConnector
Date Wed, 27 Aug 2003 03:56:53 GMT
Overview: CoytoteConnector.start()/stop() are misbehaving on tomcat-4.1.27

  a) the org.apache.coyote.http11.Http11Protocol handler will _not_ 
     start() successfully after I've stop()ped it.
  b) the  org.apache.jk.server.JkCoyoteHandler handler will start() after
     a stop() but after a number of stop()/start() cycles, it fails to
     start successfully.
  In both cases, the connector thinks the handler isAvailable(), but 
  there is simply no service being offered on the specified port. nada.

Is this a known issue with the connector/handler interaction?  A quick
perusal of the source did not lead me to a quick answer, and I won't
have any real time to dig into the problem until after the project
is complete (a couple of months away), so I'm asking y'all.

  I've got apache/mod_jk setup to loadbalance with a pool of tomcats as
shown below.

         (Round Robin DNS)
     A1         A2        A3
    /--\-------/--\------/--\   <-- mod_jk lb worker balancing/session affinity
  T1P  |     T2P  |    T3P  |   <-- primary Tomcat Services
       |          |         | 
      T1S        T2S       T3S  <-- secondary tomcat Services
  On each of the T.P (primary) tomcats, I have a Valve that verifies a 
connection to an external data source (proprietary CMS thingie), and when
it fails, it does a CoyoteConnector.stop() for the Jk handler, sends a 
redirect back thru the DNS layer, so it will get another tomcat that has 
a valid connection to the external data source.

   All of this appeared to work as intended, so I wrote a quickie JSP to
let the client to "restart" the downed connectors which were stop()ped
due to the external data source becoming unavailable.  At this point I
noticed that issuing a stop()/start() sequence to the http11 connector
caused the http11 connector to not _really_ restart (and listen for
connections).  Having seen this "issue" is only allowed the Jk connector
to be "managed" via this JSP.  After a handful of stop()/start() cycles
on the Jk handler, I noticed that the Jk connector wasn't really listening
for connections while the CoyoteConnector thought is was "available".

  In addition to this, the misbehaving handlers are not properly 
reinitialized (to listen for conns) even when reloading the context
via the /manager/ interface.
  Can anyone offer any possible solution to this?  It is _not_ critical,
as the client can easily restart the tomcats one at a time if this
situation arises in production.  I'm mostly wanting to see this bug
squashed :-)

  FWIW, I've attached the JSP that handles the restarting of downed


"Develop your talent, man, and leave the world something. Records are 
really gifts from people. To think that an artist would love you enough
to share his music with anyone is a beautiful thing."  -- Duane Allman

View raw message