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&qu
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&data=05%7C02%7
CRNoel%40westwoodone.com%7C1b723f1052ef4e59bf0808dc4a959af2%7Ce5d6709f
becf4b058cee37f5a62617c4%7C0%7C0%7C638467253633727340%7CUnknown%7CTWFp
bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
0%3D%7C0%7C%7C%7C&sdata=o5SvJv%2FM4QtRYM%2BEk18%2For7R81deb1g%2BW7N7XS
rMwuM%3D&reserved=0
Search for sessionAttributeNameFilter
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.
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:
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
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 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. Okay. Above setup doesn't work and give strange errors for the distributed >>> webapp which relies on http sessions. >>>
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.tribes.membership.cloud .DNSMembershipProvider"/> > So pretty much default-everything (except maybe the CloudMembership). > In the logs I can see the member appears/disappears messages, which > is a good thing I guess. It is! Unless you can think of a particular reason NOT to enable sticky-sessions, I'd go ahead and do it. Remember that your reverse-proxy needs to understand how to handle session stickiness, though. What are you using for load-balancing/reve
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
Re: Tomcat session replication with static membership
To answer my own questions:
On 04/09/2013 14:18, Willem Fibbe wrote:
> ...
> Now I was wondering 2 things:
> - if a Tomcat node restarts, will it be possible that it is trying to receive
> sessions from itself, rather than one or more of the other nodes? Or: should
> I configure a different server.xml on each node (its own member left out)?
I have setup a small cluster-group for testing (just quick testing) and have
seen a Tomcat node starting up,
replicating sessions from its own. Therefore, all our nodes now have a
different server.xml where its own node is
removed.
> - if I start Tomcat, I see in catalina.out:
> "WARNING:
> [SetPropertiesRule]{Server/Service/Engine/Cluster/Channel/Interceptor/Member}
> Setting property 'uniqueId' to '{10,0,10,227}' did not find a matching
> property."
> -> I removed uniqueId-attribute, but will this cause any possible
> problems?
So far, we have't seen any problems, although in catalina.out I see each server
with the same id:
INFO: Replication member
added:org.apache.catalina.tribes.membership.MemberImpl[tcp://hostname01.domain.nl:5678,hostname01.domain.nl,5678,
alive=0,id={0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 }, payload={}, command={},
domain={112 117 98 108 105 115 104 45 99 ...(15)}, ]
INFO: Replication member
added:org.apache.catalina.tribes.membership.MemberImpl[tcp://hostname02.domain.nl:5678,hostname02.domain.nl,5678,
alive=0,id={0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 }, payload={}, command={},
domain={112 117 98 108 105 115 104 45 99 ...(15)}, ]
Sessions seem te be replicating just fine though.
Willem
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat session replication and domain change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Leon, On 11/16/11 5:32 PM, Leon Rosenberg wrote: > Hello Chris, > > thank you for the answer, more inline. > >>> User logins on http://www.site.fr, a new session is created. >>> User uses the site, attributes are written and read... User >>> clicks a special link and is redirected to >>> https://secure.site.com - secure.site.com (same webapp, >>> different servers) loads the session previously initialized on >>> www.site.fr and associates it locally. >> >> How does this work? Or, were you asking if Tomcat can make this >> work (easily) for you? > > Yes. I know/can think about other solutions where the session id > of the original session is transmitted via additional parameter and > is used for session copy, like: server A issues session AAA. link > to server B contains sessionIdParameter=AAA a vavle or something on > server B notices that there is no local session for user on server > B yet and copies the AAA session. > > The question was, does tomcat support this already, or would I have > to code something myself. URL rewriting is not an option for > several reasons. You'll have to roll your own, here. If you don't mind passing-around a meta-session-id, you could use something like memcached as a unified session that everyone can see. >> Unfortunately, you may have a shitstorm of session chatter. >> Presumably, you'll have a number of domain-specific servers and >> a single secure one (or clustering all around, which actually >> makes the chatter problem worse). That means that if you have 100 >> sessions on each of 10 CCTLD servers then you'll have 1 >> sessions on the secure server. If that's okay, then go for it. > > Either you miscalculated it or I don't get the relation, 10x100 = > 1000, not 10.000 ;-) Too much coffee makes my fingers twitchy. 100 sessions per server is nothin', too. > But the point is valid, after the user leaves secure.site.com he > will probably never come back and there is no need to keep his > session (noone pays twice ;-)). You obviously need to change your business model. :) > But I assume tomcat session replication support doesn't support > session purge, neither session pull instead of permanent > synchronization. I don't think you can tell another node to purge a session without purging it from the entire cluster. Someone with more cluster experience than I can probably comment on that, but it's a safe bet :) With something like memcached, the "session" exists in the service and not in the server so it's not like you're wasting memory waiting for the session to die on the payment server. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7FccEACgkQ9CaO5/Lv0PCkFQCfdq3nr85ZoMWryYzoGt2FuTuS 6UYAn27fnaH6+jQ79N1DD3auGwnWzcNr =iZQ4 -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 and domain change
Hello Chris, thank you for the answer, more inline. >> User logins on http://www.site.fr, a new session is created. User >> uses the site, attributes are written and read... User clicks a >> special link and is redirected to https://secure.site.com - >> secure.site.com (same webapp, different servers) loads the session >> previously initialized on www.site.fr and associates it locally. > > How does this work? Or, were you asking if Tomcat can make this work > (easily) for you? Yes. I know/can think about other solutions where the session id of the original session is transmitted via additional parameter and is used for session copy, like: server A issues session AAA. link to server B contains sessionIdParameter=AAA a vavle or something on server B notices that there is no local session for user on server B yet and copies the AAA session. The question was, does tomcat support this already, or would I have to code something myself. URL rewriting is not an option for several reasons. ... > Unfortunately, you may have a shitstorm of session chatter. > Presumably, you'll have a number of domain-specific servers and a > single secure one (or clustering all around, which actually makes the > chatter problem worse). That means that if you have 100 sessions on > each of 10 CCTLD servers then you'll have 1 sessions on the secure > server. If that's okay, then go for it. Either you miscalculated it or I don't get the relation, 10x100 = 1000, not 10.000 ;-) But the point is valid, after the user leaves secure.site.com he will probably never come back and there is no need to keep his session (noone pays twice ;-)). But I assume tomcat session replication support doesn't support session purge, neither session pull instead of permanent synchronization. regards Leon - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat session replication and domain change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Leon, On 11/16/11 5:06 PM, Leon Rosenberg wrote: > User logins on http://www.site.fr, a new session is created. User > uses the site, attributes are written and read... User clicks a > special link and is redirected to https://secure.site.com - > secure.site.com (same webapp, different servers) loads the session > previously initialized on www.site.fr and associates it locally. How does this work? Or, were you asking if Tomcat can make this work (easily) for you? > User uses secure.site.com, modifies attributes etc. After user is > finished he jumps (on click or by simply entering the url) back to > www.site.fr, the local session contains all the changes from > secure.site.com. If you are using cookies to track your session, then this will not work because the browser isn't going to send the session id when the domain changes. If you could always be on *.site.fr (like from www.site.fr to secure.site.fr) then it would work if you set your cookie domain to site.fr. But that is a per-context setting which means you'd need a separate context for each domain you wanted to support. Yuck. If you use URL rewriting for session tracking, then this might work: cluster all the sites together and make sure that the jsessionid parameter is added to any URL you create that crosses the domain border. All copies of the webapp should replicate session info amongst themselves in both directions (www <-> secure). Unfortunately, you may have a shitstorm of session chatter. Presumably, you'll have a number of domain-specific servers and a single secure one (or clustering all around, which actually makes the chatter problem worse). That means that if you have 100 sessions on each of 10 CCTLD servers then you'll have 1 sessions on the secure server. If that's okay, then go for it. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7ENssACgkQ9CaO5/Lv0PD6NACgsrmhV5v1yn1JKNz3Ap7tfQne 3kYAniU8iETd7qvDEjqdo38/MTEgGna3 =dvKy -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 problem
I forgot to state that I am running tomcat 5.5 -- View this message in context: http://www.nabble.com/Tomcat-Session-Replication-problem-tp16185824p16185828.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat session replication problem
Hi! O Mar, 11-03-2008 ás 22:32 -0600, Filip Hanik - Dev Lists escribiu: > for it to work you would need to have channelSendOptions="6", No, it doesn't work too. I've already tried with it... With synchronous session replication server response is a bit slower (but too much...) but I have the same problem... > however, > not using sticky sessions is a bad strategy, I know, but then, what is the reason for supporting them at all? Cheers, Vreixo > no matter how you look at it. > using sticky sessions, one can take advantage of asynchronous messaging > and hence not affect the overall response time > and other benefits of course > > Filip > Vreixo Formoso wrote: > > Hi! > > > > I've a session replication problem I don't know how to solve. > > > > I've installed a tomcat cluster with 2 tomcat workers (v6.0.14) and an > > apache server 2.2.3 as load balancer, with mod_jk. > > > > I've configured DeltaManager for session replication. When I use sticky > > sessions, all works propertly, when I stop one tomcat the other one > > handles the session. > > > > However, if I disable sticky sessions things change. As a first sight, > > it seems to work ok. Each request is processed by a different tomcat, > > sessions are replicated propertly. However, if I send several requests > > too fast (well, not so fast, just clicking F5 in the web browser 1 or 2 > > times per second), after a short time the session is suddenly lost, and > > a new session is created. May it be a session replication problem? I've > > tried with several cluster->channelSendOptions but I always have the > > same problem. Note that with sticky sessions in the load balancer the > > problem does not exists. Any ideas? > > > > Thank you in advance. > > > > Cheers, > > Vreixo Formoso > > > > > > - cluster config in server.xml -- > > > > > channelSendOptions="4"> > > > >> className="org.apache.catalina.ha.session.DeltaManager" > >expireSessionsOnShutdown="false" > >notifyListenersOnReplication="true"/> > > > >> className="org.apache.catalina.tribes.group.GroupChannel"> > > > className="org.apache.catalina.tribes.membership.McastService" > > address="228.0.0.4" > > port="45564" > > frequency="500" > > dropTime="3000"/> > > > className="org.apache.catalina.tribes.transport.nio.NioReceiver" > > address="auto" > > port="4002" > > autoBind="100" > > selectorTimeout="5000" > > maxThreads="6"/> > > > > > className="org.apache.catalina.tribes.transport.ReplicationTransmitter"> > >> className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/> > > > > > className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/> > > > className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/> > > > > > >> filter=""/> > >> className="org.apache.catalina.ha.session.JvmRouteBinderValve"/> > > > >> className="org.apache.catalina.ha.deploy.FarmWarDeployer" > > tempDir="/tmp/war-temp/" > > deployDir="/tmp/war-deploy/" > > watchDir="/tmp/war-listen/" > > watchEnabled="false"/> > > > >> className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/> > >> className="org.apache.catalina.ha.session.ClusterSessionListener"/> > > > > > > > > > > > > > > > > > > - > > To start a new topic, e-mail: users@tomcat.apache.org > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > - > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat session replication problem
for it to work you would need to have channelSendOptions="6", however, not using sticky sessions is a bad strategy, no matter how you look at it. using sticky sessions, one can take advantage of asynchronous messaging and hence not affect the overall response time and other benefits of course Filip Vreixo Formoso wrote: Hi! I've a session replication problem I don't know how to solve. I've installed a tomcat cluster with 2 tomcat workers (v6.0.14) and an apache server 2.2.3 as load balancer, with mod_jk. I've configured DeltaManager for session replication. When I use sticky sessions, all works propertly, when I stop one tomcat the other one handles the session. However, if I disable sticky sessions things change. As a first sight, it seems to work ok. Each request is processed by a different tomcat, sessions are replicated propertly. However, if I send several requests too fast (well, not so fast, just clicking F5 in the web browser 1 or 2 times per second), after a short time the session is suddenly lost, and a new session is created. May it be a session replication problem? I've tried with several cluster->channelSendOptions but I always have the same problem. Note that with sticky sessions in the load balancer the problem does not exists. Any ideas? Thank you in advance. Cheers, Vreixo Formoso - cluster config in server.xml -- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Session Replication at undeploy/install (6.0.14 / windows)
[EMAIL PROTECTED] wrote: Hello, if I reload a context, all sessions are going to be serialized and deserialized automatically. Is the same possible at undeploy / deploy? yes, works the same way The problem is, that all users are thrown out of their apps if we "redeploy" under production. wanna give us a test case? Filip (I know thats not recommended, but sometimes its really necessary...) Thanks! Hans. Diese Nachricht ist ausschliesslich fuer den oben bezeichneten Adressaten bestimmt und enthaelt moeglicherweise vertrauliche Informationen. Sollten Sie nicht der oben bezeichnete Adressat sein oder diese Nachricht irrtuemlich erhalten haben, ersuchen wir Sie, diese Nachricht nicht weiterzugeben, zu kopieren oder im Vertrauen darauf zu handeln, sondern den Absender zu verstaendigen und diese Nachricht samt allfaelliger Anlagen sofort zu loeschen. Vielen Dank. This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee, you should not disseminate, copy, or take any action in reliance on it. If you have received this message in error, please immediately notify the sender of this message and delete this message and any attachment. Thank you. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat session replication/cluster (mod_proxy_ajp)
could well be. depends on your setup... > > WARNING: Unable to asynchronously send session with > id=[88798A041EC3F104045E5C22B47ADE77.jvm1-1151322148155] - message will > be ignored. java.net.ConnectException: Connection refused at > java.net.PlainSocketImpl.socketConnect(Native Method) at > java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) at > java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195) at > java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) at > java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) at > java.net.Socket.connect(Socket.java:507) at > java.net.Socket.connect(Socket.java:457) at > java.net.Socket.(Socket.java:365) at > java.net.Socket.(Socket.java:207) at > org.apache.catalina.cluster.tcp.DataSender.createSocket(DataSender.java:704) > at > org.apache.catalina.cluster.tcp.DataSender.openSocket(DataSender.java:679) > at > org.apache.catalina.cluster.tcp.DataSender.pushMessage(DataSender.java:803) > at > org.apache.catalina.cluster.tcp.FastAsyncSocketSender$FastQueueThread.pushQueuedMessages(FastAsyncSocketSender.java:476) > at > org.apache.catalina.cluster.tcp.FastAsyncSocketSender$FastQueueThread.run(FastAsyncSocketSender.java:442) > # > > Could this be a firewall problem on one of the receiving servers > - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat session replication/cluster (mod_proxy_ajp)
On Mon, 26 Jun 2006 11:46:43 +0100 Pid <[EMAIL PROTECTED]> wrote: > > > Sean O'Reilly wrote: > > > Still having some problems with load balancing and state replication > > neither of which appear to be working. If i shutdown tomcat on the > > main server i can still get to the application directory from one of > > the other servers but get a 503 error if i try to run any of the > > applications ?? > > Where's the 503 coming from, Apache or Tomcat? > > > > > - > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] An exciting new error WARNING: Unable to asynchronously send session with id=[88798A041EC3F104045E5C22B47ADE77.jvm1-1151322148155] - message will be ignored. java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) at java.net.Socket.connect(Socket.java:507) at java.net.Socket.connect(Socket.java:457) at java.net.Socket.(Socket.java:365) at java.net.Socket.(Socket.java:207) at org.apache.catalina.cluster.tcp.DataSender.createSocket(DataSender.java:704) at org.apache.catalina.cluster.tcp.DataSender.openSocket(DataSender.java:679) at org.apache.catalina.cluster.tcp.DataSender.pushMessage(DataSender.java:803) at org.apache.catalina.cluster.tcp.FastAsyncSocketSender$FastQueueThread.pushQueuedMessages(FastAsyncSocketSender.java:476) at org.apache.catalina.cluster.tcp.FastAsyncSocketSender$FastQueueThread.run(FastAsyncSocketSender.java:442) # Could this be a firewall problem on one of the receiving servers -- Sean O'Reilly Systems Administrator SECPay Ltd http://www.secpay.com [EMAIL PROTECTED] Mobile 07917 463906 DDI 01732 300212 This email contains information which is confidential. It is for the exclusive use of the addressee(s). If you are not the addressee, please note that any distribution, dissemination, copying or use of this communication or the information in it is prohibited. If you have received this email in error, please telephone me immediately. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat session replication/cluster (mod_proxy_ajp)
Sean O'Reilly wrote: > Still having some problems with load balancing and state replication > neither of which appear to be working. If i shutdown tomcat on the > main server i can still get to the application directory from one of > the other servers but get a 503 error if i try to run any of the > applications ?? Where's the 503 coming from, Apache or Tomcat? - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat session replication/cluster (mod_proxy_ajp)
(I've manually configured the tcpListenAddress to be the node's main IP. Obviously it's not 000.000.000.00.) I've specified JvmRouteBinderValve, JvmRouteSessionIDBinderListener and ClusterSessionListener. Sean O'Reilly wrote: > On Fri, 23 Jun 2006 16:43:16 +0100 > Pid <[EMAIL PROTECTED]> wrote: > >> >> Sean O'Reilly wrote: >>> On Fri, 23 Jun 2006 09:05:18 -0500 >>> Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: >>> I am sure it would be easier to use mod_proxy_balancer and >>> mod_proxy_ajp but can't find any documentation anywhere. >> My servers didn't have their clocks synchronised, check that. >> Also try using the most basic cluster config to start with and work up >> to more complex variations. >> >> There's not much to configure for proxy_ajp / balancer. >> We're running Apache2.2 + Tomcat 5.5.17 + with mod_proxy_ajp &c. >> AJP needs no config, which is nice. >> Balancer also needs very little, see mod_proxy for details. >> The route=TCS1 parameter is the jvmRoute set in the tomcat Engine. >> >> ### put this in your Apache vhost/conf >> >> ReWriteEngine on >> ProxyPreserveHost On >> ProxyRequests Off >> ProxyVia Off >> >> >>BalancerMember ajp://tomcat1:8009 smax=10 loadfactor=10 route=TCS1 >>BalancerMember ajp://tomcat2:8009 smax=10 loadfactor=10 route=TCS2 >> >> >> RewriteRule ^\/(.+)\.jsp(.+)? balancer://mycluster/$1.jsp$2 [P,L] >> >> ProxyPass /favicon.ico ! >> ProxyPass /robots.txt ! >> ProxyPass /images/ ! >> ProxyPass /forms/ balancer://mycluster/forms/ \ >> maxattempts=1 lbmethod=bytraffic stickysession=JSESSIONID >> >> >> >> >>> Thanks for the help so far guys. >>> >> - >> To start a new topic, e-mail: users@tomcat.apache.org >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] > ok here are latest config files > > server.xml (cluster configuration) > > name="cluster" > debug="10" > serviceclass="org.apache.catalina.cluster.mcast.McastService" > mcastAddress="228.0.0.4" > mcastPort="45564" > mcastFrequency="500" > mcastDroptime="3000" > tcpThreadCount="6" > tcpListenAddress="auto" > tcpListenPort="4001" > tcpSelectorTimeout="100" > printToScreen="false" > expireSessionsOnShutdown="false" > useDirtyFlag="true" > replicationMode="synchronous"/> > > > filter=".*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;"/> > ### > connector.conf > > ReWriteEngine On > ProxyPreserveHost On > ProxyRequests Off > ProxyViaOff > > > BalancerMember ajp://localhost:8009 smax=10 loadfactor=1 > route=jvm1 > BalancerMember ajp://192.168.4.3:8009 smax=10 loadfactor=1 > route=jvm2 > BalancerMember ajp://192.168.4.1:8009 smax=10 loadfactor=1 > route=jvm3 > > > RewriteRule ^\/(.+)\.jsp(.+)? balancer://secpay_cluster/$1.jsp$2 [P,L] > > ProxyPass /favicon.ico ! > ProxyPass /robots.txt ! > ProxyPass /images/ ! > ProxyPass /jsp-examples/* balancer://secpay_cluster/jsp-examples/ > maxattempts=1 lbmethod=byrequests nofailover=off > stickysession=JSESSIONID > ProxyPassReverse /jsp-example/* balancer://secpay_cluster/jsp-examples/ > maxattempts=1 lbmethod=byrequests nofailover=off > stickysession=JSESSIONID > ProxyPass /servlets-examples/* > balancer://secpay_cluster/servlets-examples/ maxattempts=1 > lbmethod=byrequests nofailover=off stickysession=JSESSIONID > ProxyPassReverse /servlets-examples/* > balancer://secpay_cluster/servlets-examples/ maxattempts=1 > lbmethod=byrequests nofailover=off stickysession=JSESSIONID > > ## > startup logs from one of the servers > > 26-Jun-2006 11:13:45 org.apache.catalina.cluster.tcp.SimpleTcpCluster > createDefaultClusterListener > INFO: Add Default ClusterListener at cluster localhost > 26-Jun-2006 11:13:45 org.apache.catalina.cluster.tcp.SimpleTcpCluster > createDefaultClusterReceiver > INFO: Add Default ClusterReceiver at cluster localhost > 26-Jun-2006 11:13:45 org.apache.catalina.cluster.tcp.SimpleTcpCluster > createDefaultClusterSender > INFO: Add Default ClusterSender at cluster localhost > 26-Jun-2006 11:13:45 > org.apache.catalina.cluster.tcp.SocketReplicationListener > createServerSocket > INFO: Open Socket at [127.0.0.1:8015] > 26-Jun-2006 11:13:45 > org.apache.catalina.cluster.tcp.ReplicationTransmitter start > INFO: Start ClusterSender at cluster > Standalone:type=Cluster,host=localhost with name > Standalone:type=ClusterSender,host=localhost > 26-Jun-2006 11:
Re: Tomcat session replication/cluster (mod_proxy_ajp)
On Fri, 23 Jun 2006 16:43:16 +0100 Pid <[EMAIL PROTECTED]> wrote: > > > Sean O'Reilly wrote: > > On Fri, 23 Jun 2006 09:05:18 -0500 > > Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: > > I am sure it would be easier to use mod_proxy_balancer and > > mod_proxy_ajp but can't find any documentation anywhere. > > My servers didn't have their clocks synchronised, check that. > Also try using the most basic cluster config to start with and work up > to more complex variations. > > There's not much to configure for proxy_ajp / balancer. > We're running Apache2.2 + Tomcat 5.5.17 + with mod_proxy_ajp &c. > AJP needs no config, which is nice. > Balancer also needs very little, see mod_proxy for details. > The route=TCS1 parameter is the jvmRoute set in the tomcat Engine. > > ### put this in your Apache vhost/conf > > ReWriteEngine on > ProxyPreserveHost On > ProxyRequests Off > ProxyVia Off > > >BalancerMember ajp://tomcat1:8009 smax=10 loadfactor=10 route=TCS1 >BalancerMember ajp://tomcat2:8009 smax=10 loadfactor=10 route=TCS2 > > > RewriteRule ^\/(.+)\.jsp(.+)? balancer://mycluster/$1.jsp$2 [P,L] > > ProxyPass /favicon.ico ! > ProxyPass /robots.txt ! > ProxyPass /images/ ! > ProxyPass /forms/ balancer://mycluster/forms/ \ > maxattempts=1 lbmethod=bytraffic stickysession=JSESSIONID > > > > > > Thanks for the help so far guys. > > > > - > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] ok here are latest config files server.xml (cluster configuration) ### connector.conf ReWriteEngine On ProxyPreserveHost On ProxyRequests Off ProxyViaOff BalancerMember ajp://localhost:8009 smax=10 loadfactor=1 route=jvm1 BalancerMember ajp://192.168.4.3:8009 smax=10 loadfactor=1 route=jvm2 BalancerMember ajp://192.168.4.1:8009 smax=10 loadfactor=1 route=jvm3 RewriteRule ^\/(.+)\.jsp(.+)? balancer://secpay_cluster/$1.jsp$2 [P,L] ProxyPass /favicon.ico ! ProxyPass /robots.txt ! ProxyPass /images/ ! ProxyPass /jsp-examples/* balancer://secpay_cluster/jsp-examples/ maxattempts=1 lbmethod=byrequests nofailover=off stickysession=JSESSIONID ProxyPassReverse /jsp-example/* balancer://secpay_cluster/jsp-examples/ maxattempts=1 lbmethod=byrequests nofailover=off stickysession=JSESSIONID ProxyPass /servlets-examples/* balancer://secpay_cluster/servlets-examples/ maxattempts=1 lbmethod=byrequests nofailover=off stickysession=JSESSIONID ProxyPassReverse /servlets-examples/* balancer://secpay_cluster/servlets-examples/ maxattempts=1 lbmethod=byrequests nofailover=off stickysession=JSESSIONID ## startup logs from one of the servers 26-Jun-2006 11:13:45 org.apache.catalina.cluster.tcp.SimpleTcpCluster createDefaultClusterListener INFO: Add Default ClusterListener at cluster localhost 26-Jun-2006 11:13:45 org.apache.catalina.cluster.tcp.SimpleTcpCluster createDefaultClusterReceiver INFO: Add Default ClusterReceiver at cluster localhost 26-Jun-2006 11:13:45 org.apache.catalina.cluster.tcp.SimpleTcpCluster createDefaultClusterSender INFO: Add Default ClusterSender at cluster localhost 26-Jun-2006 11:13:45 org.apache.catalina.cluster.tcp.SocketReplicationListener createServerSocket INFO: Open Socket at [127.0.0.1:8015] 26-Jun-2006 11:13:45 org.apache.catalina.cluster.tcp.ReplicationTransmitter start INFO: Start ClusterSender at cluster Standalone:type=Cluster,host=localhost with name Standalone:type=ClusterSender,host=localhost 26-Jun-2006 11:13:45 org.apache.catalina.cluster.tcp.SimpleTcpCluster createDefaultMembershipService INFO: Add Default Membership Service at cluster localhost 26-Jun-2006 11:13:45 org.apache.catalina.cluster.mcast.McastService start INFO: Sleeping for 4000 milliseconds to establish cluster membership 26-Jun-2006 11:13:46 org.apache.catalina.cluster.tcp.SimpleTcpCluster memberAdded INFO: Replication member added:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.4.121:8015,catalina,192.168.4.121,8015, alive=154886] 26-Jun-2006 11:13:46 org.apache.catalina.cluster.tcp.FastAsyncSocketSender checkThread INFO: Create sender [/192.168.4.121:8,015] queue thread to tcp background replication 26-Jun-2006 11:13:49 org.apache.catalina.cluster.mcast.McastService registerMBean INFO: membership mbean registered (Standalone:type=ClusterMembership,host=localhost) 26-Jun-2006 11:13:51 org.apache.catalina.core.ApplicationContext log INFO: org.apache.webapp.balancer.BalancerFilter: init(): ruleChain: [org.apache.webapp.balancer.RuleChain: [org.apache.webapp.balancer.rules.URLStringMatchRule: Target string: News / Redirect URL: http://www.cnn.com], [org.apache.webapp.balancer.rules.Requ
Re: Tomcat session replication/cluster (mod_proxy_ajp)
Sean O'Reilly wrote: > On Fri, 23 Jun 2006 09:05:18 -0500 > Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: > I am sure it would be easier to use mod_proxy_balancer and > mod_proxy_ajp but can't find any documentation anywhere. My servers didn't have their clocks synchronised, check that. Also try using the most basic cluster config to start with and work up to more complex variations. There's not much to configure for proxy_ajp / balancer. We're running Apache2.2 + Tomcat 5.5.17 + with mod_proxy_ajp &c. AJP needs no config, which is nice. Balancer also needs very little, see mod_proxy for details. The route=TCS1 parameter is the jvmRoute set in the tomcat Engine. ### put this in your Apache vhost/conf ReWriteEngine on ProxyPreserveHost On ProxyRequests Off ProxyVia Off BalancerMember ajp://tomcat1:8009 smax=10 loadfactor=10 route=TCS1 BalancerMember ajp://tomcat2:8009 smax=10 loadfactor=10 route=TCS2 RewriteRule ^\/(.+)\.jsp(.+)? balancer://mycluster/$1.jsp$2 [P,L] ProxyPass /favicon.ico ! ProxyPass /robots.txt ! ProxyPass /images/ ! ProxyPass /forms/ balancer://mycluster/forms/ \ maxattempts=1 lbmethod=bytraffic stickysession=JSESSIONID > Thanks for the help so far guys. > - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat session replication/cluster
How are you defining the cluster in your server.xml? I did this recently, and had a bunch of small problems. E.g. my server clocks weren't sync'd. I found that enabling just the SimpleTcpCluster element (without all the rest) helped me get up and running. Sean O'Reilly wrote: > On Fri, 23 Jun 2006 10:00:36 -0500 > Here is what is written to my logs > > 23-Jun-2006 16:26:38 org.apache.catalina.cluster.session.DeltaManager > waitForSendAllSessions SEVERE: Manager [/jsp-examples]: No session > state send at 23/06/06 16:25 received, timing out after 60,121 ms. > 23-Jun-2006 16:26:38 org.apache.catalina.core.ApplicationContext log > INFO: ContextListener: contextInitialized() 23-Jun-2006 16:26:38 > org.apache.catalina.core.ApplicationContext log INFO: SessionListener: > contextInitialized() 23-Jun-2006 16:26:39 > org.apache.jk.common.ChannelSocket init INFO: JK: ajp13 listening > on /0.0.0.0:8009 23-Jun-2006 16:26:39 org.apache.jk.server.JkMain start > INFO: Jk running ID=0 time=0/230 config=null > 23-Jun-2006 16:26:39 org.apache.catalina.storeconfig.StoreLoader load > INFO: Find registry server-registry.xml at classpath resource > 23-Jun-2006 16:26:39 org.apache.catalina.startup.Catalina start > INFO: Server startup in 67074 ms > - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat session replication/cluster
Sean O'Reilly wrote: On Fri, 23 Jun 2006 10:00:36 -0500 Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: Sean O'Reilly wrote: On Fri, 23 Jun 2006 09:05:18 -0500 Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: Hi Guys, I appear to be finally getting somewhere with the in-memory state replication but am now getting the following error when starting up my tomcat instances/ WARNING: Manager [/jsp-examples], requesting session state from org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.4.121:4001,catalina,192.168.4.121,4001, alive=74436]. This operation will timeout if no session state has been received within 60 seconds. 23-Jun-2006 13:27:38 org.apache.catalina.cluster.session.DeltaManager waitForSendAllSessions SEVERE: Manager [/jsp-examples]: No session state send at 23/06/06 13:26 received, timing out after 60,140 ms. 23-Jun-2006 13:27:38 org.apache.catalina.core.ApplicationContext log INFO: ContextListener: contextInitialized() 23-Jun-2006 13:27:38 org.apache.catalina.core.ApplicationContext log INFO: SessionListener: contextInitialized() 23-Jun-2006 13:27:38 org.apache.jk.common.ChannelSocket init INFO: JK: ajp13 listening on /0.0.0.0:8009 23-Jun-2006 13:27:38 org.apache.jk.server.JkMain start INFO: Jk running ID=0 time=0/224 config=null 23-Jun-2006 13:27:38 org.apache.catalina.storeconfig.StoreLoader load INFO: Find registry server-registry.xml at classpath resource 23-Jun-2006 13:27:39 org.apache.catalina.startup.Catalina start INFO: Server startup in 67102 ms Can anyone point me in the right direction as to why the session state is not being replicated ? Two things to check: 1. What does the other server log say, maybe there is an error there, does the other server know of this server? 2. your server.xml, you would need to provide us with a little bit more info Filip - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I might be being a bit thick here !!! I have 3 servers ! One is running apache2, mod_jk2 and tomcat-5.5.17, the other two just have tomcat-5.5.17. Do i need to have apache and mod_jk2 running on all servers ? I am sure it would be easier to use mod_proxy_balancer and mod_proxy_ajp but can't find any documentation anywhere. Thanks for the help so far guys. your problem is not related to Apache or mod_jk, its strictly Tomcat. Session state transfer fails. and that's the path you need to persue. 1. Check all your tomcat logs 2. Make sure that node discovery is working, you should have in each of your tomcat nodes, a info log statement saying it detected the other two nodes. Filip Here is what is written to my logs 23-Jun-2006 16:26:38 org.apache.catalina.cluster.session.DeltaManager waitForSendAllSessions SEVERE: Manager [/jsp-examples]: No session state send at 23/06/06 16:25 received, timing out after 60,121 ms. 23-Jun-2006 16:26:38 org.apache.catalina.core.ApplicationContext log INFO: ContextListener: contextInitialized() 23-Jun-2006 16:26:38 org.apache.catalina.core.ApplicationContext log INFO: SessionListener: contextInitialized() 23-Jun-2006 16:26:39 org.apache.jk.common.ChannelSocket init INFO: JK: ajp13 listening on /0.0.0.0:8009 23-Jun-2006 16:26:39 org.apache.jk.server.JkMain start INFO: Jk running ID=0 time=0/230 config=null 23-Jun-2006 16:26:39 org.apache.catalina.storeconfig.StoreLoader load INFO: Find registry server-registry.xml at classpath resource 23-Jun-2006 16:26:39 org.apache.catalina.startup.Catalina start INFO: Server startup in 67074 ms I'm sure the is plenty more in the log earlier that you are kindfully omitting and that is vital Filip -- Filip Hanik - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat session replication/cluster
On Fri, 23 Jun 2006 10:00:36 -0500 Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: > Sean O'Reilly wrote: > > On Fri, 23 Jun 2006 09:05:18 -0500 > > Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: > > > > > >>> Hi Guys, > >>> > >>> I appear to be finally getting somewhere with the in-memory state > >>> replication but am now getting the following error when starting > >>> up my tomcat instances/ > >>> > >>> WARNING: Manager [/jsp-examples], requesting session state from > >>> org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.4.121:4001,catalina,192.168.4.121,4001, > >>> alive=74436]. This operation will timeout if no session state has > >>> been received within 60 seconds. 23-Jun-2006 13:27:38 > >>> org.apache.catalina.cluster.session.DeltaManager > >>> waitForSendAllSessions SEVERE: Manager [/jsp-examples]: No session > >>> state send at 23/06/06 13:26 received, timing out after 60,140 ms. > >>> 23-Jun-2006 13:27:38 org.apache.catalina.core.ApplicationContext > >>> log INFO: ContextListener: contextInitialized() 23-Jun-2006 > >>> 13:27:38 org.apache.catalina.core.ApplicationContext log INFO: > >>> SessionListener: contextInitialized() 23-Jun-2006 13:27:38 > >>> org.apache.jk.common.ChannelSocket init INFO: JK: ajp13 listening > >>> on /0.0.0.0:8009 23-Jun-2006 13:27:38 org.apache.jk.server.JkMain > >>> start INFO: Jk running ID=0 time=0/224 config=null 23-Jun-2006 > >>> 13:27:38 org.apache.catalina.storeconfig.StoreLoader load INFO: > >>> Find registry server-registry.xml at classpath resource > >>> 23-Jun-2006 13:27:39 org.apache.catalina.startup.Catalina start > >>> INFO: Server startup in 67102 ms > >>> > >>> Can anyone point me in the right direction as to why the session > >>> state is not being replicated ? > >>> > >>> > >> Two things to check: > >> 1. What does the other server log say, maybe there is an error > >> there, does the other server know of this server? > >> 2. your server.xml, you would need to provide us with a little bit > >> more info > >> > >> Filip > >> > >> - > >> To start a new topic, e-mail: users@tomcat.apache.org > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > > > > I might be being a bit thick here !!! > > > > I have 3 servers ! > > > > One is running apache2, mod_jk2 and tomcat-5.5.17, the other two > > just have tomcat-5.5.17. Do i need to have apache and mod_jk2 > > running on all servers ? > > > > I am sure it would be easier to use mod_proxy_balancer and > > mod_proxy_ajp but can't find any documentation anywhere. > > > > Thanks for the help so far guys. > > > your problem is not related to Apache or mod_jk, its strictly Tomcat. > Session state transfer fails. > and that's the path you need to persue. > 1. Check all your tomcat logs > 2. Make sure that node discovery is working, you should have in each > of your tomcat nodes, a info log statement saying it detected the > other two nodes. > > Filip > > Here is what is written to my logs 23-Jun-2006 16:26:38 org.apache.catalina.cluster.session.DeltaManager waitForSendAllSessions SEVERE: Manager [/jsp-examples]: No session state send at 23/06/06 16:25 received, timing out after 60,121 ms. 23-Jun-2006 16:26:38 org.apache.catalina.core.ApplicationContext log INFO: ContextListener: contextInitialized() 23-Jun-2006 16:26:38 org.apache.catalina.core.ApplicationContext log INFO: SessionListener: contextInitialized() 23-Jun-2006 16:26:39 org.apache.jk.common.ChannelSocket init INFO: JK: ajp13 listening on /0.0.0.0:8009 23-Jun-2006 16:26:39 org.apache.jk.server.JkMain start INFO: Jk running ID=0 time=0/230 config=null 23-Jun-2006 16:26:39 org.apache.catalina.storeconfig.StoreLoader load INFO: Find registry server-registry.xml at classpath resource 23-Jun-2006 16:26:39 org.apache.catalina.startup.Catalina start INFO: Server startup in 67074 ms -- Sean O'Reilly Systems Administrator SECPay Ltd http://www.secpay.com [EMAIL PROTECTED] Mobile 07917 463906 DDI 01732 300212 This email contains information which is confidential. It is for the exclusive use of the addressee(s). If you are not the addressee, please note that any distribution, dissemination, copying or use of this communication or the information in it is prohibited. If you have received this email in error, please telephone me immediately. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat session replication/cluster
Sean O'Reilly wrote: On Fri, 23 Jun 2006 09:05:18 -0500 Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: Hi Guys, I appear to be finally getting somewhere with the in-memory state replication but am now getting the following error when starting up my tomcat instances/ WARNING: Manager [/jsp-examples], requesting session state from org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.4.121:4001,catalina,192.168.4.121,4001, alive=74436]. This operation will timeout if no session state has been received within 60 seconds. 23-Jun-2006 13:27:38 org.apache.catalina.cluster.session.DeltaManager waitForSendAllSessions SEVERE: Manager [/jsp-examples]: No session state send at 23/06/06 13:26 received, timing out after 60,140 ms. 23-Jun-2006 13:27:38 org.apache.catalina.core.ApplicationContext log INFO: ContextListener: contextInitialized() 23-Jun-2006 13:27:38 org.apache.catalina.core.ApplicationContext log INFO: SessionListener: contextInitialized() 23-Jun-2006 13:27:38 org.apache.jk.common.ChannelSocket init INFO: JK: ajp13 listening on /0.0.0.0:8009 23-Jun-2006 13:27:38 org.apache.jk.server.JkMain start INFO: Jk running ID=0 time=0/224 config=null 23-Jun-2006 13:27:38 org.apache.catalina.storeconfig.StoreLoader load INFO: Find registry server-registry.xml at classpath resource 23-Jun-2006 13:27:39 org.apache.catalina.startup.Catalina start INFO: Server startup in 67102 ms Can anyone point me in the right direction as to why the session state is not being replicated ? Two things to check: 1. What does the other server log say, maybe there is an error there, does the other server know of this server? 2. your server.xml, you would need to provide us with a little bit more info Filip - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I might be being a bit thick here !!! I have 3 servers ! One is running apache2, mod_jk2 and tomcat-5.5.17, the other two just have tomcat-5.5.17. Do i need to have apache and mod_jk2 running on all servers ? I am sure it would be easier to use mod_proxy_balancer and mod_proxy_ajp but can't find any documentation anywhere. Thanks for the help so far guys. your problem is not related to Apache or mod_jk, its strictly Tomcat. Session state transfer fails. and that's the path you need to persue. 1. Check all your tomcat logs 2. Make sure that node discovery is working, you should have in each of your tomcat nodes, a info log statement saying it detected the other two nodes. Filip -- Filip Hanik - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat session replication/cluster
On Fri, 23 Jun 2006 09:05:18 -0500 Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: > > > Hi Guys, > > > > I appear to be finally getting somewhere with the in-memory state > > replication but am now getting the following error when starting up > > my tomcat instances/ > > > > WARNING: Manager [/jsp-examples], requesting session state from > > org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.4.121:4001,catalina,192.168.4.121,4001, > > alive=74436]. This operation will timeout if no session state has > > been received within 60 seconds. 23-Jun-2006 13:27:38 > > org.apache.catalina.cluster.session.DeltaManager > > waitForSendAllSessions SEVERE: Manager [/jsp-examples]: No session > > state send at 23/06/06 13:26 received, timing out after 60,140 ms. > > 23-Jun-2006 13:27:38 org.apache.catalina.core.ApplicationContext > > log INFO: ContextListener: contextInitialized() 23-Jun-2006 13:27:38 > > org.apache.catalina.core.ApplicationContext log INFO: > > SessionListener: contextInitialized() 23-Jun-2006 13:27:38 > > org.apache.jk.common.ChannelSocket init INFO: JK: ajp13 listening > > on /0.0.0.0:8009 23-Jun-2006 13:27:38 org.apache.jk.server.JkMain > > start INFO: Jk running ID=0 time=0/224 config=null 23-Jun-2006 > > 13:27:38 org.apache.catalina.storeconfig.StoreLoader load INFO: > > Find registry server-registry.xml at classpath resource 23-Jun-2006 > > 13:27:39 org.apache.catalina.startup.Catalina start INFO: Server > > startup in 67102 ms > > > > Can anyone point me in the right direction as to why the session > > state is not being replicated ? > > > Two things to check: > 1. What does the other server log say, maybe there is an error there, > does the other server know of this server? > 2. your server.xml, you would need to provide us with a little bit > more info > > Filip > > - > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] I might be being a bit thick here !!! I have 3 servers ! One is running apache2, mod_jk2 and tomcat-5.5.17, the other two just have tomcat-5.5.17. Do i need to have apache and mod_jk2 running on all servers ? I am sure it would be easier to use mod_proxy_balancer and mod_proxy_ajp but can't find any documentation anywhere. Thanks for the help so far guys. -- Sean O'Reilly Systems Administrator SECPay Ltd http://www.secpay.com [EMAIL PROTECTED] Mobile 07917 463906 DDI 01732 300212 This email contains information which is confidential. It is for the exclusive use of the addressee(s). If you are not the addressee, please note that any distribution, dissemination, copying or use of this communication or the information in it is prohibited. If you have received this email in error, please telephone me immediately. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat session replication/cluster
Hi Guys, I appear to be finally getting somewhere with the in-memory state replication but am now getting the following error when starting up my tomcat instances/ WARNING: Manager [/jsp-examples], requesting session state from org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.4.121:4001,catalina,192.168.4.121,4001, alive=74436]. This operation will timeout if no session state has been received within 60 seconds. 23-Jun-2006 13:27:38 org.apache.catalina.cluster.session.DeltaManager waitForSendAllSessions SEVERE: Manager [/jsp-examples]: No session state send at 23/06/06 13:26 received, timing out after 60,140 ms. 23-Jun-2006 13:27:38 org.apache.catalina.core.ApplicationContext log INFO: ContextListener: contextInitialized() 23-Jun-2006 13:27:38 org.apache.catalina.core.ApplicationContext log INFO: SessionListener: contextInitialized() 23-Jun-2006 13:27:38 org.apache.jk.common.ChannelSocket init INFO: JK: ajp13 listening on /0.0.0.0:8009 23-Jun-2006 13:27:38 org.apache.jk.server.JkMain start INFO: Jk running ID=0 time=0/224 config=null 23-Jun-2006 13:27:38 org.apache.catalina.storeconfig.StoreLoader load INFO: Find registry server-registry.xml at classpath resource 23-Jun-2006 13:27:39 org.apache.catalina.startup.Catalina start INFO: Server startup in 67102 ms Can anyone point me in the right direction as to why the session state is not being replicated ? Two things to check: 1. What does the other server log say, maybe there is an error there, does the other server know of this server? 2. your server.xml, you would need to provide us with a little bit more info Filip - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat session replication/cluster
On Thu, 22 Jun 2006 15:39:09 +0100
Pid <[EMAIL PROTECTED]> wrote:
> In each case it's the ROOT context, so is it appending "" where
> there's no Context name/path: ie
>
> SEVERE: Context manager doesn't exist:host1+context1
>
> where context1=""
> ?
>
> It would still seem that the name parameter supplied to the
> getManagerName is carrying over it's previous value, and appending
> again, rather than resetting. I'm not familiar enough with the code
> to see where it's occuring though.
>
>
>
> Pid wrote:
> > OK,
> >
> > I'm probably being dense here.
> >
> > (There's only 1 context in each host, the ROOT context)
> > If I take the Host/Context offline in one node and restart it, the
> > logs on that node start showing the following:
> >
> > SEVERE: Context manager doesn't exist:host1
> >
> > As the Context doesn't exist, which is the same message that appears
> > briefly in the logs during a restart, until that particular Host is
> > loaded (under normal circumstances).
> >
> > This much I understand, and provides no problems for me.
> >
> >
> > With all Hosts available on each node of the cluster, I then update
> > the Context on one Host, (by adding a new jar, say). The Context
> > has reloadable="true", so it does just that.
> >
> > Once that context has updated, the other nodes start seeing:
> >
> > SEVERE: Context manager doesn't exist:host1host1
> >
> > If I reload the context again, (without restarting the server), I
> > see this:
> >
> > SEVERE: Context manager doesn't exist:host1host1host1
> >
> > I could go on, but I think you can see where this is going...
> >
> >
> >
> > Peter Rossbach wrote:
> >> Hmm,
> >>
> >> look at o.a.c.cluster.tcp.SimpleTcpCluster
> >>
> >> L 626ff
> >> private String getManagerName(String name, Manager manager) {
> >> String clusterName = name ;
> >> if(getContainer() instanceof Engine) {
> >> Container context = manager.getContainer() ;
> >> if(context != null && context instanceof Context) {
> >> Container host = ((Context)context).getParent();
> >> if(host != null && host instanceof Host)
> >> clusterName = host.getName() + name ;
> >> }
> >> }
> >> return clusterName;
> >> }
> >>
> >>
> >> You see we append "hostname + context" as cluster engine container.
> >>
> >> Peter
> >>
> >>
> >>
> >> Am 22.06.2006 um 10:32 schrieb Pid:
> >>
> >>>
> >>> Filip Hanik - Dev Lists wrote:
> if the cluster is put in the engine element, the context names
> are prefixed with the engine name, since you can have multiple
> contexts with the same name in different host
> when reloading a context, you'll get these errors cause the
> context is not available during the reload
> this will be fixed with the new Apache Tribes module
> Filip
> >>> I understand that the context is not available during reload.
> >>> After reload has completed, the error persists.
> >>>
> >>> My Engine name is Catalina, it looks like the cluster isn't
> >>> sending the engine name, but the context name, appended to itself.
> >>>
> >>> You're implying that it should send Catalina+website1, but it's
> >>> sending website1+website1 instead.
> >>>
> >>> After startup:
> >>> Node1 sees Node2 send "website2"
> >>> Node2 sees Node1 send "website1"
> >>>
> >>> After context on Node1 is finished reloading:
> >>> Node1 sees Node2 send "website2"
> >>> Node2 sees Node1 send "website1website1"
> >>>
> >>> I think that the context name is being appended to itself.
> >>>
> >>>
> Pid wrote:
> > I'm seeing an issue on 5.5.17 with a 2 node cluster config.
> > When a context is reloaded, it sends the context node name
> > incorrectly to the cluster.
> > E.g. context is called "website1"
> >
> > SEVERE: Context manager doesn't exist:website1website1
> >
> > The config I'm using is exactly the same as the default from
> > server.xml,
> > except the cluster is defined in Engine, rather than each Host.
> >
> >
> >
> >
> > Filip Hanik - Dev Lists wrote:
> >
> >> also, use Tomcat 5.5.17
> >>
> >> Sean O'Reilly wrote:
> >>
> >>> Hi,
> >>>
> >>> I am trying to get in-memory session replication working and
> >>> am testing
> >>> running 3 seperate tomcat instances on the same server.
> >>>
> >>> I am using tomcat-5.5.15 and apache-2.0.54 with jk2.
> >>>
> >>> Whenever i run my test app although it should be doing
> >>> round-robin load
> >>> balancing it doesn't switch to another instance of tomcat
> >>> until the eighth request and does not appear to have sent the
> >>> session information
> >>> across as the session ID changes.
> >>>
> >>> Here are my server.xml and workers2.properties files
> >>>
> >>> server.xml
> >>>
> >>>
> >>>
> >>>
> >>>>>> className="org.ap
Re: Tomcat session replication/cluster
In each case it's the ROOT context, so is it appending "" where there's
no Context name/path: ie
SEVERE: Context manager doesn't exist:host1+context1
where context1=""
?
It would still seem that the name parameter supplied to the
getManagerName is carrying over it's previous value, and appending
again, rather than resetting. I'm not familiar enough with the code to
see where it's occuring though.
Pid wrote:
> OK,
>
> I'm probably being dense here.
>
> (There's only 1 context in each host, the ROOT context)
> If I take the Host/Context offline in one node and restart it, the logs
> on that node start showing the following:
>
> SEVERE: Context manager doesn't exist:host1
>
> As the Context doesn't exist, which is the same message that appears
> briefly in the logs during a restart, until that particular Host is
> loaded (under normal circumstances).
>
> This much I understand, and provides no problems for me.
>
>
> With all Hosts available on each node of the cluster, I then update the
> Context on one Host, (by adding a new jar, say). The Context has
> reloadable="true", so it does just that.
>
> Once that context has updated, the other nodes start seeing:
>
> SEVERE: Context manager doesn't exist:host1host1
>
> If I reload the context again, (without restarting the server), I see this:
>
> SEVERE: Context manager doesn't exist:host1host1host1
>
> I could go on, but I think you can see where this is going...
>
>
>
> Peter Rossbach wrote:
>> Hmm,
>>
>> look at o.a.c.cluster.tcp.SimpleTcpCluster
>>
>> L 626ff
>> private String getManagerName(String name, Manager manager) {
>> String clusterName = name ;
>> if(getContainer() instanceof Engine) {
>> Container context = manager.getContainer() ;
>> if(context != null && context instanceof Context) {
>> Container host = ((Context)context).getParent();
>> if(host != null && host instanceof Host)
>> clusterName = host.getName() + name ;
>> }
>> }
>> return clusterName;
>> }
>>
>>
>> You see we append "hostname + context" as cluster engine container.
>>
>> Peter
>>
>>
>>
>> Am 22.06.2006 um 10:32 schrieb Pid:
>>
>>>
>>> Filip Hanik - Dev Lists wrote:
if the cluster is put in the engine element, the context names are
prefixed with the engine name, since you can have multiple contexts with
the same name in different host
when reloading a context, you'll get these errors cause the context is
not available during the reload
this will be fixed with the new Apache Tribes module
Filip
>>> I understand that the context is not available during reload. After
>>> reload has completed, the error persists.
>>>
>>> My Engine name is Catalina, it looks like the cluster isn't sending the
>>> engine name, but the context name, appended to itself.
>>>
>>> You're implying that it should send Catalina+website1, but it's sending
>>> website1+website1 instead.
>>>
>>> After startup:
>>> Node1 sees Node2 send "website2"
>>> Node2 sees Node1 send "website1"
>>>
>>> After context on Node1 is finished reloading:
>>> Node1 sees Node2 send "website2"
>>> Node2 sees Node1 send "website1website1"
>>>
>>> I think that the context name is being appended to itself.
>>>
>>>
Pid wrote:
> I'm seeing an issue on 5.5.17 with a 2 node cluster config.
> When a context is reloaded, it sends the context node name incorrectly
> to the cluster.
> E.g. context is called "website1"
>
> SEVERE: Context manager doesn't exist:website1website1
>
> The config I'm using is exactly the same as the default from
> server.xml,
> except the cluster is defined in Engine, rather than each Host.
>
>
>
>
> Filip Hanik - Dev Lists wrote:
>
>> also, use Tomcat 5.5.17
>>
>> Sean O'Reilly wrote:
>>
>>> Hi,
>>>
>>> I am trying to get in-memory session replication working and am
>>> testing
>>> running 3 seperate tomcat instances on the same server.
>>>
>>> I am using tomcat-5.5.15 and apache-2.0.54 with jk2.
>>>
>>> Whenever i run my test app although it should be doing round-robin
>>> load
>>> balancing it doesn't switch to another instance of tomcat until the
>>> eighth request and does not appear to have sent the session
>>> information
>>> across as the session ID changes.
>>>
>>> Here are my server.xml and workers2.properties files
>>>
>>> server.xml
>>>
>>>
>>>
>>>
>>> >> className="org.apache.catalina.core.AprLifecycleListener" />
>>> >> className="org.apache.catalina.mbeans.ServerLifecycleListener" />
>>> >> className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"
>>>
>>> />
>>> >> className="org.apache.catalina.storeconfig.StoreConfigLifecycleListener"/>
>>>
>>>
>>>
>>>
>>>
>>>
Re: Tomcat session replication/cluster
Makes sense, can we please ask you to open up a bug for us,
http://issues.apache.org/bugzilla/
thanks
Filip
Pid wrote:
OK,
I'm probably being dense here.
(There's only 1 context in each host, the ROOT context)
If I take the Host/Context offline in one node and restart it, the logs
on that node start showing the following:
SEVERE: Context manager doesn't exist:host1
As the Context doesn't exist, which is the same message that appears
briefly in the logs during a restart, until that particular Host is
loaded (under normal circumstances).
This much I understand, and provides no problems for me.
With all Hosts available on each node of the cluster, I then update the
Context on one Host, (by adding a new jar, say). The Context has
reloadable="true", so it does just that.
Once that context has updated, the other nodes start seeing:
SEVERE: Context manager doesn't exist:host1host1
If I reload the context again, (without restarting the server), I see this:
SEVERE: Context manager doesn't exist:host1host1host1
I could go on, but I think you can see where this is going...
Peter Rossbach wrote:
Hmm,
look at o.a.c.cluster.tcp.SimpleTcpCluster
L 626ff
private String getManagerName(String name, Manager manager) {
String clusterName = name ;
if(getContainer() instanceof Engine) {
Container context = manager.getContainer() ;
if(context != null && context instanceof Context) {
Container host = ((Context)context).getParent();
if(host != null && host instanceof Host)
clusterName = host.getName() + name ;
}
}
return clusterName;
}
You see we append "hostname + context" as cluster engine container.
Peter
Am 22.06.2006 um 10:32 schrieb Pid:
Filip Hanik - Dev Lists wrote:
if the cluster is put in the engine element, the context names are
prefixed with the engine name, since you can have multiple contexts with
the same name in different host
when reloading a context, you'll get these errors cause the context is
not available during the reload
this will be fixed with the new Apache Tribes module
Filip
I understand that the context is not available during reload. After
reload has completed, the error persists.
My Engine name is Catalina, it looks like the cluster isn't sending the
engine name, but the context name, appended to itself.
You're implying that it should send Catalina+website1, but it's sending
website1+website1 instead.
After startup:
Node1 sees Node2 send "website2"
Node2 sees Node1 send "website1"
After context on Node1 is finished reloading:
Node1 sees Node2 send "website2"
Node2 sees Node1 send "website1website1"
I think that the context name is being appended to itself.
Pid wrote:
I'm seeing an issue on 5.5.17 with a 2 node cluster config.
When a context is reloaded, it sends the context node name incorrectly
to the cluster.
E.g. context is called "website1"
SEVERE: Context manager doesn't exist:website1website1
The config I'm using is exactly the same as the default from
server.xml,
except the cluster is defined in Engine, rather than each Host.
Filip Hanik - Dev Lists wrote:
also, use Tomcat 5.5.17
Sean O'Reilly wrote:
Hi,
I am trying to get in-memory session replication working and am
testing
running 3 seperate tomcat instances on the same server.
I am using tomcat-5.5.15 and apache-2.0.54 with jk2.
Whenever i run my test app although it should be doing round-robin
load
balancing it doesn't switch to another instance of tomcat until the
eighth request and does not appear to have sent the session
information
across as the session ID changes.
Here are my server.xml and workers2.properties files
server.xml
workers2.properties
[logger.apache2]
file="/etc/httpd/conf/logs/error.log"
level=INFO
debug=1
# Config settings
[config]
file=/etc/httpd/conf/workers2.properties
debug=0
# Shared memory file settings
[shm]
file=/etc/httpd/conf/jk2.shm
size=10
# Communcation channel settings for "Tomcat5A"
[channel.socket:localhost:8009]
host=localhost
port=8009
tomcatId=Tomcat5A
group=balanced
lb_factor=1
route=Tomcat5A
# Declare a Tomcat5A worker
[ajp13:localhost:8009]
channel=channel.socket:Tomcat5A
# Communcation channel settings for "Tomcat5B"
[channel.socket:localhost:8010]
host=localhost
port=8010
tomcatId=Tomcat5B
group=
Re: Tomcat session replication/cluster
OK,
I'm probably being dense here.
(There's only 1 context in each host, the ROOT context)
If I take the Host/Context offline in one node and restart it, the logs
on that node start showing the following:
SEVERE: Context manager doesn't exist:host1
As the Context doesn't exist, which is the same message that appears
briefly in the logs during a restart, until that particular Host is
loaded (under normal circumstances).
This much I understand, and provides no problems for me.
With all Hosts available on each node of the cluster, I then update the
Context on one Host, (by adding a new jar, say). The Context has
reloadable="true", so it does just that.
Once that context has updated, the other nodes start seeing:
SEVERE: Context manager doesn't exist:host1host1
If I reload the context again, (without restarting the server), I see this:
SEVERE: Context manager doesn't exist:host1host1host1
I could go on, but I think you can see where this is going...
Peter Rossbach wrote:
> Hmm,
>
> look at o.a.c.cluster.tcp.SimpleTcpCluster
>
> L 626ff
> private String getManagerName(String name, Manager manager) {
> String clusterName = name ;
> if(getContainer() instanceof Engine) {
> Container context = manager.getContainer() ;
> if(context != null && context instanceof Context) {
> Container host = ((Context)context).getParent();
> if(host != null && host instanceof Host)
> clusterName = host.getName() + name ;
> }
> }
> return clusterName;
> }
>
>
> You see we append "hostname + context" as cluster engine container.
>
> Peter
>
>
>
> Am 22.06.2006 um 10:32 schrieb Pid:
>
>>
>>
>> Filip Hanik - Dev Lists wrote:
>>> if the cluster is put in the engine element, the context names are
>>> prefixed with the engine name, since you can have multiple contexts with
>>> the same name in different host
>>> when reloading a context, you'll get these errors cause the context is
>>> not available during the reload
>>> this will be fixed with the new Apache Tribes module
>>> Filip
>>
>> I understand that the context is not available during reload. After
>> reload has completed, the error persists.
>>
>> My Engine name is Catalina, it looks like the cluster isn't sending the
>> engine name, but the context name, appended to itself.
>>
>> You're implying that it should send Catalina+website1, but it's sending
>> website1+website1 instead.
>>
>> After startup:
>> Node1 sees Node2 send "website2"
>> Node2 sees Node1 send "website1"
>>
>> After context on Node1 is finished reloading:
>> Node1 sees Node2 send "website2"
>> Node2 sees Node1 send "website1website1"
>>
>> I think that the context name is being appended to itself.
>>
>>
>>> Pid wrote:
I'm seeing an issue on 5.5.17 with a 2 node cluster config.
When a context is reloaded, it sends the context node name incorrectly
to the cluster.
E.g. context is called "website1"
SEVERE: Context manager doesn't exist:website1website1
The config I'm using is exactly the same as the default from
server.xml,
except the cluster is defined in Engine, rather than each Host.
Filip Hanik - Dev Lists wrote:
> also, use Tomcat 5.5.17
>
> Sean O'Reilly wrote:
>
>> Hi,
>>
>> I am trying to get in-memory session replication working and am
>> testing
>> running 3 seperate tomcat instances on the same server.
>>
>> I am using tomcat-5.5.15 and apache-2.0.54 with jk2.
>>
>> Whenever i run my test app although it should be doing round-robin
>> load
>> balancing it doesn't switch to another instance of tomcat until the
>> eighth request and does not appear to have sent the session
>> information
>> across as the session ID changes.
>>
>> Here are my server.xml and workers2.properties files
>>
>> server.xml
>>
>>
>>
>>
>> > className="org.apache.catalina.core.AprLifecycleListener" />
>> > className="org.apache.catalina.mbeans.ServerLifecycleListener" />
>> > className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"
>>
>> />
>> > className="org.apache.catalina.storeconfig.StoreConfigLifecycleListener"/>
>>
>>
>>
>>
>>
>>
>>
>>
>> > value="30"/>
>>
>>
>> > 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" />
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> > redirectPort="8443"
>> protocol="AJP/1.3"
Re: Tomcat session replication/cluster
Hmm,
look at o.a.c.cluster.tcp.SimpleTcpCluster
L 626ff
private String getManagerName(String name, Manager manager) {
String clusterName = name ;
if(getContainer() instanceof Engine) {
Container context = manager.getContainer() ;
if(context != null && context instanceof Context) {
Container host = ((Context)context).getParent();
if(host != null && host instanceof Host)
clusterName = host.getName() + name ;
}
}
return clusterName;
}
You see we append "hostname + context" as cluster engine container.
Peter
Am 22.06.2006 um 10:32 schrieb Pid:
Filip Hanik - Dev Lists wrote:
if the cluster is put in the engine element, the context names are
prefixed with the engine name, since you can have multiple
contexts with
the same name in different host
when reloading a context, you'll get these errors cause the
context is
not available during the reload
this will be fixed with the new Apache Tribes module
Filip
I understand that the context is not available during reload. After
reload has completed, the error persists.
My Engine name is Catalina, it looks like the cluster isn't sending
the
engine name, but the context name, appended to itself.
You're implying that it should send Catalina+website1, but it's
sending
website1+website1 instead.
After startup:
Node1 sees Node2 send "website2"
Node2 sees Node1 send "website1"
After context on Node1 is finished reloading:
Node1 sees Node2 send "website2"
Node2 sees Node1 send "website1website1"
I think that the context name is being appended to itself.
Pid wrote:
I'm seeing an issue on 5.5.17 with a 2 node cluster config.
When a context is reloaded, it sends the context node name
incorrectly
to the cluster.
E.g. context is called "website1"
SEVERE: Context manager doesn't exist:website1website1
The config I'm using is exactly the same as the default from
server.xml,
except the cluster is defined in Engine, rather than each Host.
Filip Hanik - Dev Lists wrote:
also, use Tomcat 5.5.17
Sean O'Reilly wrote:
Hi,
I am trying to get in-memory session replication working and am
testing
running 3 seperate tomcat instances on the same server.
I am using tomcat-5.5.15 and apache-2.0.54 with jk2.
Whenever i run my test app although it should be doing round-
robin load
balancing it doesn't switch to another instance of tomcat until
the
eighth request and does not appear to have sent the session
information
across as the session ID changes.
Here are my server.xml and workers2.properties files
server.xml
className="org.apache.catalina.mbeans.GlobalResourcesLifecycleList
ener"
/>
className="org.apache.catalina.storeconfig.StoreConfigLifecycleLis
tener"/>
jvmRoute="Tomcat5A">
className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase"/>
managerClassName="org.apache.catalina.cluster.session.DeltaManager
"
expireSessionsOnShutdown="false"
useDirtyFlag="true"
notifyListenersOnReplication="true">
filter=".*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*
\.css;.*\.txt;"/>
className="org.apache.catalina.cluster.session.ClusterSessionListe
ner"/>
workers2.properties
[logger.apache2]
file="/etc/httpd/conf/logs/error.log"
level=INFO
debug=1
# Config settings
[config]
file=/etc/httpd/conf/workers2.properties
debug=0
# Shared memory file settings
[shm]
file=/etc/httpd/conf/jk2.shm
size=10
# Communcation channel settings for "Tomcat5A"
[channel.socket:localhost:8009]
host=localhost
port=8009
tomcatId=Tomcat5A
group=balanced
lb_factor=1
route=Tomcat5A
# Declare a Tomcat5A worker
[ajp13:localhost:8009]
channel=channel.socket:Tomcat5A
# Communcation channel settings for "Tomcat5B"
[channel.socket:localhost:8010]
host=localhost
port=8010
tomcatId=Tomcat5B
group=balanced
lb_factor=1
route=Tomcat5B
# Declare a Tomcat5B worker
[ajp13:localhost:8010]
channel=channel.socket:Tomcat5B
# Communcation channel settings for "Tomcat5C"
[channel.socket:localhost:8011]
host=localhost
port=8011
tomcatId=Tomcat5C
group=balanced
lb_factor=1
route=Tomcat5C
# Declare a Tomcat5C worker
[ajp13:localhost:8011]
channel=channel.socket:Tomcat5C
# Load balanced Worker
[lb:balanced]
worker=ajp13:localhost:8009
worker=ajp13:localhost:8010
worker=ajp13:localhost:8011
timeout=90
attempts=3
recovery
Re: Tomcat session replication/cluster
Filip Hanik - Dev Lists wrote: > if the cluster is put in the engine element, the context names are > prefixed with the engine name, since you can have multiple contexts with > the same name in different host > when reloading a context, you'll get these errors cause the context is > not available during the reload > this will be fixed with the new Apache Tribes module > Filip I understand that the context is not available during reload. After reload has completed, the error persists. My Engine name is Catalina, it looks like the cluster isn't sending the engine name, but the context name, appended to itself. You're implying that it should send Catalina+website1, but it's sending website1+website1 instead. After startup: Node1 sees Node2 send "website2" Node2 sees Node1 send "website1" After context on Node1 is finished reloading: Node1 sees Node2 send "website2" Node2 sees Node1 send "website1website1" I think that the context name is being appended to itself. > Pid wrote: >> I'm seeing an issue on 5.5.17 with a 2 node cluster config. >> When a context is reloaded, it sends the context node name incorrectly >> to the cluster. >> E.g. context is called "website1" >> >> SEVERE: Context manager doesn't exist:website1website1 >> >> The config I'm using is exactly the same as the default from server.xml, >> except the cluster is defined in Engine, rather than each Host. >> >> >> >> >> Filip Hanik - Dev Lists wrote: >> >>> also, use Tomcat 5.5.17 >>> >>> Sean O'Reilly wrote: >>> Hi, I am trying to get in-memory session replication working and am testing running 3 seperate tomcat instances on the same server. I am using tomcat-5.5.15 and apache-2.0.54 with jk2. Whenever i run my test app although it should be doing round-robin load balancing it doesn't switch to another instance of tomcat until the eighth request and does not appear to have sent the session information across as the session ID changes. Here are my server.xml and workers2.properties files server.xml >>> className="org.apache.catalina.core.AprLifecycleListener" /> >>> className="org.apache.catalina.mbeans.ServerLifecycleListener" /> >>> className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" /> >>> className="org.apache.catalina.storeconfig.StoreConfigLifecycleListener"/> >>> value="30"/> >>> 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" /> >>> redirectPort="8443" protocol="AJP/1.3" /> >>> jvmRoute="Tomcat5A"> >>> resourceName="UserDatabase"/> >>>unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false"> >>> className="org.apache.catalina.cluster.tcp.SimpleTcpCluster" managerClassName="org.apache.catalina.cluster.session.DeltaManager" expireSessionsOnShutdown="false" useDirtyFlag="true" notifyListenersOnReplication="true"> >>> className="org.apache.catalina.cluster.mcast.McastService" mcastAddr="228.0.0.4" mcastPort="45564" mcastFrequency="500" mcastDropTime="3000"/> >>> className="org.apache.catalina.cluster.tcp.ReplicationListener" tcpListenAddress="auto" tcpListenPort="4001" tcpSelectorTimeout="100" tcpThreadCount="6"/> >>> className="org.apache.catalina.cluster.tcp.ReplicationTransmitter" replicationMode="pooled" ackTimeout="15000"/> >>> className="org.apache.catalina.cluster.tcp.ReplicationValve" filter=".*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;"/> >>> className="org.apache.catalina.cluster.deploy.FarmWarDeployer" tempDir="/tmp/war-temp/" deployDir="/tmp/war-deploy/"
Re: Tomcat session replication/cluster
if the cluster is put in the engine element, the context names are prefixed with the engine name, since you can have multiple contexts with the same name in different host when reloading a context, you'll get these errors cause the context is not available during the reload this will be fixed with the new Apache Tribes module Filip Pid wrote: I'm seeing an issue on 5.5.17 with a 2 node cluster config. When a context is reloaded, it sends the context node name incorrectly to the cluster. E.g. context is called "website1" SEVERE: Context manager doesn't exist:website1website1 The config I'm using is exactly the same as the default from server.xml, except the cluster is defined in Engine, rather than each Host. Filip Hanik - Dev Lists wrote: also, use Tomcat 5.5.17 Sean O'Reilly wrote: Hi, I am trying to get in-memory session replication working and am testing running 3 seperate tomcat instances on the same server. I am using tomcat-5.5.15 and apache-2.0.54 with jk2. Whenever i run my test app although it should be doing round-robin load balancing it doesn't switch to another instance of tomcat until the eighth request and does not appear to have sent the session information across as the session ID changes. Here are my server.xml and workers2.properties files server.xml jvmRoute="Tomcat5A"> className="org.apache.catalina.cluster.tcp.SimpleTcpCluster" managerClassName="org.apache.catalina.cluster.session.DeltaManager" expireSessionsOnShutdown="false" useDirtyFlag="true" notifyListenersOnReplication="true"> className="org.apache.catalina.cluster.mcast.McastService" mcastAddr="228.0.0.4" mcastPort="45564" mcastFrequency="500" mcastDropTime="3000"/> className="org.apache.catalina.cluster.tcp.ReplicationListener" tcpListenAddress="auto" tcpListenPort="4001" tcpSelectorTimeout="100" tcpThreadCount="6"/> className="org.apache.catalina.cluster.tcp.ReplicationTransmitter" replicationMode="pooled" ackTimeout="15000"/> filter=".*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;"/> workers2.properties [logger.apache2] file="/etc/httpd/conf/logs/error.log" level=INFO debug=1 # Config settings [config] file=/etc/httpd/conf/workers2.properties debug=0 # Shared memory file settings [shm] file=/etc/httpd/conf/jk2.shm size=10 # Communcation channel settings for "Tomcat5A" [channel.socket:localhost:8009] host=localhost port=8009 tomcatId=Tomcat5A group=balanced lb_factor=1 route=Tomcat5A # Declare a Tomcat5A worker [ajp13:localhost:8009] channel=channel.socket:Tomcat5A # Communcation channel settings for "Tomcat5B" [channel.socket:localhost:8010] host=localhost port=8010 tomcatId=Tomcat5B group=balanced lb_factor=1 route=Tomcat5B # Declare a Tomcat5B worker [ajp13:localhost:8010] channel=channel.socket:Tomcat5B # Communcation channel settings for "Tomcat5C" [channel.socket:localhost:8011] host=localhost port=8011 tomcatId=Tomcat5C group=balanced lb_factor=1 route=Tomcat5C # Declare a Tomcat5C worker [ajp13:localhost:8011] channel=channel.socket:Tomcat5C # Load balanced Worker [lb:balanced] worker=ajp13:localhost:8009 worker=ajp13:localhost:8010 worker=ajp13:localhost:8011 timeout=90 attempts=3 recovery=30 stickySession=0 noWorkerMsg=Server Busy please retry later. noWorkerCodeMsg=503 # URI mappings for the tomcat worker # Map the "jsp-examples" web application context to the web server URI space [uri:/jsp-examples/*] info= Mapping for jsp-examples context for tomcat context=/jsp-examples group=balanced [shm] file=/etc/httpd/conf/jk2.shm size=100 [uri:/servlets-examples/*] context=/servlets-examples group=balanced # Define a status worker [status:] # Status URI mapping [uri:/jkstatus/*] group=status obviously the server.xml files on the other 2 instances of tomcat are the same except the ports and jvmRoute have been changed. can anyone see where i am going wrong ? Thanks - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Filip Hanik ---
