Re: Problems with Clustering / Session Replication
On Oct 25, 2013, at 11:11 AM, Nicholas Violi nvi...@globalgiving.org wrote: On Tue, Sep 24, 2013 at 5:21 PM, Daniel Mikusa dmik...@gopivotal.comwrote: A couple general thoughts... 1.) When looking at log statements at the FINE lower levels, recognize that these are not reporting problems. They just give you the ability to trace the flow of what is happening in the code. If it was a problem, you'd see WARN, ERROR or SEVERE. 2.) If you'd like a second opinion on something you see in the logs, post as much of the logs as possible. If you only post snippets or filter the logs, you might inadvertently filter out something that is important. 3.) Try a different PC, if you have one available. If it works on another PC, start comparing the two to see what is different. 4.) Simplify as much as possible. Start with two fresh Tomcat instance. Add the simplest possible cluster configuration and go from there. https://tomcat.apache.org/tomcat-7.0-doc/cluster-howto.html#For_the_impatient Sorry I can't be of more help. Dan Hi all, Thanks for all your hard work last month on my session replication issue. I think I've found a solution today (via my SO post http://stackoverflow.com/questions/18835014/tomcats-clustering-session-replication-not-replicating-properly/19391515#19391515). The problem appears to be solved by moving the Manager element out of the ServerServiceEngineCluster element in server.xml and putting it instead in the Context element of context.xml. So my context.xml now looks like this: ?xml version='1.0' encoding='utf-8'? !-- The contents of this file will be loaded for each web application -- Context useHttpOnly=true sessionCookiePath=/ xmlValidation=false xmlNamespaceAware=false !-- Default set of monitored resources -- WatchedResourceWEB-INF/web.xml/WatchedResource !-- Clustering / Session replication manager -- Manager className=org.apache.catalina.ha.session.DeltaManager expireSessionsOnShutdown=false notifyListenersOnReplication=true/ /Context And server.xml still has the Cluster element inside Engine, but Cluster no longer has a Manager element: Engine name=Catalina defaultHost=localhost Cluster channelSendOptions=8 className=org.apache.catalina.ha.tcp.SimpleTcpCluster Channel className=org.apache.catalina.tribes.group.GroupChannel Membership address=228.0.0.4 className=org.apache.catalina.tribes.membership.McastService dropTime=3000 frequency=500 port=45564/ Receiver address=auto autoBind=100 className=org.apache.catalina.tribes.transport.nio.NioReceiver maxThreads=6 port=4000 selectorTimeout=5000/ 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/ /Channel Valve className=org.apache.catalina.ha.tcp.ReplicationValve filter=/ Valve className=org.apache.catalina.ha.session.JvmRouteBinderValve/ ClusterListener className=org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener/ ClusterListener className=org.apache.catalina.ha.session.ClusterSessionListener/ /Cluster !-- etc... -- /Engine I'll leave it up to you all to determine if the documentation needs to be updated, or if there's an underlying bug here somewhere, In my opinion, this is unlikely. What you had before should have worked. Is it possible that you had a Manager/ tag defined in conf/context.xml or another context location? From the Cluster Manager tag docs... The Manager element defined inside the Cluster element is the template defined for all web applications that are markeddistributable/ in their web.xml file. However, you can still override the manager implementation on a per web application basis, by putting the Manager inside the Context element either in the context.xml file or the server.xml file. Perhaps you were inadvertently overriding your cluster manager configuration? That would certainly explain the behavior you were and are now seeing. Dan but hopefully this will help anyone with the same problem in the future. Thanks, Nick - To unsubscribe, e-mail:
Re: Problems with Clustering / Session Replication
On Tue, Sep 24, 2013 at 5:21 PM, Daniel Mikusa dmik...@gopivotal.comwrote: A couple general thoughts... 1.) When looking at log statements at the FINE lower levels, recognize that these are not reporting problems. They just give you the ability to trace the flow of what is happening in the code. If it was a problem, you'd see WARN, ERROR or SEVERE. 2.) If you'd like a second opinion on something you see in the logs, post as much of the logs as possible. If you only post snippets or filter the logs, you might inadvertently filter out something that is important. 3.) Try a different PC, if you have one available. If it works on another PC, start comparing the two to see what is different. 4.) Simplify as much as possible. Start with two fresh Tomcat instance. Add the simplest possible cluster configuration and go from there. https://tomcat.apache.org/tomcat-7.0-doc/cluster-howto.html#For_the_impatient Sorry I can't be of more help. Dan Hi all, Thanks for all your hard work last month on my session replication issue. I think I've found a solution today (via my SO post http://stackoverflow.com/questions/18835014/tomcats-clustering-session-replication-not-replicating-properly/19391515#19391515). The problem appears to be solved by moving the Manager element out of the ServerServiceEngineCluster element in server.xml and putting it instead in the Context element of context.xml. So my context.xml now looks like this: ?xml version='1.0' encoding='utf-8'? !-- The contents of this file will be loaded for each web application -- Context useHttpOnly=true sessionCookiePath=/ xmlValidation=false xmlNamespaceAware=false !-- Default set of monitored resources -- WatchedResourceWEB-INF/web.xml/WatchedResource !-- Clustering / Session replication manager -- Manager className=org.apache.catalina.ha.session.DeltaManager expireSessionsOnShutdown=false notifyListenersOnReplication=true/ /Context And server.xml still has the Cluster element inside Engine, but Cluster no longer has a Manager element: Engine name=Catalina defaultHost=localhost Cluster channelSendOptions=8 className=org.apache.catalina.ha.tcp.SimpleTcpCluster Channel className=org.apache.catalina.tribes.group.GroupChannel Membership address=228.0.0.4 className=org.apache.catalina.tribes.membership.McastService dropTime=3000 frequency=500 port=45564/ Receiver address=auto autoBind=100 className=org.apache.catalina.tribes.transport.nio.NioReceiver maxThreads=6 port=4000 selectorTimeout=5000/ 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/ /Channel Valve className=org.apache.catalina.ha.tcp.ReplicationValve filter=/ Valve className=org.apache.catalina.ha.session.JvmRouteBinderValve/ ClusterListener className=org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener/ ClusterListener className=org.apache.catalina.ha.session.ClusterSessionListener/ /Cluster !-- etc... -- /Engine I'll leave it up to you all to determine if the documentation needs to be updated, or if there's an underlying bug here somewhere, but hopefully this will help anyone with the same problem in the future. Thanks, Nick
Re: Problems with Clustering / Session Replication
On Sep 23, 2013, at 4:49 PM, Nicholas Violi nvi...@globalgiving.org wrote:
On Thu, Sep 19, 2013 at 9:03 AM, Daniel Mikusa dmik...@gopivotal.comwrote:
Here's what I've been using:
WEB-INF/web.xml:
?xml version=1.0 encoding=UTF-8?
web-app version=2.5 xmlns=http://java.sun.com/xml/ns/javaee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd;
distributable/
/web-app
index.jsp:
%
Integer count = (Integer) session.getAttribute(counter);
if (count == null) {
count = 0;
session.setAttribute(counter, 0);
} else {
session.setAttribute(counter, count + 1);
}
%
html
head
titleIndex/title
/head
body
h2Session [%= session.getId() %]/h2
pCurrent count is %= count %/p
/body
/html
It's crude, but effective for testing session replication.
Hi, and sorry for the silence; I had a few other things take priority over
this last week, but I've found some time today to test your counter app.
So I'm now cutting out both httpd and my complicated webapp, and still see
no replication of session variables, and nothing in the logs regarding
clustering besides startup/shutdown of nodes in the cluster. Both instances
of the counter app show the same session ID, and both increment (correctly)
independent of each other, but they are not sharing the session variable :(
One possible clue as to what's going on is this log message, that's been
bothering me:
FINE: Received a failure detector
packet:ClusterData[src=org.apache.catalina.tribes.membership.MemberImpl[tcp://{192,
168, 1, 240}:4000,{192, 168, 1, 240},4000, alive=1379968430807,
securePort=-1, UDP Port=-1, id={81 35 97 0 -37 63 71 -104 -102 28 115 6 -51
-24 -24 99 }, payload={}, command={}, domain={}, ]; id={-101 -57 -98 104
-103 31 66 113 -85 -84 -80 -86 14 -2 52 -31 }; sent=2013-09-23 16:33:50.81]
Other than that I'm at a loss on where to go; any suggestions are welcome.
A couple general thoughts...
1.) When looking at log statements at the FINE lower levels, recognize that
these are not reporting problems. They just give you the ability to trace the
flow of what is happening in the code. If it was a problem, you'd see WARN,
ERROR or SEVERE.
2.) If you'd like a second opinion on something you see in the logs, post as
much of the logs as possible. If you only post snippets or filter the logs,
you might inadvertently filter out something that is important.
3.) Try a different PC, if you have one available. If it works on another PC,
start comparing the two to see what is different.
4.) Simplify as much as possible. Start with two fresh Tomcat instance. Add
the simplest possible cluster configuration and go from there.
https://tomcat.apache.org/tomcat-7.0-doc/cluster-howto.html#For_the_impatient
Sorry I can't be of more help.
Dan
Thanks,
Nick
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problems with Clustering / Session Replication
On Thu, Sep 19, 2013 at 9:03 AM, Daniel Mikusa dmik...@gopivotal.comwrote:
Here's what I've been using:
WEB-INF/web.xml:
?xml version=1.0 encoding=UTF-8?
web-app version=2.5 xmlns=http://java.sun.com/xml/ns/javaee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd;
distributable/
/web-app
index.jsp:
%
Integer count = (Integer) session.getAttribute(counter);
if (count == null) {
count = 0;
session.setAttribute(counter, 0);
} else {
session.setAttribute(counter, count + 1);
}
%
html
head
titleIndex/title
/head
body
h2Session [%= session.getId() %]/h2
pCurrent count is %= count %/p
/body
/html
It's crude, but effective for testing session replication.
Hi, and sorry for the silence; I had a few other things take priority over
this last week, but I've found some time today to test your counter app.
So I'm now cutting out both httpd and my complicated webapp, and still see
no replication of session variables, and nothing in the logs regarding
clustering besides startup/shutdown of nodes in the cluster. Both instances
of the counter app show the same session ID, and both increment (correctly)
independent of each other, but they are not sharing the session variable :(
One possible clue as to what's going on is this log message, that's been
bothering me:
FINE: Received a failure detector
packet:ClusterData[src=org.apache.catalina.tribes.membership.MemberImpl[tcp://{192,
168, 1, 240}:4000,{192, 168, 1, 240},4000, alive=1379968430807,
securePort=-1, UDP Port=-1, id={81 35 97 0 -37 63 71 -104 -102 28 115 6 -51
-24 -24 99 }, payload={}, command={}, domain={}, ]; id={-101 -57 -98 104
-103 31 66 113 -85 -84 -80 -86 14 -2 52 -31 }; sent=2013-09-23 16:33:50.81]
Other than that I'm at a loss on where to go; any suggestions are welcome.
Thanks,
Nick
Re: Problems with Clustering / Session Replication
On Sep 18, 2013, at 9:00 AM, Nicholas Violi nvi...@globalgiving.org wrote:
Thanks Daniel.
On Tue, Sep 17, 2013 at 5:30 PM, Daniel Mikusa dmik...@gopivotal.comwrote:
Tried a quick two node setup on my Mac w/out HTTPD and it worked OK. Go
to one Tomcat instance's port in chrome, it increments the counter in my
app. Refresh a few times. Open a second tab, go to the second Tomcat
instance's port. The counter picks up where it left off and continues
incrementing. Flipping back and forth between tabs / servers works fine.
Here's the cluster config that I used in case it helps.
Cluster channelSendOptions=8
className=org.apache.catalina.ha.tcp.SimpleTcpCluster
Manager
className=org.apache.catalina.ha.session.DeltaManager
expireSessionsOnShutdown=false
notifyListenersOnReplication=true/
Channel
className=org.apache.catalina.tribes.group.GroupChannel
Membership address=228.0.0.4
className=org.apache.catalina.tribes.membership.McastService
dropTime=3000
frequency=500
port=45564/
Receiver address=auto
autoBind=100
className=org.apache.catalina.tribes.transport.nio.NioReceiver
maxThreads=6
port=4000
selectorTimeout=5000/
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/
/Channel
Valve
className=org.apache.catalina.ha.tcp.ReplicationValve
filter=/
Valve
className=org.apache.catalina.ha.session.JvmRouteBinderValve/
ClusterListener
className=org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener/
ClusterListener
className=org.apache.catalina.ha.session.ClusterSessionListener/
/Cluster
Just tried this with the same results. My test that replication is behaving
is accessing my webapp on the two ports and monitoring the session counter
and list in the tomcat manager, and as I said before, I can only see the
sessions created on the server attached to the manager instance. Is that a
reasonable test? With the clustering config pretty well ruled out as the
culprit, maybe my webapp is not dealing with sessions appropriately? Would
you mind sending me your counter test app?
Here's what I've been using:
WEB-INF/web.xml:
?xml version=1.0 encoding=UTF-8?
web-app version=2.5 xmlns=http://java.sun.com/xml/ns/javaee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd;
distributable/
/web-app
index.jsp:
%
Integer count = (Integer) session.getAttribute(counter);
if (count == null) {
count = 0;
session.setAttribute(counter, 0);
} else {
session.setAttribute(counter, count + 1);
}
%
html
head
titleIndex/title
/head
body
h2Session [%= session.getId() %]/h2
pCurrent count is %= count %/p
/body
/html
It's crude, but effective for testing session replication.
Beyond that, have you tried increasing the log levels?
I found conflicting information about enabling logging. What I had
previously was
org.apache.catalina.tribes.level = FINE
org.apache.catalina.tribes.MESSAGES = FINE
in logging.properties, which was reporting the FINE log statements in my
original post. I just added some more:
org.apache.catalina.ha.level = FINE
org.apache.catalina.ha.session.level = FINE
org.apache.catalina.ha.session.DeltaManager.level = FINE
org.apache.catalina.ha.tcp.level = FINE
org.apache.catalina.ha.tcp.level = FINE
org.apache.catalina.ha.tcp.ReplicationValve.level = FINE
org.apache.catalina.ha.session.ClusterSessionListener.level = FINE
org.apache.catalina.ha.session.JvmRouteSessionIDBinterListener.level = FINE
And I still don't see any messages when interacting with the webapp in the
browser. Are there any other classes I should be logging?
Use the information Mark sent. That worked for me with one minor change. I
had to set this level to FINER.
org.apache.catalina.tribes.MESSAGES.level = FINER
With this, I see messages like this in the logs:
19-Sep-2013 09:02:07.930 FINER [Tribes-Task-Receiver-3]
org.apache.catalina.tribes.transport.nio.NioReplicationTask.drainChannel
NioReplicationThread - Received msg:UniqueId{126, 49,
Re: Problems with Clustering / Session Replication
Thanks Daniel. On Tue, Sep 17, 2013 at 5:30 PM, Daniel Mikusa dmik...@gopivotal.comwrote: Tried a quick two node setup on my Mac w/out HTTPD and it worked OK. Go to one Tomcat instance's port in chrome, it increments the counter in my app. Refresh a few times. Open a second tab, go to the second Tomcat instance's port. The counter picks up where it left off and continues incrementing. Flipping back and forth between tabs / servers works fine. Here's the cluster config that I used in case it helps. Cluster channelSendOptions=8 className=org.apache.catalina.ha.tcp.SimpleTcpCluster Manager className=org.apache.catalina.ha.session.DeltaManager expireSessionsOnShutdown=false notifyListenersOnReplication=true/ Channel className=org.apache.catalina.tribes.group.GroupChannel Membership address=228.0.0.4 className=org.apache.catalina.tribes.membership.McastService dropTime=3000 frequency=500 port=45564/ Receiver address=auto autoBind=100 className=org.apache.catalina.tribes.transport.nio.NioReceiver maxThreads=6 port=4000 selectorTimeout=5000/ 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/ /Channel Valve className=org.apache.catalina.ha.tcp.ReplicationValve filter=/ Valve className=org.apache.catalina.ha.session.JvmRouteBinderValve/ ClusterListener className=org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener/ ClusterListener className=org.apache.catalina.ha.session.ClusterSessionListener/ /Cluster Just tried this with the same results. My test that replication is behaving is accessing my webapp on the two ports and monitoring the session counter and list in the tomcat manager, and as I said before, I can only see the sessions created on the server attached to the manager instance. Is that a reasonable test? With the clustering config pretty well ruled out as the culprit, maybe my webapp is not dealing with sessions appropriately? Would you mind sending me your counter test app? Beyond that, have you tried increasing the log levels? I found conflicting information about enabling logging. What I had previously was org.apache.catalina.tribes.level = FINE org.apache.catalina.tribes.MESSAGES = FINE in logging.properties, which was reporting the FINE log statements in my original post. I just added some more: org.apache.catalina.ha.level = FINE org.apache.catalina.ha.session.level = FINE org.apache.catalina.ha.session.DeltaManager.level = FINE org.apache.catalina.ha.tcp.level = FINE org.apache.catalina.ha.tcp.level = FINE org.apache.catalina.ha.tcp.ReplicationValve.level = FINE org.apache.catalina.ha.session.ClusterSessionListener.level = FINE org.apache.catalina.ha.session.JvmRouteSessionIDBinterListener.level = FINE And I still don't see any messages when interacting with the webapp in the browser. Are there any other classes I should be logging? Thanks, Nick
Re: Problems with Clustering / Session Replication
On 9/18/2013 6:00 AM, Nicholas Violi wrote:
Thanks Daniel.
On Tue, Sep 17, 2013 at 5:30 PM, Daniel Mikusa dmik...@gopivotal.comwrote:
Tried a quick two node setup on my Mac w/out HTTPD and it worked OK. Go
to one Tomcat instance's port in chrome, it increments the counter in my
app. Refresh a few times. Open a second tab, go to the second Tomcat
instance's port. The counter picks up where it left off and continues
incrementing. Flipping back and forth between tabs / servers works fine.
Here's the cluster config that I used in case it helps.
Cluster channelSendOptions=8
className=org.apache.catalina.ha.tcp.SimpleTcpCluster
Manager
className=org.apache.catalina.ha.session.DeltaManager
expireSessionsOnShutdown=false
notifyListenersOnReplication=true/
Channel
className=org.apache.catalina.tribes.group.GroupChannel
Membership address=228.0.0.4
className=org.apache.catalina.tribes.membership.McastService
dropTime=3000
frequency=500
port=45564/
Receiver address=auto
autoBind=100
className=org.apache.catalina.tribes.transport.nio.NioReceiver
maxThreads=6
port=4000
selectorTimeout=5000/
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/
/Channel
Valve
className=org.apache.catalina.ha.tcp.ReplicationValve
filter=/
Valve
className=org.apache.catalina.ha.session.JvmRouteBinderValve/
ClusterListener
className=org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener/
ClusterListener
className=org.apache.catalina.ha.session.ClusterSessionListener/
/Cluster
Just tried this with the same results. My test that replication is behaving
is accessing my webapp on the two ports and monitoring the session counter
and list in the tomcat manager, and as I said before, I can only see the
sessions created on the server attached to the manager instance. Is that a
reasonable test? With the clustering config pretty well ruled out as the
culprit, maybe my webapp is not dealing with sessions appropriately? Would
you mind sending me your counter test app?
Beyond that, have you tried increasing the log levels?
I found conflicting information about enabling logging. What I had
previously was
org.apache.catalina.tribes.level = FINE
org.apache.catalina.tribes.MESSAGES = FINE
in logging.properties, which was reporting the FINE log statements in my
original post. I just added some more:
org.apache.catalina.ha.level = FINE
org.apache.catalina.ha.session.level = FINE
org.apache.catalina.ha.session.DeltaManager.level = FINE
org.apache.catalina.ha.tcp.level = FINE
org.apache.catalina.ha.tcp.level = FINE
org.apache.catalina.ha.tcp.ReplicationValve.level = FINE
org.apache.catalina.ha.session.ClusterSessionListener.level = FINE
org.apache.catalina.ha.session.JvmRouteSessionIDBinterListener.level = FINE
And I still don't see any messages when interacting with the webapp in the
browser. Are there any other classes I should be logging?
Thanks,
Nick
Copy-pasted from a message I sent to the mailing list about 3 weeks ago:
It's been a while since I've played with this, so your mileage may vary.
# wrapped for easier reading
# added one additional handler
handlers = 1catalina.org.apache.juli.FileHandler,
2localhost.org.apache.juli.FileHandler,
3manager.org.apache.juli.FileHandler,
4host-manager.or.apache.juli.FileHandler,
java.util.logging.ConsoleHandler,
5cluster.org.apache.juli.FileHandler
# just the new cluster log handler - all others are stock
# logging.properties
# beware of the wrapping
5cluster.org.apache.juli.FileHandler.level = FINER
5cluster.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
5cluster.org.apache.juli.FileHandler.prefix = cluster.
# just the clustering logs - all others are stock logging.properties
org.apache.catalina.tribes.MESSAGES.level = FINE
org.apache.catalina.tribes.MESSAGES.handlers =
5cluster.org.apache.juli.FileHandler
org.apache.catalina.tribes.level = FINE
org.apache.catalina.tribes.handlers =
5cluster.org.apache.juli.FileHandler
org.apache.catalina.ha.level = FINE
org.apache.catalina.ha.handlers =
Re: Problems with Clustering / Session Replication
Hi Nicholas, I'm am a bit of a novice but I did have a very similar problem when I started using the clustering modules. My Tomcat output was referring to localhost (10.x.x.x) addresses while my netstat was reporting LISTEN on network addresses (192.x.x.x:400?). You have the same disparity. My system operated to expectation after I registered my machine's network IP address in linux folder /etc/hosts. Once I did that tomcat clustering logs started reporting membership with network addresses instead of localhost addresses. On Thu, Sep 19, 2013 at 2:37 AM, Mark Eggers its_toas...@yahoo.com wrote: On 9/18/2013 6:00 AM, Nicholas Violi wrote: Thanks Daniel. On Tue, Sep 17, 2013 at 5:30 PM, Daniel Mikusa dmik...@gopivotal.com wrote: Tried a quick two node setup on my Mac w/out HTTPD and it worked OK. Go to one Tomcat instance's port in chrome, it increments the counter in my app. Refresh a few times. Open a second tab, go to the second Tomcat instance's port. The counter picks up where it left off and continues incrementing. Flipping back and forth between tabs / servers works fine. Here's the cluster config that I used in case it helps. Cluster channelSendOptions=8 className=org.apache.**catalina.ha.tcp.**SimpleTcpCluster Manager className=org.apache.**catalina.ha.session.**DeltaManager expireSessionsOnShutdown=**false notifyListenersOnReplication=**true/ Channel className=org.apache.**catalina.tribes.group.**GroupChannel Membership address=228.0.0.4 className=org.apache.**catalina.tribes.membership.**McastService dropTime=3000 frequency=500 port=45564/ Receiver address=auto autoBind=100 className=org.apache.**catalina.tribes.transport.nio.**NioReceiver maxThreads=6 port=4000 selectorTimeout=5000/ 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/** /Channel Valve className=org.apache.**catalina.ha.tcp.**ReplicationValve filter=/ Valve className=org.apache.**catalina.ha.session.**JvmRouteBinderValve/ ClusterListener className=org.apache.**catalina.ha.session.** JvmRouteSessionIDBinderListene**r/ ClusterListener className=org.apache.**catalina.ha.session.**ClusterSessionListener/ /Cluster Just tried this with the same results. My test that replication is behaving is accessing my webapp on the two ports and monitoring the session counter and list in the tomcat manager, and as I said before, I can only see the sessions created on the server attached to the manager instance. Is that a reasonable test? With the clustering config pretty well ruled out as the culprit, maybe my webapp is not dealing with sessions appropriately? Would you mind sending me your counter test app? Beyond that, have you tried increasing the log levels? I found conflicting information about enabling logging. What I had previously was org.apache.catalina.tribes.**level = FINE org.apache.catalina.tribes.**MESSAGES = FINE in logging.properties, which was reporting the FINE log statements in my original post. I just added some more: org.apache.catalina.ha.level = FINE org.apache.catalina.ha.**session.level = FINE org.apache.catalina.ha.**session.DeltaManager.level = FINE org.apache.catalina.ha.tcp.**level = FINE org.apache.catalina.ha.tcp.**level = FINE org.apache.catalina.ha.tcp.**ReplicationValve.level = FINE org.apache.catalina.ha.**session.**ClusterSessionListener.level = FINE org.apache.catalina.ha.**session.**JvmRouteSessionIDBinterListene**r.level = FINE And I still don't see any messages when interacting with the webapp in the browser. Are there any other classes I should be logging? Thanks, Nick Copy-pasted from a message I sent to the mailing list about 3 weeks ago: It's been a while since I've played with this, so your mileage may vary. # wrapped for easier reading # added one additional handler handlers = 1catalina.org.apache.juli.**FileHandler, 2localhost.org.apache.juli.**FileHandler, 3manager.org.apache.juli.**FileHandler, 4host-manager.or.apache.juli.**FileHandler,
Re: Problems with Clustering / Session Replication
alternatively try an explicit address in the Receiver configuration Receiver className=org.apache.catalina.tribes.transport.nio.NioReceiver address=auto port=4001 autoBind=100 selectorTimeout=5000 maxThreads=6/ instead of address=auto try address=192.168.1.43 this should alter the log displayed at start-up and I would be very interested if you still had a problem. On Thu, Sep 19, 2013 at 10:35 AM, Vince Stewart stewart.vi...@gmail.comwrote: Hi Nicholas, I'm am a bit of a novice but I did have a very similar problem when I started using the clustering modules. My Tomcat output was referring to localhost (10.x.x.x) addresses while my netstat was reporting LISTEN on network addresses (192.x.x.x:400?). You have the same disparity. My system operated to expectation after I registered my machine's network IP address in linux folder /etc/hosts. Once I did that tomcat clustering logs started reporting membership with network addresses instead of localhost addresses. On Thu, Sep 19, 2013 at 2:37 AM, Mark Eggers its_toas...@yahoo.comwrote: On 9/18/2013 6:00 AM, Nicholas Violi wrote: Thanks Daniel. On Tue, Sep 17, 2013 at 5:30 PM, Daniel Mikusa dmik...@gopivotal.com wrote: Tried a quick two node setup on my Mac w/out HTTPD and it worked OK. Go to one Tomcat instance's port in chrome, it increments the counter in my app. Refresh a few times. Open a second tab, go to the second Tomcat instance's port. The counter picks up where it left off and continues incrementing. Flipping back and forth between tabs / servers works fine. Here's the cluster config that I used in case it helps. Cluster channelSendOptions=8 className=org.apache.**catalina.ha.tcp.**SimpleTcpCluster Manager className=org.apache.**catalina.ha.session.**DeltaManager expireSessionsOnShutdown=**false notifyListenersOnReplication=**true/ Channel className=org.apache.**catalina.tribes.group.**GroupChannel Membership address=228.0.0.4 className=org.apache.**catalina.tribes.membership.**McastService dropTime=3000 frequency=500 port=45564/ Receiver address=auto autoBind=100 className=org.apache.**catalina.tribes.transport.nio.**NioReceiver maxThreads=6 port=4000 selectorTimeout=5000/ 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/** /Channel Valve className=org.apache.**catalina.ha.tcp.**ReplicationValve filter=/ Valve className=org.apache.**catalina.ha.session.**JvmRouteBinderValve/ ClusterListener className=org.apache.**catalina.ha.session.** JvmRouteSessionIDBinderListene**r/ ClusterListener className=org.apache.**catalina.ha.session.**ClusterSessionListener/ /Cluster Just tried this with the same results. My test that replication is behaving is accessing my webapp on the two ports and monitoring the session counter and list in the tomcat manager, and as I said before, I can only see the sessions created on the server attached to the manager instance. Is that a reasonable test? With the clustering config pretty well ruled out as the culprit, maybe my webapp is not dealing with sessions appropriately? Would you mind sending me your counter test app? Beyond that, have you tried increasing the log levels? I found conflicting information about enabling logging. What I had previously was org.apache.catalina.tribes.**level = FINE org.apache.catalina.tribes.**MESSAGES = FINE in logging.properties, which was reporting the FINE log statements in my original post. I just added some more: org.apache.catalina.ha.level = FINE org.apache.catalina.ha.**session.level = FINE org.apache.catalina.ha.**session.DeltaManager.level = FINE org.apache.catalina.ha.tcp.**level = FINE org.apache.catalina.ha.tcp.**level = FINE org.apache.catalina.ha.tcp.**ReplicationValve.level = FINE org.apache.catalina.ha.**session.**ClusterSessionListener.level = FINE org.apache.catalina.ha.**session.**JvmRouteSessionIDBinterListene**r.level = FINE And I still don't see any
Problems with Clustering / Session Replication
Hello,
I'm setting up clustering/replication on Tomcat 7 on my local machine, to
evaluate it for use with my environment/codebase, and sessions don't appear
to be replicating. Hopefully I've provided enough information below, but
please let me know if you have any more questions.
___Setup___
I have two identical tomcat servers in sibling directories running on
different ports. I have httpd listening on two other ports and connecting
to the two tomcat instances as VirtualHosts. I can access and interact with
both environments on the configured ports; everything is working as
expected.
The tomcat servers have clustering enabled like this, in server.xml:
Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster
channelSendOptions=8
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=228.0.0.4
port=45564
frequency=500
dropTime=3000/
Receiver
className=org.apache.catalina.tribes.transport.nio.NioReceiver
address=auto
port=4001
autoBind=100
selectorTimeout=5000
maxThreads=6/
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=/
Valve
className=org.apache.catalina.ha.session.JvmRouteBinderValve/
ClusterListener
className=org.apache.catalina.ha.session.ClusterSessionListener/
/Cluster
and I added the distributable tag to the very beginning of web.xml:
web-app xmlns=http://java.sun.com/xml/ns/javaee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd;
version=3.0
distributable /
(lots more...)
/web-app
___What's working___
When the servers start, they log
Sep 16, 2013 1:44:23 PM org.apache.catalina.ha.tcp.SimpleTcpCluster
startInternal
INFO: Cluster is about to start
Sep 16, 2013 1:44:23 PM org.apache.catalina.tribes.transport.ReceiverBase
getBind
FINE: Starting replication listener on address:10.0.0.100
Sep 16, 2013 1:44:23 PM org.apache.catalina.tribes.transport.ReceiverBase
bind
INFO: Receiver Server Socket bound to:/10.0.0.100:4001
Sep 16, 2013 1:44:23 PM
org.apache.catalina.tribes.membership.McastServiceImpl setupSocket
INFO: Setting cluster mcast soTimeout to 500
Sep 16, 2013 1:44:23 PM
org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers
INFO: Sleeping for 1000 milliseconds to establish cluster membership, start
level:4
Sep 16, 2013 1:44:24 PM
org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers
INFO: Done sleeping, membership established, start level:4
Sep 16, 2013 1:44:24 PM
org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers
INFO: Sleeping for 1000 milliseconds to establish cluster membership, start
level:8
Sep 16, 2013 1:44:25 PM
org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers
INFO: Done sleeping, membership established, start level:8
When the second server starts up, the first one logs
Sep 16, 2013 2:17:30 PM
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
messageReceived
FINE: Received a failure detector
packet:ClusterData[src=org.apache.catalina.tribes.membership.MemberImpl[tcp://{10,
0, 0, 100}:4000,{10, 0, 0, 100},4000, alive=112208, securePort=-1, UDP
Port=-1, id={118 6 107 -67 88 98 72 95 -73 41 4 -108 58 -5 -127 -41 },
payload={}, command={}, domain={}, ]; id={25 110 120 -2 -25 6 78 -97 -84
-34 2 -11 49 -62 -8 -56 }; sent=2013-09-16 14:17:30.139]
Sep 16, 2013 2:17:30 PM
org.apache.catalina.tribes.transport.nio.NioReplicationTask remoteEof
FINE: Channel closed on the remote end, disconnecting
Sep 16, 2013 2:17:30 PM
org.apache.catalina.tribes.membership.McastServiceImpl memberDataReceived
FINE: Mcast add member
org.apache.catalina.tribes.membership.MemberImpl[tcp://{10, 0, 0,
100}:4001,{10, 0, 0, 100},4001, alive=1010, securePort=-1, UDP Port=-1,
id={82 -45 -109 -56 -110 -5 78 -10 -103 61 -40 -59 -36 -79 104 120 },
payload={}, command={}, domain={}, ]
Sep 16, 2013 2:17:30 PM org.apache.catalina.ha.tcp.SimpleTcpCluster
memberAdded
INFO: Replication
Re: Problems with Clustering / Session Replication
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Nicholas,
On 9/17/13 9:59 AM, Nicholas Violi wrote:
Hello, I'm setting up clustering/replication on Tomcat 7 on my
local machine, to evaluate it for use with my environment/codebase,
and sessions don't appear to be replicating. Hopefully I've
provided enough information below, but please let me know if you
have any more questions.
___Setup___
I have two identical tomcat servers in sibling directories running
on different ports. I have httpd listening on two other ports and
connecting to the two tomcat instances as VirtualHosts. I can
access and interact with both environments on the configured ports;
everything is working as expected.
The tomcat servers have clustering enabled like this, in
server.xml:
I have to admit that I've never set up Tomcat for clustering, but I
wonder if you'd have better luck configuring with a Unicast membership
model to begin... it seems a bit more straightforward, and has the
added benefit that it will work even if multicast isn't working on
your machine for some reason.
[...]
so I know they're aware of each other.
Hmm.
Finally, when I use the Cluster/Operations MBean in jconsole to try
to set property foo to bar, jconsole reports method
successfully invoked, and the server logs
Sep 16, 2013 2:30:18 PM
org.apache.catalina.ha.tcp.SimpleTcpCluster setProperty WARNING:
Dynamic setProperty(foo,value) has been disabled, please use
explicit properties for the element you are trying to identify
I'm not too worried about that error; mostly included to
demonstrate that setProperty creates a log statement.
___What's not working___
As far as I can tell, no session information is being replicated in
my app.
The tomcat manager only lists sessions started on the server it's
monitoring, and not the other one in the cluster.
I'm under the impression that whenever the app calls
HttpSession.setAttribute, that attribute should be replicated to
the other cluster nodes, and I would expect that some record of
that would be logged. My app includes this line:
public static void saveBillingInfo(IPageContext pageContext,
BillingInfo billingInfo) {
pageContext.getSession().setAttribute(billingInfo, billingInfo);
//etc... }
where BillingInfo is a Serializable class containing only one
field, a HashMap of information about the billing info.
No log statements are written when this or any other line
processes, and I don't see any evidence that session information is
actually being shared.
I believe the DeltaManager will replicate those attributes that have
been set during the whole request. So, instead of sending one message
per call to session.setAttribtue, you'll get one big message with all
of the mutations together. But I agree you should be getting *something*.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSOGVLAAoJEBzwKT+lPKRY5P4P/0K9f4mTyWKG/MYVP6YOMkRY
XCYLsFJzR4vX8SVSi1gF/ae71qE3cJbkMaXp/Lr6VAJsvJfRepw8aE8lP53N3OUo
CTLMgx1Ud0cGf2iivwWUksRvPzqBg2UKTSG23wp6av0ZhJ5Qhqujh1NPdJ/91tq/
bXBlXx+/XYo6s9dYo6VhOYl+lM3VMusNJwUg6Yjb67onXzZ8LvFwXigMCVIJ2n5T
c+8VJ66Jz5iOiGIWabh7mGKsDbHNsEImATLDhAxk3dyuFyQb9e/hVzXqxZoclb8N
ImwDbWmEgZRew2bpXLUlGWmHt8PDxknF6D3cI7YyAw0bQ66Yw27TnEMdFx/y7yrJ
YGlScXPs17ghzg3WkCHpJ0lt37TOXAdUQMcwHRg0GyiWsdoXrAfLlbkLLUnxPidr
bRBswNurZQ1j4JoVYojWOhwKB3tLdeXHmNNxfjNRfi1cpnjJ1Tdumdg+Iq0LjT//
nM0DciBdFEPw/jM50yR6klg8srMvPhW3HP3i6KXugcoRv4E2/9JvOTwlbJslxZD5
KHrlBTQZegkxPIuu2Bx+QIoAWtU51d2plkTGH+Kq8nGlo9o9YD3DQ0B5r1I+0R9o
pAVyD42bCf/eHDNttcLqRFzXMkJftW4MloL6SuCAeu7L3pyZd42DPiw5E6+qw7uh
5zfC+mgFBJwtDgFJ7+tJ
=0MQ8
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problems with Clustering / Session Replication
Hi Daniel, Thanks for the response. It seems that the ports (you're correct, 4000 and 4001) aren't open; telnet reports Connection refused and nmap lists the ports as closed. Shouldn't tomcat be opening them? I'm not running a firewall or anything. I'll come back to your questions about my apache config if we get stuck, but I suspect that's not the issue. Thanks, Nick On Tue, Sep 17, 2013 at 10:52 AM, Daniel Mikusa dmik...@gopivotal.comwrote: On Sep 17, 2013, at 9:59 AM, Nicholas Violi nvi...@globalgiving.org wrote: Hello, I'm setting up clustering/replication on Tomcat 7 on my local machine, to evaluate it for use with my environment/codebase, and sessions don't appear to be replicating. Hopefully I've provided enough information below, but please let me know if you have any more questions. ___Setup___ I have two identical tomcat servers in sibling directories running on different ports. Good. Out of curiosity, are they listening on HTTP or AJP? I have httpd listening on two other ports and connecting to the two tomcat instances as VirtualHosts. This sounds a little weird, can you explain further? - Why are you listening on two ports? Is one HTTP and one HTTPS? - Where and why are you using VirtualHosts? That's unnecessary for a simple clustering setup and is probably just complicating things. - How are you connecting to your Tomcat instances? mod_proxy or mod_jk? Can you include the config? I can access and interact with both environments on the configured ports; everything is working as expected. The tomcat servers have clustering enabled like this, in server.xml: Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster channelSendOptions=8 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=228.0.0.4 port=45564 frequency=500 dropTime=3000/ Receiver className=org.apache.catalina.tribes.transport.nio.NioReceiver address=auto port=4001 autoBind=100 selectorTimeout=5000 maxThreads=6/ 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=/ Valve className=org.apache.catalina.ha.session.JvmRouteBinderValve/ ClusterListener className=org.apache.catalina.ha.session.ClusterSessionListener/ /Cluster Are you trying to setup sticky sessions? If so, what are you setting for jvmRoute? and I added the distributable tag to the very beginning of web.xml: web-app xmlns=http://java.sun.com/xml/ns/javaee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd; version=3.0 distributable / (lots more...) /web-app ___What's working___ When the servers start, they log Sep 16, 2013 1:44:23 PM org.apache.catalina.ha.tcp.SimpleTcpCluster startInternal INFO: Cluster is about to start Sep 16, 2013 1:44:23 PM org.apache.catalina.tribes.transport.ReceiverBase getBind FINE: Starting replication listener on address:10.0.0.100 Sep 16, 2013 1:44:23 PM org.apache.catalina.tribes.transport.ReceiverBase bind INFO: Receiver Server Socket bound to:/10.0.0.100:4001 Sep 16, 2013 1:44:23 PM org.apache.catalina.tribes.membership.McastServiceImpl setupSocket INFO: Setting cluster mcast soTimeout to 500 Sep 16, 2013 1:44:23 PM org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers INFO: Sleeping for 1000 milliseconds to establish cluster membership, start level:4 Sep 16, 2013 1:44:24 PM org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers INFO: Done sleeping, membership established, start level:4 Sep 16, 2013 1:44:24 PM org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers INFO: Sleeping for 1000 milliseconds to establish cluster membership, start level:8 Sep 16, 2013 1:44:25 PM org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers
Re: Problems with Clustering / Session Replication
On Sep 17, 2013, at 9:59 AM, Nicholas Violi nvi...@globalgiving.org wrote:
Hello,
I'm setting up clustering/replication on Tomcat 7 on my local machine, to
evaluate it for use with my environment/codebase, and sessions don't appear
to be replicating. Hopefully I've provided enough information below, but
please let me know if you have any more questions.
___Setup___
I have two identical tomcat servers in sibling directories running on
different ports.
Good. Out of curiosity, are they listening on HTTP or AJP?
I have httpd listening on two other ports and connecting
to the two tomcat instances as VirtualHosts.
This sounds a little weird, can you explain further?
- Why are you listening on two ports? Is one HTTP and one HTTPS?
- Where and why are you using VirtualHosts? That's unnecessary for a simple
clustering setup and is probably just complicating things.
- How are you connecting to your Tomcat instances? mod_proxy or mod_jk? Can
you include the config?
I can access and interact with
both environments on the configured ports; everything is working as
expected.
The tomcat servers have clustering enabled like this, in server.xml:
Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster
channelSendOptions=8
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=228.0.0.4
port=45564
frequency=500
dropTime=3000/
Receiver
className=org.apache.catalina.tribes.transport.nio.NioReceiver
address=auto
port=4001
autoBind=100
selectorTimeout=5000
maxThreads=6/
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=/
Valve
className=org.apache.catalina.ha.session.JvmRouteBinderValve/
ClusterListener
className=org.apache.catalina.ha.session.ClusterSessionListener/
/Cluster
Are you trying to setup sticky sessions? If so, what are you setting for
jvmRoute?
and I added the distributable tag to the very beginning of web.xml:
web-app xmlns=http://java.sun.com/xml/ns/javaee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd;
version=3.0
distributable /
(lots more...)
/web-app
___What's working___
When the servers start, they log
Sep 16, 2013 1:44:23 PM org.apache.catalina.ha.tcp.SimpleTcpCluster
startInternal
INFO: Cluster is about to start
Sep 16, 2013 1:44:23 PM org.apache.catalina.tribes.transport.ReceiverBase
getBind
FINE: Starting replication listener on address:10.0.0.100
Sep 16, 2013 1:44:23 PM org.apache.catalina.tribes.transport.ReceiverBase
bind
INFO: Receiver Server Socket bound to:/10.0.0.100:4001
Sep 16, 2013 1:44:23 PM
org.apache.catalina.tribes.membership.McastServiceImpl setupSocket
INFO: Setting cluster mcast soTimeout to 500
Sep 16, 2013 1:44:23 PM
org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers
INFO: Sleeping for 1000 milliseconds to establish cluster membership, start
level:4
Sep 16, 2013 1:44:24 PM
org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers
INFO: Done sleeping, membership established, start level:4
Sep 16, 2013 1:44:24 PM
org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers
INFO: Sleeping for 1000 milliseconds to establish cluster membership, start
level:8
Sep 16, 2013 1:44:25 PM
org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers
INFO: Done sleeping, membership established, start level:8
When the second server starts up, the first one logs
Sep 16, 2013 2:17:30 PM
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
messageReceived
FINE: Received a failure detector
packet:ClusterData[src=org.apache.catalina.tribes.membership.MemberImpl[tcp://{10,
0, 0, 100}:4000,{10, 0, 0, 100},4000, alive=112208, securePort=-1, UDP
Port=-1, id={118 6 107 -67 88 98 72 95 -73 41 4 -108 58 -5 -127 -41 },
payload={}, command={}, domain={}, ]; id={25 110 120 -2 -25 6 78
Re: Problems with Clustering / Session Replication
On Sep 17, 2013, at 11:10 AM, Nicholas Violi nvi...@globalgiving.org wrote: Hi Daniel, Please don't top post. Either reply at the bottom or reply inline. That is the convention we try to follow on this list. Thanks for the response. It seems that the ports (you're correct, 4000 and 4001) aren't open; telnet reports Connection refused and nmap lists the ports as closed. Can your run netstat and see if anything is listening on those ports? netstat -tln should work on Linux or netstat -an | grep LISTEN on Mac. Sorry I'm not sure about the command on Windows. You should see something which lists the ports. Example from my Mac. tcp4 0 0 192.168.0.6.4001 *.*LISTEN tcp4 0 0 192.168.0.6.4000 *.*LISTEN tcp46 0 0 *.8080 *.*LISTEN tcp46 0 0 *.8081 *.*LISTEN ... Shouldn't tomcat be opening them? Yes it should and the logs indicate that it appears to be doing so. Output from netstat should confirm. Dan I'm not running a firewall or anything. I'll come back to your questions about my apache config if we get stuck, but I suspect that's not the issue. Thanks, Nick On Tue, Sep 17, 2013 at 10:52 AM, Daniel Mikusa dmik...@gopivotal.comwrote: On Sep 17, 2013, at 9:59 AM, Nicholas Violi nvi...@globalgiving.org wrote: Hello, I'm setting up clustering/replication on Tomcat 7 on my local machine, to evaluate it for use with my environment/codebase, and sessions don't appear to be replicating. Hopefully I've provided enough information below, but please let me know if you have any more questions. ___Setup___ I have two identical tomcat servers in sibling directories running on different ports. Good. Out of curiosity, are they listening on HTTP or AJP? I have httpd listening on two other ports and connecting to the two tomcat instances as VirtualHosts. This sounds a little weird, can you explain further? - Why are you listening on two ports? Is one HTTP and one HTTPS? - Where and why are you using VirtualHosts? That's unnecessary for a simple clustering setup and is probably just complicating things. - How are you connecting to your Tomcat instances? mod_proxy or mod_jk? Can you include the config? I can access and interact with both environments on the configured ports; everything is working as expected. The tomcat servers have clustering enabled like this, in server.xml: Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster channelSendOptions=8 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=228.0.0.4 port=45564 frequency=500 dropTime=3000/ Receiver className=org.apache.catalina.tribes.transport.nio.NioReceiver address=auto port=4001 autoBind=100 selectorTimeout=5000 maxThreads=6/ 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=/ Valve className=org.apache.catalina.ha.session.JvmRouteBinderValve/ ClusterListener className=org.apache.catalina.ha.session.ClusterSessionListener/ /Cluster Are you trying to setup sticky sessions? If so, what are you setting for jvmRoute? and I added the distributable tag to the very beginning of web.xml: web-app xmlns=http://java.sun.com/xml/ns/javaee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd; version=3.0 distributable / (lots more...) /web-app ___What's working___ When the servers start, they log Sep 16, 2013 1:44:23 PM org.apache.catalina.ha.tcp.SimpleTcpCluster startInternal INFO: Cluster is about to start Sep 16, 2013 1:44:23 PM org.apache.catalina.tribes.transport.ReceiverBase getBind FINE: Starting replication listener on address:10.0.0.100 Sep 16, 2013 1:44:23 PM org.apache.catalina.tribes.transport.ReceiverBase bind INFO: Receiver Server
Re: Problems with Clustering / Session Replication
On Tue, Sep 17, 2013 at 11:25 AM, Daniel Mikusa dmik...@gopivotal.comwrote: Please don't top post. Either reply at the bottom or reply inline. That is the convention we try to follow on this list. Sorry thanks. Can your run netstat and see if anything is listening on those ports? netstat -tln should work on Linux or netstat -an | grep LISTEN on Mac. Sorry I'm not sure about the command on Windows. Yep, I see them: tcp4 0 0 192.168.1.243.4000 *.*LISTEN tcp4 0 0 192.168.1.243.4001 *.*LISTEN If it matters, the apache and tomcat ports are running with a wildcard IP: tcp46 0 0 *.8082 *.*LISTEN tcp46 0 0 *.8080 *.*LISTEN tcp46 0 0 *.8081 *.*LISTEN tcp46 0 0 *.8083 *.*LISTEN Thanks, Nick
Re: Problems with Clustering / Session Replication
On Sep 17, 2013, at 11:32 AM, Nicholas Violi nvi...@globalgiving.org wrote: On Tue, Sep 17, 2013 at 11:25 AM, Daniel Mikusa dmik...@gopivotal.comwrote: Please don't top post. Either reply at the bottom or reply inline. That is the convention we try to follow on this list. Sorry thanks. Can your run netstat and see if anything is listening on those ports? netstat -tln should work on Linux or netstat -an | grep LISTEN on Mac. Sorry I'm not sure about the command on Windows. Yep, I see them: tcp4 0 0 192.168.1.243.4000 *.*LISTEN tcp4 0 0 192.168.1.243.4001 *.*LISTEN Good! Since Tomcat is listening on the ports, you just need to figure out why you can't connect to them. You should be able to telnet to the ports. Try: telnet 192.168.1.243 4000 and telnet 192.168.1.243 4001. Are you sure you don't have a firewall? Dan If it matters, the apache and tomcat ports are running with a wildcard IP: tcp46 0 0 *.8082 *.*LISTEN tcp46 0 0 *.8080 *.*LISTEN tcp46 0 0 *.8081 *.*LISTEN tcp46 0 0 *.8083 *.*LISTEN Thanks, Nick - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Problems with Clustering / Session Replication
From: Daniel Mikusa [mailto:dmik...@gopivotal.com] Subject: Re: Problems with Clustering / Session Replication Are you sure you don't have a firewall? Remember that a firewall could be on the server, the client, or anywhere in between. The OP should first see if a connection can be made from the same system Tomcat is running on. If that doesn't work, the server firewall is blocking it. If it does work, keep looking farther up the network. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problems with Clustering / Session Replication
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chuck, On 9/17/13 12:25 PM, Caldarale, Charles R wrote: From: Daniel Mikusa [mailto:dmik...@gopivotal.com] Subject: Re: Problems with Clustering / Session Replication Are you sure you don't have a firewall? Remember that a firewall could be on the server, the client, or anywhere in between. The OP should first see if a connection can be made from the same system Tomcat is running on. If that doesn't work, the server firewall is blocking it. If it does work, keep looking farther up the network. While the above is true, OP originally said that everything was on localhost. Most software firewalls allow localhost communication by default, so I would be surprised if that's the problem. It's obviously possible that the problem is non-default firewall rules. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSOIVfAAoJEBzwKT+lPKRYSKIQAJRdVrmB4LofRLqsAPMsEzAY 8o9X+SLOxJ71lmK55G1WYOr6tzx1uEPShzuey49zEYrfd8GNa3G1/IXBLUnpO9mU 0bbCDTleCFWcpZ5JFIvd0LStcqLxH6C2y5YxIeMZgSZmB4e79jIEaPJIGZAOpsx+ NhyaV9EGwc7cwFqr983PCEwT36DeEaLs8xaVO0hx/pqHrm7XhdiEKaYb7IGIZyqv PG4J0WlDkydZhFKFyWiJwCam+ngjMd61j2LiXtN4AZFo0WUu3cLh+r1gm+1JAiY3 K577fHThrjg+Pb28tkP+m6ywY3tyGC9MoKn1RhAg4spT22YJhHADoY4l2XhAt1Iw SNAq2NV13SBmPpiyBo2p+E2uE9kpYYPGPdOppqSoTU37wiAqBEra1S/iERibtZF2 UCC5yz++vSzpH2DtkCehdp5fkymg+PciMrRbM9wg6d8GzWCB/6EIP2lAqnjT4i2u qlcfbbqQEyxhgVNQhCqoZuxA650Efl7UDUayYr6TnMgFbC2IcnascQiOSLl0HdKh mEdM/Jd042IUgY0EFtwoueEiCIyHQZW3Vy46b8eO++wzufRUeOz8BVmh9yQQyvJa LliM+vwYDjNEyEp25KTEUVJER3l+eeL4Ow6k5Nj4cJ7lIg/GmBwy32VeqZJQ+FvS 3pAHCPfYvEHyYDIXfrD9 =wFB0 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problems with Clustering / Session Replication
On Tue, Sep 17, 2013 at 12:08 PM, Daniel Mikusa dmik...@gopivotal.comwrote: Good! Since Tomcat is listening on the ports, you just need to figure out why you can't connect to them. You should be able to telnet to the ports. Try: telnet 192.168.1.243 4000 and telnet 192.168.1.243 4001. telnet connects fine... Are you sure you don't have a firewall? Double checked that my mac's firewall is switched off and sudo ipfw list returns 65535 allow ip from any to any Thanks, Nick
RE: Problems with Clustering / Session Replication
From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: Problems with Clustering / Session Replication While the above is true, OP originally said that everything was on localhost. Note the IP address reported by the OP's netstat: 192.168.1.243. That's decidedly not localhost and may be subject to firewall restrictions. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Problems with Clustering / Session Replication
From: Nicholas Violi [mailto:nvi...@globalgiving.org] Subject: Re: Problems with Clustering / Session Replication telnet connects fine... ??? Previously, you stated: telnet reports Connection refused. Which is it? Are you sure you don't have a firewall? Double checked that my mac's firewall is switched off and sudo ipfw list returns 65535 allow ip from any to any Good to get that out of the way. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problems with Clustering / Session Replication
On Tue, Sep 17, 2013 at 1:16 PM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: telnet connects fine... ??? Previously, you stated: telnet reports Connection refused. Which is it? Apologies for not specifying. My first test was telnet localhost 4000, which refused the connection. After seeing the result of netstat I tried telnet 192.168.1.143 4000 which connected correctly. I guess it makes sense that telnet would bind to the external IP, but the cluster sibling should also be able to connect on this IP, so I'm still at a loss for what's failing. Thanks, Nick
Re: Problems with Clustering / Session Replication
On Sep 17, 2013, at 1:21 PM, Nicholas Violi nvi...@globalgiving.org wrote: On Tue, Sep 17, 2013 at 1:16 PM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: telnet connects fine... ??? Previously, you stated: telnet reports Connection refused. Which is it? Apologies for not specifying. My first test was telnet localhost 4000, which refused the connection. After seeing the result of netstat I tried telnet 192.168.1.143 4000 which connected correctly. I guess it makes sense that telnet would bind to the external IP, but the cluster sibling should also be able to connect on this IP, so I'm still at a loss for what's failing. How do you have HTTPD configured? It's important to get this right. Dan Thanks, Nick - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problems with Clustering / Session Replication
On Sep 17, 2013, at 3:08 PM, Nicholas Violi nvi...@globalgiving.org wrote: On Tue, Sep 17, 2013 at 2:34 PM, Daniel Mikusa dmik...@gopivotal.comwrote: How do you have HTTPD configured? It's important to get this right. The tomcats are running on 8081 and 8083 and apache is listening on 8080 and 8082, with each one proxied to the corresponding tomcat instance. I think these are the relevant parts of httpd.conf, but let me know if there's something else you want to see: Listen 8080 Listen 8082 [...] NameVirtualHost *:8080 NameVirtualHost *:8082 [...] VirtualHost *:8080 DocumentRoot /var/www/ ServerName local.mysite.com ScriptAlias /cgi-bin/ /var/www/cgi-bin/ [...] ProxyPass/dy http://localhost:8081/dy max=100 ProxyPassReverse /dy http://localhost:8081/dy max=100 /VirtualHost VirtualHost *:8082 DocumentRoot /var/www/ ServerName local.mysite.com ScriptAlias /cgi-bin/ /var/www/cgi-bin/ [...] ProxyPass/dy http://localhost:8083/dy max=100 ProxyPassReverse /dy http://localhost:8083/dy max=100 /VirtualHost What is your purpose with this configuration and with this setup? It's a legit setup, but may not be doing what you want. Typically you would use mod_proxy mod_proxy_balancer (or mod_jk) to front a cluster of Tomcat servers. Something like this should balance load across the two nodes in your cluster with mod_proxy. Proxy balancer://mycluster BalancerMember http://localhost:8081 BalancerMember http://localhost:8083 /Proxy ProxyPass /dy balancer://mycluster/dy Dan Thanks, Nick - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problems with Clustering / Session Replication
On Tue, Sep 17, 2013 at 2:34 PM, Daniel Mikusa dmik...@gopivotal.comwrote: How do you have HTTPD configured? It's important to get this right. The tomcats are running on 8081 and 8083 and apache is listening on 8080 and 8082, with each one proxied to the corresponding tomcat instance. I think these are the relevant parts of httpd.conf, but let me know if there's something else you want to see: Listen 8080 Listen 8082 [...] NameVirtualHost *:8080 NameVirtualHost *:8082 [...] VirtualHost *:8080 DocumentRoot /var/www/ ServerName local.mysite.com ScriptAlias /cgi-bin/ /var/www/cgi-bin/ [...] ProxyPass/dy http://localhost:8081/dy max=100 ProxyPassReverse /dy http://localhost:8081/dy max=100 /VirtualHost VirtualHost *:8082 DocumentRoot /var/www/ ServerName local.mysite.com ScriptAlias /cgi-bin/ /var/www/cgi-bin/ [...] ProxyPass/dy http://localhost:8083/dy max=100 ProxyPassReverse /dy http://localhost:8083/dy max=100 /VirtualHost Thanks, Nick
Re: Problems with Clustering / Session Replication
On Sep 17, 2013, at 3:39 PM, Nicholas Violi nvi...@globalgiving.org wrote: On Tue, Sep 17, 2013 at 3:21 PM, Daniel Mikusa dmik...@gopivotal.comwrote: What is your purpose with this configuration and with this setup? It's a legit setup, but may not be doing what you want. Typically you would use mod_proxy mod_proxy_balancer (or mod_jk) to front a cluster of Tomcat servers. In production we have a dedicated hardware load balancer in front of standalone servers that each run one instance of apache connected to one tomcat, so when I was looking to extend that for local testing, I just added another VirtualHost. Since apache is not concerned with load balancing in production, I don't need to complicate my local system with that detail. I would disagree with this conclusion. In your test setup you absolutely need this. In production, you don't need HTTPD because you have a dedicated hardware load balancer. Unless you have one of those on your desk, you need HTTPD to perform that role. Dan Thanks, Nick - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problems with Clustering / Session Replication
On Tue, Sep 17, 2013 at 3:21 PM, Daniel Mikusa dmik...@gopivotal.comwrote: What is your purpose with this configuration and with this setup? It's a legit setup, but may not be doing what you want. Typically you would use mod_proxy mod_proxy_balancer (or mod_jk) to front a cluster of Tomcat servers. In production we have a dedicated hardware load balancer in front of standalone servers that each run one instance of apache connected to one tomcat, so when I was looking to extend that for local testing, I just added another VirtualHost. Since apache is not concerned with load balancing in production, I don't need to complicate my local system with that detail. Thanks, Nick
Re: Problems with Clustering / Session Replication
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nicholas, On 9/17/13 3:39 PM, Nicholas Violi wrote: On Tue, Sep 17, 2013 at 3:21 PM, Daniel Mikusa dmik...@gopivotal.comwrote: What is your purpose with this configuration and with this setup? It's a legit setup, but may not be doing what you want. Typically you would use mod_proxy mod_proxy_balancer (or mod_jk) to front a cluster of Tomcat servers. In production we have a dedicated hardware load balancer in front of standalone servers that each run one instance of apache connected to one tomcat, so when I was looking to extend that for local testing, I just added another VirtualHost. Since apache is not concerned with load balancing in production, I don't need to complicate my local system with that detail. If you want a less complicated setup, then take Apache httpd out of the equation entirely. If you already have load-balancing out front, what is httpd doing for you? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSOL9dAAoJEBzwKT+lPKRYVwoP/iuZYLTFbW7XRg9f5UYZNef7 RGe12De3v5uKMdLo7XjZlgszQfel/pCgBjzU21/QKJ+dZrdfgWPJ+FEQJJp+qSek MIuYhXzpnvOgmht3aYIud1SI+JwcvZO5Gbx3sDq+7tEzVzBS6u3WrtbUq51Vh2Dq lvdxLcr3qEB3tjEsCDjDpKZ7gHp5ZlXzPJz1UwBxZKTM2hBB1mP+uAaU0xjvQFyO eU8iJT48t9I8p6nNqLNoERt8mO81CTBcQw5Amc7c5VXHsJ1jaICDbOPazAU+uPkI ywWtBDw9E+c29qPftZqN2e7gnj3+pH0oqJBWxyG0mnMgMnAqO+KneUz9uzbqUrS0 1NPraHXB0EU3K4/hmHxjIRPLo3rrOt2akFppZzkVd0l0AvEnk5bS/d2DFcdGIvZR bnB3Ats2JWuKsjhDQNuXqaQeG6FcbGIZRbwUn4pkRvczDkQpwTkZGQCjPBdwAqWL 2wDYnERW5kJ4AnJjpx1MmKyZguWxCdj678TYx2m4pCKM6/rInPTtovRLTACeA1vX uyWdGxqet5r1DD168RGr1hU9wIGsqBGS1BVvS6LnFSz6Y1JMnw/hni+vn+adMTmh w9YDlzxb3i2kmsGaaqXM7EjmTfwNl5kJmQlZZSlj1BLvhN/NmE/L8EpNfdO/53vn rQeSn7qrM+RaWF6CNQuT =yCjK -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problems with Clustering / Session Replication
On Tue, Sep 17, 2013 at 4:18 PM, Daniel Mikusa dmik...@gopivotal.comwrote: I would disagree with this conclusion. In your test setup you absolutely need this. In production, you don't need HTTPD because you have a dedicated hardware load balancer. Unless you have one of those on your desk, you need HTTPD to perform that role. Since this is just for testing, my plan was to use the two alternate ports to mimic load balancing: I can interact with tomcat A on port 8080, then switch to 8082 and hopefully see the same session data on tomcat B. What benefit does apache load balancing bring to my testing of the clustering features?
Re: Problems with Clustering / Session Replication
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nicholas, On 9/17/13 4:33 PM, Nicholas Violi wrote: On Tue, Sep 17, 2013 at 4:18 PM, Daniel Mikusa dmik...@gopivotal.comwrote: I would disagree with this conclusion. In your test setup you absolutely need this. In production, you don't need HTTPD because you have a dedicated hardware load balancer. Unless you have one of those on your desk, you need HTTPD to perform that role. Since this is just for testing, my plan was to use the two alternate ports to mimic load balancing: I can interact with tomcat A on port 8080, then switch to 8082 and hopefully see the same session data on tomcat B. What benefit does apache load balancing bring to my testing of the clustering features? If you wanted to mimic load-balancing (meaning that you as a human arbitrarily choose which back-end instance to contact) then you didn't need Apache httpd in the mix: you can simply connect directly to whichever Tomcat you want. I think we're getting off-topic, though, as it seems the cluster membership is the problem and not loca-balancing and/or app-server-selection. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSOL/UAAoJEBzwKT+lPKRYITUQAMYsZ2jxr/9j8ECtNpR94mS0 jaNzkqHizcUm2B0RFMlqArrdZX6W+7IaaE4L2ZVTDvlBtXP8bYwkLFq/Irvv+g2E Y13SIzN9IIfR3+ZsYjOkDKeiEGo3z7nYaEhbB+wu3EIFjLIV4K88QTpcdCu8Q+uo D6OLtKOmqzUUJk/aLPCBV0OmiwK/BVdoLUMGG/prFaQohId+5ay7DFrukjKusDAb EtOtJe6nNdciAsj5jaQhpybOozoKHICiPJT4zURRfoXCUjD8nlCt6SwlMaKVCSVC 5HoO4LtVYbkUG3j8MeUiLXGoGqvNEmg+vEFB5MyAzeCqzzVokpvUi4Mfmj0k2/HQ IRSCoqZsrarFjT4JsUnMUV+r79xzJZpiz864F4Jyhatztb6dZpOZ3ZLUb0e8/0ft SUiK+a8Ao1m29LsEtSC9JrsDM6+NqOIk28c8hKl73dGOeYGhxDpJkpE09wlUcEB1 qEO/LOGFsdOBZuVOhFj6r9dYdWVvBMvGcm8BdDIhdlteGNcFJgoqFsXRAhDvORck DLDsvKSfT4DxyKcgnkBMcDg9x1JjVjk1Z9dZRMl/9fdhGCQFZhMin9ORTtsp2fx5 4bc5qs/NRUdtc1g4uNcAqUw9yAV++afpIhygLnN7JWtvjMVf63C4wtvR0oQPTE8H usbZAJrT1/yN/7ZBnZrf =2SwC -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problems with Clustering / Session Replication
On Sep 17, 2013, at 4:18 PM, Daniel Mikusa dmik...@gopivotal.com wrote: On Sep 17, 2013, at 3:39 PM, Nicholas Violi nvi...@globalgiving.org wrote: On Tue, Sep 17, 2013 at 3:21 PM, Daniel Mikusa dmik...@gopivotal.comwrote: What is your purpose with this configuration and with this setup? It's a legit setup, but may not be doing what you want. Typically you would use mod_proxy mod_proxy_balancer (or mod_jk) to front a cluster of Tomcat servers. In production we have a dedicated hardware load balancer in front of standalone servers that each run one instance of apache connected to one tomcat, so when I was looking to extend that for local testing, I just added another VirtualHost. Since apache is not concerned with load balancing in production, I don't need to complicate my local system with that detail. I would disagree with this conclusion. In your test setup you absolutely need this. In production, you don't need HTTPD because you have a dedicated hardware load balancer. Unless you have one of those on your desk, you need HTTPD to perform that role. Dan Disregard this. For some reason I was thinking HTTPD is necessary. Chris is right as usual, it's not necessary for a simple test. Tried a quick two node setup on my Mac w/out HTTPD and it worked OK. Go to one Tomcat instance's port in chrome, it increments the counter in my app. Refresh a few times. Open a second tab, go to the second Tomcat instance's port. The counter picks up where it left off and continues incrementing. Flipping back and forth between tabs / servers works fine. Here's the cluster config that I used in case it helps. Cluster channelSendOptions=8 className=org.apache.catalina.ha.tcp.SimpleTcpCluster Manager className=org.apache.catalina.ha.session.DeltaManager expireSessionsOnShutdown=false notifyListenersOnReplication=true/ Channel className=org.apache.catalina.tribes.group.GroupChannel Membership address=228.0.0.4 className=org.apache.catalina.tribes.membership.McastService dropTime=3000 frequency=500 port=45564/ Receiver address=auto autoBind=100 className=org.apache.catalina.tribes.transport.nio.NioReceiver maxThreads=6 port=4000 selectorTimeout=5000/ 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/ /Channel Valve className=org.apache.catalina.ha.tcp.ReplicationValve filter=/ Valve className=org.apache.catalina.ha.session.JvmRouteBinderValve/ ClusterListener className=org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener/ ClusterListener className=org.apache.catalina.ha.session.ClusterSessionListener/ /Cluster Beyond that, have you tried increasing the log levels? Dan Thanks, Nick - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
