Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Subject: Re: Installing APR based Apache Tomcat Native Library
To: Tomcat Users List <users@tomcat.apache.org>
References: 
 <CAH5Tk0FfdY4cS2YsgaDBZAJZbAGZXjo5_xd8kwUUfXJ8_81KEQ@mail.gmail.com>
 <OFF22BB7FD.59150FD2-ONC1257F48.002DE3EC-C1257F48.002E7B5D@lex-com.net>
 <CAH5Tk0Ff=0JvLkX=PocUtk1Tu5aEL_+_pXD_24eMYjxOTGBjAA@mail.gmail.com>
 <CAH5Tk0ER1TZcPRfP0BDTLtd=bdvjx1KxBRg4Uhqjt7b7TJUWqA@mail.gmail.com>
 <56B0BA1F.6000103@christopherschultz.net>
 <CAH5Tk0FKU3itL+JA0vTenhWT40CrJX+DrVQPiY25ZjSD29oi0g@mail.gmail.com>
 <56B10CF8.6090602@christopherschultz.net>
 <CAH5Tk0F6p+rHzk4XdHjjb9=QKTm474u7d60VQLRvo0dw8uZi0A@mail.gmail.com>
 <56B21698.1040401@christopherschultz.net>
 <CAH5Tk0Fq=m6GSEdr-GNpvjHe80OikXfy7d_Ggc-rif3pHXOdYA@mail.gmail.com>
 <56B26DD5.3020406@christopherschultz.net>
 <CAH5Tk0Gd9i5aGK_1b6gyPDZxTkBTDmTrL_ijgNvc8Rq+rfZ_UA@mail.gmail.com>
 <CAH5Tk0E2Cz+3eHs+ty_6LH4vErn0XXxqnfnLh7SsdEE9AXjHMA@mail.gmail.com>
From: Christopher Schultz <chris@christopherschultz.net>
Message-id: <56B518C7.1010009@christopherschultz.net>
Date: Fri, 05 Feb 2016 16:48:55 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0)
 Gecko/20100101 Thunderbird/38.5.1
MIME-version: 1.0
In-reply-to: 
 <CAH5Tk0E2Cz+3eHs+ty_6LH4vErn0XXxqnfnLh7SsdEE9AXjHMA@mail.gmail.com>
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit

-----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 < 
>> chris@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org