Return-Path: Delivered-To: apmail-tomcat-users-archive@www.apache.org Received: (qmail 16467 invoked from network); 3 Sep 2009 03:23:14 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 3 Sep 2009 03:23:14 -0000 Received: (qmail 62817 invoked by uid 500); 3 Sep 2009 03:23:10 -0000 Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org Received: (qmail 62758 invoked by uid 500); 3 Sep 2009 03:23:09 -0000 Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Users List" Delivered-To: mailing list users@tomcat.apache.org Received: (qmail 62747 invoked by uid 99); 3 Sep 2009 03:23:09 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Sep 2009 03:23:09 +0000 X-ASF-Spam-Status: No, hits=4.6 required=10.0 tests=FS_REPLICA,HTML_FONT_FACE_BAD,HTML_MESSAGE,HTML_OBFUSCATE_05_10,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of sumedhsakdeo@gmail.com designates 72.14.220.156 as permitted sender) Received: from [72.14.220.156] (HELO fg-out-1718.google.com) (72.14.220.156) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Sep 2009 03:23:01 +0000 Received: by fg-out-1718.google.com with SMTP id e12so584398fga.0 for ; Wed, 02 Sep 2009 20:22:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=OUvyQ3268t0X7DqsV7gxY6x5sIHxp0XDixow0OvfHUs=; b=l6ecaVnJiu4iaCdzEn6nAECPiQbx5G7rEYLpmBAM2tsc2xRLucrGCo9azJJhWyYI+M Ry14hZo3Kb2mGlkkHW/kY5ZJgivkYD7ovqZ9pVDVKkC5kOEr3D1s7lGDeyzTJZII3JuB rwIGEpS+k2cnR5edsdNq2UJ4YneogCOFgTTrg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=bmmqDOtCv9YyCpfhMP+vABp8ZfG2VTcxToLlWqFMLfYCpGB0uI1HO9b8YXFoSLasHf fqoUuBBl4yYEQ9N9TEjo3afrIG0eE5oCewl+B0tqY7baJWWI48JX7T2R73D6qllF67yV wVkx2Hghfx4CiHOk4YWXMwmuwIivk4mw2t/ts= MIME-Version: 1.0 Received: by 10.239.142.145 with SMTP id g17mr864421hba.55.1251948159702; Wed, 02 Sep 2009 20:22:39 -0700 (PDT) In-Reply-To: <15060d5e0909021759n20754f41u418bd4f98568b717@mail.gmail.com> References: <4A9EBD30.6060104@kippdata.de> <15060d5e0909021756r4794911bp3f34ab32945d54bd@mail.gmail.com> <15060d5e0909021759n20754f41u418bd4f98568b717@mail.gmail.com> Date: Thu, 3 Sep 2009 08:52:39 +0530 Message-ID: Subject: Re: Apache Server failover and session replication From: Sumedh Sakdeo To: Tomcat Users List Content-Type: multipart/alternative; boundary=001485f27fde561b220472a3e5c0 X-Virus-Checked: Checked by ClamAV on apache.org --001485f27fde561b220472a3e5c0 Content-Type: text/plain; charset=ISO-8859-1 http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html *How it Works * 1. TomcatA starts up 2. TomcatB starts up (Wait that TomcatA start is complete) 3. TomcatA receives a request, a session S1 is created. 4. TomcatA crashes 5. TomcatB receives a request for session S1 6. TomcatA starts up 7. TomcatA receives a request, invalidate is called on the session (S1) 8. TomcatB receives a request, for a new session (S2) 9. TomcatA The session S2 expires due to inactivity. section describes the steps.7-9 steps confusing. Does tomcat 6 even support such scenario? --Sumedh On Thu, Sep 3, 2009 at 6:29 AM, Shaun Senecal wrote: > After re-reading your initial post, the problems might not be as related as > I thought since at no point did replication "stop" for me. > > > On Thu, Sep 3, 2009 at 9:56 AM, Shaun Senecal >wrote: > > > We had a similar problem with Tomcat 6 using clustering. It turns out > that > > the SSO information is only propagated while all instances are running. > If > > Instance-A fails, several users then log in to Instance-B, then > Instance-A > > comes back up, all of the SSO information for the users that logged in > > during the downtime is not included in Instance-A so those users are > forced > > to re-login once the load balancer sends them to that instance. > > > > I wrote a fix for it, which might be useful for you. However, it hasnt > > been fully tested and is designed to only share the SSO information at > > startup, not all Session information. If Tomcat doenst handle this case, > > then the fix I wrote should be easily extended to handle that. > Basically, > > when an instance comes up it broadcasts a request for all known SSO > > information to the cluster. It then takes the first response it gets and > > continues processing as normal. > > > > Let me know if you dont find a proper solution to the problem and I will > > try to dig up that fix. My intention was to post it back to the group, > but > > I got sidetracked once we (temporarily) stopped using clustering. > > > > > > Shaun > > > > > > On Thu, Sep 3, 2009 at 3:52 AM, Sumedh Sakdeo >wrote: > > > >> Hi Rainer, > >> > >> I am using Tomcat session clustering and Apache Http Server for LB(using > >> mod_jk module). Also, using Tomcat 6. I have made appropriate changes > to > >> worker.properties and httpd.conf. Also I have made appropriate changes > to > >> server.xml on each tomcat. > >> > >> Thanks, > >> Sumedh > >> > >> On Thu, Sep 3, 2009 at 12:15 AM, Rainer Jung >> >wrote: > >> > >> > On 02.09.2009 19:57, Sumedh Sakdeo wrote: > >> > > Hello All, > >> > > I have a setup with two tomcat instances(A&B). I have > >> > configured > >> > > an apache web server 2.2 for load balancing and fail over. Setup > looks > >> > fine > >> > > as per the configurations suggested. Let tomcat A be handling some > >> > request > >> > > at sometime. When tomcat instance(A) goes down, the session is > >> replicated > >> > to > >> > > another tomcat instance(B) successfully. Now tomcat instance B is > >> > handling > >> > > those requests. Till this point everything goes fine, but when I > bring > >> up > >> > > tomcat instance(A) and after that tomcat instance(B) goes down, the > >> > session > >> > > is no longer replicated. What might be the issue? In status page of > >> > apache > >> > > server I see even if node status is OK session is not replicated to > >> fail > >> > > over node for second time. > >> > > >> > How do you replicate? Are you using Tomcat session clustering? Tomcat > >> > 5.5 or Tomcat 6? > >> > > >> > Regards, > >> > > >> > Rainer > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org > >> > For additional commands, e-mail: users-help@tomcat.apache.org > >> > > >> > > >> > > > > > --001485f27fde561b220472a3e5c0--