You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Jules Gosnell <jg...@lastminute.com> on 2003/04/04 18:24:34 UTC
mod_jk integration, local_worker, session capping/bleeding....
http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.0/doc/jk/workershowto.html
contains the following text:
'We need a graceful shut down of a node for maintenance. The balancer in
front asks a special port on each node periodically. If we want to
remove a node from the cluster, we switch off this port. The
loadbalancer can't connect to it and marks the node as down. But we
don't move the sessions to another node. In this environment it is an
error if the balancer sends a request without a session to an
apache+mod_jk+tomcat which port is switched off. And if the load
balancer determines that a node is down no other node is allowed to send
a request without a session to it. Only requests with old sessions on
the switched off node would be routed to this node. After some time
nobody uses the old sessions and the sessions will time out. Then nobody
uses this node, because all session are gone and the node is unreachable
without a session-id in the request. If someone uses a session which
timed out, our servlet system sends a redirect response without a
session id to the browser. This is necessary for me, because on a
switched off node apache and tomcat can still be up and running, but
they are in an old state and should only be asked for valid old
sessions. After the last session timed out, I could update the node etc.
without killing sessions or moving them to another node. Sometimes we
have a lot of big objects in our sessions, so it would be really time
consuming to move them.'
My reading of this is that I can dynamically tell TC to stop accepting
new sessions. It will notify mod_jk and thenceforth only requests
already bound to existing sessions hosted in this TC instance will be
forwarded from mod_jk.
I have scoured the web, mailing list archives and src code, most likely
with the wrong keywords, trying to find references explaining, how I can
tell TC that I want to bleed the existing sessions off it, using this
functionality.
I understand and use the support for session affinity via jvmRoute and
other worker properties. I would now like to extend what I have to
support the graceful shutdown on TC nodes without the loss of session
data. I do not want to persist or otherwise distribute these sessions.
Can anyone point me in the right direction ?
Thanks for your time,
Jules
------------------------------
This e-mail is intended for the named addressee only. It may contain confidential and/or privileged information. If you have received this message in error, please let us know and then delete this message from your system. You should not copy the message, use it for any purpose or disclose its contents to anyone.
________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
RE: mod_jk integration, local_worker, session capping/bleeding....
Posted by Dennis Cartier <de...@canadianblackbook.com>.
Hi Jules,
It's has been awhile :)
I can shed some light on this, I also read that page and spent forever
trying to figure out what the author was alluding to. I eventually found it
on the tomcat-dev list, or perhaps the CVS logs, I cannot remember which.
He is actually talking about his hardware load balancer monitoring this
special 'port', not Tomcat or mod_jk! The page fails to mention this and
definitely makes you think that this is something you can do with just
mod_jk->Tomcat. It's not.
In my case, I use the 'local_worker' property to accomplish a similar
function. I keep all my nodes set to '0' for local_worker and only toggle
them to '1' when I want mod_jk to ignore the remaining node(s) still set to
'0'. Of course you have to be a bit careful as toggling the same node to '1'
across your cluster will cause that node to become very popular!
I am not sure, but I also observed a bit of weird behaviour using this
technique. It seemed that the round robin load balancing failed to work when
more than 1 node was set to '1'. The first node set to '1' in the
workers.properties file seemed to always get the request. I have to look
into this further still.
Dennis Cartier
-----Original Message-----
From: Jules Gosnell [mailto:jgosnell@lastminute.com]
Sent: Friday, April 04, 2003 11:25 AM
To: tomcat-user@jakarta.apache.org
Cc: jules@mortbay.com
Subject: mod_jk integration, local_worker, session capping/bleeding....
http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.0
/doc/jk/workershowto.html
contains the following text:
'We need a graceful shut down of a node for maintenance. The balancer in
front asks a special port on each node periodically. If we want to
remove a node from the cluster, we switch off this port. The
loadbalancer can't connect to it and marks the node as down. But we
don't move the sessions to another node. In this environment it is an
error if the balancer sends a request without a session to an
apache+mod_jk+tomcat which port is switched off. And if the load
balancer determines that a node is down no other node is allowed to send
a request without a session to it. Only requests with old sessions on
the switched off node would be routed to this node. After some time
nobody uses the old sessions and the sessions will time out. Then nobody
uses this node, because all session are gone and the node is unreachable
without a session-id in the request. If someone uses a session which
timed out, our servlet system sends a redirect response without a
session id to the browser. This is necessary for me, because on a
switched off node apache and tomcat can still be up and running, but
they are in an old state and should only be asked for valid old
sessions. After the last session timed out, I could update the node etc.
without killing sessions or moving them to another node. Sometimes we
have a lot of big objects in our sessions, so it would be really time
consuming to move them.'
My reading of this is that I can dynamically tell TC to stop accepting
new sessions. It will notify mod_jk and thenceforth only requests
already bound to existing sessions hosted in this TC instance will be
forwarded from mod_jk.
I have scoured the web, mailing list archives and src code, most likely
with the wrong keywords, trying to find references explaining, how I can
tell TC that I want to bleed the existing sessions off it, using this
functionality.
I understand and use the support for session affinity via jvmRoute and
other worker properties. I would now like to extend what I have to
support the graceful shutdown on TC nodes without the loss of session
data. I do not want to persist or otherwise distribute these sessions.
Can anyone point me in the right direction ?
Thanks for your time,
Jules
------------------------------
This e-mail is intended for the named addressee only. It may contain
confidential and/or privileged information. If you have received this
message in error, please let us know and then delete this message from your
system. You should not copy the message, use it for any purpose or disclose
its contents to anyone.
________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org