Hi Christopher,
Il 23/12/2015 19:12, Christopher Schultz ha scritto:
Jason,
On 12/22/15 11:46 PM, Jason Britton wrote:
On Tue, Dec 22, 2015 at 4:01 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
So mod_jk routes a request to the node which is going down, and then
decides to re-route because the connection times-out? Just making sure I
have that all in my head (it's an awfully long sentence).
my understanding, could be wrong, that if the connect_timeout is reached by
mod_jk that it would try a different node.
I can't remember if it will auto-retry; it might depend upon your
configuration.
This is configurable, usually i set:
worker.$WORKER_NAME.recovery_options=19
that is from memory, retry only GET and HEAD, not POST.
This because it have occured to me, that a POST timeouts to some app
running in a tomcat backend but the tomcat side processing thread does
not know this and it continues running. JK retries the same POST in
another tomcat backend. In this case you get your POST request executed
at least twice which usually is not nice.
BTW this thread reminds me about a patch i sent but never followed on
being busy with other stuff:
https://mail-archives.apache.org/mod_mbox/tomcat-users/201404.mbox/%3c533ec184.7070...@postecom.it%3E
The problem i tried to solve was that when you have N backends and your
site get's slashdotted so that backends are all busy, mod_jk amplifies
the load even more, as it retries at least all N backends. With that
patch i added an option for thelling mod_jk to retry only X backends,
usually only once.
A different active tomcat node now receives the request
and tries to reconstitute the user's session from the same shared
JDBCStore, but what if the first tomcat node is not finished shutting
down
and has not finished writing out this particular user's session data yet?
How can we ensure that session data will be there?
Although I'm not entirely sure of the behavior of Tomcat's clustering
features in that particular case, you are mostly asking the following:
"what happens if two nodes are essentially sharing a session? how do I
make sure their view of the session is consistent?"
I should have clarified the environment I was envisioning was one with
sticky sessions, no clustering. And the situation I'm looking to wrap my
brain around is one where the once active node is triggered to write out
session data due to the impending shut down of the particular node.
At about the same time this shutdown is occurring a request comes in for a
client that has a session cookie value routing it to the node being shut
down. mod_jk times out trying to connect to this node and reroutes the
request to an active node. I see a race condition where depending on how
long it takes the first tomcat being shutdown to write out session data to
the JDBCStore, that the subsequent tomcat node trying to service the
request may not find this user's session data in the shared JDBCStore. I'd
really like to know if this is truly something to be concerned about, and
if so, how to account for it.
This scenario really isn't any different than a clustered environment
with two requests going to two different nodes (for any reason, really).
I think this answer still stands:
I think the answer is: you can't. Make your requests as idempotent as
possible and, when possible, execute the other kinds of requests such a
way that the first one to execute "wins" and the others fail gracefully.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Regards,
Frederik
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
