Re: Tomcat session replication

2020-07-01 Thread Thomas Meyer
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

2020-07-01 Thread 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

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Tomcat session replication

2020-07-01 Thread Thomas Meyer
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

2020-06-30 Thread 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".

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Tomcat session replication

2020-06-29 Thread Thomas Meyer
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

2020-06-29 Thread Christopher Schultz
-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

Re: Tomcat session replication

2020-06-29 Thread Christopher Schultz
-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

2020-06-27 Thread Thomas Meyer
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

2020-06-27 Thread 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);
- 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

2013-09-05 Thread Willem Fibbe - Realworks BV
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

2011-11-17 Thread Christopher Schultz
-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

2011-11-16 Thread Christopher Schultz
-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 and domain change

2011-11-16 Thread Leon Rosenberg
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 problem

2008-03-20 Thread Mc210274

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

2008-03-12 Thread Vreixo Formoso
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 --
 
  Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster
   channelSendOptions=4
 
Manager
  className=org.apache.catalina.ha.session.DeltaManager
 expireSessionsOnShutdown=false
 notifyListenersOnReplication=true/
 
Channel
  className=org.apache.catalina.tribes.group.GroupChannel
  Membership
  className=org.apache.catalina.tribes.membership.McastService
  address=228.0.0.4
  port=45564
  frequency=500
  dropTime=3000/
  Receiver
  className=org.apache.catalina.tribes.transport.nio.NioReceiver
address=auto
port=4002
autoBind=100
selectorTimeout=5000
maxThreads=6/
 
  Sender
  className=org.apache.catalina.tribes.transport.ReplicationTransmitter
Transport
  className=org.apache.catalina.tribes.transport.nio.PooledParallelSender/
  /Sender
  Interceptor
  className=org.apache.catalina.tribes.group.interceptors.TcpFailureDetector/
  Interceptor
  className=org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor/
/Channel
 
Valve className=org.apache.catalina.ha.tcp.ReplicationValve
   filter=/
Valve
  className=org.apache.catalina.ha.session.JvmRouteBinderValve/
 
Deployer
  className=org.apache.catalina.ha.deploy.FarmWarDeployer
  tempDir=/tmp/war-temp/
  deployDir=/tmp/war-deploy/
  watchDir=/tmp/war-listen/
  watchEnabled=false/
 
ClusterListener
  className=org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener/
ClusterListener
  className=org.apache.catalina.ha.session.ClusterSessionListener/
  /Cluster
 
 
 
 
 
 
 
  -
  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

2008-03-11 Thread Filip Hanik - Dev Lists
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 --

Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster
 channelSendOptions=4

  Manager
className=org.apache.catalina.ha.session.DeltaManager
   expireSessionsOnShutdown=false
   notifyListenersOnReplication=true/

  Channel
className=org.apache.catalina.tribes.group.GroupChannel
Membership
className=org.apache.catalina.tribes.membership.McastService
address=228.0.0.4
port=45564
frequency=500
dropTime=3000/
Receiver
className=org.apache.catalina.tribes.transport.nio.NioReceiver
  address=auto
  port=4002
  autoBind=100
  selectorTimeout=5000
  maxThreads=6/

Sender
className=org.apache.catalina.tribes.transport.ReplicationTransmitter
  Transport
className=org.apache.catalina.tribes.transport.nio.PooledParallelSender/
/Sender
Interceptor
className=org.apache.catalina.tribes.group.interceptors.TcpFailureDetector/
Interceptor
className=org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor/
  /Channel

  Valve className=org.apache.catalina.ha.tcp.ReplicationValve
 filter=/
  Valve
className=org.apache.catalina.ha.session.JvmRouteBinderValve/

  Deployer
className=org.apache.catalina.ha.deploy.FarmWarDeployer
tempDir=/tmp/war-temp/
deployDir=/tmp/war-deploy/
watchDir=/tmp/war-listen/
watchEnabled=false/

  ClusterListener
className=org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener/
  ClusterListener
className=org.apache.catalina.ha.session.ClusterSessionListener/
/Cluster







-
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)

2007-08-28 Thread Filip Hanik - Dev Lists

[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)

2006-06-26 Thread Sean O'Reilly
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
 
 Proxy balancer://mycluster
BalancerMember ajp://tomcat1:8009 smax=10 loadfactor=10 route=TCS1
BalancerMember ajp://tomcat2:8009 smax=10 loadfactor=10 route=TCS2
 /Proxy
 
 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)

Cluster className=org.apache.catalina.cluster.tcp.SimpleTcpCluster
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/

Valve className=org.apache.catalina.cluster.tcp.ReplicationValve
   
filter=.*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;/
###
connector.conf

ReWriteEngine   On
ProxyPreserveHost   On
ProxyRequests   Off
ProxyViaOff

Proxy balancer://secpay_cluster
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
/proxy

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 

Re: Tomcat session replication/cluster (mod_proxy_ajp)

2006-06-26 Thread Pid
(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.


Cluster className=org.apache.catalina.cluster.tcp.SimpleTcpCluster

managerClassName=org.apache.catalina.cluster.session.DeltaManager
 clusterName=ServerCluster01
 expireSessionsOnShutdown=false
 useDirtyFlag=true
 notifyListenersOnReplication=true
Membership
className=org.apache.catalina.cluster.mcast.McastService
mcastAddr=228.0.0.4
mcastPort=45564
mcastFrequency=500
mcastDropTime=3000/
Receiver

className=org.apache.catalina.cluster.tcp.ReplicationListener
tcpListenAddress=000.000.000.000
tcpListenPort=4001
tcpSelectorTimeout=100
tcpThreadCount=6/
Sender

className=org.apache.catalina.cluster.tcp.ReplicationTransmitter
replicationMode=pooled
autoConnect=true
ackTimeout=15000
waitForAck=true/

Valve className=org.apache.catalina.cluster.tcp.ReplicationValve
filter=.*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;/

Valve
className=org.apache.catalina.cluster.session.JvmRouteBinderValve
enabled=true/
ClusterListener
className=org.apache.catalina.cluster.session.JvmRouteSessionIDBinderListener/
ClusterListener
className=org.apache.catalina.cluster.session.ClusterSessionListener /

/Cluster



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

 Proxy balancer://mycluster
BalancerMember ajp://tomcat1:8009 smax=10 loadfactor=10 route=TCS1
BalancerMember ajp://tomcat2:8009 smax=10 loadfactor=10 route=TCS2
 /Proxy

 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)
 
 Cluster className=org.apache.catalina.cluster.tcp.SimpleTcpCluster
 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/
 
 Valve className=org.apache.catalina.cluster.tcp.ReplicationValve

 filter=.*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;/
 ###
 connector.conf
 
 ReWriteEngine   On
 ProxyPreserveHost   On
 ProxyRequests   Off
 ProxyViaOff
 
 Proxy balancer://secpay_cluster
 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
 /proxy
 
 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/* 

Re: Tomcat session replication/cluster (mod_proxy_ajp)

2006-06-26 Thread Pid


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)

2006-06-26 Thread Sean O'Reilly
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.init(Socket.java:365) at
java.net.Socket.init(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)

2006-06-26 Thread Pid
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.init(Socket.java:365) at
 java.net.Socket.init(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

2006-06-23 Thread Sean O'Reilly
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
 
  Server port=8005 shutdown=SHUTDOWN
 
!-- Comment these entries out to disable JMX MBeans support
  used for
  theadministration web application --
Listener
  className=org.apache.catalina.core.AprLifecycleListener /
Listener
  className=org.apache.catalina.mbeans.ServerLifecycleListener /
Listener
  className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener
 
  /
Listener
  className=org.apache.catalina.storeconfig.StoreConfigLifecycleListener/
 
 
 
 
!-- Global JNDI resources --
GlobalNamingResources
 
  !-- Test entry for demonstration purposes --
  Environment name=simpleValue 

Re: Tomcat session replication/cluster

2006-06-23 Thread Filip Hanik - Dev Lists



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

2006-06-23 Thread Sean O'Reilly
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

2006-06-23 Thread Filip Hanik - Dev Lists

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

2006-06-23 Thread Sean O'Reilly
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

2006-06-23 Thread Filip Hanik - Dev Lists

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

2006-06-23 Thread Pid
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 (mod_proxy_ajp)

2006-06-23 Thread Pid


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

Proxy balancer://mycluster
   BalancerMember ajp://tomcat1:8009 smax=10 loadfactor=10 route=TCS1
   BalancerMember ajp://tomcat2:8009 smax=10 loadfactor=10 route=TCS2
/Proxy

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

2006-06-22 Thread 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

 Server port=8005 shutdown=SHUTDOWN

   !-- Comment these entries out to disable JMX MBeans support used for
 theadministration web application --
   Listener
 className=org.apache.catalina.core.AprLifecycleListener /
   Listener
 className=org.apache.catalina.mbeans.ServerLifecycleListener /
   Listener
 className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener
 /
   Listener
 className=org.apache.catalina.storeconfig.StoreConfigLifecycleListener/



   !-- Global JNDI resources --
   GlobalNamingResources

 !-- Test entry for demonstration purposes --
 Environment name=simpleValue type=java.lang.Integer
 value=30/

 !-- Editable user database that can also be used by
  UserDatabaseRealm to authenticate users --
 Resource name=UserDatabase auth=Container
   type=org.apache.catalina.UserDatabase
description=User database that can be updated and saved
   
 factory=org.apache.catalina.users.MemoryUserDatabaseFactory
   pathname=conf/tomcat-users.xml /

   /GlobalNamingResources

   !-- A Service is a collection of one or more Connectors that
 share
a single Container (and therefore the web applications visible
within that Container).  Normally, that Container is an
 Engine,
but this is not required.

Note:  A Service is not itself a Container, so you may not
define subcomponents such as Valves or Loggers at this
 level.
--

   !-- Define the Tomcat Stand-Alone Service --
   Service name=Catalina

 !-- A Connector represents an endpoint by which requests are
 received
  and responses are returned.  Each Connector passes requests on
 to the
  associated Container (normally an Engine) for processing.

  By default, a non-SSL HTTP/1.1 Connector is established on
 port 8080.
  You can also enable an SSL HTTP/1.1 Connector on port 8443 by
  following the instructions below and uncommenting the second
 Connector
  entry.  SSL support requires the following steps (see the SSL
 Config
  HOWTO in the Tomcat 5 documentation bundle for more detailed
  instructions):
  * If your JDK version 1.3 or prior, download and install JSSE
 1.0.2 or
later, and put the JAR files into $JAVA_HOME/jre/lib/ext.
  * Execute:
  %JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA
 (Windows)
  $JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA
 (Unix)
with a password value of changeit for both the certificate
 and
the keystore itself.

  By default, DNS lookups are enabled when a web application
 calls
  request.getRemoteHost().  This can have an adverse impact on
  performance, so you can disable it by setting the
  enableLookups attribute to false.  When DNS lookups are
 disabled,
  request.getRemoteHost() will return the String version of the
  IP address of the remote client.
 --

  

Re: Tomcat session replication/cluster

2006-06-22 Thread Pid
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

 Server port=8005 shutdown=SHUTDOWN

   !-- Comment these entries out to disable JMX MBeans support
 used for
 theadministration web application --
   Listener
 className=org.apache.catalina.core.AprLifecycleListener /
   Listener
 className=org.apache.catalina.mbeans.ServerLifecycleListener /
   Listener
 className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener

 /
   Listener
 className=org.apache.catalina.storeconfig.StoreConfigLifecycleListener/




   !-- Global JNDI resources --
   GlobalNamingResources

 !-- Test entry for demonstration purposes --
 Environment name=simpleValue type=java.lang.Integer
 value=30/

 !-- Editable user database that can also be used by
  UserDatabaseRealm to authenticate users --
 Resource name=UserDatabase auth=Container
   type=org.apache.catalina.UserDatabase
description=User database that can be updated and saved

 factory=org.apache.catalina.users.MemoryUserDatabaseFactory
   pathname=conf/tomcat-users.xml /

   /GlobalNamingResources

   !-- A Service is a collection of one or more Connectors that
 share
a single Container (and therefore the web applications
 visible
within that Container).  Normally, that Container is an
 Engine,
but this is not required.

   

Re: Tomcat session replication/cluster

2006-06-22 Thread Filip Hanik - Dev Lists

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

Server port=8005 shutdown=SHUTDOWN

  !-- Comment these entries out to disable JMX MBeans support
used for
theadministration web application --
  Listener
className=org.apache.catalina.core.AprLifecycleListener /
  Listener
className=org.apache.catalina.mbeans.ServerLifecycleListener /
  Listener
className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener

/
  Listener
className=org.apache.catalina.storeconfig.StoreConfigLifecycleListener/




  !-- Global JNDI resources --
  GlobalNamingResources

!-- Test entry for demonstration purposes --
Environment name=simpleValue type=java.lang.Integer
value=30/

!-- Editable user database that can also be used by
 UserDatabaseRealm to authenticate users --
Resource name=UserDatabase auth=Container
  type=org.apache.catalina.UserDatabase
   description=User database that can be updated and saved

factory=org.apache.catalina.users.MemoryUserDatabaseFactory
  pathname=conf/tomcat-users.xml /

  /GlobalNamingResources

  !-- A Service is a collection of one or more Connectors that
share
   a single Container (and therefore the web applications
visible
   within that 

Re: Tomcat session replication/cluster

2006-06-21 Thread Filip Hanik - Dev Lists
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

Server port=8005 shutdown=SHUTDOWN

  !-- Comment these entries out to disable JMX MBeans support used for
theadministration web application --
  Listener className=org.apache.catalina.core.AprLifecycleListener /
  Listener
className=org.apache.catalina.mbeans.ServerLifecycleListener /
  Listener
className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener
/
  Listener
className=org.apache.catalina.storeconfig.StoreConfigLifecycleListener/


  !-- Global JNDI resources --
  GlobalNamingResources

!-- Test entry for demonstration purposes --
Environment name=simpleValue type=java.lang.Integer
value=30/

!-- Editable user database that can also be used by
 UserDatabaseRealm to authenticate users --
Resource name=UserDatabase auth=Container
  type=org.apache.catalina.UserDatabase
   description=User database that can be updated and saved
   factory=org.apache.catalina.users.MemoryUserDatabaseFactory
  pathname=conf/tomcat-users.xml /

  /GlobalNamingResources

  !-- A Service is a collection of one or more Connectors that
share
   a single Container (and therefore the web applications visible
   within that Container).  Normally, that Container is an Engine,
   but this is not required.

   Note:  A Service is not itself a Container, so you may not
   define subcomponents such as Valves or Loggers at this level.
   --

  !-- Define the Tomcat Stand-Alone Service --
  Service name=Catalina

!-- A Connector represents an endpoint by which requests are
received
 and responses are returned.  Each Connector passes requests on
to the
 associated Container (normally an Engine) for processing.

 By default, a non-SSL HTTP/1.1 Connector is established on
port 8080.
 You can also enable an SSL HTTP/1.1 Connector on port 8443 by
 following the instructions below and uncommenting the second
Connector
 entry.  SSL support requires the following steps (see the SSL
Config
 HOWTO in the Tomcat 5 documentation bundle for more detailed
 instructions):
 * If your JDK version 1.3 or prior, download and install JSSE
1.0.2 or
   later, and put the JAR files into $JAVA_HOME/jre/lib/ext.
 * Execute:
 %JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA
(Windows)
 $JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA
(Unix)
   with a password value of changeit for both the certificate
and
   the keystore itself.

 By default, DNS lookups are enabled when a web application
calls
 request.getRemoteHost().  This can have an adverse impact on
 performance, so you can disable it by setting the
 enableLookups attribute to false.  When DNS lookups are
disabled,
 request.getRemoteHost() will return the String version of the
 IP address of the remote client.
--

!-- Define a non-SSL HTTP/1.1 Connector on port 8080
Connector port=8080 maxHttpHeaderSize=8192
   maxThreads=150 minSpareThreads=25
maxSpareThreads=75
   enableLookups=false redirectPort=8443
acceptCount=100
   connectionTimeout=2 disableUploadTimeout=true /
--
!-- Note : To disable connection timeouts, set connectionTimeout
value
 to 0 --

!-- Note : To use gzip compression you could set the following

properties :

   compression=on   
compressionMinSize=2048   
noCompressionUserAgents=gozilla, traviata   
compressableMimeType=text/html,text/xml

--

!-- Define a SSL HTTP/1.1 Connector on