-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yuval,
On 2/4/16 3:14 AM, Yuval Schwartz wrote: >> On Wed, Feb 3, 2016 at 11:15 PM, Christopher Schultz < >> ch...@christopherschultz.net> wrote: > > ELB usually uses HTTP keepalive, so that might be part of the > issue. > >> ELB has a feature called "connection draining" which keeps >> connections open while the instance is de-registering (my >> instance begins de-registering when I shutdown tomcat) for a set >> period of time (default: 300 s). It is this connection that stays >> open when tomcat shuts down that causes the WARNING message to >> appear. If I disable connection draining then I stop seeing the >> WARNING when I shutdown tomcat. That'll do it. So, if you had waited 5 minutes between removing your node from ELB and shutting-down Tomcat, you'd find that there also no errors. >> However, "connection draining" seems like a nice feature. One >> option to overcome this WARNING while still keeping connection >> draining would be to first undeploy my application, then, after >> the connection draining time period expires, shutdown tomcat >> (tested this, doesn't throw the warning). > >> Do you have any other recommendations for how I might keep this >> feature and adjust something else in my configuration? Any light >> to shed on the matter? Wait 5 minutes? 5 minutes is quite a long time to drain the node. How long is the average request? In production, we use ELB with 30-second draining. (Then again, we have a layer of stateless httpd instances in between... when we drain our Tomcat nodes, we typically wait over an hour.) I think this might come down to the lack of flexibility of ELB. The way we use ELB, we are balancing between a set of httpd instances which are *all* proxying to the same set of back-end Tomcat nodes. So the currently-enabled set of httpd instances is irrelevant to the client: any httpd can get to any Tomcat. When we want to service an httpd instance, we remove it from the ELB with a short draining period and reboot, upgrade, whatever. No interruption to the Tomcat nodes. If we want to service a Tomcat node, we bring-down the node from *httpd*, not from ELB. We are using mod_jk which allows you to put a Tomcat node into a "disabled" state, which means existing users will still be routed to the node that is "going down" but new users will go to other nodes instead. Once the number of sessions on that node goes to zero, we STOP the node in mod_jk (NO TRAFFIC AT ALL to the node) and then service it. ELB lacks this two-phase removal feature that mod_jk has. That means, when you remove a node from ELB, the countdown starts for your users... if they don't log off from that node, they will lose their sessions in T minus 5 minutes. If you are using sticky sessions with no clustering (like we are), then those users are just out of luck when the 5-minute timer runs out. If you want better behavior, you are going to need more complexity. /On the other hand/, if you *are* clustered and don't use (or need) sticky sessions, then you can significantly reduce that user-draining period to the maximum reasonable response time you expect to be able to serve. If you have a super-fast entirely-clustered (or stateless) service, set the drain time to 1 second. If you have requests that routinely last 45 seconds, set the drain-time to more like 90 seconds. 5 minutes doesn't seem like it makes any sense to be in any scenario, though. Hope that helps, - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAla1GMcACgkQ9CaO5/Lv0PBO+ACeJLP4z3DUfcUqVmG30w7sYSsN 5ggAoLDU8DSnA1vjVppiN9QU11GFsfng =RhN2 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
