> From: Gal Robert [mailto:[EMAIL PROTECTED] 
> Often happens, that we must correct a little error in business logic.
> In these cases we usually patch a class file, and replace it in the 
> application, then redeploy it.
>  From your (and other) responses it seems, there's no correct way to
> do such a patch without redeploying the application.

Unfortunately, I agree.

> On the other hand, your idea about tomcat clustering, and redirecting 
> requests sounds quite interesting. I think, this would 
> satisfy the above
> requirement. Can you give me some more information about your 
> idea? Does it require a deep know-how?

Not really, but it requires that your application has a certain feature:
that users using the application are independent, or that they only
interact through a common back-end system that is not part of the
webapp.  A bulletin board is a reasonable example: users can post, and
the posts are stored in a common database.  Each user accesses posts
through the webapp.  It wouldn't matter if each user had their own
separate webapp accessing the posts; nothing would appear to change.
Many applications have this feature; yours may well.  By contrast, an
interactive chat system that uses (say) a Map in the context to know
who's online doesn't have this feature - if you separate it across two
servers, each would only see half the users.

The multiple-server, staged upgrade is a standard technique in
high-availability systems, where you want to have more than one of
everything for redundancy.  I'm adapting it a little here, to fulfil
your requirement of on-the-fly upgrades.  No doubt others on this list
can fill in more details.  I should add a disclaimer: I've done this
with credit-card processing systems, but not with Tomcat, so I'm
speaking from theory.  The above should be taken with a large pinch of
NaCl until someone corroborates it for Tomcat.  That said, search the
archives for this list, as I recall a couple of discussions from people
who had almost exactly this setup.

If you have n identical nodes and a way of shifting the load away from
one of them, you can produce an idle node - at which point you can
upgrade it to the new version.  This part requires no more than several
identical Tomcat (or other servlet container) instances.  For high
availability, you'd run them on different machines.  For high
flexibility and to allow upgrades (your situation), you could choose to
combine them onto one machine if you wished to take the reliability risk
and understood the performance characteristics of the system.  Often,
it's cheaper for the business to buy another pizza-box server and shove
it in the rack than it is to pay someone's time to investigate the
'cheaper' way of doing it!

The new part is that you need a front-end load balancer.  This can be
done in hardware (Cisco's mid- and high-end routers have this facility,
for example).  I strongly suspect it can also be done in software; I'd
be very surprised if nobody had written this into some combination of
Linux kernel and modules.  I don't know whether it can be done using an
Apache front-end and JK; I suspect someone on this list could enlighten
us.  The load balancer sits 'in front of' your n identical nodes and has
its own IP address, which is the IP address by which your users connect
to the application.  That load balancer then redirects requests to the
nodes according to its policy.  That policy needs to include 'sticky'
sessions: a set of requests from a given user will always be directed to
the same node.  If your organisation has no experience of setting one of
these up, you'd probably want to buy in the expertise.

Now, to upgrade a node (say node B of two nodes labelled A and B), you
change the load balancer's policy: existing sessions remain sticky, but
all new sessions go to node A.  Monitor the number of sessions on node
B; when it drops to zero, it's safe to upgrade B, restart it and test it
- you know that no users will come in and disturb your tests.  Then
change load balancer policy to send new sessions to node B, wait for all
the sessions on A to complete, and do the symmetrical upgrade on A.
Finally, set your load balancer policy back to even distribution if you
wish to use the redundancy in this system.

You can short-circuit the whole process if you don't want the
redundancy: the load balancer always directs traffic to one 'current'
node, and most of the time you have one 'spare' node.  To upgrade, make
the change on the 'spare' node and test, then change policy to make the
'spare' node receive all new sessions.  Once all the sessions have
finished on the old 'active' node, the roles reverse - you have a new
'active' node that's been upgraded, and the 'spare' running the prior
version of the software.

                - Peter
--
Peter Crowther, Director, Melandra Limited
John Dalton House, 121 Deansgate, Manchester M3 2AB
t: +44 (0)161 828 8736  f: +44 (0)161 832 5683

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to