You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Leo Sakhvoruk <le...@gmail.com> on 2006/10/25 17:48:36 UTC
Tomcat failover.
I know this is not a Tomcat list but I'm just hoping somebody's had
experience in this area and could provide some quick guidance on the
issue. I'm trying to setup a cluster of tomcat servers in session
replication mode for failover purposes. Though it's pretty unclear from
the docs if this kind of a setup requires an Apache server to run or if
this can be done exclusively using Tomcat.
I'm also wondering if something specific has to be done in Tapestry as
well besides just the items that are stored in the session being
serializable.
Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tomcat failover.
Posted by Leo Sakhvoruk <le...@gmail.com>.
No you're right there'll always be a single point of failure unless
there is a truly redundant environment. But, minimizing the number of
links in a non-redundant chain minimizes the chance of one of those
links failing ;) So I'm trying to cut down on the number of things it
takes to have the system running and only keeping those pieces that are
absolutely necessary for the operation.
Dennis Sinelnikov wrote:
> 2 mirror installations of apache httpd and dns round robin them. I
> could be wrong, but at some point you will have single point of
> failure -- either at apache httpd level or dns level.
>
> Dennis
> Leo Sakhvoruk wrote:
>> Yeah, I've read the docs on mod_jk. It seems a self-defeating purpose
>> to set up Apache httpd for load balancing and fail over because it
>> introduces a single point of failure on the part of the Apache httpd.
>> That's why I originally asked if the only way to set up fail over was
>> via integration with httpd. It would've been nice to just be able to
>> do a fail over cluster with DNS round-robin where after one Tomcat
>> server went down the next one in the DNS chain would be able to
>> resume the session. But from what I've been able to gather Apache
>> httpd is required for that kind of setup. Pity.
>>
>> Dennis Sinelnikov wrote:
>>> Take a look at mod_jk, there are some great examples on apache's
>>> httpd website.
>>>
>>> Dennis
>>>
>>> Leo Sakhvoruk wrote:
>>>> Excellent points Patrick! I will most certainly consider them as I
>>>> look at clustering further.
>>>>
>>>> Thanks,
>>>>
>>>> Leo
>>>>
>>>> Patrick Moore wrote:
>>>>> Hi Leo --
>>>>>
>>>>>> From my experience, these are the questions that you should make
>>>>>> sure
>>>>> were asked first:
>>>>>
>>>>> 1. What is the effect on the user experience if the new server does
>>>>> not have the session information?
>>>>>
>>>>> 2. How large a memory footprint does each session occupy?
>>>>>
>>>>> 3. How often do session variables change?
>>>>>
>>>>> It has been my experience that session replication is almost never
>>>>> worth the trouble it causes in terms of extra load on network and
>>>>> webapps. Failure at the web app level usually has so little
>>>>> consequences that usually it is enough to simply:
>>>>>
>>>>> 1. just redirect the user to a new web server
>>>>> 2. the new server asks them to reauthenticate
>>>>> 3. looks for any work in progress that was significant enough to
>>>>> store
>>>>> in the database ( which the app is probably already doing as it is)
>>>>> 4. If it finds such work offers to take them back to that flow.
>>>>>
>>>>> Think about just storing every significant checkpoint in your app
>>>>> as a
>>>>> cookie that deserializes to a bookmark that takes them to an
>>>>> IExternalPage that will continue their work. You are using
>>>>> IExternalPage and bookmarks, right? right? (hint, hint) :-)
>>>>>
>>>>> -Pat
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tomcat failover.
Posted by Dennis Sinelnikov <de...@augustschell.com>.
2 mirror installations of apache httpd and dns round robin them. I
could be wrong, but at some point you will have single point of failure
-- either at apache httpd level or dns level.
Dennis
Leo Sakhvoruk wrote:
> Yeah, I've read the docs on mod_jk. It seems a self-defeating purpose to
> set up Apache httpd for load balancing and fail over because it
> introduces a single point of failure on the part of the Apache httpd.
> That's why I originally asked if the only way to set up fail over was
> via integration with httpd. It would've been nice to just be able to do
> a fail over cluster with DNS round-robin where after one Tomcat server
> went down the next one in the DNS chain would be able to resume the
> session. But from what I've been able to gather Apache httpd is required
> for that kind of setup. Pity.
>
> Dennis Sinelnikov wrote:
>> Take a look at mod_jk, there are some great examples on apache's httpd
>> website.
>>
>> Dennis
>>
>> Leo Sakhvoruk wrote:
>>> Excellent points Patrick! I will most certainly consider them as I
>>> look at clustering further.
>>>
>>> Thanks,
>>>
>>> Leo
>>>
>>> Patrick Moore wrote:
>>>> Hi Leo --
>>>>
>>>>> From my experience, these are the questions that you should make sure
>>>> were asked first:
>>>>
>>>> 1. What is the effect on the user experience if the new server does
>>>> not have the session information?
>>>>
>>>> 2. How large a memory footprint does each session occupy?
>>>>
>>>> 3. How often do session variables change?
>>>>
>>>> It has been my experience that session replication is almost never
>>>> worth the trouble it causes in terms of extra load on network and
>>>> webapps. Failure at the web app level usually has so little
>>>> consequences that usually it is enough to simply:
>>>>
>>>> 1. just redirect the user to a new web server
>>>> 2. the new server asks them to reauthenticate
>>>> 3. looks for any work in progress that was significant enough to store
>>>> in the database ( which the app is probably already doing as it is)
>>>> 4. If it finds such work offers to take them back to that flow.
>>>>
>>>> Think about just storing every significant checkpoint in your app as a
>>>> cookie that deserializes to a bookmark that takes them to an
>>>> IExternalPage that will continue their work. You are using
>>>> IExternalPage and bookmarks, right? right? (hint, hint) :-)
>>>>
>>>> -Pat
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tomcat failover.
Posted by Leo Sakhvoruk <le...@gmail.com>.
Yeah, I've read the docs on mod_jk. It seems a self-defeating purpose to
set up Apache httpd for load balancing and fail over because it
introduces a single point of failure on the part of the Apache httpd.
That's why I originally asked if the only way to set up fail over was
via integration with httpd. It would've been nice to just be able to do
a fail over cluster with DNS round-robin where after one Tomcat server
went down the next one in the DNS chain would be able to resume the
session. But from what I've been able to gather Apache httpd is required
for that kind of setup. Pity.
Dennis Sinelnikov wrote:
> Take a look at mod_jk, there are some great examples on apache's httpd
> website.
>
> Dennis
>
> Leo Sakhvoruk wrote:
>> Excellent points Patrick! I will most certainly consider them as I
>> look at clustering further.
>>
>> Thanks,
>>
>> Leo
>>
>> Patrick Moore wrote:
>>> Hi Leo --
>>>
>>>> From my experience, these are the questions that you should make sure
>>> were asked first:
>>>
>>> 1. What is the effect on the user experience if the new server does
>>> not have the session information?
>>>
>>> 2. How large a memory footprint does each session occupy?
>>>
>>> 3. How often do session variables change?
>>>
>>> It has been my experience that session replication is almost never
>>> worth the trouble it causes in terms of extra load on network and
>>> webapps. Failure at the web app level usually has so little
>>> consequences that usually it is enough to simply:
>>>
>>> 1. just redirect the user to a new web server
>>> 2. the new server asks them to reauthenticate
>>> 3. looks for any work in progress that was significant enough to store
>>> in the database ( which the app is probably already doing as it is)
>>> 4. If it finds such work offers to take them back to that flow.
>>>
>>> Think about just storing every significant checkpoint in your app as a
>>> cookie that deserializes to a bookmark that takes them to an
>>> IExternalPage that will continue their work. You are using
>>> IExternalPage and bookmarks, right? right? (hint, hint) :-)
>>>
>>> -Pat
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tomcat failover.
Posted by Dennis Sinelnikov <de...@augustschell.com>.
Take a look at mod_jk, there are some great examples on apache's httpd
website.
Dennis
Leo Sakhvoruk wrote:
> Excellent points Patrick! I will most certainly consider them as I look
> at clustering further.
>
> Thanks,
>
> Leo
>
> Patrick Moore wrote:
>> Hi Leo --
>>
>>> From my experience, these are the questions that you should make sure
>> were asked first:
>>
>> 1. What is the effect on the user experience if the new server does
>> not have the session information?
>>
>> 2. How large a memory footprint does each session occupy?
>>
>> 3. How often do session variables change?
>>
>> It has been my experience that session replication is almost never
>> worth the trouble it causes in terms of extra load on network and
>> webapps. Failure at the web app level usually has so little
>> consequences that usually it is enough to simply:
>>
>> 1. just redirect the user to a new web server
>> 2. the new server asks them to reauthenticate
>> 3. looks for any work in progress that was significant enough to store
>> in the database ( which the app is probably already doing as it is)
>> 4. If it finds such work offers to take them back to that flow.
>>
>> Think about just storing every significant checkpoint in your app as a
>> cookie that deserializes to a bookmark that takes them to an
>> IExternalPage that will continue their work. You are using
>> IExternalPage and bookmarks, right? right? (hint, hint) :-)
>>
>> -Pat
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tomcat failover.
Posted by Leo Sakhvoruk <le...@gmail.com>.
Excellent points Patrick! I will most certainly consider them as I look
at clustering further.
Thanks,
Leo
Patrick Moore wrote:
> Hi Leo --
>
>> From my experience, these are the questions that you should make sure
> were asked first:
>
> 1. What is the effect on the user experience if the new server does
> not have the session information?
>
> 2. How large a memory footprint does each session occupy?
>
> 3. How often do session variables change?
>
> It has been my experience that session replication is almost never
> worth the trouble it causes in terms of extra load on network and
> webapps. Failure at the web app level usually has so little
> consequences that usually it is enough to simply:
>
> 1. just redirect the user to a new web server
> 2. the new server asks them to reauthenticate
> 3. looks for any work in progress that was significant enough to store
> in the database ( which the app is probably already doing as it is)
> 4. If it finds such work offers to take them back to that flow.
>
> Think about just storing every significant checkpoint in your app as a
> cookie that deserializes to a bookmark that takes them to an
> IExternalPage that will continue their work. You are using
> IExternalPage and bookmarks, right? right? (hint, hint) :-)
>
> -Pat
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tomcat failover.
Posted by Patrick Moore <tr...@gmail.com>.
Hi Leo --
>From my experience, these are the questions that you should make sure
were asked first:
1. What is the effect on the user experience if the new server does
not have the session information?
2. How large a memory footprint does each session occupy?
3. How often do session variables change?
It has been my experience that session replication is almost never
worth the trouble it causes in terms of extra load on network and
webapps. Failure at the web app level usually has so little
consequences that usually it is enough to simply:
1. just redirect the user to a new web server
2. the new server asks them to reauthenticate
3. looks for any work in progress that was significant enough to store
in the database ( which the app is probably already doing as it is)
4. If it finds such work offers to take them back to that flow.
Think about just storing every significant checkpoint in your app as a
cookie that deserializes to a bookmark that takes them to an
IExternalPage that will continue their work. You are using
IExternalPage and bookmarks, right? right? (hint, hint) :-)
-Pat
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tomcat failover.
Posted by Daniel Tabuenca <dt...@gmail.com>.
I'm not an expert, but you do not need Apache HTTPD server in order
to get Tomcat to cluster (although you can certainly use it if you
want). As far as tapestry, I don't think there is anything special you
need to do other than make sure your session is serializable.
On 10/25/06, Leo Sakhvoruk <le...@gmail.com> wrote:
> I know this is not a Tomcat list but I'm just hoping somebody's had
> experience in this area and could provide some quick guidance on the
> issue. I'm trying to setup a cluster of tomcat servers in session
> replication mode for failover purposes. Though it's pretty unclear from
> the docs if this kind of a setup requires an Apache server to run or if
> this can be done exclusively using Tomcat.
>
> I'm also wondering if something specific has to be done in Tapestry as
> well besides just the items that are stored in the session being
> serializable.
>
> Thanks.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org