Re: Is it possible to expire jvmRoute cookie
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Konstantin,
On 12/9/12 4:20 PM, Konstantin Kolinko wrote:
2012/12/7 Christopher Schultz ch...@christopherschultz.net:
On 12/7/12 4:16 AM, André Warnier wrote:
Williams, Nick wrote:
-Original Message- From: Christopher Schultz
(...)
Earlier somebody (I'm sorry, I already deleted the email)
suggested Tomcat returning a 308 or 309 or similar to the
load balancer to trigger a re-balance if the session is
expired. I think this is the best idea I've heard yet, solves
the problem elegantly and simply, and seems (relatively) easy
to achieve (this coming from someone who has no knowledge of
the code used by mod_jk/isapi_redirector).
I must admit that this sounds more elegant (and efficient) than
my suggested interceptor module.
Alternatively, if one wanted to avoid touching mod_jk for
this, maybe tomcat could return a 302 redirect to the starting
page of this application, if known ? (without
jsessionid.jvmroute of course).
That's definitely an idea worth pursuing: an expired session id
could return 302 *and* strip the jsessionid path parameter *and*
send a Set-Cookie JSESSIONID; expiration=0 header (which deletes
the cookie). The client would re-try and the balancer would
re-balance.
Konstantin, what do you think? Obviously, this shouldn't be the
default operation of Tomcat, but perhaps a setting that could be
enabled on the session manager?
If anybody want to experiment with such a feature, it is easy to
write your own Filter or Valve that implements this.
Something like if (request.getSession(false) == null
request.getRequestedSessionId() != null) {
response.sendRedirect(...); return; }
Can you see a reason not to delete the JSESSIONID cookie and
explicitly remove the ;jsessionid parameter at this point? I believe
if we don't do that, we'll end up in a redirect loop.
Things to be cautious 1. Different web applications may have
different session ids. When a browser sends us the session id
cookie, there is no indication to what web application it belongs.
If the Valve is configured at the Engine or Host level, will the call
to getSession know what webapp's session should be fetched? Obviously,
Tomcat figures this out eventually, but I was wondering if that
resolution has been done before the host- or engine-level valves are
invoked.
2. I would check the value of request.getMethod().
Yes. Redirecting PUT, POST, etc. can be ... problematic.
3. I would do nothing if jvmRoute in requested session id belongs
to a different server.
+1
See also org.apache.catalina.ha.session.JvmRouteBinderValve,
http://tomcat.apache.org/tomcat-7.0-doc/config/cluster-valve.html
I think that may be the right place for this to ultimately live, but
developing separately probably makes sense for now.
Mitchell, would you be willing to test a few proofs-of-concept if we
build them?
Thanks,
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEAREIAAYFAlDF+E4ACgkQ9CaO5/Lv0PC4jACgnQ1t/d4WBDc9B4iruRNFu+xU
IPMAmgMmGBNzmJPQw3fww31L6XKcWN42
=Fp1q
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is it possible to expire jvmRoute cookie
2012/12/10 Christopher Schultz ch...@christopherschultz.net: If the Valve is configured at the Engine or Host level, will the call to getSession know what webapp's session should be fetched? Obviously, Tomcat figures this out eventually, but I was wondering if that resolution has been done before the host- or engine-level valves are invoked. The Context to which the request maps to is known from requestURI + mapper. (Regardless of where the valve is configured). See also org.apache.catalina.ha.session.JvmRouteBinderValve, http://tomcat.apache.org/tomcat-7.0-doc/config/cluster-valve.html I think that may be the right place for this to ultimately live, but developing separately probably makes sense for now. I do not think such feature belongs to Tomcat itself. I think it'd be better to do at the balancer (to ignore jvmRoute occasionally). If balancer sends request to a different Tomcat, tomcat can deal with it thanks to JvmRouteBinderValve and like it deals with the usual fail-over scenario. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is it possible to expire jvmRoute cookie
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Konstantin, On 12/10/12 3:37 PM, Konstantin Kolinko wrote: 2012/12/10 Christopher Schultz ch...@christopherschultz.net: If the Valve is configured at the Engine or Host level, will the call to getSession know what webapp's session should be fetched? Obviously, Tomcat figures this out eventually, but I was wondering if that resolution has been done before the host- or engine-level valves are invoked. The Context to which the request maps to is known from requestURI + mapper. (Regardless of where the valve is configured). Great, thanks. See also org.apache.catalina.ha.session.JvmRouteBinderValve, http://tomcat.apache.org/tomcat-7.0-doc/config/cluster-valve.html I think that may be the right place for this to ultimately live, but developing separately probably makes sense for now. I do not think such feature belongs to Tomcat itself. I think it'd be better to do at the balancer (to ignore jvmRoute occasionally). The problem is that the balancer (e.g. mod_jk) doesn't know if the session id is valid without forwarding it to the Tomcat instance with the specified jvmroute. If you haven't already done so, please take a quick look back at the earlier posts in this thread to see the evolution of this proposal. Briefly, we were looking for something that would not require any changes to the balancer software (specifically, mod_jk and mod_proxy_ajp) so that it could be fixed in one version of one product (Tomcat). Fixing this in the balancer would require either a) a ping-style session-checking message to be designed and implemented in both the balancer and Tomcat or b) a custom HTTP response code from Tomcat that would trigger a re-balance at the balancer level. I'm sure there are other possibilities, but these were the ones I initially proposed. If balancer sends request to a different Tomcat, tomcat can deal with it thanks to JvmRouteBinderValve and like it deals with the usual fail-over scenario. Of course. The Tomcat that eventually receives the (possibly re-balanced) request should not behave any differently than now. Thanks, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEAREIAAYFAlDGYfMACgkQ9CaO5/Lv0PDwtgCgj478uOry6qn3rBsGPzyZ5vAH FvoAoLa+9iccQ6OE4+Sa02kBdQFotU+g =GyP4 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is it possible to expire jvmRoute cookie
2012/12/7 Christopher Schultz ch...@christopherschultz.net:
On 12/7/12 4:16 AM, André Warnier wrote:
Williams, Nick wrote:
-Original Message- From: Christopher Schultz
(...)
Earlier somebody (I'm sorry, I already deleted the email)
suggested Tomcat returning a 308 or 309 or similar to the load
balancer to trigger a re-balance if the session is expired. I
think this is the best idea I've heard yet, solves the problem
elegantly and simply, and seems (relatively) easy to achieve
(this coming from someone who has no knowledge of the code used
by mod_jk/isapi_redirector).
I must admit that this sounds more elegant (and efficient) than my
suggested interceptor module.
Alternatively, if one wanted to avoid touching mod_jk for this,
maybe tomcat could return a 302 redirect to the starting page of
this application, if known ? (without jsessionid.jvmroute of
course).
That's definitely an idea worth pursuing: an expired session id could
return 302 *and* strip the jsessionid path parameter *and* send a
Set-Cookie JSESSIONID; expiration=0 header (which deletes the cookie).
The client would re-try and the balancer would re-balance.
Konstantin, what do you think? Obviously, this shouldn't be the
default operation of Tomcat, but perhaps a setting that could be
enabled on the session manager?
If anybody want to experiment with such a feature,
it is easy to write your own Filter or Valve that implements this.
Something like
if (request.getSession(false) == null
request.getRequestedSessionId() != null) {
response.sendRedirect(...);
return;
}
Things to be cautious
1. Different web applications may have different session ids. When a
browser sends us the session id cookie, there is no indication to what
web application it belongs.
2. I would check the value of request.getMethod().
3. I would do nothing if jvmRoute in requested session id belongs to a
different server.
See also org.apache.catalina.ha.session.JvmRouteBinderValve,
http://tomcat.apache.org/tomcat-7.0-doc/config/cluster-valve.html
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is it possible to expire jvmRoute cookie
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 12/6/12 2:40 PM, André Warnier wrote: Christopher Schultz wrote: Yes, but session cookies typically have an expiration of -1 which means when the browser exits. Never exiting the browser has predicable consequences, here. So for this case, the solution would consist in setting a timeout for the cookie. Since the container (generally) manages the cookie timeout, most applications don't ever directly touch the JSESSIONID cookie or its timeout. If the cookie times out, the browser will not send it anymore when the user comes back, mod_jk will route this to any tomcat, which will start a new session and set a new cookie. CQFD. That is true, but it would be a shame for the cookie to time out before the (server-side) session was actually destroyed. I think this is a legitimate gripe. - if it is appended at the end of the URL, then how could the server get rid of it (in the browser's displayed page) ? Set a new value for the JSESSIONID cookie. Well no, not in this case. (Sorry, I just noticed that you said at the end of the URL. I was still thinking about cookies. If the jsessionid is in the browser, you'll have to redirect the client with a different (or missing) jsessionid parameter. The OP says : because the previous user does not close his browser, walks away for a while to have a drink, and comes back. In the meantime, the session has expired but the old page containing the URL links with the expired jsessionid.jvmroute tagged at the end is still there, sitting in the browser's window.. So now the user clicks on a link of that old page, which sends a request to the server, with the expired session-id. But because of the tagged-on old jvmroute, mod_jk sends it through to the same tomcat as before. Which is what he is trying to prevent. Until now, Tomcat hasn't sent anything, so it had no opportunity to set a new jsessionid. Right. Honestly, the same is true for the cookie situation: Tomcat had no initial opportunity. My question was thus : how can one even imagine to have tomcat or mod_jk or Apache httpd go clear these links (with the expired jsessionid.jvmroute) out of the browser's currently displayed page, when the session times out. Obviously they can't. Right, they can't. My suggestion is an invalid-session event to trigger a re-balance at the mod_jk (or mod_proxy_ajp) level. If Tomcat can use some obscure response code (306? 308/9?), perhaps that could trigger a re-balance in httpd. When such a re-balance happens, the new backend server would ignore both the cookie and the jsessionid (because the jvmroute does not match the current server) and produce a response with a new Set-Cookie and re-written URLs (if appropriate). Just tell me : if I happened to know the session-id and the jvmroute, would there be any request which I could send to Tomcat, which would not have any non-idempotent effect, and which would tell me if that session is still valid ? AFAIK, Tomcat does not have a ping operation for a session. If you make a request that touches the session, you'll freshen the last-used timestamp and extend the life of the session. You must have read enough I have a javascript ping to check my session status on the server, and no my sessions never expire! posts on the list to be aware of this. (On second thought, of course there would : one could just build one into the application). That might get tricky. I'm not sure if you can even ask Tomcat if the session is valid without it updating the last-touched time and extending the life of the session (which I believe is *not* what you want, here). You are going to force me to disclose the details, and thus maybe lose my patenting opportunity, but oh well. I am not thinking of a regular ping which would run independently. What I am thinking of is this : - the front-end httpd server intercepts all requests for this application early (before mod_jk gets to see them). That's not a problem. - the interceptor at the front-end retrieves the jsession.jvmroute from the URL (or even the cookie), and reformulates a request to tomcat, substituting the real application path by the path of a ping responder servlet within the target application, adding the jsessionid.jvmroute back into this new path. It then makes an (internal) request to this URL. (In the meantime, the original request is held; that's not a problem either). - the (internal, secondary) request is handled normally, goes to mod_jk, who forwards it normally to tomcat according to the jvmroute. - the response from tomcat is either - a) a normal response, if that session was still alive and well - b) a session expired response (probably a login page or whatever, but in any case with a new session-id which doesn't match the original) - this response goes back to the interceptor module in httpd, which gets a chance to examine it. - if the response is (a), then the
Re: Is it possible to expire jvmRoute cookie
Williams, Nick wrote: -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Thursday, December 06, 2012 5:08 PM To: Tomcat Users List Subject: Re: Is it possible to expire jvmRoute cookie 2. How one additional user can be a problem in such a system? If he accesses a heavy-loaded system the things will be slow for him, but faster for all others, who close their browsers regularly. Let's take a pathological example: Assumptions: 1. Cluster has 3 nodes (A, B, C) 2. Users never close their browsers Let's say that server A is rock-solid and never goes down. Servers B and C are running Gentoo Linux or Debian Sid or Microsoft Windows or have flaky hardware and so they crash or need to be rebooted all the time; perhaps daily. Users on nodes B and C will constantly fail-over to node A. Those users will stick on node A pretty much forever. Therefore node A always gets most of the traffic, and nodes B and C only get new users for a while before failing-over. Even if nodes B and C can handle 1/3 of the load, they will get much less than that, and node A will, over time, accumulate users without bound. It would be nice to avoid this kind of situation. So one could recommend that if things go slow to close one's browser, clean caches, or even reboot. ;) If I called tech support for a website and they told me I needed to close my browser or reboot my computer to just to use their website, I would assume that they were complete idiots. If I want to be lied to about what the problem is, I'll call my home broadband provider. -- HAHAHA ... nice one. I agree with Chris, here. It's not a common situation, but it is a possible situation, and if it occurred, it could get ugly quickly. Earlier somebody (I'm sorry, I already deleted the email) suggested Tomcat returning a 308 or 309 or similar to the load balancer to trigger a re-balance if the session is expired. I think this is the best idea I've heard yet, solves the problem elegantly and simply, and seems (relatively) easy to achieve (this coming from someone who has no knowledge of the code used by mod_jk/isapi_redirector). I must admit that this sounds more elegant (and efficient) than my suggested interceptor module. Alternatively, if one wanted to avoid touching mod_jk for this, maybe tomcat could return a 302 redirect to the starting page of this application, if known ? (without jsessionid.jvmroute of course). - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is it possible to expire jvmRoute cookie
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 12/7/12 3:51 AM, André Warnier wrote: You are going to force me to disclose the details, and thus maybe lose my patenting opportunity, but oh well. I am not thinking of a regular ping which would run independently. What I am thinking of is this : - the front-end httpd server intercepts all requests for this application early (before mod_jk gets to see them). That's not a problem. - the interceptor at the front-end retrieves the jsession.jvmroute from the URL (or even the cookie), and reformulates a request to tomcat, substituting the real application path by the path of a ping responder servlet within the target application, adding the jsessionid.jvmroute back into this new path. It then makes an (internal) request to this URL. (In the meantime, the original request is held; that's not a problem either). I knew this was what you were talking about. I was suggesting that such a technique would be needlessly complex and would reduce performance. Since session expired is an exception case, it should be treated as such instead of as the norm. Tomcat can barf somewhat normally when a session has expired and mod_jk can take appropriate action. Namely: re-balance the request (if you'll allow such a loose term) and strip the session id from the re-balanced request as it goes to a (potentially different) back-end Tomcat. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEAREIAAYFAlDCH6UACgkQ9CaO5/Lv0PDMoQCcC4nFzqLqR0DDHXz40oL2VFO1 bL0Ani/DUcUGqrHNOXSN4kdlLJmPmnJ7 =73HZ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is it possible to expire jvmRoute cookie
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 12/7/12 4:16 AM, André Warnier wrote: Williams, Nick wrote: -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Thursday, December 06, 2012 5:08 PM To: Tomcat Users List Subject: Re: Is it possible to expire jvmRoute cookie 2. How one additional user can be a problem in such a system? If he accesses a heavy-loaded system the things will be slow for him, but faster for all others, who close their browsers regularly. Let's take a pathological example: Assumptions: 1. Cluster has 3 nodes (A, B, C) 2. Users never close their browsers Let's say that server A is rock-solid and never goes down. Servers B and C are running Gentoo Linux or Debian Sid or Microsoft Windows or have flaky hardware and so they crash or need to be rebooted all the time; perhaps daily. Users on nodes B and C will constantly fail-over to node A. Those users will stick on node A pretty much forever. Therefore node A always gets most of the traffic, and nodes B and C only get new users for a while before failing-over. Even if nodes B and C can handle 1/3 of the load, they will get much less than that, and node A will, over time, accumulate users without bound. It would be nice to avoid this kind of situation. So one could recommend that if things go slow to close one's browser, clean caches, or even reboot. ;) If I called tech support for a website and they told me I needed to close my browser or reboot my computer to just to use their website, I would assume that they were complete idiots. If I want to be lied to about what the problem is, I'll call my home broadband provider. -- HAHAHA ... nice one. I agree with Chris, here. It's not a common situation, but it is a possible situation, and if it occurred, it could get ugly quickly. Earlier somebody (I'm sorry, I already deleted the email) suggested Tomcat returning a 308 or 309 or similar to the load balancer to trigger a re-balance if the session is expired. I think this is the best idea I've heard yet, solves the problem elegantly and simply, and seems (relatively) easy to achieve (this coming from someone who has no knowledge of the code used by mod_jk/isapi_redirector). I must admit that this sounds more elegant (and efficient) than my suggested interceptor module. Alternatively, if one wanted to avoid touching mod_jk for this, maybe tomcat could return a 302 redirect to the starting page of this application, if known ? (without jsessionid.jvmroute of course). That's definitely an idea worth pursuing: an expired session id could return 302 *and* strip the jsessionid path parameter *and* send a Set-Cookie JSESSIONID; expiration=0 header (which deletes the cookie). The client would re-try and the balancer would re-balance. Konstantin, what do you think? Obviously, this shouldn't be the default operation of Tomcat, but perhaps a setting that could be enabled on the session manager? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEAREIAAYFAlDCIF4ACgkQ9CaO5/Lv0PDJoACgw9Ys1rnye8NK24fFCtZ6x8Dj PKwAn0kws7TwyT6T4qURPbq3vtkXjxWI =2vJC -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is it possible to expire jvmRoute cookie
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 12/7/12 4:16 AM, André Warnier wrote: Williams, Nick wrote: -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Thursday, December 06, 2012 5:08 PM To: Tomcat Users List Subject: Re: Is it possible to expire jvmRoute cookie 2. How one additional user can be a problem in such a system? If he accesses a heavy-loaded system the things will be slow for him, but faster for all others, who close their browsers regularly. Let's take a pathological example: Assumptions: 1. Cluster has 3 nodes (A, B, C) 2. Users never close their browsers Let's say that server A is rock-solid and never goes down. Servers B and C are running Gentoo Linux or Debian Sid or Microsoft Windows or have flaky hardware and so they crash or need to be rebooted all the time; perhaps daily. Users on nodes B and C will constantly fail-over to node A. Those users will stick on node A pretty much forever. Therefore node A always gets most of the traffic, and nodes B and C only get new users for a while before failing-over. Even if nodes B and C can handle 1/3 of the load, they will get much less than that, and node A will, over time, accumulate users without bound. It would be nice to avoid this kind of situation. So one could recommend that if things go slow to close one's browser, clean caches, or even reboot. ;) If I called tech support for a website and they told me I needed to close my browser or reboot my computer to just to use their website, I would assume that they were complete idiots. If I want to be lied to about what the problem is, I'll call my home broadband provider. -- HAHAHA ... nice one. I agree with Chris, here. It's not a common situation, but it is a possible situation, and if it occurred, it could get ugly quickly. Earlier somebody (I'm sorry, I already deleted the email) suggested Tomcat returning a 308 or 309 or similar to the load balancer to trigger a re-balance if the session is expired. I think this is the best idea I've heard yet, solves the problem elegantly and simply, and seems (relatively) easy to achieve (this coming from someone who has no knowledge of the code used by mod_jk/isapi_redirector). I must admit that this sounds more elegant (and efficient) than my suggested interceptor module. Alternatively, if one wanted to avoid touching mod_jk for this, maybe tomcat could return a 302 redirect to the starting page of this application, if known ? (without jsessionid.jvmroute of course). That's definitely an idea worth pursuing: an expired session id could return 302 *and* strip the jsessionid path parameter *and* send a Set-Cookie JSESSIONID; expiration=0 header (which deletes the cookie). The client would re-try and the balancer would re-balance. Konstantin, what do you think? Obviously, this shouldn't be the default operation of Tomcat, but perhaps a setting that could be enabled on the session manager? By the way, that should work with mod_proxy_ajp too, which I suppose has a similar behaviour. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Is it possible to expire jvmRoute cookie
Hi, I have a jvmRoute appended to my JSESSIONID to enable sticky sessions at an application level. I see often that users do not close browsers, resulting (even if the tomcat session has expired) the user to be forwarded back to the instance. Is it possible to set an expiry for the jvmRoute / JSESSIONID to be expired at the browser so after x amount of time since last request the jvmRoute is not transmitted back to the application apache load balancer. This would prevent users constantly being directed to the same application node. Regards -- *Mitchell * The information contained in this email (and any attachments) is confidential and may be privileged. If you are not the intended recipient and have received this email in error, please notify the sender immediately by reply email and delete the message and any attachments. If you are not the named addressee, you must not copy, disclose, forward or otherwise use the information contained in this email. Cable Wireless Communications Plc and its affiliates reserve the right to monitor all email communications through their networks to ensure regulatory compliance. Cable Wireless Communications Plc is a company registered in England Wales with number: 07130199 and offices located at 3rd Floor, 26 Red Lion Square, London WC1R 4HQ
Re: Is it possible to expire jvmRoute cookie
Smith, Mitchell wrote: Hi, I have a jvmRoute appended to my JSESSIONID to enable sticky sessions at an application level. I see often that users do not close browsers, resulting (even if the tomcat session has expired) the user to be forwarded back to the instance. Is it possible to set an expiry for the jvmRoute / JSESSIONID to be expired at the browser so after x amount of time since last request the jvmRoute is not transmitted back to the application apache load balancer. This would prevent users constantly being directed to the same application node. Could you suggest a mechanism by which this would be possible ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is it possible to expire jvmRoute cookie
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mitchell, On 12/6/12 9:48 AM, Smith, Mitchell wrote: I have a jvmRoute appended to my JSESSIONID to enable sticky sessions at an application level. I see often that users do not close browsers, resulting (even if the tomcat session has expired) the user to be forwarded back to the instance. Is it possible to set an expiry for the jvmRoute / JSESSIONID to be expired at the browser so after x amount of time since last request the jvmRoute is not transmitted back to the application apache load balancer. This would prevent users constantly being directed to the same application node. While I'm not sure if there is actually a way to do this, it's an interesting problem I'd never considered: once mod_jk picks a jvmroute for you, you may be stuck there for a looong time if you never close your browser. I never close my browser. It's been running since Monday morning (okay, bad example -- because I upgraded my Firefox and it did a restart for that). But it's not uncommon for me to leave the browser running for the entire interval between releases of Firefox. When Firefox restarts itself, it actually does not expire cookies that should expire when the browser closes. So, unless I explicitly close Firefox (which happens, sometimes, accidentally since CMD-Q and CMD-W are /right next to each other/ and ff/Mac doesn't have any such you want to close all those tabs and windows? confirmation) or maybe if it crashes, I'll be stuck on a particular node every time I visit a site. Hrm. I'd be interested in any thoughts Rainer might have about this. AFAIK, a Tomcat node that gets a request with an invalid session id will simply ignore it. If a new session is required, then the old session id will be replaced with the new one (including the same jvmroute that was already attached to the session id), but everything happens on that one Tomcat node. I think the only way this might work would be to have Tomcat reply to an AJP connection with an invalid session id with a response like INVALID SESSION ID and then mod_jk could through its normal decision about which balanced worker would be chosen for the request. That seems like an awful lot of work, but it /would/ restore fairness to the system. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEUEARECAAYFAlDAuGgACgkQ9CaO5/Lv0PApygCXcrQm0wagXXMdmnEnnhB74KBO hgCgodzhNm7XjfiBBWduiItWjNELOnc= =16PP -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is it possible to expire jvmRoute cookie
Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mitchell,
On 12/6/12 9:48 AM, Smith, Mitchell wrote:
I have a jvmRoute appended to my JSESSIONID to enable sticky
sessions at an application level.
I see often that users do not close browsers, resulting (even if
the tomcat session has expired) the user to be forwarded back to
the instance.
Is it possible to set an expiry for the jvmRoute / JSESSIONID to be
expired at the browser so after x amount of time since last request
the jvmRoute is not transmitted back to the application apache load
balancer. This would prevent users constantly being directed to the
same application node.
While I'm not sure if there is actually a way to do this, it's an
interesting problem I'd never considered: once mod_jk picks a jvmroute
for you, you may be stuck there for a looong time if you never close
your browser.
I never close my browser. It's been running since Monday morning
(okay, bad example -- because I upgraded my Firefox and it did a
restart for that). But it's not uncommon for me to leave the browser
running for the entire interval between releases of Firefox. When
Firefox restarts itself, it actually does not expire cookies that
should expire when the browser closes.
So, unless I explicitly close Firefox (which happens, sometimes,
accidentally since CMD-Q and CMD-W are /right next to each other/ and
ff/Mac doesn't have any such you want to close all those tabs and
windows? confirmation) or maybe if it crashes, I'll be stuck on a
particular node every time I visit a site.
Hrm.
I'd be interested in any thoughts Rainer might have about this.
AFAIK, a Tomcat node that gets a request with an invalid session id
will simply ignore it. If a new session is required, then the old
session id will be replaced with the new one (including the same
jvmroute that was already attached to the session id), but everything
happens on that one Tomcat node.
I think the only way this might work would be to have Tomcat reply to
an AJP connection with an invalid session id with a response like
INVALID SESSION ID and then mod_jk could through its normal decision
about which balanced worker would be chosen for the request.
That seems like an awful lot of work, but it /would/ restore
fairness to the system.
Chris,
Before I read your answer, I would have been ready to bet that the OP's question was
nonsensical, in the sense that :
- the sticky identifier is either included in the JSESSIONID cookie, or appended
together with the JSESSIONID, to the request URLs, right ? (or wrong ?)
- if it is in the cookie, then it would expire at the same time as the cookie
- if it is appended at the end of the URL, then how could the server get rid of it (in the
browser's displayed page) ?
But you seem to hint otherwise, so now I doubt.
And then, there is this :
The environment variable JK_STICKY_IGNORE can be set to disable session stickyness for
individual requests. If the variable is set to an empty string or a nonzero number,
session stickyness will be disabled. Setting it to 0 will reset to the behaviour defined
by the worker configuration. This is available since version 1.2.33.
Re: http://tomcat.apache.org/connectors-doc/reference/apache.html
So, if push comes to shove, one could supposedly embed some logic on the front-end server,
to set/unset that variable prior to letting mod_jk see the call.
I'd do that with a nifty mod_perl module of course, if I could figure out how to test for
the right condition..
SetEnvIf %{THE_USER_WALKED_AWAY_WITHOUT_CLOSING_HIS_BROWSER} yes
JK_STICKY_IGNORE=yes
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is it possible to expire jvmRoute cookie
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
André,
On 12/6/12 10:53 AM, André Warnier wrote:
Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
Mitchell,
On 12/6/12 9:48 AM, Smith, Mitchell wrote:
I have a jvmRoute appended to my JSESSIONID to enable sticky
sessions at an application level.
I see often that users do not close browsers, resulting (even
if the tomcat session has expired) the user to be forwarded
back to the instance.
Is it possible to set an expiry for the jvmRoute / JSESSIONID
to be expired at the browser so after x amount of time since
last request the jvmRoute is not transmitted back to the
application apache load balancer. This would prevent users
constantly being directed to the same application node.
While I'm not sure if there is actually a way to do this, it's
an interesting problem I'd never considered: once mod_jk picks a
jvmroute for you, you may be stuck there for a looong time if you
never close your browser.
I never close my browser. It's been running since Monday morning
(okay, bad example -- because I upgraded my Firefox and it did a
restart for that). But it's not uncommon for me to leave the
browser running for the entire interval between releases of
Firefox. When Firefox restarts itself, it actually does not
expire cookies that should expire when the browser closes.
So, unless I explicitly close Firefox (which happens, sometimes,
accidentally since CMD-Q and CMD-W are /right next to each other/
and ff/Mac doesn't have any such you want to close all those
tabs and windows? confirmation) or maybe if it crashes, I'll be
stuck on a particular node every time I visit a site.
Hrm.
I'd be interested in any thoughts Rainer might have about this.
AFAIK, a Tomcat node that gets a request with an invalid session
id will simply ignore it. If a new session is required, then the
old session id will be replaced with the new one (including the
same jvmroute that was already attached to the session id), but
everything happens on that one Tomcat node.
I think the only way this might work would be to have Tomcat
reply to an AJP connection with an invalid session id with a
response like INVALID SESSION ID and then mod_jk could through
its normal decision about which balanced worker would be chosen
for the request.
That seems like an awful lot of work, but it /would/ restore
fairness to the system.
Chris,
Before I read your answer, I would have been ready to bet that the
OP's question was nonsensical, in the sense that : - the sticky
identifier is either included in the JSESSIONID cookie, or
appended together with the JSESSIONID, to the request URLs, right
? (or wrong ?)
Yes: a session id in a sticky-session configuration will have a
JSESSIONID cookie whose value looks like 0123456789ABCDEF.jvmRoute.
If the jvmroute is tacked-on to the end of the JSESSIONID, mod_jk will
route the request to the worker who has that route as long as that
balanced-worker is considered up.
- if it is in the cookie, then it would expire at the same time as
the cookie
Yes, but session cookies typically have an expiration of -1 which
means when the browser exits. Never exiting the browser has
predicable consequences, here.
- if it is appended at the end of the URL, then how could the
server get rid of it (in the browser's displayed page) ?
Set a new value for the JSESSIONID cookie.
And then, there is this :
The environment variable JK_STICKY_IGNORE can be set to disable
session stickyness for individual requests. If the variable is set
to an empty string or a nonzero number, session stickyness will be
disabled. Setting it to 0 will reset to the behaviour defined by
the worker configuration. This is available since version 1.2.33.
Re: http://tomcat.apache.org/connectors-doc/reference/apache.html
Interesting -- I was unaware of that feature. Presumably that allows a
configuration coupled with, say, SetEnvIf using the JK_STICKY_IGNORE
under certain circumstances.
So, if push comes to shove, one could supposedly embed some logic
on the front-end server, to set/unset that variable prior to
letting mod_jk see the call.
Right, but the only way to tell if the session id is legit is to ask
Tomcat. It's probably cheaper to blindly forward to Tomcat and have
Tomcat take some exception scenario in the cases where the session id
is no longer valid than it would be to ping a back-end server to see
if the session id is valid. The former is what I've described above.
I'd do that with a nifty mod_perl module of course, if I could
figure out how to test for the right condition..
SetEnvIf %{THE_USER_WALKED_AWAY_WITHOUT_CLOSING_HIS_BROWSER} yes
JK_STICKY_IGNORE=yes
That's just the kind of magic Perl was designed to accomplish.
You will, of course, need to add use Pid::CrystalBall; at the top of
the script.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Re: Is it possible to expire jvmRoute cookie
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 12/6/12 10:53 AM, André Warnier wrote: Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mitchell, On 12/6/12 9:48 AM, Smith, Mitchell wrote: I have a jvmRoute appended to my JSESSIONID to enable sticky sessions at an application level. I see often that users do not close browsers, resulting (even if the tomcat session has expired) the user to be forwarded back to the instance. Is it possible to set an expiry for the jvmRoute / JSESSIONID to be expired at the browser so after x amount of time since last request the jvmRoute is not transmitted back to the application apache load balancer. This would prevent users constantly being directed to the same application node. While I'm not sure if there is actually a way to do this, it's an interesting problem I'd never considered: once mod_jk picks a jvmroute for you, you may be stuck there for a looong time if you never close your browser. I never close my browser. It's been running since Monday morning (okay, bad example -- because I upgraded my Firefox and it did a restart for that). But it's not uncommon for me to leave the browser running for the entire interval between releases of Firefox. When Firefox restarts itself, it actually does not expire cookies that should expire when the browser closes. So, unless I explicitly close Firefox (which happens, sometimes, accidentally since CMD-Q and CMD-W are /right next to each other/ and ff/Mac doesn't have any such you want to close all those tabs and windows? confirmation) or maybe if it crashes, I'll be stuck on a particular node every time I visit a site. Hrm. I'd be interested in any thoughts Rainer might have about this. AFAIK, a Tomcat node that gets a request with an invalid session id will simply ignore it. If a new session is required, then the old session id will be replaced with the new one (including the same jvmroute that was already attached to the session id), but everything happens on that one Tomcat node. I think the only way this might work would be to have Tomcat reply to an AJP connection with an invalid session id with a response like INVALID SESSION ID and then mod_jk could through its normal decision about which balanced worker would be chosen for the request. That seems like an awful lot of work, but it /would/ restore fairness to the system. Chris, Before I read your answer, I would have been ready to bet that the OP's question was nonsensical, in the sense that : - the sticky identifier is either included in the JSESSIONID cookie, or appended together with the JSESSIONID, to the request URLs, right ? (or wrong ?) Yes: a session id in a sticky-session configuration will have a JSESSIONID cookie whose value looks like 0123456789ABCDEF.jvmRoute. If the jvmroute is tacked-on to the end of the JSESSIONID, mod_jk will route the request to the worker who has that route as long as that balanced-worker is considered up. - if it is in the cookie, then it would expire at the same time as the cookie Yes, but session cookies typically have an expiration of -1 which means when the browser exits. Never exiting the browser has predicable consequences, here. So for this case, the solution would consist in setting a timeout for the cookie. If the cookie times out, the browser will not send it anymore when the user comes back, mod_jk will route this to any tomcat, which will start a new session and set a new cookie. CQFD. - if it is appended at the end of the URL, then how could the server get rid of it (in the browser's displayed page) ? Set a new value for the JSESSIONID cookie. Well no, not in this case. The OP says : because the previous user does not close his browser, walks away for a while to have a drink, and comes back. In the meantime, the session has expired but the old page containing the URL links with the expired jsessionid.jvmroute tagged at the end is still there, sitting in the browser's window.. So now the user clicks on a link of that old page, which sends a request to the server, with the expired session-id. But because of the tagged-on old jvmroute, mod_jk sends it through to the same tomcat as before. Which is what he is trying to prevent. Until now, Tomcat hasn't sent anything, so it had no opportunity to set a new jsessionid. My question was thus : how can one even imagine to have tomcat or mod_jk or Apache httpd go clear these links (with the expired jsessionid.jvmroute) out of the browser's currently displayed page, when the session times out. Obviously they can't. And then, there is this : The environment variable JK_STICKY_IGNORE can be set to disable session stickyness for individual requests. If the variable is set to an empty string or a nonzero number, session stickyness will be disabled. Setting it to 0 will reset to the behaviour defined by the worker configuration. This is available since version
Re: Is it possible to expire jvmRoute cookie
2012/12/6 Smith, Mitchell mitchell.sm...@cwc.com: I have a jvmRoute appended to my JSESSIONID to enable sticky sessions at an application level. I see often that users do not close browsers, resulting (even if the tomcat session has expired) the user to be forwarded back to the instance. Is it possible to set an expiry for the jvmRoute / JSESSIONID to be expired at the browser so after x amount of time since last request the jvmRoute is not transmitted back to the application apache load balancer. This would prevent users constantly being directed to the same application node. 1. Even if one can set expiration time for the session cookie (configurable in a Servlet 3.0 compliant application), you cannot do anything if somebody publishes a link containing a jsessionid in it somewhere, e.g. on a forum. What I can think of is to make the jvmroute itself temporary e.g. by changing it periodically. 2. How one additional user can be a problem in such a system? If he accesses a heavy-loaded system the things will be slow for him, but faster for all others, who close their browsers regularly. So one could recommend that if things go slow to close one's browser, clean caches, or even reboot. ;) Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is it possible to expire jvmRoute cookie
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 12/6/12 2:40 PM, André Warnier wrote: Christopher Schultz wrote: Yes, but session cookies typically have an expiration of -1 which means when the browser exits. Never exiting the browser has predicable consequences, here. So for this case, the solution would consist in setting a timeout for the cookie. Since the container (generally) manages the cookie timeout, most applications don't ever directly touch the JSESSIONID cookie or its timeout. If the cookie times out, the browser will not send it anymore when the user comes back, mod_jk will route this to any tomcat, which will start a new session and set a new cookie. CQFD. That is true, but it would be a shame for the cookie to time out before the (server-side) session was actually destroyed. I think this is a legitimate gripe. - if it is appended at the end of the URL, then how could the server get rid of it (in the browser's displayed page) ? Set a new value for the JSESSIONID cookie. Well no, not in this case. (Sorry, I just noticed that you said at the end of the URL. I was still thinking about cookies. If the jsessionid is in the browser, you'll have to redirect the client with a different (or missing) jsessionid parameter. The OP says : because the previous user does not close his browser, walks away for a while to have a drink, and comes back. In the meantime, the session has expired but the old page containing the URL links with the expired jsessionid.jvmroute tagged at the end is still there, sitting in the browser's window.. So now the user clicks on a link of that old page, which sends a request to the server, with the expired session-id. But because of the tagged-on old jvmroute, mod_jk sends it through to the same tomcat as before. Which is what he is trying to prevent. Until now, Tomcat hasn't sent anything, so it had no opportunity to set a new jsessionid. Right. Honestly, the same is true for the cookie situation: Tomcat had no initial opportunity. My question was thus : how can one even imagine to have tomcat or mod_jk or Apache httpd go clear these links (with the expired jsessionid.jvmroute) out of the browser's currently displayed page, when the session times out. Obviously they can't. Right, they can't. My suggestion is an invalid-session event to trigger a re-balance at the mod_jk (or mod_proxy_ajp) level. If Tomcat can use some obscure response code (306? 308/9?), perhaps that could trigger a re-balance in httpd. When such a re-balance happens, the new backend server would ignore both the cookie and the jsessionid (because the jvmroute does not match the current server) and produce a response with a new Set-Cookie and re-written URLs (if appropriate). Just tell me : if I happened to know the session-id and the jvmroute, would there be any request which I could send to Tomcat, which would not have any non-idempotent effect, and which would tell me if that session is still valid ? AFAIK, Tomcat does not have a ping operation for a session. If you make a request that touches the session, you'll freshen the last-used timestamp and extend the life of the session. You must have read enough I have a javascript ping to check my session status on the server, and no my sessions never expire! posts on the list to be aware of this. (On second thought, of course there would : one could just build one into the application). That might get tricky. I'm not sure if you can even ask Tomcat if the session is valid without it updating the last-touched time and extending the life of the session (which I believe is *not* what you want, here). I'm heading for the patent office. Andre::CrystalBall sounds nice too. Right. Pid's probably should be: import com.pid.omniscience.CrystalBall; anyway. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEAREIAAYFAlDBIj8ACgkQ9CaO5/Lv0PC+0QCdFTe7kRkUmrWiakKZVPFA7mPk 5tIAoJlZbQl5/2T6ZqxOSC8p1C15DiB9 =CQAy -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is it possible to expire jvmRoute cookie
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Konstanti, On 12/6/12 3:39 PM, Konstantin Kolinko wrote: 2012/12/6 Smith, Mitchell mitchell.sm...@cwc.com: I have a jvmRoute appended to my JSESSIONID to enable sticky sessions at an application level. I see often that users do not close browsers, resulting (even if the tomcat session has expired) the user to be forwarded back to the instance. Is it possible to set an expiry for the jvmRoute / JSESSIONID to be expired at the browser so after x amount of time since last request the jvmRoute is not transmitted back to the application apache load balancer. This would prevent users constantly being directed to the same application node. 1. Even if one can set expiration time for the session cookie (configurable in a Servlet 3.0 compliant application), you cannot do anything if somebody publishes a link containing a jsessionid in it somewhere, e.g. on a forum. What I can think of is to make the jvmroute itself temporary e.g. by changing it periodically. 2. How one additional user can be a problem in such a system? If he accesses a heavy-loaded system the things will be slow for him, but faster for all others, who close their browsers regularly. Let's take a pathological example: Assumptions: 1. Cluster has 3 nodes (A, B, C) 2. Users never close their browsers Let's say that server A is rock-solid and never goes down. Servers B and C are running Gentoo Linux or Debian Sid or Microsoft Windows or have flaky hardware and so they crash or need to be rebooted all the time; perhaps daily. Users on nodes B and C will constantly fail-over to node A. Those users will stick on node A pretty much forever. Therefore node A always gets most of the traffic, and nodes B and C only get new users for a while before failing-over. Even if nodes B and C can handle 1/3 of the load, they will get much less than that, and node A will, over time, accumulate users without bound. It would be nice to avoid this kind of situation. So one could recommend that if things go slow to close one's browser, clean caches, or even reboot. ;) If I called tech support for a website and they told me I needed to close my browser or reboot my computer to just to use their website, I would assume that they were complete idiots. If I want to be lied to about what the problem is, I'll call my home broadband provider. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEAREIAAYFAlDBJTsACgkQ9CaO5/Lv0PDciACeIiAmy+jUn0Y8Y114gKuDMk+T p5gAoJyh8wyhM8BP5GRknZh+McIqGfE+ =DwDL -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Is it possible to expire jvmRoute cookie
-Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Thursday, December 06, 2012 5:08 PM To: Tomcat Users List Subject: Re: Is it possible to expire jvmRoute cookie 2. How one additional user can be a problem in such a system? If he accesses a heavy-loaded system the things will be slow for him, but faster for all others, who close their browsers regularly. Let's take a pathological example: Assumptions: 1. Cluster has 3 nodes (A, B, C) 2. Users never close their browsers Let's say that server A is rock-solid and never goes down. Servers B and C are running Gentoo Linux or Debian Sid or Microsoft Windows or have flaky hardware and so they crash or need to be rebooted all the time; perhaps daily. Users on nodes B and C will constantly fail-over to node A. Those users will stick on node A pretty much forever. Therefore node A always gets most of the traffic, and nodes B and C only get new users for a while before failing-over. Even if nodes B and C can handle 1/3 of the load, they will get much less than that, and node A will, over time, accumulate users without bound. It would be nice to avoid this kind of situation. So one could recommend that if things go slow to close one's browser, clean caches, or even reboot. ;) If I called tech support for a website and they told me I needed to close my browser or reboot my computer to just to use their website, I would assume that they were complete idiots. If I want to be lied to about what the problem is, I'll call my home broadband provider. -- HAHAHA ... nice one. I agree with Chris, here. It's not a common situation, but it is a possible situation, and if it occurred, it could get ugly quickly. Earlier somebody (I'm sorry, I already deleted the email) suggested Tomcat returning a 308 or 309 or similar to the load balancer to trigger a re-balance if the session is expired. I think this is the best idea I've heard yet, solves the problem elegantly and simply, and seems (relatively) easy to achieve (this coming from someone who has no knowledge of the code used by mod_jk/isapi_redirector). Nick This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.
