To keep it up, you will need to setup session replication (See your Cluster element in server.xml), either in-memory or JDBC. Both are supposed to work.
However, that implies several things:
- Your session must contain Seralizable objects only.
- Your performance will be worse (how much worse highly depends on the size of the objects in your session)
And... nobody guarantees that your memory leak (if there is one) is not related to the information stored in sessions.
Depending on your load balancer, there is another option (IMHO, better for your case).
There are some load balancers that allow you to turn a server down while keeping it up for currently established sessions, for a certain time. That allows you NOT to use session replication, thus not replicating any instability related to sessions.
Oh, and last, if you need a good consultant for fixing, optimizing or redesigning your application, you just found one ;-)
Yours,
Antonio Fiol
Derek Clarkson wrote:
Hi all,
We have an app written in a mix of JSP, servlets and struts across 3
instances of apache, tomcat and an RMI server. To say that it's a pile of
smelly stuff is an understatement, however it works (mostly) and our
customers depend on it. At least once a week though it crashes with out of
memory errors.
Until we can redesign and fix it we are looking for a way to keep it up. One
suggest has been to have two servers running with a common DB server, and to
use a load balancer to allow us to keep one server up whilst we boot the
other, then vice versa. Thus on a daily basis we can reboot both machines
whilst mainting a working system for the users.
Can anyone see any problems with this ? I'm concerned about issue realed to session management, etc.
Ciao Derek
______________________________________________________________________
This email, including attachments, is intended only for the addressee
and may be confidential, privileged and subject to copyright. If you
have received this email in error, please advise the sender and delete
it. If you are not the intended recipient of this email, you must not
use, copy or disclose its content to anyone. You must not copy or communicate to others content that is confidential or subject to copyright, unless you have the consent of the content owner.
smime.p7s
Description: S/MIME Cryptographic Signature
