FACT: Orion's HTTP clustering won't work unless the web site is
default-web-site.
also, session replication in orion(at least, 1.4.7, which is the version
I've used) does survive well server crashes, but not server restarts. I'll
explain
Environment with a redirector (R) and two orion boxes (A B)
session values are replicated.
server B goes down
server A performs (session values are used)
server B goes live again
sessions on server A aren't replicated in server B. However, any attributes
set in A(setAttribute() ), will be replicated to B in realtime.
So, there's an amount of time, when crashed servers go back online, in which
they have partial or no session status replication. This is observable when
using any tipe of redirector, either software(LoadBalancer) or
hardware(Cisco Redirector, Foundry Iron). This could be solved(not easily
tough) with a synchronization instance in which server B should get a the
bulk of all session state in server A, then proceed normally.
Along this line, but diverting, the logged user is replicated only when the
user logs in, so sessions in B after the restart have no identity
information, which will eventually trigger a login page to be displayed.
These issues tend to get worse as the island size(box count) increases.
Orion does have a HTTPSessionManager interface exposed as public. It allows
Orion to implement a 'normal' HTTPSession and a ClusteredHTTPSession
transparently, and is used internally when some attributes are on appropiate
xml files (ref: cluster/); I'd wish there was a tag on
orion-application.xml that could allow a personalized class which implements
HTTPSessionManager to be used, a la UserManager, so some of these problems
(and others that arise with mixed sites that use non secure and secure
portions) could be worked around without giving up many of orion's session
managing abilities(URL rewriting, Management of sessions with the console
and so on)
My 2c,
JP
PS: I'm forwarding this to Karl to be entered in the wishlist.
-Original Message-
From: Marcel Schutte [mailto:[EMAIL PROTECTED]]
Sent: Lunes, 21 de Mayo de 2001 5:48
To: Orion-Interest
Subject: RE: PetStore - Session State in a Cluster
My guess is you stumbled upon a mismatch between the servlet and jsp
specifications: a container needs some way to decide when to
replicate a
session to a cluster. In Orion and Weblogic this is done when
session.setAttribute() is called. This works fine for things like the
SessionServlet.
In jsp's with the jsp:useBean ... scope=session tag,
setAttribute is
only called upon creation of the bean class. Modifications to
the session
state are done through calls on the bean class. This doesn't
trigger session
replication because the container doesn't know about the change.
Marcel
Hi,
I have the (J2EE Blueprint) PetStore application clustered on
two Orion
instances running on the same machine.
When I connect through the LoadBalancer, I can see my session
state get
replicated across the two nodes. When I kill the primary
node, the load
balancer automatically connects me to the secondary node
and takes me
through the rest of the shopping cart experience, however any
items I had in
my cart (ie. Session state!) aren't there anymore.
I know that for clustering to work, objects should be
Serializable AND
placed in the session/servlet context for it to be
replicated. So my *real*
questions are:
1) I haven't dived into the PetStore code - but is this a
design issue with
the PetStore or do I need some configuration pointers?
2) Has ANYBODY got PetStore working properly in a Clustered
environment
where you can kill the primary server and continue shopping
(with your
existing cart) on the secondary node?
My Environment:Win2K, JDK 1.3, PetStore 1.1.2, Orion 1.4.5
NB: The SessionServlet example works FINE for me. When the
primary goes
down, the secondary node picks up with the same counter
number as before the
failure.
__
___
Get Your Private, Free E-mail from MSN Hotmail at
http://www.hotmail.com.
