You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2015/02/04 01:23:56 UTC
[Bug 57532] New: Session expire message sent to cluster nodes even
with DeltaSession configuration not to
https://issues.apache.org/bugzilla/show_bug.cgi?id=57532
Bug ID: 57532
Summary: Session expire message sent to cluster nodes even with
DeltaSession configuration not to
Product: Tomcat 7
Version: 7.0.42
Hardware: PC
OS: Linux
Status: NEW
Severity: major
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: andrew.jardine@jardineworks.com
Hi, - I suppose whether or not this is a bug depends on how you interpret it. I
am using Tomcat 7.0.42 but I have also tried building all the way up to Tomcat
7.0.57 to see if any changes were made but to date nothing has.
My cluster configuration using the DeltaManager for session replication. I am
using a multi-cast configuration rather than fixed nodes. My manager is
configured as follows --
<Manager className="org.apache.catalina.ha.session.DeltaManager"
expireSessionsOnShutdown="false"
notifyListenersOnReplication="true"
/>
.. the most important being that I don't want sessions to expire on shutdown.
My interpretation of this is that in a controlled shut down scenario whereby I
initiate a proper shutdown of Node A in an A, B, C cluster, that the server
will be shut down and the sessions on A retained on B and C. This works as
expected for any session that is not marked as Primary on the node that is
being shut down. Primary flagged sessions however are causing a message to be
sent to all nodes in the cluster causing the sessions to be lost. If the server
(process) is killed no sessions are lost.
I traced this issue back to the following scenario.
In the StandardManager when a shutdown event occurs it is calling a
session.expire(true). Since we have configured the DeltaSession as our
implementation class I logically went there. the expire( boolean ) method in
that class simply makes a call to an overloaded expire( boolean, boolean )
version where the second argument is statically passed as true. The second
argument in the overloaded method is used as a flag to determine whether or not
to notifyCluster.
I forked the project (Tomcat 7.0.57 branch) and update the DeltaSession.expire(
boolean ) method to use the following logic instead --
/**
* Perform the internal processing required to invalidate this session,
* without triggering an exception if the session has already expired.
*
* @param notify
* Should we notify listeners about the demise of this session?
*/
@Override
public void expire(boolean notify) {
boolean notifyCluster = true;
if ( manager instanceof DeltaManager )
notifyCluster =
((DeltaManager)manager).isExpireSessionsOnShutdown();
expire( notify, notifyCluster );
}
.. which allows me to preserve the same configuration for all Session managers
except the Delta configuration. I built this code and replaced my binaries and
have confirmed that with this logic, session expire is not communicated during
shutdown events to the cluster.
To me this seems like a defect which is why I am submitting this as an issue.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57532] Session expire message sent to cluster nodes even with
DeltaSession configuration not to
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=57532
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |RESOLVED
Resolution|--- |INVALID
--- Comment #5 from Mark Thomas <ma...@apache.org> ---
You are missing:
<ClusterListener
className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener">
I've just confirmed with my 4-node test cluster and the latest 7.0.x code that
- providing this is present - the sessions fail over correctly when the current
primary node is shutdown gracefully.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57532] Session expire message sent to cluster nodes even with
DeltaSession configuration not to
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=57532
--- Comment #2 from andrew jardine <an...@jardineworks.com> ---
Hey Mark,
I'll try to grab those details for you. All I can say for the moment is that if
I set a breakpoint in the DeltaManager class for the expire(boolean) method,
then during shutdown it hits. The only way I was able to preserve my session
replication was to modify that method. Perhaps I have configured my cluster
incorrectly? -- here is my configuration. I'll try to find some time this
weekend to get a thread dump for you.
server.xml --
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
channelSendOptions="6">
<Manager className="org.apache.catalina.ha.session.DeltaManager"
expireSessionsOnShutdown="false"
notifyListenersOnReplication="true"/>
<Channel className="org.apache.catalina.tribes.group.GroupChannel">
<Membership
className="org.apache.catalina.tribes.membership.McastService"
address="224.5.0.1"
port="45564"
frequency="500"
dropTime="3000"/>
<Receiver
className="org.apache.catalina.tribes.transport.nio.NioReceiver"
address="auto"
port="4000"
selectorTimeout="5000"
maxThreads="25"/>
<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>
<ClusterListener
className="org.apache.catalina.ha.session.ClusterSessionListener"/>
</Cluster>
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57532] Session expire message sent to cluster nodes even with
DeltaSession configuration not to
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=57532
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
--- Comment #1 from Mark Thomas <ma...@apache.org> ---
StandardManager should be irrelevant since it isn't used for clustered web
applications. The web application should be using DeltaManager.
On shutdown DeltaManager calls to two argument version of Session.expire() with
the second argument set depending on expireSessionsOnShutdown.
I'd like to see a stack trace that shows where the call to
DeltaSession.expire() is coming from.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57532] Session expire message sent to cluster nodes even with
DeltaSession configuration not to
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=57532
--- Comment #4 from andrew jardine <an...@jardineworks.com> ---
I have tried this with 2 nodes all the way up to 5 nodes -- all configured the
same, all the same results. The odd thing is that it only seems to affect
sessions that are marked as Primary on the node that is being shut down. For
example.
Node A Node B
session 1 (primary) session 1
session 2 session 2 (primary)
session 3 session 3 (primary)
session 4 (primary) session 4
session 5 (primary) session 5
If at this point I shutdown Node B, then session 2 and session 3 on Node A will
be destroyed leaving me with -
Node A Node B
session 1 (primary)
session 4 (primary)
session 5 (primary)
... but all nodes that were not primary do not appear to be sending the
"SESSION EXPIRE" message to the cluster.
I'll try to get that thread dump for you when I get a bit of breathing room at
work.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57532] Session expire message sent to cluster nodes even with
DeltaSession configuration not to
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=57532
andrew jardine <an...@jardineworks.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |APIBug
CC| |andrew.jardine@jardineworks
| |.com
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57532] Session expire message sent to cluster nodes even with
DeltaSession configuration not to
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=57532
--- Comment #3 from Christopher Schultz <ch...@christopherschultz.net> ---
(In reply to andrew jardine from comment #2)
> Perhaps I have configured my cluster incorrectly? -- here is my configuration.
>
> [snip]
You need N > 0 nodes to make a cluster. Are they all configured identically?
Maybe you have one of them still running BackupManager.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org