HI all,
Hopefully this will make the list.
I am working on a chapter for a book about scalability. I am also needing to
get our site ready for scaling. I am using Orion to test my web-app that
needs to be a demonstration of a scalable Servlet 2.2 web application. I
have a couple of questions to ask about session fail-over, and how to get
Orion to do this.
I followed the cluster doc to the tee, and everything works fine except that
the SessionServlet example does NOT keep the count going when I shut down
the server that the first request to it created a session on. It starts over
on the count. So I assume either my config is somehow just not correct, or
that this is a bug with Orion. Here is what I have in my web-site.xml file:
<?xml version="1.0"?>
<!DOCTYPE web-site PUBLIC "Orion Web Site"
http://www.orionserver.com/dtds/web-site.dtd>
<web-site host="192.168.0.10" port="8080" display-name="My Cluster Site"
cluster-island="1">
<frontend host="192.168.0.20" port="80"/>
<default-web-app application="MyApp" name="www"/>
<access-log path="./logs/access.log"/>
</web-site>
I have the identical web-app and orion config setup for two machines. The
second machine uses a different host ip address, but does use port 8080.
Same island, and the frontend is set to the same IP as the one above. I also
set the <cluster-config/> tag in the /config/global-web-app.xml file of
Orion, so that all web-apps deployed will be clustered. Finally, each
web-app web.xml has the <distirbutable/> tag in it.
I run the loadbalance.jar file with the -debug option, and run each orion
server with the two HTTP debug options. Everything runs fine. The
loadbalancer starts up, I start the two servers, I see them both being
added. I then make a request to the /servlet/SessionServlet. Comes up fine.
The loadbalancer window shows the session id and what server it goes to.
That server's orion window shows the session being created, etc. I open a
new window and do the same thing, and this time the loadbalancer routes it
to the other server and all is fine. Continuing requests from both browsers
continue to send the requests to the same server their original
request/session was created on. Now, if I shut one of the two down, the
browser that has requests going to that server sometimes shows the 404 error
as if the loadbalancer is not able to redirect its requests to the other
server still running. Other times, it works, but the session counter starts
over again. Also, I DO see from both orion server windows when I hit the
SessionServlet and refresh it that it says "sending.." or something like
that, which I assumes means its sending the session data. However, on the
other orion window I don't see "receiving.." if that is even supposed to
show up. Also, this doesn't do it every time I refresh the window..just some
of the times. This I attribute to possible browser caching of the page..not
sure though.
So I am stumped as to why the sessions are not replicating properly, or at
all. If someone can help out on this, that would be great. But this leads me
into a few "technical" questions about session fail-over in general.
First, I read one article, and someone here (or in the jsp-interest list)
had explained how to replicate a session you must always use the
setAttribute() or putValue() calls. The reason makes sense. If you run this
code:
MyBean myBean = (MyBean) session.getAttribute("MyBean");
myBean.setName("SomeName");
RequestDispatcher rd =
request.getRequestDispatcher("/somepage.jsp").forward(request,response);
then in the JSP page have:
<jsp:useBean id="MyBean" scope="session" class="mypackage.MyBean"/>
<%= MyBean.getName() %>
You'll see that it works correctly..spits out the SomeName. However, the
problem with this..at least from what I have read about writing scalable
web-apps, is that the container has not replicated this change to another
server (or servers) in the same cluster. The reason is, there is no way for
the container to know a change to a field of an object in the HtppSession
has changed. So this leads me to believe one of two things. Session
fail-over only works if you call the setAttribute() call, which the
container can implement to properly replicate the session to another server
(in whatever manner is needed but I think multi-cast is the most common), or
that the container MUST constantly replicate the session at some interval in
order to make sure the other servers sessions are all kept in sync with this
one (and vice versa for those servers sessions).
So this raises a few problems and/or questions. First, if the container
constantly replicates the session at some interval, how badly does that
degrade the performance of the server (and the cluster as replicating
involves serializing, sending, then deserializing and storing the
deseralized objects (or object) into that servers session)? Also, how
exactly is this done..I mean, is the entire Hashtable of ALL user sessions
serialized, sent, and deserialized by the other servers, and at that point
each of those servers needs to copy the deserialized object(s) into each of
their HttpSessions? Or..is there some sort of SMART replication that only
sends the specific object being set into the session? I can't imagine if you
had 3 servers in a cluster, each with say 100 users with sessions, and each
user occupied about say 2MB of memory. Your talking about trying to
serialize 200MB of data every time a setAttribute() call is made..for each
server! I can't even fathom that this is what is done, you would need
gigabit networking just to be able to replicate a session once every 10
seconds! So I have to believe its done in a manner that only the object
being put into the session is serialized and sent on its way. The reason for
the possibly stupid question though, is that I read also that ALL objects in
the HttpSession must be serializable otherwise it wont fail-over at all. If
this is true, then I gotta believe that each time it replicates the session
of a user, it tries to send the whole session of objects. IS this the case?
With Orion and/or with other containers?
So, in the case of web-application development, I prefer the MVC model of
development. I wrote a pretty small and fast MVC framework called Theseus
for just this purpose, and I am about to make it a pluggable framework with
full performance and scalability in mind, including automatically storing a
bean back into the session so a developer doesn't have to do this in any of
the action methods. Thats a little off topic with this thread, but my point
is, it seems that there is more to making a session fail-over scalable site
than just adding hardware and having a capable app server. You still need to
code the application to handle this.
Case in point, I ran my simple application using my framework which
currently does NOT reset the bean back into the HttpSession. I never once
saw the "sending..." message that I DID see with the SessionServlet. In the
SessionServlet, the object is retrieved from the session, updated, then
stored back into it. Thus, I am pretty sure, at least with Orion that you
have to always set an object back into the HttpSession if you want it
replicated. I really want to find out if this is the case with all session
managers and how they handle session replication for fail-over.
I look forward to any replies, whether it be on how to set up Orion to
properly fail over (or if its a current bug..couldn't find it in Bugzilla
though), as well as how the whole replication works..if its a per object,
per users session or the entire servlet context and all sessions, and when
it does this.
Thanks.
