Re: Session replication will never happen after disabling session persistence across Tomcat restarts

[sanigo]

Yes, I think if uncommented the

 

The ClustedManage could be disabled even if  is defined.

在 16/4/25 下午12:57, Keiichi Fujino 写道:

2016-04-23 15:29 GMT+09:00 sanigo :


Hi!
I have tested quite a few times to confirm that session replication
will not happen after uncommenting  in
conf/context.xml.
If the line is commented out, the session replication will work
happily.


Is there a warning message to your log files?
such as [Manager [xxx] does not implement ClusterManager, addition to
cluster has been aborted.]

if you have uncommented  in conf/context.xml,
All of the Web applications on your Tomcat use the StandardManager as a
session manager.
The StandardManager cannot replicate session.
If you want to replicate session, you have to use
ClusteManager(DeltaManager/BackupManager) as a session manager.
Usually defines a cluster manager template in the  / ,
and then it is cloned by distributable web application.





The versions I have tested are 7.0.68 and 7.0.69.
Any ideas?
san...@gmail.com

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

--
Keiichi.Fujino







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

Re: Session replication will never happen after disabling session persistence across Tomcat restarts

[Keiichi Fujino]

2016-04-23 15:29 GMT+09:00 sanigo :

> Hi!
>I have tested quite a few times to confirm that session replication
> will not happen after uncommenting  in
> conf/context.xml.
>If the line is commented out, the session replication will work
> happily.
>

Is there a warning message to your log files?
such as [Manager [xxx] does not implement ClusterManager, addition to
cluster has been aborted.]

if you have uncommented  in conf/context.xml,
All of the Web applications on your Tomcat use the StandardManager as a
session manager.
The StandardManager cannot replicate session.
If you want to replicate session, you have to use
ClusteManager(DeltaManager/BackupManager) as a session manager.
Usually defines a cluster manager template in the  / ,
and then it is cloned by distributable web application.




>The versions I have tested are 7.0.68 and 7.0.69.
>Any ideas?
> san...@gmail.com
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
> --
> Keiichi.Fujino
> 

Re: Session replication/fail-over for medium sized tomcat farm

[Daniel Mikusa]

On Fri, Jul 3, 2015 at 9:17 AM, Charles Richard 
charle...@thelearningbar.com wrote:

 On Fri, Jul 3, 2015 at 9:58 AM, Daniel Mikusa dmik...@pivotal.io wrote:

  On Fri, Jul 3, 2015 at 8:36 AM, Charles Richard 
  charle...@thelearningbar.com wrote:
 
   Hi,
  
   We are currently using a product called Terracotta to do session
   fail-over/replication but are considering moving away from this product
  as
   it doesn't seem to support Java 7 and Tomcat 7.
  
   What products exist out there that would help with session
   fail-over/replication?  I only know of 3:
  
   - Terracotta
   - Hazelcast
   - Tomcat native session failover (is not recommended for many tomcat
  nodes)
  
 
  I think that recommendation is just for the DeltaManager.  You can use
 the
  BackupManager with larger numbers of nodes since it's not replicating
  session data to all of the nodes in the cluster.
 
  http://tomcat.apache.org/tomcat-7.0-doc/config/cluster-manager.html
 
  In addition to that Redis and Memcached are two popular ways of sharing
  session state.
 
  Dan
 
   In the link you sent, it mentions the following:

 Downside of the BackupManager: not quite as battle tested as the delta
 manager. 


Naturally this statement makes sense because DeltaManager is the default.
More people are going to use it.  BackupManager has been around for quite a
while though.  Looking at SVN, it's been almost 9 years.  I'd say that
gives it a certain amount of credibility.

http://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/java/org/apache/catalina/ha/session/BackupManager.java?revision=433703view=markup


 Are you aware of companies using this for their Tomcat farms?


I have worked with multiple customers using it in production.  Not as
common as DeltaManager, but it's being used.

Dan




 Thanks,
 Charles

 
  
   I want to make sure i know all options before making a decision.
  
   Thanks,
   Charles
  
 

Re: Session replication/fail-over for medium sized tomcat farm

[Charles Richard]

On Fri, Jul 3, 2015 at 9:58 AM, Daniel Mikusa dmik...@pivotal.io wrote:

 On Fri, Jul 3, 2015 at 8:36 AM, Charles Richard 
 charle...@thelearningbar.com wrote:

  Hi,
 
  We are currently using a product called Terracotta to do session
  fail-over/replication but are considering moving away from this product
 as
  it doesn't seem to support Java 7 and Tomcat 7.
 
  What products exist out there that would help with session
  fail-over/replication?  I only know of 3:
 
  - Terracotta
  - Hazelcast
  - Tomcat native session failover (is not recommended for many tomcat
 nodes)
 

 I think that recommendation is just for the DeltaManager.  You can use the
 BackupManager with larger numbers of nodes since it's not replicating
 session data to all of the nodes in the cluster.

 http://tomcat.apache.org/tomcat-7.0-doc/config/cluster-manager.html

 In addition to that Redis and Memcached are two popular ways of sharing
 session state.

 Dan

  In the link you sent, it mentions the following:

Downside of the BackupManager: not quite as battle tested as the delta
manager. 

Are you aware of companies using this for their Tomcat farms?

Thanks,
Charles


 
  I want to make sure i know all options before making a decision.
 
  Thanks,
  Charles
 

Re: Session replication/fail-over for medium sized tomcat farm

[Daniel Mikusa]

On Fri, Jul 3, 2015 at 8:36 AM, Charles Richard 
charle...@thelearningbar.com wrote:

 Hi,

 We are currently using a product called Terracotta to do session
 fail-over/replication but are considering moving away from this product as
 it doesn't seem to support Java 7 and Tomcat 7.

 What products exist out there that would help with session
 fail-over/replication?  I only know of 3:

 - Terracotta
 - Hazelcast
 - Tomcat native session failover (is not recommended for many tomcat nodes)


I think that recommendation is just for the DeltaManager.  You can use the
BackupManager with larger numbers of nodes since it's not replicating
session data to all of the nodes in the cluster.

http://tomcat.apache.org/tomcat-7.0-doc/config/cluster-manager.html

In addition to that Redis and Memcached are two popular ways of sharing
session state.

Dan



 I want to make sure i know all options before making a decision.

 Thanks,
 Charles

Re: Session Replication across common base domain

[Sanket Paranjape]

Hi Guys,

Any solution for this??

On 03-01-2014 02:31 PM, Sanket Paranjape wrote:

Hi,

I am using Tomcat 7.0.47 on windows 7 with JDK 1.7.

I want to achieve session replications on multiple subdomains. If I 
have a domain as xyz.example.com and abc.example.com, then I would 
like to store session cookie on example.com and hence then I would 
be able to access same session on both domains. By default session 
cookie is set on whole domain, if I access xyz.example.com then 
session cookie will be set on this domain.


I went through the documentation for Tomcat 7 and found that in 
Context element type I can add attribute like sessionCookieDomain. 
I can easily set this attribute to base domain like .example.com and 
this works like charm.


But my requirement is slightly different. I have single tomcat serving 
multiple domains. They all different base domains as well. So 
hardcoding would not help me out here.


So I tried following.

In docs I found this link, 
http://tomcat.apache.org/tomcat-7.0-doc/config/context.html. It says 
that className attribute can be set for context.
So I wrote my own class MyStandardContext which extends 
org.apache.catalina.core.StandardContext. I overridden public String 
getSessionCookieDomain() method. I want to return base domain of the 
URL from this domain so that tomcat will set cookie on this domain. 
But to my surprise I do not have access to Request URI. If I could get 
access to this URI somehow then I would be able to extract base 
domain. It is not possible. is it?


I also tried adding multiple hosts in conf/server.xml under Engine. 
This loads context multiple times, which I do not wish.


My question is there any way I can get access to request URI in 
MyStandardContext? Or is there any configuration which forces tomcat 
to set cookie on base domain instead full domain?



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

Re: Session replication configuration file question

[Nir A]

Hi Daniel,
At last we managed to solve the replication issue. (not exactly a solution
but a workaround) :

the problem was:

The multicast tried to broadcast to local ip written in the hosts file
127.0.1.1
We had to write the actual ip adress in the hosts file

instead :

127.0.1.1 - Tomcat1

we changed to

tomcat1_ip_adress - Tomcat1


and the same on the tomcat 2 machine.

now it works.

thanks for your efforts.




On Sun, Dec 29, 2013 at 8:43 PM, Daniel Mikusa dmik...@gopivotal.comwrote:

 On Dec 29, 2013, at 10:51 AM, Nir A n...@netomedia.com wrote:

  Hi,
 
  If i want to create a cluster of 2 tomcats:
 
  Tomcat1 - ip 111.111.111.111
  Tomcat2 - ip 222.222.222.222
 
 
  Where exactly the in the server.xml i should say that my cluster contains
  both of these ips?

 By default, you don't.  If you'd rather do that, you can though.  See my
 previous email to you regarding StaticMember configuration.

  If you will take alook at my server.xml (which i copy pasted from the
  tutorial) it looks like this:
 
  ?xml version='1.0' encoding='utf-8'?
 
  Server port=8105 shutdown=SHUTDOWN
 
   Listener className=org.apache.catalina.core.AprLifecycleListener
  SSLEngine=on /
 
   Listener className=org.apache.catalina.core.JasperListener /
 
   Listener
  className=org.apache.catalina.core.JreMemoryLeakPreventionListener /
   Listener
  className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener
 /
   Listener
  className=org.apache.catalina.core.ThreadLocalLeakPreventionListener /
 
   GlobalNamingResources
 
 Resource name=UserDatabase auth=Container
   type=org.apache.catalina.UserDatabase
   description=User database that can be updated and saved
 
  factory=org.apache.catalina.users.MemoryUserDatabaseFactory
   pathname=conf/tomcat-users.xml /
   /GlobalNamingResources
 
 
   Service name=Catalina
 
 
 Connector port=8080 protocol=HTTP/1.1
connectionTimeout=2
redirectPort=8443 /
 
 Connector port=8109 protocol=AJP/1.3 redirectPort=8443 /
 
 
 Engine name=Catalina defaultHost=localhost
  Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster
   Manager className=org.apache.catalina.ha.session.BackupManager
expireSessionsOnShutdown=false
notifyListenersOnReplication=true
mapSendOptions=6/
  /Cluster
 
   Realm className=org.apache.catalina.realm.LockOutRealm
 Realm className=org.apache.catalina.realm.UserDatabaseRealm
resourceName=UserDatabase/
   /Realm
 
   Host name=localhost  appBase=webapps
 unpackWARs=true autoDeploy=true
 
 Valve className=org.apache.catalina.valves.AccessLogValve
  directory=logs
prefix=localhost_access_log. suffix=.txt
pattern=%h %l %u %t quot;%rquot; %s %b /
 
   /Host
 /Engine
   /Service
  /Server
 
  Again, It doesn't make sense to me that this configuration will work
 since
  the ips (111.111.111.111 , and 222.222.222.222) are not in it.

 The Cluster tag adds some default options for you.  See this link for more
 on the defaults.


 http://tomcat.apache.org/tomcat-7.0-doc/cluster-howto.html#For_the_impatient

 Specifically look at the Membership / tag which defines the multicast
 service.  This is how instances find each other by default.

  Where exactly should i define them?

 Again, see my other note regarding StaticMember configuration.

 Dan

 
  Thanks


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

Re: Session replication does not work - Continued

[Daniel Mikusa]

On Dec 29, 2013, at 10:11 AM, Nir A n...@netomedia.com wrote:

 Hi,
 So we have 3 tomcats in our cluster and we are failing to make them
 replicate our sessions still.
 
 Our IT guy said it might has something to do with the machines of the
 tomcats.
 
 He said that since the machines the tomcats in the cluster are installed at
 are Virtual machines there might be a problem on the multicast of the
 replication messages.
 
 1) Is it possible that our IT guy is right? (We love you Leon)

By default, clustering support uses multicast to locate other Tomcat instances. 
 If multicast does not work or is disabled on your instances won't be able to 
locate each other.

Multicast is only used for locating other nodes, it is not used for the 
transmission of session data.  TCP is used for that.

 2) Is there any alternative to multicast the session data between the
 tomcats?

Yes.  See static members configuration.

  
http://tomcat.apache.org/tomcat-7.0-doc/config/cluster-interceptor.html#Static_Membership
  
http://tomcat.apache.org/tomcat-7.0-doc/config/cluster-interceptor.html#Nested_element_StaticMember_Attributes

Dan

 
 
 Thanks!


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

Re: Session replication configuration file question

[Daniel Mikusa]

On Dec 29, 2013, at 10:51 AM, Nir A n...@netomedia.com wrote:

 Hi,
 
 If i want to create a cluster of 2 tomcats:
 
 Tomcat1 - ip 111.111.111.111
 Tomcat2 - ip 222.222.222.222
 
 
 Where exactly the in the server.xml i should say that my cluster contains
 both of these ips?

By default, you don't.  If you'd rather do that, you can though.  See my 
previous email to you regarding StaticMember configuration.

 If you will take alook at my server.xml (which i copy pasted from the
 tutorial) it looks like this:
 
 ?xml version='1.0' encoding='utf-8'?
 
 Server port=8105 shutdown=SHUTDOWN
 
  Listener className=org.apache.catalina.core.AprLifecycleListener
 SSLEngine=on /
 
  Listener className=org.apache.catalina.core.JasperListener /
 
  Listener
 className=org.apache.catalina.core.JreMemoryLeakPreventionListener /
  Listener
 className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener /
  Listener
 className=org.apache.catalina.core.ThreadLocalLeakPreventionListener /
 
  GlobalNamingResources
 
Resource name=UserDatabase auth=Container
  type=org.apache.catalina.UserDatabase
  description=User database that can be updated and saved
  factory=org.apache.catalina.users.MemoryUserDatabaseFactory
  pathname=conf/tomcat-users.xml /
  /GlobalNamingResources
 
 
  Service name=Catalina
 
 
Connector port=8080 protocol=HTTP/1.1
   connectionTimeout=2
   redirectPort=8443 /
 
Connector port=8109 protocol=AJP/1.3 redirectPort=8443 /
 
 
Engine name=Catalina defaultHost=localhost
 Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster
  Manager className=org.apache.catalina.ha.session.BackupManager
   expireSessionsOnShutdown=false
   notifyListenersOnReplication=true
   mapSendOptions=6/
 /Cluster
 
  Realm className=org.apache.catalina.realm.LockOutRealm
Realm className=org.apache.catalina.realm.UserDatabaseRealm
   resourceName=UserDatabase/
  /Realm
 
  Host name=localhost  appBase=webapps
unpackWARs=true autoDeploy=true
 
Valve className=org.apache.catalina.valves.AccessLogValve
 directory=logs
   prefix=localhost_access_log. suffix=.txt
   pattern=%h %l %u %t quot;%rquot; %s %b /
 
  /Host
/Engine
  /Service
 /Server
 
 Again, It doesn't make sense to me that this configuration will work since
 the ips (111.111.111.111 , and 222.222.222.222) are not in it.

The Cluster tag adds some default options for you.  See this link for more on 
the defaults.

  http://tomcat.apache.org/tomcat-7.0-doc/cluster-howto.html#For_the_impatient

Specifically look at the Membership / tag which defines the multicast 
service.  This is how instances find each other by default.

 Where exactly should i define them?

Again, see my other note regarding StaticMember configuration.

Dan

 
 Thanks


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

Re: session replication issue

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dhaval,

On 12/9/13, 3:04 PM, Dhaval Jaiswal wrote:
 setting of session replication worked well. However, we do have
 threading in some products. Like we are hitting the target API and
 getting response from there servers. If will not get the response
 will hit them after some time and in this case threading not
 handled by session replication because of session timeout and shows
 below errors.

Can you explain this with a little more detail?

 After some time the server starts getting high load.

The high-load is caused by greater client load, or because of the
replication re-tried, etc.?

- -chris

 SEVERE: Unable to replicate backup key: 
 AE8095AB32A4DCA0AFD7117F6F32210C.t7 to 
 backup:org.apache.catalina.tribes.membership.MemberImpl[tcp://{-64,
 -88, 3, 12}:4001,{-64, -88, 3, 12},4001, alive=30639540,id={77 33
 -17 95 -79 -80 79 2 -104 -102 -73 29 -100 39 -59 -111 },
 payload={}, command={}, domain={}, ]. Reason:Operation has timed
 out(6 ms.).; Faulty members:tcp://{-64, -88, 3, 12}:4001; 
 org.apache.catalina.tribes.ChannelException: Operation has timed
 out(6 ms.).; Faulty members:tcp://{-64, -88, 3, 12}:4001;
 
 How can i address above issue or just by increasing time out value.
 Please explain me.
 
 
 
 
 
 server.xml for session replicaiton.
 
 
 Manager className=org.apache.catalina.ha.session.BackupManager 
 expireSessionsOnShutdown=false 
 notifyListenersOnReplication=true mapSendOptions=6/ Channel 
 className=org.apache.catalina.tribes.group.GroupChannel 
 Membership 
 className=org.apache.catalina.tribes.membership.McastService 
 address=228.0.0.4 port=45565 frequency=500 
 dropTime=3/ Receiver 
 className=org.apache.catalina.tribes.transport.nio.NioReceiver 
 address=auto port=5000 selectorTimeout=5000 timeout=6 
 maxThreads=6/ Sender 
 className=org.apache.catalina.tribes.transport.ReplicationTransmitter

 
Transport
 className=org.apache.catalina.tribes.transport.nio.PooledParallelSender

 
timeout=6 keepAliveCount=0/
 /Sender Interceptor 
 className=org.apache.catalina.tribes.group.interceptors.TcpFailureDetector/

 
Interceptor
 className=org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor/

 
Interceptor
 className=org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor/

  /Channel Valve
 className=org.apache.catalina.ha.tcp.ReplicationValve
 
 filter=.*\.gif|.*\.js|.*\.jpeg|.*\.jpg|.*\.png|.*\.htm|.*\.html|.*\.css|.*\.txt/

 
Valve
 className=org.apache.catalina.ha.session.JvmRouteBinderValve/ 
 ClusterListener 
 className=org.apache.catalina.ha.session.ClusterSessionListener/

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSpjxUAAoJEBzwKT+lPKRYVGUQAKHEP5oRUq8SDKYzOSGMjdAd
cOt/L3Y5PbhB+m6RTmXYlhBvBFGUsIy1xfRhSbiUOVSaHAxVcWI96T0larG3YjYW
KkRVjzHKg96xe5FRQzRnJxp3tYqS8F+5LSnOvE9RpbOslC162qNy08cRp/nS5aQA
2JzlnZ6wuhRq80tjEb3chHWh5yPyHulcN4z8htNS/lwsIe3gyiPCErQUI6Grg1cO
d6NZEEsjYFksNkzbtteyGZbjzfztIvsIdWsK25AUA91Hqh3J7GRYbEm0ha48KVgV
f/aKVLOb1viZeZVCcGB79DhlOsOXJVwu854Qw6oaxi9VsSEb10W5SDpzqZKvRP11
To+7oI5xwdnJ+T5sw46Y0qTMqLI63ZzaeyaZlDqoc/K/RaBciqKomWXDVMpm2Vbm
9LC+QVDl5GY92sc2guEHmkGWqXL/csPSkAW2+Q9D0umcFgD/BRTDIiO4gvMXz7BD
qRFlnQuEU+zi03etHSw4eNL5BPE+3tX+MrnEideoxR4FeXfKP6FTm3yf7Zj9Pna3
Qod8QIhYacyJhxdwMSwx5qLvttfKuswV3DPx4GXxyWQzx94G+yCM6GGW5GyRHtzm
82wVT6bsTBhQ7fA73h8FofIUCpPmtl/ntN1RWjm3StcuNdGDZWOrdylqG2hHFwrk
L7T83sVpEg16Y5ypEslH
=RKD5
-END PGP SIGNATURE-

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

Re: session-replication fails on restart or kill

[Mark Thomas]

On 27/08/2013 23:02, Tomcat Random wrote:
 NP, glad to contribute a little. The FAQ was helpful but it's a little
 confusing. I'd like to clean it up and add to the part that specifically
 addresses two boxes two nodes on Linux. Would that be alright?

Sure. You'll need to create an account on the wiki and then let us know
(replying here is fine) the account name so you can be added to list of
contributors - that will enable you to edit stuff. This extra step is
necessary to avoid the spam that was created when anyone with an account
was allowed to edit the wiki.

Mark

 
 Thanks,
 Alec
 
 
 On Tue, Aug 27, 2013 at 5:52 PM, Mark Thomas ma...@apache.org wrote:
 
 On 27/08/2013 22:41, Tomcat Random wrote:
 In a great moment of DUH, I realized I had the expireSessionsOnShutdown
 to
 true.

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

 All working nicely now.

 Thanks for posting the solution. It makes the archives much more useful
 for the next person that finds themselves facing the same issue.

 Mark





 On Tue, Aug 27, 2013 at 12:27 PM, Tomcat Random tomcat.ran...@gmail.com
 wrote:

 Tomcat 7.0.42 / RHEL 6 / Two physical servers, with one tomcat instance
 on
 each server. Physical loadbalancer with sticky sessions. No proxy
 servers.

 I've set up session-replication using the delta-manager. I can confirm
 it
 works just lovely when the LB switches over from one box to the other.
 Using a test get/set session value servlet, the manager app reports the
 primary session value on the box where it was set, and the identical
 backup
 value on the other box. So everything appears good there.

 The problem is if, as a crash test, I stop/restart or kill the tomcat
 service on the box with the primary session: the backup session on the
 other box gets removed. So, as you'd imagine, when the LB swaps to the
 non-dead server the session value is gone. Not so good there.

 Shouldn't the backup session value remain? Isn't that sort of the whole
 point. Any ideas? It would seem box 1 and box 2 can communicate enough
 to
 create backup session values and detect the death of the other node. Why
 would the backup session value be lost?

 Thanks,
 Alec




 -
 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: session-replication fails on restart or kill

[Tomcat Random]

In a great moment of DUH, I realized I had the expireSessionsOnShutdown to
true.

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

All working nicely now.



On Tue, Aug 27, 2013 at 12:27 PM, Tomcat Random tomcat.ran...@gmail.comwrote:

 Tomcat 7.0.42 / RHEL 6 / Two physical servers, with one tomcat instance on
 each server. Physical loadbalancer with sticky sessions. No proxy servers.

 I've set up session-replication using the delta-manager. I can confirm it
 works just lovely when the LB switches over from one box to the other.
 Using a test get/set session value servlet, the manager app reports the
 primary session value on the box where it was set, and the identical backup
 value on the other box. So everything appears good there.

 The problem is if, as a crash test, I stop/restart or kill the tomcat
 service on the box with the primary session: the backup session on the
 other box gets removed. So, as you'd imagine, when the LB swaps to the
 non-dead server the session value is gone. Not so good there.

 Shouldn't the backup session value remain? Isn't that sort of the whole
 point. Any ideas? It would seem box 1 and box 2 can communicate enough to
 create backup session values and detect the death of the other node. Why
 would the backup session value be lost?

 Thanks,
 Alec

Re: session-replication fails on restart or kill

[Mark Thomas]

On 27/08/2013 22:41, Tomcat Random wrote:
 In a great moment of DUH, I realized I had the expireSessionsOnShutdown to
 true.
 
 Manager className=org.apache.catalina.ha.session.DeltaManager
expireSessionsOnShutdown=false
notifyListenersOnReplication=true/
 
 All working nicely now.

Thanks for posting the solution. It makes the archives much more useful
for the next person that finds themselves facing the same issue.

Mark


 
 
 
 On Tue, Aug 27, 2013 at 12:27 PM, Tomcat Random 
 tomcat.ran...@gmail.comwrote:
 
 Tomcat 7.0.42 / RHEL 6 / Two physical servers, with one tomcat instance on
 each server. Physical loadbalancer with sticky sessions. No proxy servers.

 I've set up session-replication using the delta-manager. I can confirm it
 works just lovely when the LB switches over from one box to the other.
 Using a test get/set session value servlet, the manager app reports the
 primary session value on the box where it was set, and the identical backup
 value on the other box. So everything appears good there.

 The problem is if, as a crash test, I stop/restart or kill the tomcat
 service on the box with the primary session: the backup session on the
 other box gets removed. So, as you'd imagine, when the LB swaps to the
 non-dead server the session value is gone. Not so good there.

 Shouldn't the backup session value remain? Isn't that sort of the whole
 point. Any ideas? It would seem box 1 and box 2 can communicate enough to
 create backup session values and detect the death of the other node. Why
 would the backup session value be lost?

 Thanks,
 Alec

 


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

Re: session-replication fails on restart or kill

[Tomcat Random]

NP, glad to contribute a little. The FAQ was helpful but it's a little
confusing. I'd like to clean it up and add to the part that specifically
addresses two boxes two nodes on Linux. Would that be alright?

Thanks,
Alec


On Tue, Aug 27, 2013 at 5:52 PM, Mark Thomas ma...@apache.org wrote:

 On 27/08/2013 22:41, Tomcat Random wrote:
  In a great moment of DUH, I realized I had the expireSessionsOnShutdown
 to
  true.
 
  Manager className=org.apache.catalina.ha.session.DeltaManager
 expireSessionsOnShutdown=false
 notifyListenersOnReplication=true/
 
  All working nicely now.

 Thanks for posting the solution. It makes the archives much more useful
 for the next person that finds themselves facing the same issue.

 Mark


 
 
 
  On Tue, Aug 27, 2013 at 12:27 PM, Tomcat Random tomcat.ran...@gmail.com
 wrote:
 
  Tomcat 7.0.42 / RHEL 6 / Two physical servers, with one tomcat instance
 on
  each server. Physical loadbalancer with sticky sessions. No proxy
 servers.
 
  I've set up session-replication using the delta-manager. I can confirm
 it
  works just lovely when the LB switches over from one box to the other.
  Using a test get/set session value servlet, the manager app reports the
  primary session value on the box where it was set, and the identical
 backup
  value on the other box. So everything appears good there.
 
  The problem is if, as a crash test, I stop/restart or kill the tomcat
  service on the box with the primary session: the backup session on the
  other box gets removed. So, as you'd imagine, when the LB swaps to the
  non-dead server the session value is gone. Not so good there.
 
  Shouldn't the backup session value remain? Isn't that sort of the whole
  point. Any ideas? It would seem box 1 and box 2 can communicate enough
 to
  create backup session values and detect the death of the other node. Why
  would the backup session value be lost?
 
  Thanks,
  Alec
 
 


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

Re: Session Replication

[Manuel Fernández Panzuela]

What do you need to know ?

Un abrazo


2013/2/23 Technical Support techsupp...@brainstalk.com

 Hi,

 Im beginner in Linux. Can anyone help me develop my skills in Linux?

 Regards

 Chak Teylor

 On Sat, Feb 23, 2013 at 2:27 AM, Dhaval Jaiswal dhaval.jais...@via.com
 wrote:

  I am creating cluster of 3 tomcats (Version 6) for session replication
 with
  the following changes in server.xml
 
  Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster
  channelSendOptions=6/
 Manager className=org.apache.catalina.ha.session.DeltaManager
  expireSessionsOnShutdown=false
 notifyListenersOnReplication=true
 mapSendOptions=6/
  Channel
  className=org.apache.catalina.tribes.group.GroupChannel
   Membership
  className=org.apache.catalina.tribes.membership.McastService
  address=228.0.0.4
  port=45564
  frequency=500
  dropTime=1/
   Receiver
  className=org.apache.catalina.tribes.transport.nio.NioReceiver
address=auto
port=4000
selectorTimeout=5000
timeout=6
maxThreads=6/
 
   Sender
  className=org.apache.catalina.tribes.transport.ReplicationTransmitter
  timeout=6
 Transport
 
 className=org.apache.catalina.tribes.transport.nio.PooledParallelSender/
   /Sender
   Interceptor
 
 
 className=org.apache.catalina.tribes.group.interceptors.TcpFailureDetector/
   Interceptor
 
 
 className=org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor/
   Interceptor
 
 
 className=org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor/
/Channel
   Valve className=org.apache.catalina.ha.tcp.ReplicationValve
 
 
 
 filter=.*\.gif|.*\.js|.*\.jpeg|.*\.jpg|.*\.png|.*\.htm|.*\.html|.*\.css|.*\.txt/
 ClusterListener
  className=org.apache.catalina.ha.session.ClusterSessionListener/
 
  Opening the multicaste address (228.0.0.4) on firewall for 3 tomcats for
  port 45564 and 4000. Is it correct ?
 
 
  Please let me know if there is any change required in above
 configurations.
 
 
  --
 

Re: Session Replication

[Daniel Mikusa]

On Feb 22, 2013, at 1:27 PM, Dhaval Jaiswal wrote:

 I am creating cluster of 3 tomcats (Version 6) for session replication with
 the following changes in server.xml
 
 Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster
 channelSendOptions=6/
   Manager className=org.apache.catalina.ha.session.DeltaManager
 expireSessionsOnShutdown=false
   notifyListenersOnReplication=true mapSendOptions=6/
Channel
 className=org.apache.catalina.tribes.group.GroupChannel
 Membership
 className=org.apache.catalina.tribes.membership.McastService
address=228.0.0.4
port=45564
frequency=500
dropTime=1/
 Receiver
 className=org.apache.catalina.tribes.transport.nio.NioReceiver
  address=auto
  port=4000
  selectorTimeout=5000
  timeout=6
  maxThreads=6/
 
 Sender
 className=org.apache.catalina.tribes.transport.ReplicationTransmitter
 timeout=6
   Transport
 className=org.apache.catalina.tribes.transport.nio.PooledParallelSender/
 /Sender
 Interceptor
 className=org.apache.catalina.tribes.group.interceptors.TcpFailureDetector/
 Interceptor
 className=org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor/
 Interceptor
 className=org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor/
  /Channel
 Valve className=org.apache.catalina.ha.tcp.ReplicationValve
 
 filter=.*\.gif|.*\.js|.*\.jpeg|.*\.jpg|.*\.png|.*\.htm|.*\.html|.*\.css|.*\.txt/
   ClusterListener
 className=org.apache.catalina.ha.session.ClusterSessionListener/
 
 Opening the multicaste address (228.0.0.4) on firewall for 3 tomcats for
 port 45564 and 4000. Is it correct ?

The easiest way to check if this is correct is to simply run your Tomcat 
instances?  Have you tried that?

Dan

 
 
 Please let me know if there is any change required in above configurations.
 
 
 --

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

Re: Session Replication

[Technical Support]

Hi,

Im beginner in Linux. Can anyone help me develop my skills in Linux?

Regards

Chak Teylor

On Sat, Feb 23, 2013 at 2:27 AM, Dhaval Jaiswal dhaval.jais...@via.comwrote:

 I am creating cluster of 3 tomcats (Version 6) for session replication with
 the following changes in server.xml

 Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster
 channelSendOptions=6/
Manager className=org.apache.catalina.ha.session.DeltaManager
 expireSessionsOnShutdown=false
notifyListenersOnReplication=true mapSendOptions=6/
 Channel
 className=org.apache.catalina.tribes.group.GroupChannel
  Membership
 className=org.apache.catalina.tribes.membership.McastService
 address=228.0.0.4
 port=45564
 frequency=500
 dropTime=1/
  Receiver
 className=org.apache.catalina.tribes.transport.nio.NioReceiver
   address=auto
   port=4000
   selectorTimeout=5000
   timeout=6
   maxThreads=6/

  Sender
 className=org.apache.catalina.tribes.transport.ReplicationTransmitter
 timeout=6
Transport
 className=org.apache.catalina.tribes.transport.nio.PooledParallelSender/
  /Sender
  Interceptor

 className=org.apache.catalina.tribes.group.interceptors.TcpFailureDetector/
  Interceptor

 className=org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor/
  Interceptor

 className=org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor/
   /Channel
  Valve className=org.apache.catalina.ha.tcp.ReplicationValve


 filter=.*\.gif|.*\.js|.*\.jpeg|.*\.jpg|.*\.png|.*\.htm|.*\.html|.*\.css|.*\.txt/
ClusterListener
 className=org.apache.catalina.ha.session.ClusterSessionListener/

 Opening the multicaste address (228.0.0.4) on firewall for 3 tomcats for
 port 45564 and 4000. Is it correct ?


 Please let me know if there is any change required in above configurations.


 --

Re: Session replication problem

[Mark Thomas]

On 22/03/2012 08:16, Andy Chapman wrote:
 Hi All,
 
 I'm using tribes session replication between two Tomcat 7 servers and
 getting errors as below. There are various possible causes:
 
 1. The Tomcat versions are different (7.0.4 and 7.0.20)

It is this one.

Mark

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

Re: Session replication problem

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andy,

On 3/22/12 4:16 AM, Andy Chapman wrote:
 1. The Tomcat versions are different (7.0.4 and 7.0.20)

Note that Tomcat 7.0.6 was the first non-beta version of Tomcat 7. You
should definitely upgrade the 7.0.4 version to 7.0.20 and I suspect
things will start working better.

 2. The Java versions are different (1.6.0_22 for i386_and 1.6.0_27
 for x64)

That might have been an issue, but the exception clearly shows
Tomcat's SerialMessageImpl class. Perhaps there will be other problems
after this one is cleared-up, but most Serializable classes in the JDK
are cross-version-compatible.

 3. One server is 32 bit CentOS and the other 64 bit

Should never be an issue: bytecode is host architecture agnostic
(that's the whole point).

Upgrade Tomcat and see if that helps.

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

iEYEARECAAYFAk9rGi4ACgkQ9CaO5/Lv0PCdIQCgs5KjeWFCKtGojufvbqusujXG
i0AAn3S6povTIUumL7VZtKllfhoDgD1H
=0+Te
-END PGP SIGNATURE-

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

Re: Session replication fails with Member send is failing

[Filip Hanik - Dev Lists]

On 12/7/2011 9:04 AM, Jürgen Link wrote:

Caused by: org.apache.catalina.tribes.RemoteProcessException: Received a
failedack:org.apache.catalina.tribes.transport.Constants.FAIL_ACK_DATA


sure thing, this is actually telling the sender that an exception happened on the 
receiver end.
Take a look at the logs for tcp://{10, 1, 3, 181}:5000 and it should contain 
the information in there

Filip

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

Re: session replication question in 7.0.10

[János Löbb]

Hi Mark,

This SessionExample
http://bml0065.yalepath.org/tc/examples/servlets/servlet/SessionExample

Sorry for the mistype  I have a sticky keyboard and I try to live with it.

Sorry for the comment.. Ultimately it was my fault because I left out the 
distributable tag from one the web.xml.

Thanks for your help !!  Please do not be discouraged :-)

János

On Mar 21, 2011, at 6:17 PM, Mark Thomas wrote:

 On 21/03/2011 21:34, János Löbb wrote:
 Hi,
 
 I have two machines MachineA and MachineB with osx 10.6.6 on them.  Both 
 machines have one tomcat 7.0.10 running.  On both machine the server.xml was 
 modified minimally:
 -Uncommented the Cluster tag
 -added jvmRoute=tomcat(x) to the Engine tag where x member of {1,3}, 
 -changed ports:
 for example:
Engine name=Catalina defaultHost=localhost jvmRoute=tomcat3
  Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster/
 
 If I am reading the documentation right I should have the default 
 configuration listed in the how-to, that is I should have the 
 ReplicationValve working.
 
 Unfortunately session replication does not work.   session variables using 
 the SessionExample application are not carried over  to restarted tomcats.
 
 What is the SessionExample application? No such application ships with
 Apache Tomcat.
 
 With 6.0.18 I had a ReplicationContect in server.xml.  I understand that is 
 a No-No these days, so, for the examples webapp should I create a META-INF 
 directory with a contect.xml in it ?
 
 That is context.xml not contect.xml and there should be no need to
 create it.
 
 My guess is that the web application you are using is not marked as
 distributable/ in web.xml.
 
 I thought examples should work out of box
 
 That sort of comment isn't going to encourage folks to help you.
 
 Mark
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org


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

Re: session replication question in 7.0.10

[Mark Thomas]

On 21/03/2011 21:34, János Löbb wrote:
 Hi,
 
 I have two machines MachineA and MachineB with osx 10.6.6 on them.  Both 
 machines have one tomcat 7.0.10 running.  On both machine the server.xml was 
 modified minimally:
 - Uncommented the Cluster tag
 - added jvmRoute=tomcat(x) to the Engine tag where x member of {1,3}, 
 - changed ports:
 for example:
 Engine name=Catalina defaultHost=localhost jvmRoute=tomcat3
   Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster/
 
 If I am reading the documentation right I should have the default 
 configuration listed in the how-to, that is I should have the 
 ReplicationValve working.
 
 Unfortunately session replication does not work.   session variables using 
 the SessionExample application are not carried over  to restarted tomcats.

What is the SessionExample application? No such application ships with
Apache Tomcat.

 With 6.0.18 I had a ReplicationContect in server.xml.  I understand that is a 
 No-No these days, so, for the examples webapp should I create a META-INF 
 directory with a contect.xml in it ?

That is context.xml not contect.xml and there should be no need to
create it.

My guess is that the web application you are using is not marked as
distributable/ in web.xml.

 I thought examples should work out of box

That sort of comment isn't going to encourage folks to help you.

Mark

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

Re: session replication question in 7.0.10

[János Löbb]

Sorry for the noise, one of the web.xml did not have the distributable/ tag :(

Now it is working fine.

János

On Mar 21, 2011, at 5:34 PM, János Löbb wrote:

 Hi,
 
 I have two machines MachineA and MachineB with osx 10.6.6 on them.  Both 
 machines have one tomcat 7.0.10 running.  On both machine the server.xml was 
 modified minimally:
 - Uncommented the Cluster tag
 - added jvmRoute=tomcat(x) to the Engine tag where x member of {1,3}, 
 - changed ports:
 for example:
Engine name=Catalina defaultHost=localhost jvmRoute=tomcat3
  Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster/
 
 If I am reading the documentation right I should have the default 
 configuration listed in the how-to, that is I should have the 
 ReplicationValve working.
 
 Unfortunately session replication does not work.   session variables using 
 the SessionExample application are not carried over  to restarted tomcats.
 
 I am getting the following on one machine:
 nyissz
 Mar 21, 2011 4:39:50 PM org.apache.catalina.ha.session.DeltaManager 
 getAllClusterSessions
 INFO: Manager [localhost#/examples], requesting session state from 
 org.apache.catalina.tribes.membership.MemberImpl[tcp://{10, 84, 2, 
 66}:4000,{10, 84, 2, 66},4000, alive=33001, securePort=-1, UDP Port=-1, 
 id={-43 -8 -66 47 -12 -83 72 -110 -105 -3 -61 111 -111 95 5 113 }, 
 payload={}, command={}, domain={}, ]. This operation will timeout if no 
 session state has been received within 60 seconds.
 Mar 21, 2011 4:40:50 PM org.apache.catalina.ha.session.DeltaManager 
 waitForSendAllSessions
 SEVERE: Manager [localhost#/examples]: No session state send at 3/21/11 4:39 
 PM received, timing out after 60,103 ms.
 nyassz
 
 and somewhat different on the other machine at about the same time:
 nyissz
 Mar 21, 2011 4:39:49 PM org.apache.catalina.ha.session.ClusterSessionListener 
 messageReceived
 WARNING: Context manager doesn't exist:localhost#/examples
 Mar 21, 2011 4:40:55 PM org.apache.catalina.ha.session.ClusterSessionListener 
 messageReceived
 WARNING: Context manager doesn't exist:localhost#/examples
 Mar 21, 2011 4:40:55 PM org.apache.catalina.ha.session.ClusterSessionListener 
 messageReceived
 WARNING: Context manager doesn't exist:localhost#/examples
 Mar 21, 2011 4:41:17 PM org.apache.catalina.ha.session.ClusterSessionListener 
 messageReceived
 WARNING: Context manager doesn't exist:localhost#/examples
 nyassz
 
 
 With 6.0.18 I had a ReplicationContect in server.xml.  I understand that is a 
 No-No these days, so, for the examples webapp should I create a META-INF 
 directory with a contect.xml in it ?
 
 I thought examples should work out of box
 
 Thanks ahead,
 
 János
 
 
 -
 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: Session replication fails on ReplicationValve invocation

[Lingagiri]

How did you monitored that cluster membership up and working via multicast
and the two nodes add each other as replication targets.


David Nillesen wrote:
 
 I think I may have sorted the problem. Would that have occurred if I was
 asking for a webpage without a context? i.e. just hitting some undefined
 area?
 
 Thanks,
 Dave
 
 --
 David Nillesen
 UNIX Systems Administrator
 Ph: + 61 2 6773 2112
 
 -Original Message-
 From: Martin Gainty [mailto:mgai...@hotmail.com]
 Sent: Thursday, 18 June 2009 12:06 PM
 To: Tomcat Users List
 Subject: RE: Session replication fails on ReplicationValve invocation
 
 
 Hello Dave
 
 that line from ReplicationManager is getManager()
 Manager manager = request.getContext().getManager();
 
 i would check to make sure the Manager node in /context.xml
 
 !-- The contents of this file will be loaded for each web application --
 Context
 
 !-- Default set of monitored resources --
 WatchedResourceWEB-INF/web.xml/WatchedResource
 
 !-- Uncomment this to disable session persistence across Tomcat
 restarts --
 Manager pathname=/ /
 
 !-- Uncomment this to enable Comet connection tacking (provides
 events
  on session expiration as well as webapp lifecycle) --
 !--
 Valve
 className=org.apache.catalina.valves.CometConnectionManagerValve /
 --
 /Context
 
 all explained here
 http://www.scribd.com/doc/15490833/Tomcat-The-Definitive-Guide-by-OReilly-Media
 
 Cheers,
 Martin
 __
 Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
 
 Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
 Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte
 Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht
 dient lediglich dem Austausch von Informationen und entfaltet keine
 rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
 E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
 Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
 destinataire prévu, nous te demandons avec bonté que pour satisfaire
 informez l'expéditeur. N'importe quelle diffusion non autorisée ou la
 copie de ceci est interdite. Ce message sert à l'information seulement et
 n'aura pas n'importe quel effet légalement obligatoire. Étant donné que
 les email peuvent facilement être sujets à la manipulation, nous ne
 pouvons accepter aucune responsabilité pour le contenu fourni.
 
 
 
 
 From: dnill...@une.edu.au
 To: users@tomcat.apache.org
 Date: Thu, 18 Jun 2009 10:24:20 +1000
 Subject: Session replication fails on ReplicationValve invocation

 Hi,
 I'm currently trying to establish a cluster of tomcat
 5.5.27 servers to deploy sakai in, so I'm stuck on version 5.5. It is not
 an option to upgrade to tomcat 6 which from all accounts has much better
 session replication.

 I have cluster membership up and working via multicast and the two nodes
 add each other as replication targets. When I try to establish a
 connection to the server  from my web browser to the default port of 8080
 I get this neat error in my catalina.out:
 

 ERROR: An exception or error occurred in the container during the request
 processing (2009-06-17 16:43:49,545
 http-172.31.3.37-8080-Processor5_org.apache.catalina.connector.CoyoteAdapter)
 java.lang.NullPointerException
 at
 org.apache.catalina.cluster.tcp.ReplicationValve.invoke(ReplicationValve.java:348)

 I'll put full errors and configs at the bottom of the email. The errors
 occurs regardless of whether I access an empty/nonexistent context or the
 servlet-examples which are currently installed.

 The servers are multi homed with 3 interfaces. Eth0 is
 the primary public interface, eth1 is my iSCSI network and eth2 is the
 backend cluster network. All neatly VLANd from each other in seperate
 subnets. Multicast membership works, I can see the packets arriving via
 tcpdump and the membership propagation is occurring.
 I have tried binding the receivers to both public and private interfaces
 but have had no luck. The receivers are up and appear to be functional. I
 can telnet to  them and when I enter gibberish into the console it tell
 me I am sending malformed headers.
 
 By using tcpdump and netstat I can see that neither tomcat instance is
 originating a sender session to connect to the other servers receiver.

 I have tried fastsyncqueue and pooled style senders from the
 documentation. Currently configured for pooled as it looked the simpler
 config to diagnose. jvmRoute is configured via -D options passed to java
 as a lot of our configs are done dynamically so as to have a single
 server.xml across the cluster environments. We have a shared disk backend
 system to enable this.

 Any suggestions for diagnosis, help, fixes or otherwise would be very
 much appreciated.

 Regards,
 Dave

 Log file and startup:
 INFO

Re: Session replication question

[Filip Hanik - Dev Lists]

make sure your clocks are synced across all machines, since session expiration 
is time based

Filip

On 12/23/2010 8:22 AM, Jorge Santiago Cruz Lambert wrote:

Hi!

I'm not an expert on Tomcat and we purchase a load balancer service with two
tomcat 6.0.29 instances in separate Ubuntu servers with JVM version
1.6.0_22-b04. This instances have been configured to replicate the session
as follow:

Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster
channelSendOptions=6 channelStartOptions=3
   Manager
className=org.apache.catalina.ha.session.DeltaManager
expireSessionsOnShutdown=false notifyListenersOnReplication=true/
   Channel
className=org.apache.catalina.tribes.group.GroupChannel
   Receiver
className=org.apache.catalina.tribes.transport.nio.NioReceiver
   address=auto
   port=4001
   autoBind=100
   selectorTimeout=5000
   maxThreads=10/
   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.StaticMembershipInterceptor
   Member
className=org.apache.catalina.tribes.membership.StaticMember
   port=4000
   securePort=-1
   host=xxx.xxx.xxx.xxx
   domain=tomcat-cluster

  uniqueId={0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1}/
   /Interceptor
   Interceptor
className=org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor/
   /Channel
   Valve
className=org.apache.catalina.ha.tcp.ReplicationValve
filter=.*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;/
   Valve
className=org.apache.catalina.ha.session.JvmRouteBinderValve/
   ClusterListener
className=org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener/
   ClusterListener
className=org.apache.catalina.ha.session.ClusterSessionListener/
   /Cluster

The balancer has a sticky session feature that makes persistent
connections for 300s and its balancing algorithm is least connections.

The problem is when trying to connect to load balancer with a device that
changes its IP each request, it looks like session is not replicated and in
some cases we can see the session id in the manager but with empty
attributes.

We have our application distributable, sessions are Serializable and we
tried to change as previously I read in this list, the channelSendOptions
from 8 (Asynchronous) to 6, and in this way we stopped the SEVERE messages
from catalina saying something like:

SEVERE: Manager [localhost#]: Unable to receive message through TCP channel
java.lang.IllegalStateException: setAttribute: Session already invalidated
 at
org.apache.catalina.session.StandardSession.setAttribute(StandardSession.java:1326)
 at
org.apache.catalina.ha.session.DeltaSession.setAttribute(DeltaSession.java:594)
 at
org.apache.catalina.ha.session.DeltaRequest.execute(DeltaRequest.java:164)
 at
org.apache.catalina.ha.session.DeltaManager.handleSESSION_DELTA(DeltaManager.java:1487)
 at
org.apache.catalina.ha.session.DeltaManager.messageReceived(DeltaManager.java:1437)
 at
org.apache.catalina.ha.session.DeltaManager.messageDataReceived(DeltaManager.java:1171)
 at
org.apache.catalina.ha.session.ClusterSessionListener.messageReceived(ClusterSessionListener.java:92)
 at
org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived(SimpleTcpCluster.java:901)
 at
org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived(SimpleTcpCluster.java:882)
 at
org.apache.catalina.tribes.group.GroupChannel.messageReceived(GroupChannel.java:269)
 at
org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79)
 at
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.messageReceived(TcpFailureDetector.java:110)
 at
org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79)
 at
org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79)
 at
org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79)
 at

Re: Session replication question

[Jorge Santiago Cruz Lambert]

Thanks for replying, I'm cheking the time in our machines and they are the
same, but in different time zones:

Machine 1: Thu Dec 23 17:18:40 CET 2010
Machine 2: Thu Dec 23 16:18:40 UTC 2010

Do I need to change the timezone in Machine 2? I think the time is the same
and ntp is running as process.

On Thu, Dec 23, 2010 at 5:06 PM, Filip Hanik - Dev Lists devli...@hanik.com
 wrote:

 make sure your clocks are synced across all machines, since session
 expiration is time based

 Filip


 On 12/23/2010 8:22 AM, Jorge Santiago Cruz Lambert wrote:

 Hi!

 I'm not an expert on Tomcat and we purchase a load balancer service with
 two
 tomcat 6.0.29 instances in separate Ubuntu servers with JVM version
 1.6.0_22-b04. This instances have been configured to replicate the session
 as follow:

 Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster
 channelSendOptions=6 channelStartOptions=3
   Manager
 className=org.apache.catalina.ha.session.DeltaManager
 expireSessionsOnShutdown=false notifyListenersOnReplication=true/
   Channel
 className=org.apache.catalina.tribes.group.GroupChannel
   Receiver
 className=org.apache.catalina.tribes.transport.nio.NioReceiver
   address=auto
   port=4001
   autoBind=100
   selectorTimeout=5000
   maxThreads=10/
   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.StaticMembershipInterceptor
   Member
 className=org.apache.catalina.tribes.membership.StaticMember
   port=4000
   securePort=-1
   host=xxx.xxx.xxx.xxx
   domain=tomcat-cluster

  uniqueId={0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1}/
   /Interceptor
   Interceptor

 className=org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor/
   /Channel
   Valve
 className=org.apache.catalina.ha.tcp.ReplicationValve

 filter=.*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;/
   Valve
 className=org.apache.catalina.ha.session.JvmRouteBinderValve/
   ClusterListener

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

 The balancer has a sticky session feature that makes persistent
 connections for 300s and its balancing algorithm is least connections.

 The problem is when trying to connect to load balancer with a device that
 changes its IP each request, it looks like session is not replicated and
 in
 some cases we can see the session id in the manager but with empty
 attributes.

 We have our application distributable, sessions are Serializable and we
 tried to change as previously I read in this list, the channelSendOptions
 from 8 (Asynchronous) to 6, and in this way we stopped the SEVERE messages
 from catalina saying something like:

 SEVERE: Manager [localhost#]: Unable to receive message through TCP
 channel
 java.lang.IllegalStateException: setAttribute: Session already invalidated
 at

 org.apache.catalina.session.StandardSession.setAttribute(StandardSession.java:1326)
 at

 org.apache.catalina.ha.session.DeltaSession.setAttribute(DeltaSession.java:594)
 at
 org.apache.catalina.ha.session.DeltaRequest.execute(DeltaRequest.java:164)
 at

 org.apache.catalina.ha.session.DeltaManager.handleSESSION_DELTA(DeltaManager.java:1487)
 at

 org.apache.catalina.ha.session.DeltaManager.messageReceived(DeltaManager.java:1437)
 at

 org.apache.catalina.ha.session.DeltaManager.messageDataReceived(DeltaManager.java:1171)
 at

 org.apache.catalina.ha.session.ClusterSessionListener.messageReceived(ClusterSessionListener.java:92)
 at

 org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived(SimpleTcpCluster.java:901)
 at

 org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived(SimpleTcpCluster.java:882)
 at

 org.apache.catalina.tribes.group.GroupChannel.messageReceived(GroupChannel.java:269)
 at

 org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79)
 at

 

Re: Session replication question

[Jorge Santiago Cruz Lambert]

 Thanks for replying, I'm cheking the time in our machines and they are the
 same, but in different time zones:

 Machine 1: Thu Dec 23 17:18:40 CET 2010
 Machine 2: Thu Dec 23 16:18:40 UTC 2010

 Do I need to change the timezone in Machine 2? I think the time is the same
 and ntp is running as process.

 On Thu, Dec 23, 2010 at 5:06 PM, Filip Hanik - Dev Lists 
 devli...@hanik.com wrote:

 make sure your clocks are synced across all machines, since session
 expiration is time based

 Filip


 On 12/23/2010 8:22 AM, Jorge Santiago Cruz Lambert wrote:

 Hi!

 I'm not an expert on Tomcat and we purchase a load balancer service with
 two
 tomcat 6.0.29 instances in separate Ubuntu servers with JVM version
 1.6.0_22-b04. This instances have been configured to replicate the
 session
 as follow:

 Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster
 channelSendOptions=6 channelStartOptions=3
   Manager
 className=org.apache.catalina.ha.session.DeltaManager
 expireSessionsOnShutdown=false notifyListenersOnReplication=true/
   Channel
 className=org.apache.catalina.tribes.group.GroupChannel
   Receiver
 className=org.apache.catalina.tribes.transport.nio.NioReceiver
   address=auto
   port=4001
   autoBind=100
   selectorTimeout=5000
   maxThreads=10/
   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.StaticMembershipInterceptor
   Member
 className=org.apache.catalina.tribes.membership.StaticMember
   port=4000
   securePort=-1
   host=xxx.xxx.xxx.xxx
   domain=tomcat-cluster

  uniqueId={0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1}/
   /Interceptor
   Interceptor

 className=org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor/
   /Channel
   Valve
 className=org.apache.catalina.ha.tcp.ReplicationValve

 filter=.*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;/
   Valve
 className=org.apache.catalina.ha.session.JvmRouteBinderValve/
   ClusterListener

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

 The balancer has a sticky session feature that makes persistent
 connections for 300s and its balancing algorithm is least connections.

 The problem is when trying to connect to load balancer with a device that
 changes its IP each request, it looks like session is not replicated and
 in
 some cases we can see the session id in the manager but with empty
 attributes.

 We have our application distributable, sessions are Serializable and we
 tried to change as previously I read in this list, the channelSendOptions
 from 8 (Asynchronous) to 6, and in this way we stopped the SEVERE
 messages
 from catalina saying something like:

 SEVERE: Manager [localhost#]: Unable to receive message through TCP
 channel
 java.lang.IllegalStateException: setAttribute: Session already
 invalidated
 at

 org.apache.catalina.session.StandardSession.setAttribute(StandardSession.java:1326)
 at

 org.apache.catalina.ha.session.DeltaSession.setAttribute(DeltaSession.java:594)
 at

 org.apache.catalina.ha.session.DeltaRequest.execute(DeltaRequest.java:164)
 at

 org.apache.catalina.ha.session.DeltaManager.handleSESSION_DELTA(DeltaManager.java:1487)
 at

 org.apache.catalina.ha.session.DeltaManager.messageReceived(DeltaManager.java:1437)
 at

 org.apache.catalina.ha.session.DeltaManager.messageDataReceived(DeltaManager.java:1171)
 at

 org.apache.catalina.ha.session.ClusterSessionListener.messageReceived(ClusterSessionListener.java:92)
 at

 org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived(SimpleTcpCluster.java:901)
 at

 org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived(SimpleTcpCluster.java:882)
 at

 org.apache.catalina.tribes.group.GroupChannel.messageReceived(GroupChannel.java:269)
 at

 org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79)
 at

 

Re: Session replication with multicast

[Guillaume HERAIL]

Actually, it works without it, just forgot to add distributable / in
my web.xml.

2010/11/29 Filip Hanik - Dev Lists devli...@hanik.com:
 alternatively, try to add

 -Djava.net.preferIPv4Stack=true

 to your JVM args

 On 11/26/2010 06:36 AM, Guillaume HERAIL wrote:

 Hi,

 OS : Debian lenny
 Tomcat : 7.0.2
 JRE : 1.6.0_21

 I have a problem trying to clusterize two tomcat on two different
 boxes. I want to use the MemberShip's argument bind to tell to tomcat
 wich interface to use but i get an exception :
 http://paste.geeknode.org/22a07ecb (where bind=192.168.0.1 and
 192.168.0.2 respectively).

 Here is my Cluster block : http://paste.geeknode.org/4cf7af8f

 If anyone has a clue...

 Thanks,




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





-- 
Guillaume

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

Re: Session replication with multicast

[Guillaume HERAIL]

I found my mistake, i forgot to add distributable / in my web.xml.
Anyway, i've updated tomcat on my boxes.

Thanks,

2010/11/27 Christopher Schultz ch...@christopherschultz.net:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Guillaume,

 (Apologies for the top-post, but these are general comments)

 I don't know anything about Tomcat's clustering, but I do know that
 Tomcat 7 has had a few releases since 7.0.2. 7.0.5 was just recently
 tagged and might be released next week. You should re-test with the
 latest released version, or even go up to 7.0.5: you'll get better
 feedback from those who actually work with the clustering code.

 Thanks,
 - -chris

 On 11/26/2010 8:36 AM, Guillaume HERAIL wrote:
 Hi,

 OS : Debian lenny
 Tomcat : 7.0.2
 JRE : 1.6.0_21

 I have a problem trying to clusterize two tomcat on two different
 boxes. I want to use the MemberShip's argument bind to tell to tomcat
 wich interface to use but i get an exception :
 http://paste.geeknode.org/22a07ecb (where bind=192.168.0.1 and
 192.168.0.2 respectively).

 Here is my Cluster block : http://paste.geeknode.org/4cf7af8f

 If anyone has a clue...

 Thanks,

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (MingW32)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAkzxEOcACgkQ9CaO5/Lv0PAtaACcCEllrsFqW9gxPQstX5eR+SOf
 wiMAnRmbG3ndIwFihkorvpSR3pTNHFWU
 =VWza
 -END PGP SIGNATURE-

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





-- 
Guillaume

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

Re: Session replication with multicast

[Filip Hanik - Dev Lists]

On 11/26/2010 06:36 AM, Guillaume HERAIL wrote:

Hi,

OS : Debian lenny
Tomcat : 7.0.2
JRE : 1.6.0_21

I have a problem trying to clusterize two tomcat on two different
boxes. I want to use the MemberShip's argument bind to tell to tomcat
wich interface to use but i get an exception :
http://paste.geeknode.org/22a07ecb (where bind=192.168.0.1 and
192.168.0.2 respectively).
   


IIRC, linux doesn't support bind for multicast sockets

Filip


Here is my Cluster block : http://paste.geeknode.org/4cf7af8f

If anyone has a clue...

Thanks,

   



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

Re: Session replication with multicast

[Filip Hanik - Dev Lists]

alternatively, try to add

-Djava.net.preferIPv4Stack=true

to your JVM args

On 11/26/2010 06:36 AM, Guillaume HERAIL wrote:

Hi,

OS : Debian lenny
Tomcat : 7.0.2
JRE : 1.6.0_21

I have a problem trying to clusterize two tomcat on two different
boxes. I want to use the MemberShip's argument bind to tell to tomcat
wich interface to use but i get an exception :
http://paste.geeknode.org/22a07ecb (where bind=192.168.0.1 and
192.168.0.2 respectively).

Here is my Cluster block : http://paste.geeknode.org/4cf7af8f

If anyone has a clue...

Thanks,

   



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

Re: Session replication with multicast

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Guillaume,

(Apologies for the top-post, but these are general comments)

I don't know anything about Tomcat's clustering, but I do know that
Tomcat 7 has had a few releases since 7.0.2. 7.0.5 was just recently
tagged and might be released next week. You should re-test with the
latest released version, or even go up to 7.0.5: you'll get better
feedback from those who actually work with the clustering code.

Thanks,
- -chris

On 11/26/2010 8:36 AM, Guillaume HERAIL wrote:
 Hi,
 
 OS : Debian lenny
 Tomcat : 7.0.2
 JRE : 1.6.0_21
 
 I have a problem trying to clusterize two tomcat on two different
 boxes. I want to use the MemberShip's argument bind to tell to tomcat
 wich interface to use but i get an exception :
 http://paste.geeknode.org/22a07ecb (where bind=192.168.0.1 and
 192.168.0.2 respectively).
 
 Here is my Cluster block : http://paste.geeknode.org/4cf7af8f
 
 If anyone has a clue...
 
 Thanks,
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzxEOcACgkQ9CaO5/Lv0PAtaACcCEllrsFqW9gxPQstX5eR+SOf
wiMAnRmbG3ndIwFihkorvpSR3pTNHFWU
=VWza
-END PGP SIGNATURE-

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

Re: Session replication: Channel.SEND_OPTIONS_SECURE

[Filip Hanik - Dev Lists]

On 03/23/2010 09:46 AM, Tom wrote:

On Tue, Mar 23, 2010 at 1:58 PM, Caldarale, Charles R
chuck.caldar...@unisys.com  wrote:
   

From: Tom [mailto:808...@gmail.com]
Subject: Session replication: Channel.SEND_OPTIONS_SECURE

There is little documentation about Channel.SEND_OPTIONS_SECURE
   

 From a brief glance at the code, SEND_OPTIONS_SECURE appears to be defined, 
but not yet implemented - which would explain the behavior you observe.

 

Thanks, that is what I feared. I think for our needs a crossover cable
or tunnel will be sufficient.

I am also interested in SEND_OPTIONS_BYTE_MESSAGE. Can anyone
elaborate on the pros/cons other than speed?
   
only pros, since you get to control all the class loading and how it 
happens.
otherwise, you have to build some block on top of the channel that does 
the class loading for you

Regards,
Tom

-
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: Session replication: Channel.SEND_OPTIONS_SECURE

[Caldarale, Charles R]

 From: Tom [mailto:808...@gmail.com]
 Subject: Session replication: Channel.SEND_OPTIONS_SECURE
 
 There is little documentation about Channel.SEND_OPTIONS_SECURE

From a brief glance at the code, SEND_OPTIONS_SECURE appears to be defined, 
but not yet implemented - which would explain the behavior you observe.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

Re: Session replication: Channel.SEND_OPTIONS_SECURE

[Tom]

On Tue, Mar 23, 2010 at 1:58 PM, Caldarale, Charles R
chuck.caldar...@unisys.com wrote:
 From: Tom [mailto:808...@gmail.com]
 Subject: Session replication: Channel.SEND_OPTIONS_SECURE

 There is little documentation about Channel.SEND_OPTIONS_SECURE

 From a brief glance at the code, SEND_OPTIONS_SECURE appears to be defined, 
 but not yet implemented - which would explain the behavior you observe.


Thanks, that is what I feared. I think for our needs a crossover cable
or tunnel will be sufficient.

I am also interested in SEND_OPTIONS_BYTE_MESSAGE. Can anyone
elaborate on the pros/cons other than speed?

Regards,
Tom

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

Re: Session replication using only PersistenceManager + JDBCStore

[Yves Glodt]

Thanks for your detailed answer, I will probably go with in-memory replication.
Regading your last question, I have one database instance sitting on
top of a 2 node DRBD.

2009/6/17 Christopher Schultz ch...@christopherschultz.net:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Yves,

 On 6/17/2009 6:04 AM, Yves Glodt wrote:
 In my setup are 4 apaches with mod_proxy which connect to 4 tomcats.
 In front of the apaches is a hardware balancer which does
 round-robin, but with a kind of sticky TCP-sessions, so mostly the
 clients on the web stay on the same server. Mostly...

 Why not use mod_jk's session stickiness? The httpd server can be chosen
 randomly by the hw lb, but the right Tomcat always gets the request.
 Then, you can forget about session replication and get better
 performance. On the other hand, if your users cannot be expected to
 tolerate interruptions (due to a failing server) then you'll /have/ to
 go with some kind of replication.

 To be completely safe and sleep well, I would like to replicate the
 sessions now, and in the mentioned document I read that it is
 possible using the PersistenceManager with JDBCStore.

 Just note that this is probably the slowest of the 3 options presented
 in the Replication HOWTO, since each session attribute will have to be
 retrieved from the database every time. Option #3 (in-memory
 replication) will probably be the fastest option for a cluster such as
 yours, especially if all the members of the cluster are on the same
 (real) network.

 My question now: Is it enough to set up PersistenceManager with
 JDBCStore on my 4 tomcats to use the same database/table as session
 store ?

 It should be.

 Or do I need to mess with ReplicationValve and jvmRoute set up as
 well ?

 No, but I think using real replication will give you better performance.

 I will put my server.xml at the end of the file, which is set up
 with JDBCStore using a Firebird Database with JayBird.

 How are you sharing your database across your 4 Tomcat instances?

 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.9 (MingW32)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAko5RwoACgkQ9CaO5/Lv0PDK/wCffEK2IfLU3urah7UO4c8+NV2w
 VOMAn2ly1yE2CO3+PdglPRj2k9plFn5F
 =qeVK
 -END PGP SIGNATURE-

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



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

Re: Session replication without Apache

[Emilio Recio]

Manu_SF wrote:

Hi,

I have a working prototype tomcat cluster with 2 worker nodes connected to
Apache webserver as the Loadbalancer with mod_jk connectors. The session
replication works like a charm with these 2 nodes.

However, my ultimate goal is to deploy it over a system that does NOT have
Apache (Instead has a Big-ip hardware loadbalancer).

My question is - Is there a way to implement session replication on tomcat
nodes without Apache?

Thanks,
Manu
  
Hi, i suggest you that read Professional Apache Tomcat 6 Author: Vivek 
Chopra, Sing Li, Jeff Genender (Chapter 11 and 17). They explain a lot 
of possibles configurations of Tomcat to Load Balancing and Replication 
Sessions. May by you can search the book in google and read only the 
chapter.

See you


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

Re: Session replication without Apache

[Rainer Jung]

On 06.07.2009 20:33, Manu_SF wrote:
 Hi,
 
 I have a working prototype tomcat cluster with 2 worker nodes connected to
 Apache webserver as the Loadbalancer with mod_jk connectors. The session
 replication works like a charm with these 2 nodes.
 
 However, my ultimate goal is to deploy it over a system that does NOT have
 Apache (Instead has a Big-ip hardware loadbalancer).
 
 My question is - Is there a way to implement session replication on tomcat
 nodes without Apache?

Tomcat cluster isn't aware in any way what kind of infrastructure is in
front of Tomcat. So it doesn't know about your Apache/mod_jk and would
replicate just the same when the requests come in via an http connector,
distributed by a Big IP.

But: Your load balancer should do correct stickyness. The usual basic
client IP stickyness is not good. The load balancer could use e.g. its
own cookie to track stickyness, or use the JSESSIONID cookie of Tomcat.

See also: http://markmail.org/message/6ftyqbzmiulsve23

Regards,

Rainer

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

Re: Session replication fails on ReplicationValve invocation

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

David,

On 6/18/2009 12:03 AM, David Nillesen wrote:
 I think I may have sorted the problem. Would that have occurred if I
 was asking for a webpage without a context? i.e. just hitting some
 undefined area?

All requests are handled by /some/ context. If the URL doesn't match any
context, it will be handled by the ROOT context. If no ROOT context is
deployed, Tomcat will give you a Bad Request response code (IIRC).

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAko7/n0ACgkQ9CaO5/Lv0PB/mACeIBPpCjlxFDOfCC1qcUTRi/cT
vQMAn3hMJCV+Y87dPneB9CtJb/zMEYJv
=NjdT
-END PGP SIGNATURE-

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

Re: Session replication using only PersistenceManager + JDBCStore

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Yves,

On 6/17/2009 6:04 AM, Yves Glodt wrote:
 In my setup are 4 apaches with mod_proxy which connect to 4 tomcats. 
 In front of the apaches is a hardware balancer which does
 round-robin, but with a kind of sticky TCP-sessions, so mostly the
 clients on the web stay on the same server. Mostly...

Why not use mod_jk's session stickiness? The httpd server can be chosen
randomly by the hw lb, but the right Tomcat always gets the request.
Then, you can forget about session replication and get better
performance. On the other hand, if your users cannot be expected to
tolerate interruptions (due to a failing server) then you'll /have/ to
go with some kind of replication.

 To be completely safe and sleep well, I would like to replicate the 
 sessions now, and in the mentioned document I read that it is
 possible using the PersistenceManager with JDBCStore.

Just note that this is probably the slowest of the 3 options presented
in the Replication HOWTO, since each session attribute will have to be
retrieved from the database every time. Option #3 (in-memory
replication) will probably be the fastest option for a cluster such as
yours, especially if all the members of the cluster are on the same
(real) network.

 My question now: Is it enough to set up PersistenceManager with
 JDBCStore on my 4 tomcats to use the same database/table as session
 store ?

It should be.

 Or do I need to mess with ReplicationValve and jvmRoute set up as
 well ?

No, but I think using real replication will give you better performance.

 I will put my server.xml at the end of the file, which is set up
 with JDBCStore using a Firebird Database with JayBird.

How are you sharing your database across your 4 Tomcat instances?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAko5RwoACgkQ9CaO5/Lv0PDK/wCffEK2IfLU3urah7UO4c8+NV2w
VOMAn2ly1yE2CO3+PdglPRj2k9plFn5F
=qeVK
-END PGP SIGNATURE-

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

RE: Session replication fails on ReplicationValve invocation

[Martin Gainty]

Hello Dave

that line from ReplicationManager is getManager()
Manager manager = request.getContext().getManager();

i would check to make sure the Manager node in /context.xml

!-- The contents of this file will be loaded for each web application --
Context

!-- Default set of monitored resources --
WatchedResourceWEB-INF/web.xml/WatchedResource

!-- Uncomment this to disable session persistence across Tomcat restarts 
--
Manager pathname=/ /

!-- Uncomment this to enable Comet connection tacking (provides events
 on session expiration as well as webapp lifecycle) --
!--
Valve className=org.apache.catalina.valves.CometConnectionManagerValve /
--
/Context

all explained here 
http://www.scribd.com/doc/15490833/Tomcat-The-Definitive-Guide-by-OReilly-Media

Cheers,
Martin 
__ 
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
 
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem 
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. 
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung 
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est 
interdite. Ce message sert à l'information seulement et n'aura pas n'importe 
quel effet légalement obligatoire. Étant donné que les email peuvent facilement 
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité 
pour le contenu fourni.




 From: dnill...@une.edu.au
 To: users@tomcat.apache.org
 Date: Thu, 18 Jun 2009 10:24:20 +1000
 Subject: Session replication fails on ReplicationValve invocation
 
 Hi,
 I'm currently trying to establish a cluster of tomcat 5.5.27 
 servers to deploy sakai in, so I'm stuck on version 5.5. It is not an option 
 to upgrade to tomcat 6 which from all accounts has much better session 
 replication.
 
 I have cluster membership up and working via multicast and the two nodes add 
 each other as replication targets. When I try to establish a connection to 
 the server  from my web browser to the default port of 8080 I get this neat 
 error in my catalina.out:
 
 ERROR: An exception or error occurred in the container during the request 
 processing (2009-06-17 16:43:49,545 
 http-172.31.3.37-8080-Processor5_org.apache.catalina.connector.CoyoteAdapter)
 java.lang.NullPointerException
 at 
 org.apache.catalina.cluster.tcp.ReplicationValve.invoke(ReplicationValve.java:348)
 
 I'll put full errors and configs at the bottom of the email. The errors 
 occurs regardless of whether I access an empty/nonexistent context or the 
 servlet-examples which are currently installed.
 
 The servers are multi homed with 3 interfaces. Eth0 is the 
 primary public interface, eth1 is my iSCSI network and eth2 is the backend 
 cluster network. All neatly VLANd from each other in seperate subnets. 
 Multicast membership works, I can see the packets arriving via tcpdump and 
 the membership propagation is occurring.
 I have tried binding the receivers to both public and private interfaces but 
 have had no luck. The receivers are up and appear to be functional. I can 
 telnet to  them and when I enter gibberish into the console it tell me I am 
 sending malformed headers.
 By using tcpdump and netstat I can see that neither tomcat instance is 
 originating a sender session to connect to the other servers receiver.
 
 I have tried fastsyncqueue and pooled style senders from the documentation. 
 Currently configured for pooled as it looked the simpler config to diagnose. 
 jvmRoute is configured via -D options passed to java as a lot of our configs 
 are done dynamically so as to have a single server.xml across the cluster 
 environments. We have a shared disk backend system to enable this.
 
 Any suggestions for diagnosis, help, fixes or otherwise would be very much 
 appreciated.
 
 Regards,
 Dave
 
 Log file and startup:
 INFO: The Apache Tomcat Native library which allows optimal performance in 
 production environments was not found on the java.library.path: 
 /apps/java/jdk1.5.0_19/jre/lib/amd64/server:/apps/java/jdk1.5.0_19/jre/lib/amd64:/apps/java/jdk1.5
 .0_19/jre/../lib/amd64 (2009-06-17 16:40:36,874 
 main_org.apache.catalina.core.AprLifecycleListener)
 INFO: Initializing Coyote HTTP/1.1 on http-172.31.3.37-8080 (2009-06-17 
 16:40:37,019 main_org.apache.coyote.http11.Http11BaseProtocol)
 INFO: Initialization processed in 1400 ms (2009-06-17 16:40:37,021 
 main_org.apache.catalina.startup.Catalina)
 INFO: Set JAAS app name ENGINE 

RE: Session replication fails on ReplicationValve invocation

[David Nillesen]

I think I may have sorted the problem. Would that have occurred if I was asking 
for a webpage without a context? i.e. just hitting some undefined area?

Thanks,
Dave

--
David Nillesen
UNIX Systems Administrator
Ph: + 61 2 6773 2112

-Original Message-
From: Martin Gainty [mailto:mgai...@hotmail.com]
Sent: Thursday, 18 June 2009 12:06 PM
To: Tomcat Users List
Subject: RE: Session replication fails on ReplicationValve invocation


Hello Dave

that line from ReplicationManager is getManager()
Manager manager = request.getContext().getManager();

i would check to make sure the Manager node in /context.xml

!-- The contents of this file will be loaded for each web application --
Context

!-- Default set of monitored resources --
WatchedResourceWEB-INF/web.xml/WatchedResource

!-- Uncomment this to disable session persistence across Tomcat restarts 
--
Manager pathname=/ /

!-- Uncomment this to enable Comet connection tacking (provides events
 on session expiration as well as webapp lifecycle) --
!--
Valve className=org.apache.catalina.valves.CometConnectionManagerValve /
--
/Context

all explained here
http://www.scribd.com/doc/15490833/Tomcat-The-Definitive-Guide-by-OReilly-Media

Cheers,
Martin
__
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem 
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. 
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung 
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est 
interdite. Ce message sert à l'information seulement et n'aura pas n'importe 
quel effet légalement obligatoire. Étant donné que les email peuvent facilement 
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité 
pour le contenu fourni.




 From: dnill...@une.edu.au
 To: users@tomcat.apache.org
 Date: Thu, 18 Jun 2009 10:24:20 +1000
 Subject: Session replication fails on ReplicationValve invocation

 Hi,
 I'm currently trying to establish a cluster of tomcat 5.5.27 
 servers to deploy sakai in, so I'm stuck on version 5.5. It is not an option 
 to upgrade to tomcat 6 which from all accounts has much better session 
 replication.

 I have cluster membership up and working via multicast and the two nodes add 
 each other as replication targets. When I try to establish a connection to 
 the server  from my web browser to the default port of 8080 I get this neat 
 error in my catalina.out:


 ERROR: An exception or error occurred in the container during the request 
 processing (2009-06-17 16:43:49,545 
 http-172.31.3.37-8080-Processor5_org.apache.catalina.connector.CoyoteAdapter)
 java.lang.NullPointerException
 at 
 org.apache.catalina.cluster.tcp.ReplicationValve.invoke(ReplicationValve.java:348)

 I'll put full errors and configs at the bottom of the email. The errors 
 occurs regardless of whether I access an empty/nonexistent context or the 
 servlet-examples which are currently installed.

 The servers are multi homed with 3 interfaces. Eth0 is the 
 primary public interface, eth1 is my iSCSI network and eth2 is the backend 
 cluster network. All neatly VLANd from each other in seperate subnets. 
 Multicast membership works, I can see the packets arriving via tcpdump and 
 the membership propagation is occurring.
 I have tried binding the receivers to both public and private interfaces but 
 have had no luck. The receivers are up and appear to be functional. I can 
 telnet to  them and when I enter gibberish into the console it tell me I am 
 sending malformed headers.

 By using tcpdump and netstat I can see that neither tomcat instance is 
 originating a sender session to connect to the other servers receiver.

 I have tried fastsyncqueue and pooled style senders from the documentation. 
 Currently configured for pooled as it looked the simpler config to diagnose. 
 jvmRoute is configured via -D options passed to java as a lot of our configs 
 are done dynamically so as to have a single server.xml across the cluster 
 environments. We have a shared disk backend system to enable this.

 Any suggestions for diagnosis, help, fixes or otherwise would be very much 
 appreciated.

 Regards,
 Dave

 Log file and startup:
 INFO: The Apache Tomcat Native library which allows optimal performance in 
 production environments was not found on the java.library.path: 
 /apps/java/jdk1.5.0_19/jre/lib/amd64/server:/apps/java

Re: Session Replication problem

[Filip Hanik - Dev Lists]

no all operating systems support a bind address for multicast sockets

socket = new MulticastSocket(new InetSocketAddress(address,port));

Filip

sudhakar p wrote:

Hi

I am trying to configure Clustering/Session Replication in Tomcat 6.0.18 and
am getting this message when I start the tomcat 6.0.18  server.

*INFO  org.apache.catalina.tribes.membership.McastService - Binding to
multicast address, failed. Binding to port only*

Tomact log:
2009-05-01 12:00:06,400 [main] INFO
org.apache.catalina.core.StandardService - Starting service Catalina
2009-05-01 12:00:06,401 [main] INFO  org.apache.catalina.core.StandardEngine
- Starting Servlet Engine: Apache Tomcat/6.0.18
2009-05-01 12:00:06,409 [main] INFO
org.apache.catalina.ha.tcp.SimpleTcpCluster - Cluster is about to start
2009-05-01 12:00:06,555 [main] INFO
org.apache.catalina.tribes.transport.ReceiverBase - Receiver Server Socket
bound to:/172.31.3.10:28512
2009-05-01 12:00:06,600 [main] INFO
org.apache.catalina.tribes.membership.McastService - Attempting to bind the
multicast socket to /228.0.0.4:18512
2009-05-01 12:00:06,763 [main] INFO
org.apache.catalina.tribes.membership.McastService - Binding to multicast
address, failed. Binding to port only.
2009-05-01 12:00:06,764 [main] INFO
org.apache.catalina.tribes.membership.McastService - Setting multihome
multicast interface to:/172.31.3.10
2009-05-01 12:00:06,765 [main] INFO
org.apache.catalina.tribes.membership.McastService - Setting cluster mcast
soTimeout to 500
2009-05-01 12:00:06,982 [main] INFO
org.apache.catalina.tribes.membership.McastService - Sleeping for 1000
milliseconds to establish cluster membership, start level:4
2009-05-01 12:00:08,033 [main] INFO
org.apache.catalina.tribes.membership.McastService - Done sleeping,
membership established, start level:4
2009-05-01 12:00:08,042 [main] INFO
org.apache.catalina.tribes.membership.McastService - Sleeping for 1000
milliseconds to establish cluster membership, start level:8
2009-05-01 12:00:09,044 [main] INFO
org.apache.catalina.tribes.membership.McastService - Done sleeping,
membership established, start level:8
2009-05-01 12:00:09,072 [main] INFO
org.apache.catalina.ha.session.JvmRouteBinderValve - JvmRouteBinderValve
started

Config:
Membership className=org.apache.catalina.tribes.membership.McastService
address=230.0.0.10
port=18512
bind=172.31.3.12
domain=ramm.bftg.com/
Receiver
className=org.apache.catalina.tribes.transport.nio.NioReceiver
address=172.31.3.12
port=28512
timeout=100/

Can anybody help me pls ?

Thanks in Advance

Raju

  



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

Re: Session Replication problem

[sudhakar p]

Hi Filip,

Thanks for your reply

My server OS is Linux Red Hat Enterprise Linux Server release 5.3 which will
be support MULTICAST.

Please help to fix the problem

Thanks in Advance


Raju



On Fri, May 8, 2009 at 8:50 AM, Filip Hanik - Dev Lists
devli...@hanik.comwrote:

 no all operating systems support a bind address for multicast sockets

 socket = new MulticastSocket(new InetSocketAddress(address,port));

 Filip


 sudhakar p wrote:

 Hi

 I am trying to configure Clustering/Session Replication in Tomcat 6.0.18
 and
 am getting this message when I start the tomcat 6.0.18  server.

 *INFO  org.apache.catalina.tribes.membership.McastService - Binding to
 multicast address, failed. Binding to port only*

 Tomact log:
 2009-05-01 12:00:06,400 [main] INFO
 org.apache.catalina.core.StandardService - Starting service Catalina
 2009-05-01 12:00:06,401 [main] INFO
  org.apache.catalina.core.StandardEngine
 - Starting Servlet Engine: Apache Tomcat/6.0.18
 2009-05-01 12:00:06,409 [main] INFO
 org.apache.catalina.ha.tcp.SimpleTcpCluster - Cluster is about to start
 2009-05-01 12:00:06,555 [main] INFO
 org.apache.catalina.tribes.transport.ReceiverBase - Receiver Server Socket
 bound to:/172.31.3.10:28512
 2009-05-01 12:00:06,600 [main] INFO
 org.apache.catalina.tribes.membership.McastService - Attempting to bind
 the
 multicast socket to /228.0.0.4:18512
 2009-05-01 12:00:06,763 [main] INFO
 org.apache.catalina.tribes.membership.McastService - Binding to multicast
 address, failed. Binding to port only.
 2009-05-01 12:00:06,764 [main] INFO
 org.apache.catalina.tribes.membership.McastService - Setting multihome
 multicast interface to:/172.31.3.10
 2009-05-01 12:00:06,765 [main] INFO
 org.apache.catalina.tribes.membership.McastService - Setting cluster mcast
 soTimeout to 500
 2009-05-01 12:00:06,982 [main] INFO
 org.apache.catalina.tribes.membership.McastService - Sleeping for 1000
 milliseconds to establish cluster membership, start level:4
 2009-05-01 12:00:08,033 [main] INFO
 org.apache.catalina.tribes.membership.McastService - Done sleeping,
 membership established, start level:4
 2009-05-01 12:00:08,042 [main] INFO
 org.apache.catalina.tribes.membership.McastService - Sleeping for 1000
 milliseconds to establish cluster membership, start level:8
 2009-05-01 12:00:09,044 [main] INFO
 org.apache.catalina.tribes.membership.McastService - Done sleeping,
 membership established, start level:8
 2009-05-01 12:00:09,072 [main] INFO
 org.apache.catalina.ha.session.JvmRouteBinderValve - JvmRouteBinderValve
 started

 Config:
 Membership className=org.apache.catalina.tribes.membership.McastService
address=230.0.0.10
port=18512
bind=172.31.3.12
domain=ramm.bftg.com/
Receiver
 className=org.apache.catalina.tribes.transport.nio.NioReceiver
address=172.31.3.12
port=28512
timeout=100/

 Can anybody help me pls ?

 Thanks in Advance

 Raju





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

Re: Session Replication problem

[Filip Hanik - Dev Lists]

I don't think Linux supports binding to an interface for multicast. 
Multicast still works, you just can't bind it, instead you setup your 
routing table to make sure you route it the way you want.
the other way you can do is setup static memberships, where you define 
your tomcat instances instead.



Filip

sudhakar p wrote:

Hi Filip,

Thanks for your reply

My server OS is Linux Red Hat Enterprise Linux Server release 5.3 which will
be support MULTICAST.

Please help to fix the problem

Thanks in Advance


Raju



On Fri, May 8, 2009 at 8:50 AM, Filip Hanik - Dev Lists
devli...@hanik.comwrote:

  

no all operating systems support a bind address for multicast sockets

socket = new MulticastSocket(new InetSocketAddress(address,port));

Filip


sudhakar p wrote:



Hi

I am trying to configure Clustering/Session Replication in Tomcat 6.0.18
and
am getting this message when I start the tomcat 6.0.18  server.

*INFO  org.apache.catalina.tribes.membership.McastService - Binding to
multicast address, failed. Binding to port only*

Tomact log:
2009-05-01 12:00:06,400 [main] INFO
org.apache.catalina.core.StandardService - Starting service Catalina
2009-05-01 12:00:06,401 [main] INFO
 org.apache.catalina.core.StandardEngine
- Starting Servlet Engine: Apache Tomcat/6.0.18
2009-05-01 12:00:06,409 [main] INFO
org.apache.catalina.ha.tcp.SimpleTcpCluster - Cluster is about to start
2009-05-01 12:00:06,555 [main] INFO
org.apache.catalina.tribes.transport.ReceiverBase - Receiver Server Socket
bound to:/172.31.3.10:28512
2009-05-01 12:00:06,600 [main] INFO
org.apache.catalina.tribes.membership.McastService - Attempting to bind
the
multicast socket to /228.0.0.4:18512
2009-05-01 12:00:06,763 [main] INFO
org.apache.catalina.tribes.membership.McastService - Binding to multicast
address, failed. Binding to port only.
2009-05-01 12:00:06,764 [main] INFO
org.apache.catalina.tribes.membership.McastService - Setting multihome
multicast interface to:/172.31.3.10
2009-05-01 12:00:06,765 [main] INFO
org.apache.catalina.tribes.membership.McastService - Setting cluster mcast
soTimeout to 500
2009-05-01 12:00:06,982 [main] INFO
org.apache.catalina.tribes.membership.McastService - Sleeping for 1000
milliseconds to establish cluster membership, start level:4
2009-05-01 12:00:08,033 [main] INFO
org.apache.catalina.tribes.membership.McastService - Done sleeping,
membership established, start level:4
2009-05-01 12:00:08,042 [main] INFO
org.apache.catalina.tribes.membership.McastService - Sleeping for 1000
milliseconds to establish cluster membership, start level:8
2009-05-01 12:00:09,044 [main] INFO
org.apache.catalina.tribes.membership.McastService - Done sleeping,
membership established, start level:8
2009-05-01 12:00:09,072 [main] INFO
org.apache.catalina.ha.session.JvmRouteBinderValve - JvmRouteBinderValve
started

Config:
Membership className=org.apache.catalina.tribes.membership.McastService
   address=230.0.0.10
   port=18512
   bind=172.31.3.12
   domain=ramm.bftg.com/
   Receiver
className=org.apache.catalina.tribes.transport.nio.NioReceiver
   address=172.31.3.12
   port=28512
   timeout=100/

Can anybody help me pls ?

Thanks in Advance

Raju



  

-
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: Session Replication problems

[Filip Hanik - Dev Lists]

we'd need the entire stacktrace, not just a snippet for it to be helpful 
to us.


Filip

Mohamedin wrote:

Dear All,

I use these configuration to enable session replication:


Master server:

Engine name=Catalina defaultHost=localhost jvmRoute=master
Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster 
channelSendOptions=8
Manager className=org.apache.catalina.ha.session.DeltaManager 
expireSessionsOnShutdown=false notifyListenersOnReplication=true domainReplication=true 
/
Channel 
className=org.apache.catalina.tribes.group.GroupChannel
Membership 
className=org.apache.catalina.tribes.membership.McastService port=5000/
Sender 
className=org.apache.catalina.tribes.transport.ReplicationTransmitter
Transport 
className=org.apache.catalina.tribes.transport.nio.PooledParallelSender /
/Sender
Receiver 
className=org.apache.catalina.tribes.transport.nio.NioReceiver
address=111.111.111.111 port=6000 autoBind=100 
selectorTimeout=5000
maxThreads=6 /
Interceptor 
className=org.apache.catalina.tribes.group.interceptors.TcpFailureDetector /
Interceptor 
className=org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor
 /
Interceptor 
className=org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor
Member 
className=org.apache.catalina.tribes.membership.StaticMember
port=6000 securePort=-1 host=111.111.111.222 
domain=111.111.111.222 /
Member 
className=org.apache.catalina.tribes.membership.StaticMember
port=6000 securePort=-1 host=111.111.111.223 
domain=111.111.111.223 /
Member 
className=org.apache.catalina.tribes.membership.StaticMember
port=6000 securePort=-1 host=111.111.111.224 
domain=111.111.111.224 /
/Interceptor
/Channel
Valve className=org.apache.catalina.ha.tcp.ReplicationValve 
filter= /
ClusterListener 
className=org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener /
ClusterListener 
className=org.apache.catalina.ha.session.ClusterSessionListener /
/Cluster


===
S2 server:
===
Engine name=Catalina defaultHost=localhost jvmRoute=s2

Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster 
channelSendOptions=8
Manager className=org.apache.catalina.ha.session.DeltaManager 
expireSessionsOnShutdown=false notifyListenersOnReplication=true domainReplication=true 
/
Channel 
className=org.apache.catalina.tribes.group.GroupChannel
Membership 
className=org.apache.catalina.tribes.membership.McastService port=5000/
Sender 
className=org.apache.catalina.tribes.transport.ReplicationTransmitter
Transport 
className=org.apache.catalina.tribes.transport.nio.PooledParallelSender /
/Sender
Receiver 
className=org.apache.catalina.tribes.transport.nio.NioReceiver
address=111.111.111.223 port=6000 autoBind=100 
selectorTimeout=5000
maxThreads=6 /
Interceptor 
className=org.apache.catalina.tribes.group.interceptors.TcpFailureDetector /
Interceptor 
className=org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor
 /
Interceptor 
className=org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor
Member 
className=org.apache.catalina.tribes.membership.StaticMember
port=6000 securePort=-1 host=111.111.111.111 
domain=111.111.111.111 /
Member 
className=org.apache.catalina.tribes.membership.StaticMember
port=6000 securePort=-1 host=111.111.111.222 
domain=111.111.111.222 /
Member 
className=org.apache.catalina.tribes.membership.StaticMember
port=6000 securePort=-1 host=111.111.111.224 
domain=111.111.111.224 /
/Interceptor
/Channel
Valve className=org.apache.catalina.ha.tcp.ReplicationValve 
filter= /
ClusterListener 
className=org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener /
ClusterListener 
className=org.apache.catalina.ha.session.ClusterSessionListener /
/Cluster


==
S3 server:
==

Engine name=Catalina defaultHost=localhost 

Re: Session Replication in Cluster

[Filip Hanik - Dev Lists]

what you're seeing is correct.
the server did fail over, and by changing the session id, it ensures 
that it does not do fail back


Filip

Roy McMorran wrote:

Hello all,


I've built a very simple 2-member Tomcat cluster for testing, but I am 
unable to get the session replication quite right.  The problem is 
when I fail one member of the cluster.  The behavior I was expecting 
is that the other cluster member would take over the session ids for 
the failed member.  However it is appending it's own jvmRoute value to 
the session id, and thus setting a new cookie.



Details:
I have 2 cluster members, itchy and scratchy, running on the same 
physical server, and CATALINA_BASE is /var/tomcat/itchy and 
/var/tomcat/scratchy respectively.  Tomcat 6.0.18 binaries, etc. are 
at /usr/local/tomcat.  Using mod_jk 1.2.27 on Apache 2.2.11 (Apache is 
also on the same server).  I am using sticky sessions.



Here are the access logs for the 2 members from a short failover 
experiment (note I'm including the session ID in the 2nd field).  The 
session starts on scratchy.  From scratchy_access_log.2009-04-02.txt:


192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.scratchy - 
[02/Apr/2009:10:19:55 -0400] GET / HTTP/1.1 200 14612
192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.scratchy - 
[02/Apr/2009:10:20:14 -0400] GET /about/ HTTP/1.1 200 19507



At 10:21:39 AM I do a kill -9 on the scratchy instance.  Now the 
traffic goes to the other cluster member as expected.  From 
itchy_access_log.2009-04-02.txt:


192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.itchy - 
[02/Apr/2009:10:22:11 -0400] GET /about/publications/ HTTP/1.1 200 
18263
192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.itchy - 
[02/Apr/2009:10:22:32 -0400] GET /about/changes/ HTTP/1.1 200 12736



Note however that the new member's jvmRoute value is now appended to 
the session id.  I thought is was supposed to stay exactly the same 
after failover.



Additional details can be found as follows:

server.xml for itchy - see:
http://gillnet.mdibl.org/~mcmorran/itchy-server.xml.txt

server.xml for scratchy - see:
http://gillnet.mdibl.org/~mcmorran/scratchy-server.xml.txt

context.xml (identical) - see:
https://gillnet.mdibl.org/~mcmorran/context.xml.txt

workers.properties:
https://gillnet.mdibl.org/~mcmorran/workers.properties

I've also included the catalina.out file for both, from startup and 
through the test at:

https://gillnet.mdibl.org/~mcmorran/itchy-catalina.out
https://gillnet.mdibl.org/~mcmorran/scratchy-catalina.out


I'd appreciate any advice on where I went wrong.  Thanks and best wishes,
Roy




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

Re: Session Replication in Cluster

[János Löbb]

To stick with the analogy:

 Your session's baby part is: FEBA6A8127A69079C79B7A641158CE20 and  
that remains the same if with daddy or mommy.


Your session's daddy part is: itchy
and
Your session's mommy part is: scratchy

Enjoy them :)

János

On Apr 3, 2009, at 5:32 PM, Roy McMorran wrote:


János Löbb wrote:


If You look the values created by the session earlier  
with ...node1, than You will see the same values after fail over  
with ...node2.  A new session would not know about them.


To verify it You can use the supplied SessionExmaple webapp.


OK, trying that.

So, using an example webapp (see:
https://gillnet.mdibl.org/~mcmorran/session.jsp.txt

(which just uses session.getID() )

...should it return *just* the session ID part, or the concatenation  
of the session ID and the jvmRoute?


Here's what I see:

Before failover:
This is the session id FEBA6A8127A69079C79B7A641158CE20.itchy
This is an existing session

After failover:
This is the session id FEBA6A8127A69079C79B7A641158CE20.scratchy
This is an existing session

Thanks,
-r

--
Roy McMorran
Systems Administrator
MDI Biological Laboratory
mcmor...@mdibl.org



-
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: Session Replication in Cluster

[Roy McMorran]

Hi Jorge, thanks for the reply.

Actually no, these are the access logs from the Tomcat cluster members; 
you can view the corresponding AccessLogValve entries in the server.xml 
files referenced below.


I included those logs for illustration, but I have confirmed that those 
are the actual session IDs at the browser.  After the failover the new 
Tomcat cluster member sends a new Set-Cookie header with the new session ID.


You're right that the first portion of the session ID does seem to be 
replicated properly, but I thought it was the function of 
JvmRouteBinderValve to update the entire session ID in a failover, 
including the jvmRoute portion.


Best wishes,
Roy

Jorge Medina wrote:

Are your logs Apache logs? Mod_jk logs?

If it is Apache, the question would probably better answer in the Apache
mailing list. 
Anyway, What does your LogFormat string looks like? 


I bet what you see in the logs is the concatenation of the session ID
and the worker name. I doubt two servers would generate the same hex
digits for the session. Therefore, your server must be working as
expected, you are just interpreting the logs incorrectly.

-Original Message-
From: Roy McMorran [mailto:mcmor...@mdibl.org] 
Sent: Thursday, April 02, 2009 10:59 AM

To: Tomcat Users List
Subject: Session Replication in Cluster

Hello all,


I've built a very simple 2-member Tomcat cluster for testing, but I am
unable to get the session replication quite right.  The problem is when
I fail one member of the cluster.  The behavior I was expecting is that
the other cluster member would take over the session ids for the failed
member.  However it is appending it's own jvmRoute value to the session
id, and thus setting a new cookie.


Details:
I have 2 cluster members, itchy and scratchy, running on the same
physical server, and CATALINA_BASE is /var/tomcat/itchy and
/var/tomcat/scratchy respectively.  Tomcat 6.0.18 binaries, etc. are at
/usr/local/tomcat.  Using mod_jk 1.2.27 on Apache 2.2.11 (Apache is also
on the same server).  I am using sticky sessions.


Here are the access logs for the 2 members from a short failover 
experiment (note I'm including the session ID in the 2nd field).  The

session starts on scratchy.  From scratchy_access_log.2009-04-02.txt:

192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.scratchy -
[02/Apr/2009:10:19:55 -0400] GET / HTTP/1.1 200 14612
192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.scratchy -
[02/Apr/2009:10:20:14 -0400] GET /about/ HTTP/1.1 200 19507


At 10:21:39 AM I do a kill -9 on the scratchy instance.  Now the traffic
goes to the other cluster member as expected.  From
itchy_access_log.2009-04-02.txt:

192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.itchy -
[02/Apr/2009:10:22:11 -0400] GET /about/publications/ HTTP/1.1 200
18263
192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.itchy -
[02/Apr/2009:10:22:32 -0400] GET /about/changes/ HTTP/1.1 200 12736


Note however that the new member's jvmRoute value is now appended to the
session id.  I thought is was supposed to stay exactly the same after
failover.


Additional details can be found as follows:

server.xml for itchy - see:
http://gillnet.mdibl.org/~mcmorran/itchy-server.xml.txt

server.xml for scratchy - see:
http://gillnet.mdibl.org/~mcmorran/scratchy-server.xml.txt

context.xml (identical) - see:
https://gillnet.mdibl.org/~mcmorran/context.xml.txt

workers.properties:
https://gillnet.mdibl.org/~mcmorran/workers.properties

I've also included the catalina.out file for both, from startup and
through the test at:
https://gillnet.mdibl.org/~mcmorran/itchy-catalina.out
https://gillnet.mdibl.org/~mcmorran/scratchy-catalina.out


I'd appreciate any advice on where I went wrong.  Thanks and best
wishes,
Roy

  



--
Roy McMorran
Systems Administrator
MDI Biological Laboratory
mcmor...@mdibl.org



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

Re: Session Replication in Cluster

[Mark Thomas]

Roy McMorran wrote:
 Hi Jorge, thanks for the reply.
 
 Actually no, these are the access logs from the Tomcat cluster members;
 you can view the corresponding AccessLogValve entries in the server.xml
 files referenced below.
 
 I included those logs for illustration, but I have confirmed that those
 are the actual session IDs at the browser.  After the failover the new
 Tomcat cluster member sends a new Set-Cookie header with the new session
 ID.
 
 You're right that the first portion of the session ID does seem to be
 replicated properly, but I thought it was the function of
 JvmRouteBinderValve to update the entire session ID in a failover,
 including the jvmRoute portion.

Nope. The job of that valve is to change the route - exactly what you
are seeing.

Mark

 
 Best wishes,
 Roy
 
 Jorge Medina wrote:
 Are your logs Apache logs? Mod_jk logs?

 If it is Apache, the question would probably better answer in the Apache
 mailing list. Anyway, What does your LogFormat string looks like?
 I bet what you see in the logs is the concatenation of the session ID
 and the worker name. I doubt two servers would generate the same hex
 digits for the session. Therefore, your server must be working as
 expected, you are just interpreting the logs incorrectly.

 -Original Message-
 From: Roy McMorran [mailto:mcmor...@mdibl.org] Sent: Thursday, April
 02, 2009 10:59 AM
 To: Tomcat Users List
 Subject: Session Replication in Cluster

 Hello all,


 I've built a very simple 2-member Tomcat cluster for testing, but I am
 unable to get the session replication quite right.  The problem is when
 I fail one member of the cluster.  The behavior I was expecting is that
 the other cluster member would take over the session ids for the failed
 member.  However it is appending it's own jvmRoute value to the session
 id, and thus setting a new cookie.


 Details:
 I have 2 cluster members, itchy and scratchy, running on the same
 physical server, and CATALINA_BASE is /var/tomcat/itchy and
 /var/tomcat/scratchy respectively.  Tomcat 6.0.18 binaries, etc. are at
 /usr/local/tomcat.  Using mod_jk 1.2.27 on Apache 2.2.11 (Apache is also
 on the same server).  I am using sticky sessions.


 Here are the access logs for the 2 members from a short failover
 experiment (note I'm including the session ID in the 2nd field).  The
 session starts on scratchy.  From scratchy_access_log.2009-04-02.txt:

 192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.scratchy -
 [02/Apr/2009:10:19:55 -0400] GET / HTTP/1.1 200 14612
 192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.scratchy -
 [02/Apr/2009:10:20:14 -0400] GET /about/ HTTP/1.1 200 19507


 At 10:21:39 AM I do a kill -9 on the scratchy instance.  Now the traffic
 goes to the other cluster member as expected.  From
 itchy_access_log.2009-04-02.txt:

 192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.itchy -
 [02/Apr/2009:10:22:11 -0400] GET /about/publications/ HTTP/1.1 200
 18263
 192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.itchy -
 [02/Apr/2009:10:22:32 -0400] GET /about/changes/ HTTP/1.1 200 12736


 Note however that the new member's jvmRoute value is now appended to the
 session id.  I thought is was supposed to stay exactly the same after
 failover.


 Additional details can be found as follows:

 server.xml for itchy - see:
 http://gillnet.mdibl.org/~mcmorran/itchy-server.xml.txt

 server.xml for scratchy - see:
 http://gillnet.mdibl.org/~mcmorran/scratchy-server.xml.txt

 context.xml (identical) - see:
 https://gillnet.mdibl.org/~mcmorran/context.xml.txt

 workers.properties:
 https://gillnet.mdibl.org/~mcmorran/workers.properties

 I've also included the catalina.out file for both, from startup and
 through the test at:
 https://gillnet.mdibl.org/~mcmorran/itchy-catalina.out
 https://gillnet.mdibl.org/~mcmorran/scratchy-catalina.out


 I'd appreciate any advice on where I went wrong.  Thanks and best
 wishes,
 Roy

   
 
 



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

Re: Session Replication in Cluster

[Roy McMorran]

Mark Thomas wrote:


Nope. The job of that valve is to change the route - exactly what you
are seeing.

  

Thanks Mark,

Is it the expected behavior then, that the 2nd part of the session ID 
changes after a failover, and a new cookie is set?


Thanks,
Roy

--
Roy McMorran
Systems Administrator
MDI Biological Laboratory
mcmor...@mdibl.org



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

Re: Session Replication in Cluster

[Mark Thomas]

Roy McMorran wrote:
 Mark Thomas wrote:

 Nope. The job of that valve is to change the route - exactly what you
 are seeing.

   
 Thanks Mark,
 
 Is it the expected behavior then, that the 2nd part of the session ID
 changes after a failover, and a new cookie is set?

Yes

Mark



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

Re: Session Replication in Cluster

[Roy McMorran]

Mark Thomas wrote:
Roy McMorran wrote: 
  

Thanks Mark,

Is it the expected behavior then, that the 2nd part of the session ID
changes after a failover, and a new cookie is set?



Yes

Mark
  


Interesting.  I am certain I saw the other behavior (both parts of the 
session ID were preserved) earlier in my testing, but I haven't been 
able to reproduce it since...now I know why.  Thanks for your help Mark 
and Jorge.


Cheers,
Roy

--
Roy McMorran
Systems Administrator
MDI Biological Laboratory
mcmor...@mdibl.org



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

Re: Session Replication in Cluster

[Roy McMorran]

Mark Thomas wrote:

Roy McMorran wrote:
  

Is it the expected behavior then, that the 2nd part of the session ID
changes after a failover, and a new cookie is set?



Yes

  


OK, please bear with me here, I may be just showing my ignorance with 
respect to Tomcat and web applications in general, but...


If the session ID changes from ABC123.node1 to ABC123.node2, then 
you will start a new session at the browser.
If you are going to establish a new session anyway, why bother 
replicating the first part of the session ID at all?


Thanks,
-r

--
Roy McMorran
Systems Administrator
MDI Biological Laboratory
mcmor...@mdibl.org



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

RE: Session Replication in Cluster

[Caldarale, Charles R]

 From: Roy McMorran [mailto:mcmor...@mdibl.org]
 Subject: Re: Session Replication in Cluster
 
 If the session ID changes from ABC123.node1 to ABC123.node2, then
 you will start a new session at the browser.

No, you get a new *cookie* at the browser; the session is something only the 
server has cognizance of.  Assuming your session replication across nodes is 
working properly, the user sitting at the browser won't know that anything has 
changed.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

Re: Session Replication in Cluster

[János Löbb]

On Apr 3, 2009, at 3:31 PM, Roy McMorran wrote:


Mark Thomas wrote:

Roy McMorran wrote:

Is it the expected behavior then, that the 2nd part of the session  
ID

changes after a failover, and a new cookie is set?



Yes




OK, please bear with me here, I may be just showing my ignorance  
with respect to Tomcat and web applications in general, but...


If the session ID changes from ABC123.node1 to ABC123.node2,  
then you will start a new session at the browser.
If you are going to establish a new session anyway, why bother  
replicating the first part of the session ID at all?


Thanks,
-r

--
Roy McMorran
Systems Administrator
MDI Biological Laboratory
mcmor...@mdibl.org



If You look the values created by the session earlier  
with ...node1, than You will see the same values after fail over  
with ...node2.  A new session would not know about them.


To verify it You can use the supplied SessionExmaple webapp.

It is like passing a baby among family members and making a snapshot.   
As long as the baby the same everything is alright :)


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

Re: Session Replication in Cluster

[Roy McMorran]

Caldarale, Charles R wrote:

From: Roy McMorran [mailto:mcmor...@mdibl.org]
Subject: Re: Session Replication in Cluster

If the session ID changes from ABC123.node1 to ABC123.node2, then
you will start a new session at the browser.



No, you get a new *cookie* at the browser; the session is something only the 
server has cognizance of.  Assuming your session replication across nodes is 
working properly, the user sitting at the browser won't know that anything has 
changed.

  
Thanks Chuck, that was helpful.  I think I was being misled by the 
behavior of the application I'm trying to cluster.  It looked like a 
whole new session had been established after the failover, but upon 
closer investigation I can see now that is not the case.


Best wishes,
-r


--
Roy McMorran
Systems Administrator
MDI Biological Laboratory
mcmor...@mdibl.org



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

Re: Session Replication in Cluster

[Roy McMorran]

János Löbb wrote:


If You look the values created by the session earlier with 
...node1, than You will see the same values after fail over with 
...node2.  A new session would not know about them.


To verify it You can use the supplied SessionExmaple webapp.

It is like passing a baby among family members and making a snapshot.  
As long as the baby the same everything is alright :)



Thank you János, that is a great analogy!  Appreciate your reply.

Cheers,
-r

--
Roy McMorran
Systems Administrator
MDI Biological Laboratory
mcmor...@mdibl.org



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

Re: Session Replication in Cluster

[Roy McMorran]

János Löbb wrote:


If You look the values created by the session earlier with 
...node1, than You will see the same values after fail over with 
...node2.  A new session would not know about them.


To verify it You can use the supplied SessionExmaple webapp.


OK, trying that.

So, using an example webapp (see:
https://gillnet.mdibl.org/~mcmorran/session.jsp.txt

(which just uses session.getID() )

...should it return *just* the session ID part, or the concatenation of 
the session ID and the jvmRoute?


Here's what I see:

Before failover:
This is the session id FEBA6A8127A69079C79B7A641158CE20.itchy
This is an existing session

After failover:
This is the session id FEBA6A8127A69079C79B7A641158CE20.scratchy
This is an existing session

Thanks,
-r

--
Roy McMorran
Systems Administrator
MDI Biological Laboratory
mcmor...@mdibl.org



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

Re: Session Replication in Cluster

[Mark Thomas]

Roy McMorran wrote:
 János Löbb wrote:

 If You look the values created by the session earlier with
 ...node1, than You will see the same values after fail over with
 ...node2.  A new session would not know about them.

 To verify it You can use the supplied SessionExmaple webapp.
 
 OK, trying that.
 
 So, using an example webapp (see:
 https://gillnet.mdibl.org/~mcmorran/session.jsp.txt
 
 (which just uses session.getID() )
 
 ...should it return *just* the session ID part, or the concatenation of
 the session ID and the jvmRoute?
 
 Here's what I see:
 
 Before failover:
 This is the session id FEBA6A8127A69079C79B7A641158CE20.itchy
 This is an existing session
 
 After failover:
 This is the session id FEBA6A8127A69079C79B7A641158CE20.scratchy
 This is an existing session

Which is 100% correct and expected behaviour. The session ID *has* to
change as the last part, the route, is used by the load balancer to
maintain session stickiness. The contents of both of those sessions will
be identical.

Mark



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

RE: Session Replication in Cluster

[Jorge Medina]

Are your logs Apache logs? Mod_jk logs?

If it is Apache, the question would probably better answer in the Apache
mailing list. 
Anyway, What does your LogFormat string looks like? 

I bet what you see in the logs is the concatenation of the session ID
and the worker name. I doubt two servers would generate the same hex
digits for the session. Therefore, your server must be working as
expected, you are just interpreting the logs incorrectly.

-Original Message-
From: Roy McMorran [mailto:mcmor...@mdibl.org] 
Sent: Thursday, April 02, 2009 10:59 AM
To: Tomcat Users List
Subject: Session Replication in Cluster

Hello all,


I've built a very simple 2-member Tomcat cluster for testing, but I am
unable to get the session replication quite right.  The problem is when
I fail one member of the cluster.  The behavior I was expecting is that
the other cluster member would take over the session ids for the failed
member.  However it is appending it's own jvmRoute value to the session
id, and thus setting a new cookie.


Details:
I have 2 cluster members, itchy and scratchy, running on the same
physical server, and CATALINA_BASE is /var/tomcat/itchy and
/var/tomcat/scratchy respectively.  Tomcat 6.0.18 binaries, etc. are at
/usr/local/tomcat.  Using mod_jk 1.2.27 on Apache 2.2.11 (Apache is also
on the same server).  I am using sticky sessions.


Here are the access logs for the 2 members from a short failover 
experiment (note I'm including the session ID in the 2nd field).  The
session starts on scratchy.  From scratchy_access_log.2009-04-02.txt:

192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.scratchy -
[02/Apr/2009:10:19:55 -0400] GET / HTTP/1.1 200 14612
192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.scratchy -
[02/Apr/2009:10:20:14 -0400] GET /about/ HTTP/1.1 200 19507


At 10:21:39 AM I do a kill -9 on the scratchy instance.  Now the traffic
goes to the other cluster member as expected.  From
itchy_access_log.2009-04-02.txt:

192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.itchy -
[02/Apr/2009:10:22:11 -0400] GET /about/publications/ HTTP/1.1 200
18263
192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.itchy -
[02/Apr/2009:10:22:32 -0400] GET /about/changes/ HTTP/1.1 200 12736


Note however that the new member's jvmRoute value is now appended to the
session id.  I thought is was supposed to stay exactly the same after
failover.


Additional details can be found as follows:

server.xml for itchy - see:
http://gillnet.mdibl.org/~mcmorran/itchy-server.xml.txt

server.xml for scratchy - see:
http://gillnet.mdibl.org/~mcmorran/scratchy-server.xml.txt

context.xml (identical) - see:
https://gillnet.mdibl.org/~mcmorran/context.xml.txt

workers.properties:
https://gillnet.mdibl.org/~mcmorran/workers.properties

I've also included the catalina.out file for both, from startup and
through the test at:
https://gillnet.mdibl.org/~mcmorran/itchy-catalina.out
https://gillnet.mdibl.org/~mcmorran/scratchy-catalina.out


I'd appreciate any advice on where I went wrong.  Thanks and best
wishes,
Roy

-- 
Roy McMorran
Systems Administrator
MDI Biological Laboratory
mcmor...@mdibl.org


-
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: Session replication problem

[Mohamedin]

Let me give an example:

I have server1 with tomcat8080  tomcat8081
server2 also with tomcat8080  tomcat8081

I need server1.tomcat8080  server2.tomcat8080 to replicate their sessions

and server1.tomcat8081  server2.tomcat8081 to replicate their sessions

What I see in the log is all see all sessions e.g.

server1.tomcat8080, server2.tomcat8080, server1.tomcat8081  
server2.tomcat8081 replicate the sessions all together



Thanks a lot,
Mohamedin
- Original Message - 
From: Filip Hanik - Dev Lists devli...@hanik.com

To: Tomcat Users List users@tomcat.apache.org
Sent: Tuesday, February 10, 2009 4:10 AM
Subject: Re: Session replication problem



Mohamedin wrote:
I have a problem with Session replication. I am running multible tomcat 
instance on the same server. And I have 4 servers of the same 
configuration (Multible tomcat instances). I have enabled the session 
replication on these 4 servers (In each instance with different port).


The problem is that All instances see each other. while I only need 
similar instances to see each other.


I'm not sure I understand what you are trying to achieve, what do you mean 
by similar


Filip


The config:


Engine name=Catalina defaultHost=localhost jvmRoute=myserver

 Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster 
channelSendOptions=8
 Manager 
className=org.apache.catalina.ha.session.DeltaManager
 expireSessionsOnShutdown=false 
notifyListenersOnReplication=true

 domainReplication=true /
 Channel 
className=org.apache.catalina.tribes.group.GroupChannel
 Sender 
className=org.apache.catalina.tribes.transport.ReplicationTransmitter
 Transport 
className=org.apache.catalina.tribes.transport.nio.PooledParallelSender 
/

 /Sender
 Receiver 
className=org.apache.catalina.tribes.transport.nio.NioReceiver
 address=245.245.245.245 port= 
autoBind=100 selectorTimeout=5000

 maxThreads=6 /
 Interceptor 
className=org.apache.catalina.tribes.group.interceptors.TcpFailureDetector 
/
 Interceptor 
className=org.apache.catalina.tribes.group.interceptors.MessageDispatch15Intercepto 
r /
 Interceptor 
className=org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor 

 Member 
className=org.apache.catalina.tribes.membership.StaticMember
 port= securePort=-1 
host=245.245.245.246 domain=245.245.245.246 /
 Member 
className=org.apache.catalina.tribes.membership.StaticMember
 port= securePort=-1 
host=245.245.245.247 domain=245.245.245.247 /
 Member 
className=org.apache.catalina.tribes.membership.StaticMember
 port= securePort=-1 
host=245.245.245.248 domain=245.245.245.248 /

 /Interceptor
 /Channel
 Valve 
className=org.apache.catalina.ha.tcp.ReplicationValve filter= /
 ClusterListener 
className=org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener 
/
 ClusterListener 
className=org.apache.catalina.ha.session.ClusterSessionListener /

 /Cluster
.
.
.

other instances use the same config (Only different port)


In the log I see:

07.02.2009 18:08:19 org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal 
performance in production environments was not found on the 
java.library.path: 
/usr/lib/jvm/java-1.5.0-sun-1.5.0.14/jre/lib/amd64/server:/usr/lib/jvm/java-1.5.0-sun-1.5.0.14/jre/lib/amd64:/usr/lib/jvm/java-1.5.0-sun-1.5.0.14/jre/../lib/amd64

07.02.2009 18:08:20 org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-8083
07.02.2009 18:08:20 org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 483 ms
07.02.2009 18:08:20 org.apache.catalina.core.StandardService start
INFO: Starting service Catalina
07.02.2009 18:08:20 org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.16
07.02.2009 18:08:20 org.apache.catalina.ha.tcp.SimpleTcpCluster start
INFO: Cluster is about to start
07.02.2009 18:08:20 org.apache.catalina.tribes.transport.ReceiverBase 
bind

INFO: Receiver Server Socket bound to:/245.245.245.245:
07.02.2009 18:08:20 
org.apache.catalina.tribes.membership.McastServiceImpl setupSocket

INFO: Setting cluster mcast soTimeout to 500
07.02.2009 18:08:20 
org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers
INFO: Sleeping for 1000 milliseconds to establish cluster membership, 
start level:4

Re: Session replication problem

[Filip Hanik - Dev Lists]

that's easy

I need server1.tomcat8080  server2.tomcat8080 to replicate their 
sessions


make sure 8080 server have Membership port=X/

and server1.tomcat8081  server2.tomcat8081 to replicate their sessions

and Membership port=Y/

http://tomcat.apache.org/tomcat-6.0-doc/config/cluster-membership.html

having a unique port will divide the membership

Filip

Mohamedin wrote:

Let me give an example:

I have server1 with tomcat8080  tomcat8081
server2 also with tomcat8080  tomcat8081

I need server1.tomcat8080  server2.tomcat8080 to replicate their 
sessions


and server1.tomcat8081  server2.tomcat8081 to replicate their sessions

What I see in the log is all see all sessions e.g.

server1.tomcat8080, server2.tomcat8080, server1.tomcat8081  
server2.tomcat8081 replicate the sessions all together



Thanks a lot,
Mohamedin
- Original Message - From: Filip Hanik - Dev Lists 
devli...@hanik.com

To: Tomcat Users List users@tomcat.apache.org
Sent: Tuesday, February 10, 2009 4:10 AM
Subject: Re: Session replication problem



Mohamedin wrote:
I have a problem with Session replication. I am running multible 
tomcat instance on the same server. And I have 4 servers of the same 
configuration (Multible tomcat instances). I have enabled the 
session replication on these 4 servers (In each instance with 
different port).


The problem is that All instances see each other. while I only need 
similar instances to see each other.


I'm not sure I understand what you are trying to achieve, what do you 
mean by similar


Filip


The config:


Engine name=Catalina defaultHost=localhost 
jvmRoute=myserver


 Cluster 
className=org.apache.catalina.ha.tcp.SimpleTcpCluster 
channelSendOptions=8
 Manager 
className=org.apache.catalina.ha.session.DeltaManager
 expireSessionsOnShutdown=false 
notifyListenersOnReplication=true

 domainReplication=true /
 Channel 
className=org.apache.catalina.tribes.group.GroupChannel
 Sender 
className=org.apache.catalina.tribes.transport.ReplicationTransmitter 

 Transport 
className=org.apache.catalina.tribes.transport.nio.PooledParallelSender 
/

 /Sender
 Receiver 
className=org.apache.catalina.tribes.transport.nio.NioReceiver
 address=245.245.245.245 
port= autoBind=100 selectorTimeout=5000

 maxThreads=6 /
 Interceptor 
className=org.apache.catalina.tribes.group.interceptors.TcpFailureDetector 
/
 Interceptor 
className=org.apache.catalina.tribes.group.interceptors.MessageDispatch15Intercepto 
r /
 Interceptor 
className=org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor 

 Member 
className=org.apache.catalina.tribes.membership.StaticMember
 port= securePort=-1 
host=245.245.245.246 domain=245.245.245.246 /
 Member 
className=org.apache.catalina.tribes.membership.StaticMember
 port= securePort=-1 
host=245.245.245.247 domain=245.245.245.247 /
 Member 
className=org.apache.catalina.tribes.membership.StaticMember
 port= securePort=-1 
host=245.245.245.248 domain=245.245.245.248 /

 /Interceptor
 /Channel
 Valve 
className=org.apache.catalina.ha.tcp.ReplicationValve filter= /
 ClusterListener 
className=org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener 
/
 ClusterListener 
className=org.apache.catalina.ha.session.ClusterSessionListener /

 /Cluster
.
.
.

other instances use the same config (Only different port)


In the log I see:

07.02.2009 18:08:19 org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows 
optimal performance in production environments was not found on the 
java.library.path: 
/usr/lib/jvm/java-1.5.0-sun-1.5.0.14/jre/lib/amd64/server:/usr/lib/jvm/java-1.5.0-sun-1.5.0.14/jre/lib/amd64:/usr/lib/jvm/java-1.5.0-sun-1.5.0.14/jre/../lib/amd64 


07.02.2009 18:08:20 org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-8083
07.02.2009 18:08:20 org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 483 ms
07.02.2009 18:08:20 org.apache.catalina.core.StandardService start
INFO: Starting service Catalina
07.02.2009 18:08:20 org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.16
07.02.2009 18:08:20 org.apache.catalina.ha.tcp.SimpleTcpCluster start
INFO: Cluster is about to start
07.02.2009 18:08:20

Re: Session replication problem

[Filip Hanik - Dev Lists]

Mohamedin wrote:

I have a problem with Session replication. I am running multible tomcat 
instance on the same server. And I have 4 servers of the same configuration 
(Multible tomcat instances). I have enabled the session replication on these 4 
servers (In each instance with different port).

The problem is that All instances see each other. while I only need similar 
instances to see each other.
  
I'm not sure I understand what you are trying to achieve, what do you 
mean by similar


Filip


The config:


Engine name=Catalina defaultHost=localhost jvmRoute=myserver

 Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster 
channelSendOptions=8
 Manager 
className=org.apache.catalina.ha.session.DeltaManager
 expireSessionsOnShutdown=false 
notifyListenersOnReplication=true
 domainReplication=true /
 Channel 
className=org.apache.catalina.tribes.group.GroupChannel
 Sender 
className=org.apache.catalina.tribes.transport.ReplicationTransmitter
 Transport 
className=org.apache.catalina.tribes.transport.nio.PooledParallelSender /
 /Sender
 Receiver 
className=org.apache.catalina.tribes.transport.nio.NioReceiver
 address=245.245.245.245 port= autoBind=100 
selectorTimeout=5000
 maxThreads=6 /
 Interceptor 
className=org.apache.catalina.tribes.group.interceptors.TcpFailureDetector /
 Interceptor 
className=org.apache.catalina.tribes.group.interceptors.MessageDispatch15Intercepto
r /
 Interceptor 
className=org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor

 Member 
className=org.apache.catalina.tribes.membership.StaticMember
 port= securePort=-1 host=245.245.245.246 
domain=245.245.245.246 /
 Member 
className=org.apache.catalina.tribes.membership.StaticMember
 port= securePort=-1 host=245.245.245.247 
domain=245.245.245.247 /
 Member 
className=org.apache.catalina.tribes.membership.StaticMember
 port= securePort=-1 host=245.245.245.248 
domain=245.245.245.248 /
 /Interceptor
 /Channel
 Valve className=org.apache.catalina.ha.tcp.ReplicationValve 
filter= /
 ClusterListener 
className=org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener /
 ClusterListener 
className=org.apache.catalina.ha.session.ClusterSessionListener /
 /Cluster
.
.
.

other instances use the same config (Only different port)


In the log I see:

07.02.2009 18:08:19 org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal 
performance in production environments was not found on the java.library.path: 
/usr/lib/jvm/java-1.5.0-sun-1.5.0.14/jre/lib/amd64/server:/usr/lib/jvm/java-1.5.0-sun-1.5.0.14/jre/lib/amd64:/usr/lib/jvm/java-1.5.0-sun-1.5.0.14/jre/../lib/amd64
07.02.2009 18:08:20 org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-8083
07.02.2009 18:08:20 org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 483 ms
07.02.2009 18:08:20 org.apache.catalina.core.StandardService start
INFO: Starting service Catalina
07.02.2009 18:08:20 org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.16
07.02.2009 18:08:20 org.apache.catalina.ha.tcp.SimpleTcpCluster start
INFO: Cluster is about to start
07.02.2009 18:08:20 org.apache.catalina.tribes.transport.ReceiverBase bind
INFO: Receiver Server Socket bound to:/245.245.245.245:
07.02.2009 18:08:20 org.apache.catalina.tribes.membership.McastServiceImpl 
setupSocket
INFO: Setting cluster mcast soTimeout to 500
07.02.2009 18:08:20 org.apache.catalina.tribes.membership.McastServiceImpl 
waitForMembers
INFO: Sleeping for 1000 milliseconds to establish cluster membership, start 
level:4
07.02.2009 18:08:20 org.apache.catalina.ha.tcp.SimpleTcpCluster memberAdded
INFO: Replication member 
added:org.apache.catalina.tribes.membership.MemberImpl[tcp://245.245.245.246:,245.245.245.246,,
 alive=0,id={0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 }, payload={}, command={}, 
domain={55 54 46 55 53 46 49 55 52 ...(12)}, ]
07.02.2009 18:08:20 org.apache.catalina.ha.tcp.SimpleTcpCluster memberAdded
INFO: Replication member 
added:org.apache.catalina.tribes.membership.MemberImpl[tcp://245.245.245.247:,245.245.245.247,,
 alive=0,id={0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 }, payload={}, command={}, 
domain={55 54 46 55 53 46 49 50 57 ...(13)}, ]
07.02.2009 18:08:20 

RE: Session replication/sharing across WARs?

[Caldarale, Charles R]

 From: Robert Campbell [mailto:rrc...@gmail.com]
 Subject: Session replication/sharing across WARs?

 This means that I need single sign-on/share session between the two
 apps. Both WARs will be deployed on the same Tomcat 5.5 instance,

It's in the docs:
http://tomcat.apache.org/tomcat-5.5-doc/config/host.html#Single%20Sign%20On
http://tomcat.apache.org/tomcat-5.5-doc/config/valve.html#Single%20Sign%20On%20Valve

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

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

Re: Session replication for JPetStore application in tomcat 6

[Alan Chaney]

Anupam

I think this is probably your problem. You create and save information 
in one node and then look to see if it is in the other node. It will 
only be there if you are independently synchronizing the database state, 
because, as you said in your previous emails, they are independent. The 
database state is nothing to do with the http session, you must manage 
that separately.


2) Is it necessary to make the petstore database on each of nodes clustered
for session replication to happen ?

  

Regards

Alan Chaney


-
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: Session replication for JPetStore application in tomcat 6

[Anupam Beri]

Thanks a lot Filip !
Well I tried to set up the log4j.properties at the server as well as the
application level  to include these categories but it dosent seem to work,
i.e I couldnt see the traces specific to sessions .

Is there any specific trace that could enable the sessionID to appear in the
logs, i .e the ID being replicated to the other nodes ?

I also read that the session attributes must be implemented with a
serializable interface. For the jpetstore application , does this mean that
the data items that are pushed into the cart also be serializable?
Sorry for too many questions but  a bit confused.

Best Regards,
Anupam 



Filip Hanik - Dev Lists wrote:
 
 you could enable tracing for the two following categories
 
 org.apache.catalina.ha
 org.apache.catalina.tribes.MESSAGES
 
 Filip
 
 Anupam Beri wrote:
 Hello  Filip,
 Thanks a lot for your reply. From the logs , the session state send is
 evident .The scenario i tried is as follows 

  I opened the application  web page on the first node via my browser ,
 logged in , did some operations like some additions and modifications. I
 displayed the items in the cart .
  
 Then I opened the same application web page on the second node via
 browser
 and tried to display the items in the cart and it said that the Cart is
 empty .

 I had a few questions ...

 1) how can I know if session replication is happening i.e any special
 debugging can be enabled in log4j ? (from above scenario , the items in
 the
 cart should be the same ? can this be the criteria ?)

 2) Is it necessary to make the petstore database on each of nodes
 clustered
 for session replication to happen ?

 I wish to do some load testing too with jmeter to see how the load is
 distributed between workers.

 Any help will be greatefully appreciated !

 Best Regards,
 Anupam


  




 Filip Hanik - Dev Lists wrote:
   
 looks like its working, what is it that you don't think is working or 
 would like help with?

 6 nov. 2008 17:08:30 org.apache.catalina.ha.session.DeltaManager 
 getAllClusterSessions
 ATTENTION: Manager [localhost#/jpetstore], requesting session state from 
 org.apache.catalina.tribes.membership.MemberImpl[tcp://{-84, 17, 4, 
 14}:4000,{-84, 17, 4, 14},4000, alive=276200,id={44 8 -106 78 -12 88 70 
 -91 -126 47 21 -83 -67 102 67 -94 }, payload={}, command={}, domain={}, 
 ]. This operation will timeout if no session state has been received 
 within 60 seconds.
 6 nov. 2008 17:08:30 org.apache.catalina.ha.session.DeltaManager 
 waitForSendAllSessions
 INFO: Manager [localhost#/jpetstore]; session state send at 06/11/08 
 17:08 received in 112 ms.

 Filip

 Anupam Beri wrote:
 
 Hello All ,
I am a newbie to the Tomcat and Tomcat
 clustering
 environment .I was just going through some posts on this forum for
 reference
 .
 I wish to deploy the classic JPetStore application which comes with the
 Spring framework in the clustered environment involving 2 machines for
 session replication

 For this, I installed Apache 2.2 , Tomcat 6.0.18 and mod_jk on each of
 these
 machines . I configured mod_jk load balancer for sticky session and
 deployed
 JPetStore on either of them .
 But once I start tomcat and apache on either machine and try to do some
 transactions , I cannot see any sessions being exchanged between the
 two
 members of the cluster.

 The JPetStore application also uses a database (hsqldb) and its
 necessary
 to
 start one on either machine (it is not a shared one).

 I was reading some documentation regarding if the session attributes
 are
 to
 be implemented from serializable interface...but I see they already
 have
 been in the source code .

 I will be greateful if anyone could help me out and give a  good
 insight
 on
 where I am going wrong ?
 I have attached the server.xml , workers.properties and catalina.out
 for
 the
 two nodes in the attached file.
 Any help is deeply appreciated !

 Best Regards !!
 Anupam

 http://www.nabble.com/file/p20456399/clustering_files.rar
 clustering_files.rar 
   
   
 -
 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]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Session-replication-for-JPetStore-application-in-tomcat-6-tp20456399p20479064.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: Session replication for JPetStore application in tomcat 6

[Filip Hanik - Dev Lists]

looks like its working, what is it that you don't think is working or 
would like help with?


6 nov. 2008 17:08:30 org.apache.catalina.ha.session.DeltaManager 
getAllClusterSessions
ATTENTION: Manager [localhost#/jpetstore], requesting session state from 
org.apache.catalina.tribes.membership.MemberImpl[tcp://{-84, 17, 4, 
14}:4000,{-84, 17, 4, 14},4000, alive=276200,id={44 8 -106 78 -12 88 70 
-91 -126 47 21 -83 -67 102 67 -94 }, payload={}, command={}, domain={}, 
]. This operation will timeout if no session state has been received 
within 60 seconds.
6 nov. 2008 17:08:30 org.apache.catalina.ha.session.DeltaManager 
waitForSendAllSessions
INFO: Manager [localhost#/jpetstore]; session state send at 06/11/08 
17:08 received in 112 ms.


Filip

Anupam Beri wrote:

Hello All ,
   I am a newbie to the Tomcat and Tomcat clustering
environment .I was just going through some posts on this forum for reference
.
I wish to deploy the classic JPetStore application which comes with the
Spring framework in the clustered environment involving 2 machines for
session replication

For this, I installed Apache 2.2 , Tomcat 6.0.18 and mod_jk on each of these
machines . I configured mod_jk load balancer for sticky session and deployed
JPetStore on either of them .
But once I start tomcat and apache on either machine and try to do some
transactions , I cannot see any sessions being exchanged between the two
members of the cluster.

The JPetStore application also uses a database (hsqldb) and its necessary to
start one on either machine (it is not a shared one).

I was reading some documentation regarding if the session attributes are to
be implemented from serializable interface...but I see they already have
been in the source code .

I will be greateful if anyone could help me out and give a  good insight on
where I am going wrong ?
I have attached the server.xml , workers.properties and catalina.out for the
two nodes in the attached file.
Any help is deeply appreciated !

Best Regards !!
Anupam

http://www.nabble.com/file/p20456399/clustering_files.rar
clustering_files.rar 
  



-
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: Session replication for JPetStore application in tomcat 6

[Anupam Beri]

Hello  Filip,
Thanks a lot for your reply. From the logs , the session state send is
evident .The scenario i tried is as follows 

 I opened the application  web page on the first node via my browser ,
logged in , did some operations like some additions and modifications. I
displayed the items in the cart .
 
Then I opened the same application web page on the second node via browser
and tried to display the items in the cart and it said that the Cart is
empty .

I had a few questions ...

1) how can I know if session replication is happening i.e any special
debugging can be enabled in log4j ? (from above scenario , the items in the
cart should be the same ? can this be the criteria ?)

2) Is it necessary to make the petstore database on each of nodes clustered
for session replication to happen ?

I wish to do some load testing too with jmeter to see how the load is
distributed between workers.

Any help will be greatefully appreciated !

Best Regards,
Anupam


 




Filip Hanik - Dev Lists wrote:
 
 looks like its working, what is it that you don't think is working or 
 would like help with?
 
 6 nov. 2008 17:08:30 org.apache.catalina.ha.session.DeltaManager 
 getAllClusterSessions
 ATTENTION: Manager [localhost#/jpetstore], requesting session state from 
 org.apache.catalina.tribes.membership.MemberImpl[tcp://{-84, 17, 4, 
 14}:4000,{-84, 17, 4, 14},4000, alive=276200,id={44 8 -106 78 -12 88 70 
 -91 -126 47 21 -83 -67 102 67 -94 }, payload={}, command={}, domain={}, 
 ]. This operation will timeout if no session state has been received 
 within 60 seconds.
 6 nov. 2008 17:08:30 org.apache.catalina.ha.session.DeltaManager 
 waitForSendAllSessions
 INFO: Manager [localhost#/jpetstore]; session state send at 06/11/08 
 17:08 received in 112 ms.
 
 Filip
 
 Anupam Beri wrote:
 Hello All ,
I am a newbie to the Tomcat and Tomcat clustering
 environment .I was just going through some posts on this forum for
 reference
 .
 I wish to deploy the classic JPetStore application which comes with the
 Spring framework in the clustered environment involving 2 machines for
 session replication

 For this, I installed Apache 2.2 , Tomcat 6.0.18 and mod_jk on each of
 these
 machines . I configured mod_jk load balancer for sticky session and
 deployed
 JPetStore on either of them .
 But once I start tomcat and apache on either machine and try to do some
 transactions , I cannot see any sessions being exchanged between the two
 members of the cluster.

 The JPetStore application also uses a database (hsqldb) and its necessary
 to
 start one on either machine (it is not a shared one).

 I was reading some documentation regarding if the session attributes are
 to
 be implemented from serializable interface...but I see they already have
 been in the source code .

 I will be greateful if anyone could help me out and give a  good insight
 on
 where I am going wrong ?
 I have attached the server.xml , workers.properties and catalina.out for
 the
 two nodes in the attached file.
 Any help is deeply appreciated !

 Best Regards !!
 Anupam

 http://www.nabble.com/file/p20456399/clustering_files.rar
 clustering_files.rar 
   
 
 
 -
 To start a new topic, e-mail: users@tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Session-replication-for-JPetStore-application-in-tomcat-6-tp20456399p20464726.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: Session replication for JPetStore application in tomcat 6

[Filip Hanik - Dev Lists]

you could enable tracing for the two following categories

org.apache.catalina.ha
org.apache.catalina.tribes.MESSAGES

Filip

Anupam Beri wrote:

Hello  Filip,
Thanks a lot for your reply. From the logs , the session state send is
evident .The scenario i tried is as follows 

 I opened the application  web page on the first node via my browser ,
logged in , did some operations like some additions and modifications. I
displayed the items in the cart .
 
Then I opened the same application web page on the second node via browser

and tried to display the items in the cart and it said that the Cart is
empty .

I had a few questions ...

1) how can I know if session replication is happening i.e any special
debugging can be enabled in log4j ? (from above scenario , the items in the
cart should be the same ? can this be the criteria ?)

2) Is it necessary to make the petstore database on each of nodes clustered
for session replication to happen ?

I wish to do some load testing too with jmeter to see how the load is
distributed between workers.

Any help will be greatefully appreciated !

Best Regards,
Anupam


 





Filip Hanik - Dev Lists wrote:
  
looks like its working, what is it that you don't think is working or 
would like help with?


6 nov. 2008 17:08:30 org.apache.catalina.ha.session.DeltaManager 
getAllClusterSessions
ATTENTION: Manager [localhost#/jpetstore], requesting session state from 
org.apache.catalina.tribes.membership.MemberImpl[tcp://{-84, 17, 4, 
14}:4000,{-84, 17, 4, 14},4000, alive=276200,id={44 8 -106 78 -12 88 70 
-91 -126 47 21 -83 -67 102 67 -94 }, payload={}, command={}, domain={}, 
]. This operation will timeout if no session state has been received 
within 60 seconds.
6 nov. 2008 17:08:30 org.apache.catalina.ha.session.DeltaManager 
waitForSendAllSessions
INFO: Manager [localhost#/jpetstore]; session state send at 06/11/08 
17:08 received in 112 ms.


Filip

Anupam Beri wrote:


Hello All ,
   I am a newbie to the Tomcat and Tomcat clustering
environment .I was just going through some posts on this forum for
reference
.
I wish to deploy the classic JPetStore application which comes with the
Spring framework in the clustered environment involving 2 machines for
session replication

For this, I installed Apache 2.2 , Tomcat 6.0.18 and mod_jk on each of
these
machines . I configured mod_jk load balancer for sticky session and
deployed
JPetStore on either of them .
But once I start tomcat and apache on either machine and try to do some
transactions , I cannot see any sessions being exchanged between the two
members of the cluster.

The JPetStore application also uses a database (hsqldb) and its necessary
to
start one on either machine (it is not a shared one).

I was reading some documentation regarding if the session attributes are
to
be implemented from serializable interface...but I see they already have
been in the source code .

I will be greateful if anyone could help me out and give a  good insight
on
where I am going wrong ?
I have attached the server.xml , workers.properties and catalina.out for
the
two nodes in the attached file.
Any help is deeply appreciated !

Best Regards !!
Anupam

http://www.nabble.com/file/p20456399/clustering_files.rar
clustering_files.rar 
  
  

-
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: Session Replication question

[Filip Hanik - Dev Lists]

useDirtyFlag is supposed to be the SimpleTcpManager, DeltaManager always 
only replicates deltas. so does the backup manager.
The two managers that work best are DeltaManager and BackupManager, both 
of them replicate upon setAttribute/removeAttribute actions.
DeltaManager replicates to all other nodes in the cluster, BackupManager 
replicates to a single backup node where the data is stored.


SimpleTcpManager, is no longer actively developed.
Filip

Jess Holle wrote:
I read the cluster how-to regarding.  I'm still not clear on a couple 
of details if is just using DeltaManager and SimpleTcpCluster:


  1. If useDirtyFlag is false, I assume that the session is entire
 replicated after each and every access.  Is this correct?
  2. If useDirtyFlag is true, are only the pieces of the session that
 were changed (via setAttribute(), removeAttribute(), etc) sent
 throughout the cluster?
 * Or is this a separately configurable option?  If so, when
   one calls setAttribute() and/or removeAttribute multiple
   times on the same attribute during the same request, are the
   duplicate events/deltas coalesced?

I'm just trying to understand the behavior and capabilities of the 
clustering a bit better.  I naively expected to find replication only 
when setAttribute(), removeAttribute() or the like are called /and/ 
that these changes would be coalesced into a minimalistic delta that 
would then be pushed to other nodes in the cluster (with a separate 
timestamp on each attribute if necessary).

for the
--
Jess Holle






-
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: session replication / cluster groups

[Paul McGurn]

I believe this segregation is typically done with instances of multiple load 
balancers.  I'm not an expert on the mod_jk stuff, but you'd probably want to 
implement this with multiple load balancers regardless, when you're getting up 
to that many instances.

Bear in mind that this piece of your setup is acting as a single point of 
failure in front of your Tomcat cluster.

Paul McGurn   |   Manager, Customer Support
Escalations  Operations
· ·· LogMeIn, Inc.
www.LogMeIn.com   |   [EMAIL PROTECTED]
p. +1 781.897.1320   |   f. +1 781.897.0632


-Original Message-
From: Kevin Phillips [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 17, 2008 12:04 PM
To: users@tomcat.apache.org
Subject: session replication / cluster groups

Hi, I have tomcat clustering working well with an apache load balancer in front 
(sticky session). I have around 10 at the moment, and I soon need to add at 
least 20 to 30 more. The configuration for session replication is all-to-all, 
using multicast. My aim is to reduce the session traffic between servers, so I 
am looking for alternatives. The Tomcat 6 book (o reilly) states:

If you find that you have too many nodes in your cluster for all-to-all 
replication, you can [..] segment your network such that half of your nodes are 
in one group and half are in another group (or implement primary/secondary 
clustering).

I assume that segmentation is done by supplying a different multicast ip/port 
to the two groups, however, how will the apache (mod_proxy) know the right 
group member to fall to?


Regards,
K. Phillips




-
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: session replication / cluster groups

[Filip Hanik - Dev Lists]

you could use the BackupManager this only replicates data to one backup node

http://tomcat.apache.org/tomcat-6.0-doc/config/cluster-manager.html

and you can fail over to any node, it will fetch the backup from the 
backup node

Filip

Kevin Phillips wrote:

Hi, I have tomcat clustering working well with an apache load balancer in front (sticky 
session). I have around 10 at the moment, and I soon need to add at least 20 to 30 more. 
The configuration for session replication is all-to-all, using multicast. My 
aim is to reduce the session traffic between servers, so I am looking for alternatives. 
The Tomcat 6 book (o reilly) states:

If you find that you have too many nodes in your cluster for all-to-all replication, you can [..] segment your network such that half of your nodes are in one group and half are in another group (or implement primary/secondary clustering). 


I assume that segmentation is done by supplying a different multicast ip/port 
to the two groups, however, how will the apache (mod_proxy) know the right 
group member to fall to?


Regards,
K. Phillips



  
  



-
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: Session replication problem in tomcat 6.0.14 (loadbalancing with Apache)

[Filip Hanik - Dev Lists]

the error should be fixed in 6.0.18
Filip

Pavan Singaraju wrote:

My question here was if the other node is not available anymore, will this
exception come? If so how to avoid it. The fact is the session replication
is happenning and everything is working inspite of the exception. But just
in case if we want to avoid this exception, is there a way or should  the
exception be ignored??
--
Pavan Kumar Singaraju

On Wed, Jul 30, 2008 at 7:00 PM, Filip Hanik - Dev Lists [EMAIL PROTECTED]
  

wrote:



  

this

Jul 30, 2008 1:49:24 PM org.apache.catalina.ha.tcp.SimpleTcpCluster
memberDisappeared
INFO: Received member

disappeared:org.apache.catalina.tribes.membership.MemberImpl[tcp://d5-4232.xius.ltd:4002,d5-4232.xius.ltd,4002,
alive=46858,id={-38 -119 -88 -15 -57 -62 77 116 -98 -70 -92 -50 45 -83 -71
-74 }, payload={}, command={66 65 66 89 45 65 76 69 88 ...(9)}, domain={},
]

indicates that the other node is not part of the cluster anymore.
what does your config look like?

Filip



Pavan Singaraju wrote:



Hello all,
I am trying to do session replication in two tomcats (using Apache to do
the
loadbalancing).
Ran the examples application and put a value in to the session. Now
stopped
the tomcat where the session is set.
Submitted the URL again.
Web page showed no value in the session. I think the session value is not
tranfered. In the log file, i could see the following happenning.
Help me with this to identiry why the error and how to do the session
replication.
I am using Tomcat 6.0.14 on JDK 1.6


Jul 30, 2008 1:49:24 PM org.apache.catalina.ha.tcp.SimpleTcpCluster
memberDisappeared
INFO: Received member

disappeared:org.apache.catalina.tribes.membership.MemberImpl[tcp://d5-4232.xius.ltd:4002,d5-4232.xius.ltd,4002,
alive=46858,id={-38 -119 -88 -15 -57 -62 77 116 -98 -70 -92 -50 45 -83 -71
-74 }, payload={}, command={66 65 66 89 45 65 76 69 88 ...(9)}, domain={},
]
Jul 30, 2008 1:49:40 PM org.apache.catalina.ha.tcp.SimpleTcpCluster send
SEVERE: Unable to send message through cluster sender.
org.apache.catalina.tribes.ChannelException: No destination given; No
faulty
members identified.
 at
org.apache.catalina.tribes.group.GroupChannel.send(GroupChannel.java:194)
 at
org.apache.catalina.tribes.group.GroupChannel.send(GroupChannel.java:175)
 at

org.apache.catalina.ha.tcp.SimpleTcpCluster.send(SimpleTcpCluster.java:835)
 at

org.apache.catalina.ha.tcp.SimpleTcpCluster.sendClusterDomain(SimpleTcpCluster.java:814)
 at

org.apache.catalina.ha.session.JvmRouteBinderValve.sendSessionIDClusterBackup(JvmRouteBinderValve.java:391)
 at

org.apache.catalina.ha.session.JvmRouteBinderValve.changeSessionID(JvmRouteBinderValve.java:362)
 at

org.apache.catalina.ha.session.JvmRouteBinderValve.handleJvmRoute(JvmRouteBinderValve.java:319)
 at

org.apache.catalina.ha.session.JvmRouteBinderValve.handlePossibleTurnover(JvmRouteBinderValve.java:229)
 at

org.apache.catalina.ha.session.JvmRouteBinderValve.invoke(JvmRouteBinderValve.java:206)
 at

org.apache.catalina.ha.tcp.ReplicationValve.invoke(ReplicationValve.java:347)
 at

org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263)
 at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
 at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283)
 at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767)
 at

org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697)
 at

org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889)
 at

org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
 at java.lang.Thread.run(Thread.java:619



  

-
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: Session replication problem in tomcat 6.0.14 (loadbalancing with Apache)

[Filip Hanik - Dev Lists]

this

Jul 30, 2008 1:49:24 PM org.apache.catalina.ha.tcp.SimpleTcpCluster
memberDisappeared
INFO: Received member
disappeared:org.apache.catalina.tribes.membership.MemberImpl[tcp://d5-4232.xius.ltd:4002,d5-4232.xius.ltd,4002,
alive=46858,id={-38 -119 -88 -15 -57 -62 77 116 -98 -70 -92 -50 45 -83 -71
-74 }, payload={}, command={66 65 66 89 45 65 76 69 88 ...(9)}, domain={}, ]

indicates that the other node is not part of the cluster anymore.
what does your config look like?

Filip


Pavan Singaraju wrote:

Hello all,
I am trying to do session replication in two tomcats (using Apache to do the
loadbalancing).
Ran the examples application and put a value in to the session. Now stopped
the tomcat where the session is set.
Submitted the URL again.
Web page showed no value in the session. I think the session value is not
tranfered. In the log file, i could see the following happenning.
Help me with this to identiry why the error and how to do the session
replication.
I am using Tomcat 6.0.14 on JDK 1.6


Jul 30, 2008 1:49:24 PM org.apache.catalina.ha.tcp.SimpleTcpCluster
memberDisappeared
INFO: Received member
disappeared:org.apache.catalina.tribes.membership.MemberImpl[tcp://d5-4232.xius.ltd:4002,d5-4232.xius.ltd,4002,
alive=46858,id={-38 -119 -88 -15 -57 -62 77 116 -98 -70 -92 -50 45 -83 -71
-74 }, payload={}, command={66 65 66 89 45 65 76 69 88 ...(9)}, domain={}, ]
Jul 30, 2008 1:49:40 PM org.apache.catalina.ha.tcp.SimpleTcpCluster send
SEVERE: Unable to send message through cluster sender.
org.apache.catalina.tribes.ChannelException: No destination given; No faulty
members identified.
 at
org.apache.catalina.tribes.group.GroupChannel.send(GroupChannel.java:194)
 at
org.apache.catalina.tribes.group.GroupChannel.send(GroupChannel.java:175)
 at
org.apache.catalina.ha.tcp.SimpleTcpCluster.send(SimpleTcpCluster.java:835)
 at
org.apache.catalina.ha.tcp.SimpleTcpCluster.sendClusterDomain(SimpleTcpCluster.java:814)
 at
org.apache.catalina.ha.session.JvmRouteBinderValve.sendSessionIDClusterBackup(JvmRouteBinderValve.java:391)
 at
org.apache.catalina.ha.session.JvmRouteBinderValve.changeSessionID(JvmRouteBinderValve.java:362)
 at
org.apache.catalina.ha.session.JvmRouteBinderValve.handleJvmRoute(JvmRouteBinderValve.java:319)
 at
org.apache.catalina.ha.session.JvmRouteBinderValve.handlePossibleTurnover(JvmRouteBinderValve.java:229)
 at
org.apache.catalina.ha.session.JvmRouteBinderValve.invoke(JvmRouteBinderValve.java:206)
 at
org.apache.catalina.ha.tcp.ReplicationValve.invoke(ReplicationValve.java:347)
 at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263)
 at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
 at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283)
 at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767)
 at
org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697)
 at
org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889)
 at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
 at java.lang.Thread.run(Thread.java:619

  



-
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: Session replication problem in tomcat 6.0.14 (loadbalancing with Apache)

[Pavan Singaraju]

My question here was if the other node is not available anymore, will this
exception come? If so how to avoid it. The fact is the session replication
is happenning and everything is working inspite of the exception. But just
in case if we want to avoid this exception, is there a way or should  the
exception be ignored??
--
Pavan Kumar Singaraju

On Wed, Jul 30, 2008 at 7:00 PM, Filip Hanik - Dev Lists [EMAIL PROTECTED]
 wrote:

 this

 Jul 30, 2008 1:49:24 PM org.apache.catalina.ha.tcp.SimpleTcpCluster
 memberDisappeared
 INFO: Received member

 disappeared:org.apache.catalina.tribes.membership.MemberImpl[tcp://d5-4232.xius.ltd:4002,d5-4232.xius.ltd,4002,
 alive=46858,id={-38 -119 -88 -15 -57 -62 77 116 -98 -70 -92 -50 45 -83 -71
 -74 }, payload={}, command={66 65 66 89 45 65 76 69 88 ...(9)}, domain={},
 ]

 indicates that the other node is not part of the cluster anymore.
 what does your config look like?

 Filip



 Pavan Singaraju wrote:

 Hello all,
 I am trying to do session replication in two tomcats (using Apache to do
 the
 loadbalancing).
 Ran the examples application and put a value in to the session. Now
 stopped
 the tomcat where the session is set.
 Submitted the URL again.
 Web page showed no value in the session. I think the session value is not
 tranfered. In the log file, i could see the following happenning.
 Help me with this to identiry why the error and how to do the session
 replication.
 I am using Tomcat 6.0.14 on JDK 1.6


 Jul 30, 2008 1:49:24 PM org.apache.catalina.ha.tcp.SimpleTcpCluster
 memberDisappeared
 INFO: Received member

 disappeared:org.apache.catalina.tribes.membership.MemberImpl[tcp://d5-4232.xius.ltd:4002,d5-4232.xius.ltd,4002,
 alive=46858,id={-38 -119 -88 -15 -57 -62 77 116 -98 -70 -92 -50 45 -83 -71
 -74 }, payload={}, command={66 65 66 89 45 65 76 69 88 ...(9)}, domain={},
 ]
 Jul 30, 2008 1:49:40 PM org.apache.catalina.ha.tcp.SimpleTcpCluster send
 SEVERE: Unable to send message through cluster sender.
 org.apache.catalina.tribes.ChannelException: No destination given; No
 faulty
 members identified.
  at
 org.apache.catalina.tribes.group.GroupChannel.send(GroupChannel.java:194)
  at
 org.apache.catalina.tribes.group.GroupChannel.send(GroupChannel.java:175)
  at

 org.apache.catalina.ha.tcp.SimpleTcpCluster.send(SimpleTcpCluster.java:835)
  at

 org.apache.catalina.ha.tcp.SimpleTcpCluster.sendClusterDomain(SimpleTcpCluster.java:814)
  at

 org.apache.catalina.ha.session.JvmRouteBinderValve.sendSessionIDClusterBackup(JvmRouteBinderValve.java:391)
  at

 org.apache.catalina.ha.session.JvmRouteBinderValve.changeSessionID(JvmRouteBinderValve.java:362)
  at

 org.apache.catalina.ha.session.JvmRouteBinderValve.handleJvmRoute(JvmRouteBinderValve.java:319)
  at

 org.apache.catalina.ha.session.JvmRouteBinderValve.handlePossibleTurnover(JvmRouteBinderValve.java:229)
  at

 org.apache.catalina.ha.session.JvmRouteBinderValve.invoke(JvmRouteBinderValve.java:206)
  at

 org.apache.catalina.ha.tcp.ReplicationValve.invoke(ReplicationValve.java:347)
  at

 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263)
  at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
  at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283)
  at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767)
  at

 org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697)
  at

 org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889)
  at

 org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
  at java.lang.Thread.run(Thread.java:619





 -
 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: Session replication problem

[Giancarlo Frison]

The problem reported below was due to a misconfiguration.
In the past I disabled the session persistence uncommenting the manager
row in context.xml :
Manager pathname= /

After session persistance's activation (commenting the row above)
session replication works as expected.

Giancarlo Frison

Filip Hanik - Dev Lists ha scritto:
 you can turn debug on and see the messages being sent back and forth.
 a previous user reported that sessions got expired during a normal
 shutdown, I yet have to investigate this

 Filip

 Giancarlo Frison wrote:
 Hi all,

 I have a cluster configured with 2 tomcat instaces in the same host and
 apache + mod_jk as load balancer with stiky session.
 The instances' server.xml (show below) diff only for
 /Cluster/Channel/Receiver[port] attribute, the first one set to 4000 and
 the second one set to 4001.
 The 2 instances seem aware each other at the startup as report by the
 log of clone1 (listening on port 4000):

 Nov 29, 2007 10:57:43 AM org.apache.coyote.ajp.AjpAprProtocol start
 INFO: Starting Coyote AJP/1.3 on ajp-8009
 Nov 29, 2007 10:57:43 AM org.apache.catalina.startup.Catalina start
 INFO: Server startup in 4364 ms
 Nov 29, 2007 10:58:03 AM org.apache.catalina.tribes.io.BufferPool
 getBufferPool
 INFO: Created a buffer pool with max size:104857600 bytes of
 type:org.apache.catalina.tribes.io.BufferPool15Impl
 Nov 29, 2007 10:58:04 AM org.apache.catalina.ha.tcp.SimpleTcpCluster
 memberAdded
 INFO: Replication member
 added:org.apache.catalina.tribes.membership.MemberImpl[tcp://localhost.localdomain:4001,localhost.localdomain,4001,

 alive=1009,id={31 -16 121 -113 112 30 72 -34 -128 51 27 -12 115 7 -107
 -22 }, payload={}, command={}, domain={}, ]


 To test the session replication I've created a session on clone2
 afterwards I shutted down such instance, as reported by clone1
 catalina.out:

 Nov 29, 2007 11:00:47 AM
 org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
 memberDisappeared
 INFO: Verification complete. Member
 disappeared[org.apache.catalina.tribes.membership.MemberImpl[tcp://localhost.localdomain:4001,localhost.localdomain,4001,

 alive=164497,id={31 -16 121 -113 112 30 72 -34 -128 51 27 -12 115 7 -107
 -22 }, payload={}, command={66 65 66 89 45 65 76 69 88 ...(9)},
 domain={}, ]]
 Nov 29, 2007 11:00:47 AM org.apache.catalina.ha.tcp.SimpleTcpCluster
 memberDisappeared
 INFO: Received member
 disappeared:org.apache.catalina.tribes.membership.MemberImpl[tcp://localhost.localdomain:4001,localhost.localdomain,4001,

 alive=164497,id={31 -16 121 -113 112 30 72 -34 -128 51 27 -12 115 7 -107
 -22 }, payload={}, command={66 65 66 89 45 65 76 69 88 ...(9)},
 domain={}, ]

 With clone2 failover the mod_jk dispatch the request to the clone1. I've
 expected to find in the clone1 the session, instead request.getSession()
 == false.

 The cluster configuration follow stiky session rule, the load balancer
 works fine, everything ok except for session replication.
 Any clue on these cases?

 Thanks a lot!

 -- worker.properties:

 worker.list=lbworker
 worker.lbworker.type=lb
 worker.lbworker.balance_workers=c1,c2
 worker.c1.type=ajp13
 worker.c1.host=localhost
 worker.c1.port=8009
 worker.c2.type=ajp13
 worker.c2.host=localhost
 worker.c2.port=8010

 -- server.xml

 Cluster channelSendOptions=8  
 className=org.apache.catalina.ha.tcp.SimpleTcpCluster
 Manager
 className=org.apache.catalina.ha.session.DeltaManager 
 expireSessionsOnShutdown=false  
 notifyListenersOnReplication=true /
 Channel  
 className=org.apache.catalina.tribes.group.GroupChannel
 Membership
 className=org.apache.catalina.tribes.membership.McastService  
 address=228.0.0.4port=45564 frequency=500
 dropTime=3000/
 Receiver address=localhost autoBind=100 
 className=org.apache.catalina.tribes.transport.nio.NioReceiver   
 maxThreads=6 port=4000 selectorTimeout=5000 /
 Sender
 className=org.apache.catalina.tribes.transport.ReplicationTransmitter
 Transport
 className=org.apache.catalina.tribes.transport.nio.PooledParallelSender
 /
 /Sender
 Interceptor  
 className=org.apache.catalina.tribes.group.interceptors.TcpFailureDetector

 /
 Interceptor  
 className=org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor

 /
 Interceptor
 className=org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor/

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

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



 Giancarlo Frison



 

Re: Session replication problem

[Filip Hanik - Dev Lists]

excellent, yes, you are overriding the clustering manager if you define 
one yourself

thanks for reporting back!
Filip

Giancarlo Frison wrote:

The problem reported below was due to a misconfiguration.
In the past I disabled the session persistence uncommenting the manager
row in context.xml :
Manager pathname= /

After session persistance's activation (commenting the row above)
session replication works as expected.

Giancarlo Frison

Filip Hanik - Dev Lists ha scritto:
  

you can turn debug on and see the messages being sent back and forth.
a previous user reported that sessions got expired during a normal
shutdown, I yet have to investigate this

Filip

Giancarlo Frison wrote:


Hi all,

I have a cluster configured with 2 tomcat instaces in the same host and
apache + mod_jk as load balancer with stiky session.
The instances' server.xml (show below) diff only for
/Cluster/Channel/Receiver[port] attribute, the first one set to 4000 and
the second one set to 4001.
The 2 instances seem aware each other at the startup as report by the
log of clone1 (listening on port 4000):

Nov 29, 2007 10:57:43 AM org.apache.coyote.ajp.AjpAprProtocol start
INFO: Starting Coyote AJP/1.3 on ajp-8009
Nov 29, 2007 10:57:43 AM org.apache.catalina.startup.Catalina start
INFO: Server startup in 4364 ms
Nov 29, 2007 10:58:03 AM org.apache.catalina.tribes.io.BufferPool
getBufferPool
INFO: Created a buffer pool with max size:104857600 bytes of
type:org.apache.catalina.tribes.io.BufferPool15Impl
Nov 29, 2007 10:58:04 AM org.apache.catalina.ha.tcp.SimpleTcpCluster
memberAdded
INFO: Replication member
added:org.apache.catalina.tribes.membership.MemberImpl[tcp://localhost.localdomain:4001,localhost.localdomain,4001,

alive=1009,id={31 -16 121 -113 112 30 72 -34 -128 51 27 -12 115 7 -107
-22 }, payload={}, command={}, domain={}, ]


To test the session replication I've created a session on clone2
afterwards I shutted down such instance, as reported by clone1
catalina.out:

Nov 29, 2007 11:00:47 AM
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared
INFO: Verification complete. Member
disappeared[org.apache.catalina.tribes.membership.MemberImpl[tcp://localhost.localdomain:4001,localhost.localdomain,4001,

alive=164497,id={31 -16 121 -113 112 30 72 -34 -128 51 27 -12 115 7 -107
-22 }, payload={}, command={66 65 66 89 45 65 76 69 88 ...(9)},
domain={}, ]]
Nov 29, 2007 11:00:47 AM org.apache.catalina.ha.tcp.SimpleTcpCluster
memberDisappeared
INFO: Received member
disappeared:org.apache.catalina.tribes.membership.MemberImpl[tcp://localhost.localdomain:4001,localhost.localdomain,4001,

alive=164497,id={31 -16 121 -113 112 30 72 -34 -128 51 27 -12 115 7 -107
-22 }, payload={}, command={66 65 66 89 45 65 76 69 88 ...(9)},
domain={}, ]

With clone2 failover the mod_jk dispatch the request to the clone1. I've
expected to find in the clone1 the session, instead request.getSession()
== false.

The cluster configuration follow stiky session rule, the load balancer
works fine, everything ok except for session replication.
Any clue on these cases?

Thanks a lot!

-- worker.properties:

worker.list=lbworker
worker.lbworker.type=lb
worker.lbworker.balance_workers=c1,c2
worker.c1.type=ajp13
worker.c1.host=localhost
worker.c1.port=8009
worker.c2.type=ajp13
worker.c2.host=localhost
worker.c2.port=8010

-- server.xml

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

Manager
className=org.apache.catalina.ha.session.DeltaManager 
expireSessionsOnShutdown=false  
notifyListenersOnReplication=true /
Channel  
className=org.apache.catalina.tribes.group.GroupChannel

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

Sender
className=org.apache.catalina.tribes.transport.ReplicationTransmitter
Transport
className=org.apache.catalina.tribes.transport.nio.PooledParallelSender

/
/Sender
Interceptor  
className=org.apache.catalina.tribes.group.interceptors.TcpFailureDetector


/
Interceptor  
className=org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor


/
Interceptor
className=org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor/

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


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

/Cluster



Giancarlo Frison

Re: Session replication problem

[Giancarlo Frison]

Hi all,

This is the catalina.out. I read the post about session expiration
during shutdown, so I tried to kill -9 the process to avoid any
unexpected behavior but the outcome is the same, no session replication.
What I may do? I appreciate any suggestion. Thanks!


INFO: Starting Servlet Engine: Apache Tomcat/6.0.14
Dec 5, 2007 2:23:16 PM org.apache.catalina.ha.tcp.SimpleTcpCluster start
INFO: Cluster is about to start
Dec 5, 2007 2:23:16 PM org.apache.catalina.tribes.transport.ReceiverBase
bind
INFO: Receiver Server Socket bound to:/10.228.111.40:4001
Dec 5, 2007 2:23:16 PM
org.apache.catalina.tribes.membership.McastServiceImpl setupSocket
INFO: Setting cluster mcast soTimeout to 500
Dec 5, 2007 2:23:16 PM
org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers
INFO: Sleeping for 1000 milliseconds to establish cluster membership,
start level:4
Dec 5, 2007 2:23:16 PM org.apache.catalina.ha.tcp.SimpleTcpCluster
memberAdded
INFO: Replication member
added:org.apache.catalina.tribes.membership.MemberImpl[tcp://lnxp-1429.srv.mediaways.net:4000,lnxp-1429.srv.mediaways.net,4000,
alive=10573,id={110 72 2 -26 77 55 67 103 -75 -105 19 43 29 72 -12 -46
}, payload={}, command={}, domain={}, ]
Dec 5, 2007 2:23:17 PM
org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers
INFO: Done sleeping, membership established, start level:4
Dec 5, 2007 2:23:17 PM
org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers
INFO: Sleeping for 1000 milliseconds to establish cluster membership,
start level:8
Dec 5, 2007 2:23:17 PM org.apache.catalina.tribes.io.BufferPool
getBufferPool
INFO: Created a buffer pool with max size:104857600 bytes of
type:org.apache.catalina.tribes.io.BufferPool15Impl
Dec 5, 2007 2:23:18 PM
org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers
INFO: Done sleeping, membership established, start level:8
Dec 5, 2007 2:23:18 PM org.apache.catalina.startup.HostConfig deployWAR
INFO: Deploying web application archive webx.war
Dec 5, 2007 2:23:18 PM org.apache.catalina.ha.tcp.SimpleTcpCluster
registerManager
WARNING: Manager [ [EMAIL PROTECTED]
does not implement ClusterManager, addition to cluster has been aborted.
log4j:WARN No such property [datePattern] in
org.apache.log4j.RollingFileAppender.
pack: com.nimbuzz.webx.response
Dec 5, 2007 2:23:20 PM org.apache.coyote.http11.Http11NioProtocol start
INFO: Starting Coyote HTTP/1.1 on http-8080
Dec 5, 2007 2:23:20 PM org.apache.coyote.ajp.AjpAprProtocol start
INFO: Starting Coyote AJP/1.3 on ajp-8009
Dec 5, 2007 2:23:20 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 4353 ms
Dec 5, 2007 2:25:53 PM
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared
INFO: Received
memberDisappeared[org.apache.catalina.tribes.membership.MemberImpl[tcp://lnxp-1429.srv.mediaways.net:4000,lnxp-1429.srv.mediaways.net,4000,
alive=164207,id={110 72 2 -26 77 55 67 103 -75 -105 19 43 29 72 -12 -46
}, payload={}, command={}, domain={}, ]] message. Will verify.
Dec 5, 2007 2:25:53 PM
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared
INFO: Verification complete. Member
disappeared[org.apache.catalina.tribes.membership.MemberImpl[tcp://lnxp-1429.srv.mediaways.net:4000,lnxp-1429.srv.mediaways.net,4000,
alive=164207,id={110 72 2 -26 77 55 67 103 -75 -105 19 43 29 72 -12 -46
}, payload={}, command={}, domain={}, ]]
Dec 5, 2007 2:25:53 PM org.apache.catalina.ha.tcp.SimpleTcpCluster
memberDisappeared
INFO: Received member
disappeared:org.apache.catalina.tribes.membership.MemberImpl[tcp://lnxp-1429.srv.mediaways.net:4000,lnxp-1429.srv.mediaways.net,4000,
alive=164207,id={110 72 2 -26 77 55 67 103 -75 -105 19 43 29 72 -12 -46
}, payload={}, command={}, domain={}, ]



Filip Hanik - Dev Lists ha scritto:
 you can turn debug on and see the messages being sent back and forth.
 a previous user reported that sessions got expired during a normal
 shutdown, I yet have to investigate this

 Filip

 Giancarlo Frison wrote:
 Hi all,

 I have a cluster configured with 2 tomcat instaces in the same host and
 apache + mod_jk as load balancer with stiky session.
 The instances' server.xml (show below) diff only for
 /Cluster/Channel/Receiver[port] attribute, the first one set to 4000 and
 the second one set to 4001.
 The 2 instances seem aware each other at the startup as report by the
 log of clone1 (listening on port 4000):

 Nov 29, 2007 10:57:43 AM org.apache.coyote.ajp.AjpAprProtocol start
 INFO: Starting Coyote AJP/1.3 on ajp-8009
 Nov 29, 2007 10:57:43 AM org.apache.catalina.startup.Catalina start
 INFO: Server startup in 4364 ms
 Nov 29, 2007 10:58:03 AM org.apache.catalina.tribes.io.BufferPool
 getBufferPool
 INFO: Created a buffer pool with max size:104857600 bytes of
 type:org.apache.catalina.tribes.io.BufferPool15Impl
 Nov 29, 2007 10:58:04 AM org.apache.catalina.ha.tcp.SimpleTcpCluster
 memberAdded
 INFO: Replication member
 

Re: Session replication problem

[Filip Hanik - Dev Lists]

you can turn debug on and see the messages being sent back and forth.
a previous user reported that sessions got expired during a normal 
shutdown, I yet have to investigate this


Filip

Giancarlo Frison wrote:

Hi all,

I have a cluster configured with 2 tomcat instaces in the same host and
apache + mod_jk as load balancer with stiky session.
The instances' server.xml (show below) diff only for
/Cluster/Channel/Receiver[port] attribute, the first one set to 4000 and
the second one set to 4001.
The 2 instances seem aware each other at the startup as report by the
log of clone1 (listening on port 4000):

Nov 29, 2007 10:57:43 AM org.apache.coyote.ajp.AjpAprProtocol start
INFO: Starting Coyote AJP/1.3 on ajp-8009
Nov 29, 2007 10:57:43 AM org.apache.catalina.startup.Catalina start
INFO: Server startup in 4364 ms
Nov 29, 2007 10:58:03 AM org.apache.catalina.tribes.io.BufferPool
getBufferPool
INFO: Created a buffer pool with max size:104857600 bytes of
type:org.apache.catalina.tribes.io.BufferPool15Impl
Nov 29, 2007 10:58:04 AM org.apache.catalina.ha.tcp.SimpleTcpCluster
memberAdded
INFO: Replication member
added:org.apache.catalina.tribes.membership.MemberImpl[tcp://localhost.localdomain:4001,localhost.localdomain,4001,
alive=1009,id={31 -16 121 -113 112 30 72 -34 -128 51 27 -12 115 7 -107
-22 }, payload={}, command={}, domain={}, ]


To test the session replication I've created a session on clone2
afterwards I shutted down such instance, as reported by clone1 catalina.out:

Nov 29, 2007 11:00:47 AM
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared
INFO: Verification complete. Member
disappeared[org.apache.catalina.tribes.membership.MemberImpl[tcp://localhost.localdomain:4001,localhost.localdomain,4001,
alive=164497,id={31 -16 121 -113 112 30 72 -34 -128 51 27 -12 115 7 -107
-22 }, payload={}, command={66 65 66 89 45 65 76 69 88 ...(9)},
domain={}, ]]
Nov 29, 2007 11:00:47 AM org.apache.catalina.ha.tcp.SimpleTcpCluster
memberDisappeared
INFO: Received member
disappeared:org.apache.catalina.tribes.membership.MemberImpl[tcp://localhost.localdomain:4001,localhost.localdomain,4001,
alive=164497,id={31 -16 121 -113 112 30 72 -34 -128 51 27 -12 115 7 -107
-22 }, payload={}, command={66 65 66 89 45 65 76 69 88 ...(9)}, domain={}, ]

With clone2 failover the mod_jk dispatch the request to the clone1. I've
expected to find in the clone1 the session, instead request.getSession()
== false.

The cluster configuration follow stiky session rule, the load balancer
works fine, everything ok except for session replication.
Any clue on these cases?

Thanks a lot!

-- worker.properties:

worker.list=lbworker
worker.lbworker.type=lb
worker.lbworker.balance_workers=c1,c2
worker.c1.type=ajp13
worker.c1.host=localhost
worker.c1.port=8009
worker.c2.type=ajp13
worker.c2.host=localhost
worker.c2.port=8010

-- server.xml

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

Manager
className=org.apache.catalina.ha.session.DeltaManager  
expireSessionsOnShutdown=false   
notifyListenersOnReplication=true /
Channel   
className=org.apache.catalina.tribes.group.GroupChannel

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

Sender
className=org.apache.catalina.tribes.transport.ReplicationTransmitter
Transport 
className=org.apache.catalina.tribes.transport.nio.PooledParallelSender /

/Sender
Interceptor   
className=org.apache.catalina.tribes.group.interceptors.TcpFailureDetector

/
Interceptor   
className=org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor

/
Interceptor
className=org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor/
/Channel
Valve
className=org.apache.catalina.ha.tcp.ReplicationValve filter= /
Valve
className=org.apache.catalina.ha.session.JvmRouteBinderValve /
ClusterListener   
className=org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener

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

/Cluster



Giancarlo Frison



-
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: Session Replication

[Pid]

Andrew Hole wrote:
 Hello everyone!
 
 For using Tomcat session clustering I need to put the following
 component in all nodes?

Yes, obviously.  Any node without a cluster definition won't know that
it's supposed to be in a cluster without it...

I don't suppose you've read the docs on clustering, at all?

p



 Cluster
 className=org.apache.catalina.cluster.tcp.SimpleTcpCluster
doClusterLog=true
  clusterLogName=clusterlog
 
 manager.className=org.apache.catalina.cluster.session.DeltaManager
manager.expireSessionsOnShutdown=false
manager.notifyListenersOnReplication=false
 manager.notifySessionListenersOnReplication=false
 manager.sendAllSessions=false
 manager.sendAllSessionsSize=500
 manager.sendAllSessionsWaitTime=20
   Membership
 
 className=org.apache.catalina.cluster.mcast.McastService
   mcastAddr=228.0.0.4
mcastBindAddress=127.0.0.1
  mcastClusterDomain=d10
   mcastPort=45564
  mcastFrequency=1000
   mcastDropTime=3
   
 recoveryCounter=10
 recoveryEnabled=true
   recoverySleepTime=5000/
   Receiver
 
 className=org.apache.catalina.cluster.tcp.ReplicationListener
 tcpListenAddress=auto
tcpListenPort=9016
   tcpSelectorTimeout=100
   tcpThreadCount=6/
   Sender
 
 className=org.apache.catalina.cluster.tcp.ReplicationTransmitter
  replicationMode=fastasyncqueue
   recoverTimeout=5000
   recoverCounter=6
 doTransmitterProcessingStats=true
doProcessingStats=true
   doWaitAckStats=true
queueTimeWait=true
 queueDoStats=true
   queueCheckLock=true
   ackTimeout=15000
   waitForAck=true
 keepAliveTimeout=8
 keepAliveMaxRequestCount=-1/
   Valve
 className=org.apache.catalina.cluster.tcp.ReplicationValve
 
 filter=.*\.gif;.*\.js;.*\.css;.*\.png;.*\.jpeg;.*\.jpg;.*\.htm;.*\.html;.*\.txt;
 primaryIndicator=true /
   Valve
 className=org.apache.catalina.cluster.session.JvmRouteBinderValve
  enabled=true /
   ClusterListener
 className=org.apache.catalina.cluster.session.ClusterSessionListener
 /
   ClusterListener
 className=org.apache.catalina.cluster.session.JvmRouteSessionIDBinderListener
 /
   Deployer
 className=org.apache.catalina.cluster.deploy.FarmWarDeployer
 
 tempDir=${catalina.base}/war-temp
 
 deployDir=${catalina.base}/war-deploy/
 
 watchDir=${catalina.base}/war-listen/
watchEnabled=true/
   /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: Session Replication

[Filip Hanik - Dev Lists]

yeah, but if you bind to 127.0.0.1 how do you expect clustering to work 
between nodes? :)


Filip

Andrew Hole wrote:

Hello everyone!

For using Tomcat session clustering I need to put the following
component in all nodes?

Cluster
className=org.apache.catalina.cluster.tcp.SimpleTcpCluster
   doClusterLog=true
 clusterLogName=clusterlog

manager.className=org.apache.catalina.cluster.session.DeltaManager
   manager.expireSessionsOnShutdown=false
   manager.notifyListenersOnReplication=false
manager.notifySessionListenersOnReplication=false
manager.sendAllSessions=false
manager.sendAllSessionsSize=500
manager.sendAllSessionsWaitTime=20
  Membership

className=org.apache.catalina.cluster.mcast.McastService
  mcastAddr=228.0.0.4
   mcastBindAddress=127.0.0.1
 mcastClusterDomain=d10
  mcastPort=45564
 mcastFrequency=1000
  mcastDropTime=3

recoveryCounter=10
recoveryEnabled=true
  recoverySleepTime=5000/
  Receiver

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

className=org.apache.catalina.cluster.tcp.ReplicationTransmitter
 replicationMode=fastasyncqueue
  recoverTimeout=5000
  recoverCounter=6
doTransmitterProcessingStats=true
   doProcessingStats=true
  doWaitAckStats=true
   queueTimeWait=true
queueDoStats=true
  queueCheckLock=true
  ackTimeout=15000
  waitForAck=true
keepAliveTimeout=8
keepAliveMaxRequestCount=-1/
  Valve
className=org.apache.catalina.cluster.tcp.ReplicationValve

filter=.*\.gif;.*\.js;.*\.css;.*\.png;.*\.jpeg;.*\.jpg;.*\.htm;.*\.html;.*\.txt;
primaryIndicator=true /
  Valve
className=org.apache.catalina.cluster.session.JvmRouteBinderValve
 enabled=true / 
  ClusterListener
className=org.apache.catalina.cluster.session.ClusterSessionListener
/
  ClusterListener
className=org.apache.catalina.cluster.session.JvmRouteSessionIDBinderListener
/
  Deployer
className=org.apache.catalina.cluster.deploy.FarmWarDeployer
tempDir=${catalina.base}/war-temp

deployDir=${catalina.base}/war-deploy/

watchDir=${catalina.base}/war-listen/
   watchEnabled=true/
  /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: Session Replication

[Andrew Hole]

I only have one machine to test Session Replication. Every tomcat
instances are in same machine.

On 9/27/07, Caldarale, Charles R [EMAIL PROTECTED] wrote:
  From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED]
  Subject: Re: Session Replication
 
  yeah, but if you bind to 127.0.0.1 how do you expect
  clustering to work between nodes? :)

 Well, you could run all the Tomcat instances on the same box.  What's
 that saying about eggs and baskets?

  - Chuck


 THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
 MATERIAL and is thus for use only by the intended recipient. If you
 received this in error, please contact the sender and delete the e-mail
 and its attachments from all computers.

 -
 To 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: Session Replication

[Filip Hanik - Dev Lists]

then, the tcpListenPort must be unique for each instance, since you 
cannot share the port


Filip

Andrew Hole wrote:

I only have one machine to test Session Replication. Every tomcat
instances are in same machine.

On 9/27/07, Caldarale, Charles R [EMAIL PROTECTED] wrote:
  

From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED]
Subject: Re: Session Replication

yeah, but if you bind to 127.0.0.1 how do you expect
clustering to work between nodes? :)
  

Well, you could run all the Tomcat instances on the same box.  What's
that saying about eggs and baskets?

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

-
To 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: Session Replication

[Andrew Hole]

Thanks.

Exists some layer to replicate database sessions? If my application is
connected to an instance that crasches, every sessions dies. I would
like to obtain response from the other database instance when this
happens.
Thanks

On 9/27/07, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote:
 then, the tcpListenPort must be unique for each instance, since you
 cannot share the port

 Filip

 Andrew Hole wrote:
  I only have one machine to test Session Replication. Every tomcat
  instances are in same machine.
 
  On 9/27/07, Caldarale, Charles R [EMAIL PROTECTED] wrote:
 
  From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED]
  Subject: Re: Session Replication
 
  yeah, but if you bind to 127.0.0.1 how do you expect
  clustering to work between nodes? :)
 
  Well, you could run all the Tomcat instances on the same box.  What's
  that saying about eggs and baskets?
 
   - Chuck
 
 
  THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
  MATERIAL and is thus for use only by the intended recipient. If you
  received this in error, please contact the sender and delete the e-mail
  and its attachments from all computers.
 
  -
  To 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]



-
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: Session Replication

[Filip Hanik - Dev Lists]

bit confused on what you are trying to achieve

Filip

Andrew Hole wrote:

Thanks.

Exists some layer to replicate database sessions? If my application is
connected to an instance that crasches, every sessions dies. I would
like to obtain response from the other database instance when this
happens.
Thanks

On 9/27/07, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote:
  

then, the tcpListenPort must be unique for each instance, since you
cannot share the port

Filip

Andrew Hole wrote:


I only have one machine to test Session Replication. Every tomcat
instances are in same machine.

On 9/27/07, Caldarale, Charles R [EMAIL PROTECTED] wrote:

  

From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED]
Subject: Re: Session Replication

yeah, but if you bind to 127.0.0.1 how do you expect
clustering to work between nodes? :)

  

Well, you could run all the Tomcat instances on the same box.  What's
that saying about eggs and baskets?

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

-
To 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]





-
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: Session Replication in Tomcat5.5.17

[ShivKumar]

Hi Thanks for ur reply. I did what u said but no luck. If possible send the
tested code and all other relevent files to me?

Any help regard this highly appreciated..
My Id is [EMAIL PROTECTED]

Thanks

Fiona Sariedine wrote:
 
  what this done with my problem
 
 -Oorspronkelijk bericht-
 Van: Mark Thomas [mailto:[EMAIL PROTECTED]
 Verzonden: woensdag 20 juni 2007 14:12
 Aan: Tomcat Users List
 Onderwerp: Re: Session Replication in Tomcat5.5.17
 
 shiva sha wrote:
 Hai

 If i remove tomcats names (jvm route) in workers.properties means how
 Apache route the request?
 Pls clarify
 
 Remove the line:
 
 worker.list=tomcat1,tomcat2,loadbalancer
 
 Replace it with
 
 worker.list=loadbalancer
 
 Everythign else remains the same.
 
 mark
 
 -
 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]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Session-Replication-in-Tomcat5.5.17-tf3941122.html#a11250665
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: Session Replication in Tomcat5.5.17

[shiva sha]

Hi
I had made some changes in httpd.conf,mod_jk.conf,mod_jk_cluster.conf also..
I forgot to send that file.
Pls check all the entries are correct.

mod_jk.conf

LoadModule jk_module modules/mod_jk.dll
IfModule mod_jk.c
JkWorkersFile D:/Apache Group/Apache2/conf/workers.properties
JkLogFile logs/jk.log
JkLogLevel error
JkMount /clusterapp/* loadbalancer
JkMount /clusterapp/ loadbalancer
JkMount /clusterapp loadbalancer
JkMount /clusterapp/* ajp1.3
JkMount /clusterapp/* ajp1.3
JkMount /*.jsp ajp1.3
/IfModule

mod_jk_cluster.conf


LoadModule jk_module modules/mod_jk.dll
IfModule mod_jk.c
JkWorkersFile D:/Apache Group/Apache2/conf/workers.properties
JkLogFile logs/jk.log
JkLogLevel error
JkMount /clusterapp/* loadbalancer
JkMount /clusterapp/ loadbalancer
JkMount /clusterapp loadbalancer
JkMount /clusterapp/* ajp1.3
JkMount /clusterapp/* ajp1.3
JkMount /*.jsp ajp1.3
/IfModule

httpd.conf

In httpd.conf i  had added the below entry only.

LoadModule jk_module modules/mod_jk.dll


I did what u said but no luck. If possible send the tested code and all
other relevent files to me?

Any help regard this highly appreciated..
My Id is [EMAIL PROTECTED]

Thanks

On 6/22/07, ShivKumar [EMAIL PROTECTED] wrote:



Hi Thanks for ur reply. I did what u said but no luck. If possible send
the
tested code and all other relevent files to me?

Any help regard this highly appreciated..
My Id is [EMAIL PROTECTED]

Thanks

Fiona Sariedine wrote:

  what this done with my problem

 -Oorspronkelijk bericht-
 Van: Mark Thomas [mailto:[EMAIL PROTECTED]
 Verzonden: woensdag 20 juni 2007 14:12
 Aan: Tomcat Users List
 Onderwerp: Re: Session Replication in Tomcat5.5.17

 shiva sha wrote:
 Hai

 If i remove tomcats names (jvm route) in workers.properties means how
 Apache route the request?
 Pls clarify

 Remove the line:

 worker.list=tomcat1,tomcat2,loadbalancer

 Replace it with

 worker.list=loadbalancer

 Everythign else remains the same.

 mark

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




--
View this message in context:
http://www.nabble.com/Session-Replication-in-Tomcat5.5.17-tf3941122.html#a11250665
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: Session Replication in Tomcat5.5.17

[shiva sha]

Hi I follwoed ur given URLs...
But no luck..
This is my configuraion

Apache Version : 2.2.4
Tomcat Version : 5.5.17
JDK  :  1.6.0_01
Win 2000

workers.properties

worker.list=tomcat1,tomcat2,loadbalancer

# First tomcat server

worker.tomcat1.type=ajp13
worker.tomcat1.host=192.168.10.30
worker.tomcat1.port=8009
worker.tomcat1.lbfactor=1
worker.tomcat1.connection_pool_timeout=600
worker.tomcat1.socket_keepalive=1
worker.tomcat1.socket_timeout=60
worker.tomcat1.cachesize=20
worker.tomcat1.cache_timeout=180
worker.tomcat1.recycle_timeout=180

# Second tomcat server

worker.tomcat2.type=ajp13
worker.tomcat2.host=192.168.10.50
worker.tomcat2.port=9009
worker.tomcat2.lbfactor=1
worker.tomcat2.connection_pool_timeout=600
worker.tomcat2.socket_keepalive=1
worker.tomcat2.socket_timeout=60
worker.tomcat2.cachesize=20
worker.tomcat2.cache_timeout=180
worker.tomcat2.recycle_timeout=180

worker.tomcat2.lbfactor=100
worker.loadbalancer.type=lb
worker.loadbalancer.sticky_session=True
worker.loadbalancer.balance_workers=tomcat1,tomcat2

Below is the Tomcat1 server.xml.


Server port=8005 shutdown=SHUTDOWN

 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/


 GlobalNamingResources


   Environment name=simpleValue type=java.lang.Integer value=30/

   Resource name=UserDatabase auth=Container
 type=org.apache.catalina.UserDatabase
  description=User database that can be updated and saved
  factory=org.apache.catalina.users.MemoryUserDatabaseFactory
 pathname=conf/tomcat-users.xml /

 /GlobalNamingResources

 Service name=Catalina

   !-- Define a non-SSL HTTP/1.1 Connector on port 8080 --
   Connector port=8081 maxHttpHeaderSize=8192
  maxThreads=150 minSpareThreads=25 maxSpareThreads=75
  enableLookups=false redirectPort=8443 acceptCount=100
  connectionTimeout=2 disableUploadTimeout=true /

   !-- Define an AJP 1.3 Connector on port 8009 --
   Connector port=8009
  enableLookups=false redirectPort=8443 protocol=AJP/1.3
/

   !-- Define the top level container in our container hierarchy --
   Engine name=Catalina defaultHost=localhost jvmRoute=tomcat1

 Realm className=org.apache.catalina.realm.UserDatabaseRealm
resourceName=UserDatabase/

 !-- Define the default virtual host
  Note: XML Schema validation will not work with Xerces 2.2.
  --
 Host name=localhost appBase=webapps
  unpackWARs=true autoDeploy=true
  xmlValidation=false xmlNamespaceAware=false


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

managerClassName=
org.apache.catalina.cluster.session.DeltaManager
expireSessionsOnShutdown=false
useDirtyFlag=true
notifyListenersOnReplication=true

   Membership
   className=org.apache.catalina.cluster.mcast.McastService
   mcastAddr=228.0.0.4
   mcastBindAddress=192.168.10.30
   mcastPort=45564
   mcastFrequency=500
   mcastDropTime=3000/

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

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

   Valve className=
org.apache.catalina.cluster.tcp.ReplicationValve

filter=.*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;/

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

   ClusterListener className=
org.apache.catalina.cluster.session.ClusterSessionListener/
   /Cluster


 /Host

   /Engine

 /Service

/Server

For Tomcat2 i had changed the below elements only..

Server port=9005 shutdown=SHUTDOWN
Connector port=9081 maxHttpHeaderSize=8192
  maxThreads=150 minSpareThreads=25 maxSpareThreads=75
  enableLookups=false redirectPort=8443 acceptCount=100
  connectionTimeout=2 disableUploadTimeout=true /

   !-- Define an AJP 1.3 Connector on port 8009 --
   Connector port=9009
  enableLookups=false redirectPort=8443 protocol=AJP/1.3
/
Membership
   className=org.apache.catalina.cluster.mcast.McastService
   mcastAddr=228.0.0.4
   

RE: Session Replication in Tomcat5.5.17

[Raghupathy, Gurumoorthy]

Try to remove  tomcat1,tomcat2, from the workers.properties

It should be something like 

worker.list=loadbalancer

Thanks 
Guru
-Original Message-
From: shiva sha [mailto:[EMAIL PROTECTED] 
Sent: 20 June 2007 09:30
To: Tomcat Users List
Subject: Re: Session Replication in Tomcat5.5.17

Hi I follwoed ur given URLs...
But no luck..
This is my configuraion

Apache Version : 2.2.4
Tomcat Version : 5.5.17
JDK  :  1.6.0_01
Win 2000

workers.properties

worker.list=tomcat1,tomcat2,loadbalancer

# First tomcat server

worker.tomcat1.type=ajp13
worker.tomcat1.host=192.168.10.30
worker.tomcat1.port=8009
worker.tomcat1.lbfactor=1
worker.tomcat1.connection_pool_timeout=600
worker.tomcat1.socket_keepalive=1
worker.tomcat1.socket_timeout=60
worker.tomcat1.cachesize=20
worker.tomcat1.cache_timeout=180
worker.tomcat1.recycle_timeout=180

# Second tomcat server

worker.tomcat2.type=ajp13
worker.tomcat2.host=192.168.10.50
worker.tomcat2.port=9009
worker.tomcat2.lbfactor=1
worker.tomcat2.connection_pool_timeout=600
worker.tomcat2.socket_keepalive=1
worker.tomcat2.socket_timeout=60
worker.tomcat2.cachesize=20
worker.tomcat2.cache_timeout=180
worker.tomcat2.recycle_timeout=180

worker.tomcat2.lbfactor=100
worker.loadbalancer.type=lb
worker.loadbalancer.sticky_session=True
worker.loadbalancer.balance_workers=tomcat1,tomcat2

Below is the Tomcat1 server.xml.


Server port=8005 shutdown=SHUTDOWN

  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/


  GlobalNamingResources


Environment name=simpleValue type=java.lang.Integer
value=30/

Resource name=UserDatabase auth=Container
  type=org.apache.catalina.UserDatabase
   description=User database that can be updated and saved
   factory=org.apache.catalina.users.MemoryUserDatabaseFactory
  pathname=conf/tomcat-users.xml /

  /GlobalNamingResources

  Service name=Catalina

!-- Define a non-SSL HTTP/1.1 Connector on port 8080 --
Connector port=8081 maxHttpHeaderSize=8192
   maxThreads=150 minSpareThreads=25
maxSpareThreads=75
   enableLookups=false redirectPort=8443
acceptCount=100
   connectionTimeout=2 disableUploadTimeout=true /

!-- Define an AJP 1.3 Connector on port 8009 --
Connector port=8009
   enableLookups=false redirectPort=8443
protocol=AJP/1.3
/

!-- Define the top level container in our container hierarchy --
Engine name=Catalina defaultHost=localhost jvmRoute=tomcat1

  Realm className=org.apache.catalina.realm.UserDatabaseRealm
 resourceName=UserDatabase/

  !-- Define the default virtual host
   Note: XML Schema validation will not work with Xerces 2.2.
   --
  Host name=localhost appBase=webapps
   unpackWARs=true autoDeploy=true
   xmlValidation=false xmlNamespaceAware=false


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

 managerClassName=
org.apache.catalina.cluster.session.DeltaManager
 expireSessionsOnShutdown=false
 useDirtyFlag=true
 notifyListenersOnReplication=true

Membership
 
className=org.apache.catalina.cluster.mcast.McastService
mcastAddr=228.0.0.4
mcastBindAddress=192.168.10.30
mcastPort=45564
mcastFrequency=500
mcastDropTime=3000/

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

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

Valve className=
org.apache.catalina.cluster.tcp.ReplicationValve

filter=.*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;
/

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

ClusterListener className=
org.apache.catalina.cluster.session.ClusterSessionListener/
/Cluster


  /Host

/Engine

  /Service

/Server

For Tomcat2 i had changed the below elements only..

Server port=9005 shutdown=SHUTDOWN
Connector port=9081 maxHttpHeaderSize=8192
   maxThreads=150 minSpareThreads=25
maxSpareThreads=75
   enableLookups=false redirectPort=8443
acceptCount=100

Re: Session Replication in Tomcat5.5.17

[shiva sha]

Hi

At present I m trying Session replication only..
I think i need tomcat1 and tomcat2..
Am i correct?

Thanks


On 6/20/07, Raghupathy, Gurumoorthy [EMAIL PROTECTED]
wrote:


Try to remove  tomcat1,tomcat2, from the workers.properties

It should be something like

worker.list=loadbalancer

Thanks
Guru
-Original Message-
From: shiva sha [mailto:[EMAIL PROTECTED]
Sent: 20 June 2007 09:30
To: Tomcat Users List
Subject: Re: Session Replication in Tomcat5.5.17

Hi I follwoed ur given URLs...
But no luck..
This is my configuraion

Apache Version : 2.2.4
Tomcat Version : 5.5.17
JDK  :  1.6.0_01
Win 2000

workers.properties

worker.list=tomcat1,tomcat2,loadbalancer

# First tomcat server

worker.tomcat1.type=ajp13
worker.tomcat1.host=192.168.10.30
worker.tomcat1.port=8009
worker.tomcat1.lbfactor=1
worker.tomcat1.connection_pool_timeout=600
worker.tomcat1.socket_keepalive=1
worker.tomcat1.socket_timeout=60
worker.tomcat1.cachesize=20
worker.tomcat1.cache_timeout=180
worker.tomcat1.recycle_timeout=180

# Second tomcat server

worker.tomcat2.type=ajp13
worker.tomcat2.host=192.168.10.50
worker.tomcat2.port=9009
worker.tomcat2.lbfactor=1
worker.tomcat2.connection_pool_timeout=600
worker.tomcat2.socket_keepalive=1
worker.tomcat2.socket_timeout=60
worker.tomcat2.cachesize=20
worker.tomcat2.cache_timeout=180
worker.tomcat2.recycle_timeout=180

worker.tomcat2.lbfactor=100
worker.loadbalancer.type=lb
worker.loadbalancer.sticky_session=True
worker.loadbalancer.balance_workers=tomcat1,tomcat2

Below is the Tomcat1 server.xml.


Server port=8005 shutdown=SHUTDOWN

  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/


  GlobalNamingResources


Environment name=simpleValue type=java.lang.Integer
value=30/

Resource name=UserDatabase auth=Container
  type=org.apache.catalina.UserDatabase
   description=User database that can be updated and saved
   factory=org.apache.catalina.users.MemoryUserDatabaseFactory
  pathname=conf/tomcat-users.xml /

  /GlobalNamingResources

  Service name=Catalina

!-- Define a non-SSL HTTP/1.1 Connector on port 8080 --
Connector port=8081 maxHttpHeaderSize=8192
   maxThreads=150 minSpareThreads=25
maxSpareThreads=75
   enableLookups=false redirectPort=8443
acceptCount=100
   connectionTimeout=2 disableUploadTimeout=true /

!-- Define an AJP 1.3 Connector on port 8009 --
Connector port=8009
   enableLookups=false redirectPort=8443
protocol=AJP/1.3
/

!-- Define the top level container in our container hierarchy --
Engine name=Catalina defaultHost=localhost jvmRoute=tomcat1

  Realm className=org.apache.catalina.realm.UserDatabaseRealm
 resourceName=UserDatabase/

  !-- Define the default virtual host
   Note: XML Schema validation will not work with Xerces 2.2.
   --
  Host name=localhost appBase=webapps
   unpackWARs=true autoDeploy=true
   xmlValidation=false xmlNamespaceAware=false


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

 managerClassName=
org.apache.catalina.cluster.session.DeltaManager
 expireSessionsOnShutdown=false
 useDirtyFlag=true
 notifyListenersOnReplication=true

Membership

className=org.apache.catalina.cluster.mcast.McastService
mcastAddr=228.0.0.4
mcastBindAddress=192.168.10.30
mcastPort=45564
mcastFrequency=500
mcastDropTime=3000/

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

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

Valve className=
org.apache.catalina.cluster.tcp.ReplicationValve

filter=.*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;
/

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

ClusterListener className=
org.apache.catalina.cluster.session.ClusterSessionListener/
/Cluster


  /Host

/Engine

  /Service

/Server

For Tomcat2 i had changed the below elements only..

Server port=9005 shutdown=SHUTDOWN
Connector port=9081

Re: Session replication in tomcat5.5

[Phi-Long LE]

did you try to add the address attribute within connector tag ?
something looks strange in your worker.properties i.e.

worker.tomcat1.lbfactor=1
worker.tomcat2.lbfactor=100
this two directive mean something like you will use 100 times tomcat2 
for 1 time tomcat1... if you want to use the two tomcat at the same load 
you should specify the same number


can we have your mod_jk.log at the apache startup ??
you should as well start tomcat first

Le 20/06/2007 11:10, shiva sha a écrit :

Hi I follwoed the below URLs...

http://tomcat.apache.org/tomcat-5.5-doc/cluster-howto.html
http://tomcat.apache.org/connectors-doc/reference/workers.html
http://tomcat.apache.org/connectors-doc/generic_howto/workers.html

But no luck.. Session is not get replicated..
This is my configuraion

Apache Version : 2.2.4
Tomcat Version : 5.5.17
JDK  :  1.6.0_01
Win 2000

workers.properties

worker.list=tomcat1,tomcat2,loadbalancer

# First tomcat server

worker.tomcat1.type=ajp13
worker.tomcat1.host=192.168.10.30
worker.tomcat1.port=8009
worker.tomcat1.lbfactor=1
worker.tomcat1.connection_pool_timeout=600
worker.tomcat1.socket_keepalive=1
worker.tomcat1.socket_timeout=60
worker.tomcat1.cachesize=20
worker.tomcat1.cache_timeout=180
worker.tomcat1.recycle_timeout=180

# Second tomcat server

worker.tomcat2.type=ajp13
worker.tomcat2.host=192.168.10.50
worker.tomcat2.port=9009
worker.tomcat2.lbfactor=1
worker.tomcat2.connection_pool_timeout=600
worker.tomcat2.socket_keepalive=1
worker.tomcat2.socket_timeout=60
worker.tomcat2.cachesize=20
worker.tomcat2.cache_timeout=180
worker.tomcat2.recycle_timeout=180

worker.tomcat2.lbfactor=100
worker.loadbalancer.type=lb
worker.loadbalancer.sticky_session=True
worker.loadbalancer.balance_workers=tomcat1,tomcat2

Below is the Tomcat1 server.xml.


Server port=8005 shutdown=SHUTDOWN

 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/


 GlobalNamingResources


   Environment name=simpleValue type=java.lang.Integer value=30/

   Resource name=UserDatabase auth=Container
 type=org.apache.catalina.UserDatabase
  description=User database that can be updated and saved
  factory=org.apache.catalina.users.MemoryUserDatabaseFactory
 pathname=conf/tomcat-users.xml /

 /GlobalNamingResources

 Service name=Catalina

   !-- Define a non-SSL HTTP/1.1 Connector on port 8080 --
   Connector port=8081 maxHttpHeaderSize=8192
  maxThreads=150 minSpareThreads=25 maxSpareThreads=75
  enableLookups=false redirectPort=8443 acceptCount=100
  connectionTimeout=2 disableUploadTimeout=true /

   !-- Define an AJP 1.3 Connector on port 8009 --
   Connector port=8009
  enableLookups=false redirectPort=8443 
protocol=AJP/1.3

/

   !-- Define the top level container in our container hierarchy --
   Engine name=Catalina defaultHost=localhost jvmRoute=tomcat1

 Realm className=org.apache.catalina.realm.UserDatabaseRealm
resourceName=UserDatabase/

 !-- Define the default virtual host
  Note: XML Schema validation will not work with Xerces 2.2.
  --
 Host name=localhost appBase=webapps
  unpackWARs=true autoDeploy=true
  xmlValidation=false xmlNamespaceAware=false


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


managerClassName=
org.apache.catalina.cluster.session.DeltaManager
expireSessionsOnShutdown=false
useDirtyFlag=true
notifyListenersOnReplication=true

   Membership
   className=org.apache.catalina.cluster.mcast.McastService
   mcastAddr=228.0.0.4
   mcastBindAddress=192.168.10.30
   mcastPort=45564
   mcastFrequency=500
   mcastDropTime=3000/

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

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

   Valve className=
org.apache.catalina.cluster.tcp.ReplicationValve

filter=.*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;/ 



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

   ClusterListener className=

Re: Session replication in tomcat5.5

[Phi-Long LE]

I had paste the mod_jk.dll in conf/modules..

What i m trying is
First i started the Apache and then Tomcat1,Tomcat2..
I run the html file in Tomcat1 and the given value is stored in session and
displays the same.
Then stop the Tomcat1..
If i run the same HTML i want to show the session value which is stored in
Tomcat instance1..
But i can not get the old session value..It will start new session only..
Session is not get replicated across Tomcat instances...

not sure to really understand what you try to do... load balancing a 
webapp or trying to have a standby tomcat in case of the first one 
crashes... well am not sure you can transfer a sessionID... never heard 
before about such possibilities(anyway am still young in IT ;-)) the 
session should be binded to one tomcat instance (default: sticky_session 
is set to true)


Le 20/06/2007 12:32, Phi-Long LE a écrit :

did you try to add the address attribute within connector tag ?
something looks strange in your worker.properties i.e.

worker.tomcat1.lbfactor=1
worker.tomcat2.lbfactor=100
this two directive mean something like you will use 100 times tomcat2 
for 1 time tomcat1... if you want to use the two tomcat at the same 
load you should specify the same number


can we have your mod_jk.log at the apache startup ??
you should as well start tomcat first

Le 20/06/2007 11:10, shiva sha a écrit :

Hi I follwoed the below URLs...

http://tomcat.apache.org/tomcat-5.5-doc/cluster-howto.html
http://tomcat.apache.org/connectors-doc/reference/workers.html
http://tomcat.apache.org/connectors-doc/generic_howto/workers.html

But no luck.. Session is not get replicated..
This is my configuraion

Apache Version : 2.2.4
Tomcat Version : 5.5.17
JDK  :  1.6.0_01
Win 2000

workers.properties

worker.list=tomcat1,tomcat2,loadbalancer

# First tomcat server

worker.tomcat1.type=ajp13
worker.tomcat1.host=192.168.10.30
worker.tomcat1.port=8009
worker.tomcat1.lbfactor=1
worker.tomcat1.connection_pool_timeout=600
worker.tomcat1.socket_keepalive=1
worker.tomcat1.socket_timeout=60
worker.tomcat1.cachesize=20
worker.tomcat1.cache_timeout=180
worker.tomcat1.recycle_timeout=180

# Second tomcat server

worker.tomcat2.type=ajp13
worker.tomcat2.host=192.168.10.50
worker.tomcat2.port=9009
worker.tomcat2.lbfactor=1
worker.tomcat2.connection_pool_timeout=600
worker.tomcat2.socket_keepalive=1
worker.tomcat2.socket_timeout=60
worker.tomcat2.cachesize=20
worker.tomcat2.cache_timeout=180
worker.tomcat2.recycle_timeout=180

worker.tomcat2.lbfactor=100
worker.loadbalancer.type=lb
worker.loadbalancer.sticky_session=True
worker.loadbalancer.balance_workers=tomcat1,tomcat2

Below is the Tomcat1 server.xml.


Server port=8005 shutdown=SHUTDOWN

 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/


 GlobalNamingResources


   Environment name=simpleValue type=java.lang.Integer value=30/

   Resource name=UserDatabase auth=Container
 type=org.apache.catalina.UserDatabase
  description=User database that can be updated and saved
  factory=org.apache.catalina.users.MemoryUserDatabaseFactory
 pathname=conf/tomcat-users.xml /

 /GlobalNamingResources

 Service name=Catalina

   !-- Define a non-SSL HTTP/1.1 Connector on port 8080 --
   Connector port=8081 maxHttpHeaderSize=8192
  maxThreads=150 minSpareThreads=25 maxSpareThreads=75
  enableLookups=false redirectPort=8443 
acceptCount=100

  connectionTimeout=2 disableUploadTimeout=true /

   !-- Define an AJP 1.3 Connector on port 8009 --
   Connector port=8009
  enableLookups=false redirectPort=8443 
protocol=AJP/1.3

/

   !-- Define the top level container in our container hierarchy --
   Engine name=Catalina defaultHost=localhost jvmRoute=tomcat1

 Realm className=org.apache.catalina.realm.UserDatabaseRealm
resourceName=UserDatabase/

 !-- Define the default virtual host
  Note: XML Schema validation will not work with Xerces 2.2.
  --
 Host name=localhost appBase=webapps
  unpackWARs=true autoDeploy=true
  xmlValidation=false xmlNamespaceAware=false


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


managerClassName=
org.apache.catalina.cluster.session.DeltaManager
expireSessionsOnShutdown=false
useDirtyFlag=true
notifyListenersOnReplication=true

   Membership
   
className=org.apache.catalina.cluster.mcast.McastService

   mcastAddr=228.0.0.4
   mcastBindAddress=192.168.10.30
   mcastPort=45564
   mcastFrequency=500
   mcastDropTime=3000/

   Receiver
   className=

Re: Session Replication in Tomcat5.5.17

[Mark Thomas]

shiva sha wrote:
 Hi
 
 At present I m trying Session replication only..
 I think i need tomcat1 and tomcat2..
 Am i correct?

No - you need to remove these.

Mark

-
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: Session replication in tomcat5.5

[shiva sha]

Thanks Guru..

Below is the log entry from mod_jk.log

[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1806):
worker tomcat1 contact is '192.168.10.30:8009'
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1895):
setting socket keepalive to 1
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1934):
setting socket timeout to -1
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1938):
setting socket buffer size to 0
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1942):
setting connection recycle timeout to 180
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1946):
setting cache timeout to 180
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1950):
setting connect timeout to 0
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1954):
setting reply timeout to 0
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1958):
setting prepost timeout to 0
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1962):
setting recovery opts to 0
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1966):
setting number of retries to 3
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1843):
setting connection cache size to 20
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_worker.c (141): about to
create instance tomcat2 of ajp13
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_worker.c (154): about to
validate and init tomcat2
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1806):
worker tomcat2 contact is '192.168.10.50:9009'
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1895):
setting socket keepalive to 1
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1934):
setting socket timeout to -1
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1938):
setting socket buffer size to 0
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1942):
setting connection recycle timeout to 180
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1946):
setting cache timeout to 180
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1950):
setting connect timeout to 0
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1954):
setting reply timeout to 0
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1958):
setting prepost timeout to 0
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1962):
setting recovery opts to 0
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1966):
setting number of retries to 3
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1843):
setting connection cache size to 20
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_lb_worker.c (833):
Balanced worker 0 has name tomcat1 in domain
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_lb_worker.c (833):
Balanced worker 1 has name tomcat2 in domain
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_worker.c (248): removing
old loadbalancer worker
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_shm.c (72): Shared memory
is already opened
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_shm.c (105): Attached
shared memory [1] size=65536 free=64696 addr=0x7cb5c8
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] mod_jk.c (2306): Attached
shm:memory
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] mod_jk.c (2316): Initialized
mod_jk/1.2.14
[Mon Jun 18 21:54:41 2007] [2292:2296] [debug] mod_jk.c (1747): Shmem
cleanup
[Mon Jun 18 21:54:41 2007] [2292:2296] [debug] mod_jk.c (1747): Shmem
cleanup
[Mon Jun 18 21:54:41 2007] [2300:1396] [debug] mod_jk.c (1747): Shmem
cleanup

Can u pls give the tested code for tomcatapplication, serve.xml,
workers.properties, mod_jk.conf,mod_jk_cluster.conf. and how to run a
application..
Bcoz i tried with many times i cant get session replication..

Thanks

On 6/20/07, Phi-Long LE [EMAIL PROTECTED] wrote:


did you try to add the address attribute within connector tag ?
something looks strange in your worker.properties i.e.

worker.tomcat1.lbfactor=1
worker.tomcat2.lbfactor=100
this two directive mean something like you will use 100 times tomcat2
for 1 time tomcat1... if you want to use the two tomcat at the same load
you should specify the same number

can we have your mod_jk.log at the apache startup ??
you should as well start tomcat first

Le 20/06/2007 11:10, shiva sha a écrit :
 Hi I follwoed the below URLs...

 http://tomcat.apache.org/tomcat-5.5-doc/cluster-howto.html
 http://tomcat.apache.org/connectors-doc/reference/workers.html
 http://tomcat.apache.org/connectors-doc/generic_howto/workers.html

 But no luck.. Session is not get replicated..
 This is my configuraion

 Apache Version : 2.2.4
 Tomcat Version : 5.5.17
 JDK  :  1.6.0_01
 Win 2000

 workers.properties

 worker.list=tomcat1,tomcat2,loadbalancer

 # First tomcat server

 worker.tomcat1.type=ajp13
 worker.tomcat1.host=192.168.10.30
 

RE: Session replication in tomcat5.5

[Raghupathy, Gurumoorthy]

Hi Shiva,

Your config looks ok to me ... please can you confirm that all your 
session attributes are Serializable ? Even if one is not then session 
replication will have issues ... look at your application logs and confirm back

Thanks
Guru

-Original Message-
From: shiva sha [mailto:[EMAIL PROTECTED] 
Sent: 20 June 2007 12:46
To: Tomcat Users List; [EMAIL PROTECTED]
Subject: Re: Session replication in tomcat5.5

Thanks Guru..

Below is the log entry from mod_jk.log

[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1806):
worker tomcat1 contact is '192.168.10.30:8009'
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1895):
setting socket keepalive to 1
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1934):
setting socket timeout to -1
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1938):
setting socket buffer size to 0
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1942):
setting connection recycle timeout to 180
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1946):
setting cache timeout to 180
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1950):
setting connect timeout to 0
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1954):
setting reply timeout to 0
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1958):
setting prepost timeout to 0
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1962):
setting recovery opts to 0
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1966):
setting number of retries to 3
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1843):
setting connection cache size to 20
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_worker.c (141): about to
create instance tomcat2 of ajp13
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_worker.c (154): about to
validate and init tomcat2
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1806):
worker tomcat2 contact is '192.168.10.50:9009'
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1895):
setting socket keepalive to 1
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1934):
setting socket timeout to -1
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1938):
setting socket buffer size to 0
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1942):
setting connection recycle timeout to 180
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1946):
setting cache timeout to 180
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1950):
setting connect timeout to 0
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1954):
setting reply timeout to 0
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1958):
setting prepost timeout to 0
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1962):
setting recovery opts to 0
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1966):
setting number of retries to 3
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1843):
setting connection cache size to 20
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_lb_worker.c (833):
Balanced worker 0 has name tomcat1 in domain
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_lb_worker.c (833):
Balanced worker 1 has name tomcat2 in domain
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_worker.c (248): removing
old loadbalancer worker
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_shm.c (72): Shared memory
is already opened
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_shm.c (105): Attached
shared memory [1] size=65536 free=64696 addr=0x7cb5c8
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] mod_jk.c (2306): Attached
shm:memory
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] mod_jk.c (2316): Initialized
mod_jk/1.2.14
[Mon Jun 18 21:54:41 2007] [2292:2296] [debug] mod_jk.c (1747): Shmem
cleanup
[Mon Jun 18 21:54:41 2007] [2292:2296] [debug] mod_jk.c (1747): Shmem
cleanup
[Mon Jun 18 21:54:41 2007] [2300:1396] [debug] mod_jk.c (1747): Shmem
cleanup

Can u pls give the tested code for tomcatapplication, serve.xml,
workers.properties, mod_jk.conf,mod_jk_cluster.conf. and how to run a
application..
Bcoz i tried with many times i cant get session replication..

Thanks

On 6/20/07, Phi-Long LE [EMAIL PROTECTED] wrote:

 did you try to add the address attribute within connector tag ?
 something looks strange in your worker.properties i.e.

 worker.tomcat1.lbfactor=1
 worker.tomcat2.lbfactor=100
 this two directive mean something like you will use 100 times tomcat2
 for 1 time tomcat1... if you want to use the two tomcat at the same load
 you should specify the same number

 can we have your mod_jk.log at the apache startup ??
 you should as well start tomcat first

 Le 20/06/2007 11:10, shiva sha a écrit :
  Hi I follwoed the below URLs...
 
  http://tomcat.apache.org/tomcat-5.5-doc/cluster-howto.html

Re: Session replication in tomcat5.5

[shiva sha]

Yes Guru..
I had set all session attributes are Serializable

Thanks
Shiva



On 6/20/07, Raghupathy, Gurumoorthy [EMAIL PROTECTED]
wrote:


Hi Shiva,

Your config looks ok to me ... please can you confirm that all
your session attributes are Serializable ? Even if one is not then session
replication will have issues ... look at your application logs and confirm
back

Thanks
Guru

-Original Message-
From: shiva sha [mailto:[EMAIL PROTECTED]
Sent: 20 June 2007 12:46
To: Tomcat Users List; [EMAIL PROTECTED]
Subject: Re: Session replication in tomcat5.5

Thanks Guru..

Below is the log entry from mod_jk.log

[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1806):
worker tomcat1 contact is '192.168.10.30:8009'
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1895):
setting socket keepalive to 1
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1934):
setting socket timeout to -1
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1938):
setting socket buffer size to 0
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1942):
setting connection recycle timeout to 180
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1946):
setting cache timeout to 180
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1950):
setting connect timeout to 0
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1954):
setting reply timeout to 0
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1958):
setting prepost timeout to 0
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1962):
setting recovery opts to 0
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1966):
setting number of retries to 3
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1843):
setting connection cache size to 20
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_worker.c (141): about to
create instance tomcat2 of ajp13
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_worker.c (154): about to
validate and init tomcat2
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1806):
worker tomcat2 contact is '192.168.10.50:9009'
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1895):
setting socket keepalive to 1
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1934):
setting socket timeout to -1
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1938):
setting socket buffer size to 0
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1942):
setting connection recycle timeout to 180
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1946):
setting cache timeout to 180
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1950):
setting connect timeout to 0
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1954):
setting reply timeout to 0
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1958):
setting prepost timeout to 0
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1962):
setting recovery opts to 0
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1966):
setting number of retries to 3
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_ajp_common.c (1843):
setting connection cache size to 20
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_lb_worker.c (833):
Balanced worker 0 has name tomcat1 in domain
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_lb_worker.c (833):
Balanced worker 1 has name tomcat2 in domain
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_worker.c (248): removing
old loadbalancer worker
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_shm.c (72): Shared
memory
is already opened
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] jk_shm.c (105): Attached
shared memory [1] size=65536 free=64696 addr=0x7cb5c8
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] mod_jk.c (2306): Attached
shm:memory
[Mon Jun 18 21:27:32 2007] [2292:2296] [debug] mod_jk.c (2316):
Initialized
mod_jk/1.2.14
[Mon Jun 18 21:54:41 2007] [2292:2296] [debug] mod_jk.c (1747): Shmem
cleanup
[Mon Jun 18 21:54:41 2007] [2292:2296] [debug] mod_jk.c (1747): Shmem
cleanup
[Mon Jun 18 21:54:41 2007] [2300:1396] [debug] mod_jk.c (1747): Shmem
cleanup

Can u pls give the tested code for tomcatapplication, serve.xml,
workers.properties, mod_jk.conf,mod_jk_cluster.conf. and how to run a
application..
Bcoz i tried with many times i cant get session replication..

Thanks

On 6/20/07, Phi-Long LE [EMAIL PROTECTED] wrote:

 did you try to add the address attribute within connector tag ?
 something looks strange in your worker.properties i.e.

 worker.tomcat1.lbfactor=1
 worker.tomcat2.lbfactor=100
 this two directive mean something like you will use 100 times tomcat2
 for 1 time tomcat1... if you want to use the two tomcat at the same load
 you should specify the same number

 can we have your mod_jk.log at the apache startup ??
 you should as well start tomcat first

Re: Session Replication in Tomcat5.5.17

[shiva sha]

Hai

If i remove tomcats names (jvm route) in workers.properties means how Apache
route the request?
Pls clarify

On 6/20/07, Mark Thomas [EMAIL PROTECTED] wrote:


shiva sha wrote:
 Hi

 At present I m trying Session replication only..
 I think i need tomcat1 and tomcat2..
 Am i correct?

No - you need to remove these.

Mark

-
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: Session Replication in Tomcat5.5.17

[Mark Thomas]

shiva sha wrote:
 Hai
 
 If i remove tomcats names (jvm route) in workers.properties means how
 Apache
 route the request?
 Pls clarify

Remove the line:

worker.list=tomcat1,tomcat2,loadbalancer

Replace it with

worker.list=loadbalancer

Everythign else remains the same.

mark

-
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: Session Replication in Tomcat5.5.17

[Fiona Sariedine]

 what this done with my problem

-Oorspronkelijk bericht-
Van: Mark Thomas [mailto:[EMAIL PROTECTED]
Verzonden: woensdag 20 juni 2007 14:12
Aan: Tomcat Users List
Onderwerp: Re: Session Replication in Tomcat5.5.17

shiva sha wrote:
 Hai

 If i remove tomcats names (jvm route) in workers.properties means how
 Apache route the request?
 Pls clarify

Remove the line:

worker.list=tomcat1,tomcat2,loadbalancer

Replace it with

worker.list=loadbalancer

Everythign else remains the same.

mark

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