Re: question for sso session replication in tomcat 6.0.26
On 13/07/2010 21:58, Okubo, Yasushi (TSD) wrote: -Original Message- From: Pid [mailto:p...@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 signature.asc Description: OpenPGP digital signature
RE: question for sso session replication in tomcat 6.0.26
-Original Message- From: Pid [mailto:p...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: question for sso session replication in tomcat 6.0.26
-Original Message-
From: Pid [mailto:p...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
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]
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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: question for sso session replication in tomcat 6.0.26
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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: question for sso session replication in tomcat 6.0.26
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:p...@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=dynprop=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
Re: question for sso session replication in tomcat 6.0.26
- 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:p...@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=dynprop=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
RE: question for sso session replication in tomcat 6.0.26
Yes, I do.
Manager className=org.apache.catalina.ha.session.DeltaManager
name=webclust2
expireSessionsOnShutdown=false
-Original Message-
From: Pid [mailto:p...@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.selectionkeyi...@1bd7b222
Jun 28, 2010 10:27:40 AM
org.apache.catalina.tribes.transport.nio.NioReplicationTask run
FINER: Servicing key:sun.nio.ch.selectionkeyi...@1bd7b222
Jun 28, 2010 10:27:40 AM
org.apache.catalina.tribes.transport.nio.NioReplicationTask run
FINER: Draining channel:sun.nio.ch.selectionkeyi...@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.selectionkeyi...@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.nioreplicationtas...@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.nioreplicationtas...@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.selectionkeyi...@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
Re: question for sso session replication in tomcat 6.0.26
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:p...@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.selectionkeyi...@1bd7b222
Jun 28, 2010 10:27:40 AM
org.apache.catalina.tribes.transport.nio.NioReplicationTask run
FINER: Servicing key:sun.nio.ch.selectionkeyi...@1bd7b222
Jun 28, 2010 10:27:40 AM
org.apache.catalina.tribes.transport.nio.NioReplicationTask run
FINER: Draining channel:sun.nio.ch.selectionkeyi...@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.selectionkeyi...@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.nioreplicationtas...@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.nioreplicationtas...@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.selectionkeyi...@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
RE: question for sso session replication in tomcat 6.0.26
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:p...@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
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
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:p...@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
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=dynprop=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:p...@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) yasushi.ok...@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.bris...@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:p...@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
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:p...@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) yasushi.ok...@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.bris...@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:p...@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
RE: question for sso session replication in tomcat 6.0.26
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=dynprop=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:p...@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) yasushi.ok...@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.bris...@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:p...@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
RE: question for sso session replication in tomcat 6.0.26
Hi Pid My colleague found that a bunch of undocumented attributes for DeltaManager, and he started using them, then he told me that it looked like sso failover started working. So, I went to tomcat source code (v6.0.26) and checked the options he used. It turned out that sendAllSessionsWaitTime attribute needs to be set to -1. But this trick did not always work. sso failover still does not work in my test cases. Could you tell me the implications for this flag when we set to -1? It looks like DeltaManager will send replication messages all the time continuously. I am not sure if we want to set this flag on production since it still fails sso failover and may cause network issues. Have you found anything yet? yasushi -Original Message- From: Pid [mailto:p...@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) yasushi.ok...@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.bris...@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:p...@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
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) yasushi.ok...@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.bris...@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:p...@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
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:p...@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) yasushi.ok...@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.bris...@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:p...@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
RE: question for sso session replication in tomcat 6.0.26
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:p...@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) yasushi.ok...@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.bris...@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:p...@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
Re: question for sso session replication in tomcat 6.0.26
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 andrew.br...@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)
yasushi.ok...@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.br...@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)
yasushi.ok...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e
RE: question for sso session replication in tomcat 6.0.26
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 andrew.br...@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)
yasushi.ok...@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.br...@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)
yasushi.ok...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h
Re: question for sso session replication in tomcat 6.0.26
=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.br...@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 andrew.br...@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)
yasushi.ok...@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.br...@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)
yasushi.ok...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h
RE: question for sso session replication in tomcat 6.0.26
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.ok...@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
RE: question for sso session replication in tomcat 6.0.26
Ok I will try to install the latest apache httpd and test again. Thanks, yasushi -Original Message- From: Pid [mailto:p...@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
RE: question for sso session replication in tomcat 6.0.26
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:p...@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
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:p...@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
RE: question for sso session replication in tomcat 6.0.26
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.bris...@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:p...@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
RE: question for sso session replication in tomcat 6.0.26
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.br...@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)
yasushi.ok...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
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)
yasushi.ok...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: question for sso session replication in tomcat 6.0.26
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)
yasushi.ok...@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.br...@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)
yasushi.ok...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
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 andrew.br...@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)
yasushi.ok...@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.br...@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)
yasushi.ok...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
