-----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
