You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Okubo, Yasushi (TSD)" <Ya...@takedasd.com> on 2010/06/22 05:03:21 UTC
question for sso session replication in tomcat 6.0.26
Hi experts
I found this old email from archive in TC 5.5.23.
Does this problem still exist in tomcat 6.0.x or 6.0.26?
When failover occurs, sso session id is updated with new number after
forcing a user to relogin to the application since sso session id is not
replicated and rewritten correctly. Could someone explain what is
expected in current tomcat 6.0.x cluster upon failover? Should sso
session id is replicated correctly in tomcat 6.0.x?
Thanks,
yasushi
ROOKIE wrote:
Hi,
I have a problem with tomcat cluster + mod_proxy load balancer :
We have a main app which authenticate itself to a webapp and from this
app one
can launch embedded apps which use the SSO cookie to access other
webapps on
the server (Single-Sign-On for the user).
Things are working perfectly for the normal cookie but not for the sso
cookie.
The problem I have is that tomcat does not replicate SSO sessions so
when these embedded apps route through the load balancer we get 401s on
all the other cluster members except the one which actually generated
the SSO cookie.
I wanted to know if we can edit the SSO cookie generated by tomcat to
also
contain the jvmRoute parameter so that the load balancer directly goes
to the
correct cluster member.
I tried doing this in my code by fetching the SSO cookie and appending
to it
the jvmRoute as follows :
HttpServletRequest request =
(HttpServletRequest)Security.getContext(HttpServletRequest.class);
HttpServletResponse response =
(HttpServletResponse)Security.getContext(HttpServletResponse.class);
if(request != null) {
String jvmRoute = "Vinod_Cluster_1"; // as mentioned in
server.xml
Cookie[] cookies = request.getCookies();
for(int nc=0; cookies != null && nc < cookies.length; nc++)
{
if(_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
_sessionId = cookies[nc].getValue();
}
else if(_SSO_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
_ssoSessionId = cookies[nc].getValue();
if (!_ssoSessionId.contains("." + jvmRoute)) {
_ssoSessionId += "." + jvmRoute;
response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME, _ssoSessionId));
}
}
But after this I started getting 401s from even the correct cluster
member. My guess is addCookie doesnt update the cookie in tomcat's cache
which is reasonable.
Other thought was to edit tomcat's sso cookie generation code to append
the
jvmRoute to the sso cookie.
Is there an better way to achieve this in my code base ?
Thanks In Advance,
Vinod
Re: question for sso session replication in tomcat 6.0.26
Posted by Pid <pi...@pidster.com>.
On 22/06/2010 06:09, Andrew Bruno wrote:
> Oh sorry, I re-read your answer. Not sure why SSO is not working, be
> interested to find out though..
You were right to ask about configuration.
We can't really begin to analyze the problem until we've seen the
cluster config and know the usual OS, JVM,
HTTPD/mod_jk/mod_proxy/loadbalancer & other relevant version/config
information.
p
> AB
>
> On Tue, Jun 22, 2010 at 3:04 PM, Andrew Bruno <an...@gmail.com> wrote:
>> Hi Yasushi
>>
>> In your serverl.xml have you added the jvmroute to the Engine?
>>
>> i.e.
>>
>> <Engine name="Catalina" defaultHost="localhost" jvmRoute="1">
>>
>> Andrew
>>
>> On Tue, Jun 22, 2010 at 2:50 PM, Okubo, Yasushi (TSD) <Ya...@takedasd.com> wrote:
>>> Hi Andrew
>>>
>>> Thank for your post. When I checked the session id from firefox, sso session id [jsessionidsso] does not have jvmroute info, but only jsessionid has jvmroute. So, session replication upon failover is working fine, but singlesionon upon failover is not working on tomcat 6.0.x (including 6.0.26).
>>>
>>> yasushi
>>>
>>> -----Original Message-----
>>> From: Andrew Bruno [mailto:andrew.bruno@gmail.com]
>>> Sent: Monday, June 21, 2010 9:18 PM
>>> To: Tomcat Users List
>>> Subject: Re: question for sso session replication in tomcat 6.0.26
>>>
>>> Looking at the code I think this is wrong
>>>
>>> if (!_ssoSessionId.contains("." + jvmRoute)) {
>>> _ssoSessionId += "." + jvmRoute;
>>> response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME, _ssoSessionId));
>>> }
>>>
>>> The original sessionId will already have the "."+_any_other_jvmRoute
>>> included, so you need to substring it, and append the new jvmRoute.
>>>
>>> _ssoSessionId= _ssoSessionId.substring(0, _ssoSessionId.indexOf("."))
>>>
>>> and then add
>>>
>>> _ssoSessionId += "." + jvmRoute;
>>>
>>> AB
>>>
>>> On Tue, Jun 22, 2010 at 1:03 PM, Okubo, Yasushi (TSD)
>>> <Ya...@takedasd.com> wrote:
>>>> Hi experts
>>>>
>>>>
>>>>
>>>> I found this old email from archive in TC 5.5.23.
>>>>
>>>> Does this problem still exist in tomcat 6.0.x or 6.0.26?
>>>>
>>>>
>>>>
>>>> When failover occurs, sso session id is updated with new number after
>>>> forcing a user to relogin to the application since sso session id is not
>>>> replicated and rewritten correctly. Could someone explain what is
>>>> expected in current tomcat 6.0.x cluster upon failover? Should sso
>>>> session id is replicated correctly in tomcat 6.0.x?
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> yasushi
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ROOKIE wrote:
>>>> Hi,
>>>> I have a problem with tomcat cluster + mod_proxy load balancer :
>>>>
>>>> We have a main app which authenticate itself to a webapp and from this
>>>> app one
>>>> can launch embedded apps which use the SSO cookie to access other
>>>> webapps on
>>>> the server (Single-Sign-On for the user).
>>>>
>>>> Things are working perfectly for the normal cookie but not for the sso
>>>> cookie.
>>>>
>>>>
>>>> The problem I have is that tomcat does not replicate SSO sessions so
>>>> when these embedded apps route through the load balancer we get 401s on
>>>> all the other cluster members except the one which actually generated
>>>> the SSO cookie.
>>>>
>>>> I wanted to know if we can edit the SSO cookie generated by tomcat to
>>>> also
>>>> contain the jvmRoute parameter so that the load balancer directly goes
>>>> to the
>>>> correct cluster member.
>>>>
>>>>
>>>> I tried doing this in my code by fetching the SSO cookie and appending
>>>> to it
>>>> the jvmRoute as follows :
>>>>
>>>> HttpServletRequest request =
>>>> (HttpServletRequest)Security.getContext(HttpServletRequest.class);
>>>> HttpServletResponse response =
>>>> (HttpServletResponse)Security.getContext(HttpServletResponse.class);
>>>> if(request != null) {
>>>> String jvmRoute = "Vinod_Cluster_1"; // as mentioned in
>>>> server.xml
>>>> Cookie[] cookies = request.getCookies();
>>>> for(int nc=0; cookies != null && nc < cookies.length; nc++)
>>>> {
>>>> if(_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
>>>> _sessionId = cookies[nc].getValue();
>>>> }
>>>>
>>>> else if(_SSO_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
>>>>
>>>> _ssoSessionId = cookies[nc].getValue();
>>>> if (!_ssoSessionId.contains("." + jvmRoute)) {
>>>> _ssoSessionId += "." + jvmRoute;
>>>>
>>>> response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME, _ssoSessionId));
>>>> }
>>>>
>>>>
>>>> }
>>>>
>>>>
>>>> But after this I started getting 401s from even the correct cluster
>>>> member. My guess is addCookie doesnt update the cookie in tomcat's cache
>>>> which is reasonable.
>>>>
>>>> Other thought was to edit tomcat's sso cookie generation code to append
>>>> the
>>>> jvmRoute to the sso cookie.
>>>>
>>>>
>>>> Is there an better way to achieve this in my code base ?
>>>>
>>>> Thanks In Advance,
>>>> Vinod
>>>>
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: question for sso session replication in tomcat 6.0.26
Posted by Pid <pi...@pidster.com>.
On 13/07/2010 21:58, Okubo, Yasushi (TSD) wrote:
>
>
> -----Original Message-----
> From: Pid [mailto:pid@pidster.com]
> Sent: Friday, June 25, 2010 4:29 AM
> To: Tomcat Users List
> Subject: Re: question for sso session replication in tomcat 6.0.26
>
> On 24/06/2010 21:49, Okubo, Yasushi (TSD) wrote:
>> My bad.
>>
>> I added *.jsp to the filter since it contains the path to index page
> as
>> follows. Now, I am wondering when sso session id is created and
>> replicated, is it when index.jsp was accessed or login.jsp was
> accessed?
>>
>> You had added it and have now removed it?
>
>> The normal session id is created when you access a JSP for the first
>> time, unless you have specifically configured JSPs to not create a
>> session. A session can also be created manually by a Filter or a
> Servlet.
>
>> The SSO session is created when the container login process completes
>> authentication successfully.
>
>> I'm not entirely clear on when SSO replication occurs - presumably
> only
>> when there's a change like session invalidation or creation.
>
>
>> p
>
> Hi Pid
>
> I tested with the latest v6.0.28, and sso session identifier propagation
> has been fixed.
>
> https://issues.apache.org/bugzilla/show_bug.cgi?id=49445
Great, pleased it's working for you now.
p
RE: question for sso session replication in tomcat 6.0.26
Posted by "Okubo, Yasushi (TSD)" <Ya...@takedasd.com>.
-----Original Message-----
From: Pid [mailto:pid@pidster.com]
Sent: Friday, June 25, 2010 4:29 AM
To: Tomcat Users List
Subject: Re: question for sso session replication in tomcat 6.0.26
On 24/06/2010 21:49, Okubo, Yasushi (TSD) wrote:
> My bad.
>
> I added *.jsp to the filter since it contains the path to index page
as
> follows. Now, I am wondering when sso session id is created and
> replicated, is it when index.jsp was accessed or login.jsp was
accessed?
>
> You had added it and have now removed it?
> The normal session id is created when you access a JSP for the first
> time, unless you have specifically configured JSPs to not create a
> session. A session can also be created manually by a Filter or a
Servlet.
> The SSO session is created when the container login process completes
> authentication successfully.
> I'm not entirely clear on when SSO replication occurs - presumably
only
> when there's a change like session invalidation or creation.
> p
Hi Pid
I tested with the latest v6.0.28, and sso session identifier propagation
has been fixed.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49445
Thanks,
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: question for sso session replication in tomcat 6.0.26
Posted by "Okubo, Yasushi (TSD)" <Ya...@takedasd.com>.
Hi Pid
I think I found a problem. Could you tell me how to fix this? Should I
report it to bugzilla?
SingleSignOn sessionEvent is destroying session, but DeltaSession is
notifying session expiration to other node on same cluster.
== singlesignon ==
protected void deregister(String ssoId) {
if (containerLog.isDebugEnabled())
containerLog.debug("Deregistering sso id '" + ssoId + "'");
// Look up and remove the corresponding SingleSignOnEntry
SingleSignOnEntry sso = null;
synchronized (cache) {
sso = (SingleSignOnEntry) cache.remove(ssoId);
}
if (sso == null)
return;
// Expire any associated sessions
Session sessions[] = sso.findSessions();
for (int i = 0; i < sessions.length; i++) {
if (containerLog.isTraceEnabled())
containerLog.trace(" Invalidating session " +
sessions[i]);
// Remove from reverse cache first to avoid recursion
synchronized (reverse) {
reverse.remove(sessions[i]);
}
// Invalidate this session
sessions[i].expire(); <-- this is calling
deltasession.expire(true), then dltasession.expire(notify, true)
}
// NOTE: Clients may still possess the old single sign on
cookie,
// but it will be removed on the next request since it is no
longer
// in the cache
}
== deltasesion ==
public void expire(boolean notify) {
expire(notify, true);
}
public void expire(boolean notify, boolean notifyCluster) {
if (expiring)
return;
String expiredId = getIdInternal();
if(expiredId != null && manager != null &&
manager instanceof DeltaManager) {
DeltaManager dmanager = (DeltaManager)manager;
CatalinaCluster cluster = dmanager.getCluster();
ClusterMessage msg = dmanager.requestCompleted(expiredId,
true);
if (msg != null) {
if(dmanager.doDomainReplication()) {
cluster.sendClusterDomain(msg);
} else {
cluster.send(msg);
}
}
}
super.expire(notify);
if (notifyCluster) {
if (log.isDebugEnabled())
log.debug(sm.getString("deltaSession.notifying",
((ClusterManager)manager).getName(),
new Boolean(isPrimarySession()),
expiredId));
if ( manager instanceof DeltaManager ) {
( (DeltaManager) manager).sessionExpired(expiredId);
}
}
}
Jun 28, 2010 3:05:53 PM org.apache.catalina.ha.session.DeltaManager stop
INFO: Manager [/cluster] expiring sessions upon shutdown
Jun 28, 2010 3:05:53 PM org.apache.catalina.authenticator.SingleSignOn
sessionEvent
FINE: Process session destroyed on
DeltaSession[EBEEECC91096DF7020488C1BDD75DF41.jvm2]
Jun 28, 2010 3:05:53 PM
org.apache.catalina.tribes.transport.nio.ParallelNioSender doLoop
FINER: ParallelNioSender - Sent msg:UniqueId{-2, -89, -62, -53, 103,
-39, 67, -1, -111, 52, -43, -84, -41, 66, 66, 31} at 2010-06-28
15:05:53.689 to tcp://{127, 0, 0, 1}:4010
Jun 28, 2010 3:05:53 PM
org.apache.catalina.tribes.group.ChannelCoordinator sendMessage
FINER: ChannelCoordinator - Sent msg:UniqueId{-2, -89, -62, -53, 103,
-39, 67, -1, -111, 52, -43, -84, -41, 66, 66, 31} at 2010-06-28
15:05:53.69 to {tcp://{127, 0, 0, 1}:4010}
Jun 28, 2010 3:05:53 PM org.apache.catalina.tribes.group.GroupChannel
send
FINER: GroupChannel - Sent msg:UniqueId{-2, -89, -62, -53, 103, -39, 67,
-1, -111, 52, -43, -84, -41, 66, 66, 31} at 2010-06-28 15:05:53.69 to
{tcp://{127, 0, 0, 1}:4010}
Jun 28, 2010 3:05:53 PM org.apache.catalina.tribes.group.GroupChannel
send
FINER: GroupChannel - Send Message:UniqueId{-2, -89, -62, -53, 103, -39,
67, -1, -111, 52, -43, -84, -41, 66, 66, 31} is
SingleSignOnMessage[action=3, ssoId=1C052A3927DC43EE6CAF27997F85C23B,
sessionId=null, username=null]
Jun 28, 2010 3:05:53 PM
org.apache.catalina.ha.authenticator.ClusterSingleSignOn deregister
FINE: SingleSignOnMessage Send with action 3
Jun 28, 2010 3:05:53 PM org.apache.catalina.authenticator.SingleSignOn
deregister
FINE: Deregistering sso id '1C052A3927DC43EE6CAF27997F85C23B'
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: question for sso session replication in tomcat 6.0.26
Posted by "Okubo, Yasushi (TSD)" <Ya...@takedasd.com>.
On 28/06/2010 23:19, Okubo, Yasushi (TSD) wrote:
> On 28/06/2010 21:21, Okubo, Yasushi (TSD) wrote:
>> Yes, I do.
>>
>> <Manager className="org.apache.catalina.ha.session.DeltaManager"
>> name="webclust2"
>> expireSessionsOnShutdown="false"
>
> Hmm.
>
> Can you unset the DeltaManager name attribute on all of your
instances?
>
>
> p
>
>
> Hi Pid
>
> I moved expireSessionOnShutdown, but the result was the same. I did
not
> see any difference.
>I didn't ask you to move expireSessionsOnShutdown, I asked you not to
>set the name attribute.
> /**
> * Return the descriptive short name of this Manager
implementation.>
> */
> public String getName() {
> return name;
> }
>It's the only thing I can see in your config that looks weird. I'm not
>really sure how it could affect things, but it might, so don't set it,
>please.
> By the way, when I shutdown the node1, it is getting action = 3 from
> SimpleTpcCluster, which means logout defined in
> singlesignonmessage.java. And clustersinglesignon is deregistering
this
> session id from other nodes.
>
> It looks like clustersinglesignon can send a message to other nodes
even
> if deltamanager.expireSessionsOnShutdown set to false. Why?
>I don't know. Certainly seems odd, I'll look into the
>expireSessionsOnShutdown attribute again tomorrow.
>p
>Hi Pid
>I removed name attribute from DeltaManager, but the result was the
same. >It looks like ClusteSingleSignOn is sending deregister message
through >SimpleTCPCluster when it received the message from
GroupChannel.
>Action = 3 is logout.
>Jun 29, 2010 10:25:16 AM org.apache.catalina.tribes.group.GroupChannel
send
>FINER: GroupChannel - Send Message:UniqueId{-47, 62, -63, -59, 37, 80,
72, >-98, -85, -5, 102, -1, -95, 34, 82, 25} is
SingleSignOnMessage[action=3, >ssoId=D01FF1E66C0D50C4418216F9974FA667,
sessionId=null, username=null]
It looks like DeltaManager stopped, so expireSessionsOnShutdown flag may
not have any impact on this matter.
After SingleSignOn.sessionEvent destroying the session value, and sso
ssession, somehow this message was propagated to simpleTpcCluster and
clusterSingleSignOn is deregisterting sso session by sending this
message to simpleTpcCluster. Is there any way to stop it?
Jun 28, 2010 3:05:53 PM org.apache.catalina.ha.session.DeltaManager stop
FINE: Manager [/cluster] is stopping
Jun 28, 2010 3:05:53 PM org.apache.catalina.ha.session.DeltaManager stop
INFO: Manager [/cluster] expiring sessions upon shutdown
Jun 28, 2010 3:05:53 PM org.apache.catalina.authenticator.SingleSignOn
sessionEvent
FINE: Process session destroyed on
DeltaSession[EBEEECC91096DF7020488C1BDD75DF41.jvm2]
Jun 28, 2010 3:05:53 PM
org.apache.catalina.tribes.transport.nio.ParallelNioSender doLoop
FINER: ParallelNioSender - Sent msg:UniqueId{-2, -89, -62, -53, 103,
-39, 67, -1, -111, 52, -43, -84, -41, 66, 66, 31} at 2010-06-28
15:05:53.689 to tcp://{127, 0, 0, 1}:4010
Jun 28, 2010 3:05:53 PM
org.apache.catalina.tribes.group.ChannelCoordinator sendMessage
FINER: ChannelCoordinator - Sent msg:UniqueId{-2, -89, -62, -53, 103,
-39, 67, -1, -111, 52, -43, -84, -41, 66, 66, 31} at 2010-06-28
15:05:53.69 to {tcp://{127, 0, 0, 1}:4010}
Jun 28, 2010 3:05:53 PM org.apache.catalina.tribes.group.GroupChannel
send
FINER: GroupChannel - Sent msg:UniqueId{-2, -89, -62, -53, 103, -39, 67,
-1, -111, 52, -43, -84, -41, 66, 66, 31} at 2010-06-28 15:05:53.69 to
{tcp://{127, 0, 0, 1}:4010}
Jun 28, 2010 3:05:53 PM org.apache.catalina.tribes.group.GroupChannel
send
FINER: GroupChannel - Send Message:UniqueId{-2, -89, -62, -53, 103, -39,
67, -1, -111, 52, -43, -84, -41, 66, 66, 31} is
SingleSignOnMessage[action=3, ssoId=1C052A3927DC43EE6CAF27997F85C23B,
sessionId=null, username=null]
Jun 28, 2010 3:05:53 PM
org.apache.catalina.ha.authenticator.ClusterSingleSignOn deregister
FINE: SingleSignOnMessage Send with action 3
Jun 28, 2010 3:05:53 PM org.apache.catalina.authenticator.SingleSignOn
deregister
FINE: Deregistering sso id '1C052A3927DC43EE6CAF27997F85C23B'
Jun 28, 2010 3:05:53 PM org.apache.catalina.authenticator.SingleSignOn
deregister
FINER: Invalidating session
DeltaSession[EBEEECC91096DF7020488C1BDD75DF41.jvm2]
Jun 28, 2010 3:05:53 PM org.apache.catalina.connector.MapperListener
handleNotification
FINE: Handle Catalina:type=Manager,path=/cluster,host=webclust2 type :
JMX.mbean.unregistered
Jun 28, 2010 3:05:53 PM org.apache.catalina.connector.MapperListener
handleNotification
FINE: Handle Catalina:type=Manager,path=/cluster,host=webclust2 type :
JMX.mbean.unregistered
Jun 28, 2010 3:05:53 PM org.apache.catalina.core.StandardContext
listenerStop
FINE: Sending application stop events
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: question for sso session replication in tomcat 6.0.26
Posted by "Okubo, Yasushi (TSD)" <Ya...@takedasd.com>.
-----Original Message-----
From: Pid [mailto:pid@pidster.com]
Sent: Monday, June 28, 2010 4:01 PM
To: Tomcat Users List
Subject: Re: question for sso session replication in tomcat 6.0.26
On 28/06/2010 23:19, Okubo, Yasushi (TSD) wrote:
> On 28/06/2010 21:21, Okubo, Yasushi (TSD) wrote:
>> Yes, I do.
>>
>> <Manager className="org.apache.catalina.ha.session.DeltaManager"
>> name="webclust2"
>> expireSessionsOnShutdown="false"
>
> Hmm.
>
> Can you unset the DeltaManager name attribute on all of your
instances?
>
>
> p
>
>
> Hi Pid
>
> I moved expireSessionOnShutdown, but the result was the same. I did
not
> see any difference.
>I didn't ask you to move expireSessionsOnShutdown, I asked you not to
>set the name attribute.
> /**
> * Return the descriptive short name of this Manager
implementation.>
> */
> public String getName() {
> return name;
> }
>It's the only thing I can see in your config that looks weird. I'm not
>really sure how it could affect things, but it might, so don't set it,
>please.
> By the way, when I shutdown the node1, it is getting action = 3 from
> SimpleTpcCluster, which means logout defined in
> singlesignonmessage.java. And clustersinglesignon is deregistering
this
> session id from other nodes.
>
> It looks like clustersinglesignon can send a message to other nodes
even
> if deltamanager.expireSessionsOnShutdown set to false. Why?
>I don't know. Certainly seems odd, I'll look into the
>expireSessionsOnShutdown attribute again tomorrow.
>p
Hi Pid
I removed name attribute from DeltaManager, but the result was the same.
It looks like ClusteSingleSignOn is sending deregister message through
SimpleTCPCluster when it received the message from GroupChannel.
Action = 3 is logout.
Jun 29, 2010 10:25:16 AM org.apache.catalina.tribes.group.GroupChannel
send
FINER: GroupChannel - Send Message:UniqueId{-47, 62, -63, -59, 37, 80,
72, -98, -85, -5, 102, -1, -95, 34, 82, 25} is
SingleSignOnMessage[action=3, ssoId=D01FF1E66C0D50C4418216F9974FA667,
sessionId=null, username=null]
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: question for sso session replication in tomcat 6.0.26
Posted by Pid <pi...@pidster.com>.
On 28/06/2010 23:19, Okubo, Yasushi (TSD) wrote:
> On 28/06/2010 21:21, Okubo, Yasushi (TSD) wrote:
>> Yes, I do.
>>
>> <Manager className="org.apache.catalina.ha.session.DeltaManager"
>> name="webclust2"
>> expireSessionsOnShutdown="false"
>
> Hmm.
>
> Can you unset the DeltaManager name attribute on all of your instances?
>
>
> p
>
>
> Hi Pid
>
> I moved expireSessionOnShutdown, but the result was the same. I did not
> see any difference.
I didn't ask you to move expireSessionsOnShutdown, I asked you not to
set the name attribute.
/**
* Return the descriptive short name of this Manager implementation.
*/
public String getName() {
return name;
}
It's the only thing I can see in your config that looks weird. I'm not
really sure how it could affect things, but it might, so don't set it,
please.
> By the way, when I shutdown the node1, it is getting action = 3 from
> SimpleTpcCluster, which means logout defined in
> singlesignonmessage.java. And clustersinglesignon is deregistering this
> session id from other nodes.
>
> It looks like clustersinglesignon can send a message to other nodes even
> if deltamanager.expireSessionsOnShutdown set to false. Why?
I don't know. Certainly seems odd, I'll look into the
expireSessionsOnShutdown attribute again tomorrow.
p
> Then, how can Tomcat differentiate event between shutdown and logout?
>
> == Catalina.out ==
> Jun 28, 2010 3:05:53 PM org.apache.catalina.ha.session.DeltaManager stop
> FINE: Manager [/cluster] is stopping
> Jun 28, 2010 3:05:53 PM org.apache.catalina.ha.session.DeltaManager stop
> INFO: Manager [/cluster] expiring sessions upon shutdown
> Jun 28, 2010 3:05:53 PM org.apache.catalina.authenticator.SingleSignOn
> sessionEvent
> FINE: Process session destroyed on
> DeltaSession[EBEEECC91096DF7020488C1BDD75DF41.jvm2]
> Jun 28, 2010 3:05:53 PM
> org.apache.catalina.tribes.transport.nio.ParallelNioSender doLoop
> FINER: ParallelNioSender - Sent msg:UniqueId{-2, -89, -62, -53, 103,
> -39, 67, -1, -111, 52, -43, -84, -41, 66, 66, 31} at 2010-06-28
> 15:05:53.689 to tcp://{127, 0, 0, 1}:4010
> Jun 28, 2010 3:05:53 PM
> org.apache.catalina.tribes.group.ChannelCoordinator sendMessage
> FINER: ChannelCoordinator - Sent msg:UniqueId{-2, -89, -62, -53, 103,
> -39, 67, -1, -111, 52, -43, -84, -41, 66, 66, 31} at 2010-06-28
> 15:05:53.69 to {tcp://{127, 0, 0, 1}:4010}
> Jun 28, 2010 3:05:53 PM org.apache.catalina.tribes.group.GroupChannel
> send
> FINER: GroupChannel - Sent msg:UniqueId{-2, -89, -62, -53, 103, -39, 67,
> -1, -111, 52, -43, -84, -41, 66, 66, 31} at 2010-06-28 15:05:53.69 to
> {tcp://{127, 0, 0, 1}:4010}
> Jun 28, 2010 3:05:53 PM org.apache.catalina.tribes.group.GroupChannel
> send
> FINER: GroupChannel - Send Message:UniqueId{-2, -89, -62, -53, 103, -39,
> 67, -1, -111, 52, -43, -84, -41, 66, 66, 31} is
> SingleSignOnMessage[action=3, ssoId=1C052A3927DC43EE6CAF27997F85C23B,
> sessionId=null, username=null]
> Jun 28, 2010 3:05:53 PM
> org.apache.catalina.ha.authenticator.ClusterSingleSignOn deregister
> FINE: SingleSignOnMessage Send with action 3
> Jun 28, 2010 3:05:53 PM org.apache.catalina.authenticator.SingleSignOn
> deregister
> FINE: Deregistering sso id '1C052A3927DC43EE6CAF27997F85C23B'
> Jun 28, 2010 3:05:53 PM org.apache.catalina.authenticator.SingleSignOn
> deregister
> FINER: Invalidating session
> DeltaSession[EBEEECC91096DF7020488C1BDD75DF41.jvm2]
> Jun 28, 2010 3:05:53 PM org.apache.catalina.connector.MapperListener
> handleNotification
> FINE: Handle Catalina:type=Manager,path=/cluster,host=webclust2 type :
> JMX.mbean.unregistered
> Jun 28, 2010 3:05:53 PM org.apache.catalina.connector.MapperListener
> handleNotification
> FINE: Handle Catalina:type=Manager,path=/cluster,host=webclust2 type :
> JMX.mbean.unregistered
> Jun 28, 2010 3:05:53 PM org.apache.catalina.core.StandardContext
> listenerStop
> FINE: Sending application stop events
>
> == singlesignonmessage.java
> public class SingleSignOnMessage implements ClusterMessage, Serializable
> {
>
> public static final int ADD_SESSION = 1;
> public static final int DEREGISTER_SESSION = 2;
> public static final int LOGOUT_SESSION = 3;
>
>
>> -----Original Message-----
>> From: Pid [mailto:pid@pidster.com]
>> Sent: Monday, June 28, 2010 1:09 PM
>> To: Tomcat Users List
>> Subject: Re: question for sso session replication in tomcat 6.0.26
>>
>> On 28/06/2010 19:58, Okubo, Yasushi (TSD) wrote:
>>>
>>> Hi Pid
>>>
>>> I got more detailed log and it looks like clustersinglesignon is
>>> deregistering sso session on other nodes.
>>>
>>> 0. session destroyed C0641336BF4E6B4654927AA3337EAB9F.jvm1 by
> shutdown
>>> [on node1]
>>>
>>> 1. clustersinglesignon is calling singlesignon to invalidate session
>>> [ssoId=7BA0AB7AE2BFDB08CE2EBE8F42D3E89C] for node1
>>>
>>> 2, but it looks like this message came back to the node1 (through
>> group
>>> channel/mulitcast?)
>>>
>>> 3. then clustersinglesignon is deregistering this session again for
>>> ssoId=7BA0AB7AE2BFDB08CE2EBE8F42D3E89C. deregister method propagates
>>> this message to other nodes to deregister
>>> ssoId=7BA0AB7AE2BFDB08CE2EBE8F42D3E89C from all members in the same
>>> cluster.
>>>
>>>
>>> Is there any way to break this chain of actions to stop
>>> clustersinglesigon invoking deregister method?
>>
>> Do you have ClusterManager.expireSessionsOnShutdown set to false?
>>
>>
>> p
>>
>>> Jun 28, 2010 10:27:40 AM org.apache.catalina.ha.session.DeltaManager
>>> stop
>>> FINE: Manager [/cluster] is stopping
>>> Jun 28, 2010 10:27:40 AM org.apache.catalina.ha.session.DeltaManager
>>> stop
>>> INFO: Manager [/cluster] expiring sessions upon shutdown
>>> FINE: Process session destroyed on
>>> DeltaSession[C0641336BF4E6B4654927AA3337EAB9F.jvm1]
>>> Jun 28, 2010 10:27:40 AM
>>> org.apache.catalina.tribes.transport.nio.NioReplicationTask
>>> serviceChannel
>>> FINER: About to service key:sun.nio.ch.SelectionKeyImpl@1bd7b222
>>> Jun 28, 2010 10:27:40 AM
>>> org.apache.catalina.tribes.transport.nio.NioReplicationTask run
>>> FINER: Servicing key:sun.nio.ch.SelectionKeyImpl@1bd7b222
>>> Jun 28, 2010 10:27:40 AM
>>> org.apache.catalina.tribes.transport.nio.NioReplicationTask run
>>> FINER: Draining channel:sun.nio.ch.SelectionKeyImpl@1bd7b222
>>> Jun 28, 2010 10:27:40 AM
>>> org.apache.catalina.tribes.transport.nio.NioReplicationTask
>>> registerForRead
>>> FINER: Adding key for read event:sun.nio.ch.SelectionKeyImpl@1bd7b222
>>> Jun 28, 2010 10:27:40 AM
>>> org.apache.catalina.tribes.transport.nio.NioReceiver addEvent
>>> FINER: Adding event to
>>>
>>
> selector:org.apache.catalina.tribes.transport.nio.NioReplicationTask$1@5
>>> 637dde9
>>> Jun 28, 2010 10:27:40 AM
>>> org.apache.catalina.tribes.transport.nio.NioReplicationTask
>> drainChannel
>>> FINER: NioReplicationThread - Received msg:UniqueId{48, -7, -97,
> -123,
>>> -116, -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at
> 2010-06-28
>>> 10:27:40.78
>>> Jun 28, 2010 10:27:40 AM
>>> org.apache.catalina.tribes.transport.nio.NioReceiver events
>>> FINER: Processing event in
>>>
>>
> selector:org.apache.catalina.tribes.transport.nio.NioReplicationTask$1@5
>>> 637dde9
>>> Jun 28, 2010 10:27:40 AM
>>> org.apache.catalina.tribes.group.ChannelCoordinator messageReceived
>>> FINER: ChannelCoordinator - Received msg:UniqueId{48, -7, -97, -123,
>>> -116, -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at
> 2010-06-28
>>> 10:27:40.78 from tcp://{127, 0, 0, 1}:4010
>>> Jun 28, 2010 10:27:40 AM
>>> org.apache.catalina.tribes.transport.nio.NioReplicationTask$1 run
>>> FINER: Registering key for read:sun.nio.ch.SelectionKeyImpl@1bd7b222
>>> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.tribes.group.GroupChannel
>>> messageReceived
>>> FINER: GroupChannel - Received msg:UniqueId{48, -7, -97, -123, -116,
>>> -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28
>>> 10:27:40.78 from tcp://{127, 0, 0, 1}:4010
>>> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.tribes.group.GroupChannel
>>> messageReceived
>>> FINER: GroupChannel - Receive Message:UniqueId{48, -7, -97, -123,
>> -116,
>>> -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} is
>>> SingleSignOnMessage[action=3, ssoId=7BA0AB7AE2BFDB08CE2EBE8F42D3E89C,
>>> sessionId=null, username=null]
>>> Jun 28, 2010 10:27:40 AM org.apache.catalina.ha.tcp.SimpleTcpCluster
>>> messageReceived
>>> FINE: Assuming clocks are synched: Replication for
>>> 7BA0AB7AE2BFDB08CE2EBE8F42D3E89C#-#1277746060782 took=1277746060782
>> ms.
>>> Jun 28, 2010 10:27:40 AM
>>> org.apache.catalina.ha.authenticator.ClusterSingleSignOnListener
>>> messageReceived
>>> FINE: SingleSignOnMessage Received with action 3
>>> Jun 28, 2010 10:27:40 AM
>> org.apache.catalina.authenticator.SingleSignOn
>>> deregister
>>> FINE: Deregistering sso id '7BA0AB7AE2BFDB08CE2EBE8F42D3E89C'
>>> Jun 28, 2010 10:27:40 AM
>> org.apache.catalina.authenticator.SingleSignOn
>>> deregister
>>> FINER: Invalidating session
>>> DeltaSession[C0641336BF4E6B4654927AA3337EAB9F.jvm1]
>>> 2010 10:27:40 AM org.apache.catalina.tribes.group.GroupChannel
>>> messageReceived
>>> FINER: GroupChannel delivered[true] id:UniqueId{48, -7, -97, -123,
>> -116,
>>> -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17}
>>> Jun 28, 2010 10:27:40 AM
>>> org.apache.catalina.tribes.transport.nio.NioReplicationTask sendAck
>>> FINER: ACK sent to 55801
>>> Jun 28, 2010 10:27:40 AM
>>> org.apache.catalina.tribes.transport.nio.ParallelNioSender doLoop
>>> FINER: ParallelNioSender - Sent msg:UniqueId{48, -7, -97, -123, -116,
>>> -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28
>>> 10:27:40.785 to tcp://{127, 0, 0, 1}:4010
>>> Jun 28, 2010 10:27:40 AM
>>> org.apache.catalina.tribes.transport.nio.ParallelNioSender doLoop
>>> FINER: ParallelNioSender - Sent msg:UniqueId{48, -7, -97, -123, -116,
>>> -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28
>>> 10:27:40.786 to tcp://{127, 0, 0, 1}:4020
>>> Jun 28, 2010 10:27:40 AM
>>> org.apache.catalina.tribes.group.ChannelCoordinator sendMessage
>>> FINER: ChannelCoordinator - Sent msg:UniqueId{48, -7, -97, -123,
> -116,
>>> -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28
>>> 10:27:40.786 to {tcp://{127, 0, 0, 1}:4010, tcp://{127, 0, 0,
> 1}:4020}
>>> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.tribes.group.GroupChannel
>>> send
>>> FINER: GroupChannel - Sent msg:UniqueId{48, -7, -97, -123, -116, -54,
>>> 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28
>> 10:27:40.787
>>> to {tcp://{127, 0, 0, 1}:4010, tcp://{127, 0, 0, 1}:4020}
>>> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.tribes.group.GroupChannel
>>> send
>>> FINER: GroupChannel - Send Message:UniqueId{48, -7, -97, -123, -116,
>>> -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} is
>>> SingleSignOnMessage[action=3, ssoId=7BA0AB7AE2BFDB08CE2EBE8F42D3E89C,
>>> sessionId=null, username=null]
>>> Jun 28, 2010 10:27:40 AM
>>> org.apache.catalina.ha.authenticator.ClusterSingleSignOn deregister
>>> FINE: SingleSignOnMessage Send with action 3
>>> Jun 28, 2010 10:27:40 AM
>> org.apache.catalina.authenticator.SingleSignOn
>>> deregister
>>> FINE: Deregistering sso id '7BA0AB7AE2BFDB08CE2EBE8F42D3E89C'
>>> Jun 28, 2010 10:27:40 AM org.apache.catalina.connector.MapperListener
>>> handleNotification
>>> FINE: Handle Catalina:type=Manager,path=/cluster,host=webclust2 type
> :
>>> JMX.mbean.unregistered
>>> Jun 28, 2010 10:27:40 AM org.apache.catalina.connector.MapperListener
>>> handleNotification
>>> FINE: Handle Catalina:type=Manager,path=/cluster,host=webclust2 type
> :
>>> JMX.mbean.unregistered
>>> Jun 28, 2010 10:27:40 AM org.apache.catalina.core.StandardContext
>>> listenerStop
>>> FINE: Sending application stop events
>>>
>>>
>>>
>>> /**
>>> * Notifies the cluster that a single sign on session
>>> * has been terminated due to a user logout, deregister
>>> * the specified single sign on identifier, and invalidate
>>> * any associated sessions on the local node.
>>> *
>>> * @param ssoId Single sign on identifier to deregister
>>> */
>>> protected void deregister(String ssoId) {
>>>
>>> if (cluster != null) {
>>> messageNumber++;
>>> SingleSignOnMessage msg =
>>> new SingleSignOnMessage(cluster.getLocalMember(),
>>> ssoId, null);
>>> msg.setAction(SingleSignOnMessage.LOGOUT_SESSION);
>>>
>>> cluster.sendClusterDomain(msg);
>>> if (containerLog.isDebugEnabled())
>>> containerLog.debug("SingleSignOnMessage Send with action
>>> "
>>> + msg.getAction());
>>> }
>>>
>>> deregisterLocal(ssoId);
>>>
>>> }
>>>
>>> protected void deregisterLocal(String ssoId) {
>>>
>>> super.deregister(ssoId);
>>>
>>> }
>>>
>>>
>>> -----Original Message-----
>>> From: Pid [mailto:pid@pidster.com]
>>> Sent: Friday, June 25, 2010 4:29 AM
>>> To: Tomcat Users List
>>> Subject: Re: question for sso session replication in tomcat 6.0.26
>>>
>>> On 24/06/2010 21:49, Okubo, Yasushi (TSD) wrote:
>>>> My bad.
>>>>
>>>> I added *.jsp to the filter since it contains the path to index page
>>> as
>>>> follows. Now, I am wondering when sso session id is created and
>>>> replicated, is it when index.jsp was accessed or login.jsp was
>>> accessed?
>>>
>>> You had added it and have now removed it?
>>>
>>> The normal session id is created when you access a JSP for the first
>>> time, unless you have specifically configured JSPs to not create a
>>> session. A session can also be created manually by a Filter or a
>>> Servlet.
>>>
>>> The SSO session is created when the container login process completes
>>> authentication successfully.
>>>
>>> I'm not entirely clear on when SSO replication occurs - presumably
>> only
>>> when there's a change like session invalidation or creation.
>>>
>>>
>>> p
>>>
>>>
>>>> == index.jsp ==
>>>> <% response.sendRedirect("/test/index.html?homepage=dyn&prop=Home");
>>> %>
>>>>
>>>> -----Original Message-----
>>>> From: Okubo, Yasushi (TSD)
>>>> Sent: Thursday, June 24, 2010 1:13 PM
>>>> To: 'Tomcat Users List'
>>>> Subject: RE: question for sso session replication in tomcat 6.0.26
>>>>
>>>>
>>>> Hi Pid
>>>>
>>>> I started getting the following error upon login to one node onto
>>>> cluster.
>>>> Could you tell me what this mean is?
>>>>
>>>> Yasushi
>>>>
>>>>
>>>> Jun 24, 2010 10:51:58 AM org.apache.catalina.ha.tcp.ReplicationValve
>>>> sendReplicationMessage
>>>> SEVERE: Unable to perform replication request.
>>>> java.lang.NullPointerException
>>>> at
>>>>
>>>
>>
> org.apache.catalina.ha.tcp.ReplicationValve.isRequestWithoutSessionChang
>>>> e(ReplicationValve.java:590)
>>>> at
>>>>
>>>
>>
> org.apache.catalina.ha.tcp.ReplicationValve.sendSessionReplicationMessag
>>>> e(ReplicationValve.java:516)
>>>> at
>>>>
>>>
>>
> org.apache.catalina.ha.tcp.ReplicationValve.sendReplicationMessage(Repli
>>>> cationValve.java:430)
>>>> at
>>>>
>>>
>>
> org.apache.catalina.ha.tcp.ReplicationValve.invoke(ReplicationValve.java
>>>> :363)
>>>> at
>>>>
>>>
>>
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
>>>> :102)
>>>> at
>>>>
>>>
>>
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555
>>>> )
>>>> at
>>>>
>>>
>>
> org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:
>>>> 421)
>>>> at
>>>>
>>>
>>
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
>>>> java:109)
>>>> at
>>>>
>>>
>>
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:2
>>>> 98)
>>>> at
>>>>
>>>
>>
> org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:427)
>>>> at
>>>>
>>>
>>
> org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpApr
>>>> Protocol.java:384)
>>>> at
>>>>
>>>
>>
> org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1555)
>>>> at java.lang.Thread.run(Thread.java:619)
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>
>
RE: question for sso session replication in tomcat 6.0.26
Posted by "Okubo, Yasushi (TSD)" <Ya...@takedasd.com>.
On 28/06/2010 21:21, Okubo, Yasushi (TSD) wrote:
> Yes, I do.
>
> <Manager className="org.apache.catalina.ha.session.DeltaManager"
> name="webclust2"
> expireSessionsOnShutdown="false"
Hmm.
Can you unset the DeltaManager name attribute on all of your instances?
p
Hi Pid
I moved expireSessionOnShutdown, but the result was the same. I did not
see any difference.
By the way, when I shutdown the node1, it is getting action = 3 from
SimpleTpcCluster, which means logout defined in
singlesignonmessage.java. And clustersinglesignon is deregistering this
session id from other nodes.
It looks like clustersinglesignon can send a message to other nodes even
if deltamanager.expireSessionsOnShutdown set to false. Why?
Then, how can Tomcat differentiate event between shutdown and logout?
== Catalina.out ==
Jun 28, 2010 3:05:53 PM org.apache.catalina.ha.session.DeltaManager stop
FINE: Manager [/cluster] is stopping
Jun 28, 2010 3:05:53 PM org.apache.catalina.ha.session.DeltaManager stop
INFO: Manager [/cluster] expiring sessions upon shutdown
Jun 28, 2010 3:05:53 PM org.apache.catalina.authenticator.SingleSignOn
sessionEvent
FINE: Process session destroyed on
DeltaSession[EBEEECC91096DF7020488C1BDD75DF41.jvm2]
Jun 28, 2010 3:05:53 PM
org.apache.catalina.tribes.transport.nio.ParallelNioSender doLoop
FINER: ParallelNioSender - Sent msg:UniqueId{-2, -89, -62, -53, 103,
-39, 67, -1, -111, 52, -43, -84, -41, 66, 66, 31} at 2010-06-28
15:05:53.689 to tcp://{127, 0, 0, 1}:4010
Jun 28, 2010 3:05:53 PM
org.apache.catalina.tribes.group.ChannelCoordinator sendMessage
FINER: ChannelCoordinator - Sent msg:UniqueId{-2, -89, -62, -53, 103,
-39, 67, -1, -111, 52, -43, -84, -41, 66, 66, 31} at 2010-06-28
15:05:53.69 to {tcp://{127, 0, 0, 1}:4010}
Jun 28, 2010 3:05:53 PM org.apache.catalina.tribes.group.GroupChannel
send
FINER: GroupChannel - Sent msg:UniqueId{-2, -89, -62, -53, 103, -39, 67,
-1, -111, 52, -43, -84, -41, 66, 66, 31} at 2010-06-28 15:05:53.69 to
{tcp://{127, 0, 0, 1}:4010}
Jun 28, 2010 3:05:53 PM org.apache.catalina.tribes.group.GroupChannel
send
FINER: GroupChannel - Send Message:UniqueId{-2, -89, -62, -53, 103, -39,
67, -1, -111, 52, -43, -84, -41, 66, 66, 31} is
SingleSignOnMessage[action=3, ssoId=1C052A3927DC43EE6CAF27997F85C23B,
sessionId=null, username=null]
Jun 28, 2010 3:05:53 PM
org.apache.catalina.ha.authenticator.ClusterSingleSignOn deregister
FINE: SingleSignOnMessage Send with action 3
Jun 28, 2010 3:05:53 PM org.apache.catalina.authenticator.SingleSignOn
deregister
FINE: Deregistering sso id '1C052A3927DC43EE6CAF27997F85C23B'
Jun 28, 2010 3:05:53 PM org.apache.catalina.authenticator.SingleSignOn
deregister
FINER: Invalidating session
DeltaSession[EBEEECC91096DF7020488C1BDD75DF41.jvm2]
Jun 28, 2010 3:05:53 PM org.apache.catalina.connector.MapperListener
handleNotification
FINE: Handle Catalina:type=Manager,path=/cluster,host=webclust2 type :
JMX.mbean.unregistered
Jun 28, 2010 3:05:53 PM org.apache.catalina.connector.MapperListener
handleNotification
FINE: Handle Catalina:type=Manager,path=/cluster,host=webclust2 type :
JMX.mbean.unregistered
Jun 28, 2010 3:05:53 PM org.apache.catalina.core.StandardContext
listenerStop
FINE: Sending application stop events
== singlesignonmessage.java
public class SingleSignOnMessage implements ClusterMessage, Serializable
{
public static final int ADD_SESSION = 1;
public static final int DEREGISTER_SESSION = 2;
public static final int LOGOUT_SESSION = 3;
> -----Original Message-----
> From: Pid [mailto:pid@pidster.com]
> Sent: Monday, June 28, 2010 1:09 PM
> To: Tomcat Users List
> Subject: Re: question for sso session replication in tomcat 6.0.26
>
> On 28/06/2010 19:58, Okubo, Yasushi (TSD) wrote:
>>
>> Hi Pid
>>
>> I got more detailed log and it looks like clustersinglesignon is
>> deregistering sso session on other nodes.
>>
>> 0. session destroyed C0641336BF4E6B4654927AA3337EAB9F.jvm1 by
shutdown
>> [on node1]
>>
>> 1. clustersinglesignon is calling singlesignon to invalidate session
>> [ssoId=7BA0AB7AE2BFDB08CE2EBE8F42D3E89C] for node1
>>
>> 2, but it looks like this message came back to the node1 (through
> group
>> channel/mulitcast?)
>>
>> 3. then clustersinglesignon is deregistering this session again for
>> ssoId=7BA0AB7AE2BFDB08CE2EBE8F42D3E89C. deregister method propagates
>> this message to other nodes to deregister
>> ssoId=7BA0AB7AE2BFDB08CE2EBE8F42D3E89C from all members in the same
>> cluster.
>>
>>
>> Is there any way to break this chain of actions to stop
>> clustersinglesigon invoking deregister method?
>
> Do you have ClusterManager.expireSessionsOnShutdown set to false?
>
>
> p
>
>> Jun 28, 2010 10:27:40 AM org.apache.catalina.ha.session.DeltaManager
>> stop
>> FINE: Manager [/cluster] is stopping
>> Jun 28, 2010 10:27:40 AM org.apache.catalina.ha.session.DeltaManager
>> stop
>> INFO: Manager [/cluster] expiring sessions upon shutdown
>> FINE: Process session destroyed on
>> DeltaSession[C0641336BF4E6B4654927AA3337EAB9F.jvm1]
>> Jun 28, 2010 10:27:40 AM
>> org.apache.catalina.tribes.transport.nio.NioReplicationTask
>> serviceChannel
>> FINER: About to service key:sun.nio.ch.SelectionKeyImpl@1bd7b222
>> Jun 28, 2010 10:27:40 AM
>> org.apache.catalina.tribes.transport.nio.NioReplicationTask run
>> FINER: Servicing key:sun.nio.ch.SelectionKeyImpl@1bd7b222
>> Jun 28, 2010 10:27:40 AM
>> org.apache.catalina.tribes.transport.nio.NioReplicationTask run
>> FINER: Draining channel:sun.nio.ch.SelectionKeyImpl@1bd7b222
>> Jun 28, 2010 10:27:40 AM
>> org.apache.catalina.tribes.transport.nio.NioReplicationTask
>> registerForRead
>> FINER: Adding key for read event:sun.nio.ch.SelectionKeyImpl@1bd7b222
>> Jun 28, 2010 10:27:40 AM
>> org.apache.catalina.tribes.transport.nio.NioReceiver addEvent
>> FINER: Adding event to
>>
>
selector:org.apache.catalina.tribes.transport.nio.NioReplicationTask$1@5
>> 637dde9
>> Jun 28, 2010 10:27:40 AM
>> org.apache.catalina.tribes.transport.nio.NioReplicationTask
> drainChannel
>> FINER: NioReplicationThread - Received msg:UniqueId{48, -7, -97,
-123,
>> -116, -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at
2010-06-28
>> 10:27:40.78
>> Jun 28, 2010 10:27:40 AM
>> org.apache.catalina.tribes.transport.nio.NioReceiver events
>> FINER: Processing event in
>>
>
selector:org.apache.catalina.tribes.transport.nio.NioReplicationTask$1@5
>> 637dde9
>> Jun 28, 2010 10:27:40 AM
>> org.apache.catalina.tribes.group.ChannelCoordinator messageReceived
>> FINER: ChannelCoordinator - Received msg:UniqueId{48, -7, -97, -123,
>> -116, -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at
2010-06-28
>> 10:27:40.78 from tcp://{127, 0, 0, 1}:4010
>> Jun 28, 2010 10:27:40 AM
>> org.apache.catalina.tribes.transport.nio.NioReplicationTask$1 run
>> FINER: Registering key for read:sun.nio.ch.SelectionKeyImpl@1bd7b222
>> Jun 28, 2010 10:27:40 AM
org.apache.catalina.tribes.group.GroupChannel
>> messageReceived
>> FINER: GroupChannel - Received msg:UniqueId{48, -7, -97, -123, -116,
>> -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28
>> 10:27:40.78 from tcp://{127, 0, 0, 1}:4010
>> Jun 28, 2010 10:27:40 AM
org.apache.catalina.tribes.group.GroupChannel
>> messageReceived
>> FINER: GroupChannel - Receive Message:UniqueId{48, -7, -97, -123,
> -116,
>> -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} is
>> SingleSignOnMessage[action=3, ssoId=7BA0AB7AE2BFDB08CE2EBE8F42D3E89C,
>> sessionId=null, username=null]
>> Jun 28, 2010 10:27:40 AM org.apache.catalina.ha.tcp.SimpleTcpCluster
>> messageReceived
>> FINE: Assuming clocks are synched: Replication for
>> 7BA0AB7AE2BFDB08CE2EBE8F42D3E89C#-#1277746060782 took=1277746060782
> ms.
>> Jun 28, 2010 10:27:40 AM
>> org.apache.catalina.ha.authenticator.ClusterSingleSignOnListener
>> messageReceived
>> FINE: SingleSignOnMessage Received with action 3
>> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.authenticator.SingleSignOn
>> deregister
>> FINE: Deregistering sso id '7BA0AB7AE2BFDB08CE2EBE8F42D3E89C'
>> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.authenticator.SingleSignOn
>> deregister
>> FINER: Invalidating session
>> DeltaSession[C0641336BF4E6B4654927AA3337EAB9F.jvm1]
>> 2010 10:27:40 AM org.apache.catalina.tribes.group.GroupChannel
>> messageReceived
>> FINER: GroupChannel delivered[true] id:UniqueId{48, -7, -97, -123,
> -116,
>> -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17}
>> Jun 28, 2010 10:27:40 AM
>> org.apache.catalina.tribes.transport.nio.NioReplicationTask sendAck
>> FINER: ACK sent to 55801
>> Jun 28, 2010 10:27:40 AM
>> org.apache.catalina.tribes.transport.nio.ParallelNioSender doLoop
>> FINER: ParallelNioSender - Sent msg:UniqueId{48, -7, -97, -123, -116,
>> -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28
>> 10:27:40.785 to tcp://{127, 0, 0, 1}:4010
>> Jun 28, 2010 10:27:40 AM
>> org.apache.catalina.tribes.transport.nio.ParallelNioSender doLoop
>> FINER: ParallelNioSender - Sent msg:UniqueId{48, -7, -97, -123, -116,
>> -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28
>> 10:27:40.786 to tcp://{127, 0, 0, 1}:4020
>> Jun 28, 2010 10:27:40 AM
>> org.apache.catalina.tribes.group.ChannelCoordinator sendMessage
>> FINER: ChannelCoordinator - Sent msg:UniqueId{48, -7, -97, -123,
-116,
>> -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28
>> 10:27:40.786 to {tcp://{127, 0, 0, 1}:4010, tcp://{127, 0, 0,
1}:4020}
>> Jun 28, 2010 10:27:40 AM
org.apache.catalina.tribes.group.GroupChannel
>> send
>> FINER: GroupChannel - Sent msg:UniqueId{48, -7, -97, -123, -116, -54,
>> 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28
> 10:27:40.787
>> to {tcp://{127, 0, 0, 1}:4010, tcp://{127, 0, 0, 1}:4020}
>> Jun 28, 2010 10:27:40 AM
org.apache.catalina.tribes.group.GroupChannel
>> send
>> FINER: GroupChannel - Send Message:UniqueId{48, -7, -97, -123, -116,
>> -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} is
>> SingleSignOnMessage[action=3, ssoId=7BA0AB7AE2BFDB08CE2EBE8F42D3E89C,
>> sessionId=null, username=null]
>> Jun 28, 2010 10:27:40 AM
>> org.apache.catalina.ha.authenticator.ClusterSingleSignOn deregister
>> FINE: SingleSignOnMessage Send with action 3
>> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.authenticator.SingleSignOn
>> deregister
>> FINE: Deregistering sso id '7BA0AB7AE2BFDB08CE2EBE8F42D3E89C'
>> Jun 28, 2010 10:27:40 AM org.apache.catalina.connector.MapperListener
>> handleNotification
>> FINE: Handle Catalina:type=Manager,path=/cluster,host=webclust2 type
:
>> JMX.mbean.unregistered
>> Jun 28, 2010 10:27:40 AM org.apache.catalina.connector.MapperListener
>> handleNotification
>> FINE: Handle Catalina:type=Manager,path=/cluster,host=webclust2 type
:
>> JMX.mbean.unregistered
>> Jun 28, 2010 10:27:40 AM org.apache.catalina.core.StandardContext
>> listenerStop
>> FINE: Sending application stop events
>>
>>
>>
>> /**
>> * Notifies the cluster that a single sign on session
>> * has been terminated due to a user logout, deregister
>> * the specified single sign on identifier, and invalidate
>> * any associated sessions on the local node.
>> *
>> * @param ssoId Single sign on identifier to deregister
>> */
>> protected void deregister(String ssoId) {
>>
>> if (cluster != null) {
>> messageNumber++;
>> SingleSignOnMessage msg =
>> new SingleSignOnMessage(cluster.getLocalMember(),
>> ssoId, null);
>> msg.setAction(SingleSignOnMessage.LOGOUT_SESSION);
>>
>> cluster.sendClusterDomain(msg);
>> if (containerLog.isDebugEnabled())
>> containerLog.debug("SingleSignOnMessage Send with action
>> "
>> + msg.getAction());
>> }
>>
>> deregisterLocal(ssoId);
>>
>> }
>>
>> protected void deregisterLocal(String ssoId) {
>>
>> super.deregister(ssoId);
>>
>> }
>>
>>
>> -----Original Message-----
>> From: Pid [mailto:pid@pidster.com]
>> Sent: Friday, June 25, 2010 4:29 AM
>> To: Tomcat Users List
>> Subject: Re: question for sso session replication in tomcat 6.0.26
>>
>> On 24/06/2010 21:49, Okubo, Yasushi (TSD) wrote:
>>> My bad.
>>>
>>> I added *.jsp to the filter since it contains the path to index page
>> as
>>> follows. Now, I am wondering when sso session id is created and
>>> replicated, is it when index.jsp was accessed or login.jsp was
>> accessed?
>>
>> You had added it and have now removed it?
>>
>> The normal session id is created when you access a JSP for the first
>> time, unless you have specifically configured JSPs to not create a
>> session. A session can also be created manually by a Filter or a
>> Servlet.
>>
>> The SSO session is created when the container login process completes
>> authentication successfully.
>>
>> I'm not entirely clear on when SSO replication occurs - presumably
> only
>> when there's a change like session invalidation or creation.
>>
>>
>> p
>>
>>
>>> == index.jsp ==
>>> <% response.sendRedirect("/test/index.html?homepage=dyn&prop=Home");
>> %>
>>>
>>> -----Original Message-----
>>> From: Okubo, Yasushi (TSD)
>>> Sent: Thursday, June 24, 2010 1:13 PM
>>> To: 'Tomcat Users List'
>>> Subject: RE: question for sso session replication in tomcat 6.0.26
>>>
>>>
>>> Hi Pid
>>>
>>> I started getting the following error upon login to one node onto
>>> cluster.
>>> Could you tell me what this mean is?
>>>
>>> Yasushi
>>>
>>>
>>> Jun 24, 2010 10:51:58 AM org.apache.catalina.ha.tcp.ReplicationValve
>>> sendReplicationMessage
>>> SEVERE: Unable to perform replication request.
>>> java.lang.NullPointerException
>>> at
>>>
>>
>
org.apache.catalina.ha.tcp.ReplicationValve.isRequestWithoutSessionChang
>>> e(ReplicationValve.java:590)
>>> at
>>>
>>
>
org.apache.catalina.ha.tcp.ReplicationValve.sendSessionReplicationMessag
>>> e(ReplicationValve.java:516)
>>> at
>>>
>>
>
org.apache.catalina.ha.tcp.ReplicationValve.sendReplicationMessage(Repli
>>> cationValve.java:430)
>>> at
>>>
>>
>
org.apache.catalina.ha.tcp.ReplicationValve.invoke(ReplicationValve.java
>>> :363)
>>> at
>>>
>>
>
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
>>> :102)
>>> at
>>>
>>
>
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555
>>> )
>>> at
>>>
>>
>
org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:
>>> 421)
>>> at
>>>
>>
>
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
>>> java:109)
>>> at
>>>
>>
>
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:2
>>> 98)
>>> at
>>>
>>
>
org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:427)
>>> at
>>>
>>
>
org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpApr
>>> Protocol.java:384)
>>> at
>>>
>>
>
org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1555)
>>> at java.lang.Thread.run(Thread.java:619)
>>>
>>>
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: question for sso session replication in tomcat 6.0.26
Posted by Pid <pi...@pidster.com>.
On 28/06/2010 21:21, Okubo, Yasushi (TSD) wrote:
> Yes, I do.
>
> <Manager className="org.apache.catalina.ha.session.DeltaManager"
> name="webclust2"
> expireSessionsOnShutdown="false"
Hmm.
Can you unset the DeltaManager name attribute on all of your instances?
p
> -----Original Message-----
> From: Pid [mailto:pid@pidster.com]
> Sent: Monday, June 28, 2010 1:09 PM
> To: Tomcat Users List
> Subject: Re: question for sso session replication in tomcat 6.0.26
>
> On 28/06/2010 19:58, Okubo, Yasushi (TSD) wrote:
>>
>> Hi Pid
>>
>> I got more detailed log and it looks like clustersinglesignon is
>> deregistering sso session on other nodes.
>>
>> 0. session destroyed C0641336BF4E6B4654927AA3337EAB9F.jvm1 by shutdown
>> [on node1]
>>
>> 1. clustersinglesignon is calling singlesignon to invalidate session
>> [ssoId=7BA0AB7AE2BFDB08CE2EBE8F42D3E89C] for node1
>>
>> 2, but it looks like this message came back to the node1 (through
> group
>> channel/mulitcast?)
>>
>> 3. then clustersinglesignon is deregistering this session again for
>> ssoId=7BA0AB7AE2BFDB08CE2EBE8F42D3E89C. deregister method propagates
>> this message to other nodes to deregister
>> ssoId=7BA0AB7AE2BFDB08CE2EBE8F42D3E89C from all members in the same
>> cluster.
>>
>>
>> Is there any way to break this chain of actions to stop
>> clustersinglesigon invoking deregister method?
>
> Do you have ClusterManager.expireSessionsOnShutdown set to false?
>
>
> p
>
>> Jun 28, 2010 10:27:40 AM org.apache.catalina.ha.session.DeltaManager
>> stop
>> FINE: Manager [/cluster] is stopping
>> Jun 28, 2010 10:27:40 AM org.apache.catalina.ha.session.DeltaManager
>> stop
>> INFO: Manager [/cluster] expiring sessions upon shutdown
>> FINE: Process session destroyed on
>> DeltaSession[C0641336BF4E6B4654927AA3337EAB9F.jvm1]
>> Jun 28, 2010 10:27:40 AM
>> org.apache.catalina.tribes.transport.nio.NioReplicationTask
>> serviceChannel
>> FINER: About to service key:sun.nio.ch.SelectionKeyImpl@1bd7b222
>> Jun 28, 2010 10:27:40 AM
>> org.apache.catalina.tribes.transport.nio.NioReplicationTask run
>> FINER: Servicing key:sun.nio.ch.SelectionKeyImpl@1bd7b222
>> Jun 28, 2010 10:27:40 AM
>> org.apache.catalina.tribes.transport.nio.NioReplicationTask run
>> FINER: Draining channel:sun.nio.ch.SelectionKeyImpl@1bd7b222
>> Jun 28, 2010 10:27:40 AM
>> org.apache.catalina.tribes.transport.nio.NioReplicationTask
>> registerForRead
>> FINER: Adding key for read event:sun.nio.ch.SelectionKeyImpl@1bd7b222
>> Jun 28, 2010 10:27:40 AM
>> org.apache.catalina.tribes.transport.nio.NioReceiver addEvent
>> FINER: Adding event to
>>
> selector:org.apache.catalina.tribes.transport.nio.NioReplicationTask$1@5
>> 637dde9
>> Jun 28, 2010 10:27:40 AM
>> org.apache.catalina.tribes.transport.nio.NioReplicationTask
> drainChannel
>> FINER: NioReplicationThread - Received msg:UniqueId{48, -7, -97, -123,
>> -116, -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28
>> 10:27:40.78
>> Jun 28, 2010 10:27:40 AM
>> org.apache.catalina.tribes.transport.nio.NioReceiver events
>> FINER: Processing event in
>>
> selector:org.apache.catalina.tribes.transport.nio.NioReplicationTask$1@5
>> 637dde9
>> Jun 28, 2010 10:27:40 AM
>> org.apache.catalina.tribes.group.ChannelCoordinator messageReceived
>> FINER: ChannelCoordinator - Received msg:UniqueId{48, -7, -97, -123,
>> -116, -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28
>> 10:27:40.78 from tcp://{127, 0, 0, 1}:4010
>> Jun 28, 2010 10:27:40 AM
>> org.apache.catalina.tribes.transport.nio.NioReplicationTask$1 run
>> FINER: Registering key for read:sun.nio.ch.SelectionKeyImpl@1bd7b222
>> Jun 28, 2010 10:27:40 AM org.apache.catalina.tribes.group.GroupChannel
>> messageReceived
>> FINER: GroupChannel - Received msg:UniqueId{48, -7, -97, -123, -116,
>> -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28
>> 10:27:40.78 from tcp://{127, 0, 0, 1}:4010
>> Jun 28, 2010 10:27:40 AM org.apache.catalina.tribes.group.GroupChannel
>> messageReceived
>> FINER: GroupChannel - Receive Message:UniqueId{48, -7, -97, -123,
> -116,
>> -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} is
>> SingleSignOnMessage[action=3, ssoId=7BA0AB7AE2BFDB08CE2EBE8F42D3E89C,
>> sessionId=null, username=null]
>> Jun 28, 2010 10:27:40 AM org.apache.catalina.ha.tcp.SimpleTcpCluster
>> messageReceived
>> FINE: Assuming clocks are synched: Replication for
>> 7BA0AB7AE2BFDB08CE2EBE8F42D3E89C#-#1277746060782 took=1277746060782
> ms.
>> Jun 28, 2010 10:27:40 AM
>> org.apache.catalina.ha.authenticator.ClusterSingleSignOnListener
>> messageReceived
>> FINE: SingleSignOnMessage Received with action 3
>> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.authenticator.SingleSignOn
>> deregister
>> FINE: Deregistering sso id '7BA0AB7AE2BFDB08CE2EBE8F42D3E89C'
>> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.authenticator.SingleSignOn
>> deregister
>> FINER: Invalidating session
>> DeltaSession[C0641336BF4E6B4654927AA3337EAB9F.jvm1]
>> 2010 10:27:40 AM org.apache.catalina.tribes.group.GroupChannel
>> messageReceived
>> FINER: GroupChannel delivered[true] id:UniqueId{48, -7, -97, -123,
> -116,
>> -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17}
>> Jun 28, 2010 10:27:40 AM
>> org.apache.catalina.tribes.transport.nio.NioReplicationTask sendAck
>> FINER: ACK sent to 55801
>> Jun 28, 2010 10:27:40 AM
>> org.apache.catalina.tribes.transport.nio.ParallelNioSender doLoop
>> FINER: ParallelNioSender - Sent msg:UniqueId{48, -7, -97, -123, -116,
>> -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28
>> 10:27:40.785 to tcp://{127, 0, 0, 1}:4010
>> Jun 28, 2010 10:27:40 AM
>> org.apache.catalina.tribes.transport.nio.ParallelNioSender doLoop
>> FINER: ParallelNioSender - Sent msg:UniqueId{48, -7, -97, -123, -116,
>> -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28
>> 10:27:40.786 to tcp://{127, 0, 0, 1}:4020
>> Jun 28, 2010 10:27:40 AM
>> org.apache.catalina.tribes.group.ChannelCoordinator sendMessage
>> FINER: ChannelCoordinator - Sent msg:UniqueId{48, -7, -97, -123, -116,
>> -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28
>> 10:27:40.786 to {tcp://{127, 0, 0, 1}:4010, tcp://{127, 0, 0, 1}:4020}
>> Jun 28, 2010 10:27:40 AM org.apache.catalina.tribes.group.GroupChannel
>> send
>> FINER: GroupChannel - Sent msg:UniqueId{48, -7, -97, -123, -116, -54,
>> 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28
> 10:27:40.787
>> to {tcp://{127, 0, 0, 1}:4010, tcp://{127, 0, 0, 1}:4020}
>> Jun 28, 2010 10:27:40 AM org.apache.catalina.tribes.group.GroupChannel
>> send
>> FINER: GroupChannel - Send Message:UniqueId{48, -7, -97, -123, -116,
>> -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} is
>> SingleSignOnMessage[action=3, ssoId=7BA0AB7AE2BFDB08CE2EBE8F42D3E89C,
>> sessionId=null, username=null]
>> Jun 28, 2010 10:27:40 AM
>> org.apache.catalina.ha.authenticator.ClusterSingleSignOn deregister
>> FINE: SingleSignOnMessage Send with action 3
>> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.authenticator.SingleSignOn
>> deregister
>> FINE: Deregistering sso id '7BA0AB7AE2BFDB08CE2EBE8F42D3E89C'
>> Jun 28, 2010 10:27:40 AM org.apache.catalina.connector.MapperListener
>> handleNotification
>> FINE: Handle Catalina:type=Manager,path=/cluster,host=webclust2 type :
>> JMX.mbean.unregistered
>> Jun 28, 2010 10:27:40 AM org.apache.catalina.connector.MapperListener
>> handleNotification
>> FINE: Handle Catalina:type=Manager,path=/cluster,host=webclust2 type :
>> JMX.mbean.unregistered
>> Jun 28, 2010 10:27:40 AM org.apache.catalina.core.StandardContext
>> listenerStop
>> FINE: Sending application stop events
>>
>>
>>
>> /**
>> * Notifies the cluster that a single sign on session
>> * has been terminated due to a user logout, deregister
>> * the specified single sign on identifier, and invalidate
>> * any associated sessions on the local node.
>> *
>> * @param ssoId Single sign on identifier to deregister
>> */
>> protected void deregister(String ssoId) {
>>
>> if (cluster != null) {
>> messageNumber++;
>> SingleSignOnMessage msg =
>> new SingleSignOnMessage(cluster.getLocalMember(),
>> ssoId, null);
>> msg.setAction(SingleSignOnMessage.LOGOUT_SESSION);
>>
>> cluster.sendClusterDomain(msg);
>> if (containerLog.isDebugEnabled())
>> containerLog.debug("SingleSignOnMessage Send with action
>> "
>> + msg.getAction());
>> }
>>
>> deregisterLocal(ssoId);
>>
>> }
>>
>> protected void deregisterLocal(String ssoId) {
>>
>> super.deregister(ssoId);
>>
>> }
>>
>>
>> -----Original Message-----
>> From: Pid [mailto:pid@pidster.com]
>> Sent: Friday, June 25, 2010 4:29 AM
>> To: Tomcat Users List
>> Subject: Re: question for sso session replication in tomcat 6.0.26
>>
>> On 24/06/2010 21:49, Okubo, Yasushi (TSD) wrote:
>>> My bad.
>>>
>>> I added *.jsp to the filter since it contains the path to index page
>> as
>>> follows. Now, I am wondering when sso session id is created and
>>> replicated, is it when index.jsp was accessed or login.jsp was
>> accessed?
>>
>> You had added it and have now removed it?
>>
>> The normal session id is created when you access a JSP for the first
>> time, unless you have specifically configured JSPs to not create a
>> session. A session can also be created manually by a Filter or a
>> Servlet.
>>
>> The SSO session is created when the container login process completes
>> authentication successfully.
>>
>> I'm not entirely clear on when SSO replication occurs - presumably
> only
>> when there's a change like session invalidation or creation.
>>
>>
>> p
>>
>>
>>> == index.jsp ==
>>> <% response.sendRedirect("/test/index.html?homepage=dyn&prop=Home");
>> %>
>>>
>>> -----Original Message-----
>>> From: Okubo, Yasushi (TSD)
>>> Sent: Thursday, June 24, 2010 1:13 PM
>>> To: 'Tomcat Users List'
>>> Subject: RE: question for sso session replication in tomcat 6.0.26
>>>
>>>
>>> Hi Pid
>>>
>>> I started getting the following error upon login to one node onto
>>> cluster.
>>> Could you tell me what this mean is?
>>>
>>> Yasushi
>>>
>>>
>>> Jun 24, 2010 10:51:58 AM org.apache.catalina.ha.tcp.ReplicationValve
>>> sendReplicationMessage
>>> SEVERE: Unable to perform replication request.
>>> java.lang.NullPointerException
>>> at
>>>
>>
> org.apache.catalina.ha.tcp.ReplicationValve.isRequestWithoutSessionChang
>>> e(ReplicationValve.java:590)
>>> at
>>>
>>
> org.apache.catalina.ha.tcp.ReplicationValve.sendSessionReplicationMessag
>>> e(ReplicationValve.java:516)
>>> at
>>>
>>
> org.apache.catalina.ha.tcp.ReplicationValve.sendReplicationMessage(Repli
>>> cationValve.java:430)
>>> at
>>>
>>
> org.apache.catalina.ha.tcp.ReplicationValve.invoke(ReplicationValve.java
>>> :363)
>>> at
>>>
>>
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
>>> :102)
>>> at
>>>
>>
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555
>>> )
>>> at
>>>
>>
> org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:
>>> 421)
>>> at
>>>
>>
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
>>> java:109)
>>> at
>>>
>>
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:2
>>> 98)
>>> at
>>>
>>
> org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:427)
>>> at
>>>
>>
> org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpApr
>>> Protocol.java:384)
>>> at
>>>
>>
> org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1555)
>>> at java.lang.Thread.run(Thread.java:619)
>>>
>>>
>>
>>
>
>
>
RE: question for sso session replication in tomcat 6.0.26
Posted by "Okubo, Yasushi (TSD)" <Ya...@takedasd.com>.
Yes, I do.
<Manager className="org.apache.catalina.ha.session.DeltaManager"
name="webclust2"
expireSessionsOnShutdown="false"
-----Original Message-----
From: Pid [mailto:pid@pidster.com]
Sent: Monday, June 28, 2010 1:09 PM
To: Tomcat Users List
Subject: Re: question for sso session replication in tomcat 6.0.26
On 28/06/2010 19:58, Okubo, Yasushi (TSD) wrote:
>
> Hi Pid
>
> I got more detailed log and it looks like clustersinglesignon is
> deregistering sso session on other nodes.
>
> 0. session destroyed C0641336BF4E6B4654927AA3337EAB9F.jvm1 by shutdown
> [on node1]
>
> 1. clustersinglesignon is calling singlesignon to invalidate session
> [ssoId=7BA0AB7AE2BFDB08CE2EBE8F42D3E89C] for node1
>
> 2, but it looks like this message came back to the node1 (through
group
> channel/mulitcast?)
>
> 3. then clustersinglesignon is deregistering this session again for
> ssoId=7BA0AB7AE2BFDB08CE2EBE8F42D3E89C. deregister method propagates
> this message to other nodes to deregister
> ssoId=7BA0AB7AE2BFDB08CE2EBE8F42D3E89C from all members in the same
> cluster.
>
>
> Is there any way to break this chain of actions to stop
> clustersinglesigon invoking deregister method?
Do you have ClusterManager.expireSessionsOnShutdown set to false?
p
> Jun 28, 2010 10:27:40 AM org.apache.catalina.ha.session.DeltaManager
> stop
> FINE: Manager [/cluster] is stopping
> Jun 28, 2010 10:27:40 AM org.apache.catalina.ha.session.DeltaManager
> stop
> INFO: Manager [/cluster] expiring sessions upon shutdown
> FINE: Process session destroyed on
> DeltaSession[C0641336BF4E6B4654927AA3337EAB9F.jvm1]
> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.tribes.transport.nio.NioReplicationTask
> serviceChannel
> FINER: About to service key:sun.nio.ch.SelectionKeyImpl@1bd7b222
> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.tribes.transport.nio.NioReplicationTask run
> FINER: Servicing key:sun.nio.ch.SelectionKeyImpl@1bd7b222
> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.tribes.transport.nio.NioReplicationTask run
> FINER: Draining channel:sun.nio.ch.SelectionKeyImpl@1bd7b222
> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.tribes.transport.nio.NioReplicationTask
> registerForRead
> FINER: Adding key for read event:sun.nio.ch.SelectionKeyImpl@1bd7b222
> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.tribes.transport.nio.NioReceiver addEvent
> FINER: Adding event to
>
selector:org.apache.catalina.tribes.transport.nio.NioReplicationTask$1@5
> 637dde9
> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.tribes.transport.nio.NioReplicationTask
drainChannel
> FINER: NioReplicationThread - Received msg:UniqueId{48, -7, -97, -123,
> -116, -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28
> 10:27:40.78
> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.tribes.transport.nio.NioReceiver events
> FINER: Processing event in
>
selector:org.apache.catalina.tribes.transport.nio.NioReplicationTask$1@5
> 637dde9
> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.tribes.group.ChannelCoordinator messageReceived
> FINER: ChannelCoordinator - Received msg:UniqueId{48, -7, -97, -123,
> -116, -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28
> 10:27:40.78 from tcp://{127, 0, 0, 1}:4010
> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.tribes.transport.nio.NioReplicationTask$1 run
> FINER: Registering key for read:sun.nio.ch.SelectionKeyImpl@1bd7b222
> Jun 28, 2010 10:27:40 AM org.apache.catalina.tribes.group.GroupChannel
> messageReceived
> FINER: GroupChannel - Received msg:UniqueId{48, -7, -97, -123, -116,
> -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28
> 10:27:40.78 from tcp://{127, 0, 0, 1}:4010
> Jun 28, 2010 10:27:40 AM org.apache.catalina.tribes.group.GroupChannel
> messageReceived
> FINER: GroupChannel - Receive Message:UniqueId{48, -7, -97, -123,
-116,
> -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} is
> SingleSignOnMessage[action=3, ssoId=7BA0AB7AE2BFDB08CE2EBE8F42D3E89C,
> sessionId=null, username=null]
> Jun 28, 2010 10:27:40 AM org.apache.catalina.ha.tcp.SimpleTcpCluster
> messageReceived
> FINE: Assuming clocks are synched: Replication for
> 7BA0AB7AE2BFDB08CE2EBE8F42D3E89C#-#1277746060782 took=1277746060782
ms.
> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.ha.authenticator.ClusterSingleSignOnListener
> messageReceived
> FINE: SingleSignOnMessage Received with action 3
> Jun 28, 2010 10:27:40 AM
org.apache.catalina.authenticator.SingleSignOn
> deregister
> FINE: Deregistering sso id '7BA0AB7AE2BFDB08CE2EBE8F42D3E89C'
> Jun 28, 2010 10:27:40 AM
org.apache.catalina.authenticator.SingleSignOn
> deregister
> FINER: Invalidating session
> DeltaSession[C0641336BF4E6B4654927AA3337EAB9F.jvm1]
> 2010 10:27:40 AM org.apache.catalina.tribes.group.GroupChannel
> messageReceived
> FINER: GroupChannel delivered[true] id:UniqueId{48, -7, -97, -123,
-116,
> -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17}
> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.tribes.transport.nio.NioReplicationTask sendAck
> FINER: ACK sent to 55801
> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.tribes.transport.nio.ParallelNioSender doLoop
> FINER: ParallelNioSender - Sent msg:UniqueId{48, -7, -97, -123, -116,
> -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28
> 10:27:40.785 to tcp://{127, 0, 0, 1}:4010
> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.tribes.transport.nio.ParallelNioSender doLoop
> FINER: ParallelNioSender - Sent msg:UniqueId{48, -7, -97, -123, -116,
> -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28
> 10:27:40.786 to tcp://{127, 0, 0, 1}:4020
> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.tribes.group.ChannelCoordinator sendMessage
> FINER: ChannelCoordinator - Sent msg:UniqueId{48, -7, -97, -123, -116,
> -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28
> 10:27:40.786 to {tcp://{127, 0, 0, 1}:4010, tcp://{127, 0, 0, 1}:4020}
> Jun 28, 2010 10:27:40 AM org.apache.catalina.tribes.group.GroupChannel
> send
> FINER: GroupChannel - Sent msg:UniqueId{48, -7, -97, -123, -116, -54,
> 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28
10:27:40.787
> to {tcp://{127, 0, 0, 1}:4010, tcp://{127, 0, 0, 1}:4020}
> Jun 28, 2010 10:27:40 AM org.apache.catalina.tribes.group.GroupChannel
> send
> FINER: GroupChannel - Send Message:UniqueId{48, -7, -97, -123, -116,
> -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} is
> SingleSignOnMessage[action=3, ssoId=7BA0AB7AE2BFDB08CE2EBE8F42D3E89C,
> sessionId=null, username=null]
> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.ha.authenticator.ClusterSingleSignOn deregister
> FINE: SingleSignOnMessage Send with action 3
> Jun 28, 2010 10:27:40 AM
org.apache.catalina.authenticator.SingleSignOn
> deregister
> FINE: Deregistering sso id '7BA0AB7AE2BFDB08CE2EBE8F42D3E89C'
> Jun 28, 2010 10:27:40 AM org.apache.catalina.connector.MapperListener
> handleNotification
> FINE: Handle Catalina:type=Manager,path=/cluster,host=webclust2 type :
> JMX.mbean.unregistered
> Jun 28, 2010 10:27:40 AM org.apache.catalina.connector.MapperListener
> handleNotification
> FINE: Handle Catalina:type=Manager,path=/cluster,host=webclust2 type :
> JMX.mbean.unregistered
> Jun 28, 2010 10:27:40 AM org.apache.catalina.core.StandardContext
> listenerStop
> FINE: Sending application stop events
>
>
>
> /**
> * Notifies the cluster that a single sign on session
> * has been terminated due to a user logout, deregister
> * the specified single sign on identifier, and invalidate
> * any associated sessions on the local node.
> *
> * @param ssoId Single sign on identifier to deregister
> */
> protected void deregister(String ssoId) {
>
> if (cluster != null) {
> messageNumber++;
> SingleSignOnMessage msg =
> new SingleSignOnMessage(cluster.getLocalMember(),
> ssoId, null);
> msg.setAction(SingleSignOnMessage.LOGOUT_SESSION);
>
> cluster.sendClusterDomain(msg);
> if (containerLog.isDebugEnabled())
> containerLog.debug("SingleSignOnMessage Send with action
> "
> + msg.getAction());
> }
>
> deregisterLocal(ssoId);
>
> }
>
> protected void deregisterLocal(String ssoId) {
>
> super.deregister(ssoId);
>
> }
>
>
> -----Original Message-----
> From: Pid [mailto:pid@pidster.com]
> Sent: Friday, June 25, 2010 4:29 AM
> To: Tomcat Users List
> Subject: Re: question for sso session replication in tomcat 6.0.26
>
> On 24/06/2010 21:49, Okubo, Yasushi (TSD) wrote:
>> My bad.
>>
>> I added *.jsp to the filter since it contains the path to index page
> as
>> follows. Now, I am wondering when sso session id is created and
>> replicated, is it when index.jsp was accessed or login.jsp was
> accessed?
>
> You had added it and have now removed it?
>
> The normal session id is created when you access a JSP for the first
> time, unless you have specifically configured JSPs to not create a
> session. A session can also be created manually by a Filter or a
> Servlet.
>
> The SSO session is created when the container login process completes
> authentication successfully.
>
> I'm not entirely clear on when SSO replication occurs - presumably
only
> when there's a change like session invalidation or creation.
>
>
> p
>
>
>> == index.jsp ==
>> <% response.sendRedirect("/test/index.html?homepage=dyn&prop=Home");
> %>
>>
>> -----Original Message-----
>> From: Okubo, Yasushi (TSD)
>> Sent: Thursday, June 24, 2010 1:13 PM
>> To: 'Tomcat Users List'
>> Subject: RE: question for sso session replication in tomcat 6.0.26
>>
>>
>> Hi Pid
>>
>> I started getting the following error upon login to one node onto
>> cluster.
>> Could you tell me what this mean is?
>>
>> Yasushi
>>
>>
>> Jun 24, 2010 10:51:58 AM org.apache.catalina.ha.tcp.ReplicationValve
>> sendReplicationMessage
>> SEVERE: Unable to perform replication request.
>> java.lang.NullPointerException
>> at
>>
>
org.apache.catalina.ha.tcp.ReplicationValve.isRequestWithoutSessionChang
>> e(ReplicationValve.java:590)
>> at
>>
>
org.apache.catalina.ha.tcp.ReplicationValve.sendSessionReplicationMessag
>> e(ReplicationValve.java:516)
>> at
>>
>
org.apache.catalina.ha.tcp.ReplicationValve.sendReplicationMessage(Repli
>> cationValve.java:430)
>> at
>>
>
org.apache.catalina.ha.tcp.ReplicationValve.invoke(ReplicationValve.java
>> :363)
>> at
>>
>
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
>> :102)
>> at
>>
>
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555
>> )
>> at
>>
>
org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:
>> 421)
>> at
>>
>
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
>> java:109)
>> at
>>
>
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:2
>> 98)
>> at
>>
>
org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:427)
>> at
>>
>
org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpApr
>> Protocol.java:384)
>> at
>>
>
org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1555)
>> at java.lang.Thread.run(Thread.java:619)
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: question for sso session replication in tomcat 6.0.26
Posted by Pid <pi...@pidster.com>.
On 28/06/2010 19:58, Okubo, Yasushi (TSD) wrote:
>
> Hi Pid
>
> I got more detailed log and it looks like clustersinglesignon is
> deregistering sso session on other nodes.
>
> 0. session destroyed C0641336BF4E6B4654927AA3337EAB9F.jvm1 by shutdown
> [on node1]
>
> 1. clustersinglesignon is calling singlesignon to invalidate session
> [ssoId=7BA0AB7AE2BFDB08CE2EBE8F42D3E89C] for node1
>
> 2, but it looks like this message came back to the node1 (through group
> channel/mulitcast?)
>
> 3. then clustersinglesignon is deregistering this session again for
> ssoId=7BA0AB7AE2BFDB08CE2EBE8F42D3E89C. deregister method propagates
> this message to other nodes to deregister
> ssoId=7BA0AB7AE2BFDB08CE2EBE8F42D3E89C from all members in the same
> cluster.
>
>
> Is there any way to break this chain of actions to stop
> clustersinglesigon invoking deregister method?
Do you have ClusterManager.expireSessionsOnShutdown set to false?
p
> Jun 28, 2010 10:27:40 AM org.apache.catalina.ha.session.DeltaManager
> stop
> FINE: Manager [/cluster] is stopping
> Jun 28, 2010 10:27:40 AM org.apache.catalina.ha.session.DeltaManager
> stop
> INFO: Manager [/cluster] expiring sessions upon shutdown
> FINE: Process session destroyed on
> DeltaSession[C0641336BF4E6B4654927AA3337EAB9F.jvm1]
> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.tribes.transport.nio.NioReplicationTask
> serviceChannel
> FINER: About to service key:sun.nio.ch.SelectionKeyImpl@1bd7b222
> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.tribes.transport.nio.NioReplicationTask run
> FINER: Servicing key:sun.nio.ch.SelectionKeyImpl@1bd7b222
> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.tribes.transport.nio.NioReplicationTask run
> FINER: Draining channel:sun.nio.ch.SelectionKeyImpl@1bd7b222
> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.tribes.transport.nio.NioReplicationTask
> registerForRead
> FINER: Adding key for read event:sun.nio.ch.SelectionKeyImpl@1bd7b222
> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.tribes.transport.nio.NioReceiver addEvent
> FINER: Adding event to
> selector:org.apache.catalina.tribes.transport.nio.NioReplicationTask$1@5
> 637dde9
> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.tribes.transport.nio.NioReplicationTask drainChannel
> FINER: NioReplicationThread - Received msg:UniqueId{48, -7, -97, -123,
> -116, -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28
> 10:27:40.78
> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.tribes.transport.nio.NioReceiver events
> FINER: Processing event in
> selector:org.apache.catalina.tribes.transport.nio.NioReplicationTask$1@5
> 637dde9
> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.tribes.group.ChannelCoordinator messageReceived
> FINER: ChannelCoordinator - Received msg:UniqueId{48, -7, -97, -123,
> -116, -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28
> 10:27:40.78 from tcp://{127, 0, 0, 1}:4010
> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.tribes.transport.nio.NioReplicationTask$1 run
> FINER: Registering key for read:sun.nio.ch.SelectionKeyImpl@1bd7b222
> Jun 28, 2010 10:27:40 AM org.apache.catalina.tribes.group.GroupChannel
> messageReceived
> FINER: GroupChannel - Received msg:UniqueId{48, -7, -97, -123, -116,
> -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28
> 10:27:40.78 from tcp://{127, 0, 0, 1}:4010
> Jun 28, 2010 10:27:40 AM org.apache.catalina.tribes.group.GroupChannel
> messageReceived
> FINER: GroupChannel - Receive Message:UniqueId{48, -7, -97, -123, -116,
> -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} is
> SingleSignOnMessage[action=3, ssoId=7BA0AB7AE2BFDB08CE2EBE8F42D3E89C,
> sessionId=null, username=null]
> Jun 28, 2010 10:27:40 AM org.apache.catalina.ha.tcp.SimpleTcpCluster
> messageReceived
> FINE: Assuming clocks are synched: Replication for
> 7BA0AB7AE2BFDB08CE2EBE8F42D3E89C#-#1277746060782 took=1277746060782 ms.
> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.ha.authenticator.ClusterSingleSignOnListener
> messageReceived
> FINE: SingleSignOnMessage Received with action 3
> Jun 28, 2010 10:27:40 AM org.apache.catalina.authenticator.SingleSignOn
> deregister
> FINE: Deregistering sso id '7BA0AB7AE2BFDB08CE2EBE8F42D3E89C'
> Jun 28, 2010 10:27:40 AM org.apache.catalina.authenticator.SingleSignOn
> deregister
> FINER: Invalidating session
> DeltaSession[C0641336BF4E6B4654927AA3337EAB9F.jvm1]
> 2010 10:27:40 AM org.apache.catalina.tribes.group.GroupChannel
> messageReceived
> FINER: GroupChannel delivered[true] id:UniqueId{48, -7, -97, -123, -116,
> -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17}
> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.tribes.transport.nio.NioReplicationTask sendAck
> FINER: ACK sent to 55801
> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.tribes.transport.nio.ParallelNioSender doLoop
> FINER: ParallelNioSender - Sent msg:UniqueId{48, -7, -97, -123, -116,
> -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28
> 10:27:40.785 to tcp://{127, 0, 0, 1}:4010
> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.tribes.transport.nio.ParallelNioSender doLoop
> FINER: ParallelNioSender - Sent msg:UniqueId{48, -7, -97, -123, -116,
> -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28
> 10:27:40.786 to tcp://{127, 0, 0, 1}:4020
> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.tribes.group.ChannelCoordinator sendMessage
> FINER: ChannelCoordinator - Sent msg:UniqueId{48, -7, -97, -123, -116,
> -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28
> 10:27:40.786 to {tcp://{127, 0, 0, 1}:4010, tcp://{127, 0, 0, 1}:4020}
> Jun 28, 2010 10:27:40 AM org.apache.catalina.tribes.group.GroupChannel
> send
> FINER: GroupChannel - Sent msg:UniqueId{48, -7, -97, -123, -116, -54,
> 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28 10:27:40.787
> to {tcp://{127, 0, 0, 1}:4010, tcp://{127, 0, 0, 1}:4020}
> Jun 28, 2010 10:27:40 AM org.apache.catalina.tribes.group.GroupChannel
> send
> FINER: GroupChannel - Send Message:UniqueId{48, -7, -97, -123, -116,
> -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} is
> SingleSignOnMessage[action=3, ssoId=7BA0AB7AE2BFDB08CE2EBE8F42D3E89C,
> sessionId=null, username=null]
> Jun 28, 2010 10:27:40 AM
> org.apache.catalina.ha.authenticator.ClusterSingleSignOn deregister
> FINE: SingleSignOnMessage Send with action 3
> Jun 28, 2010 10:27:40 AM org.apache.catalina.authenticator.SingleSignOn
> deregister
> FINE: Deregistering sso id '7BA0AB7AE2BFDB08CE2EBE8F42D3E89C'
> Jun 28, 2010 10:27:40 AM org.apache.catalina.connector.MapperListener
> handleNotification
> FINE: Handle Catalina:type=Manager,path=/cluster,host=webclust2 type :
> JMX.mbean.unregistered
> Jun 28, 2010 10:27:40 AM org.apache.catalina.connector.MapperListener
> handleNotification
> FINE: Handle Catalina:type=Manager,path=/cluster,host=webclust2 type :
> JMX.mbean.unregistered
> Jun 28, 2010 10:27:40 AM org.apache.catalina.core.StandardContext
> listenerStop
> FINE: Sending application stop events
>
>
>
> /**
> * Notifies the cluster that a single sign on session
> * has been terminated due to a user logout, deregister
> * the specified single sign on identifier, and invalidate
> * any associated sessions on the local node.
> *
> * @param ssoId Single sign on identifier to deregister
> */
> protected void deregister(String ssoId) {
>
> if (cluster != null) {
> messageNumber++;
> SingleSignOnMessage msg =
> new SingleSignOnMessage(cluster.getLocalMember(),
> ssoId, null);
> msg.setAction(SingleSignOnMessage.LOGOUT_SESSION);
>
> cluster.sendClusterDomain(msg);
> if (containerLog.isDebugEnabled())
> containerLog.debug("SingleSignOnMessage Send with action
> "
> + msg.getAction());
> }
>
> deregisterLocal(ssoId);
>
> }
>
> protected void deregisterLocal(String ssoId) {
>
> super.deregister(ssoId);
>
> }
>
>
> -----Original Message-----
> From: Pid [mailto:pid@pidster.com]
> Sent: Friday, June 25, 2010 4:29 AM
> To: Tomcat Users List
> Subject: Re: question for sso session replication in tomcat 6.0.26
>
> On 24/06/2010 21:49, Okubo, Yasushi (TSD) wrote:
>> My bad.
>>
>> I added *.jsp to the filter since it contains the path to index page
> as
>> follows. Now, I am wondering when sso session id is created and
>> replicated, is it when index.jsp was accessed or login.jsp was
> accessed?
>
> You had added it and have now removed it?
>
> The normal session id is created when you access a JSP for the first
> time, unless you have specifically configured JSPs to not create a
> session. A session can also be created manually by a Filter or a
> Servlet.
>
> The SSO session is created when the container login process completes
> authentication successfully.
>
> I'm not entirely clear on when SSO replication occurs - presumably only
> when there's a change like session invalidation or creation.
>
>
> p
>
>
>> == index.jsp ==
>> <% response.sendRedirect("/test/index.html?homepage=dyn&prop=Home");
> %>
>>
>> -----Original Message-----
>> From: Okubo, Yasushi (TSD)
>> Sent: Thursday, June 24, 2010 1:13 PM
>> To: 'Tomcat Users List'
>> Subject: RE: question for sso session replication in tomcat 6.0.26
>>
>>
>> Hi Pid
>>
>> I started getting the following error upon login to one node onto
>> cluster.
>> Could you tell me what this mean is?
>>
>> Yasushi
>>
>>
>> Jun 24, 2010 10:51:58 AM org.apache.catalina.ha.tcp.ReplicationValve
>> sendReplicationMessage
>> SEVERE: Unable to perform replication request.
>> java.lang.NullPointerException
>> at
>>
> org.apache.catalina.ha.tcp.ReplicationValve.isRequestWithoutSessionChang
>> e(ReplicationValve.java:590)
>> at
>>
> org.apache.catalina.ha.tcp.ReplicationValve.sendSessionReplicationMessag
>> e(ReplicationValve.java:516)
>> at
>>
> org.apache.catalina.ha.tcp.ReplicationValve.sendReplicationMessage(Repli
>> cationValve.java:430)
>> at
>>
> org.apache.catalina.ha.tcp.ReplicationValve.invoke(ReplicationValve.java
>> :363)
>> at
>>
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
>> :102)
>> at
>>
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555
>> )
>> at
>>
> org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:
>> 421)
>> at
>>
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
>> java:109)
>> at
>>
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:2
>> 98)
>> at
>>
> org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:427)
>> at
>>
> org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpApr
>> Protocol.java:384)
>> at
>>
> org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1555)
>> at java.lang.Thread.run(Thread.java:619)
>>
>>
>
>
RE: question for sso session replication in tomcat 6.0.26
Posted by "Okubo, Yasushi (TSD)" <Ya...@takedasd.com>.
Hi Pid
I got more detailed log and it looks like clustersinglesignon is
deregistering sso session on other nodes.
0. session destroyed C0641336BF4E6B4654927AA3337EAB9F.jvm1 by shutdown
[on node1]
1. clustersinglesignon is calling singlesignon to invalidate session
[ssoId=7BA0AB7AE2BFDB08CE2EBE8F42D3E89C] for node1
2, but it looks like this message came back to the node1 (through group
channel/mulitcast?)
3. then clustersinglesignon is deregistering this session again for
ssoId=7BA0AB7AE2BFDB08CE2EBE8F42D3E89C. deregister method propagates
this message to other nodes to deregister
ssoId=7BA0AB7AE2BFDB08CE2EBE8F42D3E89C from all members in the same
cluster.
Is there any way to break this chain of actions to stop
clustersinglesigon invoking deregister method?
Jun 28, 2010 10:27:40 AM org.apache.catalina.ha.session.DeltaManager
stop
FINE: Manager [/cluster] is stopping
Jun 28, 2010 10:27:40 AM org.apache.catalina.ha.session.DeltaManager
stop
INFO: Manager [/cluster] expiring sessions upon shutdown
FINE: Process session destroyed on
DeltaSession[C0641336BF4E6B4654927AA3337EAB9F.jvm1]
Jun 28, 2010 10:27:40 AM
org.apache.catalina.tribes.transport.nio.NioReplicationTask
serviceChannel
FINER: About to service key:sun.nio.ch.SelectionKeyImpl@1bd7b222
Jun 28, 2010 10:27:40 AM
org.apache.catalina.tribes.transport.nio.NioReplicationTask run
FINER: Servicing key:sun.nio.ch.SelectionKeyImpl@1bd7b222
Jun 28, 2010 10:27:40 AM
org.apache.catalina.tribes.transport.nio.NioReplicationTask run
FINER: Draining channel:sun.nio.ch.SelectionKeyImpl@1bd7b222
Jun 28, 2010 10:27:40 AM
org.apache.catalina.tribes.transport.nio.NioReplicationTask
registerForRead
FINER: Adding key for read event:sun.nio.ch.SelectionKeyImpl@1bd7b222
Jun 28, 2010 10:27:40 AM
org.apache.catalina.tribes.transport.nio.NioReceiver addEvent
FINER: Adding event to
selector:org.apache.catalina.tribes.transport.nio.NioReplicationTask$1@5
637dde9
Jun 28, 2010 10:27:40 AM
org.apache.catalina.tribes.transport.nio.NioReplicationTask drainChannel
FINER: NioReplicationThread - Received msg:UniqueId{48, -7, -97, -123,
-116, -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28
10:27:40.78
Jun 28, 2010 10:27:40 AM
org.apache.catalina.tribes.transport.nio.NioReceiver events
FINER: Processing event in
selector:org.apache.catalina.tribes.transport.nio.NioReplicationTask$1@5
637dde9
Jun 28, 2010 10:27:40 AM
org.apache.catalina.tribes.group.ChannelCoordinator messageReceived
FINER: ChannelCoordinator - Received msg:UniqueId{48, -7, -97, -123,
-116, -54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28
10:27:40.78 from tcp://{127, 0, 0, 1}:4010
Jun 28, 2010 10:27:40 AM
org.apache.catalina.tribes.transport.nio.NioReplicationTask$1 run
FINER: Registering key for read:sun.nio.ch.SelectionKeyImpl@1bd7b222
Jun 28, 2010 10:27:40 AM org.apache.catalina.tribes.group.GroupChannel
messageReceived
FINER: GroupChannel - Received msg:UniqueId{48, -7, -97, -123, -116,
-54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28
10:27:40.78 from tcp://{127, 0, 0, 1}:4010
Jun 28, 2010 10:27:40 AM org.apache.catalina.tribes.group.GroupChannel
messageReceived
FINER: GroupChannel - Receive Message:UniqueId{48, -7, -97, -123, -116,
-54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} is
SingleSignOnMessage[action=3, ssoId=7BA0AB7AE2BFDB08CE2EBE8F42D3E89C,
sessionId=null, username=null]
Jun 28, 2010 10:27:40 AM org.apache.catalina.ha.tcp.SimpleTcpCluster
messageReceived
FINE: Assuming clocks are synched: Replication for
7BA0AB7AE2BFDB08CE2EBE8F42D3E89C#-#1277746060782 took=1277746060782 ms.
Jun 28, 2010 10:27:40 AM
org.apache.catalina.ha.authenticator.ClusterSingleSignOnListener
messageReceived
FINE: SingleSignOnMessage Received with action 3
Jun 28, 2010 10:27:40 AM org.apache.catalina.authenticator.SingleSignOn
deregister
FINE: Deregistering sso id '7BA0AB7AE2BFDB08CE2EBE8F42D3E89C'
Jun 28, 2010 10:27:40 AM org.apache.catalina.authenticator.SingleSignOn
deregister
FINER: Invalidating session
DeltaSession[C0641336BF4E6B4654927AA3337EAB9F.jvm1]
2010 10:27:40 AM org.apache.catalina.tribes.group.GroupChannel
messageReceived
FINER: GroupChannel delivered[true] id:UniqueId{48, -7, -97, -123, -116,
-54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17}
Jun 28, 2010 10:27:40 AM
org.apache.catalina.tribes.transport.nio.NioReplicationTask sendAck
FINER: ACK sent to 55801
Jun 28, 2010 10:27:40 AM
org.apache.catalina.tribes.transport.nio.ParallelNioSender doLoop
FINER: ParallelNioSender - Sent msg:UniqueId{48, -7, -97, -123, -116,
-54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28
10:27:40.785 to tcp://{127, 0, 0, 1}:4010
Jun 28, 2010 10:27:40 AM
org.apache.catalina.tribes.transport.nio.ParallelNioSender doLoop
FINER: ParallelNioSender - Sent msg:UniqueId{48, -7, -97, -123, -116,
-54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28
10:27:40.786 to tcp://{127, 0, 0, 1}:4020
Jun 28, 2010 10:27:40 AM
org.apache.catalina.tribes.group.ChannelCoordinator sendMessage
FINER: ChannelCoordinator - Sent msg:UniqueId{48, -7, -97, -123, -116,
-54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28
10:27:40.786 to {tcp://{127, 0, 0, 1}:4010, tcp://{127, 0, 0, 1}:4020}
Jun 28, 2010 10:27:40 AM org.apache.catalina.tribes.group.GroupChannel
send
FINER: GroupChannel - Sent msg:UniqueId{48, -7, -97, -123, -116, -54,
78, -17, -115, -13, -34, 116, 39, 49, 95, 17} at 2010-06-28 10:27:40.787
to {tcp://{127, 0, 0, 1}:4010, tcp://{127, 0, 0, 1}:4020}
Jun 28, 2010 10:27:40 AM org.apache.catalina.tribes.group.GroupChannel
send
FINER: GroupChannel - Send Message:UniqueId{48, -7, -97, -123, -116,
-54, 78, -17, -115, -13, -34, 116, 39, 49, 95, 17} is
SingleSignOnMessage[action=3, ssoId=7BA0AB7AE2BFDB08CE2EBE8F42D3E89C,
sessionId=null, username=null]
Jun 28, 2010 10:27:40 AM
org.apache.catalina.ha.authenticator.ClusterSingleSignOn deregister
FINE: SingleSignOnMessage Send with action 3
Jun 28, 2010 10:27:40 AM org.apache.catalina.authenticator.SingleSignOn
deregister
FINE: Deregistering sso id '7BA0AB7AE2BFDB08CE2EBE8F42D3E89C'
Jun 28, 2010 10:27:40 AM org.apache.catalina.connector.MapperListener
handleNotification
FINE: Handle Catalina:type=Manager,path=/cluster,host=webclust2 type :
JMX.mbean.unregistered
Jun 28, 2010 10:27:40 AM org.apache.catalina.connector.MapperListener
handleNotification
FINE: Handle Catalina:type=Manager,path=/cluster,host=webclust2 type :
JMX.mbean.unregistered
Jun 28, 2010 10:27:40 AM org.apache.catalina.core.StandardContext
listenerStop
FINE: Sending application stop events
/**
* Notifies the cluster that a single sign on session
* has been terminated due to a user logout, deregister
* the specified single sign on identifier, and invalidate
* any associated sessions on the local node.
*
* @param ssoId Single sign on identifier to deregister
*/
protected void deregister(String ssoId) {
if (cluster != null) {
messageNumber++;
SingleSignOnMessage msg =
new SingleSignOnMessage(cluster.getLocalMember(),
ssoId, null);
msg.setAction(SingleSignOnMessage.LOGOUT_SESSION);
cluster.sendClusterDomain(msg);
if (containerLog.isDebugEnabled())
containerLog.debug("SingleSignOnMessage Send with action
"
+ msg.getAction());
}
deregisterLocal(ssoId);
}
protected void deregisterLocal(String ssoId) {
super.deregister(ssoId);
}
-----Original Message-----
From: Pid [mailto:pid@pidster.com]
Sent: Friday, June 25, 2010 4:29 AM
To: Tomcat Users List
Subject: Re: question for sso session replication in tomcat 6.0.26
On 24/06/2010 21:49, Okubo, Yasushi (TSD) wrote:
> My bad.
>
> I added *.jsp to the filter since it contains the path to index page
as
> follows. Now, I am wondering when sso session id is created and
> replicated, is it when index.jsp was accessed or login.jsp was
accessed?
You had added it and have now removed it?
The normal session id is created when you access a JSP for the first
time, unless you have specifically configured JSPs to not create a
session. A session can also be created manually by a Filter or a
Servlet.
The SSO session is created when the container login process completes
authentication successfully.
I'm not entirely clear on when SSO replication occurs - presumably only
when there's a change like session invalidation or creation.
p
> == index.jsp ==
> <% response.sendRedirect("/test/index.html?homepage=dyn&prop=Home");
%>
>
> -----Original Message-----
> From: Okubo, Yasushi (TSD)
> Sent: Thursday, June 24, 2010 1:13 PM
> To: 'Tomcat Users List'
> Subject: RE: question for sso session replication in tomcat 6.0.26
>
>
> Hi Pid
>
> I started getting the following error upon login to one node onto
> cluster.
> Could you tell me what this mean is?
>
> Yasushi
>
>
> Jun 24, 2010 10:51:58 AM org.apache.catalina.ha.tcp.ReplicationValve
> sendReplicationMessage
> SEVERE: Unable to perform replication request.
> java.lang.NullPointerException
> at
>
org.apache.catalina.ha.tcp.ReplicationValve.isRequestWithoutSessionChang
> e(ReplicationValve.java:590)
> at
>
org.apache.catalina.ha.tcp.ReplicationValve.sendSessionReplicationMessag
> e(ReplicationValve.java:516)
> at
>
org.apache.catalina.ha.tcp.ReplicationValve.sendReplicationMessage(Repli
> cationValve.java:430)
> at
>
org.apache.catalina.ha.tcp.ReplicationValve.invoke(ReplicationValve.java
> :363)
> at
>
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
> :102)
> at
>
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555
> )
> at
>
org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:
> 421)
> at
>
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
> java:109)
> at
>
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:2
> 98)
> at
>
org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:427)
> at
>
org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpApr
> Protocol.java:384)
> at
>
org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1555)
> at java.lang.Thread.run(Thread.java:619)
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: question for sso session replication in tomcat 6.0.26
Posted by Pid <pi...@pidster.com>.
On 24/06/2010 21:49, Okubo, Yasushi (TSD) wrote:
> My bad.
>
> I added *.jsp to the filter since it contains the path to index page as
> follows. Now, I am wondering when sso session id is created and
> replicated, is it when index.jsp was accessed or login.jsp was accessed?
You had added it and have now removed it?
The normal session id is created when you access a JSP for the first
time, unless you have specifically configured JSPs to not create a
session. A session can also be created manually by a Filter or a Servlet.
The SSO session is created when the container login process completes
authentication successfully.
I'm not entirely clear on when SSO replication occurs - presumably only
when there's a change like session invalidation or creation.
p
> == index.jsp ==
> <% response.sendRedirect("/test/index.html?homepage=dyn&prop=Home"); %>
>
> -----Original Message-----
> From: Okubo, Yasushi (TSD)
> Sent: Thursday, June 24, 2010 1:13 PM
> To: 'Tomcat Users List'
> Subject: RE: question for sso session replication in tomcat 6.0.26
>
>
> Hi Pid
>
> I started getting the following error upon login to one node onto
> cluster.
> Could you tell me what this mean is?
>
> Yasushi
>
>
> Jun 24, 2010 10:51:58 AM org.apache.catalina.ha.tcp.ReplicationValve
> sendReplicationMessage
> SEVERE: Unable to perform replication request.
> java.lang.NullPointerException
> at
> org.apache.catalina.ha.tcp.ReplicationValve.isRequestWithoutSessionChang
> e(ReplicationValve.java:590)
> at
> org.apache.catalina.ha.tcp.ReplicationValve.sendSessionReplicationMessag
> e(ReplicationValve.java:516)
> at
> org.apache.catalina.ha.tcp.ReplicationValve.sendReplicationMessage(Repli
> cationValve.java:430)
> at
> org.apache.catalina.ha.tcp.ReplicationValve.invoke(ReplicationValve.java
> :363)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
> :102)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555
> )
> at
> org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:
> 421)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
> java:109)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:2
> 98)
> at
> org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:427)
> at
> org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpApr
> Protocol.java:384)
> at
> org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1555)
> at java.lang.Thread.run(Thread.java:619)
>
>
> -----Original Message-----
> From: Pid [mailto:pid@pidster.com]
> Sent: Wednesday, June 23, 2010 1:06 AM
> To: Tomcat Users List
> Subject: Re: question for sso session replication in tomcat 6.0.26
>
> I'll have to look at the code, but maybe you're being affected by a
> recent bug whereby the session id changes after login but isn't then
> replicated.
>
> You might search bugzilla to see if this applies to 6.0.26.
>
>
> p
>
> On 22 Jun 2010, at 22:41, "Okubo, Yasushi (TSD)"
> <Ya...@takedasd.com> wrote:
>
>>
>> Hi
>>
>> There were two cookies created by Tomcat 6.0.26. One is for SSO, and
> the
>> other is for regular session between client and tomcat. JSESSIONID is
>> working fine : it means session replication and failover, but not
>> JSESSIONIDSSO. JSESSIONIDSSO is updated with new value upon relogin.
>>
>> yasushi
>>
>>
>> JSESSIONIDSSO
>> 65110434847FE0AA1F1EBF0EF0871D25
>>
>>
>> JSESSIONID
>> 5CFE92814875C4DEFC554526147698A3.jvm2
>>
>> -----Original Message-----
>> From: Jon Brisbin [mailto:jon.brisbin@npcinternational.com]
>> Sent: Tuesday, June 22, 2010 2:17 PM
>> To: Tomcat Users List
>> Cc: Okubo, Yasushi (TSD)
>> Subject: Re: question for sso session replication in tomcat 6.0.26
>>
>> Are you using a "jvmRoute" setting on your BalancerMember definition
> in
>> mod_proxy config and on the <Engine/> element in server.xml? Your
> cookie
>> would have the jvmRoute property added to the end of it (e.g.
>> ALONGMD5HASH.server1) if so.
>>
>> From the Almighty Google:
>> http://community.jboss.org/wiki/usingmodproxywithjboss
>>
>> Jon Brisbin
>> Portal Webmaster
>> NPC International, Inc.
>>
>>
>>
>> On Jun 22, 2010, at 3:48 PM, Okubo, Yasushi (TSD) wrote:
>>
>>> Hi
>>>
>>> I downloaded apache apache v2.2.15 and compiled and installed, but
> the
>>> result was the same.
>>>
>>> Session sso replication looked like failed. Upon shutting down the
>>> node, it kicked me out of password protected area and needed to
>> re-loin
>>> on the second node.
>>>
>>> On apache, I installed/enabled all modules including basic
>>> authentication etc. Is there any requirement on apache side or how
>> the
>>> virtual host should be set up in httpd.conf to make sso failover
> work?
>>>
>>> Thanks,
>>> yasushi
>>>
>>> -----Original Message-----
>>> From: Pid [mailto:pid@pidster.com]
>>> Sent: Tuesday, June 22, 2010 8:04 AM
>>> To: Tomcat Users List
>>> Subject: Re: question for sso session replication in tomcat 6.0.26
>>>
>>> On 22/06/2010 15:56, Okubo, Yasushi (TSD) wrote:
>>>> Hi Andrew
>>>>
>>>> In case of no failover, SSO works for all web applications on the
>> same
>>> host. Upon failover [shutting down one node], a user is routed to
> the
>>> other node, and TC is asking for a user to re-login when he/she tried
>> to
>>> access password protected area.
>>>>
>>>> I have checked many times on server.xml and session replication is
>>> working fine upon failover, so I cannot think any misconfiguration on
>>> server.xml
>>>> The issue is SSO failover is not working. I think it might be
>> related
>>> to my apache virtual host setup, but could not figure it out.
>>>>
>>>> Thanks for your help,
>>>> yasushi
>>>>
>>>> I am using mod_proxy_ajp, mod_proxy_balancer [v2.2.3]
>>>
>>> mod_proxy_ajp appeared in 2.2.3 for the first time, it was functional
>>> but not perfect & there are many bugfixes and improvements since
> then,
>>> you should upgrade HTTPD.
>>>
>>>
>>> p
>>>
>>>> OS : Redhat Linux 64bit RHEL v5.5
>>>> JDK : 1.6.0.20
>>>>
>>>> === I created virtual host on port 9050 ==
>>>> Httpd.conf
>>>>
>>>> <VirtualHost 10.250.200.57:9050>
>>>> ServerAdmin xyz
>>>> ServerName webclust1.xyz.com
>>>> ServerAlias webclust1
>>>> ErrorLog logs/webclust_cluster_error.log
>>>> CustomLog logs/webclust-cluster-access_log common
>>>>
>>>> <Location /balancer-manager>
>>>> SetHandler balancer-manager
>>>>
>>>> Order Deny,Allow
>>>> Deny from all
>>>> Allow from all
>>>> </Location>
>>>>
>>>> ProxyRequests off
>>>> <Proxy balancer://webclust>
>>>> BalancerMember ajp://10.250.200.57:9001 loadfactor=10 max=150
>> smax=145
>>> route=jvm1
>>>> BalancerMember ajp://10.250.200.57:9002 loadfactor=10 max=150
>> smax=145
>>> route=jvm2
>>>> BalancerMember ajp://10.250.200.57:9003 loadfactor=10 max=150
>> smax=145
>>> route=jvm3
>>>> Order Deny,Allow
>>>> Allow from all
>>>> </Proxy>
>>>>
>>>> #Do not proxy balancer-manager
>>>> ProxyPass /balancer-manager !
>>>>
>>>> <Location /examples>
>>>> ProxyPass balancer://webclust/examples
>>> stickysession=JSESSIONID|jsessionid
>>>> ProxyPassReverse balancer://webclust/examples
>>>> Order Deny,Allow
>>>> Allow from all
>>>> </Location>
>>>>
>>>> <Location / >
>>>> ProxyPass balancer://webclust/ stickysession=JSESSIONID|jsessionid
>>>> ProxyPassReverse balancer://webclust/
>>>> Order Deny,Allow
>>>> Allow from all
>>>> </Location>
>>>>
>>>>
>>>> === server.xml ===
>>>> <!-- Define an AJP 1.3 Connector on port 8009 -->
>>>> <Connector port="9002" protocol="AJP/1.3" redirectPort="8443" />
>>>>
>>>> <Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1">
>>>>
>>>> <Host name="localhost" appBase="webapps"
>>>> unpackWARs="true" autoDeploy="true"
>>>> xmlValidation="false" xmlNamespaceAware="false">
>>>>
>>>> <Cluster
>>> className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
>>>> channelSendOptions="4">
>>>>
>>>> <Manager
>>> className="org.apache.catalina.ha.session.DeltaManager"
>>>> name="node2"
>>>> expireSessionsOnShutdown="false"
>>>> notifyListenersOnReplication="true"/>
>>>>
>>>> <Channel
>>> className="org.apache.catalina.tribes.group.GroupChannel">
>>>> <Membership
>>> className="org.apache.catalina.tribes.membership.McastService"
>>>> address="228.0.0.5"
>>>> port="45564"
>>>> frequency="500"
>>>> dropTime="3000"/>
>>>> <Receiver
>>> className="org.apache.catalina.tribes.transport.nio.NioReceiver"
>>>> address="auto"
>>>> port="4020"
>>>> autoBind="100"
>>>> selectorTimeout="5000"
>>>> maxThreads="12"/>
>>>> <Sender
>>>
>>
> className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
>>>> <Transport
>>>
>>
> className="org.apache.catalina.tribes.transport.nio.PooledParallelSender
>>> "/>
>>>> </Sender>
>>>> <Interceptor
>>>
>>
> className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetec
>>> tor"/>
>>>> <Interceptor
>>>
>>
> className="org.apache.catalina.tribes.group.interceptors.MessageDispatch
>>> 15Interceptor"/>
>>>> <Interceptor
>>>
>>
> className="org.apache.catalina.tribes.group.interceptors.ThroughputInter
>>> ceptor"/>
>>>> </Channel>
>>>>
>>>> <Valve
>>> className="org.apache.catalina.ha.tcp.ReplicationValve"
>>>>
>>>
>>
> filter=".*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;
>>> .*\.xls;.*\.sdf;.*\.xml;"/>
>>>> <!-- only with jk_mod failover-->
>>>> <Valve
>>> className="org.apache.catalina.ha.session.JvmRouteBinderValve"
>>>> enabled="true" sessionIdAttribute="takeoverSessionid"
>>> />
>>>> <!--
>>>> <Deployer
>>> className="org.apache.catalina.ha.deploy.FarmWarDeployer"
>>>> tempDir="/tmp/war-temp/"
>>>>
>>> deployDir="/usr/local/apache/node2-tomcat-6.0.26/webapps"
>>>> watchDir="/tmp/war-listen/"
>>>> watchEnabled="true"/>
>>>> -->
>>>> <!-- only with jk_mod and jvmroutebindervalve-->
>>>> <ClusterListener
>>>
>>
> className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListene
>>> r"/>
>>>> <ClusterListener
>>> className="org.apache.catalina.ha.session.ClusterSessionListener"/>
>>>> </Cluster>
>>>>
>>>> <Valve
>>> className="org.apache.catalina.ha.authenticator.ClusterSingleSignOn"
>> />
>>>>
>>>> <Valve className="org.apache.catalina.valves.AccessLogValve"
>>> directory="logs"
>>>> prefix="webappqa_node2_access_log." suffix=".log"
>>> pattern="common" resolveHosts="false"/>
>>>>
>>>> </Host>
>>>> </Engine>
>>>>
>>>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
RE: question for sso session replication in tomcat 6.0.26
Posted by "Okubo, Yasushi (TSD)" <Ya...@takedasd.com>.
My bad.
I added *.jsp to the filter since it contains the path to index page as
follows. Now, I am wondering when sso session id is created and
replicated, is it when index.jsp was accessed or login.jsp was accessed?
== index.jsp ==
<% response.sendRedirect("/test/index.html?homepage=dyn&prop=Home"); %>
-----Original Message-----
From: Okubo, Yasushi (TSD)
Sent: Thursday, June 24, 2010 1:13 PM
To: 'Tomcat Users List'
Subject: RE: question for sso session replication in tomcat 6.0.26
Hi Pid
I started getting the following error upon login to one node onto
cluster.
Could you tell me what this mean is?
Yasushi
Jun 24, 2010 10:51:58 AM org.apache.catalina.ha.tcp.ReplicationValve
sendReplicationMessage
SEVERE: Unable to perform replication request.
java.lang.NullPointerException
at
org.apache.catalina.ha.tcp.ReplicationValve.isRequestWithoutSessionChang
e(ReplicationValve.java:590)
at
org.apache.catalina.ha.tcp.ReplicationValve.sendSessionReplicationMessag
e(ReplicationValve.java:516)
at
org.apache.catalina.ha.tcp.ReplicationValve.sendReplicationMessage(Repli
cationValve.java:430)
at
org.apache.catalina.ha.tcp.ReplicationValve.invoke(ReplicationValve.java
:363)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
:102)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555
)
at
org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:
421)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:2
98)
at
org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:427)
at
org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpApr
Protocol.java:384)
at
org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1555)
at java.lang.Thread.run(Thread.java:619)
-----Original Message-----
From: Pid [mailto:pid@pidster.com]
Sent: Wednesday, June 23, 2010 1:06 AM
To: Tomcat Users List
Subject: Re: question for sso session replication in tomcat 6.0.26
I'll have to look at the code, but maybe you're being affected by a
recent bug whereby the session id changes after login but isn't then
replicated.
You might search bugzilla to see if this applies to 6.0.26.
p
On 22 Jun 2010, at 22:41, "Okubo, Yasushi (TSD)"
<Ya...@takedasd.com> wrote:
>
> Hi
>
> There were two cookies created by Tomcat 6.0.26. One is for SSO, and
the
> other is for regular session between client and tomcat. JSESSIONID is
> working fine : it means session replication and failover, but not
> JSESSIONIDSSO. JSESSIONIDSSO is updated with new value upon relogin.
>
> yasushi
>
>
> JSESSIONIDSSO
> 65110434847FE0AA1F1EBF0EF0871D25
>
>
> JSESSIONID
> 5CFE92814875C4DEFC554526147698A3.jvm2
>
> -----Original Message-----
> From: Jon Brisbin [mailto:jon.brisbin@npcinternational.com]
> Sent: Tuesday, June 22, 2010 2:17 PM
> To: Tomcat Users List
> Cc: Okubo, Yasushi (TSD)
> Subject: Re: question for sso session replication in tomcat 6.0.26
>
> Are you using a "jvmRoute" setting on your BalancerMember definition
in
> mod_proxy config and on the <Engine/> element in server.xml? Your
cookie
> would have the jvmRoute property added to the end of it (e.g.
> ALONGMD5HASH.server1) if so.
>
> From the Almighty Google:
> http://community.jboss.org/wiki/usingmodproxywithjboss
>
> Jon Brisbin
> Portal Webmaster
> NPC International, Inc.
>
>
>
> On Jun 22, 2010, at 3:48 PM, Okubo, Yasushi (TSD) wrote:
>
>> Hi
>>
>> I downloaded apache apache v2.2.15 and compiled and installed, but
the
>> result was the same.
>>
>> Session sso replication looked like failed. Upon shutting down the
>> node, it kicked me out of password protected area and needed to
> re-loin
>> on the second node.
>>
>> On apache, I installed/enabled all modules including basic
>> authentication etc. Is there any requirement on apache side or how
> the
>> virtual host should be set up in httpd.conf to make sso failover
work?
>>
>> Thanks,
>> yasushi
>>
>> -----Original Message-----
>> From: Pid [mailto:pid@pidster.com]
>> Sent: Tuesday, June 22, 2010 8:04 AM
>> To: Tomcat Users List
>> Subject: Re: question for sso session replication in tomcat 6.0.26
>>
>> On 22/06/2010 15:56, Okubo, Yasushi (TSD) wrote:
>>> Hi Andrew
>>>
>>> In case of no failover, SSO works for all web applications on the
> same
>> host. Upon failover [shutting down one node], a user is routed to
the
>> other node, and TC is asking for a user to re-login when he/she tried
> to
>> access password protected area.
>>>
>>> I have checked many times on server.xml and session replication is
>> working fine upon failover, so I cannot think any misconfiguration on
>> server.xml
>>> The issue is SSO failover is not working. I think it might be
> related
>> to my apache virtual host setup, but could not figure it out.
>>>
>>> Thanks for your help,
>>> yasushi
>>>
>>> I am using mod_proxy_ajp, mod_proxy_balancer [v2.2.3]
>>
>> mod_proxy_ajp appeared in 2.2.3 for the first time, it was functional
>> but not perfect & there are many bugfixes and improvements since
then,
>> you should upgrade HTTPD.
>>
>>
>> p
>>
>>> OS : Redhat Linux 64bit RHEL v5.5
>>> JDK : 1.6.0.20
>>>
>>> === I created virtual host on port 9050 ==
>>> Httpd.conf
>>>
>>> <VirtualHost 10.250.200.57:9050>
>>> ServerAdmin xyz
>>> ServerName webclust1.xyz.com
>>> ServerAlias webclust1
>>> ErrorLog logs/webclust_cluster_error.log
>>> CustomLog logs/webclust-cluster-access_log common
>>>
>>> <Location /balancer-manager>
>>> SetHandler balancer-manager
>>>
>>> Order Deny,Allow
>>> Deny from all
>>> Allow from all
>>> </Location>
>>>
>>> ProxyRequests off
>>> <Proxy balancer://webclust>
>>> BalancerMember ajp://10.250.200.57:9001 loadfactor=10 max=150
> smax=145
>> route=jvm1
>>> BalancerMember ajp://10.250.200.57:9002 loadfactor=10 max=150
> smax=145
>> route=jvm2
>>> BalancerMember ajp://10.250.200.57:9003 loadfactor=10 max=150
> smax=145
>> route=jvm3
>>> Order Deny,Allow
>>> Allow from all
>>> </Proxy>
>>>
>>> #Do not proxy balancer-manager
>>> ProxyPass /balancer-manager !
>>>
>>> <Location /examples>
>>> ProxyPass balancer://webclust/examples
>> stickysession=JSESSIONID|jsessionid
>>> ProxyPassReverse balancer://webclust/examples
>>> Order Deny,Allow
>>> Allow from all
>>> </Location>
>>>
>>> <Location / >
>>> ProxyPass balancer://webclust/ stickysession=JSESSIONID|jsessionid
>>> ProxyPassReverse balancer://webclust/
>>> Order Deny,Allow
>>> Allow from all
>>> </Location>
>>>
>>>
>>> === server.xml ===
>>> <!-- Define an AJP 1.3 Connector on port 8009 -->
>>> <Connector port="9002" protocol="AJP/1.3" redirectPort="8443" />
>>>
>>> <Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1">
>>>
>>> <Host name="localhost" appBase="webapps"
>>> unpackWARs="true" autoDeploy="true"
>>> xmlValidation="false" xmlNamespaceAware="false">
>>>
>>> <Cluster
>> className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
>>> channelSendOptions="4">
>>>
>>> <Manager
>> className="org.apache.catalina.ha.session.DeltaManager"
>>> name="node2"
>>> expireSessionsOnShutdown="false"
>>> notifyListenersOnReplication="true"/>
>>>
>>> <Channel
>> className="org.apache.catalina.tribes.group.GroupChannel">
>>> <Membership
>> className="org.apache.catalina.tribes.membership.McastService"
>>> address="228.0.0.5"
>>> port="45564"
>>> frequency="500"
>>> dropTime="3000"/>
>>> <Receiver
>> className="org.apache.catalina.tribes.transport.nio.NioReceiver"
>>> address="auto"
>>> port="4020"
>>> autoBind="100"
>>> selectorTimeout="5000"
>>> maxThreads="12"/>
>>> <Sender
>>
>
className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
>>> <Transport
>>
>
className="org.apache.catalina.tribes.transport.nio.PooledParallelSender
>> "/>
>>> </Sender>
>>> <Interceptor
>>
>
className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetec
>> tor"/>
>>> <Interceptor
>>
>
className="org.apache.catalina.tribes.group.interceptors.MessageDispatch
>> 15Interceptor"/>
>>> <Interceptor
>>
>
className="org.apache.catalina.tribes.group.interceptors.ThroughputInter
>> ceptor"/>
>>> </Channel>
>>>
>>> <Valve
>> className="org.apache.catalina.ha.tcp.ReplicationValve"
>>>
>>
>
filter=".*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;
>> .*\.xls;.*\.sdf;.*\.xml;"/>
>>> <!-- only with jk_mod failover-->
>>> <Valve
>> className="org.apache.catalina.ha.session.JvmRouteBinderValve"
>>> enabled="true" sessionIdAttribute="takeoverSessionid"
>> />
>>> <!--
>>> <Deployer
>> className="org.apache.catalina.ha.deploy.FarmWarDeployer"
>>> tempDir="/tmp/war-temp/"
>>>
>> deployDir="/usr/local/apache/node2-tomcat-6.0.26/webapps"
>>> watchDir="/tmp/war-listen/"
>>> watchEnabled="true"/>
>>> -->
>>> <!-- only with jk_mod and jvmroutebindervalve-->
>>> <ClusterListener
>>
>
className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListene
>> r"/>
>>> <ClusterListener
>> className="org.apache.catalina.ha.session.ClusterSessionListener"/>
>>> </Cluster>
>>>
>>> <Valve
>> className="org.apache.catalina.ha.authenticator.ClusterSingleSignOn"
> />
>>>
>>> <Valve className="org.apache.catalina.valves.AccessLogValve"
>> directory="logs"
>>> prefix="webappqa_node2_access_log." suffix=".log"
>> pattern="common" resolveHosts="false"/>
>>>
>>> </Host>
>>> </Engine>
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: question for sso session replication in tomcat 6.0.26
Posted by "Okubo, Yasushi (TSD)" <Ya...@takedasd.com>.
Hi Pid
I started getting the following error upon login to one node onto
cluster.
Could you tell me what this mean is?
Yasushi
Jun 24, 2010 10:51:58 AM org.apache.catalina.ha.tcp.ReplicationValve
sendReplicationMessage
SEVERE: Unable to perform replication request.
java.lang.NullPointerException
at
org.apache.catalina.ha.tcp.ReplicationValve.isRequestWithoutSessionChang
e(ReplicationValve.java:590)
at
org.apache.catalina.ha.tcp.ReplicationValve.sendSessionReplicationMessag
e(ReplicationValve.java:516)
at
org.apache.catalina.ha.tcp.ReplicationValve.sendReplicationMessage(Repli
cationValve.java:430)
at
org.apache.catalina.ha.tcp.ReplicationValve.invoke(ReplicationValve.java
:363)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
:102)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555
)
at
org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:
421)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:2
98)
at
org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:427)
at
org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpApr
Protocol.java:384)
at
org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1555)
at java.lang.Thread.run(Thread.java:619)
-----Original Message-----
From: Pid [mailto:pid@pidster.com]
Sent: Wednesday, June 23, 2010 1:06 AM
To: Tomcat Users List
Subject: Re: question for sso session replication in tomcat 6.0.26
I'll have to look at the code, but maybe you're being affected by a
recent bug whereby the session id changes after login but isn't then
replicated.
You might search bugzilla to see if this applies to 6.0.26.
p
On 22 Jun 2010, at 22:41, "Okubo, Yasushi (TSD)"
<Ya...@takedasd.com> wrote:
>
> Hi
>
> There were two cookies created by Tomcat 6.0.26. One is for SSO, and
the
> other is for regular session between client and tomcat. JSESSIONID is
> working fine : it means session replication and failover, but not
> JSESSIONIDSSO. JSESSIONIDSSO is updated with new value upon relogin.
>
> yasushi
>
>
> JSESSIONIDSSO
> 65110434847FE0AA1F1EBF0EF0871D25
>
>
> JSESSIONID
> 5CFE92814875C4DEFC554526147698A3.jvm2
>
> -----Original Message-----
> From: Jon Brisbin [mailto:jon.brisbin@npcinternational.com]
> Sent: Tuesday, June 22, 2010 2:17 PM
> To: Tomcat Users List
> Cc: Okubo, Yasushi (TSD)
> Subject: Re: question for sso session replication in tomcat 6.0.26
>
> Are you using a "jvmRoute" setting on your BalancerMember definition
in
> mod_proxy config and on the <Engine/> element in server.xml? Your
cookie
> would have the jvmRoute property added to the end of it (e.g.
> ALONGMD5HASH.server1) if so.
>
> From the Almighty Google:
> http://community.jboss.org/wiki/usingmodproxywithjboss
>
> Jon Brisbin
> Portal Webmaster
> NPC International, Inc.
>
>
>
> On Jun 22, 2010, at 3:48 PM, Okubo, Yasushi (TSD) wrote:
>
>> Hi
>>
>> I downloaded apache apache v2.2.15 and compiled and installed, but
the
>> result was the same.
>>
>> Session sso replication looked like failed. Upon shutting down the
>> node, it kicked me out of password protected area and needed to
> re-loin
>> on the second node.
>>
>> On apache, I installed/enabled all modules including basic
>> authentication etc. Is there any requirement on apache side or how
> the
>> virtual host should be set up in httpd.conf to make sso failover
work?
>>
>> Thanks,
>> yasushi
>>
>> -----Original Message-----
>> From: Pid [mailto:pid@pidster.com]
>> Sent: Tuesday, June 22, 2010 8:04 AM
>> To: Tomcat Users List
>> Subject: Re: question for sso session replication in tomcat 6.0.26
>>
>> On 22/06/2010 15:56, Okubo, Yasushi (TSD) wrote:
>>> Hi Andrew
>>>
>>> In case of no failover, SSO works for all web applications on the
> same
>> host. Upon failover [shutting down one node], a user is routed to
the
>> other node, and TC is asking for a user to re-login when he/she tried
> to
>> access password protected area.
>>>
>>> I have checked many times on server.xml and session replication is
>> working fine upon failover, so I cannot think any misconfiguration on
>> server.xml
>>> The issue is SSO failover is not working. I think it might be
> related
>> to my apache virtual host setup, but could not figure it out.
>>>
>>> Thanks for your help,
>>> yasushi
>>>
>>> I am using mod_proxy_ajp, mod_proxy_balancer [v2.2.3]
>>
>> mod_proxy_ajp appeared in 2.2.3 for the first time, it was functional
>> but not perfect & there are many bugfixes and improvements since
then,
>> you should upgrade HTTPD.
>>
>>
>> p
>>
>>> OS : Redhat Linux 64bit RHEL v5.5
>>> JDK : 1.6.0.20
>>>
>>> === I created virtual host on port 9050 ==
>>> Httpd.conf
>>>
>>> <VirtualHost 10.250.200.57:9050>
>>> ServerAdmin xyz
>>> ServerName webclust1.xyz.com
>>> ServerAlias webclust1
>>> ErrorLog logs/webclust_cluster_error.log
>>> CustomLog logs/webclust-cluster-access_log common
>>>
>>> <Location /balancer-manager>
>>> SetHandler balancer-manager
>>>
>>> Order Deny,Allow
>>> Deny from all
>>> Allow from all
>>> </Location>
>>>
>>> ProxyRequests off
>>> <Proxy balancer://webclust>
>>> BalancerMember ajp://10.250.200.57:9001 loadfactor=10 max=150
> smax=145
>> route=jvm1
>>> BalancerMember ajp://10.250.200.57:9002 loadfactor=10 max=150
> smax=145
>> route=jvm2
>>> BalancerMember ajp://10.250.200.57:9003 loadfactor=10 max=150
> smax=145
>> route=jvm3
>>> Order Deny,Allow
>>> Allow from all
>>> </Proxy>
>>>
>>> #Do not proxy balancer-manager
>>> ProxyPass /balancer-manager !
>>>
>>> <Location /examples>
>>> ProxyPass balancer://webclust/examples
>> stickysession=JSESSIONID|jsessionid
>>> ProxyPassReverse balancer://webclust/examples
>>> Order Deny,Allow
>>> Allow from all
>>> </Location>
>>>
>>> <Location / >
>>> ProxyPass balancer://webclust/ stickysession=JSESSIONID|jsessionid
>>> ProxyPassReverse balancer://webclust/
>>> Order Deny,Allow
>>> Allow from all
>>> </Location>
>>>
>>>
>>> === server.xml ===
>>> <!-- Define an AJP 1.3 Connector on port 8009 -->
>>> <Connector port="9002" protocol="AJP/1.3" redirectPort="8443" />
>>>
>>> <Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1">
>>>
>>> <Host name="localhost" appBase="webapps"
>>> unpackWARs="true" autoDeploy="true"
>>> xmlValidation="false" xmlNamespaceAware="false">
>>>
>>> <Cluster
>> className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
>>> channelSendOptions="4">
>>>
>>> <Manager
>> className="org.apache.catalina.ha.session.DeltaManager"
>>> name="node2"
>>> expireSessionsOnShutdown="false"
>>> notifyListenersOnReplication="true"/>
>>>
>>> <Channel
>> className="org.apache.catalina.tribes.group.GroupChannel">
>>> <Membership
>> className="org.apache.catalina.tribes.membership.McastService"
>>> address="228.0.0.5"
>>> port="45564"
>>> frequency="500"
>>> dropTime="3000"/>
>>> <Receiver
>> className="org.apache.catalina.tribes.transport.nio.NioReceiver"
>>> address="auto"
>>> port="4020"
>>> autoBind="100"
>>> selectorTimeout="5000"
>>> maxThreads="12"/>
>>> <Sender
>>
>
className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
>>> <Transport
>>
>
className="org.apache.catalina.tribes.transport.nio.PooledParallelSender
>> "/>
>>> </Sender>
>>> <Interceptor
>>
>
className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetec
>> tor"/>
>>> <Interceptor
>>
>
className="org.apache.catalina.tribes.group.interceptors.MessageDispatch
>> 15Interceptor"/>
>>> <Interceptor
>>
>
className="org.apache.catalina.tribes.group.interceptors.ThroughputInter
>> ceptor"/>
>>> </Channel>
>>>
>>> <Valve
>> className="org.apache.catalina.ha.tcp.ReplicationValve"
>>>
>>
>
filter=".*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;
>> .*\.xls;.*\.sdf;.*\.xml;"/>
>>> <!-- only with jk_mod failover-->
>>> <Valve
>> className="org.apache.catalina.ha.session.JvmRouteBinderValve"
>>> enabled="true" sessionIdAttribute="takeoverSessionid"
>> />
>>> <!--
>>> <Deployer
>> className="org.apache.catalina.ha.deploy.FarmWarDeployer"
>>> tempDir="/tmp/war-temp/"
>>>
>> deployDir="/usr/local/apache/node2-tomcat-6.0.26/webapps"
>>> watchDir="/tmp/war-listen/"
>>> watchEnabled="true"/>
>>> -->
>>> <!-- only with jk_mod and jvmroutebindervalve-->
>>> <ClusterListener
>>
>
className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListene
>> r"/>
>>> <ClusterListener
>> className="org.apache.catalina.ha.session.ClusterSessionListener"/>
>>> </Cluster>
>>>
>>> <Valve
>> className="org.apache.catalina.ha.authenticator.ClusterSingleSignOn"
> />
>>>
>>> <Valve className="org.apache.catalina.valves.AccessLogValve"
>> directory="logs"
>>> prefix="webappqa_node2_access_log." suffix=".log"
>> pattern="common" resolveHosts="false"/>
>>>
>>> </Host>
>>> </Engine>
>>>
>>>
>>> -----Original Message-----
>>> From: Andrew Bruno [mailto:andrew.bruno@gmail.com]
>>> Sent: Monday, June 21, 2010 10:09 PM
>>> To: Tomcat Users List
>>> Subject: Re: question for sso session replication in tomcat 6.0.26
>>>
>>> Oh sorry, I re-read your answer. Not sure why SSO is not working,
be
>>> interested to find out though..
>>>
>>> AB
>>>
>>> On Tue, Jun 22, 2010 at 3:04 PM, Andrew Bruno
> <an...@gmail.com>
>> wrote:
>>>> Hi Yasushi
>>>>
>>>> In your serverl.xml have you added the jvmroute to the Engine?
>>>>
>>>> i.e.
>>>>
>>>> <Engine name="Catalina" defaultHost="localhost" jvmRoute="1">
>>>>
>>>> Andrew
>>>>
>>>> On Tue, Jun 22, 2010 at 2:50 PM, Okubo, Yasushi (TSD)
>> <Ya...@takedasd.com> wrote:
>>>>> Hi Andrew
>>>>>
>>>>> Thank for your post. When I checked the session id from firefox,
>> sso session id [jsessionidsso] does not have jvmroute info, but only
>> jsessionid has jvmroute. So, session replication upon failover is
>> working fine, but singlesionon upon failover is not working on tomcat
>> 6.0.x (including 6.0.26).
>>>>>
>>>>> yasushi
>>>>>
>>>>> -----Original Message-----
>>>>> From: Andrew Bruno [mailto:andrew.bruno@gmail.com]
>>>>> Sent: Monday, June 21, 2010 9:18 PM
>>>>> To: Tomcat Users List
>>>>> Subject: Re: question for sso session replication in tomcat 6.0.26
>>>>>
>>>>> Looking at the code I think this is wrong
>>>>>
>>>>> if (!_ssoSessionId.contains("." + jvmRoute)) {
>>>>> _ssoSessionId += "." + jvmRoute;
>>>>> response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME,
>> _ssoSessionId));
>>>>> }
>>>>>
>>>>> The original sessionId will already have the
> "."+_any_other_jvmRoute
>>>>> included, so you need to substring it, and append the new
jvmRoute.
>>>>>
>>>>> _ssoSessionId= _ssoSessionId.substring(0,
>> _ssoSessionId.indexOf("."))
>>>>>
>>>>> and then add
>>>>>
>>>>> _ssoSessionId += "." + jvmRoute;
>>>>>
>>>>> AB
>>>>>
>>>>> On Tue, Jun 22, 2010 at 1:03 PM, Okubo, Yasushi (TSD)
>>>>> <Ya...@takedasd.com> wrote:
>>>>>> Hi experts
>>>>>>
>>>>>>
>>>>>>
>>>>>> I found this old email from archive in TC 5.5.23.
>>>>>>
>>>>>> Does this problem still exist in tomcat 6.0.x or 6.0.26?
>>>>>>
>>>>>>
>>>>>>
>>>>>> When failover occurs, sso session id is updated with new number
>> after
>>>>>> forcing a user to relogin to the application since sso session id
>> is not
>>>>>> replicated and rewritten correctly. Could someone explain what
is
>>>>>> expected in current tomcat 6.0.x cluster upon failover? Should
> sso
>>>>>> session id is replicated correctly in tomcat 6.0.x?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> yasushi
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ROOKIE wrote:
>>>>>> Hi,
>>>>>> I have a problem with tomcat cluster + mod_proxy load balancer :
>>>>>>
>>>>>> We have a main app which authenticate itself to a webapp and from
>> this
>>>>>> app one
>>>>>> can launch embedded apps which use the SSO cookie to access other
>>>>>> webapps on
>>>>>> the server (Single-Sign-On for the user).
>>>>>>
>>>>>> Things are working perfectly for the normal cookie but not for
the
>> sso
>>>>>> cookie.
>>>>>>
>>>>>>
>>>>>> The problem I have is that tomcat does not replicate SSO sessions
>> so
>>>>>> when these embedded apps route through the load balancer we get
>> 401s on
>>>>>> all the other cluster members except the one which actually
>> generated
>>>>>> the SSO cookie.
>>>>>>
>>>>>> I wanted to know if we can edit the SSO cookie generated by
tomcat
>> to
>>>>>> also
>>>>>> contain the jvmRoute parameter so that the load balancer directly
>> goes
>>>>>> to the
>>>>>> correct cluster member.
>>>>>>
>>>>>>
>>>>>> I tried doing this in my code by fetching the SSO cookie and
>> appending
>>>>>> to it
>>>>>> the jvmRoute as follows :
>>>>>>
>>>>>> HttpServletRequest request =
>>>>>>
(HttpServletRequest)Security.getContext(HttpServletRequest.class);
>>>>>> HttpServletResponse response =
>>>>>>
>> (HttpServletResponse)Security.getContext(HttpServletResponse.class);
>>>>>> if(request != null) {
>>>>>> String jvmRoute = "Vinod_Cluster_1"; // as mentioned
>> in
>>>>>> server.xml
>>>>>> Cookie[] cookies = request.getCookies();
>>>>>> for(int nc=0; cookies != null && nc < cookies.length;
>> nc++)
>>>>>> {
>>>>>>
>> if(_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
>>>>>> _sessionId = cookies[nc].getValue();
>>>>>> }
>>>>>>
>>>>>> else if(_SSO_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
>>>>>>
>>>>>> _ssoSessionId = cookies[nc].getValue();
>>>>>> if (!_ssoSessionId.contains("." + jvmRoute)) {
>>>>>> _ssoSessionId += "." + jvmRoute;
>>>>>>
>>>>>> response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME,
>> _ssoSessionId));
>>>>>> }
>>>>>>
>>>>>>
>>>>>> }
>>>>>>
>>>>>>
>>>>>> But after this I started getting 401s from even the correct
> cluster
>>>>>> member. My guess is addCookie doesnt update the cookie in
tomcat's
>> cache
>>>>>> which is reasonable.
>>>>>>
>>>>>> Other thought was to edit tomcat's sso cookie generation code to
>> append
>>>>>> the
>>>>>> jvmRoute to the sso cookie.
>>>>>>
>>>>>>
>>>>>> Is there an better way to achieve this in my code base ?
>>>>>>
>>>>>> Thanks In Advance,
>>>>>> Vinod
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>>
>>>
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: question for sso session replication in tomcat 6.0.26
Posted by "Okubo, Yasushi (TSD)" <Ya...@takedasd.com>.
Hi Pid
I tested tomcat with three different versions [6.0.18, 6.0.20, 6.0.24]
and the all results were consistent. SingleSignOn session did not
failover.
I hope someone can help me about this.
yasushi
-----Original Message-----
From: Okubo, Yasushi (TSD)
Sent: Wednesday, June 23, 2010 9:20 AM
To: 'Tomcat Users List'
Subject: RE: question for sso session replication in tomcat 6.0.26
Thanks Pid
It might be related to the fix for 45255. This is the only one I can see
remotely related. According to this fix, (I might be wrong), but it
looks like once the user is logged-out from the application or node upon
regular logout or node shutdown or some other reasons, a user is asked
to relogin by default to renew sso session id. Is there any way to stop
this behavior to add a flag or some kind in server.xml?
I tested with mod_jk [v1.2.30] and httpd [2.2.15], and the result is
consistent with mod_proxy_ajp and mod_balancer. SingleSignOn session
does not failover.
I will try to test older Tomcat 6.0.1x today.
Yasushi
-----Original Message-----
From: Pid [mailto:pid@pidster.com]
Sent: Wednesday, June 23, 2010 1:06 AM
To: Tomcat Users List
Subject: Re: question for sso session replication in tomcat 6.0.26
I'll have to look at the code, but maybe you're being affected by a
recent bug whereby the session id changes after login but isn't then
replicated.
You might search bugzilla to see if this applies to 6.0.26.
p
On 22 Jun 2010, at 22:41, "Okubo, Yasushi (TSD)"
<Ya...@takedasd.com> wrote:
>
> Hi
>
> There were two cookies created by Tomcat 6.0.26. One is for SSO, and
the
> other is for regular session between client and tomcat. JSESSIONID is
> working fine : it means session replication and failover, but not
> JSESSIONIDSSO. JSESSIONIDSSO is updated with new value upon relogin.
>
> yasushi
>
>
> JSESSIONIDSSO
> 65110434847FE0AA1F1EBF0EF0871D25
>
>
> JSESSIONID
> 5CFE92814875C4DEFC554526147698A3.jvm2
>
> -----Original Message-----
> From: Jon Brisbin [mailto:jon.brisbin@npcinternational.com]
> Sent: Tuesday, June 22, 2010 2:17 PM
> To: Tomcat Users List
> Cc: Okubo, Yasushi (TSD)
> Subject: Re: question for sso session replication in tomcat 6.0.26
>
> Are you using a "jvmRoute" setting on your BalancerMember definition
in
> mod_proxy config and on the <Engine/> element in server.xml? Your
cookie
> would have the jvmRoute property added to the end of it (e.g.
> ALONGMD5HASH.server1) if so.
>
> From the Almighty Google:
> http://community.jboss.org/wiki/usingmodproxywithjboss
>
> Jon Brisbin
> Portal Webmaster
> NPC International, Inc.
>
>
>
> On Jun 22, 2010, at 3:48 PM, Okubo, Yasushi (TSD) wrote:
>
>> Hi
>>
>> I downloaded apache apache v2.2.15 and compiled and installed, but
the
>> result was the same.
>>
>> Session sso replication looked like failed. Upon shutting down the
>> node, it kicked me out of password protected area and needed to
> re-loin
>> on the second node.
>>
>> On apache, I installed/enabled all modules including basic
>> authentication etc. Is there any requirement on apache side or how
> the
>> virtual host should be set up in httpd.conf to make sso failover
work?
>>
>> Thanks,
>> yasushi
>>
>> -----Original Message-----
>> From: Pid [mailto:pid@pidster.com]
>> Sent: Tuesday, June 22, 2010 8:04 AM
>> To: Tomcat Users List
>> Subject: Re: question for sso session replication in tomcat 6.0.26
>>
>> On 22/06/2010 15:56, Okubo, Yasushi (TSD) wrote:
>>> Hi Andrew
>>>
>>> In case of no failover, SSO works for all web applications on the
> same
>> host. Upon failover [shutting down one node], a user is routed to
the
>> other node, and TC is asking for a user to re-login when he/she tried
> to
>> access password protected area.
>>>
>>> I have checked many times on server.xml and session replication is
>> working fine upon failover, so I cannot think any misconfiguration on
>> server.xml
>>> The issue is SSO failover is not working. I think it might be
> related
>> to my apache virtual host setup, but could not figure it out.
>>>
>>> Thanks for your help,
>>> yasushi
>>>
>>> I am using mod_proxy_ajp, mod_proxy_balancer [v2.2.3]
>>
>> mod_proxy_ajp appeared in 2.2.3 for the first time, it was functional
>> but not perfect & there are many bugfixes and improvements since
then,
>> you should upgrade HTTPD.
>>
>>
>> p
>>
>>> OS : Redhat Linux 64bit RHEL v5.5
>>> JDK : 1.6.0.20
>>>
>>> === I created virtual host on port 9050 ==
>>> Httpd.conf
>>>
>>> <VirtualHost 10.250.200.57:9050>
>>> ServerAdmin xyz
>>> ServerName webclust1.xyz.com
>>> ServerAlias webclust1
>>> ErrorLog logs/webclust_cluster_error.log
>>> CustomLog logs/webclust-cluster-access_log common
>>>
>>> <Location /balancer-manager>
>>> SetHandler balancer-manager
>>>
>>> Order Deny,Allow
>>> Deny from all
>>> Allow from all
>>> </Location>
>>>
>>> ProxyRequests off
>>> <Proxy balancer://webclust>
>>> BalancerMember ajp://10.250.200.57:9001 loadfactor=10 max=150
> smax=145
>> route=jvm1
>>> BalancerMember ajp://10.250.200.57:9002 loadfactor=10 max=150
> smax=145
>> route=jvm2
>>> BalancerMember ajp://10.250.200.57:9003 loadfactor=10 max=150
> smax=145
>> route=jvm3
>>> Order Deny,Allow
>>> Allow from all
>>> </Proxy>
>>>
>>> #Do not proxy balancer-manager
>>> ProxyPass /balancer-manager !
>>>
>>> <Location /examples>
>>> ProxyPass balancer://webclust/examples
>> stickysession=JSESSIONID|jsessionid
>>> ProxyPassReverse balancer://webclust/examples
>>> Order Deny,Allow
>>> Allow from all
>>> </Location>
>>>
>>> <Location / >
>>> ProxyPass balancer://webclust/ stickysession=JSESSIONID|jsessionid
>>> ProxyPassReverse balancer://webclust/
>>> Order Deny,Allow
>>> Allow from all
>>> </Location>
>>>
>>>
>>> === server.xml ===
>>> <!-- Define an AJP 1.3 Connector on port 8009 -->
>>> <Connector port="9002" protocol="AJP/1.3" redirectPort="8443" />
>>>
>>> <Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1">
>>>
>>> <Host name="localhost" appBase="webapps"
>>> unpackWARs="true" autoDeploy="true"
>>> xmlValidation="false" xmlNamespaceAware="false">
>>>
>>> <Cluster
>> className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
>>> channelSendOptions="4">
>>>
>>> <Manager
>> className="org.apache.catalina.ha.session.DeltaManager"
>>> name="node2"
>>> expireSessionsOnShutdown="false"
>>> notifyListenersOnReplication="true"/>
>>>
>>> <Channel
>> className="org.apache.catalina.tribes.group.GroupChannel">
>>> <Membership
>> className="org.apache.catalina.tribes.membership.McastService"
>>> address="228.0.0.5"
>>> port="45564"
>>> frequency="500"
>>> dropTime="3000"/>
>>> <Receiver
>> className="org.apache.catalina.tribes.transport.nio.NioReceiver"
>>> address="auto"
>>> port="4020"
>>> autoBind="100"
>>> selectorTimeout="5000"
>>> maxThreads="12"/>
>>> <Sender
>>
>
className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
>>> <Transport
>>
>
className="org.apache.catalina.tribes.transport.nio.PooledParallelSender
>> "/>
>>> </Sender>
>>> <Interceptor
>>
>
className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetec
>> tor"/>
>>> <Interceptor
>>
>
className="org.apache.catalina.tribes.group.interceptors.MessageDispatch
>> 15Interceptor"/>
>>> <Interceptor
>>
>
className="org.apache.catalina.tribes.group.interceptors.ThroughputInter
>> ceptor"/>
>>> </Channel>
>>>
>>> <Valve
>> className="org.apache.catalina.ha.tcp.ReplicationValve"
>>>
>>
>
filter=".*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;
>> .*\.xls;.*\.sdf;.*\.xml;"/>
>>> <!-- only with jk_mod failover-->
>>> <Valve
>> className="org.apache.catalina.ha.session.JvmRouteBinderValve"
>>> enabled="true" sessionIdAttribute="takeoverSessionid"
>> />
>>> <!--
>>> <Deployer
>> className="org.apache.catalina.ha.deploy.FarmWarDeployer"
>>> tempDir="/tmp/war-temp/"
>>>
>> deployDir="/usr/local/apache/node2-tomcat-6.0.26/webapps"
>>> watchDir="/tmp/war-listen/"
>>> watchEnabled="true"/>
>>> -->
>>> <!-- only with jk_mod and jvmroutebindervalve-->
>>> <ClusterListener
>>
>
className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListene
>> r"/>
>>> <ClusterListener
>> className="org.apache.catalina.ha.session.ClusterSessionListener"/>
>>> </Cluster>
>>>
>>> <Valve
>> className="org.apache.catalina.ha.authenticator.ClusterSingleSignOn"
> />
>>>
>>> <Valve className="org.apache.catalina.valves.AccessLogValve"
>> directory="logs"
>>> prefix="webappqa_node2_access_log." suffix=".log"
>> pattern="common" resolveHosts="false"/>
>>>
>>> </Host>
>>> </Engine>
>>>
>>>
>>> -----Original Message-----
>>> From: Andrew Bruno [mailto:andrew.bruno@gmail.com]
>>> Sent: Monday, June 21, 2010 10:09 PM
>>> To: Tomcat Users List
>>> Subject: Re: question for sso session replication in tomcat 6.0.26
>>>
>>> Oh sorry, I re-read your answer. Not sure why SSO is not working,
be
>>> interested to find out though..
>>>
>>> AB
>>>
>>> On Tue, Jun 22, 2010 at 3:04 PM, Andrew Bruno
> <an...@gmail.com>
>> wrote:
>>>> Hi Yasushi
>>>>
>>>> In your serverl.xml have you added the jvmroute to the Engine?
>>>>
>>>> i.e.
>>>>
>>>> <Engine name="Catalina" defaultHost="localhost" jvmRoute="1">
>>>>
>>>> Andrew
>>>>
>>>> On Tue, Jun 22, 2010 at 2:50 PM, Okubo, Yasushi (TSD)
>> <Ya...@takedasd.com> wrote:
>>>>> Hi Andrew
>>>>>
>>>>> Thank for your post. When I checked the session id from firefox,
>> sso session id [jsessionidsso] does not have jvmroute info, but only
>> jsessionid has jvmroute. So, session replication upon failover is
>> working fine, but singlesionon upon failover is not working on tomcat
>> 6.0.x (including 6.0.26).
>>>>>
>>>>> yasushi
>>>>>
>>>>> -----Original Message-----
>>>>> From: Andrew Bruno [mailto:andrew.bruno@gmail.com]
>>>>> Sent: Monday, June 21, 2010 9:18 PM
>>>>> To: Tomcat Users List
>>>>> Subject: Re: question for sso session replication in tomcat 6.0.26
>>>>>
>>>>> Looking at the code I think this is wrong
>>>>>
>>>>> if (!_ssoSessionId.contains("." + jvmRoute)) {
>>>>> _ssoSessionId += "." + jvmRoute;
>>>>> response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME,
>> _ssoSessionId));
>>>>> }
>>>>>
>>>>> The original sessionId will already have the
> "."+_any_other_jvmRoute
>>>>> included, so you need to substring it, and append the new
jvmRoute.
>>>>>
>>>>> _ssoSessionId= _ssoSessionId.substring(0,
>> _ssoSessionId.indexOf("."))
>>>>>
>>>>> and then add
>>>>>
>>>>> _ssoSessionId += "." + jvmRoute;
>>>>>
>>>>> AB
>>>>>
>>>>> On Tue, Jun 22, 2010 at 1:03 PM, Okubo, Yasushi (TSD)
>>>>> <Ya...@takedasd.com> wrote:
>>>>>> Hi experts
>>>>>>
>>>>>>
>>>>>>
>>>>>> I found this old email from archive in TC 5.5.23.
>>>>>>
>>>>>> Does this problem still exist in tomcat 6.0.x or 6.0.26?
>>>>>>
>>>>>>
>>>>>>
>>>>>> When failover occurs, sso session id is updated with new number
>> after
>>>>>> forcing a user to relogin to the application since sso session id
>> is not
>>>>>> replicated and rewritten correctly. Could someone explain what
is
>>>>>> expected in current tomcat 6.0.x cluster upon failover? Should
> sso
>>>>>> session id is replicated correctly in tomcat 6.0.x?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> yasushi
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ROOKIE wrote:
>>>>>> Hi,
>>>>>> I have a problem with tomcat cluster + mod_proxy load balancer :
>>>>>>
>>>>>> We have a main app which authenticate itself to a webapp and from
>> this
>>>>>> app one
>>>>>> can launch embedded apps which use the SSO cookie to access other
>>>>>> webapps on
>>>>>> the server (Single-Sign-On for the user).
>>>>>>
>>>>>> Things are working perfectly for the normal cookie but not for
the
>> sso
>>>>>> cookie.
>>>>>>
>>>>>>
>>>>>> The problem I have is that tomcat does not replicate SSO sessions
>> so
>>>>>> when these embedded apps route through the load balancer we get
>> 401s on
>>>>>> all the other cluster members except the one which actually
>> generated
>>>>>> the SSO cookie.
>>>>>>
>>>>>> I wanted to know if we can edit the SSO cookie generated by
tomcat
>> to
>>>>>> also
>>>>>> contain the jvmRoute parameter so that the load balancer directly
>> goes
>>>>>> to the
>>>>>> correct cluster member.
>>>>>>
>>>>>>
>>>>>> I tried doing this in my code by fetching the SSO cookie and
>> appending
>>>>>> to it
>>>>>> the jvmRoute as follows :
>>>>>>
>>>>>> HttpServletRequest request =
>>>>>>
(HttpServletRequest)Security.getContext(HttpServletRequest.class);
>>>>>> HttpServletResponse response =
>>>>>>
>> (HttpServletResponse)Security.getContext(HttpServletResponse.class);
>>>>>> if(request != null) {
>>>>>> String jvmRoute = "Vinod_Cluster_1"; // as mentioned
>> in
>>>>>> server.xml
>>>>>> Cookie[] cookies = request.getCookies();
>>>>>> for(int nc=0; cookies != null && nc < cookies.length;
>> nc++)
>>>>>> {
>>>>>>
>> if(_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
>>>>>> _sessionId = cookies[nc].getValue();
>>>>>> }
>>>>>>
>>>>>> else if(_SSO_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
>>>>>>
>>>>>> _ssoSessionId = cookies[nc].getValue();
>>>>>> if (!_ssoSessionId.contains("." + jvmRoute)) {
>>>>>> _ssoSessionId += "." + jvmRoute;
>>>>>>
>>>>>> response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME,
>> _ssoSessionId));
>>>>>> }
>>>>>>
>>>>>>
>>>>>> }
>>>>>>
>>>>>>
>>>>>> But after this I started getting 401s from even the correct
> cluster
>>>>>> member. My guess is addCookie doesnt update the cookie in
tomcat's
>> cache
>>>>>> which is reasonable.
>>>>>>
>>>>>> Other thought was to edit tomcat's sso cookie generation code to
>> append
>>>>>> the
>>>>>> jvmRoute to the sso cookie.
>>>>>>
>>>>>>
>>>>>> Is there an better way to achieve this in my code base ?
>>>>>>
>>>>>> Thanks In Advance,
>>>>>> Vinod
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>>
>>>
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: question for sso session replication in tomcat 6.0.26
Posted by "Okubo, Yasushi (TSD)" <Ya...@takedasd.com>.
Thanks Pid
It might be related to the fix for 45255. This is the only one I can see
remotely related. According to this fix, (I might be wrong), but it
looks like once the user is logged-out from the application or node upon
regular logout or node shutdown or some other reasons, a user is asked
to relogin by default to renew sso session id. Is there any way to stop
this behavior to add a flag or some kind in server.xml?
I tested with mod_jk [v1.2.30] and httpd [2.2.15], and the result is
consistent with mod_proxy_ajp and mod_balancer. SingleSignOn session
does not failover.
I will try to test older Tomcat 6.0.1x today.
Yasushi
-----Original Message-----
From: Pid [mailto:pid@pidster.com]
Sent: Wednesday, June 23, 2010 1:06 AM
To: Tomcat Users List
Subject: Re: question for sso session replication in tomcat 6.0.26
I'll have to look at the code, but maybe you're being affected by a
recent bug whereby the session id changes after login but isn't then
replicated.
You might search bugzilla to see if this applies to 6.0.26.
p
On 22 Jun 2010, at 22:41, "Okubo, Yasushi (TSD)"
<Ya...@takedasd.com> wrote:
>
> Hi
>
> There were two cookies created by Tomcat 6.0.26. One is for SSO, and
the
> other is for regular session between client and tomcat. JSESSIONID is
> working fine : it means session replication and failover, but not
> JSESSIONIDSSO. JSESSIONIDSSO is updated with new value upon relogin.
>
> yasushi
>
>
> JSESSIONIDSSO
> 65110434847FE0AA1F1EBF0EF0871D25
>
>
> JSESSIONID
> 5CFE92814875C4DEFC554526147698A3.jvm2
>
> -----Original Message-----
> From: Jon Brisbin [mailto:jon.brisbin@npcinternational.com]
> Sent: Tuesday, June 22, 2010 2:17 PM
> To: Tomcat Users List
> Cc: Okubo, Yasushi (TSD)
> Subject: Re: question for sso session replication in tomcat 6.0.26
>
> Are you using a "jvmRoute" setting on your BalancerMember definition
in
> mod_proxy config and on the <Engine/> element in server.xml? Your
cookie
> would have the jvmRoute property added to the end of it (e.g.
> ALONGMD5HASH.server1) if so.
>
> From the Almighty Google:
> http://community.jboss.org/wiki/usingmodproxywithjboss
>
> Jon Brisbin
> Portal Webmaster
> NPC International, Inc.
>
>
>
> On Jun 22, 2010, at 3:48 PM, Okubo, Yasushi (TSD) wrote:
>
>> Hi
>>
>> I downloaded apache apache v2.2.15 and compiled and installed, but
the
>> result was the same.
>>
>> Session sso replication looked like failed. Upon shutting down the
>> node, it kicked me out of password protected area and needed to
> re-loin
>> on the second node.
>>
>> On apache, I installed/enabled all modules including basic
>> authentication etc. Is there any requirement on apache side or how
> the
>> virtual host should be set up in httpd.conf to make sso failover
work?
>>
>> Thanks,
>> yasushi
>>
>> -----Original Message-----
>> From: Pid [mailto:pid@pidster.com]
>> Sent: Tuesday, June 22, 2010 8:04 AM
>> To: Tomcat Users List
>> Subject: Re: question for sso session replication in tomcat 6.0.26
>>
>> On 22/06/2010 15:56, Okubo, Yasushi (TSD) wrote:
>>> Hi Andrew
>>>
>>> In case of no failover, SSO works for all web applications on the
> same
>> host. Upon failover [shutting down one node], a user is routed to
the
>> other node, and TC is asking for a user to re-login when he/she tried
> to
>> access password protected area.
>>>
>>> I have checked many times on server.xml and session replication is
>> working fine upon failover, so I cannot think any misconfiguration on
>> server.xml
>>> The issue is SSO failover is not working. I think it might be
> related
>> to my apache virtual host setup, but could not figure it out.
>>>
>>> Thanks for your help,
>>> yasushi
>>>
>>> I am using mod_proxy_ajp, mod_proxy_balancer [v2.2.3]
>>
>> mod_proxy_ajp appeared in 2.2.3 for the first time, it was functional
>> but not perfect & there are many bugfixes and improvements since
then,
>> you should upgrade HTTPD.
>>
>>
>> p
>>
>>> OS : Redhat Linux 64bit RHEL v5.5
>>> JDK : 1.6.0.20
>>>
>>> === I created virtual host on port 9050 ==
>>> Httpd.conf
>>>
>>> <VirtualHost 10.250.200.57:9050>
>>> ServerAdmin xyz
>>> ServerName webclust1.xyz.com
>>> ServerAlias webclust1
>>> ErrorLog logs/webclust_cluster_error.log
>>> CustomLog logs/webclust-cluster-access_log common
>>>
>>> <Location /balancer-manager>
>>> SetHandler balancer-manager
>>>
>>> Order Deny,Allow
>>> Deny from all
>>> Allow from all
>>> </Location>
>>>
>>> ProxyRequests off
>>> <Proxy balancer://webclust>
>>> BalancerMember ajp://10.250.200.57:9001 loadfactor=10 max=150
> smax=145
>> route=jvm1
>>> BalancerMember ajp://10.250.200.57:9002 loadfactor=10 max=150
> smax=145
>> route=jvm2
>>> BalancerMember ajp://10.250.200.57:9003 loadfactor=10 max=150
> smax=145
>> route=jvm3
>>> Order Deny,Allow
>>> Allow from all
>>> </Proxy>
>>>
>>> #Do not proxy balancer-manager
>>> ProxyPass /balancer-manager !
>>>
>>> <Location /examples>
>>> ProxyPass balancer://webclust/examples
>> stickysession=JSESSIONID|jsessionid
>>> ProxyPassReverse balancer://webclust/examples
>>> Order Deny,Allow
>>> Allow from all
>>> </Location>
>>>
>>> <Location / >
>>> ProxyPass balancer://webclust/ stickysession=JSESSIONID|jsessionid
>>> ProxyPassReverse balancer://webclust/
>>> Order Deny,Allow
>>> Allow from all
>>> </Location>
>>>
>>>
>>> === server.xml ===
>>> <!-- Define an AJP 1.3 Connector on port 8009 -->
>>> <Connector port="9002" protocol="AJP/1.3" redirectPort="8443" />
>>>
>>> <Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1">
>>>
>>> <Host name="localhost" appBase="webapps"
>>> unpackWARs="true" autoDeploy="true"
>>> xmlValidation="false" xmlNamespaceAware="false">
>>>
>>> <Cluster
>> className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
>>> channelSendOptions="4">
>>>
>>> <Manager
>> className="org.apache.catalina.ha.session.DeltaManager"
>>> name="node2"
>>> expireSessionsOnShutdown="false"
>>> notifyListenersOnReplication="true"/>
>>>
>>> <Channel
>> className="org.apache.catalina.tribes.group.GroupChannel">
>>> <Membership
>> className="org.apache.catalina.tribes.membership.McastService"
>>> address="228.0.0.5"
>>> port="45564"
>>> frequency="500"
>>> dropTime="3000"/>
>>> <Receiver
>> className="org.apache.catalina.tribes.transport.nio.NioReceiver"
>>> address="auto"
>>> port="4020"
>>> autoBind="100"
>>> selectorTimeout="5000"
>>> maxThreads="12"/>
>>> <Sender
>>
>
className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
>>> <Transport
>>
>
className="org.apache.catalina.tribes.transport.nio.PooledParallelSender
>> "/>
>>> </Sender>
>>> <Interceptor
>>
>
className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetec
>> tor"/>
>>> <Interceptor
>>
>
className="org.apache.catalina.tribes.group.interceptors.MessageDispatch
>> 15Interceptor"/>
>>> <Interceptor
>>
>
className="org.apache.catalina.tribes.group.interceptors.ThroughputInter
>> ceptor"/>
>>> </Channel>
>>>
>>> <Valve
>> className="org.apache.catalina.ha.tcp.ReplicationValve"
>>>
>>
>
filter=".*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;
>> .*\.xls;.*\.sdf;.*\.xml;"/>
>>> <!-- only with jk_mod failover-->
>>> <Valve
>> className="org.apache.catalina.ha.session.JvmRouteBinderValve"
>>> enabled="true" sessionIdAttribute="takeoverSessionid"
>> />
>>> <!--
>>> <Deployer
>> className="org.apache.catalina.ha.deploy.FarmWarDeployer"
>>> tempDir="/tmp/war-temp/"
>>>
>> deployDir="/usr/local/apache/node2-tomcat-6.0.26/webapps"
>>> watchDir="/tmp/war-listen/"
>>> watchEnabled="true"/>
>>> -->
>>> <!-- only with jk_mod and jvmroutebindervalve-->
>>> <ClusterListener
>>
>
className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListene
>> r"/>
>>> <ClusterListener
>> className="org.apache.catalina.ha.session.ClusterSessionListener"/>
>>> </Cluster>
>>>
>>> <Valve
>> className="org.apache.catalina.ha.authenticator.ClusterSingleSignOn"
> />
>>>
>>> <Valve className="org.apache.catalina.valves.AccessLogValve"
>> directory="logs"
>>> prefix="webappqa_node2_access_log." suffix=".log"
>> pattern="common" resolveHosts="false"/>
>>>
>>> </Host>
>>> </Engine>
>>>
>>>
>>> -----Original Message-----
>>> From: Andrew Bruno [mailto:andrew.bruno@gmail.com]
>>> Sent: Monday, June 21, 2010 10:09 PM
>>> To: Tomcat Users List
>>> Subject: Re: question for sso session replication in tomcat 6.0.26
>>>
>>> Oh sorry, I re-read your answer. Not sure why SSO is not working,
be
>>> interested to find out though..
>>>
>>> AB
>>>
>>> On Tue, Jun 22, 2010 at 3:04 PM, Andrew Bruno
> <an...@gmail.com>
>> wrote:
>>>> Hi Yasushi
>>>>
>>>> In your serverl.xml have you added the jvmroute to the Engine?
>>>>
>>>> i.e.
>>>>
>>>> <Engine name="Catalina" defaultHost="localhost" jvmRoute="1">
>>>>
>>>> Andrew
>>>>
>>>> On Tue, Jun 22, 2010 at 2:50 PM, Okubo, Yasushi (TSD)
>> <Ya...@takedasd.com> wrote:
>>>>> Hi Andrew
>>>>>
>>>>> Thank for your post. When I checked the session id from firefox,
>> sso session id [jsessionidsso] does not have jvmroute info, but only
>> jsessionid has jvmroute. So, session replication upon failover is
>> working fine, but singlesionon upon failover is not working on tomcat
>> 6.0.x (including 6.0.26).
>>>>>
>>>>> yasushi
>>>>>
>>>>> -----Original Message-----
>>>>> From: Andrew Bruno [mailto:andrew.bruno@gmail.com]
>>>>> Sent: Monday, June 21, 2010 9:18 PM
>>>>> To: Tomcat Users List
>>>>> Subject: Re: question for sso session replication in tomcat 6.0.26
>>>>>
>>>>> Looking at the code I think this is wrong
>>>>>
>>>>> if (!_ssoSessionId.contains("." + jvmRoute)) {
>>>>> _ssoSessionId += "." + jvmRoute;
>>>>> response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME,
>> _ssoSessionId));
>>>>> }
>>>>>
>>>>> The original sessionId will already have the
> "."+_any_other_jvmRoute
>>>>> included, so you need to substring it, and append the new
jvmRoute.
>>>>>
>>>>> _ssoSessionId= _ssoSessionId.substring(0,
>> _ssoSessionId.indexOf("."))
>>>>>
>>>>> and then add
>>>>>
>>>>> _ssoSessionId += "." + jvmRoute;
>>>>>
>>>>> AB
>>>>>
>>>>> On Tue, Jun 22, 2010 at 1:03 PM, Okubo, Yasushi (TSD)
>>>>> <Ya...@takedasd.com> wrote:
>>>>>> Hi experts
>>>>>>
>>>>>>
>>>>>>
>>>>>> I found this old email from archive in TC 5.5.23.
>>>>>>
>>>>>> Does this problem still exist in tomcat 6.0.x or 6.0.26?
>>>>>>
>>>>>>
>>>>>>
>>>>>> When failover occurs, sso session id is updated with new number
>> after
>>>>>> forcing a user to relogin to the application since sso session id
>> is not
>>>>>> replicated and rewritten correctly. Could someone explain what
is
>>>>>> expected in current tomcat 6.0.x cluster upon failover? Should
> sso
>>>>>> session id is replicated correctly in tomcat 6.0.x?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> yasushi
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ROOKIE wrote:
>>>>>> Hi,
>>>>>> I have a problem with tomcat cluster + mod_proxy load balancer :
>>>>>>
>>>>>> We have a main app which authenticate itself to a webapp and from
>> this
>>>>>> app one
>>>>>> can launch embedded apps which use the SSO cookie to access other
>>>>>> webapps on
>>>>>> the server (Single-Sign-On for the user).
>>>>>>
>>>>>> Things are working perfectly for the normal cookie but not for
the
>> sso
>>>>>> cookie.
>>>>>>
>>>>>>
>>>>>> The problem I have is that tomcat does not replicate SSO sessions
>> so
>>>>>> when these embedded apps route through the load balancer we get
>> 401s on
>>>>>> all the other cluster members except the one which actually
>> generated
>>>>>> the SSO cookie.
>>>>>>
>>>>>> I wanted to know if we can edit the SSO cookie generated by
tomcat
>> to
>>>>>> also
>>>>>> contain the jvmRoute parameter so that the load balancer directly
>> goes
>>>>>> to the
>>>>>> correct cluster member.
>>>>>>
>>>>>>
>>>>>> I tried doing this in my code by fetching the SSO cookie and
>> appending
>>>>>> to it
>>>>>> the jvmRoute as follows :
>>>>>>
>>>>>> HttpServletRequest request =
>>>>>>
(HttpServletRequest)Security.getContext(HttpServletRequest.class);
>>>>>> HttpServletResponse response =
>>>>>>
>> (HttpServletResponse)Security.getContext(HttpServletResponse.class);
>>>>>> if(request != null) {
>>>>>> String jvmRoute = "Vinod_Cluster_1"; // as mentioned
>> in
>>>>>> server.xml
>>>>>> Cookie[] cookies = request.getCookies();
>>>>>> for(int nc=0; cookies != null && nc < cookies.length;
>> nc++)
>>>>>> {
>>>>>>
>> if(_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
>>>>>> _sessionId = cookies[nc].getValue();
>>>>>> }
>>>>>>
>>>>>> else if(_SSO_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
>>>>>>
>>>>>> _ssoSessionId = cookies[nc].getValue();
>>>>>> if (!_ssoSessionId.contains("." + jvmRoute)) {
>>>>>> _ssoSessionId += "." + jvmRoute;
>>>>>>
>>>>>> response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME,
>> _ssoSessionId));
>>>>>> }
>>>>>>
>>>>>>
>>>>>> }
>>>>>>
>>>>>>
>>>>>> But after this I started getting 401s from even the correct
> cluster
>>>>>> member. My guess is addCookie doesnt update the cookie in
tomcat's
>> cache
>>>>>> which is reasonable.
>>>>>>
>>>>>> Other thought was to edit tomcat's sso cookie generation code to
>> append
>>>>>> the
>>>>>> jvmRoute to the sso cookie.
>>>>>>
>>>>>>
>>>>>> Is there an better way to achieve this in my code base ?
>>>>>>
>>>>>> Thanks In Advance,
>>>>>> Vinod
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>>
>>>
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: question for sso session replication in tomcat 6.0.26
Posted by Pid <pi...@pidster.com>.
I'll have to look at the code, but maybe you're being affected by a recent bug whereby the session id changes after login but isn't then replicated.
You might search bugzilla to see if this applies to 6.0.26.
p
On 22 Jun 2010, at 22:41, "Okubo, Yasushi (TSD)" <Ya...@takedasd.com> wrote:
>
> Hi
>
> There were two cookies created by Tomcat 6.0.26. One is for SSO, and the
> other is for regular session between client and tomcat. JSESSIONID is
> working fine : it means session replication and failover, but not
> JSESSIONIDSSO. JSESSIONIDSSO is updated with new value upon relogin.
>
> yasushi
>
>
> JSESSIONIDSSO
> 65110434847FE0AA1F1EBF0EF0871D25
>
>
> JSESSIONID
> 5CFE92814875C4DEFC554526147698A3.jvm2
>
> -----Original Message-----
> From: Jon Brisbin [mailto:jon.brisbin@npcinternational.com]
> Sent: Tuesday, June 22, 2010 2:17 PM
> To: Tomcat Users List
> Cc: Okubo, Yasushi (TSD)
> Subject: Re: question for sso session replication in tomcat 6.0.26
>
> Are you using a "jvmRoute" setting on your BalancerMember definition in
> mod_proxy config and on the <Engine/> element in server.xml? Your cookie
> would have the jvmRoute property added to the end of it (e.g.
> ALONGMD5HASH.server1) if so.
>
> From the Almighty Google:
> http://community.jboss.org/wiki/usingmodproxywithjboss
>
> Jon Brisbin
> Portal Webmaster
> NPC International, Inc.
>
>
>
> On Jun 22, 2010, at 3:48 PM, Okubo, Yasushi (TSD) wrote:
>
>> Hi
>>
>> I downloaded apache apache v2.2.15 and compiled and installed, but the
>> result was the same.
>>
>> Session sso replication looked like failed. Upon shutting down the
>> node, it kicked me out of password protected area and needed to
> re-loin
>> on the second node.
>>
>> On apache, I installed/enabled all modules including basic
>> authentication etc. Is there any requirement on apache side or how
> the
>> virtual host should be set up in httpd.conf to make sso failover work?
>>
>> Thanks,
>> yasushi
>>
>> -----Original Message-----
>> From: Pid [mailto:pid@pidster.com]
>> Sent: Tuesday, June 22, 2010 8:04 AM
>> To: Tomcat Users List
>> Subject: Re: question for sso session replication in tomcat 6.0.26
>>
>> On 22/06/2010 15:56, Okubo, Yasushi (TSD) wrote:
>>> Hi Andrew
>>>
>>> In case of no failover, SSO works for all web applications on the
> same
>> host. Upon failover [shutting down one node], a user is routed to the
>> other node, and TC is asking for a user to re-login when he/she tried
> to
>> access password protected area.
>>>
>>> I have checked many times on server.xml and session replication is
>> working fine upon failover, so I cannot think any misconfiguration on
>> server.xml
>>> The issue is SSO failover is not working. I think it might be
> related
>> to my apache virtual host setup, but could not figure it out.
>>>
>>> Thanks for your help,
>>> yasushi
>>>
>>> I am using mod_proxy_ajp, mod_proxy_balancer [v2.2.3]
>>
>> mod_proxy_ajp appeared in 2.2.3 for the first time, it was functional
>> but not perfect & there are many bugfixes and improvements since then,
>> you should upgrade HTTPD.
>>
>>
>> p
>>
>>> OS : Redhat Linux 64bit RHEL v5.5
>>> JDK : 1.6.0.20
>>>
>>> === I created virtual host on port 9050 ==
>>> Httpd.conf
>>>
>>> <VirtualHost 10.250.200.57:9050>
>>> ServerAdmin xyz
>>> ServerName webclust1.xyz.com
>>> ServerAlias webclust1
>>> ErrorLog logs/webclust_cluster_error.log
>>> CustomLog logs/webclust-cluster-access_log common
>>>
>>> <Location /balancer-manager>
>>> SetHandler balancer-manager
>>>
>>> Order Deny,Allow
>>> Deny from all
>>> Allow from all
>>> </Location>
>>>
>>> ProxyRequests off
>>> <Proxy balancer://webclust>
>>> BalancerMember ajp://10.250.200.57:9001 loadfactor=10 max=150
> smax=145
>> route=jvm1
>>> BalancerMember ajp://10.250.200.57:9002 loadfactor=10 max=150
> smax=145
>> route=jvm2
>>> BalancerMember ajp://10.250.200.57:9003 loadfactor=10 max=150
> smax=145
>> route=jvm3
>>> Order Deny,Allow
>>> Allow from all
>>> </Proxy>
>>>
>>> #Do not proxy balancer-manager
>>> ProxyPass /balancer-manager !
>>>
>>> <Location /examples>
>>> ProxyPass balancer://webclust/examples
>> stickysession=JSESSIONID|jsessionid
>>> ProxyPassReverse balancer://webclust/examples
>>> Order Deny,Allow
>>> Allow from all
>>> </Location>
>>>
>>> <Location / >
>>> ProxyPass balancer://webclust/ stickysession=JSESSIONID|jsessionid
>>> ProxyPassReverse balancer://webclust/
>>> Order Deny,Allow
>>> Allow from all
>>> </Location>
>>>
>>>
>>> === server.xml ===
>>> <!-- Define an AJP 1.3 Connector on port 8009 -->
>>> <Connector port="9002" protocol="AJP/1.3" redirectPort="8443" />
>>>
>>> <Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1">
>>>
>>> <Host name="localhost" appBase="webapps"
>>> unpackWARs="true" autoDeploy="true"
>>> xmlValidation="false" xmlNamespaceAware="false">
>>>
>>> <Cluster
>> className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
>>> channelSendOptions="4">
>>>
>>> <Manager
>> className="org.apache.catalina.ha.session.DeltaManager"
>>> name="node2"
>>> expireSessionsOnShutdown="false"
>>> notifyListenersOnReplication="true"/>
>>>
>>> <Channel
>> className="org.apache.catalina.tribes.group.GroupChannel">
>>> <Membership
>> className="org.apache.catalina.tribes.membership.McastService"
>>> address="228.0.0.5"
>>> port="45564"
>>> frequency="500"
>>> dropTime="3000"/>
>>> <Receiver
>> className="org.apache.catalina.tribes.transport.nio.NioReceiver"
>>> address="auto"
>>> port="4020"
>>> autoBind="100"
>>> selectorTimeout="5000"
>>> maxThreads="12"/>
>>> <Sender
>>
> className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
>>> <Transport
>>
> className="org.apache.catalina.tribes.transport.nio.PooledParallelSender
>> "/>
>>> </Sender>
>>> <Interceptor
>>
> className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetec
>> tor"/>
>>> <Interceptor
>>
> className="org.apache.catalina.tribes.group.interceptors.MessageDispatch
>> 15Interceptor"/>
>>> <Interceptor
>>
> className="org.apache.catalina.tribes.group.interceptors.ThroughputInter
>> ceptor"/>
>>> </Channel>
>>>
>>> <Valve
>> className="org.apache.catalina.ha.tcp.ReplicationValve"
>>>
>>
> filter=".*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;
>> .*\.xls;.*\.sdf;.*\.xml;"/>
>>> <!-- only with jk_mod failover-->
>>> <Valve
>> className="org.apache.catalina.ha.session.JvmRouteBinderValve"
>>> enabled="true" sessionIdAttribute="takeoverSessionid"
>> />
>>> <!--
>>> <Deployer
>> className="org.apache.catalina.ha.deploy.FarmWarDeployer"
>>> tempDir="/tmp/war-temp/"
>>>
>> deployDir="/usr/local/apache/node2-tomcat-6.0.26/webapps"
>>> watchDir="/tmp/war-listen/"
>>> watchEnabled="true"/>
>>> -->
>>> <!-- only with jk_mod and jvmroutebindervalve-->
>>> <ClusterListener
>>
> className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListene
>> r"/>
>>> <ClusterListener
>> className="org.apache.catalina.ha.session.ClusterSessionListener"/>
>>> </Cluster>
>>>
>>> <Valve
>> className="org.apache.catalina.ha.authenticator.ClusterSingleSignOn"
> />
>>>
>>> <Valve className="org.apache.catalina.valves.AccessLogValve"
>> directory="logs"
>>> prefix="webappqa_node2_access_log." suffix=".log"
>> pattern="common" resolveHosts="false"/>
>>>
>>> </Host>
>>> </Engine>
>>>
>>>
>>> -----Original Message-----
>>> From: Andrew Bruno [mailto:andrew.bruno@gmail.com]
>>> Sent: Monday, June 21, 2010 10:09 PM
>>> To: Tomcat Users List
>>> Subject: Re: question for sso session replication in tomcat 6.0.26
>>>
>>> Oh sorry, I re-read your answer. Not sure why SSO is not working, be
>>> interested to find out though..
>>>
>>> AB
>>>
>>> On Tue, Jun 22, 2010 at 3:04 PM, Andrew Bruno
> <an...@gmail.com>
>> wrote:
>>>> Hi Yasushi
>>>>
>>>> In your serverl.xml have you added the jvmroute to the Engine?
>>>>
>>>> i.e.
>>>>
>>>> <Engine name="Catalina" defaultHost="localhost" jvmRoute="1">
>>>>
>>>> Andrew
>>>>
>>>> On Tue, Jun 22, 2010 at 2:50 PM, Okubo, Yasushi (TSD)
>> <Ya...@takedasd.com> wrote:
>>>>> Hi Andrew
>>>>>
>>>>> Thank for your post. When I checked the session id from firefox,
>> sso session id [jsessionidsso] does not have jvmroute info, but only
>> jsessionid has jvmroute. So, session replication upon failover is
>> working fine, but singlesionon upon failover is not working on tomcat
>> 6.0.x (including 6.0.26).
>>>>>
>>>>> yasushi
>>>>>
>>>>> -----Original Message-----
>>>>> From: Andrew Bruno [mailto:andrew.bruno@gmail.com]
>>>>> Sent: Monday, June 21, 2010 9:18 PM
>>>>> To: Tomcat Users List
>>>>> Subject: Re: question for sso session replication in tomcat 6.0.26
>>>>>
>>>>> Looking at the code I think this is wrong
>>>>>
>>>>> if (!_ssoSessionId.contains("." + jvmRoute)) {
>>>>> _ssoSessionId += "." + jvmRoute;
>>>>> response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME,
>> _ssoSessionId));
>>>>> }
>>>>>
>>>>> The original sessionId will already have the
> "."+_any_other_jvmRoute
>>>>> included, so you need to substring it, and append the new jvmRoute.
>>>>>
>>>>> _ssoSessionId= _ssoSessionId.substring(0,
>> _ssoSessionId.indexOf("."))
>>>>>
>>>>> and then add
>>>>>
>>>>> _ssoSessionId += "." + jvmRoute;
>>>>>
>>>>> AB
>>>>>
>>>>> On Tue, Jun 22, 2010 at 1:03 PM, Okubo, Yasushi (TSD)
>>>>> <Ya...@takedasd.com> wrote:
>>>>>> Hi experts
>>>>>>
>>>>>>
>>>>>>
>>>>>> I found this old email from archive in TC 5.5.23.
>>>>>>
>>>>>> Does this problem still exist in tomcat 6.0.x or 6.0.26?
>>>>>>
>>>>>>
>>>>>>
>>>>>> When failover occurs, sso session id is updated with new number
>> after
>>>>>> forcing a user to relogin to the application since sso session id
>> is not
>>>>>> replicated and rewritten correctly. Could someone explain what is
>>>>>> expected in current tomcat 6.0.x cluster upon failover? Should
> sso
>>>>>> session id is replicated correctly in tomcat 6.0.x?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> yasushi
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ROOKIE wrote:
>>>>>> Hi,
>>>>>> I have a problem with tomcat cluster + mod_proxy load balancer :
>>>>>>
>>>>>> We have a main app which authenticate itself to a webapp and from
>> this
>>>>>> app one
>>>>>> can launch embedded apps which use the SSO cookie to access other
>>>>>> webapps on
>>>>>> the server (Single-Sign-On for the user).
>>>>>>
>>>>>> Things are working perfectly for the normal cookie but not for the
>> sso
>>>>>> cookie.
>>>>>>
>>>>>>
>>>>>> The problem I have is that tomcat does not replicate SSO sessions
>> so
>>>>>> when these embedded apps route through the load balancer we get
>> 401s on
>>>>>> all the other cluster members except the one which actually
>> generated
>>>>>> the SSO cookie.
>>>>>>
>>>>>> I wanted to know if we can edit the SSO cookie generated by tomcat
>> to
>>>>>> also
>>>>>> contain the jvmRoute parameter so that the load balancer directly
>> goes
>>>>>> to the
>>>>>> correct cluster member.
>>>>>>
>>>>>>
>>>>>> I tried doing this in my code by fetching the SSO cookie and
>> appending
>>>>>> to it
>>>>>> the jvmRoute as follows :
>>>>>>
>>>>>> HttpServletRequest request =
>>>>>> (HttpServletRequest)Security.getContext(HttpServletRequest.class);
>>>>>> HttpServletResponse response =
>>>>>>
>> (HttpServletResponse)Security.getContext(HttpServletResponse.class);
>>>>>> if(request != null) {
>>>>>> String jvmRoute = "Vinod_Cluster_1"; // as mentioned
>> in
>>>>>> server.xml
>>>>>> Cookie[] cookies = request.getCookies();
>>>>>> for(int nc=0; cookies != null && nc < cookies.length;
>> nc++)
>>>>>> {
>>>>>>
>> if(_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
>>>>>> _sessionId = cookies[nc].getValue();
>>>>>> }
>>>>>>
>>>>>> else if(_SSO_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
>>>>>>
>>>>>> _ssoSessionId = cookies[nc].getValue();
>>>>>> if (!_ssoSessionId.contains("." + jvmRoute)) {
>>>>>> _ssoSessionId += "." + jvmRoute;
>>>>>>
>>>>>> response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME,
>> _ssoSessionId));
>>>>>> }
>>>>>>
>>>>>>
>>>>>> }
>>>>>>
>>>>>>
>>>>>> But after this I started getting 401s from even the correct
> cluster
>>>>>> member. My guess is addCookie doesnt update the cookie in tomcat's
>> cache
>>>>>> which is reasonable.
>>>>>>
>>>>>> Other thought was to edit tomcat's sso cookie generation code to
>> append
>>>>>> the
>>>>>> jvmRoute to the sso cookie.
>>>>>>
>>>>>>
>>>>>> Is there an better way to achieve this in my code base ?
>>>>>>
>>>>>> Thanks In Advance,
>>>>>> Vinod
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: question for sso session replication in tomcat 6.0.26
Posted by "Okubo, Yasushi (TSD)" <Ya...@takedasd.com>.
Hi
There were two cookies created by Tomcat 6.0.26. One is for SSO, and the
other is for regular session between client and tomcat. JSESSIONID is
working fine : it means session replication and failover, but not
JSESSIONIDSSO. JSESSIONIDSSO is updated with new value upon relogin.
yasushi
JSESSIONIDSSO
65110434847FE0AA1F1EBF0EF0871D25
JSESSIONID
5CFE92814875C4DEFC554526147698A3.jvm2
-----Original Message-----
From: Jon Brisbin [mailto:jon.brisbin@npcinternational.com]
Sent: Tuesday, June 22, 2010 2:17 PM
To: Tomcat Users List
Cc: Okubo, Yasushi (TSD)
Subject: Re: question for sso session replication in tomcat 6.0.26
Are you using a "jvmRoute" setting on your BalancerMember definition in
mod_proxy config and on the <Engine/> element in server.xml? Your cookie
would have the jvmRoute property added to the end of it (e.g.
ALONGMD5HASH.server1) if so.
>From the Almighty Google:
http://community.jboss.org/wiki/usingmodproxywithjboss
Jon Brisbin
Portal Webmaster
NPC International, Inc.
On Jun 22, 2010, at 3:48 PM, Okubo, Yasushi (TSD) wrote:
> Hi
>
> I downloaded apache apache v2.2.15 and compiled and installed, but the
> result was the same.
>
> Session sso replication looked like failed. Upon shutting down the
> node, it kicked me out of password protected area and needed to
re-loin
> on the second node.
>
> On apache, I installed/enabled all modules including basic
> authentication etc. Is there any requirement on apache side or how
the
> virtual host should be set up in httpd.conf to make sso failover work?
>
> Thanks,
> yasushi
>
> -----Original Message-----
> From: Pid [mailto:pid@pidster.com]
> Sent: Tuesday, June 22, 2010 8:04 AM
> To: Tomcat Users List
> Subject: Re: question for sso session replication in tomcat 6.0.26
>
> On 22/06/2010 15:56, Okubo, Yasushi (TSD) wrote:
>> Hi Andrew
>>
>> In case of no failover, SSO works for all web applications on the
same
> host. Upon failover [shutting down one node], a user is routed to the
> other node, and TC is asking for a user to re-login when he/she tried
to
> access password protected area.
>>
>> I have checked many times on server.xml and session replication is
> working fine upon failover, so I cannot think any misconfiguration on
> server.xml
>> The issue is SSO failover is not working. I think it might be
related
> to my apache virtual host setup, but could not figure it out.
>>
>> Thanks for your help,
>> yasushi
>>
>> I am using mod_proxy_ajp, mod_proxy_balancer [v2.2.3]
>
> mod_proxy_ajp appeared in 2.2.3 for the first time, it was functional
> but not perfect & there are many bugfixes and improvements since then,
> you should upgrade HTTPD.
>
>
> p
>
>> OS : Redhat Linux 64bit RHEL v5.5
>> JDK : 1.6.0.20
>>
>> === I created virtual host on port 9050 ==
>> Httpd.conf
>>
>> <VirtualHost 10.250.200.57:9050>
>> ServerAdmin xyz
>> ServerName webclust1.xyz.com
>> ServerAlias webclust1
>> ErrorLog logs/webclust_cluster_error.log
>> CustomLog logs/webclust-cluster-access_log common
>>
>> <Location /balancer-manager>
>> SetHandler balancer-manager
>>
>> Order Deny,Allow
>> Deny from all
>> Allow from all
>> </Location>
>>
>> ProxyRequests off
>> <Proxy balancer://webclust>
>> BalancerMember ajp://10.250.200.57:9001 loadfactor=10 max=150
smax=145
> route=jvm1
>> BalancerMember ajp://10.250.200.57:9002 loadfactor=10 max=150
smax=145
> route=jvm2
>> BalancerMember ajp://10.250.200.57:9003 loadfactor=10 max=150
smax=145
> route=jvm3
>> Order Deny,Allow
>> Allow from all
>> </Proxy>
>>
>> #Do not proxy balancer-manager
>> ProxyPass /balancer-manager !
>>
>> <Location /examples>
>> ProxyPass balancer://webclust/examples
> stickysession=JSESSIONID|jsessionid
>> ProxyPassReverse balancer://webclust/examples
>> Order Deny,Allow
>> Allow from all
>> </Location>
>>
>> <Location / >
>> ProxyPass balancer://webclust/ stickysession=JSESSIONID|jsessionid
>> ProxyPassReverse balancer://webclust/
>> Order Deny,Allow
>> Allow from all
>> </Location>
>>
>>
>> === server.xml ===
>> <!-- Define an AJP 1.3 Connector on port 8009 -->
>> <Connector port="9002" protocol="AJP/1.3" redirectPort="8443" />
>>
>> <Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1">
>>
>> <Host name="localhost" appBase="webapps"
>> unpackWARs="true" autoDeploy="true"
>> xmlValidation="false" xmlNamespaceAware="false">
>>
>> <Cluster
> className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
>> channelSendOptions="4">
>>
>> <Manager
> className="org.apache.catalina.ha.session.DeltaManager"
>> name="node2"
>> expireSessionsOnShutdown="false"
>> notifyListenersOnReplication="true"/>
>>
>> <Channel
> className="org.apache.catalina.tribes.group.GroupChannel">
>> <Membership
> className="org.apache.catalina.tribes.membership.McastService"
>> address="228.0.0.5"
>> port="45564"
>> frequency="500"
>> dropTime="3000"/>
>> <Receiver
> className="org.apache.catalina.tribes.transport.nio.NioReceiver"
>> address="auto"
>> port="4020"
>> autoBind="100"
>> selectorTimeout="5000"
>> maxThreads="12"/>
>> <Sender
>
className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
>> <Transport
>
className="org.apache.catalina.tribes.transport.nio.PooledParallelSender
> "/>
>> </Sender>
>> <Interceptor
>
className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetec
> tor"/>
>> <Interceptor
>
className="org.apache.catalina.tribes.group.interceptors.MessageDispatch
> 15Interceptor"/>
>> <Interceptor
>
className="org.apache.catalina.tribes.group.interceptors.ThroughputInter
> ceptor"/>
>> </Channel>
>>
>> <Valve
> className="org.apache.catalina.ha.tcp.ReplicationValve"
>>
>
filter=".*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;
> .*\.xls;.*\.sdf;.*\.xml;"/>
>> <!-- only with jk_mod failover-->
>> <Valve
> className="org.apache.catalina.ha.session.JvmRouteBinderValve"
>> enabled="true" sessionIdAttribute="takeoverSessionid"
> />
>> <!--
>> <Deployer
> className="org.apache.catalina.ha.deploy.FarmWarDeployer"
>> tempDir="/tmp/war-temp/"
>>
> deployDir="/usr/local/apache/node2-tomcat-6.0.26/webapps"
>> watchDir="/tmp/war-listen/"
>> watchEnabled="true"/>
>> -->
>> <!-- only with jk_mod and jvmroutebindervalve-->
>> <ClusterListener
>
className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListene
> r"/>
>> <ClusterListener
> className="org.apache.catalina.ha.session.ClusterSessionListener"/>
>> </Cluster>
>>
>> <Valve
> className="org.apache.catalina.ha.authenticator.ClusterSingleSignOn"
/>
>>
>> <Valve className="org.apache.catalina.valves.AccessLogValve"
> directory="logs"
>> prefix="webappqa_node2_access_log." suffix=".log"
> pattern="common" resolveHosts="false"/>
>>
>> </Host>
>> </Engine>
>>
>>
>> -----Original Message-----
>> From: Andrew Bruno [mailto:andrew.bruno@gmail.com]
>> Sent: Monday, June 21, 2010 10:09 PM
>> To: Tomcat Users List
>> Subject: Re: question for sso session replication in tomcat 6.0.26
>>
>> Oh sorry, I re-read your answer. Not sure why SSO is not working, be
>> interested to find out though..
>>
>> AB
>>
>> On Tue, Jun 22, 2010 at 3:04 PM, Andrew Bruno
<an...@gmail.com>
> wrote:
>>> Hi Yasushi
>>>
>>> In your serverl.xml have you added the jvmroute to the Engine?
>>>
>>> i.e.
>>>
>>> <Engine name="Catalina" defaultHost="localhost" jvmRoute="1">
>>>
>>> Andrew
>>>
>>> On Tue, Jun 22, 2010 at 2:50 PM, Okubo, Yasushi (TSD)
> <Ya...@takedasd.com> wrote:
>>>> Hi Andrew
>>>>
>>>> Thank for your post. When I checked the session id from firefox,
> sso session id [jsessionidsso] does not have jvmroute info, but only
> jsessionid has jvmroute. So, session replication upon failover is
> working fine, but singlesionon upon failover is not working on tomcat
> 6.0.x (including 6.0.26).
>>>>
>>>> yasushi
>>>>
>>>> -----Original Message-----
>>>> From: Andrew Bruno [mailto:andrew.bruno@gmail.com]
>>>> Sent: Monday, June 21, 2010 9:18 PM
>>>> To: Tomcat Users List
>>>> Subject: Re: question for sso session replication in tomcat 6.0.26
>>>>
>>>> Looking at the code I think this is wrong
>>>>
>>>> if (!_ssoSessionId.contains("." + jvmRoute)) {
>>>> _ssoSessionId += "." + jvmRoute;
>>>> response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME,
> _ssoSessionId));
>>>> }
>>>>
>>>> The original sessionId will already have the
"."+_any_other_jvmRoute
>>>> included, so you need to substring it, and append the new jvmRoute.
>>>>
>>>> _ssoSessionId= _ssoSessionId.substring(0,
> _ssoSessionId.indexOf("."))
>>>>
>>>> and then add
>>>>
>>>> _ssoSessionId += "." + jvmRoute;
>>>>
>>>> AB
>>>>
>>>> On Tue, Jun 22, 2010 at 1:03 PM, Okubo, Yasushi (TSD)
>>>> <Ya...@takedasd.com> wrote:
>>>>> Hi experts
>>>>>
>>>>>
>>>>>
>>>>> I found this old email from archive in TC 5.5.23.
>>>>>
>>>>> Does this problem still exist in tomcat 6.0.x or 6.0.26?
>>>>>
>>>>>
>>>>>
>>>>> When failover occurs, sso session id is updated with new number
> after
>>>>> forcing a user to relogin to the application since sso session id
> is not
>>>>> replicated and rewritten correctly. Could someone explain what is
>>>>> expected in current tomcat 6.0.x cluster upon failover? Should
sso
>>>>> session id is replicated correctly in tomcat 6.0.x?
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> yasushi
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ROOKIE wrote:
>>>>> Hi,
>>>>> I have a problem with tomcat cluster + mod_proxy load balancer :
>>>>>
>>>>> We have a main app which authenticate itself to a webapp and from
> this
>>>>> app one
>>>>> can launch embedded apps which use the SSO cookie to access other
>>>>> webapps on
>>>>> the server (Single-Sign-On for the user).
>>>>>
>>>>> Things are working perfectly for the normal cookie but not for the
> sso
>>>>> cookie.
>>>>>
>>>>>
>>>>> The problem I have is that tomcat does not replicate SSO sessions
> so
>>>>> when these embedded apps route through the load balancer we get
> 401s on
>>>>> all the other cluster members except the one which actually
> generated
>>>>> the SSO cookie.
>>>>>
>>>>> I wanted to know if we can edit the SSO cookie generated by tomcat
> to
>>>>> also
>>>>> contain the jvmRoute parameter so that the load balancer directly
> goes
>>>>> to the
>>>>> correct cluster member.
>>>>>
>>>>>
>>>>> I tried doing this in my code by fetching the SSO cookie and
> appending
>>>>> to it
>>>>> the jvmRoute as follows :
>>>>>
>>>>> HttpServletRequest request =
>>>>> (HttpServletRequest)Security.getContext(HttpServletRequest.class);
>>>>> HttpServletResponse response =
>>>>>
> (HttpServletResponse)Security.getContext(HttpServletResponse.class);
>>>>> if(request != null) {
>>>>> String jvmRoute = "Vinod_Cluster_1"; // as mentioned
> in
>>>>> server.xml
>>>>> Cookie[] cookies = request.getCookies();
>>>>> for(int nc=0; cookies != null && nc < cookies.length;
> nc++)
>>>>> {
>>>>>
> if(_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
>>>>> _sessionId = cookies[nc].getValue();
>>>>> }
>>>>>
>>>>> else if(_SSO_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
>>>>>
>>>>> _ssoSessionId = cookies[nc].getValue();
>>>>> if (!_ssoSessionId.contains("." + jvmRoute)) {
>>>>> _ssoSessionId += "." + jvmRoute;
>>>>>
>>>>> response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME,
> _ssoSessionId));
>>>>> }
>>>>>
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>> But after this I started getting 401s from even the correct
cluster
>>>>> member. My guess is addCookie doesnt update the cookie in tomcat's
> cache
>>>>> which is reasonable.
>>>>>
>>>>> Other thought was to edit tomcat's sso cookie generation code to
> append
>>>>> the
>>>>> jvmRoute to the sso cookie.
>>>>>
>>>>>
>>>>> Is there an better way to achieve this in my code base ?
>>>>>
>>>>> Thanks In Advance,
>>>>> Vinod
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: question for sso session replication in tomcat 6.0.26
Posted by Jon Brisbin <jo...@npcinternational.com>.
Are you using a "jvmRoute" setting on your BalancerMember definition in mod_proxy config and on the <Engine/> element in server.xml? Your cookie would have the jvmRoute property added to the end of it (e.g. ALONGMD5HASH.server1) if so.
From the Almighty Google: http://community.jboss.org/wiki/usingmodproxywithjboss
Jon Brisbin
Portal Webmaster
NPC International, Inc.
On Jun 22, 2010, at 3:48 PM, Okubo, Yasushi (TSD) wrote:
> Hi
>
> I downloaded apache apache v2.2.15 and compiled and installed, but the
> result was the same.
>
> Session sso replication looked like failed. Upon shutting down the
> node, it kicked me out of password protected area and needed to re-loin
> on the second node.
>
> On apache, I installed/enabled all modules including basic
> authentication etc. Is there any requirement on apache side or how the
> virtual host should be set up in httpd.conf to make sso failover work?
>
> Thanks,
> yasushi
>
> -----Original Message-----
> From: Pid [mailto:pid@pidster.com]
> Sent: Tuesday, June 22, 2010 8:04 AM
> To: Tomcat Users List
> Subject: Re: question for sso session replication in tomcat 6.0.26
>
> On 22/06/2010 15:56, Okubo, Yasushi (TSD) wrote:
>> Hi Andrew
>>
>> In case of no failover, SSO works for all web applications on the same
> host. Upon failover [shutting down one node], a user is routed to the
> other node, and TC is asking for a user to re-login when he/she tried to
> access password protected area.
>>
>> I have checked many times on server.xml and session replication is
> working fine upon failover, so I cannot think any misconfiguration on
> server.xml
>> The issue is SSO failover is not working. I think it might be related
> to my apache virtual host setup, but could not figure it out.
>>
>> Thanks for your help,
>> yasushi
>>
>> I am using mod_proxy_ajp, mod_proxy_balancer [v2.2.3]
>
> mod_proxy_ajp appeared in 2.2.3 for the first time, it was functional
> but not perfect & there are many bugfixes and improvements since then,
> you should upgrade HTTPD.
>
>
> p
>
>> OS : Redhat Linux 64bit RHEL v5.5
>> JDK : 1.6.0.20
>>
>> === I created virtual host on port 9050 ==
>> Httpd.conf
>>
>> <VirtualHost 10.250.200.57:9050>
>> ServerAdmin xyz
>> ServerName webclust1.xyz.com
>> ServerAlias webclust1
>> ErrorLog logs/webclust_cluster_error.log
>> CustomLog logs/webclust-cluster-access_log common
>>
>> <Location /balancer-manager>
>> SetHandler balancer-manager
>>
>> Order Deny,Allow
>> Deny from all
>> Allow from all
>> </Location>
>>
>> ProxyRequests off
>> <Proxy balancer://webclust>
>> BalancerMember ajp://10.250.200.57:9001 loadfactor=10 max=150 smax=145
> route=jvm1
>> BalancerMember ajp://10.250.200.57:9002 loadfactor=10 max=150 smax=145
> route=jvm2
>> BalancerMember ajp://10.250.200.57:9003 loadfactor=10 max=150 smax=145
> route=jvm3
>> Order Deny,Allow
>> Allow from all
>> </Proxy>
>>
>> #Do not proxy balancer-manager
>> ProxyPass /balancer-manager !
>>
>> <Location /examples>
>> ProxyPass balancer://webclust/examples
> stickysession=JSESSIONID|jsessionid
>> ProxyPassReverse balancer://webclust/examples
>> Order Deny,Allow
>> Allow from all
>> </Location>
>>
>> <Location / >
>> ProxyPass balancer://webclust/ stickysession=JSESSIONID|jsessionid
>> ProxyPassReverse balancer://webclust/
>> Order Deny,Allow
>> Allow from all
>> </Location>
>>
>>
>> === server.xml ===
>> <!-- Define an AJP 1.3 Connector on port 8009 -->
>> <Connector port="9002" protocol="AJP/1.3" redirectPort="8443" />
>>
>> <Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1">
>>
>> <Host name="localhost" appBase="webapps"
>> unpackWARs="true" autoDeploy="true"
>> xmlValidation="false" xmlNamespaceAware="false">
>>
>> <Cluster
> className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
>> channelSendOptions="4">
>>
>> <Manager
> className="org.apache.catalina.ha.session.DeltaManager"
>> name="node2"
>> expireSessionsOnShutdown="false"
>> notifyListenersOnReplication="true"/>
>>
>> <Channel
> className="org.apache.catalina.tribes.group.GroupChannel">
>> <Membership
> className="org.apache.catalina.tribes.membership.McastService"
>> address="228.0.0.5"
>> port="45564"
>> frequency="500"
>> dropTime="3000"/>
>> <Receiver
> className="org.apache.catalina.tribes.transport.nio.NioReceiver"
>> address="auto"
>> port="4020"
>> autoBind="100"
>> selectorTimeout="5000"
>> maxThreads="12"/>
>> <Sender
> className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
>> <Transport
> className="org.apache.catalina.tribes.transport.nio.PooledParallelSender
> "/>
>> </Sender>
>> <Interceptor
> className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetec
> tor"/>
>> <Interceptor
> className="org.apache.catalina.tribes.group.interceptors.MessageDispatch
> 15Interceptor"/>
>> <Interceptor
> className="org.apache.catalina.tribes.group.interceptors.ThroughputInter
> ceptor"/>
>> </Channel>
>>
>> <Valve
> className="org.apache.catalina.ha.tcp.ReplicationValve"
>>
> filter=".*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;
> .*\.xls;.*\.sdf;.*\.xml;"/>
>> <!-- only with jk_mod failover-->
>> <Valve
> className="org.apache.catalina.ha.session.JvmRouteBinderValve"
>> enabled="true" sessionIdAttribute="takeoverSessionid"
> />
>> <!--
>> <Deployer
> className="org.apache.catalina.ha.deploy.FarmWarDeployer"
>> tempDir="/tmp/war-temp/"
>>
> deployDir="/usr/local/apache/node2-tomcat-6.0.26/webapps"
>> watchDir="/tmp/war-listen/"
>> watchEnabled="true"/>
>> -->
>> <!-- only with jk_mod and jvmroutebindervalve-->
>> <ClusterListener
> className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListene
> r"/>
>> <ClusterListener
> className="org.apache.catalina.ha.session.ClusterSessionListener"/>
>> </Cluster>
>>
>> <Valve
> className="org.apache.catalina.ha.authenticator.ClusterSingleSignOn" />
>>
>> <Valve className="org.apache.catalina.valves.AccessLogValve"
> directory="logs"
>> prefix="webappqa_node2_access_log." suffix=".log"
> pattern="common" resolveHosts="false"/>
>>
>> </Host>
>> </Engine>
>>
>>
>> -----Original Message-----
>> From: Andrew Bruno [mailto:andrew.bruno@gmail.com]
>> Sent: Monday, June 21, 2010 10:09 PM
>> To: Tomcat Users List
>> Subject: Re: question for sso session replication in tomcat 6.0.26
>>
>> Oh sorry, I re-read your answer. Not sure why SSO is not working, be
>> interested to find out though..
>>
>> AB
>>
>> On Tue, Jun 22, 2010 at 3:04 PM, Andrew Bruno <an...@gmail.com>
> wrote:
>>> Hi Yasushi
>>>
>>> In your serverl.xml have you added the jvmroute to the Engine?
>>>
>>> i.e.
>>>
>>> <Engine name="Catalina" defaultHost="localhost" jvmRoute="1">
>>>
>>> Andrew
>>>
>>> On Tue, Jun 22, 2010 at 2:50 PM, Okubo, Yasushi (TSD)
> <Ya...@takedasd.com> wrote:
>>>> Hi Andrew
>>>>
>>>> Thank for your post. When I checked the session id from firefox,
> sso session id [jsessionidsso] does not have jvmroute info, but only
> jsessionid has jvmroute. So, session replication upon failover is
> working fine, but singlesionon upon failover is not working on tomcat
> 6.0.x (including 6.0.26).
>>>>
>>>> yasushi
>>>>
>>>> -----Original Message-----
>>>> From: Andrew Bruno [mailto:andrew.bruno@gmail.com]
>>>> Sent: Monday, June 21, 2010 9:18 PM
>>>> To: Tomcat Users List
>>>> Subject: Re: question for sso session replication in tomcat 6.0.26
>>>>
>>>> Looking at the code I think this is wrong
>>>>
>>>> if (!_ssoSessionId.contains("." + jvmRoute)) {
>>>> _ssoSessionId += "." + jvmRoute;
>>>> response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME,
> _ssoSessionId));
>>>> }
>>>>
>>>> The original sessionId will already have the "."+_any_other_jvmRoute
>>>> included, so you need to substring it, and append the new jvmRoute.
>>>>
>>>> _ssoSessionId= _ssoSessionId.substring(0,
> _ssoSessionId.indexOf("."))
>>>>
>>>> and then add
>>>>
>>>> _ssoSessionId += "." + jvmRoute;
>>>>
>>>> AB
>>>>
>>>> On Tue, Jun 22, 2010 at 1:03 PM, Okubo, Yasushi (TSD)
>>>> <Ya...@takedasd.com> wrote:
>>>>> Hi experts
>>>>>
>>>>>
>>>>>
>>>>> I found this old email from archive in TC 5.5.23.
>>>>>
>>>>> Does this problem still exist in tomcat 6.0.x or 6.0.26?
>>>>>
>>>>>
>>>>>
>>>>> When failover occurs, sso session id is updated with new number
> after
>>>>> forcing a user to relogin to the application since sso session id
> is not
>>>>> replicated and rewritten correctly. Could someone explain what is
>>>>> expected in current tomcat 6.0.x cluster upon failover? Should sso
>>>>> session id is replicated correctly in tomcat 6.0.x?
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> yasushi
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ROOKIE wrote:
>>>>> Hi,
>>>>> I have a problem with tomcat cluster + mod_proxy load balancer :
>>>>>
>>>>> We have a main app which authenticate itself to a webapp and from
> this
>>>>> app one
>>>>> can launch embedded apps which use the SSO cookie to access other
>>>>> webapps on
>>>>> the server (Single-Sign-On for the user).
>>>>>
>>>>> Things are working perfectly for the normal cookie but not for the
> sso
>>>>> cookie.
>>>>>
>>>>>
>>>>> The problem I have is that tomcat does not replicate SSO sessions
> so
>>>>> when these embedded apps route through the load balancer we get
> 401s on
>>>>> all the other cluster members except the one which actually
> generated
>>>>> the SSO cookie.
>>>>>
>>>>> I wanted to know if we can edit the SSO cookie generated by tomcat
> to
>>>>> also
>>>>> contain the jvmRoute parameter so that the load balancer directly
> goes
>>>>> to the
>>>>> correct cluster member.
>>>>>
>>>>>
>>>>> I tried doing this in my code by fetching the SSO cookie and
> appending
>>>>> to it
>>>>> the jvmRoute as follows :
>>>>>
>>>>> HttpServletRequest request =
>>>>> (HttpServletRequest)Security.getContext(HttpServletRequest.class);
>>>>> HttpServletResponse response =
>>>>>
> (HttpServletResponse)Security.getContext(HttpServletResponse.class);
>>>>> if(request != null) {
>>>>> String jvmRoute = "Vinod_Cluster_1"; // as mentioned
> in
>>>>> server.xml
>>>>> Cookie[] cookies = request.getCookies();
>>>>> for(int nc=0; cookies != null && nc < cookies.length;
> nc++)
>>>>> {
>>>>>
> if(_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
>>>>> _sessionId = cookies[nc].getValue();
>>>>> }
>>>>>
>>>>> else if(_SSO_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
>>>>>
>>>>> _ssoSessionId = cookies[nc].getValue();
>>>>> if (!_ssoSessionId.contains("." + jvmRoute)) {
>>>>> _ssoSessionId += "." + jvmRoute;
>>>>>
>>>>> response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME,
> _ssoSessionId));
>>>>> }
>>>>>
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>> But after this I started getting 401s from even the correct cluster
>>>>> member. My guess is addCookie doesnt update the cookie in tomcat's
> cache
>>>>> which is reasonable.
>>>>>
>>>>> Other thought was to edit tomcat's sso cookie generation code to
> append
>>>>> the
>>>>> jvmRoute to the sso cookie.
>>>>>
>>>>>
>>>>> Is there an better way to achieve this in my code base ?
>>>>>
>>>>> Thanks In Advance,
>>>>> Vinod
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: question for sso session replication in tomcat 6.0.26
Posted by "Okubo, Yasushi (TSD)" <Ya...@takedasd.com>.
Hi
I downloaded apache apache v2.2.15 and compiled and installed, but the
result was the same.
Session sso replication looked like failed. Upon shutting down the
node, it kicked me out of password protected area and needed to re-loin
on the second node.
On apache, I installed/enabled all modules including basic
authentication etc. Is there any requirement on apache side or how the
virtual host should be set up in httpd.conf to make sso failover work?
Thanks,
yasushi
-----Original Message-----
From: Pid [mailto:pid@pidster.com]
Sent: Tuesday, June 22, 2010 8:04 AM
To: Tomcat Users List
Subject: Re: question for sso session replication in tomcat 6.0.26
On 22/06/2010 15:56, Okubo, Yasushi (TSD) wrote:
> Hi Andrew
>
> In case of no failover, SSO works for all web applications on the same
host. Upon failover [shutting down one node], a user is routed to the
other node, and TC is asking for a user to re-login when he/she tried to
access password protected area.
>
> I have checked many times on server.xml and session replication is
working fine upon failover, so I cannot think any misconfiguration on
server.xml
> The issue is SSO failover is not working. I think it might be related
to my apache virtual host setup, but could not figure it out.
>
> Thanks for your help,
> yasushi
>
> I am using mod_proxy_ajp, mod_proxy_balancer [v2.2.3]
mod_proxy_ajp appeared in 2.2.3 for the first time, it was functional
but not perfect & there are many bugfixes and improvements since then,
you should upgrade HTTPD.
p
> OS : Redhat Linux 64bit RHEL v5.5
> JDK : 1.6.0.20
>
> === I created virtual host on port 9050 ==
> Httpd.conf
>
> <VirtualHost 10.250.200.57:9050>
> ServerAdmin xyz
> ServerName webclust1.xyz.com
> ServerAlias webclust1
> ErrorLog logs/webclust_cluster_error.log
> CustomLog logs/webclust-cluster-access_log common
>
> <Location /balancer-manager>
> SetHandler balancer-manager
>
> Order Deny,Allow
> Deny from all
> Allow from all
> </Location>
>
> ProxyRequests off
> <Proxy balancer://webclust>
> BalancerMember ajp://10.250.200.57:9001 loadfactor=10 max=150 smax=145
route=jvm1
> BalancerMember ajp://10.250.200.57:9002 loadfactor=10 max=150 smax=145
route=jvm2
> BalancerMember ajp://10.250.200.57:9003 loadfactor=10 max=150 smax=145
route=jvm3
> Order Deny,Allow
> Allow from all
> </Proxy>
>
> #Do not proxy balancer-manager
> ProxyPass /balancer-manager !
>
> <Location /examples>
> ProxyPass balancer://webclust/examples
stickysession=JSESSIONID|jsessionid
> ProxyPassReverse balancer://webclust/examples
> Order Deny,Allow
> Allow from all
> </Location>
>
> <Location / >
> ProxyPass balancer://webclust/ stickysession=JSESSIONID|jsessionid
> ProxyPassReverse balancer://webclust/
> Order Deny,Allow
> Allow from all
> </Location>
>
>
> === server.xml ===
> <!-- Define an AJP 1.3 Connector on port 8009 -->
> <Connector port="9002" protocol="AJP/1.3" redirectPort="8443" />
>
> <Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1">
>
> <Host name="localhost" appBase="webapps"
> unpackWARs="true" autoDeploy="true"
> xmlValidation="false" xmlNamespaceAware="false">
>
> <Cluster
className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
> channelSendOptions="4">
>
> <Manager
className="org.apache.catalina.ha.session.DeltaManager"
> name="node2"
> expireSessionsOnShutdown="false"
> notifyListenersOnReplication="true"/>
>
> <Channel
className="org.apache.catalina.tribes.group.GroupChannel">
> <Membership
className="org.apache.catalina.tribes.membership.McastService"
> address="228.0.0.5"
> port="45564"
> frequency="500"
> dropTime="3000"/>
> <Receiver
className="org.apache.catalina.tribes.transport.nio.NioReceiver"
> address="auto"
> port="4020"
> autoBind="100"
> selectorTimeout="5000"
> maxThreads="12"/>
> <Sender
className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
> <Transport
className="org.apache.catalina.tribes.transport.nio.PooledParallelSender
"/>
> </Sender>
> <Interceptor
className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetec
tor"/>
> <Interceptor
className="org.apache.catalina.tribes.group.interceptors.MessageDispatch
15Interceptor"/>
> <Interceptor
className="org.apache.catalina.tribes.group.interceptors.ThroughputInter
ceptor"/>
> </Channel>
>
> <Valve
className="org.apache.catalina.ha.tcp.ReplicationValve"
>
filter=".*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;
.*\.xls;.*\.sdf;.*\.xml;"/>
> <!-- only with jk_mod failover-->
> <Valve
className="org.apache.catalina.ha.session.JvmRouteBinderValve"
> enabled="true" sessionIdAttribute="takeoverSessionid"
/>
> <!--
> <Deployer
className="org.apache.catalina.ha.deploy.FarmWarDeployer"
> tempDir="/tmp/war-temp/"
>
deployDir="/usr/local/apache/node2-tomcat-6.0.26/webapps"
> watchDir="/tmp/war-listen/"
> watchEnabled="true"/>
> -->
> <!-- only with jk_mod and jvmroutebindervalve-->
> <ClusterListener
className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListene
r"/>
> <ClusterListener
className="org.apache.catalina.ha.session.ClusterSessionListener"/>
> </Cluster>
>
> <Valve
className="org.apache.catalina.ha.authenticator.ClusterSingleSignOn" />
>
> <Valve className="org.apache.catalina.valves.AccessLogValve"
directory="logs"
> prefix="webappqa_node2_access_log." suffix=".log"
pattern="common" resolveHosts="false"/>
>
> </Host>
> </Engine>
>
>
> -----Original Message-----
> From: Andrew Bruno [mailto:andrew.bruno@gmail.com]
> Sent: Monday, June 21, 2010 10:09 PM
> To: Tomcat Users List
> Subject: Re: question for sso session replication in tomcat 6.0.26
>
> Oh sorry, I re-read your answer. Not sure why SSO is not working, be
> interested to find out though..
>
> AB
>
> On Tue, Jun 22, 2010 at 3:04 PM, Andrew Bruno <an...@gmail.com>
wrote:
>> Hi Yasushi
>>
>> In your serverl.xml have you added the jvmroute to the Engine?
>>
>> i.e.
>>
>> <Engine name="Catalina" defaultHost="localhost" jvmRoute="1">
>>
>> Andrew
>>
>> On Tue, Jun 22, 2010 at 2:50 PM, Okubo, Yasushi (TSD)
<Ya...@takedasd.com> wrote:
>>> Hi Andrew
>>>
>>> Thank for your post. When I checked the session id from firefox,
sso session id [jsessionidsso] does not have jvmroute info, but only
jsessionid has jvmroute. So, session replication upon failover is
working fine, but singlesionon upon failover is not working on tomcat
6.0.x (including 6.0.26).
>>>
>>> yasushi
>>>
>>> -----Original Message-----
>>> From: Andrew Bruno [mailto:andrew.bruno@gmail.com]
>>> Sent: Monday, June 21, 2010 9:18 PM
>>> To: Tomcat Users List
>>> Subject: Re: question for sso session replication in tomcat 6.0.26
>>>
>>> Looking at the code I think this is wrong
>>>
>>> if (!_ssoSessionId.contains("." + jvmRoute)) {
>>> _ssoSessionId += "." + jvmRoute;
>>> response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME,
_ssoSessionId));
>>> }
>>>
>>> The original sessionId will already have the "."+_any_other_jvmRoute
>>> included, so you need to substring it, and append the new jvmRoute.
>>>
>>> _ssoSessionId= _ssoSessionId.substring(0,
_ssoSessionId.indexOf("."))
>>>
>>> and then add
>>>
>>> _ssoSessionId += "." + jvmRoute;
>>>
>>> AB
>>>
>>> On Tue, Jun 22, 2010 at 1:03 PM, Okubo, Yasushi (TSD)
>>> <Ya...@takedasd.com> wrote:
>>>> Hi experts
>>>>
>>>>
>>>>
>>>> I found this old email from archive in TC 5.5.23.
>>>>
>>>> Does this problem still exist in tomcat 6.0.x or 6.0.26?
>>>>
>>>>
>>>>
>>>> When failover occurs, sso session id is updated with new number
after
>>>> forcing a user to relogin to the application since sso session id
is not
>>>> replicated and rewritten correctly. Could someone explain what is
>>>> expected in current tomcat 6.0.x cluster upon failover? Should sso
>>>> session id is replicated correctly in tomcat 6.0.x?
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> yasushi
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ROOKIE wrote:
>>>> Hi,
>>>> I have a problem with tomcat cluster + mod_proxy load balancer :
>>>>
>>>> We have a main app which authenticate itself to a webapp and from
this
>>>> app one
>>>> can launch embedded apps which use the SSO cookie to access other
>>>> webapps on
>>>> the server (Single-Sign-On for the user).
>>>>
>>>> Things are working perfectly for the normal cookie but not for the
sso
>>>> cookie.
>>>>
>>>>
>>>> The problem I have is that tomcat does not replicate SSO sessions
so
>>>> when these embedded apps route through the load balancer we get
401s on
>>>> all the other cluster members except the one which actually
generated
>>>> the SSO cookie.
>>>>
>>>> I wanted to know if we can edit the SSO cookie generated by tomcat
to
>>>> also
>>>> contain the jvmRoute parameter so that the load balancer directly
goes
>>>> to the
>>>> correct cluster member.
>>>>
>>>>
>>>> I tried doing this in my code by fetching the SSO cookie and
appending
>>>> to it
>>>> the jvmRoute as follows :
>>>>
>>>> HttpServletRequest request =
>>>> (HttpServletRequest)Security.getContext(HttpServletRequest.class);
>>>> HttpServletResponse response =
>>>>
(HttpServletResponse)Security.getContext(HttpServletResponse.class);
>>>> if(request != null) {
>>>> String jvmRoute = "Vinod_Cluster_1"; // as mentioned
in
>>>> server.xml
>>>> Cookie[] cookies = request.getCookies();
>>>> for(int nc=0; cookies != null && nc < cookies.length;
nc++)
>>>> {
>>>>
if(_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
>>>> _sessionId = cookies[nc].getValue();
>>>> }
>>>>
>>>> else if(_SSO_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
>>>>
>>>> _ssoSessionId = cookies[nc].getValue();
>>>> if (!_ssoSessionId.contains("." + jvmRoute)) {
>>>> _ssoSessionId += "." + jvmRoute;
>>>>
>>>> response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME,
_ssoSessionId));
>>>> }
>>>>
>>>>
>>>> }
>>>>
>>>>
>>>> But after this I started getting 401s from even the correct cluster
>>>> member. My guess is addCookie doesnt update the cookie in tomcat's
cache
>>>> which is reasonable.
>>>>
>>>> Other thought was to edit tomcat's sso cookie generation code to
append
>>>> the
>>>> jvmRoute to the sso cookie.
>>>>
>>>>
>>>> Is there an better way to achieve this in my code base ?
>>>>
>>>> Thanks In Advance,
>>>> Vinod
>>>>
>>>>
>>>>
>>>>
>>>
>>>
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>>
>>>
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: question for sso session replication in tomcat 6.0.26
Posted by "Okubo, Yasushi (TSD)" <Ya...@takedasd.com>.
Sorry I should clarify few things:
In case of no failover, SSO works for all web applications on the same node, not host. Then, session replication upon failover works for non-password protected area only.
-----Original Message-----
From: Okubo, Yasushi (TSD) [mailto:Yasushi.Okubo@takedasd.com]
Sent: Tuesday, June 22, 2010 7:57 AM
To: Tomcat Users List
Subject: RE: question for sso session replication in tomcat 6.0.26
Hi Andrew
In case of no failover, SSO works for all web applications on the same host. Upon failover [shutting down one node], a user is routed to the other node, and TC is asking for a user to re-login when he/she tried to access password protected area.
I have checked many times on server.xml and session replication is working fine upon failover, so I cannot think any misconfiguration on server.xml
The issue is SSO failover is not working. I think it might be related to my apache virtual host setup, but could not figure it out.
Thanks for your help,
yasushi
I am using mod_proxy_ajp, mod_proxy_balancer [v2.2.3]
OS : Redhat Linux 64bit RHEL v5.5
JDK : 1.6.0.20
=== I created virtual host on port 9050 ==
Httpd.conf
<VirtualHost 10.250.200.57:9050>
ServerAdmin xyz
ServerName webclust1.xyz.com
ServerAlias webclust1
ErrorLog logs/webclust_cluster_error.log
CustomLog logs/webclust-cluster-access_log common
<Location /balancer-manager>
SetHandler balancer-manager
Order Deny,Allow
Deny from all
Allow from all
</Location>
ProxyRequests off
<Proxy balancer://webclust>
BalancerMember ajp://10.250.200.57:9001 loadfactor=10 max=150 smax=145 route=jvm1
BalancerMember ajp://10.250.200.57:9002 loadfactor=10 max=150 smax=145 route=jvm2
BalancerMember ajp://10.250.200.57:9003 loadfactor=10 max=150 smax=145 route=jvm3
Order Deny,Allow
Allow from all
</Proxy>
#Do not proxy balancer-manager
ProxyPass /balancer-manager !
<Location /examples>
ProxyPass balancer://webclust/examples stickysession=JSESSIONID|jsessionid
ProxyPassReverse balancer://webclust/examples
Order Deny,Allow
Allow from all
</Location>
<Location / >
ProxyPass balancer://webclust/ stickysession=JSESSIONID|jsessionid
ProxyPassReverse balancer://webclust/
Order Deny,Allow
Allow from all
</Location>
=== server.xml ===
<!-- Define an AJP 1.3 Connector on port 8009 -->
<Connector port="9002" protocol="AJP/1.3" redirectPort="8443" />
<Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1">
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true"
xmlValidation="false" xmlNamespaceAware="false">
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
channelSendOptions="4">
<Manager className="org.apache.catalina.ha.session.DeltaManager"
name="node2"
expireSessionsOnShutdown="false"
notifyListenersOnReplication="true"/>
<Channel className="org.apache.catalina.tribes.group.GroupChannel">
<Membership className="org.apache.catalina.tribes.membership.McastService"
address="228.0.0.5"
port="45564"
frequency="500"
dropTime="3000"/>
<Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
address="auto"
port="4020"
autoBind="100"
selectorTimeout="5000"
maxThreads="12"/>
<Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
<Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
</Sender>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor"/>
</Channel>
<Valve className="org.apache.catalina.ha.tcp.ReplicationValve"
filter=".*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;.*\.xls;.*\.sdf;.*\.xml;"/>
<!-- only with jk_mod failover-->
<Valve className="org.apache.catalina.ha.session.JvmRouteBinderValve"
enabled="true" sessionIdAttribute="takeoverSessionid" />
<!--
<Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer"
tempDir="/tmp/war-temp/"
deployDir="/usr/local/apache/node2-tomcat-6.0.26/webapps"
watchDir="/tmp/war-listen/"
watchEnabled="true"/>
-->
<!-- only with jk_mod and jvmroutebindervalve-->
<ClusterListener className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/>
<ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>
</Cluster>
<Valve className="org.apache.catalina.ha.authenticator.ClusterSingleSignOn" />
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
prefix="webappqa_node2_access_log." suffix=".log" pattern="common" resolveHosts="false"/>
</Host>
</Engine>
-----Original Message-----
From: Andrew Bruno [mailto:andrew.bruno@gmail.com]
Sent: Monday, June 21, 2010 10:09 PM
To: Tomcat Users List
Subject: Re: question for sso session replication in tomcat 6.0.26
Oh sorry, I re-read your answer. Not sure why SSO is not working, be
interested to find out though..
AB
On Tue, Jun 22, 2010 at 3:04 PM, Andrew Bruno <an...@gmail.com> wrote:
> Hi Yasushi
>
> In your serverl.xml have you added the jvmroute to the Engine?
>
> i.e.
>
> <Engine name="Catalina" defaultHost="localhost" jvmRoute="1">
>
> Andrew
>
> On Tue, Jun 22, 2010 at 2:50 PM, Okubo, Yasushi (TSD) <Ya...@takedasd.com> wrote:
>> Hi Andrew
>>
>> Thank for your post. When I checked the session id from firefox, sso session id [jsessionidsso] does not have jvmroute info, but only jsessionid has jvmroute. So, session replication upon failover is working fine, but singlesionon upon failover is not working on tomcat 6.0.x (including 6.0.26).
>>
>> yasushi
>>
>> -----Original Message-----
>> From: Andrew Bruno [mailto:andrew.bruno@gmail.com]
>> Sent: Monday, June 21, 2010 9:18 PM
>> To: Tomcat Users List
>> Subject: Re: question for sso session replication in tomcat 6.0.26
>>
>> Looking at the code I think this is wrong
>>
>> if (!_ssoSessionId.contains("." + jvmRoute)) {
>> _ssoSessionId += "." + jvmRoute;
>> response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME, _ssoSessionId));
>> }
>>
>> The original sessionId will already have the "."+_any_other_jvmRoute
>> included, so you need to substring it, and append the new jvmRoute.
>>
>> _ssoSessionId= _ssoSessionId.substring(0, _ssoSessionId.indexOf("."))
>>
>> and then add
>>
>> _ssoSessionId += "." + jvmRoute;
>>
>> AB
>>
>> On Tue, Jun 22, 2010 at 1:03 PM, Okubo, Yasushi (TSD)
>> <Ya...@takedasd.com> wrote:
>>> Hi experts
>>>
>>>
>>>
>>> I found this old email from archive in TC 5.5.23.
>>>
>>> Does this problem still exist in tomcat 6.0.x or 6.0.26?
>>>
>>>
>>>
>>> When failover occurs, sso session id is updated with new number after
>>> forcing a user to relogin to the application since sso session id is not
>>> replicated and rewritten correctly. Could someone explain what is
>>> expected in current tomcat 6.0.x cluster upon failover? Should sso
>>> session id is replicated correctly in tomcat 6.0.x?
>>>
>>>
>>>
>>> Thanks,
>>>
>>> yasushi
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ROOKIE wrote:
>>> Hi,
>>> I have a problem with tomcat cluster + mod_proxy load balancer :
>>>
>>> We have a main app which authenticate itself to a webapp and from this
>>> app one
>>> can launch embedded apps which use the SSO cookie to access other
>>> webapps on
>>> the server (Single-Sign-On for the user).
>>>
>>> Things are working perfectly for the normal cookie but not for the sso
>>> cookie.
>>>
>>>
>>> The problem I have is that tomcat does not replicate SSO sessions so
>>> when these embedded apps route through the load balancer we get 401s on
>>> all the other cluster members except the one which actually generated
>>> the SSO cookie.
>>>
>>> I wanted to know if we can edit the SSO cookie generated by tomcat to
>>> also
>>> contain the jvmRoute parameter so that the load balancer directly goes
>>> to the
>>> correct cluster member.
>>>
>>>
>>> I tried doing this in my code by fetching the SSO cookie and appending
>>> to it
>>> the jvmRoute as follows :
>>>
>>> HttpServletRequest request =
>>> (HttpServletRequest)Security.getContext(HttpServletRequest.class);
>>> HttpServletResponse response =
>>> (HttpServletResponse)Security.getContext(HttpServletResponse.class);
>>> if(request != null) {
>>> String jvmRoute = "Vinod_Cluster_1"; // as mentioned in
>>> server.xml
>>> Cookie[] cookies = request.getCookies();
>>> for(int nc=0; cookies != null && nc < cookies.length; nc++)
>>> {
>>> if(_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
>>> _sessionId = cookies[nc].getValue();
>>> }
>>>
>>> else if(_SSO_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
>>>
>>> _ssoSessionId = cookies[nc].getValue();
>>> if (!_ssoSessionId.contains("." + jvmRoute)) {
>>> _ssoSessionId += "." + jvmRoute;
>>>
>>> response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME, _ssoSessionId));
>>> }
>>>
>>>
>>> }
>>>
>>>
>>> But after this I started getting 401s from even the correct cluster
>>> member. My guess is addCookie doesnt update the cookie in tomcat's cache
>>> which is reasonable.
>>>
>>> Other thought was to edit tomcat's sso cookie generation code to append
>>> the
>>> jvmRoute to the sso cookie.
>>>
>>>
>>> Is there an better way to achieve this in my code base ?
>>>
>>> Thanks In Advance,
>>> Vinod
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: question for sso session replication in tomcat 6.0.26
Posted by "Okubo, Yasushi (TSD)" <Ya...@takedasd.com>.
Ok
I will try to install the latest apache httpd and test again.
Thanks,
yasushi
-----Original Message-----
From: Pid [mailto:pid@pidster.com]
Sent: Tuesday, June 22, 2010 8:04 AM
To: Tomcat Users List
Subject: Re: question for sso session replication in tomcat 6.0.26
On 22/06/2010 15:56, Okubo, Yasushi (TSD) wrote:
> Hi Andrew
>
> In case of no failover, SSO works for all web applications on the same
host. Upon failover [shutting down one node], a user is routed to the
other node, and TC is asking for a user to re-login when he/she tried to
access password protected area.
>
> I have checked many times on server.xml and session replication is
working fine upon failover, so I cannot think any misconfiguration on
server.xml
> The issue is SSO failover is not working. I think it might be related
to my apache virtual host setup, but could not figure it out.
>
> Thanks for your help,
> yasushi
>
> I am using mod_proxy_ajp, mod_proxy_balancer [v2.2.3]
mod_proxy_ajp appeared in 2.2.3 for the first time, it was functional
but not perfect & there are many bugfixes and improvements since then,
you should upgrade HTTPD.
p
> OS : Redhat Linux 64bit RHEL v5.5
> JDK : 1.6.0.20
>
> === I created virtual host on port 9050 ==
> Httpd.conf
>
> <VirtualHost 10.250.200.57:9050>
> ServerAdmin xyz
> ServerName webclust1.xyz.com
> ServerAlias webclust1
> ErrorLog logs/webclust_cluster_error.log
> CustomLog logs/webclust-cluster-access_log common
>
> <Location /balancer-manager>
> SetHandler balancer-manager
>
> Order Deny,Allow
> Deny from all
> Allow from all
> </Location>
>
> ProxyRequests off
> <Proxy balancer://webclust>
> BalancerMember ajp://10.250.200.57:9001 loadfactor=10 max=150 smax=145
route=jvm1
> BalancerMember ajp://10.250.200.57:9002 loadfactor=10 max=150 smax=145
route=jvm2
> BalancerMember ajp://10.250.200.57:9003 loadfactor=10 max=150 smax=145
route=jvm3
> Order Deny,Allow
> Allow from all
> </Proxy>
>
> #Do not proxy balancer-manager
> ProxyPass /balancer-manager !
>
> <Location /examples>
> ProxyPass balancer://webclust/examples
stickysession=JSESSIONID|jsessionid
> ProxyPassReverse balancer://webclust/examples
> Order Deny,Allow
> Allow from all
> </Location>
>
> <Location / >
> ProxyPass balancer://webclust/ stickysession=JSESSIONID|jsessionid
> ProxyPassReverse balancer://webclust/
> Order Deny,Allow
> Allow from all
> </Location>
>
>
> === server.xml ===
> <!-- Define an AJP 1.3 Connector on port 8009 -->
> <Connector port="9002" protocol="AJP/1.3" redirectPort="8443" />
>
> <Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1">
>
> <Host name="localhost" appBase="webapps"
> unpackWARs="true" autoDeploy="true"
> xmlValidation="false" xmlNamespaceAware="false">
>
> <Cluster
className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
> channelSendOptions="4">
>
> <Manager
className="org.apache.catalina.ha.session.DeltaManager"
> name="node2"
> expireSessionsOnShutdown="false"
> notifyListenersOnReplication="true"/>
>
> <Channel
className="org.apache.catalina.tribes.group.GroupChannel">
> <Membership
className="org.apache.catalina.tribes.membership.McastService"
> address="228.0.0.5"
> port="45564"
> frequency="500"
> dropTime="3000"/>
> <Receiver
className="org.apache.catalina.tribes.transport.nio.NioReceiver"
> address="auto"
> port="4020"
> autoBind="100"
> selectorTimeout="5000"
> maxThreads="12"/>
> <Sender
className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
> <Transport
className="org.apache.catalina.tribes.transport.nio.PooledParallelSender
"/>
> </Sender>
> <Interceptor
className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetec
tor"/>
> <Interceptor
className="org.apache.catalina.tribes.group.interceptors.MessageDispatch
15Interceptor"/>
> <Interceptor
className="org.apache.catalina.tribes.group.interceptors.ThroughputInter
ceptor"/>
> </Channel>
>
> <Valve
className="org.apache.catalina.ha.tcp.ReplicationValve"
>
filter=".*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;
.*\.xls;.*\.sdf;.*\.xml;"/>
> <!-- only with jk_mod failover-->
> <Valve
className="org.apache.catalina.ha.session.JvmRouteBinderValve"
> enabled="true" sessionIdAttribute="takeoverSessionid"
/>
> <!--
> <Deployer
className="org.apache.catalina.ha.deploy.FarmWarDeployer"
> tempDir="/tmp/war-temp/"
>
deployDir="/usr/local/apache/node2-tomcat-6.0.26/webapps"
> watchDir="/tmp/war-listen/"
> watchEnabled="true"/>
> -->
> <!-- only with jk_mod and jvmroutebindervalve-->
> <ClusterListener
className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListene
r"/>
> <ClusterListener
className="org.apache.catalina.ha.session.ClusterSessionListener"/>
> </Cluster>
>
> <Valve
className="org.apache.catalina.ha.authenticator.ClusterSingleSignOn" />
>
> <Valve className="org.apache.catalina.valves.AccessLogValve"
directory="logs"
> prefix="webappqa_node2_access_log." suffix=".log"
pattern="common" resolveHosts="false"/>
>
> </Host>
> </Engine>
>
>
> -----Original Message-----
> From: Andrew Bruno [mailto:andrew.bruno@gmail.com]
> Sent: Monday, June 21, 2010 10:09 PM
> To: Tomcat Users List
> Subject: Re: question for sso session replication in tomcat 6.0.26
>
> Oh sorry, I re-read your answer. Not sure why SSO is not working, be
> interested to find out though..
>
> AB
>
> On Tue, Jun 22, 2010 at 3:04 PM, Andrew Bruno <an...@gmail.com>
wrote:
>> Hi Yasushi
>>
>> In your serverl.xml have you added the jvmroute to the Engine?
>>
>> i.e.
>>
>> <Engine name="Catalina" defaultHost="localhost" jvmRoute="1">
>>
>> Andrew
>>
>> On Tue, Jun 22, 2010 at 2:50 PM, Okubo, Yasushi (TSD)
<Ya...@takedasd.com> wrote:
>>> Hi Andrew
>>>
>>> Thank for your post. When I checked the session id from firefox,
sso session id [jsessionidsso] does not have jvmroute info, but only
jsessionid has jvmroute. So, session replication upon failover is
working fine, but singlesionon upon failover is not working on tomcat
6.0.x (including 6.0.26).
>>>
>>> yasushi
>>>
>>> -----Original Message-----
>>> From: Andrew Bruno [mailto:andrew.bruno@gmail.com]
>>> Sent: Monday, June 21, 2010 9:18 PM
>>> To: Tomcat Users List
>>> Subject: Re: question for sso session replication in tomcat 6.0.26
>>>
>>> Looking at the code I think this is wrong
>>>
>>> if (!_ssoSessionId.contains("." + jvmRoute)) {
>>> _ssoSessionId += "." + jvmRoute;
>>> response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME,
_ssoSessionId));
>>> }
>>>
>>> The original sessionId will already have the "."+_any_other_jvmRoute
>>> included, so you need to substring it, and append the new jvmRoute.
>>>
>>> _ssoSessionId= _ssoSessionId.substring(0,
_ssoSessionId.indexOf("."))
>>>
>>> and then add
>>>
>>> _ssoSessionId += "." + jvmRoute;
>>>
>>> AB
>>>
>>> On Tue, Jun 22, 2010 at 1:03 PM, Okubo, Yasushi (TSD)
>>> <Ya...@takedasd.com> wrote:
>>>> Hi experts
>>>>
>>>>
>>>>
>>>> I found this old email from archive in TC 5.5.23.
>>>>
>>>> Does this problem still exist in tomcat 6.0.x or 6.0.26?
>>>>
>>>>
>>>>
>>>> When failover occurs, sso session id is updated with new number
after
>>>> forcing a user to relogin to the application since sso session id
is not
>>>> replicated and rewritten correctly. Could someone explain what is
>>>> expected in current tomcat 6.0.x cluster upon failover? Should sso
>>>> session id is replicated correctly in tomcat 6.0.x?
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> yasushi
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ROOKIE wrote:
>>>> Hi,
>>>> I have a problem with tomcat cluster + mod_proxy load balancer :
>>>>
>>>> We have a main app which authenticate itself to a webapp and from
this
>>>> app one
>>>> can launch embedded apps which use the SSO cookie to access other
>>>> webapps on
>>>> the server (Single-Sign-On for the user).
>>>>
>>>> Things are working perfectly for the normal cookie but not for the
sso
>>>> cookie.
>>>>
>>>>
>>>> The problem I have is that tomcat does not replicate SSO sessions
so
>>>> when these embedded apps route through the load balancer we get
401s on
>>>> all the other cluster members except the one which actually
generated
>>>> the SSO cookie.
>>>>
>>>> I wanted to know if we can edit the SSO cookie generated by tomcat
to
>>>> also
>>>> contain the jvmRoute parameter so that the load balancer directly
goes
>>>> to the
>>>> correct cluster member.
>>>>
>>>>
>>>> I tried doing this in my code by fetching the SSO cookie and
appending
>>>> to it
>>>> the jvmRoute as follows :
>>>>
>>>> HttpServletRequest request =
>>>> (HttpServletRequest)Security.getContext(HttpServletRequest.class);
>>>> HttpServletResponse response =
>>>>
(HttpServletResponse)Security.getContext(HttpServletResponse.class);
>>>> if(request != null) {
>>>> String jvmRoute = "Vinod_Cluster_1"; // as mentioned
in
>>>> server.xml
>>>> Cookie[] cookies = request.getCookies();
>>>> for(int nc=0; cookies != null && nc < cookies.length;
nc++)
>>>> {
>>>>
if(_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
>>>> _sessionId = cookies[nc].getValue();
>>>> }
>>>>
>>>> else if(_SSO_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
>>>>
>>>> _ssoSessionId = cookies[nc].getValue();
>>>> if (!_ssoSessionId.contains("." + jvmRoute)) {
>>>> _ssoSessionId += "." + jvmRoute;
>>>>
>>>> response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME,
_ssoSessionId));
>>>> }
>>>>
>>>>
>>>> }
>>>>
>>>>
>>>> But after this I started getting 401s from even the correct cluster
>>>> member. My guess is addCookie doesnt update the cookie in tomcat's
cache
>>>> which is reasonable.
>>>>
>>>> Other thought was to edit tomcat's sso cookie generation code to
append
>>>> the
>>>> jvmRoute to the sso cookie.
>>>>
>>>>
>>>> Is there an better way to achieve this in my code base ?
>>>>
>>>> Thanks In Advance,
>>>> Vinod
>>>>
>>>>
>>>>
>>>>
>>>
>>>
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>>
>>>
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: question for sso session replication in tomcat 6.0.26
Posted by Pid <pi...@pidster.com>.
On 22/06/2010 15:56, Okubo, Yasushi (TSD) wrote:
> Hi Andrew
>
> In case of no failover, SSO works for all web applications on the same host. Upon failover [shutting down one node], a user is routed to the other node, and TC is asking for a user to re-login when he/she tried to access password protected area.
>
> I have checked many times on server.xml and session replication is working fine upon failover, so I cannot think any misconfiguration on server.xml
> The issue is SSO failover is not working. I think it might be related to my apache virtual host setup, but could not figure it out.
>
> Thanks for your help,
> yasushi
>
> I am using mod_proxy_ajp, mod_proxy_balancer [v2.2.3]
mod_proxy_ajp appeared in 2.2.3 for the first time, it was functional
but not perfect & there are many bugfixes and improvements since then,
you should upgrade HTTPD.
p
> OS : Redhat Linux 64bit RHEL v5.5
> JDK : 1.6.0.20
>
> === I created virtual host on port 9050 ==
> Httpd.conf
>
> <VirtualHost 10.250.200.57:9050>
> ServerAdmin xyz
> ServerName webclust1.xyz.com
> ServerAlias webclust1
> ErrorLog logs/webclust_cluster_error.log
> CustomLog logs/webclust-cluster-access_log common
>
> <Location /balancer-manager>
> SetHandler balancer-manager
>
> Order Deny,Allow
> Deny from all
> Allow from all
> </Location>
>
> ProxyRequests off
> <Proxy balancer://webclust>
> BalancerMember ajp://10.250.200.57:9001 loadfactor=10 max=150 smax=145 route=jvm1
> BalancerMember ajp://10.250.200.57:9002 loadfactor=10 max=150 smax=145 route=jvm2
> BalancerMember ajp://10.250.200.57:9003 loadfactor=10 max=150 smax=145 route=jvm3
> Order Deny,Allow
> Allow from all
> </Proxy>
>
> #Do not proxy balancer-manager
> ProxyPass /balancer-manager !
>
> <Location /examples>
> ProxyPass balancer://webclust/examples stickysession=JSESSIONID|jsessionid
> ProxyPassReverse balancer://webclust/examples
> Order Deny,Allow
> Allow from all
> </Location>
>
> <Location / >
> ProxyPass balancer://webclust/ stickysession=JSESSIONID|jsessionid
> ProxyPassReverse balancer://webclust/
> Order Deny,Allow
> Allow from all
> </Location>
>
>
> === server.xml ===
> <!-- Define an AJP 1.3 Connector on port 8009 -->
> <Connector port="9002" protocol="AJP/1.3" redirectPort="8443" />
>
> <Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1">
>
> <Host name="localhost" appBase="webapps"
> unpackWARs="true" autoDeploy="true"
> xmlValidation="false" xmlNamespaceAware="false">
>
> <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
> channelSendOptions="4">
>
> <Manager className="org.apache.catalina.ha.session.DeltaManager"
> name="node2"
> expireSessionsOnShutdown="false"
> notifyListenersOnReplication="true"/>
>
> <Channel className="org.apache.catalina.tribes.group.GroupChannel">
> <Membership className="org.apache.catalina.tribes.membership.McastService"
> address="228.0.0.5"
> port="45564"
> frequency="500"
> dropTime="3000"/>
> <Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
> address="auto"
> port="4020"
> autoBind="100"
> selectorTimeout="5000"
> maxThreads="12"/>
> <Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
> <Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
> </Sender>
> <Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
> <Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
> <Interceptor className="org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor"/>
> </Channel>
>
> <Valve className="org.apache.catalina.ha.tcp.ReplicationValve"
> filter=".*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;.*\.xls;.*\.sdf;.*\.xml;"/>
> <!-- only with jk_mod failover-->
> <Valve className="org.apache.catalina.ha.session.JvmRouteBinderValve"
> enabled="true" sessionIdAttribute="takeoverSessionid" />
> <!--
> <Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer"
> tempDir="/tmp/war-temp/"
> deployDir="/usr/local/apache/node2-tomcat-6.0.26/webapps"
> watchDir="/tmp/war-listen/"
> watchEnabled="true"/>
> -->
> <!-- only with jk_mod and jvmroutebindervalve-->
> <ClusterListener className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/>
> <ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>
> </Cluster>
>
> <Valve className="org.apache.catalina.ha.authenticator.ClusterSingleSignOn" />
>
> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
> prefix="webappqa_node2_access_log." suffix=".log" pattern="common" resolveHosts="false"/>
>
> </Host>
> </Engine>
>
>
> -----Original Message-----
> From: Andrew Bruno [mailto:andrew.bruno@gmail.com]
> Sent: Monday, June 21, 2010 10:09 PM
> To: Tomcat Users List
> Subject: Re: question for sso session replication in tomcat 6.0.26
>
> Oh sorry, I re-read your answer. Not sure why SSO is not working, be
> interested to find out though..
>
> AB
>
> On Tue, Jun 22, 2010 at 3:04 PM, Andrew Bruno <an...@gmail.com> wrote:
>> Hi Yasushi
>>
>> In your serverl.xml have you added the jvmroute to the Engine?
>>
>> i.e.
>>
>> <Engine name="Catalina" defaultHost="localhost" jvmRoute="1">
>>
>> Andrew
>>
>> On Tue, Jun 22, 2010 at 2:50 PM, Okubo, Yasushi (TSD) <Ya...@takedasd.com> wrote:
>>> Hi Andrew
>>>
>>> Thank for your post. When I checked the session id from firefox, sso session id [jsessionidsso] does not have jvmroute info, but only jsessionid has jvmroute. So, session replication upon failover is working fine, but singlesionon upon failover is not working on tomcat 6.0.x (including 6.0.26).
>>>
>>> yasushi
>>>
>>> -----Original Message-----
>>> From: Andrew Bruno [mailto:andrew.bruno@gmail.com]
>>> Sent: Monday, June 21, 2010 9:18 PM
>>> To: Tomcat Users List
>>> Subject: Re: question for sso session replication in tomcat 6.0.26
>>>
>>> Looking at the code I think this is wrong
>>>
>>> if (!_ssoSessionId.contains("." + jvmRoute)) {
>>> _ssoSessionId += "." + jvmRoute;
>>> response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME, _ssoSessionId));
>>> }
>>>
>>> The original sessionId will already have the "."+_any_other_jvmRoute
>>> included, so you need to substring it, and append the new jvmRoute.
>>>
>>> _ssoSessionId= _ssoSessionId.substring(0, _ssoSessionId.indexOf("."))
>>>
>>> and then add
>>>
>>> _ssoSessionId += "." + jvmRoute;
>>>
>>> AB
>>>
>>> On Tue, Jun 22, 2010 at 1:03 PM, Okubo, Yasushi (TSD)
>>> <Ya...@takedasd.com> wrote:
>>>> Hi experts
>>>>
>>>>
>>>>
>>>> I found this old email from archive in TC 5.5.23.
>>>>
>>>> Does this problem still exist in tomcat 6.0.x or 6.0.26?
>>>>
>>>>
>>>>
>>>> When failover occurs, sso session id is updated with new number after
>>>> forcing a user to relogin to the application since sso session id is not
>>>> replicated and rewritten correctly. Could someone explain what is
>>>> expected in current tomcat 6.0.x cluster upon failover? Should sso
>>>> session id is replicated correctly in tomcat 6.0.x?
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> yasushi
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ROOKIE wrote:
>>>> Hi,
>>>> I have a problem with tomcat cluster + mod_proxy load balancer :
>>>>
>>>> We have a main app which authenticate itself to a webapp and from this
>>>> app one
>>>> can launch embedded apps which use the SSO cookie to access other
>>>> webapps on
>>>> the server (Single-Sign-On for the user).
>>>>
>>>> Things are working perfectly for the normal cookie but not for the sso
>>>> cookie.
>>>>
>>>>
>>>> The problem I have is that tomcat does not replicate SSO sessions so
>>>> when these embedded apps route through the load balancer we get 401s on
>>>> all the other cluster members except the one which actually generated
>>>> the SSO cookie.
>>>>
>>>> I wanted to know if we can edit the SSO cookie generated by tomcat to
>>>> also
>>>> contain the jvmRoute parameter so that the load balancer directly goes
>>>> to the
>>>> correct cluster member.
>>>>
>>>>
>>>> I tried doing this in my code by fetching the SSO cookie and appending
>>>> to it
>>>> the jvmRoute as follows :
>>>>
>>>> HttpServletRequest request =
>>>> (HttpServletRequest)Security.getContext(HttpServletRequest.class);
>>>> HttpServletResponse response =
>>>> (HttpServletResponse)Security.getContext(HttpServletResponse.class);
>>>> if(request != null) {
>>>> String jvmRoute = "Vinod_Cluster_1"; // as mentioned in
>>>> server.xml
>>>> Cookie[] cookies = request.getCookies();
>>>> for(int nc=0; cookies != null && nc < cookies.length; nc++)
>>>> {
>>>> if(_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
>>>> _sessionId = cookies[nc].getValue();
>>>> }
>>>>
>>>> else if(_SSO_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
>>>>
>>>> _ssoSessionId = cookies[nc].getValue();
>>>> if (!_ssoSessionId.contains("." + jvmRoute)) {
>>>> _ssoSessionId += "." + jvmRoute;
>>>>
>>>> response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME, _ssoSessionId));
>>>> }
>>>>
>>>>
>>>> }
>>>>
>>>>
>>>> But after this I started getting 401s from even the correct cluster
>>>> member. My guess is addCookie doesnt update the cookie in tomcat's cache
>>>> which is reasonable.
>>>>
>>>> Other thought was to edit tomcat's sso cookie generation code to append
>>>> the
>>>> jvmRoute to the sso cookie.
>>>>
>>>>
>>>> Is there an better way to achieve this in my code base ?
>>>>
>>>> Thanks In Advance,
>>>> Vinod
>>>>
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
RE: question for sso session replication in tomcat 6.0.26
Posted by "Okubo, Yasushi (TSD)" <Ya...@takedasd.com>.
Hi Andrew
In case of no failover, SSO works for all web applications on the same host. Upon failover [shutting down one node], a user is routed to the other node, and TC is asking for a user to re-login when he/she tried to access password protected area.
I have checked many times on server.xml and session replication is working fine upon failover, so I cannot think any misconfiguration on server.xml
The issue is SSO failover is not working. I think it might be related to my apache virtual host setup, but could not figure it out.
Thanks for your help,
yasushi
I am using mod_proxy_ajp, mod_proxy_balancer [v2.2.3]
OS : Redhat Linux 64bit RHEL v5.5
JDK : 1.6.0.20
=== I created virtual host on port 9050 ==
Httpd.conf
<VirtualHost 10.250.200.57:9050>
ServerAdmin xyz
ServerName webclust1.xyz.com
ServerAlias webclust1
ErrorLog logs/webclust_cluster_error.log
CustomLog logs/webclust-cluster-access_log common
<Location /balancer-manager>
SetHandler balancer-manager
Order Deny,Allow
Deny from all
Allow from all
</Location>
ProxyRequests off
<Proxy balancer://webclust>
BalancerMember ajp://10.250.200.57:9001 loadfactor=10 max=150 smax=145 route=jvm1
BalancerMember ajp://10.250.200.57:9002 loadfactor=10 max=150 smax=145 route=jvm2
BalancerMember ajp://10.250.200.57:9003 loadfactor=10 max=150 smax=145 route=jvm3
Order Deny,Allow
Allow from all
</Proxy>
#Do not proxy balancer-manager
ProxyPass /balancer-manager !
<Location /examples>
ProxyPass balancer://webclust/examples stickysession=JSESSIONID|jsessionid
ProxyPassReverse balancer://webclust/examples
Order Deny,Allow
Allow from all
</Location>
<Location / >
ProxyPass balancer://webclust/ stickysession=JSESSIONID|jsessionid
ProxyPassReverse balancer://webclust/
Order Deny,Allow
Allow from all
</Location>
=== server.xml ===
<!-- Define an AJP 1.3 Connector on port 8009 -->
<Connector port="9002" protocol="AJP/1.3" redirectPort="8443" />
<Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1">
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true"
xmlValidation="false" xmlNamespaceAware="false">
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
channelSendOptions="4">
<Manager className="org.apache.catalina.ha.session.DeltaManager"
name="node2"
expireSessionsOnShutdown="false"
notifyListenersOnReplication="true"/>
<Channel className="org.apache.catalina.tribes.group.GroupChannel">
<Membership className="org.apache.catalina.tribes.membership.McastService"
address="228.0.0.5"
port="45564"
frequency="500"
dropTime="3000"/>
<Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
address="auto"
port="4020"
autoBind="100"
selectorTimeout="5000"
maxThreads="12"/>
<Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
<Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
</Sender>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor"/>
</Channel>
<Valve className="org.apache.catalina.ha.tcp.ReplicationValve"
filter=".*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;.*\.xls;.*\.sdf;.*\.xml;"/>
<!-- only with jk_mod failover-->
<Valve className="org.apache.catalina.ha.session.JvmRouteBinderValve"
enabled="true" sessionIdAttribute="takeoverSessionid" />
<!--
<Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer"
tempDir="/tmp/war-temp/"
deployDir="/usr/local/apache/node2-tomcat-6.0.26/webapps"
watchDir="/tmp/war-listen/"
watchEnabled="true"/>
-->
<!-- only with jk_mod and jvmroutebindervalve-->
<ClusterListener className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/>
<ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>
</Cluster>
<Valve className="org.apache.catalina.ha.authenticator.ClusterSingleSignOn" />
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
prefix="webappqa_node2_access_log." suffix=".log" pattern="common" resolveHosts="false"/>
</Host>
</Engine>
-----Original Message-----
From: Andrew Bruno [mailto:andrew.bruno@gmail.com]
Sent: Monday, June 21, 2010 10:09 PM
To: Tomcat Users List
Subject: Re: question for sso session replication in tomcat 6.0.26
Oh sorry, I re-read your answer. Not sure why SSO is not working, be
interested to find out though..
AB
On Tue, Jun 22, 2010 at 3:04 PM, Andrew Bruno <an...@gmail.com> wrote:
> Hi Yasushi
>
> In your serverl.xml have you added the jvmroute to the Engine?
>
> i.e.
>
> <Engine name="Catalina" defaultHost="localhost" jvmRoute="1">
>
> Andrew
>
> On Tue, Jun 22, 2010 at 2:50 PM, Okubo, Yasushi (TSD) <Ya...@takedasd.com> wrote:
>> Hi Andrew
>>
>> Thank for your post. When I checked the session id from firefox, sso session id [jsessionidsso] does not have jvmroute info, but only jsessionid has jvmroute. So, session replication upon failover is working fine, but singlesionon upon failover is not working on tomcat 6.0.x (including 6.0.26).
>>
>> yasushi
>>
>> -----Original Message-----
>> From: Andrew Bruno [mailto:andrew.bruno@gmail.com]
>> Sent: Monday, June 21, 2010 9:18 PM
>> To: Tomcat Users List
>> Subject: Re: question for sso session replication in tomcat 6.0.26
>>
>> Looking at the code I think this is wrong
>>
>> if (!_ssoSessionId.contains("." + jvmRoute)) {
>> _ssoSessionId += "." + jvmRoute;
>> response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME, _ssoSessionId));
>> }
>>
>> The original sessionId will already have the "."+_any_other_jvmRoute
>> included, so you need to substring it, and append the new jvmRoute.
>>
>> _ssoSessionId= _ssoSessionId.substring(0, _ssoSessionId.indexOf("."))
>>
>> and then add
>>
>> _ssoSessionId += "." + jvmRoute;
>>
>> AB
>>
>> On Tue, Jun 22, 2010 at 1:03 PM, Okubo, Yasushi (TSD)
>> <Ya...@takedasd.com> wrote:
>>> Hi experts
>>>
>>>
>>>
>>> I found this old email from archive in TC 5.5.23.
>>>
>>> Does this problem still exist in tomcat 6.0.x or 6.0.26?
>>>
>>>
>>>
>>> When failover occurs, sso session id is updated with new number after
>>> forcing a user to relogin to the application since sso session id is not
>>> replicated and rewritten correctly. Could someone explain what is
>>> expected in current tomcat 6.0.x cluster upon failover? Should sso
>>> session id is replicated correctly in tomcat 6.0.x?
>>>
>>>
>>>
>>> Thanks,
>>>
>>> yasushi
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ROOKIE wrote:
>>> Hi,
>>> I have a problem with tomcat cluster + mod_proxy load balancer :
>>>
>>> We have a main app which authenticate itself to a webapp and from this
>>> app one
>>> can launch embedded apps which use the SSO cookie to access other
>>> webapps on
>>> the server (Single-Sign-On for the user).
>>>
>>> Things are working perfectly for the normal cookie but not for the sso
>>> cookie.
>>>
>>>
>>> The problem I have is that tomcat does not replicate SSO sessions so
>>> when these embedded apps route through the load balancer we get 401s on
>>> all the other cluster members except the one which actually generated
>>> the SSO cookie.
>>>
>>> I wanted to know if we can edit the SSO cookie generated by tomcat to
>>> also
>>> contain the jvmRoute parameter so that the load balancer directly goes
>>> to the
>>> correct cluster member.
>>>
>>>
>>> I tried doing this in my code by fetching the SSO cookie and appending
>>> to it
>>> the jvmRoute as follows :
>>>
>>> HttpServletRequest request =
>>> (HttpServletRequest)Security.getContext(HttpServletRequest.class);
>>> HttpServletResponse response =
>>> (HttpServletResponse)Security.getContext(HttpServletResponse.class);
>>> if(request != null) {
>>> String jvmRoute = "Vinod_Cluster_1"; // as mentioned in
>>> server.xml
>>> Cookie[] cookies = request.getCookies();
>>> for(int nc=0; cookies != null && nc < cookies.length; nc++)
>>> {
>>> if(_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
>>> _sessionId = cookies[nc].getValue();
>>> }
>>>
>>> else if(_SSO_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
>>>
>>> _ssoSessionId = cookies[nc].getValue();
>>> if (!_ssoSessionId.contains("." + jvmRoute)) {
>>> _ssoSessionId += "." + jvmRoute;
>>>
>>> response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME, _ssoSessionId));
>>> }
>>>
>>>
>>> }
>>>
>>>
>>> But after this I started getting 401s from even the correct cluster
>>> member. My guess is addCookie doesnt update the cookie in tomcat's cache
>>> which is reasonable.
>>>
>>> Other thought was to edit tomcat's sso cookie generation code to append
>>> the
>>> jvmRoute to the sso cookie.
>>>
>>>
>>> Is there an better way to achieve this in my code base ?
>>>
>>> Thanks In Advance,
>>> Vinod
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: question for sso session replication in tomcat 6.0.26
Posted by Andrew Bruno <an...@gmail.com>.
Oh sorry, I re-read your answer. Not sure why SSO is not working, be
interested to find out though..
AB
On Tue, Jun 22, 2010 at 3:04 PM, Andrew Bruno <an...@gmail.com> wrote:
> Hi Yasushi
>
> In your serverl.xml have you added the jvmroute to the Engine?
>
> i.e.
>
> <Engine name="Catalina" defaultHost="localhost" jvmRoute="1">
>
> Andrew
>
> On Tue, Jun 22, 2010 at 2:50 PM, Okubo, Yasushi (TSD) <Ya...@takedasd.com> wrote:
>> Hi Andrew
>>
>> Thank for your post. When I checked the session id from firefox, sso session id [jsessionidsso] does not have jvmroute info, but only jsessionid has jvmroute. So, session replication upon failover is working fine, but singlesionon upon failover is not working on tomcat 6.0.x (including 6.0.26).
>>
>> yasushi
>>
>> -----Original Message-----
>> From: Andrew Bruno [mailto:andrew.bruno@gmail.com]
>> Sent: Monday, June 21, 2010 9:18 PM
>> To: Tomcat Users List
>> Subject: Re: question for sso session replication in tomcat 6.0.26
>>
>> Looking at the code I think this is wrong
>>
>> if (!_ssoSessionId.contains("." + jvmRoute)) {
>> _ssoSessionId += "." + jvmRoute;
>> response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME, _ssoSessionId));
>> }
>>
>> The original sessionId will already have the "."+_any_other_jvmRoute
>> included, so you need to substring it, and append the new jvmRoute.
>>
>> _ssoSessionId= _ssoSessionId.substring(0, _ssoSessionId.indexOf("."))
>>
>> and then add
>>
>> _ssoSessionId += "." + jvmRoute;
>>
>> AB
>>
>> On Tue, Jun 22, 2010 at 1:03 PM, Okubo, Yasushi (TSD)
>> <Ya...@takedasd.com> wrote:
>>> Hi experts
>>>
>>>
>>>
>>> I found this old email from archive in TC 5.5.23.
>>>
>>> Does this problem still exist in tomcat 6.0.x or 6.0.26?
>>>
>>>
>>>
>>> When failover occurs, sso session id is updated with new number after
>>> forcing a user to relogin to the application since sso session id is not
>>> replicated and rewritten correctly. Could someone explain what is
>>> expected in current tomcat 6.0.x cluster upon failover? Should sso
>>> session id is replicated correctly in tomcat 6.0.x?
>>>
>>>
>>>
>>> Thanks,
>>>
>>> yasushi
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ROOKIE wrote:
>>> Hi,
>>> I have a problem with tomcat cluster + mod_proxy load balancer :
>>>
>>> We have a main app which authenticate itself to a webapp and from this
>>> app one
>>> can launch embedded apps which use the SSO cookie to access other
>>> webapps on
>>> the server (Single-Sign-On for the user).
>>>
>>> Things are working perfectly for the normal cookie but not for the sso
>>> cookie.
>>>
>>>
>>> The problem I have is that tomcat does not replicate SSO sessions so
>>> when these embedded apps route through the load balancer we get 401s on
>>> all the other cluster members except the one which actually generated
>>> the SSO cookie.
>>>
>>> I wanted to know if we can edit the SSO cookie generated by tomcat to
>>> also
>>> contain the jvmRoute parameter so that the load balancer directly goes
>>> to the
>>> correct cluster member.
>>>
>>>
>>> I tried doing this in my code by fetching the SSO cookie and appending
>>> to it
>>> the jvmRoute as follows :
>>>
>>> HttpServletRequest request =
>>> (HttpServletRequest)Security.getContext(HttpServletRequest.class);
>>> HttpServletResponse response =
>>> (HttpServletResponse)Security.getContext(HttpServletResponse.class);
>>> if(request != null) {
>>> String jvmRoute = "Vinod_Cluster_1"; // as mentioned in
>>> server.xml
>>> Cookie[] cookies = request.getCookies();
>>> for(int nc=0; cookies != null && nc < cookies.length; nc++)
>>> {
>>> if(_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
>>> _sessionId = cookies[nc].getValue();
>>> }
>>>
>>> else if(_SSO_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
>>>
>>> _ssoSessionId = cookies[nc].getValue();
>>> if (!_ssoSessionId.contains("." + jvmRoute)) {
>>> _ssoSessionId += "." + jvmRoute;
>>>
>>> response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME, _ssoSessionId));
>>> }
>>>
>>>
>>> }
>>>
>>>
>>> But after this I started getting 401s from even the correct cluster
>>> member. My guess is addCookie doesnt update the cookie in tomcat's cache
>>> which is reasonable.
>>>
>>> Other thought was to edit tomcat's sso cookie generation code to append
>>> the
>>> jvmRoute to the sso cookie.
>>>
>>>
>>> Is there an better way to achieve this in my code base ?
>>>
>>> Thanks In Advance,
>>> Vinod
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: question for sso session replication in tomcat 6.0.26
Posted by Andrew Bruno <an...@gmail.com>.
Hi Yasushi
In your serverl.xml have you added the jvmroute to the Engine?
i.e.
<Engine name="Catalina" defaultHost="localhost" jvmRoute="1">
Andrew
On Tue, Jun 22, 2010 at 2:50 PM, Okubo, Yasushi (TSD)
<Ya...@takedasd.com> wrote:
> Hi Andrew
>
> Thank for your post. When I checked the session id from firefox, sso session id [jsessionidsso] does not have jvmroute info, but only jsessionid has jvmroute. So, session replication upon failover is working fine, but singlesionon upon failover is not working on tomcat 6.0.x (including 6.0.26).
>
> yasushi
>
> -----Original Message-----
> From: Andrew Bruno [mailto:andrew.bruno@gmail.com]
> Sent: Monday, June 21, 2010 9:18 PM
> To: Tomcat Users List
> Subject: Re: question for sso session replication in tomcat 6.0.26
>
> Looking at the code I think this is wrong
>
> if (!_ssoSessionId.contains("." + jvmRoute)) {
> _ssoSessionId += "." + jvmRoute;
> response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME, _ssoSessionId));
> }
>
> The original sessionId will already have the "."+_any_other_jvmRoute
> included, so you need to substring it, and append the new jvmRoute.
>
> _ssoSessionId= _ssoSessionId.substring(0, _ssoSessionId.indexOf("."))
>
> and then add
>
> _ssoSessionId += "." + jvmRoute;
>
> AB
>
> On Tue, Jun 22, 2010 at 1:03 PM, Okubo, Yasushi (TSD)
> <Ya...@takedasd.com> wrote:
>> Hi experts
>>
>>
>>
>> I found this old email from archive in TC 5.5.23.
>>
>> Does this problem still exist in tomcat 6.0.x or 6.0.26?
>>
>>
>>
>> When failover occurs, sso session id is updated with new number after
>> forcing a user to relogin to the application since sso session id is not
>> replicated and rewritten correctly. Could someone explain what is
>> expected in current tomcat 6.0.x cluster upon failover? Should sso
>> session id is replicated correctly in tomcat 6.0.x?
>>
>>
>>
>> Thanks,
>>
>> yasushi
>>
>>
>>
>>
>>
>>
>>
>> ROOKIE wrote:
>> Hi,
>> I have a problem with tomcat cluster + mod_proxy load balancer :
>>
>> We have a main app which authenticate itself to a webapp and from this
>> app one
>> can launch embedded apps which use the SSO cookie to access other
>> webapps on
>> the server (Single-Sign-On for the user).
>>
>> Things are working perfectly for the normal cookie but not for the sso
>> cookie.
>>
>>
>> The problem I have is that tomcat does not replicate SSO sessions so
>> when these embedded apps route through the load balancer we get 401s on
>> all the other cluster members except the one which actually generated
>> the SSO cookie.
>>
>> I wanted to know if we can edit the SSO cookie generated by tomcat to
>> also
>> contain the jvmRoute parameter so that the load balancer directly goes
>> to the
>> correct cluster member.
>>
>>
>> I tried doing this in my code by fetching the SSO cookie and appending
>> to it
>> the jvmRoute as follows :
>>
>> HttpServletRequest request =
>> (HttpServletRequest)Security.getContext(HttpServletRequest.class);
>> HttpServletResponse response =
>> (HttpServletResponse)Security.getContext(HttpServletResponse.class);
>> if(request != null) {
>> String jvmRoute = "Vinod_Cluster_1"; // as mentioned in
>> server.xml
>> Cookie[] cookies = request.getCookies();
>> for(int nc=0; cookies != null && nc < cookies.length; nc++)
>> {
>> if(_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
>> _sessionId = cookies[nc].getValue();
>> }
>>
>> else if(_SSO_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
>>
>> _ssoSessionId = cookies[nc].getValue();
>> if (!_ssoSessionId.contains("." + jvmRoute)) {
>> _ssoSessionId += "." + jvmRoute;
>>
>> response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME, _ssoSessionId));
>> }
>>
>>
>> }
>>
>>
>> But after this I started getting 401s from even the correct cluster
>> member. My guess is addCookie doesnt update the cookie in tomcat's cache
>> which is reasonable.
>>
>> Other thought was to edit tomcat's sso cookie generation code to append
>> the
>> jvmRoute to the sso cookie.
>>
>>
>> Is there an better way to achieve this in my code base ?
>>
>> Thanks In Advance,
>> Vinod
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: question for sso session replication in tomcat 6.0.26
Posted by "Okubo, Yasushi (TSD)" <Ya...@takedasd.com>.
Hi Andrew
Thank for your post. When I checked the session id from firefox, sso session id [jsessionidsso] does not have jvmroute info, but only jsessionid has jvmroute. So, session replication upon failover is working fine, but singlesionon upon failover is not working on tomcat 6.0.x (including 6.0.26).
yasushi
-----Original Message-----
From: Andrew Bruno [mailto:andrew.bruno@gmail.com]
Sent: Monday, June 21, 2010 9:18 PM
To: Tomcat Users List
Subject: Re: question for sso session replication in tomcat 6.0.26
Looking at the code I think this is wrong
if (!_ssoSessionId.contains("." + jvmRoute)) {
_ssoSessionId += "." + jvmRoute;
response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME, _ssoSessionId));
}
The original sessionId will already have the "."+_any_other_jvmRoute
included, so you need to substring it, and append the new jvmRoute.
_ssoSessionId= _ssoSessionId.substring(0, _ssoSessionId.indexOf("."))
and then add
_ssoSessionId += "." + jvmRoute;
AB
On Tue, Jun 22, 2010 at 1:03 PM, Okubo, Yasushi (TSD)
<Ya...@takedasd.com> wrote:
> Hi experts
>
>
>
> I found this old email from archive in TC 5.5.23.
>
> Does this problem still exist in tomcat 6.0.x or 6.0.26?
>
>
>
> When failover occurs, sso session id is updated with new number after
> forcing a user to relogin to the application since sso session id is not
> replicated and rewritten correctly. Could someone explain what is
> expected in current tomcat 6.0.x cluster upon failover? Should sso
> session id is replicated correctly in tomcat 6.0.x?
>
>
>
> Thanks,
>
> yasushi
>
>
>
>
>
>
>
> ROOKIE wrote:
> Hi,
> I have a problem with tomcat cluster + mod_proxy load balancer :
>
> We have a main app which authenticate itself to a webapp and from this
> app one
> can launch embedded apps which use the SSO cookie to access other
> webapps on
> the server (Single-Sign-On for the user).
>
> Things are working perfectly for the normal cookie but not for the sso
> cookie.
>
>
> The problem I have is that tomcat does not replicate SSO sessions so
> when these embedded apps route through the load balancer we get 401s on
> all the other cluster members except the one which actually generated
> the SSO cookie.
>
> I wanted to know if we can edit the SSO cookie generated by tomcat to
> also
> contain the jvmRoute parameter so that the load balancer directly goes
> to the
> correct cluster member.
>
>
> I tried doing this in my code by fetching the SSO cookie and appending
> to it
> the jvmRoute as follows :
>
> HttpServletRequest request =
> (HttpServletRequest)Security.getContext(HttpServletRequest.class);
> HttpServletResponse response =
> (HttpServletResponse)Security.getContext(HttpServletResponse.class);
> if(request != null) {
> String jvmRoute = "Vinod_Cluster_1"; // as mentioned in
> server.xml
> Cookie[] cookies = request.getCookies();
> for(int nc=0; cookies != null && nc < cookies.length; nc++)
> {
> if(_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
> _sessionId = cookies[nc].getValue();
> }
>
> else if(_SSO_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
>
> _ssoSessionId = cookies[nc].getValue();
> if (!_ssoSessionId.contains("." + jvmRoute)) {
> _ssoSessionId += "." + jvmRoute;
>
> response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME, _ssoSessionId));
> }
>
>
> }
>
>
> But after this I started getting 401s from even the correct cluster
> member. My guess is addCookie doesnt update the cookie in tomcat's cache
> which is reasonable.
>
> Other thought was to edit tomcat's sso cookie generation code to append
> the
> jvmRoute to the sso cookie.
>
>
> Is there an better way to achieve this in my code base ?
>
> Thanks In Advance,
> Vinod
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: question for sso session replication in tomcat 6.0.26
Posted by Andrew Bruno <an...@gmail.com>.
Looking at the code I think this is wrong
if (!_ssoSessionId.contains("." + jvmRoute)) {
_ssoSessionId += "." + jvmRoute;
response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME, _ssoSessionId));
}
The original sessionId will already have the "."+_any_other_jvmRoute
included, so you need to substring it, and append the new jvmRoute.
_ssoSessionId= _ssoSessionId.substring(0, _ssoSessionId.indexOf("."))
and then add
_ssoSessionId += "." + jvmRoute;
AB
On Tue, Jun 22, 2010 at 1:03 PM, Okubo, Yasushi (TSD)
<Ya...@takedasd.com> wrote:
> Hi experts
>
>
>
> I found this old email from archive in TC 5.5.23.
>
> Does this problem still exist in tomcat 6.0.x or 6.0.26?
>
>
>
> When failover occurs, sso session id is updated with new number after
> forcing a user to relogin to the application since sso session id is not
> replicated and rewritten correctly. Could someone explain what is
> expected in current tomcat 6.0.x cluster upon failover? Should sso
> session id is replicated correctly in tomcat 6.0.x?
>
>
>
> Thanks,
>
> yasushi
>
>
>
>
>
>
>
> ROOKIE wrote:
> Hi,
> I have a problem with tomcat cluster + mod_proxy load balancer :
>
> We have a main app which authenticate itself to a webapp and from this
> app one
> can launch embedded apps which use the SSO cookie to access other
> webapps on
> the server (Single-Sign-On for the user).
>
> Things are working perfectly for the normal cookie but not for the sso
> cookie.
>
>
> The problem I have is that tomcat does not replicate SSO sessions so
> when these embedded apps route through the load balancer we get 401s on
> all the other cluster members except the one which actually generated
> the SSO cookie.
>
> I wanted to know if we can edit the SSO cookie generated by tomcat to
> also
> contain the jvmRoute parameter so that the load balancer directly goes
> to the
> correct cluster member.
>
>
> I tried doing this in my code by fetching the SSO cookie and appending
> to it
> the jvmRoute as follows :
>
> HttpServletRequest request =
> (HttpServletRequest)Security.getContext(HttpServletRequest.class);
> HttpServletResponse response =
> (HttpServletResponse)Security.getContext(HttpServletResponse.class);
> if(request != null) {
> String jvmRoute = "Vinod_Cluster_1"; // as mentioned in
> server.xml
> Cookie[] cookies = request.getCookies();
> for(int nc=0; cookies != null && nc < cookies.length; nc++)
> {
> if(_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
> _sessionId = cookies[nc].getValue();
> }
>
> else if(_SSO_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
>
> _ssoSessionId = cookies[nc].getValue();
> if (!_ssoSessionId.contains("." + jvmRoute)) {
> _ssoSessionId += "." + jvmRoute;
>
> response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME, _ssoSessionId));
> }
>
>
> }
>
>
> But after this I started getting 401s from even the correct cluster
> member. My guess is addCookie doesnt update the cookie in tomcat's cache
> which is reasonable.
>
> Other thought was to edit tomcat's sso cookie generation code to append
> the
> jvmRoute to the sso cookie.
>
>
> Is there an better way to achieve this in my code base ?
>
> Thanks In Advance,
> Vinod
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org