Re: clustering questions
So the proper location for a Cluster element is inside a Host element? Host Does this mean I need to have a separate Cluster element for each virtual host? yes, unfortunately, the better solution is to do the virtual hosting in your apache server. That way you only need one cluster config. Filip Mark Eggers wrote: I'm looking at clustering and have a few questions. 1. In the documentation, the Cluster element is shown as a child of the Engine element. In the example server.xml the Cluster element is shown in the Host element. When I put the Cluster element in the Host element, I get clustering messages in catalina.out. I don't get this if I put the Cluster element in the Engine element. So the proper location for a Cluster element is inside a Host element? 2. There is a statement concerning number of threads would be optimal if it matched the number of nodes. I am fronting Tomcat with Apache/mod_jk. Would the number of nodes be the maximum clients I have configured for Apache times the number of Apache servers that can hit this Tomcat server? I am looking at having several virtual hosts running under one Tomcat instance. Does this mean I need to have a separate Cluster element for each virtual host? Thanks for helping me get started on this. /mde/ __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: picture of session state for nodes in cluster??
you would have to write a valve or other component that queries the Tomcat internal classes yourself, If you do come up with something very useful, we would love to include it into the code base. Filip John MccLain wrote: How can I get a picture of session state for each node in a cluster every time a session is replicated? is there some valve or filter out there I can use? I am having clustering problems with our app, and I want to see what the difference is in session state between the nodes in the cluster John McClain Senior Software Engineer TCS Healthcare [EMAIL PROTECTED] (530)886-1700x235 Skepticism is the first step toward truth - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to query for number of active participants in the tomcat 5.5 cluster
you would need to write a component that queries the cluster classes (internal tomcat components) yourself. I believe you can reach the cluster object through JMX and through the tomcat classes (host etc) the interface CatalinaCluster.getMembers() returns all members in a cluster. Filip Edmon Begoli wrote: Hi, Is it possible to query host tomcat for the number of active participants in the cluster that host tomcat belongs to. If yes - can you please point me to the API, and possibly examples. Thank you, Edmon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clustering without farmwardeployer
Two suggestions: 1. Make sure the farm war deployer is really turned off, and by the way, the farm war deployer doesn't deploy into webapps, instead into the dir you specify in server.xml 2. Check your scripts again, chances are you are the one redeploying your own old code. Filip Todd Huss wrote: We have a Tomcat cluster setup across 9 servers with clustering for session replication. However, we are not using the farmwardeployer because we have our own script that we use to shutdown each tomcat, deploy a fix version, and then start it up again so we don't incur any downtime. However, we're seeing some very unusual behavior. After shutting down one node, deleting contents of webapps and work directories, dropping in a new war, and restarting, the new files that get exploded in the webapps directory are not those of the war dropped into the webapps directory. They are instead the files from the previous war which is no longer on the local filesystem. It leads me to believe that even though we have the farmwardeployer turned off, that when we start tomcat in clustered mode, rather than exploding the local war, it's getting the contents of the war from another node. Any ideas? Thanks, Todd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to determine clustering problem?
turn on logging, see Tomcat docs then through log4j you can turn on logging for only org.apache.catalina.cluster and you will be able to see all messages going through. Filip John MccLain wrote: We have a webapp that runs fine in 1 tomcat instance. We have insured that all classes being stored in session are serializable When I put the app into a cluster of 3 Tomcats on my machine, it kind of works, but I am getting inconsistent failures. It is like constantly running down rabbit holes as the errors change continually. Is there a way to debug clustered apps? If this is a possible memory, issue, How do I change the memory configuration for each Tomcat instance? Is there a timeout for each screen request? can I configure it? John McClain Senior Software Engineer TCS Healthcare [EMAIL PROTECTED] (530)886-1700x235 Skepticism is the first step toward truth - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to use Database persistence for tomcat clustering?
Configure the PersistenceManager as your session manager hang zhao wrote: Hi, everyone I am trying some configuration with my small tomcat cluster (2 tomcats, 1 apache, connected with mod_jk2 as load balancer). The problem is that I want to use a shared database (Mysql) to do session replication instead of in-memory session replication. But to the best of my knowledge, you seems can not make session level fail over to work with shared database session replication. The changed session data is not sent to database immediately. In another word, how can I configure so that when I change session data, it is sent to database immediately. And so when some nodes dies, the other node can pick up the unfinished request silently without session data loss. Thanks in advance Hang __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Limit catalina.out size
or like we do, we pipe the output through cronolog Filip Tim Funk wrote: There shouldn't be anything going to standard output (Unless your code is writing to System.out) An overly simple way to rotate logs in unix ... cd $tomcat_log_dir cp -f catalina.out catalina.out.`date +%Y.%m.%d` cat /dev/null catalina.out -Tim Jimmy Ray wrote: Running on HPUX...SDK 1.4.2...the standard output is going to catlaina.out. Is it possible to change the logger settings reduce the size of the catalina.out file and perform circular logging? If so where are these settings? Regards, Jimmy Ray - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cluster Deployment Question
Make sure your WAR file gets properly installed on both instances SEVERE: Unable to install WAR file java.io.FileNotFoundException: C:\tmp\war-deploy\clustertest.war (The system cannot find the path specified) Durfee, Bernard wrote: I am ready to set Tomcat up in a clustered environment. So to test I have installed two instances of Tomcat 5.5.7 on the same XP machine. One listens on 8080 and the other on 8081. I configured the server.xml as follows... 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 mcastPort=45564 mcastFrequency=500 mcastDropTime=3000 / Receiver className=org.apache.catalina.cluster.tcp.ReplicationListener tcpListenAddress=auto tcpListenPort=4001 tcpSelectorTimeout=100 tcpThreadCount=10 / Sender className=org.apache.catalina.cluster.tcp.ReplicationTransmitter replicationMode=pooled ackTimeout=15000 / Valve className=org.apache.catalina.cluster.tcp.ReplicationValve filter=.*\.gif;.*\.js;.*\.jpg;.*\.htm;.*\.html;.*\.txt; / Deployer className=org.apache.catalina.cluster.deploy.FarmWarDeployer tempDir=/tmp/war-temp/ deployDir=/tmp/war-deploy/ watchDir=/tmp/war-listen/ watchEnabled=false / /Cluster ...with tcpListenPort as 4001 in one instance and 4002 in the other. With watchEnabled false on one but true on the other. The Tomcat instances start fine and both indicate... INFO: Replication member added ...when started. This tells me that they see each other. When I try to deploy a web-app by dropping it in the war-listen directory I get... SEVERE: Unable to install WAR file java.io.FileNotFoundException: C:\tmp\war-deploy\clustertest.war (The system cannot find the path specified) ...okay, so that doesn't work. So I try to deploy through the manager on 8080 using Select WAR file to upload... The 8080 server says: WARNING: Manager[/clustertest], requesting session state from org.apache.catalina.cluster.mcast.McastMember[tcp://123.321.21.25:4002,1 41.254.21.25,4002, alive=227500]. This operation will timeout if no session state has been received within... The 8081 server then says: Mar 18, 2005 3:03:35 PM org.apache.catalina.cluster.tcp.SimpleTcpCluster messageDataReceived WARNING: Context manager doesn't exist:/clustertest ...then the 8080 server waits, then times out and says... SEVERE: Manager[/clustertest], No session state received, timing out. ...any ideas? Seems like the Tomcats are talking and trying, but can't send the WAR from one to the other. Bernard Durfee - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache/Tomcat 4.1.18 - Displaying empty Strings as null
install tomcat 4.1.31 on your new server Mendez, Eric wrote: Hello, I recently installed Apache/Tomcat v 4.1.18 on my new server, and I have a JSP page that extracts values from an Oracle database, if the value in the database is an empty String (), it returns as a null value in my JSP page. I have another server with Tomcat v. 4.1.31, and I am not having this issue. The new server has JDK v. 1.4.2 and my old server has v. 1.4.1. Any ideas will help. Thanks Confidentiality Note: The preceding e-mail message (including any attachments) contains information that may be confidential, protected by applicable legal privileges, or constitute non-public information. It is intended to be conveyed only to the designated recipient(s). If you are not an intended recipient of this message, please notify the sender by replying to this message and then delete it from your system. Use, dissemination, distribution or reproduction of this message by unintended recipients is not authorized and may be unlawful. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat load-balancing maintenance strategy?
its fixed in 5.5.x, you need a patch for 5.0.x? Dan Carwin wrote: I also experienced cluster failure when restarting a downed cluster member in 5.0. I tested with Tomcat 5.0.30. Randall, what version of Tomcat did you succeed with? Thanks, Dan -Original Message- From: Richard Mixon (qwest) [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 08, 2005 10:45 AM To: Tomcat Users List Subject: RE: tomcat load-balancing maintenance strategy? Jim, Also check the archives for my post on restarting a downed Tomcat cluster member. This was not working well prior to Tomcat 5.5.8. When the instance was restarted it would throw exceptions trying to re-synchronize vi session replication. - Richard -Original Message- From: Randall Svancara [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 08, 2005 9:40 AM To: Tomcat Users List Subject: RE: tomcat load-balancing maintenance strategy? You need to implement either in memory session replication or persist the session in a database or a shared file system. I have finally got my tomcat cluster working and session replication is functional. Randall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SV: Cluster: will session listeners got called again after replication?
listeners will not be invoked on a state transfer, as it is not considered an event. when a new member joins the cluster, it requests a state transfer from one of the other members. Joseph Lam wrote: I have it turned on already. But seems that after a node is killed and then started up again, even though it can pick up the sessions from the other nodes, my HttpSessionBindingListener and HttpSessionListener were not called at all during the replication. Joseph On Fri, 25 Feb 2005, Filip Hanik - Dev Lists wrote: there is a flag you can set so that listeners don't get called, its optional its called notifyListenersOnReplication, see server.xml for example, default is true Filip Jesper Ekberg wrote: Hello! My first mail to this list. :) I have read it for a long time tho. We have a tried to cluster 3 Tomcat 5.5.7 machines and I found that HttpSessionBindingListener will be notified when the session is replicated and the machine crashes. I think this must be a bug?? The scenario: 3 Tomcat 5.5.7 machines on Windows 2003 Server (I know, not my fault ;)). JK2 Connector for load balancing. I log on and session is created and is replicated correctly to all machines. I shut down the server that I'm working on. The session is destroyed and method valueUnbound is called on the crashed machine. It seems odd to me that the method valueUnbound is called when the session is replicated, the session still lives on the other Tomcat machines. Sorry for my sometimes bad English ;) //Jesper -Ursprungligt meddelande- Från: Joseph Lam [mailto:[EMAIL PROTECTED] Skickat: den 24 februari 2005 08:44 Till: Tomcat Users List Ämne: Cluster: will session listeners got called again after replication? Anyone knows when a session is replicated to other nodes, will the HttpSessionBindingListener and HttpSessionAttributeListener objects be notified again? On the receiver nodes, how can I detect when a session from the sender node comes in so that I can do something with it? Joseph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat clustering and NotSerializableException
As Richard says, don't store your request in the session, not a good idea. Richard Mixon (qwest) wrote: CoyoteRequestFacade is the first element in the stack trace - it is not the session stored object that is causing the NotSerializableException. As I said in my prior posting, to resolve this issue you need to: 1) Identify each object that you are explicitly storing in the session and make sure it directly or indirectly (through inheritance) specified that it implements Serializable. 2) Follow the chain from each session object to other objects that it references and make sure they are ALL marked as serializable (again - either directly or indirectly) That will fix your problem. These issues often do not come up until either you: 1. Try and use session replication. 2. Try to persist sessions to a datastore and access from a cluster. 3. Try to persist sessions across a restart of Tomcat. Also, please just reply to the list - not to the list and to the poster. HTH - Richard Sng Wee Jim wrote: But the stacktrace says java.io.NotSerializableException: org.apache.coyote.tomcat5.CoyoteRequestFacade at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1054) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:13 32) at Since CoyoteRequestFacade is a tomcat class, I assume it has to be fixed by the tomcat team. Unless the actual object that is not Serializable not CoyoteRequestFacade is available somewhere else... - Jim -Original Message- From: Richard Mixon (qwest) [mailto:[EMAIL PROTECTED] Sent: Monday, February 28, 2005 11:13 PM To: Tomcat Users List Subject: RE: Tomcat clustering and NotSerializableException As Matt said its probably your applications objects. When we switched to clustering I was surprised at how many of my session objects I needed to add serializable to. But it was easy work and quickl done. HTH - Richard Dale, Matt wrote: I would guess that this means you have an object in your session that does not implement the serializable interface. Ta Matt -Original Message- From: Sng Wee Jim [mailto:[EMAIL PROTECTED] Sent: 28 February 2005 09:21 To: tomcat-user@jakarta.apache.org Subject: Tomcat clustering and NotSerializableException Hi, I am using Tomcat 5.0.28 on MS Win2k server. After I have uncommented the Cluster element in server.xml, I get the following exceptions on the tomcat console for some actions that are using displaytag. Is it a tomcat bug, since org.apache.coyote.tomcat5.CoyoteRequestFacade is involved? (DeltaManager.java:813)- Unable to serialize delta request java.io.NotSerializableException: org.apache.coyote.tomcat5.CoyoteRequestFacade at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1054) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java 1332) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:13 04) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.jav a:1247) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278) at org.apache.catalina.cluster.session.DeltaRequest$AttributeInfo.writeE xternal(DeltaRequest.java:300) at org.apache.catalina.cluster.session.DeltaRequest.writeExternal(DeltaR equest.java:217) at org.apache.catalina.cluster.session.DeltaManager.unloadDeltaRequest(D eltaManager.java:393) at org.apache.catalina.cluster.session.DeltaManager.requestCompleted(Del taManager.java:782) at org.apache.catalina.cluster.tcp.ReplicationValve.invoke(ReplicationVa lve.java:203) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValv eContext.java:102) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j ava:118) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValv eContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav a:520) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal ve.java:109) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValv eContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav a:520) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:16 0) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:300) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:374) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:743) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.ja va:675) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:866) at
Re: skipping state transfer. No members active in cluster group
your multicast isn't working. Filip Randall Svancara wrote: I have a problem in my tomcat logs. I am using tomcat 5.5.7 and whenever I start up tomcat for the first time, I receive this error message. INFO: Manager[/testapp], skipping state transfer. No members active in cluster group. After the delta manager starts, I receive this error. Should I be concerned about this I have set distributable/ in my web.xml. My server.xml has all the clustering stuff enable. I have provided it below!! I have started up ethereal and I can see the multicast packets broadcasting. The data portion contains the ip address of the server. Everything looks like it should work. Randall Cluster className=org.apache.catalina.cluster.tcp.SimpleTcpCluster managerClassName=org.apache.catalina.cluster.session.DeltaManager expireSessionsOnShutdown=false useDirtyFlag=false notifyListenersOnReplication=true Membership className=org.apache.catalina.cluster.mcast.McastService mcastAddr=224.0.0.3 mcastPort=45564 mcastFrequency=500 mcastDropTime=3000 mcastBindAddress=10.111.22.163/ Receiver className=org.apache.catalina.cluster.tcp.ReplicationListener tcpListenAddress=10.111.22.163 tcpListenPort=4002 tcpSelectorTimeout=200 tcpThreadCount=6/ Sender className=org.apache.catalina.cluster.tcp.ReplicationTransmitter replicationMode=pooled ackTimeout=15000/ 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/ /Cluster - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SV: Cluster: will session listeners got called again after replication?
there is a flag you can set so that listeners don't get called, its optional its called notifyListenersOnReplication, see server.xml for example, default is true Filip Jesper Ekberg wrote: Hello! My first mail to this list. :) I have read it for a long time tho. We have a tried to cluster 3 Tomcat 5.5.7 machines and I found that HttpSessionBindingListener will be notified when the session is replicated and the machine crashes. I think this must be a bug?? The scenario: 3 Tomcat 5.5.7 machines on Windows 2003 Server (I know, not my fault ;)). JK2 Connector for load balancing. I log on and session is created and is replicated correctly to all machines. I shut down the server that I'm working on. The session is destroyed and method valueUnbound is called on the crashed machine. It seems odd to me that the method valueUnbound is called when the session is replicated, the session still lives on the other Tomcat machines. Sorry for my sometimes bad English ;) //Jesper -Ursprungligt meddelande- Från: Joseph Lam [mailto:[EMAIL PROTECTED] Skickat: den 24 februari 2005 08:44 Till: Tomcat Users List Ämne: Cluster: will session listeners got called again after replication? Anyone knows when a session is replicated to other nodes, will the HttpSessionBindingListener and HttpSessionAttributeListener objects be notified again? On the receiver nodes, how can I detect when a session from the sender node comes in so that I can do something with it? Joseph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cluster: Is session's lastAccessedTime got replicated?
unless the session is primary, the last accessed time wont matter, when the session becomes primary, the last access time gets set immediately. Filip Joseph Lam wrote: Found that only when a replication is explicitly triggered by set/removeAttribute(), the other nodes' session.getLastAccessedTime() will be synchronized. Joseph On Thu, 24 Feb 2005, Joseph Lam wrote: Hi, It seems that in my 4-node cluster (TC 5.5.8), the session.getLastAccessedTime() only returns the last accessed time in each particular node only. Is this normal? How can I get the last accessed time of a session across the whole cluster? Regards, Joseph Lam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SV: Cluster: will session listeners got called again after replication?
there is a difference between a crashed tomcat and a shutdown tomcat. Filip Filip Hanik - Dev Lists wrote: there is a flag you can set so that listeners don't get called, its optional its called notifyListenersOnReplication, see server.xml for example, default is true Filip Jesper Ekberg wrote: Hello! My first mail to this list. :) I have read it for a long time tho. We have a tried to cluster 3 Tomcat 5.5.7 machines and I found that HttpSessionBindingListener will be notified when the session is replicated and the machine crashes. I think this must be a bug?? The scenario: 3 Tomcat 5.5.7 machines on Windows 2003 Server (I know, not my fault ;)). JK2 Connector for load balancing. I log on and session is created and is replicated correctly to all machines. I shut down the server that I'm working on. The session is destroyed and method valueUnbound is called on the crashed machine. It seems odd to me that the method valueUnbound is called when the session is replicated, the session still lives on the other Tomcat machines. Sorry for my sometimes bad English ;) //Jesper -Ursprungligt meddelande- Från: Joseph Lam [mailto:[EMAIL PROTECTED] Skickat: den 24 februari 2005 08:44 Till: Tomcat Users List Ämne: Cluster: will session listeners got called again after replication? Anyone knows when a session is replicated to other nodes, will the HttpSessionBindingListener and HttpSessionAttributeListener objects be notified again? On the receiver nodes, how can I detect when a session from the sender node comes in so that I can do something with it? Joseph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cluster: how to set mcast interface for dual LAN card?
there is an attribute mcastBindAddr that allows you to bind to the interface. Joseph Lam wrote: Hi, If I have two LAN cards and I want my Tomcat to mcast through one of them, what parameter should I set? Regards, Joseph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Load balancing SSL sessions
you can also use DNS round robin, www.mysite.com resolves to two or more IP addresses. Filip Andrew Miehs wrote: We use F5 BigIPs, but they are probably overkill for your application - The cisco probably will be as well. A 'Cheap' software solution might be to work with redirects, and 2 separate IP addresses. ie: ssl1.mysite.com and ssl2.mysite.com - You will need 2 ssl keys though for this to work. Does all of your app require ssl? or just a certain part, ie: payment. Do you need the stickiness for the whole app? or just for the ssl (seeing you are using tomcat, you will probably need it for the whole app)... Andrew On Feb 22, 2005, at 10:24 PM, Kelly Vista wrote: Hi - We are looking to deploy our app, running on Tomcat 5, soon and are exploring load balancing options. We are looking at H/W and S/W solutions, and I was wondering if anyone had any past experience/advice they would like to share. Our deployment is as pretty run-of-the-mill as it gets: 2 machines, each running Tomcat. We would like to avoid replicating state (since we have a lot of state in these apps, for reasons beyond our current control). Even in-memory session replication would not be option here, so we're punting on the Tomcat cluster solution. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dodgy session class
Nice catch Vlad, I'll look into it. Filip [EMAIL PROTECTED] wrote: thanks for your reply Peter. unfortunately none of the applications has explicitly configured sessions manager. I have managed to consistently reproduce the problem. The problem involves two webapps, app1 and app2. App1 is distributable. App2 contains a filter that forwards requests to app1. As it turns out all sessions created via filter are instances of StandardSession! This is with app1 being distributable and with cluster session manager. Making app2 distributable doesnt seem to have any effect on the sessions that are being created in app1 context. I've attached a test case with two sample webapps, to run them you just have to make sure crossContext is enabled for app2 and context of app1 is actually called /app1. App1 does some nasty hack to display what Class is actually hiding behind session facade, so you would have to excuse me for that. Another thing that i've noticed along the way: if a request goes to app1 via filter in app2 two sessions are created, one for each context. Filter in app2 does not create sessions explicitly (as you will see from the example) and session would not be created for app2 context if filter didnt forward requests to app1 context. The question is why session gets created implicitly in context of app2? It is not that I cannot live with it, just cant think of a logical explanation to this. Ideas anyone? Regards, Vlad -Original Message- From: Peter Rossbach [mailto:[EMAIL PROTECTED] Sent: Sat 2/12/2005 9:22 AM To: Tomcat Users List Cc: Subject:Re: dodgy session class Hmm, please check that all your applications with distributable=true have no configured Manager in there context.xml's regards Peter Filip Hanik - Dev schrieb: Any chance you have a test case to reproduce this? Shouldn't happen, unless the way sessions are created have changed. Filip - Original Message - From: [EMAIL PROTECTED] To: tomcat-user@jakarta.apache.org Sent: Friday, February 11, 2005 11:47 AM Subject: dodgy session class Hi, I'm running tomcat 5.0.30 on two machines A and B (Linux RHAS3). When tomcat A restarts it fails to sync session state with session state not received or something to that effect and tomcat B logs this message: 11 Feb 2005 17:21:49 [org.apache.catalina.cluster.tcp.TcpReplicationThread[4]] ERROR org.apache.catalina.cluster.session.SimpleTcpReplicationManager - Unable to receive message through TCP channel java.lang.ClassCastException at org.apache.catalina.cluster.session.SimpleTcpReplicationManager.messageR eceived(SimpleTcpReplicationManager.java:530) at org.apache.catalina.cluster.session.SimpleTcpReplicationManager.messageD ataReceived(SimpleTcpReplicationManager.java:596) at org.apache.catalina.cluster.tcp.SimpleTcpCluster.messageDataReceived(Sim pleTcpCluster.java:580) at org.apache.catalina.cluster.io.ObjectReader.execute(ObjectReader.java:70 ) at org.apache.catalina.cluster.tcp.TcpReplicationThread.drainChannel(TcpRep licationThread.java:129) at org.apache.catalina.cluster.tcp.TcpReplicationThread.run(TcpReplicationT hread.java:67) I changed SimpleTcpReplicationManager to output class names of the sessions it is trying to cast to ReplicatedSession and got the following picture: 11 Feb 2005 17:21:44 [Cluster-MembershipReceiver] INFO org.apache.catalina.cluster.tcp.SimpleTcpCluster - Replication member added:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.56.21: 4001,192.168.56.21,4001, alive=3] 11 Feb 2005 17:21:49 [org.apache.catalina.cluster.tcp.TcpReplicationThread[4]] INFO org.apache.catalina.cluster.session.SimpleTcpReplicationManager - SessionClass=org.apache.catalina.cluster.session.ReplicatedSession 11 Feb 2005 17:21:49 [org.apache.catalina.cluster.tcp.TcpReplicationThread[4]] INFO org.apache.catalina.cluster.session.SimpleTcpReplicationManager - SessionClass=org.apache.catalina.cluster.session.ReplicatedSession 11 Feb 2005 17:21:49 [org.apache.catalina.cluster.tcp.TcpReplicationThread[4]] INFO org.apache.catalina.cluster.session.SimpleTcpReplicationManager - SessionClass=org.apache.catalina.cluster.session.ReplicatedSession 11 Feb 2005 17:21:49 [org.apache.catalina.cluster.tcp.TcpReplicationThread[4]] INFO org.apache.catalina.cluster.session.SimpleTcpReplicationManager - SessionClass=org.apache.catalina.cluster.session.ReplicatedSession 11 Feb 2005 17:21:49 [org.apache.catalina.cluster.tcp.TcpReplicationThread[4]] INFO org.apache.catalina.cluster.session.SimpleTcpReplicationManager - SessionClass=org.apache.catalina.cluster.session.ReplicatedSession 11 Feb 2005 17:21:49 [org.apache.catalina.cluster.tcp.TcpReplicationThread[4]] INFO org.apache.catalina.cluster.session.SimpleTcpReplicationManager - SessionClass=org.apache.catalina.cluster.session.ReplicatedSession 11 Feb 2005 17:21:49 [org.apache.catalina.cluster.tcp.TcpReplicationThread[4]] INFO
Re: dodgy session class
Actually, I didn't get your attachments, could you open a bug in bugzilla and attach them there. Filip [EMAIL PROTECTED] wrote: thanks for your reply Peter. unfortunately none of the applications has explicitly configured sessions manager. I have managed to consistently reproduce the problem. The problem involves two webapps, app1 and app2. App1 is distributable. App2 contains a filter that forwards requests to app1. As it turns out all sessions created via filter are instances of StandardSession! This is with app1 being distributable and with cluster session manager. Making app2 distributable doesnt seem to have any effect on the sessions that are being created in app1 context. I've attached a test case with two sample webapps, to run them you just have to make sure crossContext is enabled for app2 and context of app1 is actually called /app1. App1 does some nasty hack to display what Class is actually hiding behind session facade, so you would have to excuse me for that. Another thing that i've noticed along the way: if a request goes to app1 via filter in app2 two sessions are created, one for each context. Filter in app2 does not create sessions explicitly (as you will see from the example) and session would not be created for app2 context if filter didnt forward requests to app1 context. The question is why session gets created implicitly in context of app2? It is not that I cannot live with it, just cant think of a logical explanation to this. Ideas anyone? Regards, Vlad -Original Message- From: Peter Rossbach [mailto:[EMAIL PROTECTED] Sent: Sat 2/12/2005 9:22 AM To: Tomcat Users List Cc: Subject:Re: dodgy session class Hmm, please check that all your applications with distributable=true have no configured Manager in there context.xml's regards Peter Filip Hanik - Dev schrieb: Any chance you have a test case to reproduce this? Shouldn't happen, unless the way sessions are created have changed. Filip - Original Message - From: [EMAIL PROTECTED] To: tomcat-user@jakarta.apache.org Sent: Friday, February 11, 2005 11:47 AM Subject: dodgy session class Hi, I'm running tomcat 5.0.30 on two machines A and B (Linux RHAS3). When tomcat A restarts it fails to sync session state with session state not received or something to that effect and tomcat B logs this message: 11 Feb 2005 17:21:49 [org.apache.catalina.cluster.tcp.TcpReplicationThread[4]] ERROR org.apache.catalina.cluster.session.SimpleTcpReplicationManager - Unable to receive message through TCP channel java.lang.ClassCastException at org.apache.catalina.cluster.session.SimpleTcpReplicationManager.messageR eceived(SimpleTcpReplicationManager.java:530) at org.apache.catalina.cluster.session.SimpleTcpReplicationManager.messageD ataReceived(SimpleTcpReplicationManager.java:596) at org.apache.catalina.cluster.tcp.SimpleTcpCluster.messageDataReceived(Sim pleTcpCluster.java:580) at org.apache.catalina.cluster.io.ObjectReader.execute(ObjectReader.java:70 ) at org.apache.catalina.cluster.tcp.TcpReplicationThread.drainChannel(TcpRep licationThread.java:129) at org.apache.catalina.cluster.tcp.TcpReplicationThread.run(TcpReplicationT hread.java:67) I changed SimpleTcpReplicationManager to output class names of the sessions it is trying to cast to ReplicatedSession and got the following picture: 11 Feb 2005 17:21:44 [Cluster-MembershipReceiver] INFO org.apache.catalina.cluster.tcp.SimpleTcpCluster - Replication member added:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.56.21: 4001,192.168.56.21,4001, alive=3] 11 Feb 2005 17:21:49 [org.apache.catalina.cluster.tcp.TcpReplicationThread[4]] INFO org.apache.catalina.cluster.session.SimpleTcpReplicationManager - SessionClass=org.apache.catalina.cluster.session.ReplicatedSession 11 Feb 2005 17:21:49 [org.apache.catalina.cluster.tcp.TcpReplicationThread[4]] INFO org.apache.catalina.cluster.session.SimpleTcpReplicationManager - SessionClass=org.apache.catalina.cluster.session.ReplicatedSession 11 Feb 2005 17:21:49 [org.apache.catalina.cluster.tcp.TcpReplicationThread[4]] INFO org.apache.catalina.cluster.session.SimpleTcpReplicationManager - SessionClass=org.apache.catalina.cluster.session.ReplicatedSession 11 Feb 2005 17:21:49 [org.apache.catalina.cluster.tcp.TcpReplicationThread[4]] INFO org.apache.catalina.cluster.session.SimpleTcpReplicationManager - SessionClass=org.apache.catalina.cluster.session.ReplicatedSession 11 Feb 2005 17:21:49 [org.apache.catalina.cluster.tcp.TcpReplicationThread[4]] INFO org.apache.catalina.cluster.session.SimpleTcpReplicationManager - SessionClass=org.apache.catalina.cluster.session.ReplicatedSession 11 Feb 2005 17:21:49 [org.apache.catalina.cluster.tcp.TcpReplicationThread[4]] INFO org.apache.catalina.cluster.session.SimpleTcpReplicationManager - SessionClass=org.apache.catalina.cluster.session.ReplicatedSession 11 Feb 2005 17:21:49
Re: JK, Session Replication/Clustering, SSL and failover in Tomcat 5
expireSessionsOnShutdown=true set this property to false! this will not kill the sessions on the other servers during shutdown. but, yes kill -9 or taskmanager killing it, will work too Filip Richard Mixon (qwest) wrote: Filip, Thanks so much for some reason taking the Manager statement completely out of the context worked. I can now see session replication occurring, which then identified some objects that were not serializable. I have fixed these and can see the session replicating correctly in the log messages. I quickly realized that I could not just run catalina stop as this caused the session to be deleted on both the tomcat instance that was stopping and on the remaining Tomcat instance - hence the reason I was always prompted to re-login in. So how do I trigger the maintenance failover? If I use the Admin console to delete the port 8009 connector (first Tomcat instance), this does not prevent JK from continuing to route traffic to this instance. I also tried using ant stop from the tomcat-deployer, but this results in a HTTP Status 503 - This application is not currently available message. I feel like I'm very close, but not quite there. Thank you - Richard Filip Hanik - Dev wrote: you said you enabled it in your context.xml file, if so remove it Filip - Original Message - From: Richard Mixon (qwest) [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Cc: Sent: Thursday, January 27, 2005 12:08 PM Subject: RE: JK, Session Replication/Clustering, SSL and failover in Tomcat 5 Filip, Yes you did say that earlier. However I do not reference PersistentManager anywhere in my server.xml. How is it getting enable? Here is the clustering part if my server.xml (I can send the entire server.xml if necessary). Cluster className=org.apache.catalina.cluster.tcp.SimpleTcpCluster managerClassName=org.apache.catalina.cluster.session.D eltaManager expireSessionsOnShutdown=true useDirtyFlag=true notifyListenersOnReplication=true Membership className=org.apache.catalina.cluster.mcast.McastServic e mcastAddr=228.0.0.4 mcastPort=45564 mcastFrequency=500 mcastDropTime=3000/ Receiver className=org.apache.catalina.cluster.tcp.ReplicationLi stener tcpListenAddress=auto tcpListenPort=4001 tcpSelectorTimeout=100 tcpThreadCount=6/ Sender className=org.apache.catalina.cluster.tcp.ReplicationTr ansmitter replicationMode=pooled ackTimeout=15000/ Valve className=org.apache.catalina.cluster.tcp.ReplicationValve filter=.*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.ht ml;.*\.css;.*\.txt;/ Deployer className=org.apache.catalina.cluster.deploy.FarmWarDeployer tempDir=c:/jakarta-tomcat-5.5.7/temp deployDir=c:/jakarta-tomcat-5.5.7/webapps watchDir=c:/jakarta-tomcat-5.5.7-deployer/build/w ebapp watchEnabled=false/ /Cluster Thank you - Richard -Original Message- From: Filip Hanik - Dev [mailto:[EMAIL PROTECTED] Sent: Thursday, January 27, 2005 10:34 AM To: Tomcat Users List Cc: [EMAIL PROTECTED] Subject: Re: JK, Session Replication/Clustering, SSL and failover in Tomcat 5 As mentioned, you can't have the persistence manager, with clustering. DEBUG TP-Processor3 org.apache.catalina.cluster.session.JvmRouteBinderValve - No Cluster DeltaManager [EMAIL PROTECTED] at /stars - Original Message - From: Richard Mixon (qwest) [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Sent: Thursday, January 27, 2005 10:55 AM Subject: RE: JK, Session Replication/Clustering, SSL and failover in Tomcat 5 Filip/all, Thank you - with your suggestion I was able to get it configured as follows: 1) After the Server line in server.xml I added Listener className=org.apache.catalina.cluster.session.JvmRouteSessionIDBinderLi fecycleListener / 2) I added to the conf/context.xml this line: Valve className=org.apache.catalina.cluster.session.JvmRouteBinderValve / All starts fine. But I still get prompted to logon when the failover occurs from srv1 to srv2. Here are the Tomcat logs (I have mostly just the cluster logging enabled. Can you see anything that is not correct? TOMCAT LOG - SRV1 BEGIN DEBUG main org.apache.catalina.cluster.tcp.ReplicationTransmitter - Setting replcation mode to pooled DEBUG main org.apache.catalina.cluster.tcp.ReplicationValve - Loading request filters=.*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt; DEBUG main org.apache.catalina.cluster.tcp.ReplicationValve - Request filter=.*\.gif DEBUG main org.apache.catalina.cluster.tcp.ReplicationValve - Request filter=.*\.js DEBUG main org.apache.catalina.cluster.tcp.ReplicationValve - Request filter=.*\.jpg DEBUG main org.apache.catalina.cluster.tcp.ReplicationValve -
Re: JK, Session Replication/Clustering, SSL and failover in Tomcat 5
Interesting, I haven't done any work with the latest work of tomcat because of engagements elsewhere. but you have the time to create a very small simple war file where this occurs, I will look at it tomorrow. It looks like the context class loader is not getting set properly, and this could be an actual bug. I'll try to get this running tomorrow. Filip Richard Mixon (qwest) wrote: Filip Hanik - Dev lists wrote: expireSessionsOnShutdown=true set this property to false! this will not kill the sessions on the other servers during shutdown. but, yes kill -9 or taskmanager killing it, will work too Filip, Thank you so much. Setting expireSessionsOnShutdown=false allowed failover to occur without prompting the user to login again. Wonderful! However, I then brought srv1 back up I got a number of exceptions when they tried to re-synchronize with the still running srv2. Any ideas on how to resolve this? Thanks again - Richard TOMCAT LOG: INFO main org.apache.catalina.cluster.tcp.SimpleTcpCluster - Cluster is about to start DEBUG main org.apache.catalina.cluster.tcp.SimpleTcpCluster - Invoking addValve on StandardEngine[Catalina].StandardHost[localhost] with class=org.apache.catalina.cluster.tcp.ReplicationValve DEBUG main org.apache.catalina.cluster.tcp.ReplicationListener - Starting replication listener on address:192.168.1.140 INFO main org.apache.catalina.cluster.mcast.McastService - Sleeping for 2000 secs to establish cluster membership INFO Cluster-MembershipReceiver org.apache.catalina.cluster.tcp.SimpleTcpCluster - Replication member added:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.140: 4002,192.168.1.140,4002, alive=153297] INFO main org.apache.catalina.cluster.deploy.FarmWarDeployer - Cluster FarmWarDeployer started. INFO main org.apache.catalina.cluster.session.JvmRouteBinderValve - JvmRouteBinderValve started DEBUG main org.apache.catalina.cluster.tcp.SimpleTcpCluster - Creating ClusterManager for context /stars using class org.apache.catalina.cluster.session.DeltaManager DEBUG org.apache.catalina.cluster.tcp.TcpReplicationThread[2] org.apache.catalina.cluster.tcp.SimpleTcpCluster - Assuming clocks are synched: Replication took=141 ms. DEBUG org.apache.catalina.cluster.tcp.TcpReplicationThread[2] org.apache.catalina.cluster.session.DeltaManager - readObject() loading session B8CBD8B217266316C21F64ED963EB502.srv2 DEBUG org.apache.catalina.cluster.tcp.TcpReplicationThread[2] org.apache.catalina.cluster.session.DeltaManager - readObject() loading session D0FC475D32E30BD6BDC4814DDFED39F7.srv2 ERROR org.apache.catalina.cluster.tcp.TcpReplicationThread[2] org.apache.struts.util.MessageResourcesFactory - MessageResourcesFactory.createFactory java.lang.ClassNotFoundException: org.apache.struts.util.PropertyMessageResourcesFactory at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.apache.struts.util.RequestUtils.applicationClass(RequestUtils.java:1 19) at org.apache.struts.util.MessageResourcesFactory.createFactory(MessageReso urcesFactory.java:150) at org.apache.struts.util.MessageResources.getMessageResources(MessageResou rces.java:495) at com.ltoj.webapp.util.ClassGrid.clinit(ClassGrid.java:63) at java.io.ObjectStreamClass.hasStaticInitializer(Native Method) at java.io.ObjectStreamClass.computeDefaultSUID(ObjectStreamClass.java:1641 ) at java.io.ObjectStreamClass.access$100(ObjectStreamClass.java:47) at java.io.ObjectStreamClass$1.run(ObjectStreamClass.java:175) at java.security.AccessController.doPrivileged(Native Method) at java.io.ObjectStreamClass.getSerialVersionUID(ObjectStreamClass.java:172 ) at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:515) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1546) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1460) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1693 ) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339) at org.apache.catalina.cluster.session.DeltaSession.readObject(DeltaSession .java:1414) at org.apache.catalina.cluster.session.DeltaSession.readObjectData(DeltaSes sion.java:910) at org.apache.catalina.cluster.session.DeltaManager.doLoad(DeltaManager.jav a:391) at org.apache.catalina.cluster.session.DeltaManager.messageReceived(DeltaMa nager.java:842) at org.apache.catalina.cluster.session.DeltaManager.messageDataReceived(Del taManager.java:712
Re: JK, Session Replication/Clustering, SSL and failover in Tomcat 5
I meant, if you have time to create a simple test app, that I can work with, it will speed up the process Filip Filip Hanik - Dev lists wrote: Interesting, I haven't done any work with the latest work of tomcat because of engagements elsewhere. but you have the time to create a very small simple war file where this occurs, I will look at it tomorrow. It looks like the context class loader is not getting set properly, and this could be an actual bug. I'll try to get this running tomorrow. Filip Richard Mixon (qwest) wrote: Filip Hanik - Dev lists wrote: expireSessionsOnShutdown=true set this property to false! this will not kill the sessions on the other servers during shutdown. but, yes kill -9 or taskmanager killing it, will work too Filip, Thank you so much. Setting expireSessionsOnShutdown=false allowed failover to occur without prompting the user to login again. Wonderful! However, I then brought srv1 back up I got a number of exceptions when they tried to re-synchronize with the still running srv2. Any ideas on how to resolve this? Thanks again - Richard TOMCAT LOG: INFO main org.apache.catalina.cluster.tcp.SimpleTcpCluster - Cluster is about to start DEBUG main org.apache.catalina.cluster.tcp.SimpleTcpCluster - Invoking addValve on StandardEngine[Catalina].StandardHost[localhost] with class=org.apache.catalina.cluster.tcp.ReplicationValve DEBUG main org.apache.catalina.cluster.tcp.ReplicationListener - Starting replication listener on address:192.168.1.140 INFO main org.apache.catalina.cluster.mcast.McastService - Sleeping for 2000 secs to establish cluster membership INFO Cluster-MembershipReceiver org.apache.catalina.cluster.tcp.SimpleTcpCluster - Replication member added:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.140: 4002,192.168.1.140,4002, alive=153297] INFO main org.apache.catalina.cluster.deploy.FarmWarDeployer - Cluster FarmWarDeployer started. INFO main org.apache.catalina.cluster.session.JvmRouteBinderValve - JvmRouteBinderValve started DEBUG main org.apache.catalina.cluster.tcp.SimpleTcpCluster - Creating ClusterManager for context /stars using class org.apache.catalina.cluster.session.DeltaManager DEBUG org.apache.catalina.cluster.tcp.TcpReplicationThread[2] org.apache.catalina.cluster.tcp.SimpleTcpCluster - Assuming clocks are synched: Replication took=141 ms. DEBUG org.apache.catalina.cluster.tcp.TcpReplicationThread[2] org.apache.catalina.cluster.session.DeltaManager - readObject() loading session B8CBD8B217266316C21F64ED963EB502.srv2 DEBUG org.apache.catalina.cluster.tcp.TcpReplicationThread[2] org.apache.catalina.cluster.session.DeltaManager - readObject() loading session D0FC475D32E30BD6BDC4814DDFED39F7.srv2 ERROR org.apache.catalina.cluster.tcp.TcpReplicationThread[2] org.apache.struts.util.MessageResourcesFactory - MessageResourcesFactory.createFactory java.lang.ClassNotFoundException: org.apache.struts.util.PropertyMessageResourcesFactory at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.apache.struts.util.RequestUtils.applicationClass(RequestUtils.java:1 19) at org.apache.struts.util.MessageResourcesFactory.createFactory(MessageReso urcesFactory.java:150) at org.apache.struts.util.MessageResources.getMessageResources(MessageResou rces.java:495) at com.ltoj.webapp.util.ClassGrid.clinit(ClassGrid.java:63) at java.io.ObjectStreamClass.hasStaticInitializer(Native Method) at java.io.ObjectStreamClass.computeDefaultSUID(ObjectStreamClass.java:1641 ) at java.io.ObjectStreamClass.access$100(ObjectStreamClass.java:47) at java.io.ObjectStreamClass$1.run(ObjectStreamClass.java:175) at java.security.AccessController.doPrivileged(Native Method) at java.io.ObjectStreamClass.getSerialVersionUID(ObjectStreamClass.java:172 ) at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:515) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1546) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1460) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1693 ) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339) at org.apache.catalina.cluster.session.DeltaSession.readObject(DeltaSession .java:1414) at org.apache.catalina.cluster.session.DeltaSession.readObjectData(DeltaSes sion.java:910) at org.apache.catalina.cluster.session.DeltaManager.doLoad(DeltaManager.jav a:391) at org.apache.catalina.cluster.session.DeltaManager.messageReceived(DeltaMa nager.java:842) at org.apache.catalina.cluster.session.DeltaManager.messageDataReceived(Del taManager.java:712
Re: JK, Session Replication/Clustering, SSL and failover in Tomcat 5
another thought, this object com.ltoj.webapp.util.ClassGrid does it contain a reference to a struts object, and maybe that is why the loading doesn't work, just a thought. Filip Filip Hanik - Dev lists wrote: Interesting, I haven't done any work with the latest work of tomcat because of engagements elsewhere. but you have the time to create a very small simple war file where this occurs, I will look at it tomorrow. It looks like the context class loader is not getting set properly, and this could be an actual bug. I'll try to get this running tomorrow. Filip Richard Mixon (qwest) wrote: Filip Hanik - Dev lists wrote: expireSessionsOnShutdown=true set this property to false! this will not kill the sessions on the other servers during shutdown. but, yes kill -9 or taskmanager killing it, will work too Filip, Thank you so much. Setting expireSessionsOnShutdown=false allowed failover to occur without prompting the user to login again. Wonderful! However, I then brought srv1 back up I got a number of exceptions when they tried to re-synchronize with the still running srv2. Any ideas on how to resolve this? Thanks again - Richard TOMCAT LOG: INFO main org.apache.catalina.cluster.tcp.SimpleTcpCluster - Cluster is about to start DEBUG main org.apache.catalina.cluster.tcp.SimpleTcpCluster - Invoking addValve on StandardEngine[Catalina].StandardHost[localhost] with class=org.apache.catalina.cluster.tcp.ReplicationValve DEBUG main org.apache.catalina.cluster.tcp.ReplicationListener - Starting replication listener on address:192.168.1.140 INFO main org.apache.catalina.cluster.mcast.McastService - Sleeping for 2000 secs to establish cluster membership INFO Cluster-MembershipReceiver org.apache.catalina.cluster.tcp.SimpleTcpCluster - Replication member added:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.140: 4002,192.168.1.140,4002, alive=153297] INFO main org.apache.catalina.cluster.deploy.FarmWarDeployer - Cluster FarmWarDeployer started. INFO main org.apache.catalina.cluster.session.JvmRouteBinderValve - JvmRouteBinderValve started DEBUG main org.apache.catalina.cluster.tcp.SimpleTcpCluster - Creating ClusterManager for context /stars using class org.apache.catalina.cluster.session.DeltaManager DEBUG org.apache.catalina.cluster.tcp.TcpReplicationThread[2] org.apache.catalina.cluster.tcp.SimpleTcpCluster - Assuming clocks are synched: Replication took=141 ms. DEBUG org.apache.catalina.cluster.tcp.TcpReplicationThread[2] org.apache.catalina.cluster.session.DeltaManager - readObject() loading session B8CBD8B217266316C21F64ED963EB502.srv2 DEBUG org.apache.catalina.cluster.tcp.TcpReplicationThread[2] org.apache.catalina.cluster.session.DeltaManager - readObject() loading session D0FC475D32E30BD6BDC4814DDFED39F7.srv2 ERROR org.apache.catalina.cluster.tcp.TcpReplicationThread[2] org.apache.struts.util.MessageResourcesFactory - MessageResourcesFactory.createFactory java.lang.ClassNotFoundException: org.apache.struts.util.PropertyMessageResourcesFactory at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.apache.struts.util.RequestUtils.applicationClass(RequestUtils.java:1 19) at org.apache.struts.util.MessageResourcesFactory.createFactory(MessageReso urcesFactory.java:150) at org.apache.struts.util.MessageResources.getMessageResources(MessageResou rces.java:495) at com.ltoj.webapp.util.ClassGrid.clinit(ClassGrid.java:63) at java.io.ObjectStreamClass.hasStaticInitializer(Native Method) at java.io.ObjectStreamClass.computeDefaultSUID(ObjectStreamClass.java:1641 ) at java.io.ObjectStreamClass.access$100(ObjectStreamClass.java:47) at java.io.ObjectStreamClass$1.run(ObjectStreamClass.java:175) at java.security.AccessController.doPrivileged(Native Method) at java.io.ObjectStreamClass.getSerialVersionUID(ObjectStreamClass.java:172 ) at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:515) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1546) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1460) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1693 ) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339) at org.apache.catalina.cluster.session.DeltaSession.readObject(DeltaSession .java:1414) at org.apache.catalina.cluster.session.DeltaSession.readObjectData(DeltaSes sion.java:910) at org.apache.catalina.cluster.session.DeltaManager.doLoad(DeltaManager.jav a:391) at org.apache.catalina.cluster.session.DeltaManager.messageReceived(DeltaMa nager.java:842
Re: JK, Session Replication/Clustering, SSL and failover in Tomcat 5
Hi Richard,
Static variable don't get serialized with an object (anyone correct me
if I am wrong), so that is not the problem.
I believe it to be a bug. Struts is taking a class loader and loading
the data, my guess is that its taking the context classloader, and that
one is not set properly.
Let me see what I can dig up before I send you off to do something crazy :)
Filip
Richard Mixon (qwest) wrote:
Filip Hanik - Dev lists wrote:
another thought,
this object com.ltoj.webapp.util.ClassGrid
does it contain a reference to a struts object, and maybe that is why
the loading doesn't work, just a thought.
Filip Hanik - Dev lists wrote:
Interesting, I haven't done any work with the latest work of tomcat
because of engagements elsewhere. but you have the time to create a
very small simple war file where this occurs, I will look at it
tomorrow.
It looks like the context class loader is not getting set properly,
and this could be an actual bug. I'll try to get this running
tomorrow.
Filip, I believe you hit it once again. I've got code such as:
...
public class ClassGrid implements java.io.Serializable
{
static MessageResources msgRsrcs =
MessageResources.getMessageResources(ApplicationResources);
private static Log log = LogFactory.getLog(ClassGrid.class);
Both the variables log and msgRsrcs are static initialized and would
be a problem when replicating from one JVM to another.
The instance variable log should not even be static - can fix that.
The variable msgRsrcs I'm not sure how to fix. I've been fighting with
too much reference to Struts in my business logic for a while. I know
better, but have had problems seeing around how to handle such things as
i18n message resource handling which Struts does so well. Any
suggestions? I realize this is quite off-topic.
Thank you much - Richard
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
