|
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.
|
