tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dmitry Beransky" <>
Subject Re: clustering iis with JK
Date Wed, 28 Nov 2007 16:12:17 GMT
Hi Rainer,

It's the item #3 on your Simple Setup list that I'm basically asking
about (I already have #1 set up and working, and parts of #2).

Here's where my problem with #3 lies:

Let's say we have two load-balanced (clustered) web/IIS servers: W1
and W2, each configured with sticky forwarding by isapi_redirectors
JK1 & JK2 to Tomcat servers T1 & T2.

Let's follow this scenario
1. Request (R1) comes to the web cluster (C) and gets dispatched to
W1. R1 is a new request, so it's gets arbitrarily sent to T2, where
it's assigned a new session (S1)
2. Request R2 from session S1 comes to C.  Let's say it gets
dispatched to W1 again (C wouldn't know anything about S1).  Since JK1
knows about S1, R2(S1) will be forwarded to T2, which started S1 ---
everything is fine.
3. Request R3 from session S1 comes to C.  And since C doesn't know
anything about S1, R3(S1) is load-balanced to W2.  JK2 at this point
doesn't know anything about S1.  To it, it's a new session, so it may
forward it either to T1 or T2.  If R3(S1) gets sent to T2, we are
good.  If not - our app is in trouble.

I'm new to all this, so I might be missing something basic.  I do
realize that Tomcat session replication (your more complex setup)
makes this problem moot.  But, let's say, I do not take the session
relication route, can I still make sure that #3 from above does not


On Nov 28, 2007 3:02 AM, Rainer Jung <> wrote:
> Dmitry Beransky wrote:
> > Hi,
> >
> > Is it possible to implement the following setup with JK/isapi_redirect?
> >
> >   1. Two clustered IIS instances
> >   2. Two load-balanced Tomcat instances
> >   3. Each IIS uses JK to forward requests to two load-balanced Tomcat instances
> >
> > I know how to do each individual item in isolation, but I can't
> > figure, once I put all three together, how to ensure that requests
> > belonging to the same session are consistently served to the
> > appropriate Tomcat instance.  Any pointers?
> >
> > For IIS clustering I am considering NLB.  Since want IIS clustering
> > for mostly for reliability rather than scalability, an easy way out
> > would be to do a fail over setup, but this is plan B.
> To isolate the layers:
> - Load-balancing the web servers (IIS)
> - Maybe stickyness already in the web layer, mainly in case you use SSL
> - Load-balancing between IIS layer and the Tomcat layer using the isapi
> redirector, including stickyness
> - Maybe session replication between the Tomcat instances to further
> increase transparency of nore failures
> Simple setup would be:
> - No session replication between Tomcat nodes (no Tomcat-Cluster).
>   In case a node fails, the users with sessions on the nodes have to
> login again. OK, if sessions are cheap, i.e. not much work lost, not
> much information in the session, and failure rate is low (application,
> hardware, network relatively stable).
> - Combined with sticky forwarding by the isapi redirector (uses URL
> encoded sessions or standard Java session cookie JSESSIONID combined
> with the jvmRoute setting in server.xml of the Tomcat backends; TC adds
> the jvmRoute to the session id, and isapi redirector sees this tag in
> the URL or cookie and maps it to the correct backend). Works very robust.
> - Load-Balancing or high availability in the IIS layer would still be
> your job. Stickyness demand on the IIS layer itself depends on the fact,
> if the IIS layer is stateless (should be, apart from the SSL case, were
> you want to have a relatively good stickyness; don't need 100%, but the
> less sticky the LB to the IIS is, the more SSL handshakes you get).
> More complex setup:
> - Add session replication to the TC backends. Most likely nevertheles
> you want to keep stickyness with the isapi redirector, to reduce
> dependency on the rpelication during the time you actually didn't have a
> node failure.
> Regards,
> Rainer
> >
> >
> > Thanks
> > Dmitry
> ---------------------------------------------------------------------
> To start a new topic, e-mail:
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message