You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Theparanoidone Theparanoidone <th...@yahoo.com> on 2009/06/10 21:59:04 UTC
Consequences of Reusing Clustered JSESSIONID
Greetings~
I would like to reuse the JSESSIONID route betweened clustered tomcats... and I'm wondering if there are negative consequences for doing so.
We have the following setup:
2 data centers... (d1 / d2)
2 apache mod_proxy_balance (ad1, ad2)
4 tomcat servers (td101, td102, td201, td202)
--- sessions are replicated between both data centers (fortunately our application is light enough that this should be okay for our needs)
d1 d2
| |
ad1 ad2
/ \ / \
td101 -- td102 -- -- td201 -- td202
Our clients are "stuck" to a particular tomcat server and data center upon logging in; however, if we need to perform maintenance... we switch everyone over to an "up" data center while we do maintenance on the "down" center.
So, in normal operation... a client will always reconnect to td101.
If we flip to maintenance mode... they'll be redirected to d2... HOWEVER our current...
While at d2... they will ping/pong in between td201 and td202... (this is because apache a2 only has routes for td201 and td202... but not td101... therefore it doesn't know how to handle td101.
Our application still works... it's just messy flip flopping between 2 tomcat servers for every request.
I'm considering relabeling the routes as follows (td1, td2, td1, td2)
d1 d2
| |
ad1 ad2
/ \ / \
td1 -- td2 -- -- td1 -- td2
Is there any weird route collisions or problems in doing this?
Do routes really have to be unique if our application controls which physical data center a customer connects to?
Thanks!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Consequences of Reusing Clustered JSESSIONID
Posted by Theparanoidone Theparanoidone <th...@yahoo.com>.
Hi Filip~
That is an interesting possible solution (seems easy too). I will give that a try. Thank you for the quick response. Cheers!
----- Original Message ----
From: Filip Hanik - Dev Lists <de...@hanik.com>
To: Tomcat Users List <us...@tomcat.apache.org>
Sent: Wednesday, June 10, 2009 1:57:26 PM
Subject: Re: Consequences of Reusing Clustered JSESSIONID
>this is because apache a2 only has routes for td201 and td202... but not td101... therefore it doesn't know how to handle td101.
why don't you setup all four routes for a1 and a2.
then use the mod_proxy_balancer lbset variable to set a preferred route, and problem will be solved
Filip
Theparanoidone Theparanoidone wrote:
> Greetings~
>
> I would like to reuse the JSESSIONID route betweened clustered tomcats... and I'm wondering if there are negative consequences for doing so.
>
> We have the following setup:
> 2 data centers... (d1 / d2)
> 2 apache mod_proxy_balance (ad1, ad2)
> 4 tomcat servers (td101, td102, td201, td202)
> --- sessions are replicated between both data centers (fortunately our application is light enough that this should be okay for our needs)
>
> d1 d2
> | |
> ad1 ad2
> / \ / \
> td101 -- td102 -- -- td201 -- td202
>
>
>
> Our clients are "stuck" to a particular tomcat server and data center upon logging in; however, if we need to perform maintenance... we switch everyone over to an "up" data center while we do maintenance on the "down" center.
>
> So, in normal operation... a client will always reconnect to td101.
> If we flip to maintenance mode... they'll be redirected to d2... HOWEVER our current...
> While at d2... they will ping/pong in between td201 and td202... (this is because apache a2 only has routes for td201 and td202... but not td101... therefore it doesn't know how to handle td101.
>
> Our application still works... it's just messy flip flopping between 2 tomcat servers for every request.
>
> I'm considering relabeling the routes as follows (td1, td2, td1, td2)
>
> d1 d2
> | |
> ad1 ad2
> / \ / \
> td1 -- td2 -- -- td1 -- td2
>
>
> Is there any weird route collisions or problems in doing this?
> Do routes really have to be unique if our application controls which physical data center a customer connects to?
>
> Thanks!
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Consequences of Reusing Clustered JSESSIONID
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Rainer Jung wrote:
> On 12.06.2009 02:57, Filip Hanik - Dev Lists wrote:
>
>> Rainer Jung wrote:
>>
>>> On 10.06.2009 22:57, Filip Hanik - Dev Lists wrote:
>>>
>>>
>>>>> this is because apache a2 only has routes for td201 and td202... but
>>>>> not td101... therefore it doesn't know how to handle td101.
>>>>>
>>>>>
>>>> why don't you setup all four routes for a1 and a2.
>>>> then use the mod_proxy_balancer lbset variable to set a preferred route,
>>>> and problem will be solved
>>>>
>>>>
>>> Although this will work, it will need more connections
>>>
>> more connections true, but they timeout if idle
>>
>>> and thus threads,
>>>
>>>
>> not really, since idle connections will be in a polling state if you are
>> using APR or NIO.
>> And if using BIO, then you set a timeout, and the threads will be
>> released after the timeout.
>>
>>
>>> because the routes use different connection pools.
>>>
>>> You could also rewrite the jvmRoute in the session id:
>>>
>>> http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html#Bind%20session%20after%20crash%20to%20failover%20node
>>>
>>>
>>>
>> sounds like a mod_jk feature, they are using proxy_balancer, is it
>> available there?
>>
>
> I thought it's only based on cluster, jvmRoute and session IDs. How
> should mod_jk come into play here?
>
just unclear documentation. also lbset wouldn't yield more connections
either, since lbset is a priority. from what I understand, lbset=1 wont
even open a connection as long as lbset=0 is available. (when you have
min connections set to 0)
> Yes, they have to set the jvmRoute, and mod_proxy_balancer has to use
> it. But apart from that?
>
you're right
> Regards,
>
> Rainer
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Consequences of Reusing Clustered JSESSIONID
Posted by Rainer Jung <ra...@kippdata.de>.
On 12.06.2009 02:57, Filip Hanik - Dev Lists wrote:
> Rainer Jung wrote:
>> On 10.06.2009 22:57, Filip Hanik - Dev Lists wrote:
>>
>>>> this is because apache a2 only has routes for td201 and td202... but
>>>> not td101... therefore it doesn't know how to handle td101.
>>>>
>>> why don't you setup all four routes for a1 and a2.
>>> then use the mod_proxy_balancer lbset variable to set a preferred route,
>>> and problem will be solved
>>>
>>
>> Although this will work, it will need more connections
> more connections true, but they timeout if idle
>> and thus threads,
>>
> not really, since idle connections will be in a polling state if you are
> using APR or NIO.
> And if using BIO, then you set a timeout, and the threads will be
> released after the timeout.
>
>> because the routes use different connection pools.
>>
>> You could also rewrite the jvmRoute in the session id:
>>
>> http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html#Bind%20session%20after%20crash%20to%20failover%20node
>>
>>
> sounds like a mod_jk feature, they are using proxy_balancer, is it
> available there?
I thought it's only based on cluster, jvmRoute and session IDs. How
should mod_jk come into play here?
Yes, they have to set the jvmRoute, and mod_proxy_balancer has to use
it. But apart from that?
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Consequences of Reusing Clustered JSESSIONID
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Rainer Jung wrote:
> On 10.06.2009 22:57, Filip Hanik - Dev Lists wrote:
>
>>> this is because apache a2 only has routes for td201 and td202... but
>>> not td101... therefore it doesn't know how to handle td101.
>>>
>> why don't you setup all four routes for a1 and a2.
>> then use the mod_proxy_balancer lbset variable to set a preferred route,
>> and problem will be solved
>>
>
> Although this will work, it will need more connections
more connections true, but they timeout if idle
> and thus threads,
>
not really, since idle connections will be in a polling state if you are
using APR or NIO.
And if using BIO, then you set a timeout, and the threads will be
released after the timeout.
> because the routes use different connection pools.
>
> You could also rewrite the jvmRoute in the session id:
>
> http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html#Bind%20session%20after%20crash%20to%20failover%20node
>
sounds like a mod_jk feature, they are using proxy_balancer, is it
available there?
> Regards,
>
> Rainer
>
>
>> Theparanoidone Theparanoidone wrote:
>>
>>> Greetings~
>>>
>>> I would like to reuse the JSESSIONID route betweened clustered
>>> tomcats... and I'm wondering if there are negative consequences for
>>> doing so.
>>>
>>> We have the following setup:
>>> 2 data centers... (d1 / d2)
>>> 2 apache mod_proxy_balance (ad1, ad2)
>>> 4 tomcat servers (td101, td102, td201, td202) --- sessions are
>>> replicated between both data centers (fortunately our application is
>>> light enough that this should be okay for our needs)
>>>
>>> d1 d2
>>> | |
>>> ad1 ad2
>>> / \ / \
>>> td101 -- td102 -- -- td201 -- td202
>>>
>>>
>>> Our clients are "stuck" to a particular tomcat server and data center
>>> upon logging in; however, if we need to perform maintenance... we
>>> switch everyone over to an "up" data center while we do maintenance on
>>> the "down" center.
>>>
>>> So, in normal operation... a client will always reconnect to td101. If
>>> we flip to maintenance mode... they'll be redirected to d2... HOWEVER
>>> our current...
>>> While at d2... they will ping/pong in between td201 and td202...
>>> (this is because apache a2 only has routes for td201 and td202... but
>>> not td101... therefore it doesn't know how to handle td101.
>>>
>>> Our application still works... it's just messy flip flopping between 2
>>> tomcat servers for every request.
>>>
>>> I'm considering relabeling the routes as follows (td1, td2, td1, td2)
>>>
>>> d1 d2
>>> | |
>>> ad1 ad2
>>> / \ / \
>>> td1 -- td2 -- -- td1 -- td2
>>>
>>> Is there any weird route collisions or problems in doing this?
>>> Do routes really have to be unique if our application controls which
>>> physical data center a customer connects to?
>>>
>>> Thanks!
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Consequences of Reusing Clustered JSESSIONID
Posted by Rainer Jung <ra...@kippdata.de>.
On 10.06.2009 22:57, Filip Hanik - Dev Lists wrote:
>> this is because apache a2 only has routes for td201 and td202... but
>> not td101... therefore it doesn't know how to handle td101.
>
> why don't you setup all four routes for a1 and a2.
> then use the mod_proxy_balancer lbset variable to set a preferred route,
> and problem will be solved
Although this will work, it will need more connections and thus threads,
because the routes use different connection pools.
You could also rewrite the jvmRoute in the session id:
http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html#Bind%20session%20after%20crash%20to%20failover%20node
Regards,
Rainer
> Theparanoidone Theparanoidone wrote:
>> Greetings~
>>
>> I would like to reuse the JSESSIONID route betweened clustered
>> tomcats... and I'm wondering if there are negative consequences for
>> doing so.
>>
>> We have the following setup:
>> 2 data centers... (d1 / d2)
>> 2 apache mod_proxy_balance (ad1, ad2)
>> 4 tomcat servers (td101, td102, td201, td202) --- sessions are
>> replicated between both data centers (fortunately our application is
>> light enough that this should be okay for our needs)
>>
>> d1 d2
>> | |
>> ad1 ad2
>> / \ / \
>> td101 -- td102 -- -- td201 -- td202
>>
>>
>> Our clients are "stuck" to a particular tomcat server and data center
>> upon logging in; however, if we need to perform maintenance... we
>> switch everyone over to an "up" data center while we do maintenance on
>> the "down" center.
>>
>> So, in normal operation... a client will always reconnect to td101. If
>> we flip to maintenance mode... they'll be redirected to d2... HOWEVER
>> our current...
>> While at d2... they will ping/pong in between td201 and td202...
>> (this is because apache a2 only has routes for td201 and td202... but
>> not td101... therefore it doesn't know how to handle td101.
>>
>> Our application still works... it's just messy flip flopping between 2
>> tomcat servers for every request.
>>
>> I'm considering relabeling the routes as follows (td1, td2, td1, td2)
>>
>> d1 d2
>> | |
>> ad1 ad2
>> / \ / \
>> td1 -- td2 -- -- td1 -- td2
>>
>> Is there any weird route collisions or problems in doing this?
>> Do routes really have to be unique if our application controls which
>> physical data center a customer connects to?
>>
>> Thanks!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Consequences of Reusing Clustered JSESSIONID
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
>this is because apache a2 only has routes for td201 and td202... but not td101... therefore it doesn't know how to handle td101.
why don't you setup all four routes for a1 and a2.
then use the mod_proxy_balancer lbset variable to set a preferred route, and problem will be solved
Filip
Theparanoidone Theparanoidone wrote:
> Greetings~
>
> I would like to reuse the JSESSIONID route betweened clustered tomcats... and I'm wondering if there are negative consequences for doing so.
>
> We have the following setup:
> 2 data centers... (d1 / d2)
> 2 apache mod_proxy_balance (ad1, ad2)
> 4 tomcat servers (td101, td102, td201, td202)
> --- sessions are replicated between both data centers (fortunately our application is light enough that this should be okay for our needs)
>
> d1 d2
> | |
> ad1 ad2
> / \ / \
> td101 -- td102 -- -- td201 -- td202
>
>
>
> Our clients are "stuck" to a particular tomcat server and data center upon logging in; however, if we need to perform maintenance... we switch everyone over to an "up" data center while we do maintenance on the "down" center.
>
> So, in normal operation... a client will always reconnect to td101.
> If we flip to maintenance mode... they'll be redirected to d2... HOWEVER our current...
> While at d2... they will ping/pong in between td201 and td202... (this is because apache a2 only has routes for td201 and td202... but not td101... therefore it doesn't know how to handle td101.
>
> Our application still works... it's just messy flip flopping between 2 tomcat servers for every request.
>
> I'm considering relabeling the routes as follows (td1, td2, td1, td2)
>
> d1 d2
> | |
> ad1 ad2
> / \ / \
> td1 -- td2 -- -- td1 -- td2
>
>
> Is there any weird route collisions or problems in doing this?
> Do routes really have to be unique if our application controls which physical data center a customer connects to?
>
> Thanks!
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org