I'll vote for this too. My client freezes for about 50 seconds when I get to Antonio Fiol Bonn�n's emails. So I've leared to not click on them. And yes, it's Outlook, but hey that's what we use here at work. My client at home (Firefox/thunderbird) does not have this problem.
> -----Original Message----- > From: Neal [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 16, 2004 11:10 AM > To: 'Tomcat Users List' > Subject: RE: Digitally Signing Posts > > > Ha! I said the same thing a month ago and was completely ignored. :-\ > > -----Original Message----- > From: Angus Mezick [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 16, 2004 6:44 AM > To: Tomcat Users List > Subject: RE: Digitally Signing Posts > > +1 > --Angus > > > -----Original Message----- > > From: George Sexton [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, March 16, 2004 8:56 AM > > To: 'Tomcat Users List' > > Cc: [EMAIL PROTECTED] > > Subject: RE:Digitally Signing Posts > > > > > > Would you either > > > > A) Not sign posts to the group > > > > Or > > > > B) Sign the posts with a working certificate? > > > > Everytime I hit one of your messages, it locks my mail client > > up for 30 > > seconds. > > > > > > Warning: > > The Certificate Revocation List needed to verify the signing > > certificate > > is either unavailable or it has expired. > > Signed by [EMAIL PROTECTED] using RSA/SHA1 at 12:48:09 AM > > 3/16/2004. > > > > -----Original Message----- > > From: Antonio Fiol Bonn�n [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, March 16, 2004 12:48 AM > > To: Tomcat Users List > > Subject: Re: Load balancing for uptime > > > > > > Hi, > > > > 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. > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
