distributed environment

[David Mossakowski <dm...@Instinet.Com>]

I'm looking to use tomcat in a distributed architecture and found this 
description from an exerpt of Jason Hunter's 'Java Servlet Programming' 
under 'Many Styles of Distribution':

"2.  Clustering support, no session migration, and no session failover. 
Servlets in a web application marked <distributable/> may execute across 
multiple machines. Nonsession requests are randomly distributed (modulo 
some weighting perhaps). Session requests are "sticky" and tied to the 
particular backend server on which they first start. Session data does 
not move between machines, and this has the advantage that sessions may 
hold nontransferable (non-Serializable) data and the disadvantage that 
sessions may not migrate to underutilized servers and a server crash may 
result in broken sessions. This is the architecture used by Apache/JServ 
and Apache/Tomcat. Sessions are tied to a particular host through a 
mechanism where the mod_jserv/mod_jk connector in Apache uses a portion 
of the session ID to indicate which backend JServ or Tomcat owns the 
session. Multiple instances of Apache may be used as well, with the 
support of load-balancing hardware or software."

My questions about this:
1. I'm assuming that with a single Apache server that it has mutltiple 
Tomcat servers that it balances across therefore knowing which session 
to send where but how is a "sticky" session achieved with mutliple 
Apache instances? The last sentence suggests this is possible.

2. Is using a single Apache server serving across multiple Tomcats and 
having another Apache server connected to the same Tomcats as a standby 
if the first goes down an effective solution for high availability?

I'm not too concerned with migrating sessions or session failover as 
long as a session is continued (meaning the request goes to the same 
Tomcat instance).  Currently I'm looking into persistent storage on a 
database but I worry it's too costly (timewise).

-- Bottom Line --
Please let me know what can I expect from Apache/Tomcat combination in a 
distributed environment without going the EJB, big-ass-expensive 
application server route.

Thanks,
d.

-- 
David Mossakowski              dmoss@instinet.com
Instinet Corporation                 212.310.7275



*******************************************************************************
<<Disclaimer>>

This message is intended only for the use of the Addressee and 
may contain information that is PRIVILEGED and/or
CONFIDENTIAL or both.

This email is intended only for the personal and confidential use
of the recipient(s) named above.

If the reader of this email is not an intended recipient, you have
received this email in error and any review, dissemination,
distribution or copying is strictly prohibited.

If you have received this email in error, please notify the sender
immediately by return mail and permanently deleting the copy
you received.

Thank you.

*******************************************************************************


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: distributed environment

[Ben Ricker <br...@wellinx.com>]

On Tue, 2002-06-25 at 20:15, David Mossakowski wrote:

> My questions about this:
> 1. I'm assuming that with a single Apache server that it has mutltiple 
> Tomcat servers that it balances across therefore knowing which session 
> to send where but how is a "sticky" session achieved with mutliple 
> Apache instances? The last sentence suggests this is possible.

I cannot speak for Tomcat, but if I am not mistaken, it works as Jserv
does for load-balancing.

Anyway, the session id is written to the cookie that is presented to
Apache, which passes it to the Jserv/Tomcat connector. When
load-balancing, the Jserv/Tomcat connector knows which Tomcat instance
(i.e., IP and port) to send the request until that session is ended.
 
> 2. Is using a single Apache server serving across multiple Tomcats and 
> having another Apache server connected to the same Tomcats as a standby 
> if the first goes down an effective solution for high availability?

Not the most effective. If you have some sort of load-balancer (i.e.,
proxy server, dedicated load-balancer, DNS, etc), you can use BOTH
Apache's which receive requests and forward them to the correct
instance. If an Apache goes down, the other one will take over and the
user will see know problems (unless the load across two Apaches would
kill one Apache).

> I'm not too concerned with migrating sessions or session failover as 
> long as a session is continued (meaning the request goes to the same 
> Tomcat instance).  Currently I'm looking into persistent storage on a 
> database but I worry it's too costly (timewise).

There is a caveat: if a Tomcat instance fails, all sessions on that
instance will fail at the next request since the cookie will still point
to it. At the next request, they will get a "session time-out" or
whatever you do when they first initiate the session (i.e., a login
screen).

 
> -- Bottom Line --
> Please let me know what can I expect from Apache/Tomcat combination in a 
> distributed environment without going the EJB, big-ass-expensive 
> application server route.

Most app servers do session failover, so they will be better. I also
have seen a way to do session failover using a JVM-to-JVM socket
connection which passes session information between JVMs. Have not tried
it myself.


Ben Ricker
Web Security System Administrator
Wellinx.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>