|Hostname and Port Changes from Status Worker do not affect new connections either
|Joe Kislo <joekislos>
|Tomcat Developers Mailing List <dev>
Description Joe Kislo 2009-05-19 15:39:16 UTC
Hostname and Port Changes from Status Worker do not affect new connections either I do not know if this is a documentation issue or a software bug. I am hoping it is a software bug (because I want it to work!), but I'll settle for some clarification in the documentation. If you change the hostname or port of an AJP worker from the Status Worker, the change does not appear to always work. The documentation states: --- http://tomcat.apache.org/connectors-doc/reference/status.html: Note that changing the host name or port will only take effect for new connections. Already established connections to the old address will still be used. --- This is, actually, exactly the behavior I want. Old connections continue to use the old settings, but new connections use the new settings. What I am seeing is my change is not affecting new connections either (I am using a non-keep alive new TCP connection... I am using curl). I believe there must be some sort of worker internal to mod_jk, and that worker is not being updated with the setting. If I make TWO new requests in parallel, the first request will get old settings, and the second request will get the new settings. So either the internal workers need to be signaled for a graceful shutdown after a port or hostname change (after handling their existing requests) or the existing internal workers need to be notified of the change.
Comment 1 Joe Kislo 2009-05-19 15:40:59 UTC
FWIW, what I am actually trying to accomplish is an administrative shutdown of an AJP worker at runtime. I am trying to accomplish this by changing the port to 0. So I would settle for another way of admin downing a worker... I am going to try building a LB worker with just the single AJP subworker in it and see if I can accomplish it that way, even though I am doing no load balancing.
Comment 2 Rainer Jung 2009-05-20 04:07:47 UTC
I will investigate.
Comment 3 Mladen Turk 2009-12-21 04:04:06 UTC
Fixed in the SVN by actually invalidating the endpoint cache, so even already connected sockets in the cache will be disconnected allowing new connections with new address
Comment 4 Rainer Jung 2010-02-23 02:54:56 UTC
Will be part of 1.2.29.