Re: [EXT]Re: [EXT]Re: Tomcat 10 session replication fails
Rick, On 4/15/24 08:12, Rick Noel wrote: Hi Chuck, Your suggestion did not work. I defined Membership as suggested... and still getting this in the logs org.apache.catalina.ha.session.DeltaManager.startInternal Starting clustering manager at [##0001] 15-Apr-2024 07:55:36.744 INFO [main] org.apache.catalina.ha.session.DeltaManager.getAllClusterSessions Manager [##0001]: skipping state transfer. No members active in cluster group Do you think the transfer is not happening because the application is only on one machine? Our Production environment will have our application on two machines but in our dev environment we have only one machine in the "cluster". So we really do not have a "cluster" environment. Again, we would like to know is going on before we introduce clustering in our live environment. We are using Java 17 and Tomcat 10 I've never set up replication in Tomcat, so I may be speaking out of turn. But is it possible that since you have only a single node (right?), Tomcat is really saying "skipping state transfer. No [other] members active in cluster group"? -chris -Original Message- From: Chuck Caldarale Sent: Saturday, April 13, 2024 4:00 PM To: Tomcat Users List Subject: [EXT]Re: [EXT]Re: Tomcat 10 session replication fails On Apr 11, 2024, at 09:07, Rick Noel wrote: We are getting closer Changing ports from the 5000 range to the 4000 range stopped two errors But now I get this.. INFO: Manager [##0001]: skipping state transfer. No members active in cluster group How to I make the member machine in the cluster active? There’s a cluster configuration option that may be coming into play here: localLoopbackDisabled. Once upon a time, the JDK method: MulticastSocket.setLoopbackMode(boolean disable) did the opposite of what one might think from just the method name - passing in true disabled local receipt of multicast packets. That method has since been deprecated, and Tomcat currently uses this method: DatagramSocket.setOption(SocketOption name, T value) which, at least in Java 21, operates as you might expect from the name - specifying true enables multicast loopback. However, there’s some interesting logic in Tomcat's handling of localLoopbackDisabled that can inverts the config value based on the Java level, along with this comment: Java < 14, a value of true means loopback is disabled. Java 14+ a value of true means loopback is enabled. Having not dug into the JRE source code for the various Java versions, I’m not yet convinced the version checking logic is correct. You might try setting localLoopbackDisabled to true in your config to see if that has an effect on your dev system. Also, let us know what Java version you’re using. - Chuck - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you know the sender and you are sure the content is safe. Please report the message using the Report Message feature in your email client if you believe the email is suspicious. - 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: [EXT]Re: [EXT]Re: Tomcat 10 session replication fails
Hi Chuck, Your suggestion did not work. I defined Membership as suggested... and still getting this in the logs org.apache.catalina.ha.session.DeltaManager.startInternal Starting clustering manager at [##0001] 15-Apr-2024 07:55:36.744 INFO [main] org.apache.catalina.ha.session.DeltaManager.getAllClusterSessions Manager [##0001]: skipping state transfer. No members active in cluster group Do you think the transfer is not happening because the application is only on one machine? Our Production environment will have our application on two machines but in our dev environment we have only one machine in the "cluster". So we really do not have a "cluster" environment. Again, we would like to know is going on before we introduce clustering in our live environment. We are using Java 17 and Tomcat 10 Rick Noel Systems Programmer | Westwood One rn...@westwoodone.com -Original Message- From: Chuck Caldarale Sent: Saturday, April 13, 2024 4:00 PM To: Tomcat Users List Subject: [EXT]Re: [EXT]Re: Tomcat 10 session replication fails > On Apr 11, 2024, at 09:07, Rick Noel wrote: > > We are getting closer > Changing ports from the 5000 range to the 4000 range stopped two > errors But now I get this.. > > INFO: Manager [##0001]: skipping state transfer. No members active in > cluster group > > How to I make the member machine in the cluster active? There’s a cluster configuration option that may be coming into play here: localLoopbackDisabled. Once upon a time, the JDK method: MulticastSocket.setLoopbackMode(boolean disable) did the opposite of what one might think from just the method name - passing in true disabled local receipt of multicast packets. That method has since been deprecated, and Tomcat currently uses this method: DatagramSocket.setOption(SocketOption name, T value) which, at least in Java 21, operates as you might expect from the name - specifying true enables multicast loopback. However, there’s some interesting logic in Tomcat's handling of localLoopbackDisabled that can inverts the config value based on the Java level, along with this comment: Java < 14, a value of true means loopback is disabled. Java 14+ a value of true means loopback is enabled. Having not dug into the JRE source code for the various Java versions, I’m not yet convinced the version checking logic is correct. You might try setting localLoopbackDisabled to true in your config to see if that has an effect on your dev system. Also, let us know what Java version you’re using. - Chuck - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you know the sender and you are sure the content is safe. Please report the message using the Report Message feature in your email client if you believe the email is suspicious. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [EXT]Re: Tomcat 10 session replication fails
Sort of off topic, but sort of related. If you're having tremendous trouble using the built in replication methods, we built a redis based session manager: https://github.com/exabrial/redex-sm Currently redex-sm only works with Tomcat 8.5, but it wouldn't be a big leap to make it work with Tomcat 10. The advantage of using Redis to store your sessions is it's a well trodden path to set up a replicated Redis cluster, you have a lot of tooling around exploring sessions stored inside there, and you can store hundreds-of-thousands of sessions, or even set them to absurd timeouts (weeks). I hate to see people struggle with session replication, as I think it really is the secret to making server-side-rendering scale out. On Sat, Apr 13, 2024 at 3:01 PM Chuck Caldarale wrote: > > > > On Apr 11, 2024, at 09:07, Rick Noel wrote: > > > > We are getting closer > > Changing ports from the 5000 range to the 4000 range stopped two errors > > But now I get this.. > > > > INFO: Manager [##0001]: skipping state transfer. No members active in > > cluster group > > > > How to I make the member machine in the cluster active? > > > There’s a cluster configuration option that may be coming into play here: > localLoopbackDisabled. Once upon a time, the JDK method: > MulticastSocket.setLoopbackMode(boolean disable) > did the opposite of what one might think from just the method name - passing > in true disabled local receipt of multicast packets. That method has since > been deprecated, and Tomcat currently uses this method: > DatagramSocket.setOption(SocketOption name, T value) > which, at least in Java 21, operates as you might expect from the name - > specifying true enables multicast loopback. > > However, there’s some interesting logic in Tomcat's handling of > localLoopbackDisabled that can inverts the config value based on the Java > level, along with this comment: > Java < 14, a value of true means loopback is disabled. Java 14+ a > value of true means loopback is enabled. > > Having not dug into the JRE source code for the various Java versions, I’m > not yet convinced the version checking logic is correct. You might try > setting localLoopbackDisabled to true in your config to see > if that has an effect on your dev system. > > Also, let us know what Java version you’re using. > > - Chuck > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > -- Jonathan | exabr...@gmail.com Pessimists, see a jar as half empty. Optimists, in contrast, see it as half full. Engineers, of course, understand the glass is twice as big as it needs to be. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [EXT]Re: Tomcat 10 session replication fails
> On Apr 11, 2024, at 09:07, Rick Noel wrote: > > We are getting closer > Changing ports from the 5000 range to the 4000 range stopped two errors > But now I get this.. > > INFO: Manager [##0001]: skipping state transfer. No members active in cluster > group > > How to I make the member machine in the cluster active? There’s a cluster configuration option that may be coming into play here: localLoopbackDisabled. Once upon a time, the JDK method: MulticastSocket.setLoopbackMode(boolean disable) did the opposite of what one might think from just the method name - passing in true disabled local receipt of multicast packets. That method has since been deprecated, and Tomcat currently uses this method: DatagramSocket.setOption(SocketOption name, T value) which, at least in Java 21, operates as you might expect from the name - specifying true enables multicast loopback. However, there’s some interesting logic in Tomcat's handling of localLoopbackDisabled that can inverts the config value based on the Java level, along with this comment: Java < 14, a value of true means loopback is disabled. Java 14+ a value of true means loopback is enabled. Having not dug into the JRE source code for the various Java versions, I’m not yet convinced the version checking logic is correct. You might try setting localLoopbackDisabled to true in your config to see if that has an effect on your dev system. Also, let us know what Java version you’re using. - Chuck - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [EXT]Re: Tomcat 10 session replication fails
Thanks Chuck, We are getting closer Changing ports from the 5000 range to the 4000 range stopped two errors But now I get this.. INFO: Manager [##0001]: skipping state transfer. No members active in cluster group How to I make the member machine in the cluster active? Rick Noel Systems Programmer | Westwood One rn...@westwoodone.com -Original Message- From: Chuck Caldarale Sent: Thursday, April 11, 2024 9:14 AM To: Tomcat Users List Subject: [EXT]Re: Tomcat 10 session replication fails [You don't often get email from n82...@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > On Apr 11, 2024, at 07:56, Rick Noel wrote: > > We have our app running on Tomcat10 and doing clustering,but are getting the > following errors seen int the Catalina log... > > Apr 11, 2024 8:14:43 AM org.apache.catalina.ha.session.DeltaManager > waitForSendAllSessions > SEVERE: Manager [##0001]: No session state sent at [4/11/24, 8:13 AM] > received, timing out after [60,068] ms. > Apr 11, 2024 8:14:43 AM org.apache.catalina.ha.session.DeltaManager > getAllClusterSessions > WARNING: Manager [##0001]: Drop message [SESSION-GET-ALL] inside > GET_ALL_SESSIONS sync phase start date [4/11/24, 8:13 AM] message date > [4/11/24, 8:13 AM] > 11-Apr-2024 08:14:43.456 > > The error, to me, indicates that the session data is not being sent out. > > We are running this app in our dev environment, and in this dev environment > the app runs on only one machine. > In our live environment the app runs on two machines and traffic goes through > a load balancer. > This may be a dumb question but are we getting these errors because we are > running the app on only one machine, and clustering cannot be done on one > machine? Likely. From the Tomcat clustering doc: If your Tomcat instances are running on the same machine, make sure the Receiver.port attribute is unique for each instance, in most cases Tomcat is smart enough to resolve this on it's own by autodetecting available ports in the range 4000-4100 You appear to have configured 5001 as the receiver port on both. > > className="org.apache.catalina.tribes.membership.McastService" > > address="228.0.0.4" > > port="45565" > > frequency="500" > > dropTime="3000"/> > > className="org.apache.catalina.tribes.transport.nio.NioReceiver" > > address="auto" > > port="5001" > > selectorTimeout="100" > > maxThreads="6"/> - Chuck CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you know the sender and you are sure the content is safe. Please report the message using the Report Message feature in your email client if you believe the email is suspicious. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 10 session replication fails
> On Apr 11, 2024, at 07:56, Rick Noel wrote: > > We have our app running on Tomcat10 and doing clustering,but are getting the > following errors seen int the Catalina log... > > Apr 11, 2024 8:14:43 AM org.apache.catalina.ha.session.DeltaManager > waitForSendAllSessions > SEVERE: Manager [##0001]: No session state sent at [4/11/24, 8:13 AM] > received, timing out after [60,068] ms. > Apr 11, 2024 8:14:43 AM org.apache.catalina.ha.session.DeltaManager > getAllClusterSessions > WARNING: Manager [##0001]: Drop message [SESSION-GET-ALL] inside > GET_ALL_SESSIONS sync phase start date [4/11/24, 8:13 AM] message date > [4/11/24, 8:13 AM] > 11-Apr-2024 08:14:43.456 > > The error, to me, indicates that the session data is not being sent out. > > We are running this app in our dev environment, and in this dev environment > the app runs on only one machine. > In our live environment the app runs on two machines and traffic goes through > a load balancer. > This may be a dumb question but are we getting these errors because we are > running the app on only one machine, and clustering cannot be done on one > machine? Likely. From the Tomcat clustering doc: If your Tomcat instances are running on the same machine, make sure the Receiver.port attribute is unique for each instance, in most cases Tomcat is smart enough to resolve this on it's own by autodetecting available ports in the range 4000-4100 You appear to have configured 5001 as the receiver port on both. > > className="org.apache.catalina.tribes.membership.McastService" > > address="228.0.0.4" > > port="45565" > > frequency="500" > > dropTime="3000"/> > > className="org.apache.catalina.tribes.transport.nio.NioReceiver" > > address="auto" > > port="5001" > > selectorTimeout="100" > > maxThreads="6”/> - Chuck
Tomcat 10 session replication fails
Hi, We have our app running on Tomcat10 and doing clustering,but are getting the following errors seen int the Catalina log... Apr 11, 2024 8:14:43 AM org.apache.catalina.ha.session.DeltaManager waitForSendAllSessions SEVERE: Manager [##0001]: No session state sent at [4/11/24, 8:13 AM] received, timing out after [60,068] ms. Apr 11, 2024 8:14:43 AM org.apache.catalina.ha.session.DeltaManager getAllClusterSessions WARNING: Manager [##0001]: Drop message [SESSION-GET-ALL] inside GET_ALL_SESSIONS sync phase start date [4/11/24, 8:13 AM] message date [4/11/24, 8:13 AM] 11-Apr-2024 08:14:43.456 The error, to me, indicates that the session data is not being sent out. We are running this app in our dev environment, and in this dev environment the app runs on only one machine. In our live environment the app runs on two machines and traffic goes through a load balancer. This may be a dumb question but are we getting these errors because we are running the app on only one machine, and clustering cannot be done on one machine? We need to better understand these errors before we can move to tomcat 10 clustering into our live 2 machine environment This is how we have clustering defined in the server.xml... Rick Noel Systems Programmer | Westwood One rn...@westwoodone.com
RE: [EXT]Re: Tomcat session replication issue - java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute :
Thank you very much Chris
The classes my app uses should be serialize anyway so I just go that route.
But thanks for that code snippet too
Rick Noel
Systems Programmer | Westwood One
rn...@westwoodone.com
-Original Message-
From: Christopher Schultz
Sent: Friday, March 22, 2024 2:36 PM
To: Tomcat Users List ; Rick Noel
Subject: Re: [EXT]Re: Tomcat session replication issue -
java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute :
Rick,
On 3/22/24 13:33, Rick Noel wrote:
> I do not want to replicate customer because that class does not
> implement serializable
>
> I was looking for someway that the Manager would NOT try to replicate
> it
This is an allow-list which is much more secure than a deny-list.
It's a regular expression, so you can feel free to get super-creative with the
expression if you want to effectively create a deny-list with one item.
Honestly, this is probably some technical dept worth paying off at this point.
Another option would be to store the object in a wrapper in the session that
*is* serializable but it doesn't actually try to serialize the object it wraps.
I did one of these ages ago for similar reasons: I didn't want to go change all
those classes to be Serializable. Here it is:
public class TransientObjectWrapper
implements Serializable
{
private static final long serialVersionUID = -4694896879363833304L;
private transient final T _o;
public TransientObjectWrapper(T o) { _o = o; }
public T getWrappedObject() { return _o; } }
Using this plus a craftily-written Filter, HttpServletRequestWrapper, and
HttpSession implementation would allow you to do this kind of thing without any
failures.
Or you could just configure Tomcat's already flexible allow-list for session
attribute names.
-chris
> -Original Message-
> From: Mark Thomas
> Sent: Friday, March 22, 2024 1:27 PM
> To: users@tomcat.apache.org
> Subject: Re: [EXT]Re: Tomcat session replication issue -
> java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute :
>
> On 22/03/2024 15:43, Rick Noel wrote:
>> Mark,
>>
>> So if my customer object is failing to get set in the session
>> replication, I could add this to the config snippet?
>>
>> sessionAttributeNameFilter="customer"
>
> You set that to the attributes you DO want to replicate, not the ones you
> don't.
>
> Mark
>
>>
>> so like this?...
>>
>>
>> >channelSendOptions="6">
>>
>> > className="org.apache.catalina.ha.session.DeltaManager"
>> expireSessionsOnShutdown="false"
>>
>> notifyListenersOnReplication="true"
>> maxActiveSessions="8192"
>>
>> sessionAttributeNameFilter="customer"
>> />
>>
>> > className="org.apache.catalina.tribes.group.GroupChannel">
>> > 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="5000"
>> selectorTimeout="100"
>> 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.MessageDispatchInterceptor"/>
>>
Re: [EXT]Re: Tomcat session replication issue - java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute :
Rick,
On 3/22/24 13:33, Rick Noel wrote:
I do not want to replicate customer because that class does not
implement serializable
I was looking for someway that the Manager would NOT try to replicate
it
This is an allow-list which is much more secure than a deny-list.
It's a regular expression, so you can feel free to get super-creative
with the expression if you want to effectively create a deny-list with
one item.
Honestly, this is probably some technical dept worth paying off at this
point.
Another option would be to store the object in a wrapper in the session
that *is* serializable but it doesn't actually try to serialize the
object it wraps.
I did one of these ages ago for similar reasons: I didn't want to go
change all those classes to be Serializable. Here it is:
public class TransientObjectWrapper
implements Serializable
{
private static final long serialVersionUID = -4694896879363833304L;
private transient final T _o;
public TransientObjectWrapper(T o) { _o = o; }
public T getWrappedObject() { return _o; }
}
Using this plus a craftily-written Filter, HttpServletRequestWrapper,
and HttpSession implementation would allow you to do this kind of thing
without any failures.
Or you could just configure Tomcat's already flexible allow-list for
session attribute names.
-chris
-Original Message-
From: Mark Thomas
Sent: Friday, March 22, 2024 1:27 PM
To: users@tomcat.apache.org
Subject: Re: [EXT]Re: Tomcat session replication issue -
java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute :
On 22/03/2024 15:43, Rick Noel wrote:
Mark,
So if my customer object is failing to get set in the session
replication, I could add this to the config snippet?
sessionAttributeNameFilter="customer"
You set that to the attributes you DO want to replicate, not the ones you don't.
Mark
so like this?...
filter=".*\.gif|.*\.js|.*\.jpeg|.*\.jpg|.*\.png|.*\.htm|.*\.html|.*\.c
ss|.*\.txt"/>
Rick Noel
Systems Programmer | Westwood One
rn...@westwoodone.com
-Original Message-
From: Mark Thomas
Sent: Friday, March 22, 2024 11:32 AM
To: users@tomcat.apache.org
Subject: [EXT]Re: Tomcat session replication issue -
java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute :
On 22/03/2024 15:15, Rick Noel wrote:
Is there a way to configure DeltaManager or the Cluster element so it does not
cause my application to throw this error.
22-Mar-2024 10:56:34.382 SEVERE [http-nio-8586-exec-5]
org.apache.catalina.core.StandardWrapperValve.invoke
Servlet.service() for servlet [jsp] in context with path [##0001]
threw exception [An exception occurred processing
[/services/include/properties.jsp] at line [196]
193:
194:session.setAttribute( "format", stationFormat );
195:session.setAttribute( "employee_id", employeeId );
196:session.setAttribute( "customer", customer );
197:session.setAttribute( "customer_id", customerId );
198:session.setAttribute( "nonidentifier_call_letters",
nonIdentifierCallLetters );
199:session.setAttribute( "call_letters", callLetters );
Stacktrace:] with root cause
java.lang.IllegalArgumentException: setAttribute:
Non-serializable attribute [customer]
I know why the error, it is because the customer object was never written to
be serialiazable.
The old application I am working on has a lot of such non serialized
objects and I do not want to search out change them all to implement
serialiazable
I am hoping there is a way to configure Tomcat to just not try and
replication sessions all object which are not serialiazable
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftomc
at.apache.org%2Ftomcat-10.1-doc%2Fconfig%2Fmanager.html=05%7C02%7
CRNoel%40westwoodone.com%7C1b723f1052ef4e59bf0808dc4a959af2%7Ce5d6709f
becf4b058cee37f5a62617c4%7C0%7C0%7C638467253633727340%7CUnknown%7CTWFp
bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
0%3D%7C0%7C%7C%7C=o5SvJv%2FM4QtRYM%2BEk18%2For7R81deb1g%2BW7N7XS
rMwuM%3D=0
Search for sessionAttributeNameFilter
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tom
RE: [EXT]Re: Tomcat session replication issue - java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute :
I do not want to replicate customer because that class does not implement serializable I was looking for someway that the Manager would NOT try to replicate it Rick Noel Systems Programmer | Westwood One rn...@westwoodone.com -Original Message- From: Mark Thomas Sent: Friday, March 22, 2024 1:27 PM To: users@tomcat.apache.org Subject: Re: [EXT]Re: Tomcat session replication issue - java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute : On 22/03/2024 15:43, Rick Noel wrote: > Mark, > > So if my customer object is failing to get set in the session > replication, I could add this to the config snippet? > > sessionAttributeNameFilter="customer" You set that to the attributes you DO want to replicate, not the ones you don't. Mark > > so like this?... > > >channelSendOptions="6"> > > className="org.apache.catalina.ha.session.DeltaManager" > expireSessionsOnShutdown="false" > > notifyListenersOnReplication="true" > maxActiveSessions="8192" > > sessionAttributeNameFilter="customer" > /> > > className="org.apache.catalina.tribes.group.GroupChannel"> > 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="5000" >selectorTimeout="100" >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.MessageDispatchInterceptor"/> > className="org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor"/> > > > className="org.apache.catalina.ha.tcp.ReplicationValve" > > filter=".*\.gif|.*\.js|.*\.jpeg|.*\.jpg|.*\.png|.*\.htm|.*\.html|.*\.c > ss|.*\.txt"/> > > > className="org.apache.catalina.ha.session.ClusterSessionListener"/> > > > > > > > Rick Noel > Systems Programmer | Westwood One > rn...@westwoodone.com > > -Original Message- > From: Mark Thomas > Sent: Friday, March 22, 2024 11:32 AM > To: users@tomcat.apache.org > Subject: [EXT]Re: Tomcat session replication issue - > java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute : > > On 22/03/2024 15:15, Rick Noel wrote: >> Is there a way to configure DeltaManager or the Cluster element so it does >> not cause my application to throw this error. >> >> 22-Mar-2024 10:56:34.382 SEVERE [http-nio-8586-exec-5] >> org.apache.catalina.core.StandardWrapperValve.invoke >> Servlet.service() for servlet [jsp] in context with path [##0001] >> threw exception [An exception occurred processing >> [/services/include/properties.jsp] at line [196] >> >> 193: >> 194:session.setAttribute( "format", stationFormat ); >> 195:session.setAttribute( "employee_id", employeeId ); >> 196:session.setAttribute( "customer", customer ); >> 197:session.setAttribute( "customer_id", customerId ); >> 198:se
Re: [EXT]Re: Tomcat session replication issue - java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute :
On 22/03/2024 15:43, Rick Noel wrote: Mark, So if my customer object is failing to get set in the session replication, I could add this to the config snippet? sessionAttributeNameFilter="customer" You set that to the attributes you DO want to replicate, not the ones you don't. Mark so like this?... Rick Noel Systems Programmer | Westwood One rn...@westwoodone.com -Original Message- From: Mark Thomas Sent: Friday, March 22, 2024 11:32 AM To: users@tomcat.apache.org Subject: [EXT]Re: Tomcat session replication issue - java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute : On 22/03/2024 15:15, Rick Noel wrote: Is there a way to configure DeltaManager or the Cluster element so it does not cause my application to throw this error. 22-Mar-2024 10:56:34.382 SEVERE [http-nio-8586-exec-5] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [jsp] in context with path [##0001] threw exception [An exception occurred processing [/services/include/properties.jsp] at line [196] 193: 194:session.setAttribute( "format", stationFormat ); 195:session.setAttribute( "employee_id", employeeId ); 196:session.setAttribute( "customer", customer ); 197:session.setAttribute( "customer_id", customerId ); 198:session.setAttribute( "nonidentifier_call_letters", nonIdentifierCallLetters ); 199:session.setAttribute( "call_letters", callLetters ); Stacktrace:] with root cause java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute [customer] I know why the error, it is because the customer object was never written to be serialiazable. The old application I am working on has a lot of such non serialized objects and I do not want to search out change them all to implement serialiazable I am hoping there is a way to configure Tomcat to just not try and replication sessions all object which are not serialiazable https://tomcat.apache.org/tomcat-10.1-doc/config/manager.html Search for sessionAttributeNameFilter Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you know the sender and you are sure the content is safe. Please report the message using the Report Message feature in your email client if you believe the email is suspicious. - 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: [EXT]Re: Tomcat session replication issue - java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute :
So setting... sessionAttributeNameFilter="customer" does not work, still getting the error java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute : customer Do I need to set this also? sessionAttributeValueClassNameFilter= "java\\.lang\\.(?:Boolean|Integer|Long|Number|String)|com.radiovoodoo.customer.Customer" I am thinking no config setting can stop this error. I am thinking I must alter my Customer code and make that class implement java.io.Serializable. And that is what I was hoping not to do. (alter the application code itself) Rick Noel Systems Programmer | Westwood One rn...@westwoodone.com -Original Message- From: Rick Noel Sent: Friday, March 22, 2024 11:43 AM To: Tomcat Users List Subject: RE: [EXT]Re: Tomcat session replication issue - java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute : Mark, So if my customer object is failing to get set in the session replication, I could add this to the config snippet? sessionAttributeNameFilter="customer" so like this?... Rick Noel Systems Programmer | Westwood One rn...@westwoodone.com -Original Message- From: Mark Thomas Sent: Friday, March 22, 2024 11:32 AM To: users@tomcat.apache.org Subject: [EXT]Re: Tomcat session replication issue - java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute : On 22/03/2024 15:15, Rick Noel wrote: > Is there a way to configure DeltaManager or the Cluster element so it does > not cause my application to throw this error. > > 22-Mar-2024 10:56:34.382 SEVERE [http-nio-8586-exec-5] > org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() > for servlet [jsp] in context with path [##0001] threw exception [An > exception occurred processing [/services/include/properties.jsp] at > line [196] > > 193: > 194:session.setAttribute( "format", stationFormat ); > 195:session.setAttribute( "employee_id", employeeId ); > 196:session.setAttribute( "customer", customer ); > 197:session.setAttribute( "customer_id", customerId ); > 198:session.setAttribute( "nonidentifier_call_letters", > nonIdentifierCallLetters ); > 199:session.setAttribute( "call_letters", callLetters ); > > > Stacktrace:] with root cause > java.lang.IllegalArgumentException: setAttribute: > Non-serializable attribute [customer] > > > I know why the error, it is because the customer object was never written to > be serialiazable. > The old application I am working on has a lot of such non serialized > objects and I do not want to search out change them all to implement > serialiazable > > I am hoping there is a way to configure Tomcat to just not try and > replication sessions all object which are not serialiazable https://tomcat.apache.org/tomcat-10.1-doc/config/manager.html Search for sessionAttributeNameFilter Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you know the sender and you are sure the content is safe. Please report the message using the Report Message feature in your email client if you believe the email is suspicious. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [EXT]Re: Tomcat session replication issue - java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute :
Mark, So if my customer object is failing to get set in the session replication, I could add this to the config snippet? sessionAttributeNameFilter="customer" so like this?... Rick Noel Systems Programmer | Westwood One rn...@westwoodone.com -Original Message- From: Mark Thomas Sent: Friday, March 22, 2024 11:32 AM To: users@tomcat.apache.org Subject: [EXT]Re: Tomcat session replication issue - java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute : On 22/03/2024 15:15, Rick Noel wrote: > Is there a way to configure DeltaManager or the Cluster element so it does > not cause my application to throw this error. > > 22-Mar-2024 10:56:34.382 SEVERE [http-nio-8586-exec-5] > org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for > servlet [jsp] in context with path [##0001] threw exception [An exception > occurred processing [/services/include/properties.jsp] at line [196] > > 193: > 194:session.setAttribute( "format", stationFormat ); > 195:session.setAttribute( "employee_id", employeeId ); > 196:session.setAttribute( "customer", customer ); > 197:session.setAttribute( "customer_id", customerId ); > 198:session.setAttribute( "nonidentifier_call_letters", > nonIdentifierCallLetters ); > 199:session.setAttribute( "call_letters", callLetters ); > > > Stacktrace:] with root cause > java.lang.IllegalArgumentException: setAttribute: > Non-serializable attribute [customer] > > > I know why the error, it is because the customer object was never written to > be serialiazable. > The old application I am working on has a lot of such non serialized objects > and I do not want to search out change them all to implement serialiazable > > I am hoping there is a way to configure Tomcat to just not try and > replication sessions all object which are not serialiazable https://tomcat.apache.org/tomcat-10.1-doc/config/manager.html Search for sessionAttributeNameFilter Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you know the sender and you are sure the content is safe. Please report the message using the Report Message feature in your email client if you believe the email is suspicious. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat session replication issue - java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute :
On 22/03/2024 15:15, Rick Noel wrote: Is there a way to configure DeltaManager or the Cluster element so it does not cause my application to throw this error. 22-Mar-2024 10:56:34.382 SEVERE [http-nio-8586-exec-5] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [jsp] in context with path [##0001] threw exception [An exception occurred processing [/services/include/properties.jsp] at line [196] 193: 194:session.setAttribute( "format", stationFormat ); 195:session.setAttribute( "employee_id", employeeId ); 196:session.setAttribute( "customer", customer ); 197:session.setAttribute( "customer_id", customerId ); 198:session.setAttribute( "nonidentifier_call_letters", nonIdentifierCallLetters ); 199:session.setAttribute( "call_letters", callLetters ); Stacktrace:] with root cause java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute [customer] I know why the error, it is because the customer object was never written to be serialiazable. The old application I am working on has a lot of such non serialized objects and I do not want to search out change them all to implement serialiazable I am hoping there is a way to configure Tomcat to just not try and replication sessions all object which are not serialiazable https://tomcat.apache.org/tomcat-10.1-doc/config/manager.html Search for sessionAttributeNameFilter Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat session replication issue - java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute :
Is there a way to configure DeltaManager or the Cluster element so it does not cause my application to throw this error. 22-Mar-2024 10:56:34.382 SEVERE [http-nio-8586-exec-5] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [jsp] in context with path [##0001] threw exception [An exception occurred processing [/services/include/properties.jsp] at line [196] 193: 194:session.setAttribute( "format", stationFormat ); 195:session.setAttribute( "employee_id", employeeId ); 196:session.setAttribute( "customer", customer ); 197:session.setAttribute( "customer_id", customerId ); 198:session.setAttribute( "nonidentifier_call_letters", nonIdentifierCallLetters ); 199:session.setAttribute( "call_letters", callLetters ); Stacktrace:] with root cause java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute [customer] I know why the error, it is because the customer object was never written to be serialiazable. The old application I am working on has a lot of such non serialized objects and I do not want to search out change them all to implement serialiazable I am hoping there is a way to configure Tomcat to just not try and replication sessions all object which are not serialiazable Rick Noel Systems Programmer | Westwood One rn...@westwoodone.com
RE: Tomcat 9 Session replication
Many thanks Mark!
-Original Message-
From: Mark Thomas
Sent: 01 February 2022 09:25
To: users@tomcat.apache.org
Subject: Re: Tomcat 9 Session replication
On 31/01/2022 14:54, Alan F wrote:
> Many thanks Chris,
>
> Don't laugh I was looking at those values after Keiichi kindly mentioned this
> too (thankyou!) and was thinking hmm where is 15 no mention! Ok makes sense
> now.
>
> Im trying to find out why we chose static, I think it was a guess at trying
> to stop the multicast interference from other hosts. I think we just had it
> all set wrong to start with.
>
> Looking at many online examples like here
> https://tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html is what i looked
> would this suffice?
>
> If you could recommend the params I need just for two hosts to talk without
> interference ie specifying group or unique id etc.
This is a working static cluster example from my 4-node test cluster.
https://people.apache.org/~markt/dev/server-static-cluster-example.xml
Things you'll need to change:
- the jvmRoute on the Engine element
- must be unique for each node
- must match the reverse proxy config for sticky sessions to work
- you'll only need two members
- LocalMember needs to be correct on each node
- The address attribute of the receiver needs to be correct on each node
Mark
>
> -Original Message-
> From: Christopher Schultz
> Sent: 31 January 2022 14:46
> To: users@tomcat.apache.org
> Subject: Re: Tomcat 9 Session replication
>
> All,
>
> On 1/31/22 08:04, Keiichi Fujino wrote:
>> If you use StaticMembershipService, you must set
>> Cluster#channelStartOptions to 15 (default).
>
> To spell that out (since the docs aren't very explicit), the value of "15" is
> the combination of the following flags:
>
> SND_RX_SEQ (1) - Starts the data receiver.
> SND_TX_SEQ (2) - Starts the data transmitter ("sender").
> MBR_RX_SEQ (4) - Starts the membership receiver ("listener").
> MBR_TX_SEQ (8) - Starts the membership transmitter ("broadcaster").
> |= 15 (0xf)
>
> I'm curious why, if one is using static membership, are the membership
> transmitter and receiver flags required? It seems to be that the membership
> should remain static and therefore no membership comms shuould be required.
> Are those important to ensure that the cluster members (through static) are
> actually present during operation?
>
> -chris
>
>> 2022年1月31日(月) 16:47 Alan F :
>>
>>> OK with your advice I tried what I thought would work from example
>>> and doesn't at all. The old example below works but this doesn’t
>>> even detect members.
>>>
>>> Below is example to which Im using on both nodes which are remote to
>>> eachother.
>>>
>>>
>>> >> channelSendOptions="8" channelStartOptions = "3">
>>> >> expireSessionsOnShutdown="false"
>>> notifyListenersOnReplication="true"/>
>>>
>>> >> className="org.apache.catalina.tribes.group.GroupChannel">
>>>
>>> >> className="org.apache.catalina.tribes.membership.StaticMembershipService">
>>> >> className="org.apache.catalina.tribes.membership.StaticMember"
>>> port="4110"
>>> host="local-tomcat"
>>> domain="tomcat-pc2"
>>>
>>> uniqueId="{1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,0}" />
>>> >> className="org.apache.catalina.tribes.membership.StaticMember"
>>> port="4110"
>>> host="remote-tomcat"
>>> domain="tomcat-pc2"
>>>
>>> uniqueId="{0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15}" />
>>>
>>>
>>> >> className="org.apache.catalina.tribes.transport.nio.NioReceiver"
>>>address="local-tomcat"
>>>port="4110"
>>>autoBind="9"
>>>selectorTimeout="2000"
>>>maxThreads="6"/>
>>>
>>> >> className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
>>>
Re: Tomcat 9 Session replication
On 31/01/2022 14:54, Alan F wrote:
Many thanks Chris,
Don't laugh I was looking at those values after Keiichi kindly mentioned this
too (thankyou!) and was thinking hmm where is 15 no mention! Ok makes sense
now.
Im trying to find out why we chose static, I think it was a guess at trying to
stop the multicast interference from other hosts. I think we just had it all
set wrong to start with.
Looking at many online examples like here
https://tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html is what i looked
would this suffice?
If you could recommend the params I need just for two hosts to talk without
interference ie specifying group or unique id etc.
This is a working static cluster example from my 4-node test cluster.
https://people.apache.org/~markt/dev/server-static-cluster-example.xml
Things you'll need to change:
- the jvmRoute on the Engine element
- must be unique for each node
- must match the reverse proxy config for sticky sessions to work
- you'll only need two members
- LocalMember needs to be correct on each node
- The address attribute of the receiver needs to be correct on each node
Mark
-Original Message-
From: Christopher Schultz
Sent: 31 January 2022 14:46
To: users@tomcat.apache.org
Subject: Re: Tomcat 9 Session replication
All,
On 1/31/22 08:04, Keiichi Fujino wrote:
If you use StaticMembershipService, you must set
Cluster#channelStartOptions to 15 (default).
To spell that out (since the docs aren't very explicit), the value of "15" is
the combination of the following flags:
SND_RX_SEQ (1) - Starts the data receiver.
SND_TX_SEQ (2) - Starts the data transmitter ("sender").
MBR_RX_SEQ (4) - Starts the membership receiver ("listener").
MBR_TX_SEQ (8) - Starts the membership transmitter ("broadcaster").
|= 15 (0xf)
I'm curious why, if one is using static membership, are the membership
transmitter and receiver flags required? It seems to be that the membership
should remain static and therefore no membership comms shuould be required. Are
those important to ensure that the cluster members (through static) are
actually present during operation?
-chris
2022年1月31日(月) 16:47 Alan F :
OK with your advice I tried what I thought would work from example
and doesn't at all. The old example below works but this doesn’t even
detect members.
Below is example to which Im using on both nodes which are remote to
eachother.
-Original Message-
From: Mark Thomas
Sent: 28 January 2022 18:15
To: users@tomcat.apache.org
Subject: Re: Tomcat 9 Session replication
On 28/01/2022 17:05, Alan F wrote:
We are currently getting traffic from all cluster members in other
environments using .staticmember opposed to multicast can I confirm
why this is see below.
What do we need to set here for a clustered pair to make them unique
and talk to eachother only without seeing traffic from other members
in Catalina.out
This is how they are currently configured as you can see only
difference
between nodes is the receiver and member ips are reversed. Im
concerned uniqueID is the same, do we also need to specify domain?
uniqueID should be unique at least within the subnet, ideally globally.
Yes, you should use a separate domain for each cluster.
Looking at your config:
You are missing the local member definition
https://tomcat.apache.org/tomcat-10.0-doc/config/cluster-interceptor.
html#Static_Membership
The deployer should be defined under the cluster, not under an interceptor.
Mark
WE have hostname A and B if you could check below:
HOSTNAME A config
channelSendOptions="8">
className="org.apache.catalina.ha.session.DeltaManager"
expireSessionsOnShutdown="false"
notifyListenersOnReplication="true"/>
className="org.apache.catalina.tribes.transport.ReplicationTransmitte
r">
className="org.apache.catalina.tribes.transport.nio.PooledParallelSen
der" />
className="org.apache.catalina.tribes.transport.nio.NioReceiver"
maxThreads="6"
port="4100"
selectorTimeout="5000"
/>
className="org.apache.catalina.tribes.group.interceptors.TcpPingInterceptor"
staticOnly="true"/>
className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"
/>
className="org.apache.catalina.tribes.group.interceptors.StaticMember
shipIntercep
Re: Tomcat 9 Session replication
Alan,
On 1/31/22 09:54, Alan F wrote:
Many thanks Chris,
Don't laugh I was looking at those values after Keiichi kindly mentioned this
too (thankyou!) and was thinking hmm where is 15 no mention! Ok makes sense
now.
Im trying to find out why we chose static, I think it was a guess at trying to
stop the multicast interference from other hosts. I think we just had it all
set wrong to start with.
Looking at many online examples like here
https://tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html is what i looked
would this suffice?
If you could recommend the params I need just for two hosts to talk without
interference ie specifying group or unique id etc.
Keiichi knows what he's talking about: set that channelStartOptions
value to "15" and try again.
With static membership, there is no multicast so there shouldn't be any
interference with other non-members. Just make sure you have your ports
unique for each cluster and your membership ids unique for each node in
each cluster.
-chris
-Original Message-
From: Christopher Schultz
Sent: 31 January 2022 14:46
To: users@tomcat.apache.org
Subject: Re: Tomcat 9 Session replication
All,
On 1/31/22 08:04, Keiichi Fujino wrote:
If you use StaticMembershipService, you must set
Cluster#channelStartOptions to 15 (default).
To spell that out (since the docs aren't very explicit), the value of "15" is
the combination of the following flags:
SND_RX_SEQ (1) - Starts the data receiver.
SND_TX_SEQ (2) - Starts the data transmitter ("sender").
MBR_RX_SEQ (4) - Starts the membership receiver ("listener").
MBR_TX_SEQ (8) - Starts the membership transmitter ("broadcaster").
|= 15 (0xf)
I'm curious why, if one is using static membership, are the membership
transmitter and receiver flags required? It seems to be that the membership
should remain static and therefore no membership comms shuould be required. Are
those important to ensure that the cluster members (through static) are
actually present during operation?
-chris
2022年1月31日(月) 16:47 Alan F :
OK with your advice I tried what I thought would work from example
and doesn't at all. The old example below works but this doesn’t even
detect members.
Below is example to which Im using on both nodes which are remote to
eachother.
-Original Message-
From: Mark Thomas
Sent: 28 January 2022 18:15
To: users@tomcat.apache.org
Subject: Re: Tomcat 9 Session replication
On 28/01/2022 17:05, Alan F wrote:
We are currently getting traffic from all cluster members in other
environments using .staticmember opposed to multicast can I confirm
why this is see below.
What do we need to set here for a clustered pair to make them unique
and talk to eachother only without seeing traffic from other members
in Catalina.out
This is how they are currently configured as you can see only
difference
between nodes is the receiver and member ips are reversed. Im
concerned uniqueID is the same, do we also need to specify domain?
uniqueID should be unique at least within the subnet, ideally globally.
Yes, you should use a separate domain for each cluster.
Looking at your config:
You are missing the local member definition
https://tomcat.apache.org/tomcat-10.0-doc/config/cluster-interceptor.
html#Static_Membership
The deployer should be defined under the cluster, not under an interceptor.
Mark
WE have hostname A and B if you could check below:
HOSTNAME A config
channelSendOptions="8">
className="org.apache.catalina.ha.session.DeltaManager"
expireSessionsOnShutdown="false"
notifyListenersOnReplication="true"/>
className="org.apache.catalina.tribes.transport.ReplicationTransmitte
r">
className="org.apache.catalina.tribes.transport.nio.PooledParallelSen
der" />
className="org.apache.catalina.tribes.transport.nio.NioReceiver"
maxThreads="6"
port="4100"
selectorTimeout="5000"
/>
className="org.apache.catalina.tribes.group.interceptors.TcpPingInterceptor"
staticOnly="true"/>
className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"
/>
className="org.apache.catalina.tribes.group.interceptors.StaticMember
shipInterceptor">
className="org.apache.catalina.tribes.membership.StaticMember"
port="4100"
RE: Tomcat 9 Session replication
Many thanks Chris,
Don't laugh I was looking at those values after Keiichi kindly mentioned this
too (thankyou!) and was thinking hmm where is 15 no mention! Ok makes sense
now.
Im trying to find out why we chose static, I think it was a guess at trying to
stop the multicast interference from other hosts. I think we just had it all
set wrong to start with.
Looking at many online examples like here
https://tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html is what i looked
would this suffice?
If you could recommend the params I need just for two hosts to talk without
interference ie specifying group or unique id etc.
-Original Message-
From: Christopher Schultz
Sent: 31 January 2022 14:46
To: users@tomcat.apache.org
Subject: Re: Tomcat 9 Session replication
All,
On 1/31/22 08:04, Keiichi Fujino wrote:
> If you use StaticMembershipService, you must set
> Cluster#channelStartOptions to 15 (default).
To spell that out (since the docs aren't very explicit), the value of "15" is
the combination of the following flags:
SND_RX_SEQ (1) - Starts the data receiver.
SND_TX_SEQ (2) - Starts the data transmitter ("sender").
MBR_RX_SEQ (4) - Starts the membership receiver ("listener").
MBR_TX_SEQ (8) - Starts the membership transmitter ("broadcaster").
|= 15 (0xf)
I'm curious why, if one is using static membership, are the membership
transmitter and receiver flags required? It seems to be that the membership
should remain static and therefore no membership comms shuould be required. Are
those important to ensure that the cluster members (through static) are
actually present during operation?
-chris
> 2022年1月31日(月) 16:47 Alan F :
>
>> OK with your advice I tried what I thought would work from example
>> and doesn't at all. The old example below works but this doesn’t even
>> detect members.
>>
>> Below is example to which Im using on both nodes which are remote to
>> eachother.
>>
>>
>> > channelSendOptions="8" channelStartOptions = "3">
>>> expireSessionsOnShutdown="false"
>> notifyListenersOnReplication="true"/>
>>
>>> className="org.apache.catalina.tribes.group.GroupChannel">
>>
>> > className="org.apache.catalina.tribes.membership.StaticMembershipService">
>> > className="org.apache.catalina.tribes.membership.StaticMember"
>>port="4110"
>>host="local-tomcat"
>>domain="tomcat-pc2"
>>
>> uniqueId="{1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,0}" />
>> > className="org.apache.catalina.tribes.membership.StaticMember"
>>port="4110"
>>host="remote-tomcat"
>>domain="tomcat-pc2"
>>
>> uniqueId="{0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15}" />
>>
>>
>> > className="org.apache.catalina.tribes.transport.nio.NioReceiver"
>> address="local-tomcat"
>> port="4110"
>> autoBind="9"
>> selectorTimeout="2000"
>> maxThreads="6"/>
>>
>> > className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
>> > className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
>>
>>
>> > className="org.apache.catalina.tribes.group.interceptors.TcpPingInterceptor"
>> staticOnly="true"/>
>> > className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"
>> />
>> > className="org.apache.catalina.tribes.group.interceptors.MessageDispatchInterceptor"/>
>> > className="org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor"/>
>> > className="org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor">
>>
>>
>>
>>
>>> filter=""/>
>>> className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
>>
>>> className="org.apache.catalina.ha.deploy.FarmWarDeployer"
>> tempDir="/op
Re: Tomcat 9 Session replication
Hi
If you use StaticMembershipService, you must set
Cluster#channelStartOptions to 15 (default).
2022年1月31日(月) 16:47 Alan F :
> OK with your advice I tried what I thought would work from example and
> doesn't at all. The old example below works but this doesn’t even detect
> members.
>
> Below is example to which Im using on both nodes which are remote to
> eachother.
>
>
> channelSendOptions="8" channelStartOptions = "3">
> expireSessionsOnShutdown="false"
>notifyListenersOnReplication="true"/>
>
>
>
> className="org.apache.catalina.tribes.membership.StaticMembershipService">
> className="org.apache.catalina.tribes.membership.StaticMember"
> port="4110"
> host="local-tomcat"
> domain="tomcat-pc2"
>
> uniqueId="{1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,0}" />
> className="org.apache.catalina.tribes.membership.StaticMember"
> port="4110"
> host="remote-tomcat"
> domain="tomcat-pc2"
>
> uniqueId="{0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15}" />
>
>
> className="org.apache.catalina.tribes.transport.nio.NioReceiver"
> address="local-tomcat"
> port="4110"
> autoBind="9"
> selectorTimeout="2000"
> maxThreads="6"/>
>
> className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
> className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
>
>
> className="org.apache.catalina.tribes.group.interceptors.TcpPingInterceptor"
> staticOnly="true"/>
> className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"
> />
> className="org.apache.catalina.tribes.group.interceptors.MessageDispatchInterceptor"/>
> className="org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor"/>
> className="org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor">
>
>
>
>
>filter=""/>
>className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
>
>className="org.apache.catalina.ha.deploy.FarmWarDeployer"
> tempDir="/opt/tomcat/war-temp/"
> deployDir="/opt/tomcat/war-deploy/"
> watchDir="/opt/tomcat/war-listen/"
> watchEnabled="true"/>
>className="org.apache.catalina.ha.session.ClusterSessionListener"/>
>
>
>
> -Original Message-
> From: Mark Thomas
> Sent: 28 January 2022 18:15
> To: users@tomcat.apache.org
> Subject: Re: Tomcat 9 Session replication
>
> On 28/01/2022 17:05, Alan F wrote:
> > We are currently getting traffic from all cluster members in other
> environments using .staticmember opposed to multicast can I confirm why
> this is see below.
> >
> > What do we need to set here for a clustered pair to make them unique
> > and talk to eachother only without seeing traffic from other members
> > in Catalina.out
> >
> > This is how they are currently configured as you can see only difference
> between nodes is the receiver and member ips are reversed. Im concerned
> uniqueID is the same, do we also need to specify domain?
>
> uniqueID should be unique at least within the subnet, ideally globally.
>
> Yes, you should use a separate domain for each cluster.
>
> Looking at your config:
>
> You are missing the local member definition
> https://tomcat.apache.org/tomcat-10.0-doc/config/cluster-interceptor.html#Static_Membership
>
> The deployer should be defined under the cluster, not under an interceptor.
>
> Mark
>
> >
> > WE have hostname A and B if you could check below:
> >
> > HOSTNAME A config
> >
> >
> >
> > channelSendOptions="8">
> > className="org.apache.catalina.ha.session.DeltaManager"
> > expireSessionsOnShutdown="false"
> > notifyListenersOnReplication="true&quo
RE: Tomcat 9 Session replication
OK with your advice I tried what I thought would work from example and doesn't
at all. The old example below works but this doesn’t even detect members.
Below is example to which Im using on both nodes which are remote to eachother.
-Original Message-
From: Mark Thomas
Sent: 28 January 2022 18:15
To: users@tomcat.apache.org
Subject: Re: Tomcat 9 Session replication
On 28/01/2022 17:05, Alan F wrote:
> We are currently getting traffic from all cluster members in other
> environments using .staticmember opposed to multicast can I confirm why this
> is see below.
>
> What do we need to set here for a clustered pair to make them unique
> and talk to eachother only without seeing traffic from other members
> in Catalina.out
>
> This is how they are currently configured as you can see only difference
> between nodes is the receiver and member ips are reversed. Im concerned
> uniqueID is the same, do we also need to specify domain?
uniqueID should be unique at least within the subnet, ideally globally.
Yes, you should use a separate domain for each cluster.
Looking at your config:
You are missing the local member definition
https://tomcat.apache.org/tomcat-10.0-doc/config/cluster-interceptor.html#Static_Membership
The deployer should be defined under the cluster, not under an interceptor.
Mark
>
> WE have hostname A and B if you could check below:
>
> HOSTNAME A config
>
>
>
> channelSendOptions="8">
> expireSessionsOnShutdown="false"
> notifyListenersOnReplication="true"/>
>
>
>
> className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
> className="org.apache.catalina.tribes.transport.nio.PooledParallelSender" />
>
>address="hostnameA"
> autoBind="0"
> className="org.apache.catalina.tribes.transport.nio.NioReceiver"
> maxThreads="6"
> port="4100"
> selectorTimeout="5000"
> />
>
> className="org.apache.catalina.tribes.group.interceptors.TcpPingInterceptor"
> staticOnly="true"/>
> className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"
> />
> className="org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor">
>
> className="org.apache.catalina.tribes.membership.StaticMember"
> port="4100"
> host="HostnameB"
> uniqueId="{0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,1}"
> />
> tempDir="/opt/tomcat/war-temp/"
> deployDir="/opt/tomcat/war-deploy/"
> watchDir="/opt/tomcat/war-listen/"
> watchEnabled="true"/>
>
>
> className="org.apache.catalina.tribes.group.interceptors.MessageDispatchInterceptor"
> />
>
>
> -
> 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: Tomcat 9 Session replication
On 28/01/2022 17:05, Alan F wrote: We are currently getting traffic from all cluster members in other environments using .staticmember opposed to multicast can I confirm why this is see below. What do we need to set here for a clustered pair to make them unique and talk to eachother only without seeing traffic from other members in Catalina.out This is how they are currently configured as you can see only difference between nodes is the receiver and member ips are reversed. Im concerned uniqueID is the same, do we also need to specify domain? uniqueID should be unique at least within the subnet, ideally globally. Yes, you should use a separate domain for each cluster. Looking at your config: You are missing the local member definition https://tomcat.apache.org/tomcat-10.0-doc/config/cluster-interceptor.html#Static_Membership The deployer should be defined under the cluster, not under an interceptor. Mark WE have hostname A and B if you could check below: HOSTNAME A config - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 9 Session replication
We are currently getting traffic from all cluster members in other environments using .staticmember opposed to multicast can I confirm why this is see below. What do we need to set here for a clustered pair to make them unique and talk to eachother only without seeing traffic from other members in Catalina.out This is how they are currently configured as you can see only difference between nodes is the receiver and member ips are reversed. Im concerned uniqueID is the same, do we also need to specify domain? WE have hostname A and B if you could check below: HOSTNAME A config
Re: Tomcat 9 cluster with FarmWarDeployer but without session replication
Hi Mark, Thank you very much. It works. When the element is not present in the web.xml, FarmWarDeployer still works but without sessions getting replicated. I tested using a sample web application and then verified by analyzing the network traffic. No session data could be found on the wire when is not present. Kamal On Wednesday, January 27, 2021, 5:09:04 PM GMT+5:30, Mark Thomas wrote: Kamal, This is off the top of my head without testing it or even looking at the code but you could try configuring a cluster with the FarmWarDeployer and then deploying a web application via the FarmWarDeployer that has the distributable flag set to false in web.xml Mark On 27/01/2021 05:44, Kamal Wickramanayake wrote: > Is it ever possible to configure a Tomcat 9 cluster with the FarmWarDeployer > enabled but without session replication? Any guidelines? > TIAKamal > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 9 cluster with FarmWarDeployer but without session replication
Kamal, This is off the top of my head without testing it or even looking at the code but you could try configuring a cluster with the FarmWarDeployer and then deploying a web application via the FarmWarDeployer that has the distributable flag set to false in web.xml Mark On 27/01/2021 05:44, Kamal Wickramanayake wrote: > Is it ever possible to configure a Tomcat 9 cluster with the FarmWarDeployer > enabled but without session replication? Any guidelines? > TIAKamal > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 9 cluster with FarmWarDeployer but without session replication
Is it ever possible to configure a Tomcat 9 cluster with the FarmWarDeployer enabled but without session replication? Any guidelines? TIAKamal
Re: Tomcat session replication
Am 1. Juli 2020 12:21:46 MESZ schrieb Mark Thomas : >On 01/07/2020 11:19, Thomas Meyer wrote: >> Am 30. Juni 2020 11:07:36 MESZ schrieb Mark Thomas >: >>> On 29/06/2020 21:41, Christopher Schultz wrote: >>>> Mark, >>>> >>>> On 6/27/20 05:29, Mark Thomas wrote: >>>>> On 27/06/2020 10:19, Thomas Meyer wrote: >>>>>> Hi, >>>>>> >>>>>> A few questions regarding tomcat session replication: >>>> >>>>> load-balancing and session replication are two separate parts of >>>>> an overall clustering solution. >>>> >>>>>> 1) is the jvmRoute attribute on Engine object necessary for >>>>>> session replication to work correctly? >>>> >>>>> No, but if you don't use it it places a number of restrictions on >>>>> the web application behaviour and on the configuration of session >>>>> replication. >>>> >>>>> The limitations are: - you need to use the DeltaManager (which >>>>> doesn't scale as well as the BackupManager); - any requests made >by >>>>> the client that depend on the session MUST be issued in series, >not >>>>> in parallel; and >>>> >>>> This is only true of requests that would modify the session-state >in >>> a >>>> way that needed to be deterministic, right? A bunch of GET requests >>>> that don't change the session ought to be okay in parallel (as long >>> as >>>> any prior state-changing requests have completed _ those changes >>>> replicated). >>> >>> Yes. >>> You don't want state changes in parallel on different nodes. >>> Any request that depends on a previous change in state can't be >issued >>> until the state changing request has completed and the changes >>> replicated. >>> >>>>> - the session Manager must be configured to update all the other >>>>> nodes in the cluster BEFORE the current request returns to the >>>>> client. >>>> >>>> Same (negative) caveat here, right? >>> >>> Yes. >>> >>> Essentially you want channelSendOptions="6". >> >> Hi, >> >> Yes I'm using that option. But it still gives an error, but I may now >found some hints what's going wrong: >> >> When using Spring's ChangeSessionIdAuthStrategy it fails with unknown >CSRF token. >> >> It looks like the node fails to replicate, i.e. doesn't export, the >session data after a changeSessionId call. >> >> When using Spring's SessionFixationProtectionStrategy (which >basically creates a new session and copy all attributes to the new >session) it works correctly with tomcats session replication. >> >> So it looks like calling changeSessionId fails to somehow replication >the new session state to the remote nodes. >> >> Looking at ManagerBase "session" attribute it's unclear if it >contains only "internal session IDs" or external session IDs which do >change. >> >> The ReplicationValve seems to call manager.findSession with the >internal ID. >> >> Maybe somewhere something mixes up internal and external session IDs >or forgets to update ManagerBase.session map. >> >> Opinions? > >Maybe this: >https://bz.apache.org/bugzilla/show_bug.cgi?id=64560 Yes, that's seems to be exactly the same problem! And it's already fixed! Thank you very much! I'll update our tomcat version from 9.0.34 to the fixed version. Regards Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat session replication
On 01/07/2020 11:19, Thomas Meyer wrote: > Am 30. Juni 2020 11:07:36 MESZ schrieb Mark Thomas : >> On 29/06/2020 21:41, Christopher Schultz wrote: >>> Mark, >>> >>> On 6/27/20 05:29, Mark Thomas wrote: >>>> On 27/06/2020 10:19, Thomas Meyer wrote: >>>>> Hi, >>>>> >>>>> A few questions regarding tomcat session replication: >>> >>>> load-balancing and session replication are two separate parts of >>>> an overall clustering solution. >>> >>>>> 1) is the jvmRoute attribute on Engine object necessary for >>>>> session replication to work correctly? >>> >>>> No, but if you don't use it it places a number of restrictions on >>>> the web application behaviour and on the configuration of session >>>> replication. >>> >>>> The limitations are: - you need to use the DeltaManager (which >>>> doesn't scale as well as the BackupManager); - any requests made by >>>> the client that depend on the session MUST be issued in series, not >>>> in parallel; and >>> >>> This is only true of requests that would modify the session-state in >> a >>> way that needed to be deterministic, right? A bunch of GET requests >>> that don't change the session ought to be okay in parallel (as long >> as >>> any prior state-changing requests have completed _ those changes >>> replicated). >> >> Yes. >> You don't want state changes in parallel on different nodes. >> Any request that depends on a previous change in state can't be issued >> until the state changing request has completed and the changes >> replicated. >> >>>> - the session Manager must be configured to update all the other >>>> nodes in the cluster BEFORE the current request returns to the >>>> client. >>> >>> Same (negative) caveat here, right? >> >> Yes. >> >> Essentially you want channelSendOptions="6". > > Hi, > > Yes I'm using that option. But it still gives an error, but I may now found > some hints what's going wrong: > > When using Spring's ChangeSessionIdAuthStrategy it fails with unknown CSRF > token. > > It looks like the node fails to replicate, i.e. doesn't export, the session > data after a changeSessionId call. > > When using Spring's SessionFixationProtectionStrategy (which basically > creates a new session and copy all attributes to the new session) it works > correctly with tomcats session replication. > > So it looks like calling changeSessionId fails to somehow replication the new > session state to the remote nodes. > > Looking at ManagerBase "session" attribute it's unclear if it contains only > "internal session IDs" or external session IDs which do change. > > The ReplicationValve seems to call manager.findSession with the internal ID. > > Maybe somewhere something mixes up internal and external session IDs or > forgets to update ManagerBase.session map. > > Opinions? Maybe this: https://bz.apache.org/bugzilla/show_bug.cgi?id=64560 Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat session replication
Am 30. Juni 2020 11:07:36 MESZ schrieb Mark Thomas : >On 29/06/2020 21:41, Christopher Schultz wrote: >> Mark, >> >> On 6/27/20 05:29, Mark Thomas wrote: >>> On 27/06/2020 10:19, Thomas Meyer wrote: >>>> Hi, >>>> >>>> A few questions regarding tomcat session replication: >> >>> load-balancing and session replication are two separate parts of >>> an overall clustering solution. >> >>>> 1) is the jvmRoute attribute on Engine object necessary for >>>> session replication to work correctly? >> >>> No, but if you don't use it it places a number of restrictions on >>> the web application behaviour and on the configuration of session >>> replication. >> >>> The limitations are: - you need to use the DeltaManager (which >>> doesn't scale as well as the BackupManager); - any requests made by >>> the client that depend on the session MUST be issued in series, not >>> in parallel; and >> >> This is only true of requests that would modify the session-state in >a >> way that needed to be deterministic, right? A bunch of GET requests >> that don't change the session ought to be okay in parallel (as long >as >> any prior state-changing requests have completed _ those changes >> replicated). > >Yes. >You don't want state changes in parallel on different nodes. >Any request that depends on a previous change in state can't be issued >until the state changing request has completed and the changes >replicated. > >>> - the session Manager must be configured to update all the other >>> nodes in the cluster BEFORE the current request returns to the >>> client. >> >> Same (negative) caveat here, right? > >Yes. > >Essentially you want channelSendOptions="6". Hi, Yes I'm using that option. But it still gives an error, but I may now found some hints what's going wrong: When using Spring's ChangeSessionIdAuthStrategy it fails with unknown CSRF token. It looks like the node fails to replicate, i.e. doesn't export, the session data after a changeSessionId call. When using Spring's SessionFixationProtectionStrategy (which basically creates a new session and copy all attributes to the new session) it works correctly with tomcats session replication. So it looks like calling changeSessionId fails to somehow replication the new session state to the remote nodes. Looking at ManagerBase "session" attribute it's unclear if it contains only "internal session IDs" or external session IDs which do change. The ReplicationValve seems to call manager.findSession with the internal ID. Maybe somewhere something mixes up internal and external session IDs or forgets to update ManagerBase.session map. Opinions? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat session replication
On 29/06/2020 21:41, Christopher Schultz wrote: > Mark, > > On 6/27/20 05:29, Mark Thomas wrote: >> On 27/06/2020 10:19, Thomas Meyer wrote: >>> Hi, >>> >>> A few questions regarding tomcat session replication: > >> load-balancing and session replication are two separate parts of >> an overall clustering solution. > >>> 1) is the jvmRoute attribute on Engine object necessary for >>> session replication to work correctly? > >> No, but if you don't use it it places a number of restrictions on >> the web application behaviour and on the configuration of session >> replication. > >> The limitations are: - you need to use the DeltaManager (which >> doesn't scale as well as the BackupManager); - any requests made by >> the client that depend on the session MUST be issued in series, not >> in parallel; and > > This is only true of requests that would modify the session-state in a > way that needed to be deterministic, right? A bunch of GET requests > that don't change the session ought to be okay in parallel (as long as > any prior state-changing requests have completed _ those changes > replicated). Yes. You don't want state changes in parallel on different nodes. Any request that depends on a previous change in state can't be issued until the state changing request has completed and the changes replicated. >> - the session Manager must be configured to update all the other >> nodes in the cluster BEFORE the current request returns to the >> client. > > Same (negative) caveat here, right? Yes. Essentially you want channelSendOptions="6". Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat session replication
Am 29. Juni 2020 22:54:12 MESZ schrieb Christopher Schultz : >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA256 > >Thomas, Hi, > >On 6/27/20 05:52, Thomas Meyer wrote: >> Am 27. Juni 2020 11:29:03 MESZ schrieb Mark Thomas >> : >>> On 27/06/2020 10:19, Thomas Meyer wrote: >>>> Hi, >>>> >>>> A few questions regarding tomcat session replication: >>> >>> load-balancing and session replication are two separate parts of >>> an overall clustering solution. >>> >>>> 1) is the jvmRoute attribute on Engine object necessary for >>>> session >>> replication to work correctly? >>> >>> No, but if you don't use it it places a number of restrictions on >>> the web application behaviour and on the configuration of >>> session replication. >>> >>> The limitations are: - you need to use the DeltaManager (which >>> doesn't scale as well as the BackupManager); >> >> Yes, I'm using default DeltaManager as I will only have two pods >> running Tomcat. >> >>> - any requests made by the client that depend on the session MUST >>> be issued in series, not in parallel; and >> >> Not sure about this one, the app uses spring default security for >> login. So need to check this one. > >This has more to do with how your web application itself works and >less about your security framework. For example, if you have a >web-1.0-style web application which is mostly user-driven GET and POST >requests, then you are probably fine with the occasional >user-initiated page RELOAD or STOP/RELOAD or STOP/RETRY event. > >But if you have a web-2.0 style >websocket/AJAX/many-things-happening-at-once-style application, then >you are probably going to have problems without sticky sessions. Yes, okay understood. Webapp is a traditional request/reply jsp app. So nothing fancy going on. > >>> - the session Manager must be configured to update all the other >>> nodes in the cluster BEFORE the current request returns to the >>> client. >> >> How to do that? I did have a look at Manager/DeltaManager >> attributes but didn't see something that looks like above setting. >> Can you plea point me in the right direction? > >http://tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html#Cluster_Infor >mation > >This is done using channelSendOptions on the and >mapSendOptions on the ReplicationValve. The default value is to be >synchronous, which would be required, here. Synchronous means that the >data is replicated before the response is completed to the client. You >could also do asynchronous which would allow the request to complete >and queue the replication for "later" (but probably pretty shortly >thereafter). Yes I also found out that simple tcp cluster had this option, but async is the default for some reason: https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/ha/tcp/SimpleTcpCluster.java#L152 I tried ack and sync-ack but I still see "session not found errors". I'll check replication valve setting. In the meantime I also did enable tribes message logging, and tried to find out what goes wrong, but have not yet fully understand the problem. The error seems to happen in springs csrf filter which stores a uuid token in the http sessions. Also a change session id happens in between. Everything looks actually okay, but it doesn't work. > >>>> 2) does session replication only work correctly with sticky >>>> load >>> balancer routing? >>> >>> No. It works quite happily without it. >> >> Good to know. > >You might want to use sticky-sessions anyway. > >>>> My setup is 1) load balancer without sticky session routing >>>> into kubernetes 2) two pods running tomcat with cloud member >>>> provider, which see and >>> find each other >>>> >>>> No jvmRoute attribute is set. >> >> Another question regarding jvmRoute: Even if my load balancer has >> no sticky sessions, should I add jvmRoute attribute? I think I >> could easily add the pod's name as jvmRoute. > >If it's no particular trouble, I would: > >1. Add jvmRoute >2. Enable sticky sessions > >#2 just means that all requests for an session-holding client will be >directed to a single Tomcat node. If fail-over is necessary, the other >node will have the session-information that was last sent successfully >and should be relatively up-to-date. The session-id will be changed >upon fail-over and the user shouldn't really notice unless some >replication message was lost. > >IMHO the o
Re: Tomcat session replication
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Thomas, On 6/27/20 05:52, Thomas Meyer wrote: > Am 27. Juni 2020 11:29:03 MESZ schrieb Mark Thomas > : >> On 27/06/2020 10:19, Thomas Meyer wrote: >>> Hi, >>> >>> A few questions regarding tomcat session replication: >> >> load-balancing and session replication are two separate parts of >> an overall clustering solution. >> >>> 1) is the jvmRoute attribute on Engine object necessary for >>> session >> replication to work correctly? >> >> No, but if you don't use it it places a number of restrictions on >> the web application behaviour and on the configuration of >> session replication. >> >> The limitations are: - you need to use the DeltaManager (which >> doesn't scale as well as the BackupManager); > > Yes, I'm using default DeltaManager as I will only have two pods > running Tomcat. > >> - any requests made by the client that depend on the session MUST >> be issued in series, not in parallel; and > > Not sure about this one, the app uses spring default security for > login. So need to check this one. This has more to do with how your web application itself works and less about your security framework. For example, if you have a web-1.0-style web application which is mostly user-driven GET and POST requests, then you are probably fine with the occasional user-initiated page RELOAD or STOP/RELOAD or STOP/RETRY event. But if you have a web-2.0 style websocket/AJAX/many-things-happening-at-once-style application, then you are probably going to have problems without sticky sessions. >> - the session Manager must be configured to update all the other >> nodes in the cluster BEFORE the current request returns to the >> client. > > How to do that? I did have a look at Manager/DeltaManager > attributes but didn't see something that looks like above setting. > Can you plea point me in the right direction? http://tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html#Cluster_Infor mation This is done using channelSendOptions on the and mapSendOptions on the ReplicationValve. The default value is to be synchronous, which would be required, here. Synchronous means that the data is replicated before the response is completed to the client. You could also do asynchronous which would allow the request to complete and queue the replication for "later" (but probably pretty shortly thereafter). >>> 2) does session replication only work correctly with sticky >>> load >> balancer routing? >> >> No. It works quite happily without it. > > Good to know. You might want to use sticky-sessions anyway. >>> My setup is 1) load balancer without sticky session routing >>> into kubernetes 2) two pods running tomcat with cloud member >>> provider, which see and >> find each other >>> >>> No jvmRoute attribute is set. > > Another question regarding jvmRoute: Even if my load balancer has > no sticky sessions, should I add jvmRoute attribute? I think I > could easily add the pod's name as jvmRoute. If it's no particular trouble, I would: 1. Add jvmRoute 2. Enable sticky sessions #2 just means that all requests for an session-holding client will be directed to a single Tomcat node. If fail-over is necessary, the other node will have the session-information that was last sent successfully and should be relatively up-to-date. The session-id will be changed upon fail-over and the user shouldn't really notice unless some replication message was lost. IMHO the only potential downside to non-sticky-sessions is that it's possible for one of your nodes to "collect" more users than the others and give you a lop-sided load-profile across your nodes. Unless that's a particular concern for you (and, for most applications, it's not a problem at all), I would enable sticky-sessions because it avoids a lot of race-conditions and other performance-related issues with cluster s. This isn't Tomcat-specific: it's just the nature of the beast. >>> Above setup doesn't work and give strange errors for the >>> distributed >> webapp which relies on http sessions. >>> >>> Should above setup work? If not why and what do I need to fix? >>> >>> Any hints of what logging to enable to debug the problem if any >>> at >> all? >> >> Please show us how you have configured the session manager and >> clustering. > > My setup is just go with the defaults: > > > className="org.apache.catalina.tribes.group.GroupChannel"> > className="org.apache.catalina.tribes.membership.cloud.CloudMembership Service" > > membershipProviderClassName="org.apache.catalina.tr
Re: Tomcat session replication
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 6/27/20 05:29, Mark Thomas wrote: > On 27/06/2020 10:19, Thomas Meyer wrote: >> Hi, >> >> A few questions regarding tomcat session replication: > > load-balancing and session replication are two separate parts of > an overall clustering solution. > >> 1) is the jvmRoute attribute on Engine object necessary for >> session replication to work correctly? > > No, but if you don't use it it places a number of restrictions on > the web application behaviour and on the configuration of session > replication. > > The limitations are: - you need to use the DeltaManager (which > doesn't scale as well as the BackupManager); - any requests made by > the client that depend on the session MUST be issued in series, not > in parallel; and This is only true of requests that would modify the session-state in a way that needed to be deterministic, right? A bunch of GET requests that don't change the session ought to be okay in parallel (as long as any prior state-changing requests have completed _ those changes replicated). > - the session Manager must be configured to update all the other > nodes in the cluster BEFORE the current request returns to the > client. Same (negative) caveat here, right? >> 2) does session replication only work correctly with sticky load >> balancer routing? > > No. It works quite happily without it. > >> >> My setup is 1) load balancer without sticky session routing into >> kubernetes 2) two pods running tomcat with cloud member provider, >> which see and find each other >> >> No jvmRoute attribute is set. >> >> Above setup doesn't work and give strange errors for the >> distributed webapp which relies on http sessions. >> >> Should above setup work? If not why and what do I need to fix? >> >> Any hints of what logging to enable to debug the problem if any >> at all? > > Please show us how you have configured the session manager and > clustering. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl76UgcACgkQHPApP6U8 pFjoNQ//TbmZA3oh1ISz3ogBK9Txb/VH1qXnJ8+Y/uP0sjK45p88vd+hoqfAyQ98 8faqgN5/IuuYCnGPYlySGDfF2b2rfXL2umq5P62rjYnDBEsWulIix4dYxNLDqZF6 GeK7lKGXABAM+gJXxbyXELEwjnppP2qCYE+gSTzwJH3Jnz4UMj2oT9bjZjBp1jOy 7CaXY0VYnVqLZhbHwTmUC4A1eIQrzN+4Cag3FVoWE2oLUpi1/GK6iYmDJpy2owA/ 1kirT89sMqehaoTS02EnBfSusX9DN0qDmUK0ddxtv8jUiEz408+ujs5YPRuVG71z 5ISuymx9Sf8e9RA+TFNm252PIJWKtumi9uddG0As/FF4Qy+LMmY94RX+aXyBcQU9 r0A1nkX8/UmjqaUx61um2/t2PDfTBCDwl0ORat4ERHHc0vfQLYnvPYLZzKj/jNn6 guflkExS5qpwbiuvWFgvFiFTAi9Og5tF2ks+sqdb3PWoie2snStGKboivQKof4qb 7BStuSWVP1aeUieGn7fqCWhLlr9VSC0r2czEShkVde4TWC/cV5F38NfSGmbYssrQ 97zjbup6+/fL5MKmOaoDY2kOS1/XPzrB/BDK+d83w98cb03txezZCwtM2QPzn/48 1QvL3n3XMna31XHa8ljHldrX2c7bm2lpkhJPL5269pFznMRZOA4= =Lg+P -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat session replication
Am 27. Juni 2020 11:29:03 MESZ schrieb Mark Thomas : >On 27/06/2020 10:19, Thomas Meyer wrote: >> Hi, >> >> A few questions regarding tomcat session replication: > >load-balancing and session replication are two separate parts of an >overall clustering solution. > >> 1) is the jvmRoute attribute on Engine object necessary for session >replication to work correctly? > >No, but if you don't use it it places a number of restrictions on the >web application behaviour and on the configuration of session >replication. > >The limitations are: >- you need to use the DeltaManager (which doesn't scale as well as the > BackupManager); Yes, I'm using default DeltaManager as I will only have two pods running Tomcat. >- any requests made by the client that depend on the session MUST be > issued in series, not in parallel; and Not sure about this one, the app uses spring default security for login. So need to check this one. >- the session Manager must be configured to update all the other nodes > in the cluster BEFORE the current request returns to the client. How to do that? I did have a look at Manager/DeltaManager attributes but didn't see something that looks like above setting. Can you plea point me in the right direction? > >> 2) does session replication only work correctly with sticky load >balancer routing? > >No. It works quite happily without it. Good to know. > >> >> My setup is >> 1) load balancer without sticky session routing into kubernetes >> 2) two pods running tomcat with cloud member provider, which see and >find each other >> >> No jvmRoute attribute is set. Another question regarding jvmRoute: Even if my load balancer has no sticky sessions, should I add jvmRoute attribute? I think I could easily add the pod's name as jvmRoute. >> >> Above setup doesn't work and give strange errors for the distributed >webapp which relies on http sessions. >> >> Should above setup work? If not why and what do I need to fix? >> >> Any hints of what logging to enable to debug the problem if any at >all? > >Please show us how you have configured the session manager and >clustering. My setup is just go with the defaults: In the logs I can see the member appears/disappears messages, which is a good thing I guess. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat session replication
On 27/06/2020 10:19, Thomas Meyer wrote: > Hi, > > A few questions regarding tomcat session replication: load-balancing and session replication are two separate parts of an overall clustering solution. > 1) is the jvmRoute attribute on Engine object necessary for session > replication to work correctly? No, but if you don't use it it places a number of restrictions on the web application behaviour and on the configuration of session replication. The limitations are: - you need to use the DeltaManager (which doesn't scale as well as the BackupManager); - any requests made by the client that depend on the session MUST be issued in series, not in parallel; and - the session Manager must be configured to update all the other nodes in the cluster BEFORE the current request returns to the client. > 2) does session replication only work correctly with sticky load balancer > routing? No. It works quite happily without it. > > My setup is > 1) load balancer without sticky session routing into kubernetes > 2) two pods running tomcat with cloud member provider, which see and find > each other > > No jvmRoute attribute is set. > > Above setup doesn't work and give strange errors for the distributed webapp > which relies on http sessions. > > Should above setup work? If not why and what do I need to fix? > > Any hints of what logging to enable to debug the problem if any at all? Please show us how you have configured the session manager and clustering. Mark > Mfg > Thomas > > - > 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
Tomcat session replication
Hi, A few questions regarding tomcat session replication: 1) is the jvmRoute attribute on Engine object necessary for session replication to work correctly? 2) does session replication only work correctly with sticky load balancer routing? My setup is 1) load balancer without sticky session routing into kubernetes 2) two pods running tomcat with cloud member provider, which see and find each other No jvmRoute attribute is set. Above setup doesn't work and give strange errors for the distributed webapp which relies on http sessions. Should above setup work? If not why and what do I need to fix? Any hints of what logging to enable to debug the problem if any at all? Mfg Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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 ?
Any experiences with Tomcat 9 session replication using overlay network to simulate broadcast/multicast?
I am researching if a packaged application built on Tomcat (not 100% sure of version but assuming 9 until I know 100% sure) using session state replication as described here http://tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html would work in an environment where broadcast/multicast is not enabled in the base networ but an overlay network is set up for the Tomcat instances for instance as described in this guide written by AWS https://aws.amazon.com/articles/overlay-multicast-in-amazon-virtual-private-cloud/? Any positive or negative experiences, tips, known "gotchas" etc. with this that you can share with me? Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, R.C.S. Luxembourg B186284 Amazon Web Services EMEA SARL, Sverige filial, Kungsgatan 49, 111 22 Stockholm, Sweden, branch register of Bolagsverket, registration no. 516411-0669
Re: Cluster session replication performance
https://bz.apache.org/bugzilla/show_bug.cgi?id=62723 Mitch On 09/14/2018 10:10 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mitch, On 9/14/18 09:43, Mitch Claborn wrote: On 09/13/2018 08:10 PM, Christopher Schultz wrote: Mitch, On 9/13/18 10:29, Mitch Claborn wrote: On 09/12/2018 11:37 AM, Christopher Schultz wrote: Would you care to submit a documentation patch/PR? Get your name in the ChangeLog and you get the text that makes the most sense to you:) Sure. How do I go about that? That kind of depends upon whether you like Subversion or git better. Do you have a preference? git I've used subversion in the past, but it's been a LONG time. Here's the git mirror: http://tomcat.apache.org/svn.html#Git_Mirror Feel free to clone that or fork it on Github or whatever. If you fork, submit a PR. If you clone, submit a patch using "git diff" attached to a bugzilla issue, or you can email it to the dev mailing list. Bugzilla is a bit nicer, since we can see diffs-in-context from there. The pages for the documentation are in the webapps/docs directory, and they are all XML which get transformed into HTML using XSLT for publication using. It's not really tough to figure out what's going on. So the files you are looking for are webapps/docs/cluster-howto.xml and webapps/docs/config/cluster.xml. If you want to preview your HTML, run "ant build-docs" (you'll need Apache Ant for this, of course) and it will build the documentation webapp. Write back if you need any help. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlubz3wACgkQHPApP6U8 pFjrahAAmmeSzKMh2Eq+gdfiY07ediDxvanbY/ljBr5QzO++OnzbWXubd+s8XQWR yQHBffv+Ff4jD2ksDQDs12slMxkmCtT2LzwXSroZXeqS8DE1WPwb8SF1ujvX05XD toPq6Wm5OfMAGl8rAC01ZSLM8+p1JYJacvnYbouG/+cIopg1xew+y1PryMJ5PyFg rbCr6Bva4cbqM8E/L2ehA/+IqbR5bMnxBFmlxRqzEyX7BrJg4DaFu6A9s5S38j2f IM2Xmc6RM9lfRJv86pWs6gUZv98ty+1TvFQPNFueVcr1H15af47IwZkRlDG5xVEs 1wc6nEpfpHnAkZ90B7juKp3OlmNLIJINWZCZ+4af3cFX12/B4A6VNK5huaul1ybt DEXSCUfpj+8taCYKmYqeisarAaOXvWTY8JP0TUIoz0bQREFUBb91lSTK9kMUK9Gs vLHAS69n+pt9PvWyoiBud0gDDEYj2LLzFkfhPNf/8ZL51HGCq/hxBtFXWFdTCX2q lECc/WEO0GPh24DWikKRLn+aw9pre5308CS5EAIlnr9fVEKx9v0Et9Nrpf7quK/+ POkur3KqaCD8MSbhKtbBqYoVcr2MyXW/YBNaT/io+JGok4677IhMUDHxvA4P+8cM LSdEWT3zFlEanxfYjIE0qY1vS1/vdeIWdDOG+jU89I/MsbEE+Q4= =aFbP -END PGP SIGNATURE- - 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: Cluster session replication performance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mitch, On 9/14/18 09:43, Mitch Claborn wrote: > On 09/13/2018 08:10 PM, Christopher Schultz wrote: Mitch, > > On 9/13/18 10:29, Mitch Claborn wrote: On 09/12/2018 11:37 AM, Christopher Schultz wrote: > Would you care to submit a documentation patch/PR? > > Get your name in the ChangeLog and you get the text that > makes the most sense to you:) Sure. How do I go about that? >> >> That kind of depends upon whether you like Subversion or git >> better. Do you have a preference? > > git > > I've used subversion in the past, but it's been a LONG time. Here's the git mirror: http://tomcat.apache.org/svn.html#Git_Mirror Feel free to clone that or fork it on Github or whatever. If you fork, submit a PR. If you clone, submit a patch using "git diff" attached to a bugzilla issue, or you can email it to the dev mailing list. Bugzilla is a bit nicer, since we can see diffs-in-context from there. The pages for the documentation are in the webapps/docs directory, and they are all XML which get transformed into HTML using XSLT for publication using. It's not really tough to figure out what's going on. So the files you are looking for are webapps/docs/cluster-howto.xml and webapps/docs/config/cluster.xml. If you want to preview your HTML, run "ant build-docs" (you'll need Apache Ant for this, of course) and it will build the documentation webapp. Write back if you need any help. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlubz3wACgkQHPApP6U8 pFjrahAAmmeSzKMh2Eq+gdfiY07ediDxvanbY/ljBr5QzO++OnzbWXubd+s8XQWR yQHBffv+Ff4jD2ksDQDs12slMxkmCtT2LzwXSroZXeqS8DE1WPwb8SF1ujvX05XD toPq6Wm5OfMAGl8rAC01ZSLM8+p1JYJacvnYbouG/+cIopg1xew+y1PryMJ5PyFg rbCr6Bva4cbqM8E/L2ehA/+IqbR5bMnxBFmlxRqzEyX7BrJg4DaFu6A9s5S38j2f IM2Xmc6RM9lfRJv86pWs6gUZv98ty+1TvFQPNFueVcr1H15af47IwZkRlDG5xVEs 1wc6nEpfpHnAkZ90B7juKp3OlmNLIJINWZCZ+4af3cFX12/B4A6VNK5huaul1ybt DEXSCUfpj+8taCYKmYqeisarAaOXvWTY8JP0TUIoz0bQREFUBb91lSTK9kMUK9Gs vLHAS69n+pt9PvWyoiBud0gDDEYj2LLzFkfhPNf/8ZL51HGCq/hxBtFXWFdTCX2q lECc/WEO0GPh24DWikKRLn+aw9pre5308CS5EAIlnr9fVEKx9v0Et9Nrpf7quK/+ POkur3KqaCD8MSbhKtbBqYoVcr2MyXW/YBNaT/io+JGok4677IhMUDHxvA4P+8cM LSdEWT3zFlEanxfYjIE0qY1vS1/vdeIWdDOG+jU89I/MsbEE+Q4= =aFbP -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cluster session replication performance
git I've used subversion in the past, but it's been a LONG time. Mitch On 09/13/2018 08:10 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mitch, On 9/13/18 10:29, Mitch Claborn wrote: On 09/12/2018 11:37 AM, Christopher Schultz wrote: Would you care to submit a documentation patch/PR? Get your name in the ChangeLog and you get the text that makes the most sense to you:) Sure. How do I go about that? That kind of depends upon whether you like Subversion or git better. Do you have a preference? - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlubCpsACgkQHPApP6U8 pFjwdBAAmsVEgl/0ItSMfW/W9wM6wyPrKmP2KaVOv6EYVg7v0ioQOkPfengZkTip Jf7aQc6h6G9hoO43+2ZZbedhV/9rWYyMAbO7aCAAB9Jr/fNETcrTYWkJ/g51YYVY Ztx4esCzxrthUu6CMOOqKVb/zi3IsZwmKawJ8tISj02D4JOIHIKJ4I3vJV363Xby oHTuT3LGH8Mu3LuBqf5wsWZV4LsC/19jOHUdCvGr2Jg+vd+x0Vj4nzuNCzNy7b6v ScK2rYHR6itM5PaVuA43IGNbtQ+6GnWxKRsuk6TN/3Yah7Dp0U24CE9TggtSDi0a AdLOuNWhaAXntoHCVhLqbxHuNWklGh7zKHGtMjp+mWhmVmST2nY1wB18YshQRHe4 Ppt7wZW48aKVB2EBdPMe1w9Ko2xJwqrKbNTryro9bP2GS08d2EDo94cTOUg7H77r AYfv+UNUI95SCEaUoqg94oAjfB3NJvCBOYUdT6GOR4hrVR4nhiKs9sgDu8zt++WK 5QAlA5nrS0i6iijpxbz8eziHjTPUgUfuy68N4R0kfWs2O1rmqHzjYKT6/fLRq90E /74wahdz/L5zHJncGE/gysu0yH3l9R5ZGCnANdH4KLtTvKctS6/q2lERiWpPHCPE AL9PHHzYlQbpiBF5AMNkcgxJEcn8Om3YX2j/G/lDrHDn5/IOuyE= =ztkd -END PGP SIGNATURE- - 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: Cluster session replication performance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mitch, On 9/13/18 10:29, Mitch Claborn wrote: > On 09/12/2018 11:37 AM, Christopher Schultz wrote: >> Would you care to submit a documentation patch/PR? >> >> Get your name in the ChangeLog and you get the text that makes >> the most sense to you:) > > Sure. How do I go about that? That kind of depends upon whether you like Subversion or git better. Do you have a preference? - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlubCpsACgkQHPApP6U8 pFjwdBAAmsVEgl/0ItSMfW/W9wM6wyPrKmP2KaVOv6EYVg7v0ioQOkPfengZkTip Jf7aQc6h6G9hoO43+2ZZbedhV/9rWYyMAbO7aCAAB9Jr/fNETcrTYWkJ/g51YYVY Ztx4esCzxrthUu6CMOOqKVb/zi3IsZwmKawJ8tISj02D4JOIHIKJ4I3vJV363Xby oHTuT3LGH8Mu3LuBqf5wsWZV4LsC/19jOHUdCvGr2Jg+vd+x0Vj4nzuNCzNy7b6v ScK2rYHR6itM5PaVuA43IGNbtQ+6GnWxKRsuk6TN/3Yah7Dp0U24CE9TggtSDi0a AdLOuNWhaAXntoHCVhLqbxHuNWklGh7zKHGtMjp+mWhmVmST2nY1wB18YshQRHe4 Ppt7wZW48aKVB2EBdPMe1w9Ko2xJwqrKbNTryro9bP2GS08d2EDo94cTOUg7H77r AYfv+UNUI95SCEaUoqg94oAjfB3NJvCBOYUdT6GOR4hrVR4nhiKs9sgDu8zt++WK 5QAlA5nrS0i6iijpxbz8eziHjTPUgUfuy68N4R0kfWs2O1rmqHzjYKT6/fLRq90E /74wahdz/L5zHJncGE/gysu0yH3l9R5ZGCnANdH4KLtTvKctS6/q2lERiWpPHCPE AL9PHHzYlQbpiBF5AMNkcgxJEcn8Om3YX2j/G/lDrHDn5/IOuyE= =ztkd -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cluster session replication performance
Sure. How do I go about that? Mitch On 09/12/2018 11:37 AM, Christopher Schultz wrote: Would you care to submit a documentation patch/PR? Get your name in the ChangeLog and you get the text that makes the most sense to you:) - -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cluster session replication performance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mitch, On 9/12/18 12:01 PM, Mitch Claborn wrote: > Thanks Mark. I changed to channelSendOptions="2" and the failure > rate of my health check program has dropped significantly, down to > 1 - 2 per 24 hours. > > I did quite a bit of reading in the doc before posting this, but > your explanation of the options is much better than the doc. I > suggest that the doc be updated with your explanation below. I > would put it in the following locations: > http://tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html#Cluster_Inf ormation > > > > http://tomcat.apache.org/tomcat-9.0-doc/config/cluster.html#SimpleTcpC luster_Attributes > > > > and also in the javadoc for Channel.java Would you care to submit a documentation patch/PR? Get your name in the ChangeLog and you get the text that makes the most sense to you :) - -chris > On 09/10/2018 03:15 PM, Mark Thomas wrote: >> On 10/09/18 17:33, Mitch Claborn wrote: >>> Further information and questions. >>> >>> I created my own interceptor based on ThroughputInterceptor so >>> that I could log the timing of specific sessions to correlate >>> them with the failures in my health check program. I was >>> surprised to find that in those instances where the health >>> check reported a failure, the interceptor reported that the >>> session send was accomplished in < 5 ms, while the health check >>> app is waiting a full 1000 ms between calls to the different >>> tomcat instances. So now I'm more confused than ever. >>> >>> Anyone have any ideas? >>> >>> In a ChannelInterceptor, does when >>> getNext().sendMessage(destination, msg, payload) returns, does >>> that mean that the message has been sent AND received by the >>> recipient member, or does that only indicate a send? >> >> You are using: channelSendOptions="8" >> >> That means that, as far as the sender is concerned, the message >> is sent as soon as it has been placed in the queue on the sender >> for transmission to the other nodes. >> >> If you use async sending, the options to enable ACKS don't offer >> very much - if anything. >> >> If you configure channelSendOptions="2" the the sender will block >> the completion of the current request until all of the receiving >> nodes have acknowledged that they have received the message. >> >> If you configure channelSendOptions="6" the the sender will block >> the completion of the current request until all of the receiving >> nodes have acknowledged that they have received and processed the >> message. >> >> There is a trade-off here between throughput on the sender vs >> reliability of replication if the sender fails. >> >> Mark >> >> - >> >> 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 > -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAluZQLAACgkQHPApP6U8 pFjEsBAAg1VStKh6RAUiZdsV//AuDtNEzRGHzNiXxOfqsKkyLqki474aKgFFuDkm Be/kpvmkN8w2Z+8gKuTstLCGVAGTW9/3X4AEPgfvF3KFpb25qkJv3HCYbjOgLIej Mym4+WYSV/SYvPZhUc2qvreiKtL9fW81Qc2Cb5E4d8+qHTzIAjqA3/qjlYIV0So+ Cq6EIVbY9aqkx8qOygiRI3VHRPL7tRExvC6wqvYP8XPHK8xV2y3cmiGrrjWsu+tD tk0dOh8O1j4zzxVvTIE/LxkSRXKtKO9s2A+CaxgmQwYG+Ljn9XzxGXC6qRa/9WNX cFGHk+KPy6RjH6XY9WXUHChMi+RFERCgfIJgiKrWkPsfeENbAGQeqi6aAp3GjjTX w6U5dggBd5NSzTDOJJ/0DV466hmQ4HiJj2wo1gKdQh0f78RHbLkuLfjuCPGw21Yk 4ou9jxGcZoFnaVvA1ymGuyEVysHV1KHY8/+KU0BNPHbNVDZz/ZuSL6NL+2cA5UaR j0LQOrJ/EScKb+60CqkmEDvc4y52Yfw216ghKUBObG7UA7h26l0ZmCEqt6VszSeG BiDXwV90TgR3OLgqXIbxfC88P3wFHyV1OCESs5Bsm4JpuX18E8ptvuTcsmv4vn5h JCunc+NWQ/WZz9p4l2hCCmVrbbdYK6MHHq7SnEk27FU1YpIVbYQ= =uEhw -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cluster session replication performance
Thanks Mark. I changed to channelSendOptions="2" and the failure rate of my health check program has dropped significantly, down to 1 - 2 per 24 hours. I did quite a bit of reading in the doc before posting this, but your explanation of the options is much better than the doc. I suggest that the doc be updated with your explanation below. I would put it in the following locations: http://tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html#Cluster_Information http://tomcat.apache.org/tomcat-9.0-doc/config/cluster.html#SimpleTcpCluster_Attributes and also in the javadoc for Channel.java Mitch On 09/10/2018 03:15 PM, Mark Thomas wrote: On 10/09/18 17:33, Mitch Claborn wrote: Further information and questions. I created my own interceptor based on ThroughputInterceptor so that I could log the timing of specific sessions to correlate them with the failures in my health check program. I was surprised to find that in those instances where the health check reported a failure, the interceptor reported that the session send was accomplished in < 5 ms, while the health check app is waiting a full 1000 ms between calls to the different tomcat instances. So now I'm more confused than ever. Anyone have any ideas? In a ChannelInterceptor, does when getNext().sendMessage(destination, msg, payload) returns, does that mean that the message has been sent AND received by the recipient member, or does that only indicate a send? You are using: channelSendOptions="8" That means that, as far as the sender is concerned, the message is sent as soon as it has been placed in the queue on the sender for transmission to the other nodes. If you use async sending, the options to enable ACKS don't offer very much - if anything. If you configure channelSendOptions="2" the the sender will block the completion of the current request until all of the receiving nodes have acknowledged that they have received the message. If you configure channelSendOptions="6" the the sender will block the completion of the current request until all of the receiving nodes have acknowledged that they have received and processed the message. There is a trade-off here between throughput on the sender vs reliability of replication if the sender fails. Mark - 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: Cluster session replication performance
On 10/09/18 17:33, Mitch Claborn wrote: > Further information and questions. > > I created my own interceptor based on ThroughputInterceptor so that I > could log the timing of specific sessions to correlate them with the > failures in my health check program. I was surprised to find that in > those instances where the health check reported a failure, the > interceptor reported that the session send was accomplished in < 5 ms, > while the health check app is waiting a full 1000 ms between calls to > the different tomcat instances. So now I'm more confused than ever. > > Anyone have any ideas? > > In a ChannelInterceptor, does when getNext().sendMessage(destination, > msg, payload) returns, does that mean that the message has been sent AND > received by the recipient member, or does that only indicate a send? You are using: channelSendOptions="8" That means that, as far as the sender is concerned, the message is sent as soon as it has been placed in the queue on the sender for transmission to the other nodes. If you use async sending, the options to enable ACKS don't offer very much - if anything. If you configure channelSendOptions="2" the the sender will block the completion of the current request until all of the receiving nodes have acknowledged that they have received the message. If you configure channelSendOptions="6" the the sender will block the completion of the current request until all of the receiving nodes have acknowledged that they have received and processed the message. There is a trade-off here between throughput on the sender vs reliability of replication if the sender fails. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cluster session replication performance
Further information and questions. I created my own interceptor based on ThroughputInterceptor so that I could log the timing of specific sessions to correlate them with the failures in my health check program. I was surprised to find that in those instances where the health check reported a failure, the interceptor reported that the session send was accomplished in < 5 ms, while the health check app is waiting a full 1000 ms between calls to the different tomcat instances. So now I'm more confused than ever. Anyone have any ideas? In a ChannelInterceptor, does when getNext().sendMessage(destination, msg, payload) returns, does that mean that the message has been sent AND received by the recipient member, or does that only indicate a send? Mitch On 09/06/2018 01:53 PM, Mitch Claborn wrote: I'm using a cluster with the DeltaManager between two servers on Tomcat 9.0.11. I've set channelSendOptions="8" (asynchronous session replication). I have a "health check" app that I run periodically, one of the functions being to check that sessions are being replicated properly. That app 1) Does a GET to tomcat A, calling a Struts action that creates a session and stores a known value in it 2) Waits 2 seconds 3) Uses the session ID cookie from step 1 and makes a call to tomcat B, to an action that retrieves that value from the session 4) Compares the two values from the session to make sure that they are the same. Most of the time this check works fine, but occasionally the call to the second server will find that the session does not exist on that server, presumably because it has not yet replicated there yet. 2 seconds seems a long time for a session to replicate, especially one as small as this one is. If I decrease the amount of wait time at step 2, the failure rate increases. I turned on the ThroughputInterceptor and have the following observations. - Server A has a transmit throughput around 10 MB/sec while B has only around 3 MB/sec. This might be accounted for by the fact that B was the last server to start, so A would have (I think) transmitted all of the sessions at once when B started up, so it might get good throughput from the big send?? Questions: 1. IS 2 seconds a long time to replicate a session? 2. Other than actual network slowness, are there internal issues that could cause the replication to be slow? 3. If so, is there anyway to diagnose those? 4. I'm thinking about writing my own version of ThroughputInterceptor that will give more information on specific messages and timings. Has anyone tried that? In that interceptor can I access the session ID? That would help me correlate timings between my failure reports and the interceptor. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Cluster session replication performance
I'm using a cluster with the DeltaManager between two servers on Tomcat 9.0.11. I've set channelSendOptions="8" (asynchronous session replication). I have a "health check" app that I run periodically, one of the functions being to check that sessions are being replicated properly. That app 1) Does a GET to tomcat A, calling a Struts action that creates a session and stores a known value in it 2) Waits 2 seconds 3) Uses the session ID cookie from step 1 and makes a call to tomcat B, to an action that retrieves that value from the session 4) Compares the two values from the session to make sure that they are the same. Most of the time this check works fine, but occasionally the call to the second server will find that the session does not exist on that server, presumably because it has not yet replicated there yet. 2 seconds seems a long time for a session to replicate, especially one as small as this one is. If I decrease the amount of wait time at step 2, the failure rate increases. I turned on the ThroughputInterceptor and have the following observations. - Server A has a transmit throughput around 10 MB/sec while B has only around 3 MB/sec. This might be accounted for by the fact that B was the last server to start, so A would have (I think) transmitted all of the sessions at once when B started up, so it might get good throughput from the big send?? Questions: 1. IS 2 seconds a long time to replicate a session? 2. Other than actual network slowness, are there internal issues that could cause the replication to be slow? 3. If so, is there anyway to diagnose those? 4. I'm thinking about writing my own version of ThroughputInterceptor that will give more information on specific messages and timings. Has anyone tried that? In that interceptor can I access the session ID? That would help me correlate timings between my failure reports and the interceptor. -- Mitch - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why Tomcat Session Replication requires Sticky Sessions
On 29 September 2017 15:38:12 BST, "Singh, Rahul (CWM-NR)" <rahul.si...@rbccm.com> wrote: >Hi, >We are using Tomcat 7 >My question is - Why does Tomcat Session Replication require Sticky >sessions to be enabled? It doesn't. >We cannot have a sticky session setup in our servers, due to policy >issues. To maintain session state across different machines, we were >planning to use session replication. But it seems stickiness is a >pre-condition for session replication. Why? Is it not a replacement for >sticky sessions? Sticky sessions are advisable in some configurations. Since you haven't explained what you are trying do or provided your cluster configuration... Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Why Tomcat Session Replication requires Sticky Sessions
Hi, We are using Tomcat 7 My question is - Why does Tomcat Session Replication require Sticky sessions to be enabled? We cannot have a sticky session setup in our servers, due to policy issues. To maintain session state across different machines, we were planning to use session replication. But it seems stickiness is a pre-condition for session replication. Why? Is it not a replacement for sticky sessions? Regards, Rahul __ This email is intended only for the use of the individual(s) to whom it is addressed and may be privileged and confidential. Unauthorised use or disclosure is prohibited. If you receive this e-mail in error, please advise immediately and delete the original message. This message may have been altered without your or our knowledge and the sender does not accept any liability for any errors or omissions in the message. Emails are monitored by supervisory personnel in jurisdictions where monitoring is permitted. Such communications are retained and may be produced to regulatory authorities or others with legal rights to the information.
Tomcat Session Replication.
Good Day! In the documentation, it says that with autobind, if port is unavailable it will try to work its way up to the port+autobind. But Members' port and Receiver's port should be the same. Is this correct? I would like to ask how does port behaves on Receiver with autobind and the Members port when the Receiver's port is unavailable? I'm using Tomcat 8.0.36 and Ubuntu. Thanks. Regards, Andrei
Re: Session replication will never happen after disabling session persistence across Tomcat restarts
Yes, I think if uncommented the The ClustedManage could be disabled even if is defined. 在 16/4/25 下午12:57, Keiichi Fujino 写道: 2016-04-23 15:29 GMT+09:00 sanigo <san...@gmail.com>: Hi! I have tested quite a few times to confirm that session replication will not happen after uncommenting in conf/context.xml. If the line is commented out, the session replication will work happily. Is there a warning message to your log files? such as [Manager [xxx] does not implement ClusterManager, addition to cluster has been aborted.] if you have uncommented in conf/context.xml, All of the Web applications on your Tomcat use the StandardManager as a session manager. The StandardManager cannot replicate session. If you want to replicate session, you have to use ClusteManager(DeltaManager/BackupManager) as a session manager. Usually defines a cluster manager template in the / , and then it is cloned by distributable web application. The versions I have tested are 7.0.68 and 7.0.69. Any ideas? san...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Keiichi.Fujino <users-h...@tomcat.apache.org> <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: Session replication will never happen after disabling session persistence across Tomcat restarts
2016-04-23 15:29 GMT+09:00 sanigo <san...@gmail.com>: > Hi! >I have tested quite a few times to confirm that session replication > will not happen after uncommenting in > conf/context.xml. >If the line is commented out, the session replication will work > happily. > Is there a warning message to your log files? such as [Manager [xxx] does not implement ClusterManager, addition to cluster has been aborted.] if you have uncommented in conf/context.xml, All of the Web applications on your Tomcat use the StandardManager as a session manager. The StandardManager cannot replicate session. If you want to replicate session, you have to use ClusteManager(DeltaManager/BackupManager) as a session manager. Usually defines a cluster manager template in the / , and then it is cloned by distributable web application. >The versions I have tested are 7.0.68 and 7.0.69. >Any ideas? > san...@gmail.com > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- > Keiichi.Fujino > <users-h...@tomcat.apache.org> <users-h...@tomcat.apache.org>
Session replication will never happen after disabling session persistence across Tomcat restarts
Hi! I have tested quite a few times to confirm that session replication will not happen after uncommenting in conf/context.xml. If the line is commented out, the session replication will work happily. The versions I have tested are 7.0.68 and 7.0.69. Any ideas? san...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cluster session replication issue: servlet hang on restart only under load
After playing with static clustering a few more days, I still ran headlong into a wall with this. I decided to go back to multicast, and try BackupManager instead of DeltaManager, and it now seems to be restarting correctly, as long as my timeout was high enough for the 15+ second AbstractMapReplication init. Overall it takes about 65 seconds for server startup compared to 15 sec for static deltaManager and 30 sec for multicast deltaManager. But the important part is that it eventually does start the server while under load, and session failover seems to work as expected. Unfortunately using backupManager is not my preferred solution, but it may be the only option until I can figure out why DeltaManager is broken in our environment. I would still love to hear if anyone has any suggestions as to why backup manager is working but delta manager is broken. Thank you, -Anthony On 3/25/2016 10:28 AM, Anthony Sturchio wrote: Thanks for the response. I apologize if I'm using the incorrect terminology here, as this is one of the smaller "hats" that I wear at work. Basically, coldfusion runs on top of a (possibly customized) tomcat backend. Each instance has its own server.xml and web.xml. As best I can figure, when starting CF, it starts tomcat in the JRE, and if applicable, starts deltamanager to handle the clustering business. After the sessions are replicated, the servlet (coldfusion server) starts up with the connector ports specified in server.xml. This all happens relatively smoothly in testing without any appreciable load. However when the box is added back into our webserver farm (via hardware load balancer), or if I create artificial load against the box using apache jmeter, session replication is not successful, and the coldfusion server never loads. I don't get any errors written to screen or log, nor does kill -3 give me anything, but as per ps aux, the java process is still running. The replication ports and Catalina connector ports are open, however the overall server shutdown port is not open, if that offers any clues. Web pages are being served via apache httpd and mod_jk and AJP/1.3. Thank you, -Anthony On 3/25/2016 10:09 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Anthony, On 3/25/16 9:41 AM, Anthony Sturchio wrote: We recently updated our Coldfusion 10 server to update 18, which moved us up to Tomcat 7.0.64, and we are now experiencing issues when restarting a CF instance. I understand that this is not a coldfuison forum, but since CF10 is based on top of a tomcat back end, which is where the issue appears to be, I figured I would ask here. As best I can figure, it appears that while under moderate load, DeltaManager sessions dont replicate, and the servlet hangs and never fully starts up. Without any load, the CF instance (servlet) starts up perfectly fine without issue. Can you clarify what it means for a servlet that has not yet started up to be "under load"? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools -http://gpgtools.org Comment: Using GnuPG with Thunderbird -http://www.enigmail.net/ iEYEARECAAYFAlb1RoIACgkQ9CaO5/Lv0PBpxgCggKFVpE/HM++CSwsGw73r6Yni UHYAn2dcnX/FomVD19Tz+TjEe1cMi/Zd =ruIF -END PGP SIGNATURE- - To unsubscribe, e-mail:users-unsubscr...@tomcat.apache.org For additional commands, e-mail:users-h...@tomcat.apache.org
Re: Cluster session replication issue: servlet hang on restart only under load
Thank you David, but this is happening on service restart, not operating system restart. But, yes, you can modify startup scripts to happen in sequence, or add a sleep delay. Thank you, -Anthony On 3/25/2016 10:11 AM, David kerber wrote: On 3/25/2016 9:41 AM, Anthony Sturchio wrote: Hello We recently updated our Coldfusion 10 server to update 18, which moved us up to Tomcat 7.0.64, and we are now experiencing issues when restarting a CF instance. I understand that this is not a coldfuison forum, but since CF10 is based on top of a tomcat back end, which is where the issue appears to be, I figured I would ask here. As best I can figure, it appears that while under moderate load, DeltaManager sessions dont replicate, and the servlet hangs and never fully starts up. Without any load, the CF instance (servlet) starts up perfectly fine without issue. I have recently tested on a fresh install of CentOS 6.7 64 Bit, with newly installed Coldfusion 10 update 18, and JDK 1.7.0_95, and can confirm this issue happens out of the box. In windows, there is an option to delay the automatic startup of services so that you can be sure all the things it depends on are ready. I have found that it can help with intermittent startup issues. Is there such a thing in CentOS that you could try? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cluster session replication issue: servlet hang on restart only under load
Thanks for the response. I apologize if I'm using the incorrect terminology here, as this is one of the smaller "hats" that I wear at work. Basically, coldfusion runs on top of a (possibly customized) tomcat backend. Each instance has its own server.xml and web.xml. As best I can figure, when starting CF, it starts tomcat in the JRE, and if applicable, starts deltamanager to handle the clustering business. After the sessions are replicated, the servlet (coldfusion server) starts up with the connector ports specified in server.xml. This all happens relatively smoothly in testing without any appreciable load. However when the box is added back into our webserver farm (via hardware load balancer), or if I create artificial load against the box using apache jmeter, session replication is not successful, and the coldfusion server never loads. I don't get any errors written to screen or log, nor does kill -3 give me anything, but as per ps aux, the java process is still running. The replication ports and Catalina connector ports are open, however the overall server shutdown port is not open, if that offers any clues. Web pages are being served via apache httpd and mod_jk and AJP/1.3. Thank you, -Anthony On 3/25/2016 10:09 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Anthony, On 3/25/16 9:41 AM, Anthony Sturchio wrote: We recently updated our Coldfusion 10 server to update 18, which moved us up to Tomcat 7.0.64, and we are now experiencing issues when restarting a CF instance. I understand that this is not a coldfuison forum, but since CF10 is based on top of a tomcat back end, which is where the issue appears to be, I figured I would ask here. As best I can figure, it appears that while under moderate load, DeltaManager sessions dont replicate, and the servlet hangs and never fully starts up. Without any load, the CF instance (servlet) starts up perfectly fine without issue. Can you clarify what it means for a servlet that has not yet started up to be "under load"? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlb1RoIACgkQ9CaO5/Lv0PBpxgCggKFVpE/HM++CSwsGw73r6Yni UHYAn2dcnX/FomVD19Tz+TjEe1cMi/Zd =ruIF -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cluster session replication issue: servlet hang on restart only under load
On 3/25/2016 9:41 AM, Anthony Sturchio wrote: Hello We recently updated our Coldfusion 10 server to update 18, which moved us up to Tomcat 7.0.64, and we are now experiencing issues when restarting a CF instance. I understand that this is not a coldfuison forum, but since CF10 is based on top of a tomcat back end, which is where the issue appears to be, I figured I would ask here. As best I can figure, it appears that while under moderate load, DeltaManager sessions dont replicate, and the servlet hangs and never fully starts up. Without any load, the CF instance (servlet) starts up perfectly fine without issue. I have recently tested on a fresh install of CentOS 6.7 64 Bit, with newly installed Coldfusion 10 update 18, and JDK 1.7.0_95, and can confirm this issue happens out of the box. In windows, there is an option to delay the automatic startup of services so that you can be sure all the things it depends on are ready. I have found that it can help with intermittent startup issues. Is there such a thing in CentOS that you could try? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cluster session replication issue: servlet hang on restart only under load
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Anthony, On 3/25/16 9:41 AM, Anthony Sturchio wrote: > We recently updated our Coldfusion 10 server to update 18, which > moved us up to Tomcat 7.0.64, and we are now experiencing issues > when restarting a CF instance. I understand that this is not a > coldfuison forum, but since CF10 is based on top of a tomcat back > end, which is where the issue appears to be, I figured I would ask > here. As best I can figure, it appears that while under moderate > load, DeltaManager sessions dont replicate, and the servlet hangs > and never fully starts up. Without any load, the CF instance > (servlet) starts up perfectly fine without issue. Can you clarify what it means for a servlet that has not yet started up to be "under load"? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlb1RoIACgkQ9CaO5/Lv0PBpxgCggKFVpE/HM++CSwsGw73r6Yni UHYAn2dcnX/FomVD19Tz+TjEe1cMi/Zd =ruIF -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Cluster session replication issue: servlet hang on restart only under load
Hello
We recently updated our Coldfusion 10 server to update 18, which moved
us up to Tomcat 7.0.64, and we are now experiencing issues when
restarting a CF instance. I understand that this is not a coldfuison
forum, but since CF10 is based on top of a tomcat back end, which is
where the issue appears to be, I figured I would ask here. As best I
can figure, it appears that while under moderate load, DeltaManager
sessions dont replicate, and the servlet hangs and never fully starts
up. Without any load, the CF instance (servlet) starts up perfectly
fine without issue.
I have recently tested on a fresh install of CentOS 6.7 64 Bit, with
newly installed Coldfusion 10 update 18, and JDK 1.7.0_95, and can
confirm this issue happens out of the box.
I have set up my server.xml files for both instances using both dynamic
(multicast) as well as static members, but both hang in the same way.
It seems that Deltamanager is simply unable to send the sessions to the
restarted / recovered member while under load. If I remove the load
from the box, it restarts normally without any issue. I have set the
Transport and Receiver timeouts to as high as 120 seconds, without any
success.
Any suggestions on how to troubleshoot would be greatly appreciated.
Here's the error from the first instance:
Mar 25, 2016 2:46:47 AM org.apache.catalina.ha.tcp.SimpleTcpCluster send
SEVERE: Unable to send message through cluster sender.
org.apache.catalina.tribes.ChannelException: Operation has timed
out(3 ms.).; Faulty members:tcp://{10, 10, 2, 84}:4002;
at
org.apache.catalina.tribes.transport.nio.ParallelNioSender.sendMessage(ParallelNioSender.java:109)
at
org.apache.catalina.tribes.transport.nio.PooledParallelSender.sendMessage(PooledParallelSender.java:54)
at
org.apache.catalina.tribes.transport.ReplicationTransmitter.sendMessage(ReplicationTransmitter.java:78)
at
org.apache.catalina.tribes.group.ChannelCoordinator.sendMessage(ChannelCoordinator.java:77)
at
org.apache.catalina.tribes.group.ChannelInterceptorBase.sendMessage(ChannelInterceptorBase.java:77)
at
org.apache.catalina.tribes.group.ChannelInterceptorBase.sendMessage(ChannelInterceptorBase.java:77)
at
org.apache.catalina.tribes.group.interceptors.MessageDispatchInterceptor.sendMessage(MessageDispatchInterceptor.java:77)
at
org.apache.catalina.tribes.group.ChannelInterceptorBase.sendMessage(ChannelInterceptorBase.java:77)
at
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.sendMessage(TcpFailureDetector.java:93)
at
org.apache.catalina.tribes.group.ChannelInterceptorBase.sendMessage(ChannelInterceptorBase.java:77)
at
org.apache.catalina.tribes.group.ChannelInterceptorBase.sendMessage(ChannelInterceptorBase.java:77)
at
org.apache.catalina.tribes.group.GroupChannel.send(GroupChannel.java:224)
at
org.apache.catalina.tribes.group.GroupChannel.send(GroupChannel.java:182)
at
org.apache.catalina.ha.tcp.SimpleTcpCluster.send(SimpleTcpCluster.java:837)
at
org.apache.catalina.ha.session.DeltaManager.sendSessions(DeltaManager.java:1429)
at
org.apache.catalina.ha.session.DeltaManager.handleGET_ALL_SESSIONS(DeltaManager.java:1357)
at
org.apache.catalina.ha.session.DeltaManager.messageReceived(DeltaManager.java:1183)
at
org.apache.catalina.ha.session.DeltaManager.messageDataReceived(DeltaManager.java:944)
at
org.apache.catalina.ha.session.ClusterSessionListener.messageReceived(ClusterSessionListener.java:91)
at
org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived(SimpleTcpCluster.java:936)
at
org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived(SimpleTcpCluster.java:917)
at
org.apache.catalina.tribes.group.GroupChannel.messageReceived(GroupChannel.java:278)
at
org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:82)
at
org.apache.catalina.tribes.group.interceptors.TcpPingInterceptor.messageReceived(TcpPingInterceptor.java:170)
at
org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:82)
at
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.messageReceived(TcpFailureDetector.java:117)
at
org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:82)
at
org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:82)
at
org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:82)
at
org.apache.catalina.tribes.group.ChannelCoordinator.messageReceived(ChannelCoordinator.java:252)
at
org.apache.catalina.tribes.transport.ReceiverBase.messageDataReceived(ReceiverBase.java:287)
at
Re: Session replication/fail-over for medium sized tomcat farm
On Fri, Jul 3, 2015 at 9:17 AM, Charles Richard charle...@thelearningbar.com wrote: On Fri, Jul 3, 2015 at 9:58 AM, Daniel Mikusa dmik...@pivotal.io wrote: On Fri, Jul 3, 2015 at 8:36 AM, Charles Richard charle...@thelearningbar.com wrote: Hi, We are currently using a product called Terracotta to do session fail-over/replication but are considering moving away from this product as it doesn't seem to support Java 7 and Tomcat 7. What products exist out there that would help with session fail-over/replication? I only know of 3: - Terracotta - Hazelcast - Tomcat native session failover (is not recommended for many tomcat nodes) I think that recommendation is just for the DeltaManager. You can use the BackupManager with larger numbers of nodes since it's not replicating session data to all of the nodes in the cluster. http://tomcat.apache.org/tomcat-7.0-doc/config/cluster-manager.html In addition to that Redis and Memcached are two popular ways of sharing session state. Dan In the link you sent, it mentions the following: Downside of the BackupManager: not quite as battle tested as the delta manager. Naturally this statement makes sense because DeltaManager is the default. More people are going to use it. BackupManager has been around for quite a while though. Looking at SVN, it's been almost 9 years. I'd say that gives it a certain amount of credibility. http://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/java/org/apache/catalina/ha/session/BackupManager.java?revision=433703view=markup Are you aware of companies using this for their Tomcat farms? I have worked with multiple customers using it in production. Not as common as DeltaManager, but it's being used. Dan Thanks, Charles I want to make sure i know all options before making a decision. Thanks, Charles
Session replication/fail-over for medium sized tomcat farm
Hi, We are currently using a product called Terracotta to do session fail-over/replication but are considering moving away from this product as it doesn't seem to support Java 7 and Tomcat 7. What products exist out there that would help with session fail-over/replication? I only know of 3: - Terracotta - Hazelcast - Tomcat native session failover (is not recommended for many tomcat nodes) I want to make sure i know all options before making a decision. Thanks, Charles
Re: Session replication/fail-over for medium sized tomcat farm
On Fri, Jul 3, 2015 at 9:58 AM, Daniel Mikusa dmik...@pivotal.io wrote: On Fri, Jul 3, 2015 at 8:36 AM, Charles Richard charle...@thelearningbar.com wrote: Hi, We are currently using a product called Terracotta to do session fail-over/replication but are considering moving away from this product as it doesn't seem to support Java 7 and Tomcat 7. What products exist out there that would help with session fail-over/replication? I only know of 3: - Terracotta - Hazelcast - Tomcat native session failover (is not recommended for many tomcat nodes) I think that recommendation is just for the DeltaManager. You can use the BackupManager with larger numbers of nodes since it's not replicating session data to all of the nodes in the cluster. http://tomcat.apache.org/tomcat-7.0-doc/config/cluster-manager.html In addition to that Redis and Memcached are two popular ways of sharing session state. Dan In the link you sent, it mentions the following: Downside of the BackupManager: not quite as battle tested as the delta manager. Are you aware of companies using this for their Tomcat farms? Thanks, Charles I want to make sure i know all options before making a decision. Thanks, Charles
Re: Session replication/fail-over for medium sized tomcat farm
On Fri, Jul 3, 2015 at 8:36 AM, Charles Richard charle...@thelearningbar.com wrote: Hi, We are currently using a product called Terracotta to do session fail-over/replication but are considering moving away from this product as it doesn't seem to support Java 7 and Tomcat 7. What products exist out there that would help with session fail-over/replication? I only know of 3: - Terracotta - Hazelcast - Tomcat native session failover (is not recommended for many tomcat nodes) I think that recommendation is just for the DeltaManager. You can use the BackupManager with larger numbers of nodes since it's not replicating session data to all of the nodes in the cluster. http://tomcat.apache.org/tomcat-7.0-doc/config/cluster-manager.html In addition to that Redis and Memcached are two popular ways of sharing session state. Dan I want to make sure i know all options before making a decision. Thanks, Charles
Re: Cluster - Session replication error: Unable to apply diff
On 22 Apr 2015, at 02:32, Keiichi Fujino kfuj...@apache.org wrote: Fixed at r1675020. -- Keiichi.Fujino Hello, Sorry for not having replied earlier. Thank you for your investigation and your bug correction. I will try to apply my test case to the trunk in the next few days, I’ll let you know if it does solve my problem. Thank you again, Théo signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Cluster - Session replication error: Unable to apply diff
Fixed at r1675020. 2015-04-20 16:18 GMT+09:00 Keiichi Fujino kfuj...@apache.org: This NPE has been caused by that apply the diff data to a ReplicatedMapEntry that has not set a MapOwner. Usually, ReplicatedMapEntry always has to have the MapOwner. I think this is probably a bug. Please open Bugzilla entry. I will scrutinize the code. 2015-04-20 15:04 GMT+09:00 Keiichi Fujino kfuj...@apache.org: Hi Are there other error or exception in your log? Please show us your cluster configuration in your server.xml. e.g. - What is mapSendOptions? - Which Interceptor do you use? 2015-04-15 3:55 GMT+09:00 Théo Chamley theo...@mley.fr: Hello, I have a working Tomcat 8.0.15 cluster with 3 members with the BackupManager as session manager. The session replication is mostly working except in a few cases. In those cases, I get the following error: 09-Apr-2015 12:16:58.369 SEVERE [Tribes-Task-Receiver-6] org.apache.catalina.tribes.tipis.AbstractReplicatedMap.messageReceived Unable to apply diff to key:3B286B4C7CA060163A00988969D21923 java.lang.NullPointerException at org.apache.catalina.ha.session.DeltaSession.applyDiff(DeltaSession.java:164) at org.apache.catalina.tribes.tipis.AbstractReplicatedMap.messageReceived(AbstractReplicatedMap.java:664) at org.apache.catalina.tribes.group.GroupChannel.messageReceived(GroupChannel.java:293) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:81) at org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.messageReceived(TcpFailureDetector.java:112) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:81) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:81) at org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor.messageReceived(ThroughputInterceptor.java:89) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:81) at org.apache.catalina.tribes.group.ChannelCoordinator.messageReceived(ChannelCoordinator.java:260) at org.apache.catalina.tribes.transport.ReceiverBase.messageDataReceived(ReceiverBase.java:240) at org.apache.catalina.tribes.transport.nio.NioReplicationTask.drainChannel(NioReplicationTask.java:206) at org.apache.catalina.tribes.transport.nio.NioReplicationTask.run(NioReplicationTask.java:97) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) I was able to replicate the problem with a scenario in the application, but I was not able to understand the underlying problem. This happens when the user is making a very specific request and this request arrives on a Tomcat where his session is not stored, forcing the Tomcat to fetch the session elsewhere. The 3 tomcats are on the same network with a very low network latency. Does anybody has some advice on how to debug this problem? For now, I got around it with sticky sessions on mod_jk, but I find this very unsatisfactory. Thank you in advance for your help, //Théo -- Keiichi.Fujino -- Keiichi.Fujino -- Keiichi.Fujino
Re: Cluster - Session replication error: Unable to apply diff
This NPE has been caused by that apply the diff data to a ReplicatedMapEntry that has not set a MapOwner. Usually, ReplicatedMapEntry always has to have the MapOwner. I think this is probably a bug. Please open Bugzilla entry. I will scrutinize the code. 2015-04-20 15:04 GMT+09:00 Keiichi Fujino kfuj...@apache.org: Hi Are there other error or exception in your log? Please show us your cluster configuration in your server.xml. e.g. - What is mapSendOptions? - Which Interceptor do you use? 2015-04-15 3:55 GMT+09:00 Théo Chamley theo...@mley.fr: Hello, I have a working Tomcat 8.0.15 cluster with 3 members with the BackupManager as session manager. The session replication is mostly working except in a few cases. In those cases, I get the following error: 09-Apr-2015 12:16:58.369 SEVERE [Tribes-Task-Receiver-6] org.apache.catalina.tribes.tipis.AbstractReplicatedMap.messageReceived Unable to apply diff to key:3B286B4C7CA060163A00988969D21923 java.lang.NullPointerException at org.apache.catalina.ha.session.DeltaSession.applyDiff(DeltaSession.java:164) at org.apache.catalina.tribes.tipis.AbstractReplicatedMap.messageReceived(AbstractReplicatedMap.java:664) at org.apache.catalina.tribes.group.GroupChannel.messageReceived(GroupChannel.java:293) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:81) at org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.messageReceived(TcpFailureDetector.java:112) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:81) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:81) at org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor.messageReceived(ThroughputInterceptor.java:89) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:81) at org.apache.catalina.tribes.group.ChannelCoordinator.messageReceived(ChannelCoordinator.java:260) at org.apache.catalina.tribes.transport.ReceiverBase.messageDataReceived(ReceiverBase.java:240) at org.apache.catalina.tribes.transport.nio.NioReplicationTask.drainChannel(NioReplicationTask.java:206) at org.apache.catalina.tribes.transport.nio.NioReplicationTask.run(NioReplicationTask.java:97) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) I was able to replicate the problem with a scenario in the application, but I was not able to understand the underlying problem. This happens when the user is making a very specific request and this request arrives on a Tomcat where his session is not stored, forcing the Tomcat to fetch the session elsewhere. The 3 tomcats are on the same network with a very low network latency. Does anybody has some advice on how to debug this problem? For now, I got around it with sticky sessions on mod_jk, but I find this very unsatisfactory. Thank you in advance for your help, //Théo -- Keiichi.Fujino -- Keiichi.Fujino
Re: Cluster - Session replication error: Unable to apply diff
Hi Are there other error or exception in your log? Please show us your cluster configuration in your server.xml. e.g. - What is mapSendOptions? - Which Interceptor do you use? 2015-04-15 3:55 GMT+09:00 Théo Chamley theo...@mley.fr: Hello, I have a working Tomcat 8.0.15 cluster with 3 members with the BackupManager as session manager. The session replication is mostly working except in a few cases. In those cases, I get the following error: 09-Apr-2015 12:16:58.369 SEVERE [Tribes-Task-Receiver-6] org.apache.catalina.tribes.tipis.AbstractReplicatedMap.messageReceived Unable to apply diff to key:3B286B4C7CA060163A00988969D21923 java.lang.NullPointerException at org.apache.catalina.ha.session.DeltaSession.applyDiff(DeltaSession.java:164) at org.apache.catalina.tribes.tipis.AbstractReplicatedMap.messageReceived(AbstractReplicatedMap.java:664) at org.apache.catalina.tribes.group.GroupChannel.messageReceived(GroupChannel.java:293) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:81) at org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.messageReceived(TcpFailureDetector.java:112) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:81) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:81) at org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor.messageReceived(ThroughputInterceptor.java:89) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:81) at org.apache.catalina.tribes.group.ChannelCoordinator.messageReceived(ChannelCoordinator.java:260) at org.apache.catalina.tribes.transport.ReceiverBase.messageDataReceived(ReceiverBase.java:240) at org.apache.catalina.tribes.transport.nio.NioReplicationTask.drainChannel(NioReplicationTask.java:206) at org.apache.catalina.tribes.transport.nio.NioReplicationTask.run(NioReplicationTask.java:97) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) I was able to replicate the problem with a scenario in the application, but I was not able to understand the underlying problem. This happens when the user is making a very specific request and this request arrives on a Tomcat where his session is not stored, forcing the Tomcat to fetch the session elsewhere. The 3 tomcats are on the same network with a very low network latency. Does anybody has some advice on how to debug this problem? For now, I got around it with sticky sessions on mod_jk, but I find this very unsatisfactory. Thank you in advance for your help, //Théo -- Keiichi.Fujino
Cluster - Session replication error: Unable to apply diff
Hello, I have a working Tomcat 8.0.15 cluster with 3 members with the BackupManager as session manager. The session replication is mostly working except in a few cases. In those cases, I get the following error: 09-Apr-2015 12:16:58.369 SEVERE [Tribes-Task-Receiver-6] org.apache.catalina.tribes.tipis.AbstractReplicatedMap.messageReceived Unable to apply diff to key:3B286B4C7CA060163A00988969D21923 java.lang.NullPointerException at org.apache.catalina.ha.session.DeltaSession.applyDiff(DeltaSession.java:164) at org.apache.catalina.tribes.tipis.AbstractReplicatedMap.messageReceived(AbstractReplicatedMap.java:664) at org.apache.catalina.tribes.group.GroupChannel.messageReceived(GroupChannel.java:293) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:81) at org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.messageReceived(TcpFailureDetector.java:112) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:81) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:81) at org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor.messageReceived(ThroughputInterceptor.java:89) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:81) at org.apache.catalina.tribes.group.ChannelCoordinator.messageReceived(ChannelCoordinator.java:260) at org.apache.catalina.tribes.transport.ReceiverBase.messageDataReceived(ReceiverBase.java:240) at org.apache.catalina.tribes.transport.nio.NioReplicationTask.drainChannel(NioReplicationTask.java:206) at org.apache.catalina.tribes.transport.nio.NioReplicationTask.run(NioReplicationTask.java:97) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) I was able to replicate the problem with a scenario in the application, but I was not able to understand the underlying problem. This happens when the user is making a very specific request and this request arrives on a Tomcat where his session is not stored, forcing the Tomcat to fetch the session elsewhere. The 3 tomcats are on the same network with a very low network latency. Does anybody has some advice on how to debug this problem? For now, I got around it with sticky sessions on mod_jk, but I find this very unsatisfactory. Thank you in advance for your help, //Théo signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Tomcat 8 - session replication DeltaManager not working
2015-02-06 19:09 GMT+03:00 Junek Leoš ju...@oksystem.cz:
Hello to all,
Would anyone know why session replication does not work for me? Load balancer
with session afinity works great, but after reconfiguration settings to
session replication my sessions are not persisted. I am running Oracle Linux
6.5 (almost same as RHEL 6.5) with Tomcat 8.0.18, Java 1.7.0_55. There are
three instances of Tomcat. All relevant config is listed below.
[...]
I am following video guide of Rama Krishnnan:
https://www.youtube.com/watch?v=cYBdaeNeXbY
What could be source or symptom of problems?
1) In catalina.out I could not see messages
INFO: Register manager /examples to cluster element Engine with name
server_name
org.apache.catalina.ha.session.DeltaManager start
INFO: Starting clustering manager at /examples
as blog post
http://blogs.agilefaqs.com/2009/11/09/setting-up-tomcat-cluster-for-session-replication/
mentions
Does it mean DeltaManager was not properly loaded?
2) Tomcat docs says All your session attributes must implement
java.io.Serializable and I am not sure about it. Below my index.jsp is
listed.
It an attribute is not a Serializable, it cannot be transmitted over the wire.
For starters, see javadoc of java.io.Serializable. There are also
tutorials and good books elsewhere.
All files
$CATALINA1_HOME/conf/web.xml
$CATALINA2_HOME/conf/web.xml
$CATALINA3_HOME/conf/web.xml
ends with
distributable/
/web-app
Your own application application in its WEB-INF/web.xml must be marked
as distributable.
I doubt that changing the above server-wide defaults helps you.
$CATALINA1_HOME/logs/catalina.out - startup
06-Feb-2015 16:49:43.449 WARNING [main]
org.apache.tomcat.util.digester.SetPropertiesRule.begin
[SetPropertiesRule]{Server/Service/Engine/Host/Context} Setting property
'docbase' to '' did not find a matching property.
Do not put Context elements into server.xml. That is a really bad practice.
See Context element in Configuration Reference Guide,
webapps/docs/config/context.html
Be careful with typos. XML files are case-sensitive. There is no such
attribute as docbase.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 8 - session replication DeltaManager not working
Hello to all, Would anyone know why session replication does not work for me? Load balancer with session afinity works great, but after reconfiguration settings to session replication my sessions are not persisted. I am running Oracle Linux 6.5 (almost same as RHEL 6.5) with Tomcat 8.0.18, Java 1.7.0_55. There are three instances of Tomcat. All relevant config is listed below. I am following video guide of Rama Krishnnan: https://www.youtube.com/watch?v=cYBdaeNeXbY What could be source or symptom of problems? 1) In catalina.out I could not see messages INFO: Register manager /examples to cluster element Engine with name server_name org.apache.catalina.ha.session.DeltaManager start INFO: Starting clustering manager at /examples as blog post http://blogs.agilefaqs.com/2009/11/09/setting-up-tomcat-cluster-for-session-replication/ mentions Does it mean DeltaManager was not properly loaded? 2) Tomcat docs says All your session attributes must implement java.io.Serializable and I am not sure about it. Below my index.jsp is listed. Thanks in advance for your help Leoš Here are relevant parts of settings: /etc/httpd/conf/httpd.conf LoadModulejk_module modules/mod_jk.so JkWorkersFile conf/workers.properties JkLogFile logs/mod_jk.log JkLogLevelemerg JkLogStampFormat [%a %b %d %H:%M:%S %Y] JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories JkRequestLogFormat %w %V %T JkMount /status stat JkMount /* balancer #JkMount /instance1* instance1 #JkMount /instance2* instance2 #JkMount /instance3* instance3 Cluster conf copied from http://tomcat.apache.org/tomcat-8.0-doc/cluster-howto.html , Deployer config was dropped. $CATALINA1_HOME/conf/server.xml -- Connector port=8117 protocol=AJP/1.3 redirectPort=8447 / Engine name=Catalina defaultHost=localhost jvmRoute=instance1 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/ /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 Realm className=org.apache.catalina.realm.LockOutRealm Realm className=org.apache.catalina.realm.UserDatabaseRealm resourceName=UserDatabase/ /Realm Host name=localhost appBase=webapps unpackWARs=true autoDeploy=true Context path= docbase=/ Valve className=org.apache.catalina.valves.AccessLogValve directory=logs prefix=localhost_access_log suffix=.txt pattern=%h %l %u %t quot;%rquot; %s %b / /Host /Engine === /opt/tom1/conf/server.xml END == $CATALINA2_HOME/conf/server.xml -- Connector port=8118 protocol=AJP/1.3 redirectPort=8448 / Engine name=Catalina defaultHost=localhost jvmRoute=instance2 --- (as above) --- Receiver className=org.apache.catalina.tribes.transport.nio.NioReceiver address=auto port=4002 --- (as above) --- $CATALINA3_HOME/conf/server.xml -- Connector port=8119 protocol=AJP/1.3 redirectPort=8449 / Engine name=Catalina defaultHost=localhost jvmRoute=instance3 --- (as above) --- Receiver className=org.apache.catalina.tribes.transport.nio.NioReceiver address=auto port=4003 --- (as above) --- All files $CATALINA1_HOME/conf/web.xml $CATALINA2_HOME/conf/web.xml $CATALINA3_HOME/conf/web.xml ends with distributable/ /web-app My application $CATALINA_HOME/webapps/ROOT/index.jsp is %@page import=java.util.ArrayList% %@page
Re: Session Replication across common base domain
Hi Guys, Any solution for this?? On 03-01-2014 02:31 PM, Sanket Paranjape wrote: Hi, I am using Tomcat 7.0.47 on windows 7 with JDK 1.7. I want to achieve session replications on multiple subdomains. If I have a domain as xyz.example.com and abc.example.com, then I would like to store session cookie on example.com and hence then I would be able to access same session on both domains. By default session cookie is set on whole domain, if I access xyz.example.com then session cookie will be set on this domain. I went through the documentation for Tomcat 7 and found that in Context element type I can add attribute like sessionCookieDomain. I can easily set this attribute to base domain like .example.com and this works like charm. But my requirement is slightly different. I have single tomcat serving multiple domains. They all different base domains as well. So hardcoding would not help me out here. So I tried following. In docs I found this link, http://tomcat.apache.org/tomcat-7.0-doc/config/context.html. It says that className attribute can be set for context. So I wrote my own class MyStandardContext which extends org.apache.catalina.core.StandardContext. I overridden public String getSessionCookieDomain() method. I want to return base domain of the URL from this domain so that tomcat will set cookie on this domain. But to my surprise I do not have access to Request URI. If I could get access to this URI somehow then I would be able to extract base domain. It is not possible. is it? I also tried adding multiple hosts in conf/server.xml under Engine. This loads context multiple times, which I do not wish. My question is there any way I can get access to request URI in MyStandardContext? Or is there any configuration which forces tomcat to set cookie on base domain instead full domain? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Session Replication across common base domain
Hi, I am using Tomcat 7.0.47 on windows 7 with JDK 1.7. I want to achieve session replications on multiple subdomains. If I have a domain as xyz.example.com and abc.example.com, then I would like to store session cookie on example.com and hence then I would be able to access same session on both domains. By default session cookie is set on whole domain, if I access xyz.example.com then session cookie will be set on this domain. I went through the documentation for Tomcat 7 and found that in Context element type I can add attribute like sessionCookieDomain. I can easily set this attribute to base domain like .example.com and this works like charm. But my requirement is slightly different. I have single tomcat serving multiple domains. They all different base domains as well. So hardcoding would not help me out here. So I tried following. In docs I found this link, http://tomcat.apache.org/tomcat-7.0-doc/config/context.html. It says that className attribute can be set for context. So I wrote my own class MyStandardContext which extends org.apache.catalina.core.StandardContext. I overridden public String getSessionCookieDomain() method. I want to return base domain of the URL from this domain so that tomcat will set cookie on this domain. But to my surprise I do not have access to Request URI. If I could get access to this URI somehow then I would be able to extract base domain. It is not possible. is it? I also tried adding multiple hosts in conf/server.xml under Engine. This loads context multiple times, which I do not wish. My question is there any way I can get access to request URI in MyStandardContext? Or is there any configuration which forces tomcat to set cookie on base domain instead full domain? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Session replication configuration file question
Hi Daniel, At last we managed to solve the replication issue. (not exactly a solution but a workaround) : the problem was: The multicast tried to broadcast to local ip written in the hosts file 127.0.1.1 We had to write the actual ip adress in the hosts file instead : 127.0.1.1 - Tomcat1 we changed to tomcat1_ip_adress - Tomcat1 and the same on the tomcat 2 machine. now it works. thanks for your efforts. On Sun, Dec 29, 2013 at 8:43 PM, Daniel Mikusa dmik...@gopivotal.comwrote: On Dec 29, 2013, at 10:51 AM, Nir A n...@netomedia.com wrote: Hi, If i want to create a cluster of 2 tomcats: Tomcat1 - ip 111.111.111.111 Tomcat2 - ip 222.222.222.222 Where exactly the in the server.xml i should say that my cluster contains both of these ips? By default, you don't. If you'd rather do that, you can though. See my previous email to you regarding StaticMember configuration. If you will take alook at my server.xml (which i copy pasted from the tutorial) it looks like this: ?xml version='1.0' encoding='utf-8'? Server port=8105 shutdown=SHUTDOWN Listener className=org.apache.catalina.core.AprLifecycleListener SSLEngine=on / Listener className=org.apache.catalina.core.JasperListener / Listener className=org.apache.catalina.core.JreMemoryLeakPreventionListener / Listener className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener / Listener className=org.apache.catalina.core.ThreadLocalLeakPreventionListener / GlobalNamingResources Resource name=UserDatabase auth=Container type=org.apache.catalina.UserDatabase description=User database that can be updated and saved factory=org.apache.catalina.users.MemoryUserDatabaseFactory pathname=conf/tomcat-users.xml / /GlobalNamingResources Service name=Catalina Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / Connector port=8109 protocol=AJP/1.3 redirectPort=8443 / Engine name=Catalina defaultHost=localhost Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster Manager className=org.apache.catalina.ha.session.BackupManager expireSessionsOnShutdown=false notifyListenersOnReplication=true mapSendOptions=6/ /Cluster Realm className=org.apache.catalina.realm.LockOutRealm Realm className=org.apache.catalina.realm.UserDatabaseRealm resourceName=UserDatabase/ /Realm Host name=localhost appBase=webapps unpackWARs=true autoDeploy=true Valve className=org.apache.catalina.valves.AccessLogValve directory=logs prefix=localhost_access_log. suffix=.txt pattern=%h %l %u %t quot;%rquot; %s %b / /Host /Engine /Service /Server Again, It doesn't make sense to me that this configuration will work since the ips (111.111.111.111 , and 222.222.222.222) are not in it. The Cluster tag adds some default options for you. See this link for more on the defaults. http://tomcat.apache.org/tomcat-7.0-doc/cluster-howto.html#For_the_impatient Specifically look at the Membership / tag which defines the multicast service. This is how instances find each other by default. Where exactly should i define them? Again, see my other note regarding StaticMember configuration. Dan Thanks - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Session replication does not work - Continued
Hi, So we have 3 tomcats in our cluster and we are failing to make them replicate our sessions still. Our IT guy said it might has something to do with the machines of the tomcats. He said that since the machines the tomcats in the cluster are installed at are Virtual machines there might be a problem on the multicast of the replication messages. 1) Is it possible that our IT guy is right? (We love you Leon) 2) Is there any alternative to multicast the session data between the tomcats? Thanks!
Session replication configuration file question
Hi, If i want to create a cluster of 2 tomcats: Tomcat1 - ip 111.111.111.111 Tomcat2 - ip 222.222.222.222 Where exactly the in the server.xml i should say that my cluster contains both of these ips? If you will take alook at my server.xml (which i copy pasted from the tutorial) it looks like this: ?xml version='1.0' encoding='utf-8'? Server port=8105 shutdown=SHUTDOWN Listener className=org.apache.catalina.core.AprLifecycleListener SSLEngine=on / Listener className=org.apache.catalina.core.JasperListener / Listener className=org.apache.catalina.core.JreMemoryLeakPreventionListener / Listener className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener / Listener className=org.apache.catalina.core.ThreadLocalLeakPreventionListener / GlobalNamingResources Resource name=UserDatabase auth=Container type=org.apache.catalina.UserDatabase description=User database that can be updated and saved factory=org.apache.catalina.users.MemoryUserDatabaseFactory pathname=conf/tomcat-users.xml / /GlobalNamingResources Service name=Catalina Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / Connector port=8109 protocol=AJP/1.3 redirectPort=8443 / Engine name=Catalina defaultHost=localhost Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster Manager className=org.apache.catalina.ha.session.BackupManager expireSessionsOnShutdown=false notifyListenersOnReplication=true mapSendOptions=6/ /Cluster Realm className=org.apache.catalina.realm.LockOutRealm Realm className=org.apache.catalina.realm.UserDatabaseRealm resourceName=UserDatabase/ /Realm Host name=localhost appBase=webapps unpackWARs=true autoDeploy=true Valve className=org.apache.catalina.valves.AccessLogValve directory=logs prefix=localhost_access_log. suffix=.txt pattern=%h %l %u %t quot;%rquot; %s %b / /Host /Engine /Service /Server Again, It doesn't make sense to me that this configuration will work since the ips (111.111.111.111 , and 222.222.222.222) are not in it. Where exactly should i define them? Thanks
Re: Session replication does not work - Continued
On Dec 29, 2013, at 10:11 AM, Nir A n...@netomedia.com wrote: Hi, So we have 3 tomcats in our cluster and we are failing to make them replicate our sessions still. Our IT guy said it might has something to do with the machines of the tomcats. He said that since the machines the tomcats in the cluster are installed at are Virtual machines there might be a problem on the multicast of the replication messages. 1) Is it possible that our IT guy is right? (We love you Leon) By default, clustering support uses multicast to locate other Tomcat instances. If multicast does not work or is disabled on your instances won't be able to locate each other. Multicast is only used for locating other nodes, it is not used for the transmission of session data. TCP is used for that. 2) Is there any alternative to multicast the session data between the tomcats? Yes. See static members configuration. http://tomcat.apache.org/tomcat-7.0-doc/config/cluster-interceptor.html#Static_Membership http://tomcat.apache.org/tomcat-7.0-doc/config/cluster-interceptor.html#Nested_element_StaticMember_Attributes Dan Thanks! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Session replication configuration file question
On Dec 29, 2013, at 10:51 AM, Nir A n...@netomedia.com wrote: Hi, If i want to create a cluster of 2 tomcats: Tomcat1 - ip 111.111.111.111 Tomcat2 - ip 222.222.222.222 Where exactly the in the server.xml i should say that my cluster contains both of these ips? By default, you don't. If you'd rather do that, you can though. See my previous email to you regarding StaticMember configuration. If you will take alook at my server.xml (which i copy pasted from the tutorial) it looks like this: ?xml version='1.0' encoding='utf-8'? Server port=8105 shutdown=SHUTDOWN Listener className=org.apache.catalina.core.AprLifecycleListener SSLEngine=on / Listener className=org.apache.catalina.core.JasperListener / Listener className=org.apache.catalina.core.JreMemoryLeakPreventionListener / Listener className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener / Listener className=org.apache.catalina.core.ThreadLocalLeakPreventionListener / GlobalNamingResources Resource name=UserDatabase auth=Container type=org.apache.catalina.UserDatabase description=User database that can be updated and saved factory=org.apache.catalina.users.MemoryUserDatabaseFactory pathname=conf/tomcat-users.xml / /GlobalNamingResources Service name=Catalina Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / Connector port=8109 protocol=AJP/1.3 redirectPort=8443 / Engine name=Catalina defaultHost=localhost Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster Manager className=org.apache.catalina.ha.session.BackupManager expireSessionsOnShutdown=false notifyListenersOnReplication=true mapSendOptions=6/ /Cluster Realm className=org.apache.catalina.realm.LockOutRealm Realm className=org.apache.catalina.realm.UserDatabaseRealm resourceName=UserDatabase/ /Realm Host name=localhost appBase=webapps unpackWARs=true autoDeploy=true Valve className=org.apache.catalina.valves.AccessLogValve directory=logs prefix=localhost_access_log. suffix=.txt pattern=%h %l %u %t quot;%rquot; %s %b / /Host /Engine /Service /Server Again, It doesn't make sense to me that this configuration will work since the ips (111.111.111.111 , and 222.222.222.222) are not in it. The Cluster tag adds some default options for you. See this link for more on the defaults. http://tomcat.apache.org/tomcat-7.0-doc/cluster-howto.html#For_the_impatient Specifically look at the Membership / tag which defines the multicast service. This is how instances find each other by default. Where exactly should i define them? Again, see my other note regarding StaticMember configuration. Dan Thanks - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
session replication issue
setting of session replication worked well. However, we do have threading
in some products. Like we are hitting the target API and getting response
from there servers. If will not get the response will hit them after some
time and in this case threading not handled by session replication because
of session timeout and shows below errors. After some time the server
starts getting
high load.
SEVERE: Unable to replicate backup key:
AE8095AB32A4DCA0AFD7117F6F32210C.t7 to
backup:org.apache.catalina.tribes.membership.MemberImpl[tcp://{-64, -88, 3,
12}:4001,{-64, -88, 3, 12},4001, alive=30639540,id={77 33 -17 95 -79 -80 79
2 -104 -102 -73 29 -100 39 -59 -111 }, payload={}, command={}, domain={},
]. Reason:Operation has timed out(6 ms.).; Faulty members:tcp://{-64,
-88, 3, 12}:4001;
org.apache.catalina.tribes.ChannelException: Operation has timed out(6
ms.).; Faulty members:tcp://{-64, -88, 3, 12}:4001;
How can i address above issue or just by increasing time out value. Please
explain me.
server.xml for session replicaiton.
Manager className=org.apache.catalina.ha.session.BackupManager
expireSessionsOnShutdown=false
notifyListenersOnReplication=true mapSendOptions=6/
Channel
className=org.apache.catalina.tribes.group.GroupChannel
Membership
className=org.apache.catalina.tribes.membership.McastService
address=228.0.0.4
port=45565
frequency=500
dropTime=3/
Receiver
className=org.apache.catalina.tribes.transport.nio.NioReceiver
address=auto
port=5000
selectorTimeout=5000
timeout=6
maxThreads=6/
Sender
className=org.apache.catalina.tribes.transport.ReplicationTransmitter
Transport
className=org.apache.catalina.tribes.transport.nio.PooledParallelSender
timeout=6 keepAliveCount=0/
/Sender
Interceptor
className=org.apache.catalina.tribes.group.interceptors.TcpFailureDetector/
Interceptor
className=org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor/
Interceptor
className=org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor/
/Channel
Valve className=org.apache.catalina.ha.tcp.ReplicationValve
filter=.*\.gif|.*\.js|.*\.jpeg|.*\.jpg|.*\.png|.*\.htm|.*\.html|.*\.css|.*\.txt/
Valve
className=org.apache.catalina.ha.session.JvmRouteBinderValve/
ClusterListener
className=org.apache.catalina.ha.session.ClusterSessionListener/
ClusterListener
className=org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener/
Re: session replication issue
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dhaval,
On 12/9/13, 3:04 PM, Dhaval Jaiswal wrote:
setting of session replication worked well. However, we do have
threading in some products. Like we are hitting the target API and
getting response from there servers. If will not get the response
will hit them after some time and in this case threading not
handled by session replication because of session timeout and shows
below errors.
Can you explain this with a little more detail?
After some time the server starts getting high load.
The high-load is caused by greater client load, or because of the
replication re-tried, etc.?
- -chris
SEVERE: Unable to replicate backup key:
AE8095AB32A4DCA0AFD7117F6F32210C.t7 to
backup:org.apache.catalina.tribes.membership.MemberImpl[tcp://{-64,
-88, 3, 12}:4001,{-64, -88, 3, 12},4001, alive=30639540,id={77 33
-17 95 -79 -80 79 2 -104 -102 -73 29 -100 39 -59 -111 },
payload={}, command={}, domain={}, ]. Reason:Operation has timed
out(6 ms.).; Faulty members:tcp://{-64, -88, 3, 12}:4001;
org.apache.catalina.tribes.ChannelException: Operation has timed
out(6 ms.).; Faulty members:tcp://{-64, -88, 3, 12}:4001;
How can i address above issue or just by increasing time out value.
Please explain me.
server.xml for session replicaiton.
Manager className=org.apache.catalina.ha.session.BackupManager
expireSessionsOnShutdown=false
notifyListenersOnReplication=true mapSendOptions=6/ Channel
className=org.apache.catalina.tribes.group.GroupChannel
Membership
className=org.apache.catalina.tribes.membership.McastService
address=228.0.0.4 port=45565 frequency=500
dropTime=3/ Receiver
className=org.apache.catalina.tribes.transport.nio.NioReceiver
address=auto port=5000 selectorTimeout=5000 timeout=6
maxThreads=6/ Sender
className=org.apache.catalina.tribes.transport.ReplicationTransmitter
Transport
className=org.apache.catalina.tribes.transport.nio.PooledParallelSender
timeout=6 keepAliveCount=0/
/Sender Interceptor
className=org.apache.catalina.tribes.group.interceptors.TcpFailureDetector/
Interceptor
className=org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor/
Interceptor
className=org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor/
/Channel Valve
className=org.apache.catalina.ha.tcp.ReplicationValve
filter=.*\.gif|.*\.js|.*\.jpeg|.*\.jpg|.*\.png|.*\.htm|.*\.html|.*\.css|.*\.txt/
Valve
className=org.apache.catalina.ha.session.JvmRouteBinderValve/
ClusterListener
className=org.apache.catalina.ha.session.ClusterSessionListener/
ClusterListener
className=org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSpjxUAAoJEBzwKT+lPKRYVGUQAKHEP5oRUq8SDKYzOSGMjdAd
cOt/L3Y5PbhB+m6RTmXYlhBvBFGUsIy1xfRhSbiUOVSaHAxVcWI96T0larG3YjYW
KkRVjzHKg96xe5FRQzRnJxp3tYqS8F+5LSnOvE9RpbOslC162qNy08cRp/nS5aQA
2JzlnZ6wuhRq80tjEb3chHWh5yPyHulcN4z8htNS/lwsIe3gyiPCErQUI6Grg1cO
d6NZEEsjYFksNkzbtteyGZbjzfztIvsIdWsK25AUA91Hqh3J7GRYbEm0ha48KVgV
f/aKVLOb1viZeZVCcGB79DhlOsOXJVwu854Qw6oaxi9VsSEb10W5SDpzqZKvRP11
To+7oI5xwdnJ+T5sw46Y0qTMqLI63ZzaeyaZlDqoc/K/RaBciqKomWXDVMpm2Vbm
9LC+QVDl5GY92sc2guEHmkGWqXL/csPSkAW2+Q9D0umcFgD/BRTDIiO4gvMXz7BD
qRFlnQuEU+zi03etHSw4eNL5BPE+3tX+MrnEideoxR4FeXfKP6FTm3yf7Zj9Pna3
Qod8QIhYacyJhxdwMSwx5qLvttfKuswV3DPx4GXxyWQzx94G+yCM6GGW5GyRHtzm
82wVT6bsTBhQ7fA73h8FofIUCpPmtl/ntN1RWjm3StcuNdGDZWOrdylqG2hHFwrk
L7T83sVpEg16Y5ypEslH
=RKD5
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Websockets with tomcat clustering and session replication
The problem is i guess, that you access the http session outside of a normal http request cycle So tomcat doesn't notice anything And also is it not a spec or behavior requirement that you don't hold on to your http session objects outside of requests? On 1 December 2013 15:33, Nir A n...@netomedia.com wrote: Hi, Ive asked here before about how do i get a session replication over websockets sessions. Mark Thomas answered me that i should try and link the httpsession with the websocket and then i will gain the replication abilities. So, I listended and implemented it just like in this url: http://stackoverflow.com/questions/17936440/accessing-httpsession-from-httpservletrequest-in-a-web-socket-socketendpoint So now, I'm able to get the session for each client. and I Do get replication! pretty nice! Only problem is, While i'm adding new attributes to the primary session (in tomcat#1 for example) , the replicated sessions (in tomcat#2 for example) does NOT contain any attribues. The session backup is there but no attributes at all. My POC web application has one html page with javascript web socket send\recieve messages. What i did notice that might shade light on whats the problem is the following scenario: If i press f5 on the browser, the web page is loaded and a new http handshake is taking place. when that happens all the attributes do replicate!!! Is there a way to make the attribute replicate without the need of refreshing the page? Thanks! -- Johan Compagner Servoy
Re: Websockets with tomcat clustering and session replication
Can you come up with an alternative ? Or can you think of a way to fool tomcat in thinking its in a regular cycle? On Dec 2, 2013 3:16 PM, Johan Compagner jcompag...@servoy.com wrote: The problem is i guess, that you access the http session outside of a normal http request cycle So tomcat doesn't notice anything And also is it not a spec or behavior requirement that you don't hold on to your http session objects outside of requests? On 1 December 2013 15:33, Nir A n...@netomedia.com wrote: Hi, Ive asked here before about how do i get a session replication over websockets sessions. Mark Thomas answered me that i should try and link the httpsession with the websocket and then i will gain the replication abilities. So, I listended and implemented it just like in this url: http://stackoverflow.com/questions/17936440/accessing-httpsession-from-httpservletrequest-in-a-web-socket-socketendpoint So now, I'm able to get the session for each client. and I Do get replication! pretty nice! Only problem is, While i'm adding new attributes to the primary session (in tomcat#1 for example) , the replicated sessions (in tomcat#2 for example) does NOT contain any attribues. The session backup is there but no attributes at all. My POC web application has one html page with javascript web socket send\recieve messages. What i did notice that might shade light on whats the problem is the following scenario: If i press f5 on the browser, the web page is loaded and a new http handshake is taking place. when that happens all the attributes do replicate!!! Is there a way to make the attribute replicate without the need of refreshing the page? Thanks! -- Johan Compagner Servoy
Re: Websockets with tomcat clustering and session replication
On Sun, Dec 1, 2013 at 4:33 PM, Nir A n...@netomedia.com wrote: My POC web application has one html page with javascript web socket send\recieve messages. What i did notice that might shade light on whats the problem is the following scenario: If i press f5 on the browser, the web page is loaded and a new http handshake is taking place. when that happens all the attributes do replicate!!! Is there a way to make the attribute replicate without the need of refreshing the page? In HTTP you have many requests associated with a session id. With session replication, each new request could go to a different server and still access the same HTTP session attributes. In WebSocket on the other hand there is a single connection the server and if you lose it, you have to reconnect, which is probably what pressing F5 does for you. Unless I'm missing something, you have to detect when the WebSocket connection is closed on client side and reconnect. Rossen
Re: Websockets with tomcat clustering and session replication
Yeah but, I would like to link the websocket session with the http session of the handshake. and that way i will be able to imitiate the session replication abilities for websocket. This mechanism works as intended only problem is the replication not replicate http session attribute while the websocket connection is happening (since this is not a regular httpsession \ request cycle) my question is - can i activate manually some kind of action on the http session to make it Refresh so the tomcat will replicate it every time i set new attribute? (I remind you again that pressing f5 will reconnect the websocket and the attributes are being copied). Thanks. On Dec 2, 2013 8:51 PM, Rossen Stoyanchev rstoyanc...@gopivotal.com wrote: On Sun, Dec 1, 2013 at 4:33 PM, Nir A n...@netomedia.com wrote: My POC web application has one html page with javascript web socket send\recieve messages. What i did notice that might shade light on whats the problem is the following scenario: If i press f5 on the browser, the web page is loaded and a new http handshake is taking place. when that happens all the attributes do replicate!!! Is there a way to make the attribute replicate without the need of refreshing the page? In HTTP you have many requests associated with a session id. With session replication, each new request could go to a different server and still access the same HTTP session attributes. In WebSocket on the other hand there is a single connection the server and if you lose it, you have to reconnect, which is probably what pressing F5 does for you. Unless I'm missing something, you have to detect when the WebSocket connection is closed on client side and reconnect. Rossen
Tomcat session replication via backmanager - attributes are not being saved on backup session
Hi, I'm using tomcat clustering of 2 tomcats, and session replication via backup manager. on session creation in one tomcat instance, the other tomcat replicates the session successfully but the attribute list is empty no matter how much i add to it. (the primary session attribute list is fine) any ideas why that happens?
Websockets with tomcat clustering and session replication
Hi, Ive asked here before about how do i get a session replication over websockets sessions. Mark Thomas answered me that i should try and link the httpsession with the websocket and then i will gain the replication abilities. So, I listended and implemented it just like in this url: http://stackoverflow.com/questions/17936440/accessing-httpsession-from-httpservletrequest-in-a-web-socket-socketendpoint So now, I'm able to get the session for each client. and I Do get replication! pretty nice! Only problem is, While i'm adding new attributes to the primary session (in tomcat#1 for example) , the replicated sessions (in tomcat#2 for example) does NOT contain any attribues. The session backup is there but no attributes at all. My POC web application has one html page with javascript web socket send\recieve messages. What i did notice that might shade light on whats the problem is the following scenario: If i press f5 on the browser, the web page is loaded and a new http handshake is taking place. when that happens all the attributes do replicate!!! Is there a way to make the attribute replicate without the need of refreshing the page? Thanks!
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: users-unsubscr
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
