Re: Clustering/Session Replication in docker swarm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Praveen, On 5/20/20 12:27, Praveen Kumar K S wrote: > Hello, > > I'm not sure if this is the right forum to ask this question. Since > this is a bigger community, I hope someone might have faced this > issue and hope I will get some help. > > I'm seeing many posts achieving Tomcat session replication in > docker swarm using traefik. But I just don't want to add another > component. I use httpd as frontend for tomcat. Tomcat will be > deployed as a service with 4 replicas and will be scaled when > required. httpd is running as docker service and both are in same > network. My question is, is there any way to achieve Tomcat session > replication in docker swarm in this case ? I'm not an auto-scaling guy, so this might be a stupid question: does Docker-swarm have its own orchestration service, or does it use something like Kubernetes? There is a "cloud" cluster membership manager which is currently undocumented but should be usable. The only current implementation is for a Kubernetes back-end, but I'm sure another implementation could be built for whatever orchestration scheme you have in your environment. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7IPCYACgkQHPApP6U8 pFhOdg/+NA7SMtLCml3WsLEtbM10HzbBU79qSfwsvoT+wZIduqYyhbXIehxxub6C rrwX6r+WMF2qxSwiHg8XT1LYBuq15x0YctHUzHA4CJ0iuaUVCsIaHJxT32Gh2BUe rAYsRH4THjqxCTMzRzr5FjMEPqicOm0l8B/LXStAjUJi2uX4UQqOhn5aFAAFoR2L r8P4xAj0Mlzr+XHAnzGWvXGULsEYJZZyAgZTpudJ40/l6pv50gKQK5qz5j3NRQSK YgFrixSMkzke6TvW6Mc+Kz/5y95XZ/xA+DG0C59+ulUsHKqf2Asy06Nk/4aGzdRt FdYGjAlCMeWMKRt2p6gseckNUxoZUx8VSwf1/0i6GQ//ynA1RBqmwblbHc6x0UCv AM2mBObvCjlbDlv0o/3Mdn4NR8iQfY12SWcbL0/VrjzqDI8nYoUk46pc1oIs2Ree 0nivzZd54k9ukT3oypm8wJl8eZYFdsYRXTIMabvxwe/CZAo8etgjqN3YaWy8gyrg cw1WydsFPBVEj+QtLlgiF9Q++sWOh1o7oQT1xp+EJ1v0zWeQnfxc2Cqt20IZtjUi RWDn8gD+VxpGYQlvS3IGLSSHZfepBKk0SEDrTZDbo+/TeDHWh6Plc/dBKWiUCzqY nqE3+HPAgIQpBpJu9je2pinNTMiRSFaG8AVhkQMk0Cd0empqdsA= =yEhA -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Clustering/Session Replication in docker swarm
Hello, I'm not sure if this is the right forum to ask this question. Since this is a bigger community, I hope someone might have faced this issue and hope I will get some help. I'm seeing many posts achieving Tomcat session replication in docker swarm using traefik. But I just don't want to add another component. I use httpd as frontend for tomcat. Tomcat will be deployed as a service with 4 replicas and will be scaled when required. httpd is running as docker service and both are in same network. My question is, is there any way to achieve Tomcat session replication in docker swarm in this case ?
Re: Problems with Clustering / Session Replication
On Oct 25, 2013, at 11:11 AM, Nicholas Violi wrote: > On Tue, Sep 24, 2013 at 5:21 PM, Daniel Mikusa wrote: >> >> 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 element out of the > element in server.xml and putting it > instead in the element of context.xml. > > So my context.xml now looks like this: > > > > xmlValidation="false" xmlNamespaceAware="false" > > > >WEB-INF/web.xml > > > expireSessionsOnShutdown="false" > notifyListenersOnReplication="true"/> > > > And server.xml still has the element inside , but > no longer has a element: > > > className="org.apache.catalina.ha.tcp.SimpleTcpCluster"> > className="org.apache.catalina.tribes.group.GroupChannel"> > > className="org.apache.catalina.tribes.membership.McastService" >dropTime="3000" >frequency="500" >port="45564"/> > autoBind="100" > > className="org.apache.catalina.tribes.transport.nio.NioReceiver" > maxThreads="6" > port="4000" > selectorTimeout="5000"/> > className="org.apache.catalina.tribes.transport.ReplicationTransmitter"> > className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/> > > className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/> > className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/> > > className="org.apache.catalina.ha.tcp.ReplicationValve" > filter=""/> > className="org.apache.catalina.ha.session.JvmRouteBinderValve"/> > className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/> > className="org.apache.catalina.ha.session.ClusterSessionListener"/> > > > > > > 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 tag defined in conf/context.xml or another context location? From the Cluster Manager tag docs... "The element defined inside the element is the template defined for all web applications that are marked in their web.xml file. However, you can still override the manager implementation on a per web application basis, by putting the inside the 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: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problems with Clustering / Session Replication
On Tue, Sep 24, 2013 at 5:21 PM, Daniel Mikusa wrote: > > 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 element out of the element in server.xml and putting it instead in the element of context.xml. So my context.xml now looks like this: WEB-INF/web.xml And server.xml still has the element inside , but no longer has a element: 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 wrote:
> On Thu, Sep 19, 2013 at 9:03 AM, Daniel Mikusa wrote:
>
>> Here's what I've been using:
>>
>>
>> WEB-INF/web.xml:
>>
>>
>> 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";>
>>
>>
>>
>>
>>
>>
>> index.jsp:
>>
>> <%
>>Integer count = (Integer) session.getAttribute("counter");
>>if (count == null) {
>>count = 0;
>>session.setAttribute("counter", 0);
>>} else {
>>session.setAttribute("counter", count + 1);
>>}
>> %>
>>
>>
>>Index
>>
>>
>>Session [<%= session.getId() %>]
>>Current count is <%= count %>
>>
>>
>>
>>
>> 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 wrote:
> Here's what I've been using:
>
>
> WEB-INF/web.xml:
>
>
> 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";>
>
>
>
>
>
>
> index.jsp:
>
> <%
> Integer count = (Integer) session.getAttribute("counter");
> if (count == null) {
> count = 0;
> session.setAttribute("counter", 0);
> } else {
> session.setAttribute("counter", count + 1);
> }
> %>
>
>
> Index
>
>
> Session [<%= session.getId() %>]
> Current count is <%= count %>
>
>
>
>
> 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 wrote:
> Thanks Daniel.
>
> On Tue, Sep 17, 2013 at 5:30 PM, Daniel Mikusa 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.
>>
>> >
>> className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
>>> className="org.apache.catalina.ha.session.DeltaManager"
>> expireSessionsOnShutdown="false"
>> notifyListenersOnReplication="true"/>
>>> className="org.apache.catalina.tribes.group.GroupChannel">
>>>
>> className="org.apache.catalina.tribes.membership.McastService"
>>dropTime="3000"
>>frequency="500"
>>port="45564"/>
>>> autoBind="100"
>>
>> className="org.apache.catalina.tribes.transport.nio.NioReceiver"
>> maxThreads="6"
>> port="4000"
>> selectorTimeout="5000"/>
>>> className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
>>> className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
>>
>>> className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
>>> className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
>>
>>> className="org.apache.catalina.ha.tcp.ReplicationValve"
>> filter=""/>
>>> className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
>>> className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/>
>>> className="org.apache.catalina.ha.session.ClusterSessionListener"/>
>>
>>
>
> 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:
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";>
index.jsp:
<%
Integer count = (Integer) session.getAttribute("counter");
if (count == null) {
count = 0;
session.setAttribute("counter", 0);
} else {
session.setAttribute("counter", count + 1);
}
%>
Index
Session [<%= session.getId() %>]
Current count is <%= count %>
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, 93, 96, -109, -4, 64,
-43, -70, 66, -70, -118, 104, 59, 39, 6} at 2013-09-19 09:02:07.929
19-Sep-2013 09:02:07.930 FINER [Tribes-Task-Receiver-3]
org.apache.catalina.trib
Re: Problems with Clustering / Session Replication
alternatively try an explicit address in the Receiver configuration 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 wrote: > 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 wrote: > >> On 9/18/2013 6:00 AM, Nicholas Violi wrote: >> >>> Thanks Daniel. >>> >>> On Tue, Sep 17, 2013 at 5:30 PM, Daniel Mikusa >> >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. >>> className="org.apache.**catalina.ha.tcp.**SimpleTcpCluster"> >>> className="org.apache.**catalina.ha.session.**DeltaManager" expireSessionsOnShutdown="**false" notifyListenersOnReplication="**true"/> >>> className="org.apache.**catalina.tribes.group.**GroupChannel"> >>> className="org.apache.**catalina.tribes.membership.**McastService" dropTime="3000" frequency="500" port="45564"/> >>>autoBind="100" className="org.apache.**catalina.tribes.transport.nio.**NioReceiver" maxThreads="6" port="4000" selectorTimeout="5000"/> >>> className="org.apache.**catalina.tribes.transport.** ReplicationTransmitter"> >>> className="org.apache.**catalina.tribes.transport.nio.** PooledParallelSender"/> >>> className="org.apache.**catalina.tribes.group.**interceptors.** TcpFailureDetector"/> >>> className="org.apache.**catalina.tribes.group.**interceptors.** MessageDispatch15Interceptor"/**> >>> className="org.apache.**catalina.ha.tcp.**ReplicationValve" filter=""/> >>> className="org.apache.**catalina.ha.session.**JvmRouteBinderValve"/> >>> className="org.apache.**catalina.ha.session.** JvmRouteSessionIDBinderListene**r"/> >>> className="org.apache.**catalina.ha.session.**ClusterSessionListener"/> >>> 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 a
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 wrote: > On 9/18/2013 6:00 AM, Nicholas Violi wrote: > >> Thanks Daniel. >> >> On Tue, Sep 17, 2013 at 5:30 PM, Daniel Mikusa > >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. >>> >>> >> >>> className="org.apache.**catalina.ha.tcp.**SimpleTcpCluster"> >>> >> className="org.apache.**catalina.ha.session.**DeltaManager" >>> expireSessionsOnShutdown="**false" >>> notifyListenersOnReplication="**true"/> >>> >> className="org.apache.**catalina.tribes.group.**GroupChannel"> >>> >> >>> className="org.apache.**catalina.tribes.membership.**McastService" >>> dropTime="3000" >>> frequency="500" >>> port="45564"/> >>> >>autoBind="100" >>> >>> className="org.apache.**catalina.tribes.transport.nio.**NioReceiver" >>>maxThreads="6" >>>port="4000" >>>selectorTimeout="5000"/> >>> >> className="org.apache.**catalina.tribes.transport.** >>> ReplicationTransmitter"> >>> >> className="org.apache.**catalina.tribes.transport.nio.** >>> PooledParallelSender"/> >>> >>> >> className="org.apache.**catalina.tribes.group.**interceptors.** >>> TcpFailureDetector"/> >>> >> className="org.apache.**catalina.tribes.group.**interceptors.** >>> MessageDispatch15Interceptor"/**> >>> >>> >> className="org.apache.**catalina.ha.tcp.**ReplicationValve" >>> filter=""/> >>> >> className="org.apache.**catalina.ha.session.**JvmRouteBinderValve"/> >>> >> className="org.apache.**catalina.ha.session.** >>> JvmRouteSessionIDBinderListene**r"/> >>> >> className="org.apache.**catalina.ha.session.**ClusterSessionListener"/> >>> >>> >>> >> 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.ju
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 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.
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 = 5cluster.org.apache.juli.FileHander
org.apache.catalina.ha.deploy.level = INFO
org.apache.catalina.ha.deploy.handlers =
5cluster.org.apache.juli.FileHandler
Set logging at the desired level.
I think I've posted this to the mailing list before . . .
/mde/
-
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
Thanks Daniel. On Tue, Sep 17, 2013 at 5:30 PM, Daniel Mikusa 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. > > > className="org.apache.catalina.ha.tcp.SimpleTcpCluster"> > className="org.apache.catalina.ha.session.DeltaManager" > expireSessionsOnShutdown="false" > notifyListenersOnReplication="true"/> > className="org.apache.catalina.tribes.group.GroupChannel"> > > className="org.apache.catalina.tribes.membership.McastService" > dropTime="3000" > frequency="500" > port="45564"/> >autoBind="100" > > className="org.apache.catalina.tribes.transport.nio.NioReceiver" > maxThreads="6" > port="4000" > selectorTimeout="5000"/> > className="org.apache.catalina.tribes.transport.ReplicationTransmitter"> > className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/> > > className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/> > className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/> > > className="org.apache.catalina.ha.tcp.ReplicationValve" >filter=""/> > className="org.apache.catalina.ha.session.JvmRouteBinderValve"/> > className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/> > className="org.apache.catalina.ha.session.ClusterSessionListener"/> > > 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 Sep 17, 2013, at 4:18 PM, Daniel Mikusa wrote: > On Sep 17, 2013, at 3:39 PM, Nicholas Violi wrote: > >> On Tue, Sep 17, 2013 at 3:21 PM, Daniel Mikusa wrote: >> >>> 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. 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
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 > wrote: > >> 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 Tue, Sep 17, 2013 at 4:18 PM, Daniel Mikusa wrote: > 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 3:39 PM, Nicholas Violi wrote: > On Tue, Sep 17, 2013 at 3:21 PM, Daniel Mikusa > wrote: > >> 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 3:21 PM, Daniel Mikusa wrote: > 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
On Sep 17, 2013, at 3:39 PM, Nicholas Violi wrote: > On Tue, Sep 17, 2013 at 3:21 PM, Daniel Mikusa wrote: > >> 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 Sep 17, 2013, at 3:08 PM, Nicholas Violi wrote: > On Tue, Sep 17, 2013 at 2:34 PM, Daniel Mikusa wrote: > >> 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 > [...] > >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 > > > >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 > 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. BalancerMember http://localhost:8081 BalancerMember http://localhost:8083 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 wrote: > 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 [...] 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 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 Thanks, Nick
Re: Problems with Clustering / Session Replication
On Sep 17, 2013, at 1:21 PM, Nicholas Violi 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 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
> 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
> 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
On Tue, Sep 17, 2013 at 12:08 PM, Daniel Mikusa wrote: > 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
-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
> 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
On Sep 17, 2013, at 11:32 AM, Nicholas Violi wrote: > On Tue, Sep 17, 2013 at 11:25 AM, Daniel Mikusa wrote: > >> >> 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
On Tue, Sep 17, 2013 at 11:25 AM, Daniel Mikusa wrote: > > 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:10 AM, Nicholas Violi 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 wrote: > >> On Sep 17, 2013, at 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. >> >> 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: >>> >>> >>channelSendOptions="8"> >>> >>> >> expireSessionsOnShutdown="false" >>> notifyListenersOnReplication="true"/> >>> >>> >>> >> className="org.apache.catalina.tribes.membership.McastService" >>> address="228.0.0.4" >>> port="45564" >>> frequency="500" >>> dropTime="3000"/> >>> >> className="org.apache.catalina.tribes.transport.nio.NioReceiver" >>> address="auto" >>> port="4001" >>> autoBind="100" >>> selectorTimeout="5000" >>> maxThreads="6"/> >>> >>> >> className="org.apache.catalina.tribes.transport.ReplicationTransmitter"> >>> >> >> className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/> >>> >>> >> >> className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/> >>> >> >> className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/> >>> >> >> className="org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor"/> >>> >>> >>> >>filter=""/> >>> >> className="org.apache.catalina.ha.session.JvmRouteBinderValve"/> >>> >>> >> className="org.apache.catalina.ha.session.ClusterSessionListener"/> >>> >> >> 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: >>> >>> 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"> >>> >>> >>> (lots more...) >>> >>> >>> >>> ___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
Re: Problems with Clustering / Session Replication
On Sep 17, 2013, at 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.
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:
>
>channelSendOptions="8">
>
> expireSessionsOnShutdown="false"
> notifyListenersOnReplication="true"/>
>
>
> className="org.apache.catalina.tribes.membership.McastService"
>address="228.0.0.4"
>port="45564"
>frequency="500"
>dropTime="3000"/>
> className="org.apache.catalina.tribes.transport.nio.NioReceiver"
> address="auto"
> port="4001"
> autoBind="100"
> selectorTimeout="5000"
> maxThreads="6"/>
>
> className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
> className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
>
> className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
> className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
> className="org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor"/>
>
>
> filter=""/>
> className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
>
> className="org.apache.catalina.ha.session.ClusterSessionListener"/>
>
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:
>
> 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">
>
>
> (lots more...)
>
>
>
> ___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.ap
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 wrote: > On Sep 17, 2013, at 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. > > 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: > > > >> channelSendOptions="8"> > > > > > expireSessionsOnShutdown="false" > > notifyListenersOnReplication="true"/> > > > > > > > className="org.apache.catalina.tribes.membership.McastService" > >address="228.0.0.4" > >port="45564" > >frequency="500" > >dropTime="3000"/> > > > className="org.apache.catalina.tribes.transport.nio.NioReceiver" > > address="auto" > > port="4001" > > autoBind="100" > > selectorTimeout="5000" > > maxThreads="6"/> > > > > > className="org.apache.catalina.tribes.transport.ReplicationTransmitter"> > > > > className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/> > > > > > > className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/> > > > > className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/> > > > > className="org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor"/> > > > > > > > filter=""/> > > > className="org.apache.catalina.ha.session.JvmRouteBinderValve"/> > > > > > className="org.apache.catalina.ha.session.ClusterSessionListener"/> > > > > 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: > > > > 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"> > > > > > > (lots more...) > > > > > > > > ___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 >
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
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:
and I added the distributable tag to the very beginning of web.xml:
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">
(lots more...)
___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 member
added:org.apache.catalina.tribes.membership.MemberImpl[tcp://{10, 0, 0,
100}:4001,{10, 0, 0, 100},4001, alive=1011, 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={}, ]
and when one is shutdown, the other one logs
Sep 16, 2013 2:28:05 PM
org.apache.catalina.tribes.membership.McastServiceImpl memberDataReceived
FINE: Member has
shutdown:org.apache.catalina.tribes.membership.MemberImpl[tcp://{10, 0, 0,
100}:4001,{10, 0, 0, 100},4001, alive=422279, securePort=-1, UDP Port=-1,
id={54 43 17 -9 13 -11 72 -63 -107 -78 -8 65 -21 -77 115 88 }, payload={},
command={66 65 66 89 45 65 76 69 88 ...(9)}, domain={}, ]
Sep 16, 2013 2:28:05 PM
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared
INFO: Verification complete. Member
disappeared[org.apache.catalina.tribes.membership.MemberImpl[tcp://{10, 0,
0, 100}:4001,{10, 0, 0, 100},4001, alive=422279, securePort=-1, UDP
Port=-1, id={54 43 17 -9 13 -11 72 -63 -107 -78 -8 65 -21 -77 115 88 },
payload={}, command={66 65 66 89 45 65 76 69 88 ...(9)}, domain={}, ]]
Sep 16, 2013 2:28:05 PM org.apache.catalina.ha.tcp.SimpleTcpCluster
memberDisappeared
INFO: Received member
disappeared:org.apache.catalina.tribes.membership.MemberImpl[tcp://{10, 0,
0, 100}:4001,{10, 0, 0, 100},4001, alive=422279, securePort=-1, UDP
Port=-1, id={54 43 17 -9 13 -11 72 -63 -107 -78 -8 65 -21 -77 115 88 },
payload={}, com
Re: Clustering: Session replication
For each Tomcat set http://tomcat.apache.org/tomcat-6.0-doc/config/cluster-receiver.html that way you broad cast your-ip-goes-here instead. alternatively, setup your hostname properly, and make sure the hostname resolves to the IP address, and not 127.0.0.1 Filip Jorge Medina wrote: Hi, I am trying to configure session replication using the object. The documentation says: "The IP broadcasted is java.net.InetAddress.getLocalHost().getHostAddress() (make sure you don't broadcast 127.0.0.1, this is a common error)" I just wrote a small java program to see what my system return for java.net.InetAddress.getLocalHost().getHostAddress() It returns 127.0.0.1 Is this something that needs to be changed by modifying the network configuration of the box? -Jorge - 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: Clustering: Session replication
I am using a virtual environment. My machine did not have an entry for its IP address in /etc/hosts I added the IP address with the name returned by the shell command `hostname` I think this probably would be resolved via DNS in a regular envionment...but for now I am set. Thanks -Jorge -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: Tuesday, February 10, 2009 4:34 PM To: Tomcat Users List Subject: RE: Clustering: Session replication > From: Jorge Medina [mailto:jmed...@e-dialog.com] > Subject: FW: Clustering: Session replication > > According to the Javadoc, InetAddress.getLocalHost() returns the > loopback address. No, it doesn't; the sentence in question reads: "If the operation is not allowed, an InetAddress representing the loopback address is returned." You seem to have ignored the first clause in the sentence. InetAddress.getLocalHost().getHostAddress() gets me an external IP address on every system I can find. - 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Clustering: Session replication
> From: Jorge Medina [mailto:jmed...@e-dialog.com] > Subject: FW: Clustering: Session replication > > According to the Javadoc, InetAddress.getLocalHost() returns the > loopback address. No, it doesn't; the sentence in question reads: "If the operation is not allowed, an InetAddress representing the loopback address is returned." You seem to have ignored the first clause in the sentence. InetAddress.getLocalHost().getHostAddress() gets me an external IP address on every system I can find. - 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
FW: Clustering: Session replication
According to the Javadoc, InetAddress.getLocalHost() returns the loopback address. So...how do I control the broadcasting address ? -Original Message- From: Jorge Medina Sent: Tuesday, February 10, 2009 3:38 PM To: 'users@tomcat.apache.org' Subject: Clustering: Session replication Hi, I am trying to configure session replication using the object. The documentation says: "The IP broadcasted is java.net.InetAddress.getLocalHost().getHostAddress() (make sure you don't broadcast 127.0.0.1, this is a common error)" I just wrote a small java program to see what my system return for java.net.InetAddress.getLocalHost().getHostAddress() It returns 127.0.0.1 Is this something that needs to be changed by modifying the network configuration of the box? -Jorge - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Clustering: Session replication
Hi, I am trying to configure session replication using the object. The documentation says: "The IP broadcasted is java.net.InetAddress.getLocalHost().getHostAddress() (make sure you don't broadcast 127.0.0.1, this is a common error)" I just wrote a small java program to see what my system return for java.net.InetAddress.getLocalHost().getHostAddress() It returns 127.0.0.1 Is this something that needs to be changed by modifying the network configuration of the box? -Jorge - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: clustering: session replication
Here it is. Only difference between server.xml in first tomcat instance and second instance is jvmRoute="jvm1" and jvmRoute="jvm2". This web app uses iframes in order to upload files without reloading the whole page. I found that this is somehow related to the issue, but still could not spot what exactly is causing it. Ajax might also be related. Thanks for the tip on logging. Could not find any evidence of sth going wrong with replication, though. I know replication is working in a failover scenario. Any suggestions? Many thanks. - Original Message From: Filip Hanik - Dev Lists <[EMAIL PROTECTED]> To: Tomcat Users List Sent: Tuesday, July 22, 2008 7:30:34 PM Subject: Re: clustering: session replication also, post your configuration, to make sure you have it right (server.xml and context.xml) Filip nch wrote: > Hello, again. > Well, I'm asking about how to enable cluster logging because I'm running an > apache/mod_jk balanced two node cluster (without sticky session). > Whenever a request is being sent to a tomcat different than the one which > started the session, then the session is lost. Btw, > this is an ajax application (dwr). > This was working perfectly well when using sticky session, but now I have the > requirement not to use it. That is, before, when one of the two tomcats went > down, then the other one would keep the session. > > I'm running tomcat 6.0.13/jdk 1.6/debian etch > > Any clues on how to tackle this issue? > Kind regards. > > > > - Original Message > From: nch <[EMAIL PROTECTED]> > To: Tomcat Users List > Sent: Tuesday, July 22, 2008 12:27:13 PM > Subject: Re: clustering: session replication > > > Sorry, I'm running 6.0.13. Does it work the same? > > > > - Original Message ---- > From: Peter Rossbach <[EMAIL PROTECTED]> > To: Tomcat Users List > Sent: Tuesday, July 22, 2008 11:10:04 AM > Subject: Re: clustering: session replication > > Hi, > > at tomcat 5.5 cluster you can use the cluster logging. Look at tomcat > docs > > http://tomcat.apache.org/tomcat-5.5-doc/cluster-howto.html > > className="org.apache.catalina.cluster.tcp.SimpleTcpCluster" > doClusterLog="true" > clusterLogName="clusterlog" > ... > > Peter > > > Am 22.07.2008 um 09:07 schrieb nch: > > >> Hi, there. >> Does anyone know how to trace session replication in a cluster? >> >> Thank you. >> >> >> >> > > > - > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > No virus found in this incoming message. > Checked by AVG. > Version: 7.5.526 / Virus Database: 270.5.3/1565 - Release Date: 7/21/2008 > 6:36 PM > - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] WEB-INF/web.xml - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: clustering: session replication
also, post your configuration, to make sure you have it right (server.xml and context.xml) Filip nch wrote: Hello, again. Well, I'm asking about how to enable cluster logging because I'm running an apache/mod_jk balanced two node cluster (without sticky session). Whenever a request is being sent to a tomcat different than the one which started the session, then the session is lost. Btw, this is an ajax application (dwr). This was working perfectly well when using sticky session, but now I have the requirement not to use it. That is, before, when one of the two tomcats went down, then the other one would keep the session. I'm running tomcat 6.0.13/jdk 1.6/debian etch Any clues on how to tackle this issue? Kind regards. - Original Message From: nch <[EMAIL PROTECTED]> To: Tomcat Users List Sent: Tuesday, July 22, 2008 12:27:13 PM Subject: Re: clustering: session replication Sorry, I'm running 6.0.13. Does it work the same? - Original Message From: Peter Rossbach <[EMAIL PROTECTED]> To: Tomcat Users List Sent: Tuesday, July 22, 2008 11:10:04 AM Subject: Re: clustering: session replication Hi, at tomcat 5.5 cluster you can use the cluster logging. Look at tomcat docs http://tomcat.apache.org/tomcat-5.5-doc/cluster-howto.html className="org.apache.catalina.cluster.tcp.SimpleTcpCluster" doClusterLog="true" clusterLogName="clusterlog" ... Peter Am 22.07.2008 um 09:07 schrieb nch: Hi, there. Does anyone know how to trace session replication in a cluster? Thank you. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] No virus found in this incoming message. Checked by AVG. Version: 7.5.526 / Virus Database: 270.5.3/1565 - Release Date: 7/21/2008 6:36 PM - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: clustering: session replication
in tomcat 6, you configure it using logging.properties for example org.apache.catalina.ha.level=FINE org.apache.catalina.tribes.level=FINE Filip nch wrote: Sorry, I'm running 6.0.13. Does it work the same? - Original Message From: Peter Rossbach <[EMAIL PROTECTED]> To: Tomcat Users List Sent: Tuesday, July 22, 2008 11:10:04 AM Subject: Re: clustering: session replication Hi, at tomcat 5.5 cluster you can use the cluster logging. Look at tomcat docs http://tomcat.apache.org/tomcat-5.5-doc/cluster-howto.html className="org.apache.catalina.cluster.tcp.SimpleTcpCluster" doClusterLog="true" clusterLogName="clusterlog" ... Peter Am 22.07.2008 um 09:07 schrieb nch: Hi, there. Does anyone know how to trace session replication in a cluster? Thank you. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] No virus found in this incoming message. Checked by AVG. Version: 7.5.526 / Virus Database: 270.5.3/1565 - Release Date: 7/21/2008 6:36 PM - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: clustering: session replication
Hello, again. Well, I'm asking about how to enable cluster logging because I'm running an apache/mod_jk balanced two node cluster (without sticky session). Whenever a request is being sent to a tomcat different than the one which started the session, then the session is lost. Btw, this is an ajax application (dwr). This was working perfectly well when using sticky session, but now I have the requirement not to use it. That is, before, when one of the two tomcats went down, then the other one would keep the session. I'm running tomcat 6.0.13/jdk 1.6/debian etch Any clues on how to tackle this issue? Kind regards. - Original Message From: nch <[EMAIL PROTECTED]> To: Tomcat Users List Sent: Tuesday, July 22, 2008 12:27:13 PM Subject: Re: clustering: session replication Sorry, I'm running 6.0.13. Does it work the same? - Original Message From: Peter Rossbach <[EMAIL PROTECTED]> To: Tomcat Users List Sent: Tuesday, July 22, 2008 11:10:04 AM Subject: Re: clustering: session replication Hi, at tomcat 5.5 cluster you can use the cluster logging. Look at tomcat docs http://tomcat.apache.org/tomcat-5.5-doc/cluster-howto.html > Hi, there. > Does anyone know how to trace session replication in a cluster? > > Thank you. > > > - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: clustering: session replication
Sorry, I'm running 6.0.13. Does it work the same? - Original Message From: Peter Rossbach <[EMAIL PROTECTED]> To: Tomcat Users List Sent: Tuesday, July 22, 2008 11:10:04 AM Subject: Re: clustering: session replication Hi, at tomcat 5.5 cluster you can use the cluster logging. Look at tomcat docs http://tomcat.apache.org/tomcat-5.5-doc/cluster-howto.html > Hi, there. > Does anyone know how to trace session replication in a cluster? > > Thank you. > > > - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: clustering: session replication
Hi, at tomcat 5.5 cluster you can use the cluster logging. Look at tomcat docs http://tomcat.apache.org/tomcat-5.5-doc/cluster-howto.html className="org.apache.catalina.cluster.tcp.SimpleTcpCluster" doClusterLog="true" clusterLogName="clusterlog" ... Peter Am 22.07.2008 um 09:07 schrieb nch: Hi, there. Does anyone know how to trace session replication in a cluster? Thank you. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
clustering: session replication
Hi, there. Does anyone know how to trace session replication in a cluster? Thank you.
Re: Clustering/Session Replication
There are some advantages and you can gain higher availability and therefore improved performance from clustering a single machine. In my little apps I use terracotta. Open source Java clustering tool that lets me acheive a pretty good distributed cache without manually rewriting code to work with more than one JVM. They have thei great tool in the management console that helps performance tuning. check 'em out. The download comes with examples that are actually fun to play with. terracotta.org Dwayne Individual On 8/24/07, Andrew Hole <[EMAIL PROTECTED]> wrote: > > Hello! > > What's benefits of using Clustering/Session Replication on same machine? > > Thanks a lot >
Re: Clustering/Session Replication
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew, Andrew Hole wrote: > What's benefits of using Clustering/Session Replication on same machine? If you have a really buggy application that crashes a lot, clustering and session replication can buy you some robustness that your engineers have not been able to provide. Performance-wise, it's not a very good idea. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGztq99CaO5/Lv0PARArGjAKC1NH+rPhlKI8QznZ0aMhpOleSztACfVJ+x XcfvDnkvGzylN6uCWwg2Cx8= =2kOs -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Clustering/Session Replication
Hello! What's benefits of using Clustering/Session Replication on same machine? Thanks a lot
