You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Stephen Nelson-Smith <sa...@gmail.com> on 2008/09/21 08:08:49 UTC

Re: mod_ajp and Load-Balancing Issue

Good morning,

> By "error", I just meant that I'd get redirected to the login page
> instead of the expected page. Sorry to confuse. There are no error
> pages, logs or messages. Just that I got switched to a different node.

<snip>

>> If you want to debug a little more: In Tomcat you can add a
>> %S to your log pattern, which will log the session id. In
>> httpd you can log the Set-Cookie outgoing header
>> "%{Set-Cookie}o" and the JSESSIONID cookie "%{JSESSIONID}C".
>> If you are not using cookies, you can of course see the
>> jsessionid path parameter dircetly in the logged URL.
>
> Thanks. I'll do that. (First time apache troubleshooter here). I'll get
> back on the results.

Did you get this to work?  I have exactly the same problem.  Apache
2.2 using mod_proxy_ajp with 3 x tomcat 6 instances behind it.  If I
remove two of the tomcats from the balancer pool, the application
works.  When I put them back in, I can log into one of the servers,
but as soon as I change screens on the application, I'm logged out.
This is because if the application detects a session change, it logs
the user out.  I need the load-balancer to direct traffic to the same
tomcat server on which the session began unless that server is down.

S.

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: mod_ajp and Load-Balancing Issue

Posted by Shaun Senecal <ss...@gmail.com>.
Oops.  My orignal post is here (
http://www.nabble.com/Clustered-SSO-improperly-invalidated-upon-web-application-shutdown-to19447895.html#a19447895).
It might descirbe the problem better to see if this is the same issue you
are facing.


On Mon, Sep 22, 2008 at 9:45 AM, Shaun Senecal <ss...@gmail.com>wrote:

> Are you using the ClusterSingleSignOn Valve?  If you are, this sounds like
> the behaviour I was seeing, and have since resolved.  The problem I had
> (well, part of the problem) was that the SSO information was not being
> replicated across the cluster when tomcat instances were brought back up.
> This meant that as long as the user was connecting to one of the -original-
> cluster instances everything was ok.  However, as soon as the client gets
> directed to one of the newly brought up instances they have no SSO info and
> are prompted for login.
>
> The solution was relatively simple.  I had to extend the
> ClusterSingleSignOn and ClusterSingleSignOnListener classes to ensure that
> A, when an instance is brought down the SSO information is not deactivated
> across the cluster and, B, that when an instance is brought back up that it
> syncs with the cluster to gather all currently known SSO info.
>
> I am planning on merging the information into the ClusterSingleSignOn and
> ClusterSingleSignOnListener classes and proposing a patch to Tomcat, but no
> one has responded to my original post and I havent had the chance to truley
> verify my fix.  It seems to be running and has been for a while now, but I
> wouldnt put it into a production system just yet.
>
> S.
>
>
> On Sun, Sep 21, 2008 at 3:08 PM, Stephen Nelson-Smith <sa...@gmail.com>wrote:
>
>> Good morning,
>>
>> > By "error", I just meant that I'd get redirected to the login page
>> > instead of the expected page. Sorry to confuse. There are no error
>> > pages, logs or messages. Just that I got switched to a different node.
>>
>> <snip>
>>
>> >> If you want to debug a little more: In Tomcat you can add a
>> >> %S to your log pattern, which will log the session id. In
>> >> httpd you can log the Set-Cookie outgoing header
>> >> "%{Set-Cookie}o" and the JSESSIONID cookie "%{JSESSIONID}C".
>> >> If you are not using cookies, you can of course see the
>> >> jsessionid path parameter dircetly in the logged URL.
>> >
>> > Thanks. I'll do that. (First time apache troubleshooter here). I'll get
>> > back on the results.
>>
>> Did you get this to work?  I have exactly the same problem.  Apache
>> 2.2 using mod_proxy_ajp with 3 x tomcat 6 instances behind it.  If I
>> remove two of the tomcats from the balancer pool, the application
>> works.  When I put them back in, I can log into one of the servers,
>> but as soon as I change screens on the application, I'm logged out.
>> This is because if the application detects a session change, it logs
>> the user out.  I need the load-balancer to direct traffic to the same
>> tomcat server on which the session began unless that server is down.
>>
>> S.
>>
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>

Re: mod_ajp and Load-Balancing Issue

Posted by Stephen Nelson-Smith <sa...@gmail.com>.
On Mon, Sep 22, 2008 at 1:45 AM, Shaun Senecal <ss...@gmail.com> wrote:
> Are you using the ClusterSingleSignOn Valve?

I'm not, no.

I have httpd 2.2 on the front-end, with a balancer pool thus:

ProxyRequests Off
ProxyVia Off
ProxyPreserveHost On
ProxyErrorOverride On
ProxyTimeout 60

<Proxy balancer://tomcat>
       BalancerMember ajp://10.1.1.231:8009 min=10 max=50
       BalancerMember ajp://10.1.1.232:8009 min=10 max=50
       #BalancerMember ajp://10.1.1.233:8009 min=10 max=50
       Order deny,allow
       Allow from all
</Proxy>

ProxyPass /             balancer://tomcat/ lbmethod=byrequests
stickysession=JSESSIONID nofailover=On
ProxyPass /servlet              balancer://tomcat/servlet
lbmethod=byrequests stickysession=JSESSIONID nofailover=On
ProxyPass /piston               balancer://tomcat/piston
lbmethod=byrequests stickysession=JSESSIONID nofailover=On
ProxyPass /manager              balancer://tomcat/manager
lbmethod=byrequests stickysession=JSESSIONID nofailover=On
ProxyPass /link                 balancer://tomcat/link
lbmethod=byrequests stickysession=JSESSIONID nofailover=On
ProxyPass /ajax                 balancer://tomcat/ajax
lbmethod=byrequests stickysession=JSESSIONID nofailover=On


When I browse to the login page, I see a jsessionid in firebug.  I
login, the jessionid cookie stays the same.  I try to navigate within
the application, and wherever I click I end up on the login screen
again, with the message "user has timed out".  The cookie doesn't
change until I login, in which case I see a new cookie.

If I comment out two of the BalancerMembers, the app works fine.  If I
add one in (as above) I get the same behaviour.

>From reading the archives, it seems I should set a route in httpd.conf
snippet and a jvmroute in the engine tag for each tomcat server.xml.
I'll try this shortly, but it seems as if Richard did this, but still
experienced problems.

Thanks,

S.

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: mod_ajp and Load-Balancing Issue

Posted by Shaun Senecal <ss...@gmail.com>.
Are you using the ClusterSingleSignOn Valve?  If you are, this sounds like
the behaviour I was seeing, and have since resolved.  The problem I had
(well, part of the problem) was that the SSO information was not being
replicated across the cluster when tomcat instances were brought back up.
This meant that as long as the user was connecting to one of the -original-
cluster instances everything was ok.  However, as soon as the client gets
directed to one of the newly brought up instances they have no SSO info and
are prompted for login.

The solution was relatively simple.  I had to extend the ClusterSingleSignOn
and ClusterSingleSignOnListener classes to ensure that A, when an instance
is brought down the SSO information is not deactivated across the cluster
and, B, that when an instance is brought back up that it syncs with the
cluster to gather all currently known SSO info.

I am planning on merging the information into the ClusterSingleSignOn and
ClusterSingleSignOnListener classes and proposing a patch to Tomcat, but no
one has responded to my original post and I havent had the chance to truley
verify my fix.  It seems to be running and has been for a while now, but I
wouldnt put it into a production system just yet.

S.

On Sun, Sep 21, 2008 at 3:08 PM, Stephen Nelson-Smith <sa...@gmail.com>wrote:

> Good morning,
>
> > By "error", I just meant that I'd get redirected to the login page
> > instead of the expected page. Sorry to confuse. There are no error
> > pages, logs or messages. Just that I got switched to a different node.
>
> <snip>
>
> >> If you want to debug a little more: In Tomcat you can add a
> >> %S to your log pattern, which will log the session id. In
> >> httpd you can log the Set-Cookie outgoing header
> >> "%{Set-Cookie}o" and the JSESSIONID cookie "%{JSESSIONID}C".
> >> If you are not using cookies, you can of course see the
> >> jsessionid path parameter dircetly in the logged URL.
> >
> > Thanks. I'll do that. (First time apache troubleshooter here). I'll get
> > back on the results.
>
> Did you get this to work?  I have exactly the same problem.  Apache
> 2.2 using mod_proxy_ajp with 3 x tomcat 6 instances behind it.  If I
> remove two of the tomcats from the balancer pool, the application
> works.  When I put them back in, I can log into one of the servers,
> but as soon as I change screens on the application, I'm logged out.
> This is because if the application detects a session change, it logs
> the user out.  I need the load-balancer to direct traffic to the same
> tomcat server on which the session began unless that server is down.
>
> S.
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>