Re: tomcat 5.0.24 crashes silently when clustering turned on
We could try upgrading our JVM from 1.4.2 but I'm concerned with going to 5.0 in case that causes other things to break. Will TC 5.0.24 run on a 5.0 JVM? --- It does, im running it on 5.0 on win platform Regards, Chandan On 9/12/05, Mike Noel [EMAIL PROTECTED] wrote: Which platform/OS? I've no experience on Win, but I never experienced a tomcat crash on unix/linux. Nevertheless five comments: This is running on RHEL 3.2.3-39 and Java 1.4.2. 0) jk2 is no longer under development. The only active connector development for apache is mod_jk and mod_proxy (for the upcoming apache 2.1/2.2). Yes, I know that jk2 is dead. We set these servers up with it almost a year ago, before it was pronounced dead, and I was hoping to not have to change. 1) If you really want to use clustering, either choose the tomcat 5.5line (preferably with fastasyncmode), or at least 5.0.28 (better 5.0.30). Are there any config file changes in going from 5.0.24 to 5.0.28? 2) Some *nixes and shells will send signals, when the user starting tomcat logs out of the system resulting in killed tomcat processes. Inj that case use nohup or any similar workaround. This isn't an issue in my case. Tomcat dies before I log out of the shell. 3) With replication you will need more memory. Any indications for OutOfMemory? Nope. 4) The only real process crashes I experienced where fixed by updates to bug fix releases of the JVM. We could try upgrading our JVM from 1.4.2 but I'm concerned with going to 5.0 in case that causes other things to break. Will TC 5.0.24 run on a 5.0 JVM? -Mike Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 5.0.24 crashes silently when clustering turned on
Which platform/OS? I've no experience on Win, but I never experienced a tomcat crash on unix/linux. Nevertheless five comments: This is running on RHEL 3.2.3-39 and Java 1.4.2. 0) jk2 is no longer under development. The only active connector development for apache is mod_jk and mod_proxy (for the upcoming apache 2.1/2.2). Yes, I know that jk2 is dead. We set these servers up with it almost a year ago, before it was pronounced dead, and I was hoping to not have to change. 1) If you really want to use clustering, either choose the tomcat 5.5 line (preferably with fastasyncmode), or at least 5.0.28 (better 5.0.30). Are there any config file changes in going from 5.0.24 to 5.0.28? 2) Some *nixes and shells will send signals, when the user starting tomcat logs out of the system resulting in killed tomcat processes. Inj that case use nohup or any similar workaround. This isn't an issue in my case. Tomcat dies before I log out of the shell. 3) With replication you will need more memory. Any indications for OutOfMemory? Nope. 4) The only real process crashes I experienced where fixed by updates to bug fix releases of the JVM. We could try upgrading our JVM from 1.4.2 but I'm concerned with going to 5.0 in case that causes other things to break. Will TC 5.0.24 run on a 5.0 JVM? -Mike Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 5.0.24 crashes silently when clustering turned on
Which platform/OS? I've no experience on Win, but I never experienced a tomcat crash on unix/linux. Nevertheless five comments: 0) jk2 is no longer under development. The only active connector development for apache is mod_jk and mod_proxy (for the upcoming apache 2.1/2.2). 1) If you really want to use clustering, either choose the tomcat 5.5 line (preferably with fastasyncmode), or at least 5.0.28 (better 5.0.30). 2) Some *nixes and shells will send signals, when the user starting tomcat logs out of the system resulting in killed tomcat processes. Inj that case use nohup or any similar workaround. 3) With replication you will need more memory. Any indications for OutOfMemory? 4) The only real process crashes I experienced where fixed by updates to bug fix releases of the JVM. I am trying to set up a 2-node cluster. Each node runs 5.0.24 with apache 2.0.50 in front (with SSL). I use the JK2 v. 2.0.43 connector. What I'm seeing doesn't make sense. I get tomcat and apache up on the first node and everything works fine. The clustering section in the server.xml file is uncommented and I've configured all of the appropriate values. Once that's working I turn to node 2. On the second node I start apache and tomcat and everything looks good for a bit. I have most of the tomcat output going to the consoleappender so I capture that output into a file. After anywhere from 1 - 2 minutes tomcat exits. There is no thread dump printed in any of the logfiles (including stdout/stderr). When I look in my log files I see normal activity for the little bit that TC is running and then it simply quits. There is no indication of TC going through the shutdown process. When tomcat exits it generates a non-zero exit code. When I first saw this problem a few weeks ago it was when I was deploying clustering in my production environment. After seeing TC exit like this 3 times in a row I rolled back my deployment and have spent the time trying to figure out what went wrong. I didn't note the exit code number! I have two different test environments setup with very similar configuration and I'm not having this problem on either of them. I'm at the point now where I'm going to have to try to deploy to production again but since I've not changed anything I'm fully expecting it to fail. This time I'll note the exit code number. Have any of you seen anything like this? What things can I adjust to enable more debugging output? Thanks for any info. -Mike Noel - 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]
tomcat 5.0.24 crashes silently when clustering turned on
I am trying to set up a 2-node cluster. Each node runs 5.0.24 with apache 2.0.50 in front (with SSL). I use the JK2 v. 2.0.43 connector. What I'm seeing doesn't make sense. I get tomcat and apache up on the first node and everything works fine. The clustering section in the server.xml file is uncommented and I've configured all of the appropriate values. Once that's working I turn to node 2. On the second node I start apache and tomcat and everything looks good for a bit. I have most of the tomcat output going to the consoleappender so I capture that output into a file. After anywhere from 1 - 2 minutes tomcat exits. There is no thread dump printed in any of the logfiles (including stdout/stderr). When I look in my log files I see normal activity for the little bit that TC is running and then it simply quits. There is no indication of TC going through the shutdown process. When tomcat exits it generates a non-zero exit code. When I first saw this problem a few weeks ago it was when I was deploying clustering in my production environment. After seeing TC exit like this 3 times in a row I rolled back my deployment and have spent the time trying to figure out what went wrong. I didn't note the exit code number! I have two different test environments setup with very similar configuration and I'm not having this problem on either of them. I'm at the point now where I'm going to have to try to deploy to production again but since I've not changed anything I'm fully expecting it to fail. This time I'll note the exit code number. Have any of you seen anything like this? What things can I adjust to enable more debugging output? Thanks for any info. -Mike Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clustering problems
Read the doc and configure greater waitForAck timeouts and more pooled worker. Sender ... ackTimeout=5 maxPoolSocketLimit=40 .. I only used fastasyncqueue mode in my production system! Sender className=org.apache.catalina.cluster.tcp.ReplicationTransmitter replicationMode=fastasyncqueue doTransmitterProcessingStats=true doProcessingStats=true doWaitAckStats=true queueTimeWait=true queueDoStats=true queueCheckLock=true waitForAck=false keepAliveTimeout=8 keepAliveMaxRequestCount=-1/ Peter Randy Paries schrieb: Hello I have two tomcat servers (flanders and krusty) Their server.xmls are below they have two nic cards. The incoming http requests come in via the 192.168 ips and go out the real ips 66.208 the 192.168 nics are on a gigbit network When my servers get really busy i messages in the log file (see below) Once this happens my httpd starts backing up and it gets real ugly fast. I have to stop both instances and restart them Does my config look ok? any suggestions? Thanks Randy From log file Aug 25, 2005 3:22:36 PM org.apache.catalina.cluster.tcp.SimpleTcpCluster memberDisappeared INFO: Received member disappeared:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.0.20 4:4001,192.168.0.204,4001, a live=47087979] Aug 25, 2005 3:22:37 PM org.apache.catalina.cluster.tcp.SimpleTcpCluster memberAdded INFO: Replication member added:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.0.204:4001 ,192.168.0.204,4001, aliv e=47092679] Aug 25, 2005 3:22:51 PM org.apache.catalina.cluster.tcp.SocketSender waitForAck WARNING: Wasn't able to read acknowledgement from server[/192.168.0.204:4001] in 15000 ms. Disconnecting socket, and trying ag ain. Aug 25, 2005 3:22:51 PM org.apache.catalina.cluster.tcp.ReplicationTransmitter sendMessageData WARNING: Unable to send replicated message, is server down? java.net.SocketTimeoutException: Read timed out at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at java.net.SocketInputStream.read(SocketInputStream.java:182) at org.apache.catalina.cluster.tcp.SocketSender.waitForAck(SocketSender.java:13 4) at org.apache.catalina.cluster.tcp.SocketSender.sendMessage(SocketSender.java:1 25) at org.apache.catalina.cluster.tcp.PooledSocketSender.sendMessage(PooledSocketS ender.java:119) at org.apache.catalina.cluster.tcp.ReplicationTransmitter.sendMessageData(Repli cationTransmitter.java:117) at org.apache.catalina.cluster.tcp.ReplicationTransmitter.sendMessage(Replicati onTransmitter.java:149) at org.apache.catalina.cluster.tcp.SimpleTcpCluster.send(SimpleTcpCluster.java: 409) at org.apache.catalina.cluster.tcp.SimpleTcpCluster.send(SimpleTcpCluster.java: 417) at org.apache.catalina.cluster.tcp.ReplicationValve.invoke(ReplicationValve.jav a:202) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex t.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java :109) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex t.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:296) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:372) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:694) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:626) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:807) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav a:644) at java.lang.Thread.run(Thread.java:534) Aug 25, 2005 3:22:51 PM org.apache.catalina.cluster.tcp.SocketSender waitForAck WARNING: Wasn't able to read acknowledgement from server[/192.168.0.204:4001] in 15000 ms. Disconnecting socket, and trying ag ain. Aug 25, 2005 3:22:51 PM org.apache.catalina.cluster.tcp.SocketSender waitForAck WARNING: Wasn't able to read acknowledgement from server[/192.168.0.204:4001] in 15000 ms. Disconnecting
Clustering problems
Hello I have two tomcat servers (flanders and krusty) Their server.xmls are below they have two nic cards. The incoming http requests come in via the 192.168 ips and go out the real ips 66.208 the 192.168 nics are on a gigbit network When my servers get really busy i messages in the log file (see below) Once this happens my httpd starts backing up and it gets real ugly fast. I have to stop both instances and restart them Does my config look ok? any suggestions? Thanks Randy From log file Aug 25, 2005 3:22:36 PM org.apache.catalina.cluster.tcp.SimpleTcpCluster memberDisappeared INFO: Received member disappeared:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.0.20 4:4001,192.168.0.204,4001, a live=47087979] Aug 25, 2005 3:22:37 PM org.apache.catalina.cluster.tcp.SimpleTcpCluster memberAdded INFO: Replication member added:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.0.204:4001 ,192.168.0.204,4001, aliv e=47092679] Aug 25, 2005 3:22:51 PM org.apache.catalina.cluster.tcp.SocketSender waitForAck WARNING: Wasn't able to read acknowledgement from server[/192.168.0.204:4001] in 15000 ms. Disconnecting socket, and trying ag ain. Aug 25, 2005 3:22:51 PM org.apache.catalina.cluster.tcp.ReplicationTransmitter sendMessageData WARNING: Unable to send replicated message, is server down? java.net.SocketTimeoutException: Read timed out at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at java.net.SocketInputStream.read(SocketInputStream.java:182) at org.apache.catalina.cluster.tcp.SocketSender.waitForAck(SocketSender.java:13 4) at org.apache.catalina.cluster.tcp.SocketSender.sendMessage(SocketSender.java:1 25) at org.apache.catalina.cluster.tcp.PooledSocketSender.sendMessage(PooledSocketS ender.java:119) at org.apache.catalina.cluster.tcp.ReplicationTransmitter.sendMessageData(Repli cationTransmitter.java:117) at org.apache.catalina.cluster.tcp.ReplicationTransmitter.sendMessage(Replicati onTransmitter.java:149) at org.apache.catalina.cluster.tcp.SimpleTcpCluster.send(SimpleTcpCluster.java: 409) at org.apache.catalina.cluster.tcp.SimpleTcpCluster.send(SimpleTcpCluster.java: 417) at org.apache.catalina.cluster.tcp.ReplicationValve.invoke(ReplicationValve.jav a:202) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex t.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java :109) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex t.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:296) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:372) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:694) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:626) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:807) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav a:644) at java.lang.Thread.run(Thread.java:534) Aug 25, 2005 3:22:51 PM org.apache.catalina.cluster.tcp.SocketSender waitForAck WARNING: Wasn't able to read acknowledgement from server[/192.168.0.204:4001] in 15000 ms. Disconnecting socket, and trying ag ain. Aug 25, 2005 3:22:51 PM org.apache.catalina.cluster.tcp.SocketSender waitForAck WARNING: Wasn't able to read acknowledgement from server[/192.168.0.204:4001] in 15000 ms. Disconnecting socket, and trying ag ain. Flanders - 192.168.0.203 Cluster className=org.apache.catalina.cluster.tcp.SimpleTcpCluster managerClassName=org.apache.catalina.cluster.session.DeltaManager expireSessionsOnShutdown=false useDirtyFlag=true Membership className=org.apache.catalina.cluster.mcast.McastService mcastAddr=228.0.0.9 mcastPort=45564 mcastFrequency=500 mcastDropTime=3000/ Receiver className=org.apache.catalina.cluster.tcp.ReplicationListener tcpListenAddress=192.168.0.203 tcpListenPort=4001 tcpSelectorTimeout=100 tcpThreadCount=6/
Clustering and controlling session manager
Hi, We're using tomcat with clustering enabled for session replication purposes. This is all well and good and works fine. However, in addition I wanted to set the sessionId length to something shorter than the default. If it wasn't for the clustering I would simply provide a context.xml file in the webapp with a suitable Manager node, eg: Context Manager sessionIdLength=6/ /Context and all would be fine. The trouble is that by doing this the session manager that would normally be created by the Cluster configuration is overridden by this Manager definition. Unless I'm missing something (and I've had a glance through the source code as well), I can't see any way of controlling any of the session manager attributes when the session manager is created using a Cluster definition. Since all you appear to be able to do is specify the manager class name and let it use whatever defaults are in play for that manager. Am I missing something? Regards, Mark This email has been scanned for all known viruses by the MessageLabs SkyScan service. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Apache mod_rewrite + Tomcat clustering/ load balancing.
Hi,
I hv clustered 2 Tomcat (version 5.0.18) instances on 2 physically
different machines A and B.
Individually accessible as
http://machineA:8080 http://machinea:8080/ and
http://machineB:8080 http://machineb:8080/
I have Apache 2.0.54 installed on machine A and following the tomcat doc
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/balancer-howto.html
I am trying to use Apache mod_rewrite to load balance/
failover between my 2 tomcat instances.
As per the doc modified the engine element in server.xml
to include the jvmRoute attribute
Configuring Apache was a headache.
The documentation assumes the reader is an expert with Apache.
It is not completely accurate. The reader cannot use it as is.
For instance it talks of creating balancer.conf but uses servers.conf in
http.
Anyways I discovered it and created a balancing.conf for
mod_rewrite as explained.
Edited apache's httpd.conf as given in the tomcat doc.
And with both tomcat instances working browsed
to
http://localhost/servlets-examples/servlet/RequestInfoExample
But it did not work. Error log gave:
File does not exist:
proxy:http://machineA:8080/servlets-examples/servlet/RequestInfoExample
But I could get the expected page when I replaced [P, L]
in the RewriteRule for Location /servlets-examples with only [L]
The funny thing however is I browse to
http://localhost/servlets-examples/servlet/RequestInfoExample
but that later automatically changes to either
http://machineA:8080/servlets-examples/servlet/RequestInfoExample or
http://machineB:8080/servlets-examples/servlet/RequestInfoExample
depending upon which Tomcat instance served my request.
Any clues as to why the URL in the browser changes?
PS: My entries in httpd.conf
RewriteMap SERVERS rnd:path to the balancer.conf
created above
Location /servlets-examples
RewriteEngine On
RewriteCond %{HTTP_COOKIE}
(^|;\s*)jsessionid=\w*\.(\w+)($|;)
RewriteRule (.*)
http://${SERVERS:%2}%{REQUEST_URI}; [P,L]
RewriteRule ^.*;jsessionid=\w*\.(\w+)($|;)
http://${SERVERS:$1}%{REQUEST_URI}; [P,L]
RewriteRule (.*)
http://${SERVERS:ALL}%{REQUEST_URI}; [P,L]
/Location
I had to replace [P,L] with [L] to make it work
rgds,
G1
This e-mail and any files transmitted with it are for the sole use of the
intended recipient(s) and may contain confidential and privileged information.
If you are not the intended recipient, please contact the sender by reply
e-mail and destroy all copies of the original message.
Any unauthorised review, use, disclosure, dissemination, forwarding, printing
or copying of this email or any action taken in reliance on this e-mail is
strictly
prohibited and may be unlawful.
Visit us at http://www.cognizant.com
Tomcat clustering load balancing
Hi, I am experimenting with Tomcat clustering I easily implemented a tomcat cluster un-commenting the cluster element in server.xml I now have 2 tomcat instances (on 2 physically different boxes) machineA and machineB I noted they can keep track of each other and get notified the other is down - for e.g. when I pull out the network cord. With clustering enabled I expect my request sent to say machineA (http://machineA:8080 http://machinea:8080/ ) to be served by the other tomcat instance. But this does not happen. 1. Am I missing something? Load balancing? 2. But how to configure load balancing? In non-clustered environment I would browse to http://machineA:8080 http://machinea:8080/ or http://machineB:8080 http://machineb:8080/ (The machine name is specified in the url EXPLICITLY.) With load balancing app should I browse to some other URL? 3. How and who will route the request? 4. Do I need to run my own specialized version of the load balancing app on a third tomcat instance? 5. What if the third tomcat instance on which the load balancing app is running comes down? rgds, G1 This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful. Visit us at http://www.cognizant.com
Re: Tomcat clustering load balancing
Hi Jeevan, 1. Am I missing something? Load balancing? Lot of ways to do load balancing : a. U can use balancer apps, it's bundled on tomcat sample b. U can use apache with mod_jk So, yes, you browse to some other URL. For example, if U run the balancer apps from tomcat, U should be redirected to some URL. Clustering and load balancing is two separated different things. A request, usually goes into the load balancer first, and after that, the load balancer redirect it to the real tomcat, it can be within the same machine but different port, or it can be to another machine. The Real tomcat, it can be clustered, or stand alone. If it's clustered, then those tomcat's are sharing their sesion state, means that if your request is handled by tomcatA and then suddenly tomcatA is dead, then the load balancer will redirect your request to tomcatB, tomcatB knows, what has been done with your request by tomcatA, and will continue to process your request. 2. But how to configure load balancing? Google ? :D I have written my documentation with load balancing and clustering,but in Indonesian language, hehehe :D sorry On 8/3/05, Sunkersett, Jeevan (Cognizant) [EMAIL PROTECTED] wrote: Hi, I am experimenting with Tomcat clustering I easily implemented a tomcat cluster un-commenting the cluster element in server.xml I now have 2 tomcat instances (on 2 physically different boxes) machineA and machineB I noted they can keep track of each other and get notified the other is down - for e.g. when I pull out the network cord. With clustering enabled I expect my request sent to say machineA (http://machineA:8080 http://machinea:8080/ ) to be served by the other tomcat instance. But this does not happen. 1. Am I missing something? Load balancing? 2. But how to configure load balancing? In non-clustered environment I would browse to http://machineA:8080 http://machinea:8080/ or http://machineB:8080 http://machineb:8080/ (The machine name is specified in the url EXPLICITLY.) With load balancing app should I browse to some other URL? 3. How and who will route the request? 4. Do I need to run my own specialized version of the load balancing app on a third tomcat instance? 5. What if the third tomcat instance on which the load balancing app is running comes down? rgds, G1 This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful. Visit us at http://www.cognizant.com -- --- http://www.psychotazkia.or.id
Using Tomcat 5.5 clustering, container managed security info does not propagate to other instances
hi all, we are having a problem with our Tomcat 5.5.9 cluster. We run 2 Tomcat instances on physically different machines. For security we use normal container managed security, configured in the web.xml. Session replication works fine, and session id's are same across the two instances. We only have trouble with the authentication. For instance, if you are logged in on instance1, if load balancer redirects subsequent request to instance2, you have to login again. Turning on Single Signon did not help. Does anybody know if we should be able to get this working, and how? Browsing through the Tomcat source code I noticed that very explicit the security Principal is not saved in a serialized session. Could this be the reason why login information is not propagated to other instances? Has anybody an idea why this is not done? Configuration: - OS: RH 4 - App server: Tomcat 5.5.9 - Session replication: in-memory, pooled - Load balancing via hardware load balancer (Cisco) tia, Dirk - Lost Boys creates and delivers internet mobile solutions - Dirk de Kok | Java Specialist Lost Boys B.V. | Joop Geesinkweg 209 | 1096 AV Amsterdam The Netherlands | Tel: +31 20 4604500 | Fax: +31 20 4604501 | [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | www.lostboys.nl http://www.lostboys.nl/
DeltaManager for Clustering
Is there documentation on using the DeltaManager for clustering? In the javadoc there is this statement: --CUT-- Correct behavior of session storing and reloading depends upon external calls to the start() and stop() methods of this class at the correct times. --END-- The tomcat clustering howto doesn't mention this though. Are the start/stop calls referred to for the container, or does the user application have to do something? I have some objects in the session that are not being syncronized accross the cluster and am trying to figure out if I'm doing something wrong either in the config or in the code. Thanks Dennis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DeltaManager for Clustering
Hi Dennis, assuming you have a valid cluster config you don't need to start/stop the DeltaManager yourself. Session attributes are only replicated, if they are serializable and the changes to the attributes are applied via setAttribute. If your attribute e.g. is a HashMap and you change an entry via getAttribute and then access by a key, the cluster will not know about the change and not replicate the new data. On the other hand this way you can obscure changes you don't really need from the replication and save some replication load. Is replication working in general in your setup? Is there documentation on using the DeltaManager for clustering? In the javadoc there is this statement: --CUT-- Correct behavior of session storing and reloading depends upon external calls to the start() and stop() methods of this class at the correct times. --END-- The tomcat clustering howto doesn't mention this though. Are the start/stop calls referred to for the container, or does the user application have to do something? I have some objects in the session that are not being syncronized accross the cluster and am trying to figure out if I'm doing something wrong either in the config or in the code. Thanks Dennis - 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: DeltaManager for Clustering
Rainer Jung wrote: Hi Dennis, assuming you have a valid cluster config you don't need to start/stop the DeltaManager yourself. Good, that's what I thought. Session attributes are only replicated, if they are serializable and the changes to the attributes are applied via setAttribute. If your attribute e.g. is a HashMap and you change an entry via getAttribute and then access by a key, the cluster will not know about the change and not replicate the new data. On the other hand this way you can obscure changes you don't really need from the replication and save some replication load. See, the thing is, we have a 3rd party library that saves information in the session. It doesn't call setAttribute every time it changes the data. DeltaManager appears to ignore the useDirtyFlag. With SimpleTcpReplicationManager, I can set useDirtyFlag to false and we get the desired behavior. With DeltaManager, the sessions get out of sync. So for the time being, I switched the managerClass back to SimpleTcpReplicationManager and things work the way they are supposed to. The issue is whether or not DeltaManager is supposed to use a useDirtyFlag or not I guess. The config option is still there in the sample cluster config that comes with server.xml as well as in the online-documentation. It has no effect though. Is replication working in general in your setup? Yes Thanks for your reply. Dennis Is there documentation on using the DeltaManager for clustering? In the javadoc there is this statement: --CUT-- Correct behavior of session storing and reloading depends upon external calls to the start() and stop() methods of this class at the correct times. --END-- The tomcat clustering howto doesn't mention this though. Are the start/stop calls referred to for the container, or does the user application have to do something? I have some objects in the session that are not being syncronized accross the cluster and am trying to figure out if I'm doing something wrong either in the config or in the code. Thanks Dennis - 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: DeltaManager for Clustering
See, the thing is, we have a 3rd party library that saves information in the session. It doesn't call setAttribute every time it changes the data. DeltaManager appears to ignore the useDirtyFlag. With SimpleTcpReplicationManager, I can set useDirtyFlag to false and we get the desired behavior. With DeltaManager, the sessions get out of sync. So for the time being, I switched the managerClass back to SimpleTcpReplicationManager and things work the way they are supposed to. The issue is whether or not DeltaManager is supposed to use a useDirtyFlag or not I guess. The config option is still there in the sample cluster config that comes with server.xml as well as in the online-documentation. It has no effect though. No, DeltaManager doesn't use that flag. It would somehow not make sense, because the whole pupose of DeltaManager is to only replicate changed attributes of a session and the flag tries to replicate every session accessed. So if you would impement it with DeltaManager it would behave the same way as the SimpleTcpReplicationManager already does. Under high load that will be a problem. If that is relevant yu must do a stress test and observe CPU/bandwidth/latency. Maybe a crude workaround: at the end of the requst do a getAttribute/setAttribute to the attributes you want to replicate. I think DeltaManager does not really check for a change, it replicates all attributes accessed via setAttribute. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DeltaManager for Clustering
Rainer Jung wrote: No, DeltaManager doesn't use that flag. It would somehow not make sense, because the whole pupose of DeltaManager is to only replicate changed attributes of a session and the flag tries to replicate every session accessed. So if you would impement it with DeltaManager it would behave the same way as the SimpleTcpReplicationManager already does. Wouldn't there usually be only one session accessed per request? At least in my application, when a request is processed, I don't have any code to access another user's sessions besides the one that made the request. So while this may be more overhead than only replicating a session if something has changed, and again more overhead than only replicating the changed attributes (DeltaManager), at least it solves my problem of the 3rd party library that doesn't call setAttribute. Under high load that will be a problem. If that is relevant yu must do a stress test and observe CPU/bandwidth/latency. I do agree that it would be important to watch bandwidth/latency to make sure SimpleTcpReplicationManager can handle our load. Maybe a crude workaround: at the end of the requst do a getAttribute/setAttribute to the attributes you want to replicate. I think DeltaManager does not really check for a change, it replicates all attributes accessed via setAttribute. - 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 and the useDirtyFlag
Dennis wrote: I've been working with a cluster of tomcat servers and wanted to change the useDirtyFlag to false so that the session is replicated after every request whether or not it was changed. Here is my modified server.xml fragment: ---CUT--- Cluster className=org.apache.catalina.cluster.tcp.SimpleTcpCluster managerClassName=org.apache.catalina.cluster.session.DeltaManager expireSessionsOnShutdown=false useDirtyFlag=false ---END CUT--- To answer my own problem.. DeltaManager ignores the useDirtyFlag. I changed it to SimpleTcpReplicationManager and got the desired effect. Possibly DeltaManager has a bug because the session, although changed, was not replicated. After restarting the servers in the cluster, I noticed that the behavior was the same as with the flag set to true. Objects in the session quickly become out of sync across the multiple servers because they are getting modifed but setAttribute is not being called. I searched around google and the mail archive a bit but didn't find any references to people having trouble with this. Before I started digging in the clustering code, I thought I'd see if anyone has any idea as to whether or not I have the correct expectation of the useDirtyFlag or if there might be some other problem. I'm using Tomcat 5.5.9. Thanks Dennis - 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]
Clustering and the useDirtyFlag
I've been working with a cluster of tomcat servers and wanted to change the useDirtyFlag to false so that the session is replicated after every request whether or not it was changed. Here is my modified server.xml fragment: ---CUT--- Cluster className=org.apache.catalina.cluster.tcp.SimpleTcpCluster managerClassName=org.apache.catalina.cluster.session.DeltaManager expireSessionsOnShutdown=false useDirtyFlag=false ---END CUT--- After restarting the servers in the cluster, I noticed that the behavior was the same as with the flag set to true. Objects in the session quickly become out of sync across the multiple servers because they are getting modifed but setAttribute is not being called. I searched around google and the mail archive a bit but didn't find any references to people having trouble with this. Before I started digging in the clustering code, I thought I'd see if anyone has any idea as to whether or not I have the correct expectation of the useDirtyFlag or if there might be some other problem. I'm using Tomcat 5.5.9. Thanks Dennis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Clustering: Slow session creation
I have been having a problem with clustered sessions in Tomcat 5.5.7. I am using the pooled replication mode, but I have also tried asynchronous mode. Right now there is one machine, the other machine is down. I would have assumed that machine one would have seen that machine two is down and not bothered to try to replicate the session, but it appears as if it is trying to communicate anyway... org.apache.catalina.connector.RequestFacade.getSession(boolean) org.apache.catalina.connector.Request.getSession(boolean) org.apache.catalina.connector.Request.doGetSession(boolean) org.apache.catalina.cluster.session.DeltaManager.createSession() org.apache.catalina.cluster.session.DeltaManager.createSession(boolean) org.apache.catalina.cluster.session.DeltaManager.getNewDeltaSession() org.apache.catalina.cluster.tcp.SimpleTcpCluster.send(ClusterMessage) org.apache.catalina.cluster.tcp.SimpleTcpCluster.send(ClusterMessage, Member) java.io.ObjectOutputStream.writeObject(Object) org.apache.catalina.cluster.tcp.ReplicationTransmitter.sendMessage(Strin g, byte[]) org.apache.catalina.cluster.io.XByteBuffer.createDataPackage(byte[]) org.apache.catalina.cluster.tcp.ReplicationTransmitter.sendMessageData(S tring, byte[], IDataSender) org.apache.catalina.cluster.tcp.PooledSocketSender.sendMessage(String, byte[]) org.apache.catalina.cluster.tcp.SocketSender.sendMessage(String, byte[]) org.apache.catalina.cluster.tcp.SocketSender.connect() java.net.Socket.init(InetAddress, int) ...it looks like the ReplicationTransmitter is trying to send a message, which hangs until the socket times out. Where can I set the timeout for this? 20 seconds seems long, 2 seconds would probably be more appropriate. I enabled DEBUG messages for the cluster component, but this is all I get in the logs... [2005-06-21 13:53:38,281 DEBUG] [org.apache.catalina.cluster.session.DeltaManager] Manager (/xyz) send new session (6359D20C5E68DE71BB557443724A0218) [2005-06-21 13:53:59,406 DEBUG] [org.apache.catalina.cluster.session.DeltaManager] Created a DeltaSession with Id[6359D20C5E68DE71BB557443724A0218] Total count=1 ...no other information about why an attempt is made to create the socket and why it takes so long to timeout. I've sort of solved the problem by disabling clustering, but I would like to get it working at some point. Any ideas? Thanks, Bernard Durfee - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: clustering questions
Hey Mark, Mark Eggers schrieb: 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? Currently clustering work only inside host element. Per catalina design we can also have a cluster inside an engine or context. I hope in future we can add the cluster also inside the engine. It look like a server.xml option and small changes inside code! For backup a virtual hosting szenario this feature was useful. I add this topic to the cluster todo list. I also start to wrote a better cluster documentation for 5.5.10 (look inside cvs head) and help are very welcome :-) 2. There is a statement concerning number of threads would be optimal if it matched the number of nodes. This statement means the number of cluster backup 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? Today, this is true, but in my real life, I have only one or two heavy application services per tomcat instance that works inside a cluster. Let us know your use case? 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]
clustering questions
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]
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]
Lb_factor problem for clustering
Can any body explain me how this lb_factor works in worker2.properties file What is the highest value we can assign to it... Actually my problem is I am using tomcat 5.5.7 with apache 2.0.48 There are 2 tomcat instances. I want some way in which all the request should land up to one tomcat node only not the other one unless first one is down. Thanks Gaurav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Lb_factor problem for clustering
Hello Look at http://jakarta.apache.org/tomcat/connectors-doc/howto/workers.html Hope this will help you Jean-Claude -Message d'origine- De : Gaurav Bansal [mailto:[EMAIL PROTECTED] Envoyé : jeudi 2 juin 2005 13:33 À : tomcat-user@jakarta.apache.org Objet : Lb_factor problem for clustering Can any body explain me how this lb_factor works in worker2.properties file What is the highest value we can assign to it... Actually my problem is I am using tomcat 5.5.7 with apache 2.0.48 There are 2 tomcat instances. I want some way in which all the request should land up to one tomcat node only not the other one unless first one is down. Thanks Gaurav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Clustering without farmwardeployer
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]
how to determine clustering problem?
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]
RE: Clustering Tomcat
It looks like your machine is unable to send a multicast message. It will be an operating system configuration. Ta Matt -Original Message- From: Ben [mailto:[EMAIL PROTECTED] Sent: 21 May 2005 02:11 To: Tomcat Subject: Clustering Tomcat Hi I'm trying to configure clustering of 2 Tomcat servers on a single CentOS 4 machine. When I start the first Tomcat, I get error messages like this in the catalina.out log file: org.apache.catalina.cluster.mcast.McastServiceImpl$SenderThread run WARNING: Unable to send mcast message. java.net.SocketException: Operation not permitted at jrockit.net.SocketNativeIO.send(Ljava.io.FileDescriptor;[BIILjava.net.InetAddress;II)I(Unknown Source) at java.net.PlainDatagramSocketImpl.send(Ljava.net.DatagramPacket;[BI)V(Unknown Source) at java.net.PlainDatagramSocketImpl.send(Ljava.net.DatagramPacket;)V(Unknown Source) at java.net.DatagramSocket.send(DatagramSocket.java:612) at org.apache.catalina.cluster.mcast.McastServiceImpl.send(McastServiceImpl.java:228) at org.apache.catalina.cluster.mcast.McastServiceImpl$SenderThread.run(McastServiceImpl.java:264) I am using JRockit 5.0_02 and Tomcat 5.5.9. Where can I find more information about this error? Thanks, Ben - 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 Tomcat
It was my firewall. The servers are working now, however I get these error messages when I stop and start one of the two Tomcat instances: May 21, 2005 5:09:20 PM org.apache.catalina.cluster.tcp.SimpleTcpCluster send SEVERE: Unable to send message through cluster sender. java.io.IOException: Sender not available. Make sure sender information is available to the ReplicationTransmitter. at org.apache.catalina.cluster.tcp.ReplicationTransmitter.sendMessageData(ReplicationTransmitter.java:641) at org.apache.catalina.cluster.tcp.ReplicationTransmitter.sendMessage(ReplicationTransmitter.java:331) at org.apache.catalina.cluster.tcp.SimpleTcpCluster.send(SimpleTcpCluster.java:463) at org.apache.catalina.cluster.session.DeltaManager.messageReceived(DeltaManager.java:860) at org.apache.catalina.cluster.session.DeltaManager.messageDataReceived(DeltaManager.java:724) at org.apache.catalina.cluster.tcp.SimpleTcpCluster.messageDataReceived(SimpleTcpCluster.java:658) at org.apache.catalina.cluster.io.ObjectReader.execute(ObjectReader.java:103) at org.apache.catalina.cluster.tcp.TcpReplicationThread.drainChannel(TcpReplicationThread.java:129) at org.apache.catalina.cluster.tcp.TcpReplicationThread.run(TcpReplicationThread.java:67) May 21, 2005 5:09:24 PM org.apache.catalina.cluster.tcp.DataSender init Thanks Ben On 5/22/05, Dale, Matt [EMAIL PROTECTED] wrote: It looks like your machine is unable to send a multicast message. It will be an operating system configuration. Ta Matt -Original Message- From: Ben [mailto:[EMAIL PROTECTED] Sent: 21 May 2005 02:11 To: Tomcat Subject: Clustering Tomcat Hi I'm trying to configure clustering of 2 Tomcat servers on a single CentOS 4 machine. When I start the first Tomcat, I get error messages like this in the catalina.out log file: org.apache.catalina.cluster.mcast.McastServiceImpl$SenderThread run WARNING: Unable to send mcast message. java.net.SocketException: Operation not permitted at jrockit.net.SocketNativeIO.send(Ljava.io.FileDescriptor;[BIILjava.net.InetAddress;II)I(Unknown Source) at java.net.PlainDatagramSocketImpl.send(Ljava.net.DatagramPacket;[BI)V(Unknown Source) at java.net.PlainDatagramSocketImpl.send(Ljava.net.DatagramPacket;)V(Unknown Source) at java.net.DatagramSocket.send(DatagramSocket.java:612) at org.apache.catalina.cluster.mcast.McastServiceImpl.send(McastServiceImpl.java:228) at org.apache.catalina.cluster.mcast.McastServiceImpl$SenderThread.run(McastServiceImpl.java:264) I am using JRockit 5.0_02 and Tomcat 5.5.9. Where can I find more information about this error? Thanks, Ben - 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]
Clustering Tomcat
Hi I'm trying to configure clustering of 2 Tomcat servers on a single CentOS 4 machine. When I start the first Tomcat, I get error messages like this in the catalina.out log file: org.apache.catalina.cluster.mcast.McastServiceImpl$SenderThread run WARNING: Unable to send mcast message. java.net.SocketException: Operation not permitted at jrockit.net.SocketNativeIO.send(Ljava.io.FileDescriptor;[BIILjava.net.InetAddress;II)I(Unknown Source) at java.net.PlainDatagramSocketImpl.send(Ljava.net.DatagramPacket;[BI)V(Unknown Source) at java.net.PlainDatagramSocketImpl.send(Ljava.net.DatagramPacket;)V(Unknown Source) at java.net.DatagramSocket.send(DatagramSocket.java:612) at org.apache.catalina.cluster.mcast.McastServiceImpl.send(McastServiceImpl.java:228) at org.apache.catalina.cluster.mcast.McastServiceImpl$SenderThread.run(McastServiceImpl.java:264) I am using JRockit 5.0_02 and Tomcat 5.5.9. Where can I find more information about this error? Thanks, Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
In-memory session replication without Clustering
Hi, a.What is the best way to share a HttpSession between web applications running on a single Tomcat instance ? That Tomcat instance is not a cluster node and clustering has not been enabled. b. What is the best way to share other java Object information (without using common persistence storage ) in memory between web applications? Are the add-on cache modules like JBoss cache etc. only solution? Regards.
Re: In-memory session replication without Clustering
From: Atanu Neogi [EMAIL PROTECTED] Sent: Friday, May 13, 2005 10:38 AM Hi, a.What is the best way to share a HttpSession between web applications running on a single Tomcat instance ? That Tomcat instance is not a cluster node and clustering has not been enabled. b. What is the best way to share other java Object information (without using common persistence storage ) in memory between web applications? Are the add-on cache modules like JBoss cache etc. only solution? The problem is that the webapps have their own distinct classloader hierarchies, so that's one thing that makes sharing objects across webapps difficult. Recall that an objects Class is based not just on the actual Class it uses, but the Classloader for the class as well. Thus if you have the an object of ClassX that's loaded by the classloader for WebappA, and another object of ClassX loaded by WebappB, and in WebappA you try: ClassX myObject = (ClassX)getObjectFromWebappB(); That will fail with a class cast exception, because WebappA.ClassX != WebappB.ClassX. Using a clustering style caching solution helps remedy this by serializing the objects, which breaks a lot of those dependencies, but is obviously expensive. One thing you can do, however, is move any classes that you want to share across webapps out into the common/lib or common/classes directories. Those classes are all shared across webapps, so they can safely be used back and forth between them, since they share the Common classloader. As for sharing HttpSessions, I don't think you can do that directly, as each webapp will have their own unique session. You'll need to have some other means to identify the user outside of the sessionid (like, say, their login name if they authenticate, or an arbitrary domain level cookie that you create on the fly if it doesn't exist yet). Then you use that credential to access shared information stored in a Cache that's loaded from the Common classloader. Regards, Will Hartung ([EMAIL PROTECTED]) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: In-memory session replication without Clustering
Will, I am perfectly aware of everything you said. I have been working with Tomcat for last few years. I should have clarified that before. I can do lot of these things using clusters and in-memory session replications. I was looking for some plug-in modules for Tomcat (and not external solutions like JBoss cache and Tangosol) to quickly implement cache sharing between web applications in a single Tomcat instance. I have one of my own based on persistent storage but that is not really efficient. Thanks anyway. Regards. Will Hartung [EMAIL PROTECTED] 05/13/2005 02:27 PM Please respond to Tomcat Users List tomcat-user@jakarta.apache.org To Tomcat Users List tomcat-user@jakarta.apache.org cc Subject Re: In-memory session replication without Clustering From: Atanu Neogi [EMAIL PROTECTED] Sent: Friday, May 13, 2005 10:38 AM Hi, a.What is the best way to share a HttpSession between web applications running on a single Tomcat instance ? That Tomcat instance is not a cluster node and clustering has not been enabled. b. What is the best way to share other java Object information (without using common persistence storage ) in memory between web applications? Are the add-on cache modules like JBoss cache etc. only solution? The problem is that the webapps have their own distinct classloader hierarchies, so that's one thing that makes sharing objects across webapps difficult. Recall that an objects Class is based not just on the actual Class it uses, but the Classloader for the class as well. Thus if you have the an object of ClassX that's loaded by the classloader for WebappA, and another object of ClassX loaded by WebappB, and in WebappA you try: ClassX myObject = (ClassX)getObjectFromWebappB(); That will fail with a class cast exception, because WebappA.ClassX != WebappB.ClassX. Using a clustering style caching solution helps remedy this by serializing the objects, which breaks a lot of those dependencies, but is obviously expensive. One thing you can do, however, is move any classes that you want to share across webapps out into the common/lib or common/classes directories. Those classes are all shared across webapps, so they can safely be used back and forth between them, since they share the Common classloader. As for sharing HttpSessions, I don't think you can do that directly, as each webapp will have their own unique session. You'll need to have some other means to identify the user outside of the sessionid (like, say, their login name if they authenticate, or an arbitrary domain level cookie that you create on the fly if it doesn't exist yet). Then you use that credential to access shared information stored in a Cache that's loaded from the Common classloader. Regards, Will Hartung ([EMAIL PROTECTED]) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat Clustering - Replicated Sessions
According to the Tomcat (5.5.9) documentation after a sessions has reached a certian period of inactivity it expires. However my question is when is this expired session marked by the JVM for garbage collection. The reason I ask is that our application has an interesting problem. If we start up a single server (configured for a cluster) and have the application run memory looks good, CPU is good, response time is good. However when we start up the 2nd clustered instance after a day or two both servers start showing up with OutOfMemory errors. The only new item introduced is that we are now replicating sessions between the applications. We changed the replication mode to asynchronous after having performance problems using pooled. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Clustering - Replicated Sessions
Hey, you have install my cluster patch for 5.5.9? http://issues.apache.org/bugzilla/show_bug.cgi?id=34389 I used very heavy the new fastasyncqueue mode without memory problems Every minute the sessions controlled for timeout. Look with an JMX Console that the manager active session count is reduced. Every expire message are transfered to all backup nodes. Peter Laura Haverkamp schrieb: According to the Tomcat (5.5.9) documentation after a sessions has reached a certian period of inactivity it expires. However my question is when is this expired session marked by the JVM for garbage collection. The reason I ask is that our application has an interesting problem. If we start up a single server (configured for a cluster) and have the application run memory looks good, CPU is good, response time is good. However when we start up the 2nd clustered instance after a day or two both servers start showing up with OutOfMemory errors. The only new item introduced is that we are now replicating sessions between the applications. We changed the replication mode to asynchronous after having performance problems using pooled. Thanks. - 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]
Clustering troubles.
I'm setting up a 2-node Tomcat cluster with jk_mod doing the loadbalancing. The loadbalancing went without a hitch, or at least without hitches that maillist archives couldn't untie. But now I'd like to have in-memory session replication between the two tomcat nodes. I uncommented the cluster element in the server.xml file on each node, but clustering didn't magically happen as I hoped it would: no replication takes place. I'm using a page in the jsp-examples webapp that sets a simple attribute on the session -- session.setAttribute(hello, howdy); When starting up Tomcat on each node, I get these log entries: Apr 27, 2005 12:30:28 PM org.apache.catalina.cluster.session.DeltaManager start INFO: Starting clustering manager at /jsp-examples Apr 27, 2005 12:30:28 PM org.apache.catalina.cluster.session.DeltaManager start INFO: Manager [/jsp-examples]: skipping state transfer. No members active in cluster group. I get this on both nodes, even if I start one node, create a session, then start node 2. Multicast is enabled: at least, when I ping 224.0.0.1, I get responses from all my interfaces. Do I need to do something to join 228.0.0.4, or is that a programmatic thing? I've pasted my workers.properties below (minus comments), and the cluster element from my server.xml. I've tried adding a name attribute to the cluster element and to each of its child elements in turn, without effect. TIA! Rod # workers.properties - workers.java_home=/usr/java/jre1.5.0_02 ps=/ # #-- ADVANCED MODE #- # worker.list=realserver1, realserver2, realserver3, realserver4, loadbalancer, jkstatus worker.realserver1.port=8009 worker.realserver1.host=localhost worker.realserver1.type=ajp13 worker.realserver1.lbfactor=100 worker.realserver2.port=8010 worker.realserver2.host=localhost worker.realserver2.type=ajp13 worker.realserver2.lbfactor=100 worker.realserver3.port=8009 worker.realserver3.host=marmot worker.realserver3.type=ajp13 worker.realserver3.lbfactor=100 worker.realserver4.port=8010 worker.realserver4.host=marmot worker.realserver4.type=ajp13 worker.realserver4.lbfactor=100 worker.loadbalancer.type=lb worker.loadbalancer.balanced_workers=realserver1, realserver2, realserver3, realserver4 worker.jkstatus.type=status # end workers.properties !-- server.xml cluster element -- 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=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]
Re: Clustering troubles.
Forgot to mention: Java runtime is jre1.5.0_02 Rod Fitzsimmons Frey wrote: I'm setting up a 2-node Tomcat cluster with jk_mod doing the loadbalancing. The loadbalancing went without a hitch, or at least without hitches that maillist archives couldn't untie. But now I'd like to have in-memory session replication between the two tomcat nodes. I uncommented the cluster element in the server.xml file on each node, but clustering didn't magically happen as I hoped it would: no replication takes place. ... etc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
tomcat clustering
Hey all, Is there a way to get the cluster system to replicate ServletContext scope variables between cluster members? If not, is there a good guide to writing Multicast sockets somewhere? Thanks alot! -Josh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat clustering
With the next release I hope we support those handlings context attribute replication handling. We start a discussion at this list ( last three days). Topic: http://marc.theaimsgroup.com/?t=11141745513r=1w=2 Peter Joshua Szmajda schrieb: Hey all, Is there a way to get the cluster system to replicate ServletContext scope variables between cluster members? If not, is there a good guide to writing Multicast sockets somewhere? Thanks alot! -Josh - 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
Awesome! I think though since I need this functionality now, I might go with JGroups' DistributedHashtable system. It's basically what I need right out of the box. Thanks, and good luck! I'll be looking forward to that functionality. -Josh Peter Rossbach wrote: With the next release I hope we support those handlings context attribute replication handling. We start a discussion at this list ( last three days). Topic: http://marc.theaimsgroup.com/?t=11141745513r=1w=2 Peter Joshua Szmajda schrieb: Hey all, Is there a way to get the cluster system to replicate ServletContext scope variables between cluster members? If not, is there a good guide to writing Multicast sockets somewhere? Thanks alot! -Josh - 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: Clustering application scope replication
Hey, with the next tomcat 5.5.10 release you can add a ClusterListener and LifecycleListener to your cluster config to realize those ServletContext attributes replication things. Look at the current cvs head and test it. ClusterListener className=org.apache.catalina.cluster.session.ClusterSessionListener / ClusterListener className=your class / Listener className=your class / Your LifecycleListener receive the manager/context un/registration event. BEFORE_MANAGERREGISTER_EVENT AFTER_MANAGERREGISTER_EVENT BEFORE_MANAGERUNREGISTER_EVENT AFTER_MANAGERUNREGISTER_EVENT ClusterListener are receive the messages. (look at ClusterSessionListener or JvmRouteSessionIDBinderListener) You must define your own ClusterMessage implementation (SessionMessageImpl or SessionIDMessage) Your code contribution is very welcome :-) Peter Will Hartung schrieb: From: Joakim Ahlén [EMAIL PROTECTED] Sent: Friday, April 22, 2005 5:54 AM Hi! We have a cluster of two tomcat 5.5.9-machines using session replication. However, we also have data in application scope (set with getServletContext().setAttribute(...)) which as far as i have found in the docs, is not replicated. You need a cluster aware caching solution. Session replication is more for failover and such. Look at something like OSCache and its ilk to get the functionality that you need. Regards, Will Hartung ([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: Clustering application scope replication
I hope you have download and use my cluster patches for 5.5.9 http://issues.apache.org/bugzilla/show_bug.cgi?id=34389 when you implement the feature ServletContext attribute replication feature I support you. ( s. other mail) Peter Joakim Ahlén schrieb: Hi! We have a cluster of two tomcat 5.5.9-machines using session replication. However, we also have data in application scope (set with getServletContext().setAttribute(...)) which as far as i have found in the docs, is not replicated. Is there any way to accomplish this with tomcat? If not, is there any plan to develop support for it? Do other application servers have support for this? Hope you can help me. Regards Joakim - 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]
Clustering application scope replication
Hi! We have a cluster of two tomcat 5.5.9-machines using session replication. However, we also have data in application scope (set with getServletContext().setAttribute(...)) which as far as i have found in the docs, is not replicated. Is there any way to accomplish this with tomcat? If not, is there any plan to develop support for it? Do other application servers have support for this? Hope you can help me. Regards Joakim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clustering application scope replication
The servlet spec says this data is local to a given JVM. I suppose a servlet engine could expand beyond the spec, but I'd be surprised if Tomcat did here. Joakim Ahlén wrote: Hi! We have a cluster of two tomcat 5.5.9-machines using session replication. However, we also have data in application scope (set with getServletContext().setAttribute(...)) which as far as i have found in the docs, is not replicated. Is there any way to accomplish this with tomcat? If not, is there any plan to develop support for it? Do other application servers have support for this? Hope you can help me. Regards Joakim - 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 application scope replication
Ok, too bad. Is there any way of storing objects if we want them in cluster scope? An ugly hack would be to use one single HttpSession with a special session-id to store global objects, and somehow fetch objects from within this HttpSession from inside requests that belongs to other sessions. I can't see how this could be done though, since request.getSession() can't fetch other sessions than its own. This would probably also have to include some tomcat specific magic which i wouldn't want. Any help is appreciated on how to handle this problem! Thanks Joakim On Fri, Apr 22, 2005 at 08:07:21AM -0500, Jess Holle wrote: The servlet spec says this data is local to a given JVM. I suppose a servlet engine could expand beyond the spec, but I'd be surprised if Tomcat did here. Joakim Ahlén wrote: Hi! We have a cluster of two tomcat 5.5.9-machines using session replication. However, we also have data in application scope (set with getServletContext().setAttribute(...)) which as far as i have found in the docs, is not replicated. Is there any way to accomplish this with tomcat? If not, is there any plan to develop support for it? Do other application servers have support for this? Hope you can help me. Regards Joakim - 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: Clustering application scope replication
Hi For your needs, you can use session replication (http://jakarta.apache.org/tomcat/tomcat-5.5-doc/cluster-howto.html) or your own mechanisms and tables with datas in a database ... Regards. On Fri, 22 Apr 2005 15:15:54 +0200 Joakim Ahlén [EMAIL PROTECTED] wrote: Ok, too bad. Is there any way of storing objects if we want them in cluster scope? An ugly hack would be to use one single HttpSession with a special session-id to store global objects, and somehow fetch objects from within this HttpSession from inside requests that belongs to other sessions. I can't see how this could be done though, since request.getSession() can't fetch other sessions than its own. This would probably also have to include some tomcat specific magic which i wouldn't want. Any help is appreciated on how to handle this problem! Thanks Joakim On Fri, Apr 22, 2005 at 08:07:21AM -0500, Jess Holle wrote: The servlet spec says this data is local to a given JVM. I suppose a servlet engine could expand beyond the spec, but I'd be surprised if Tomcat did here. Joakim Ahlén wrote: Hi! We have a cluster of two tomcat 5.5.9-machines using session replication. However, we also have data in application scope (set with getServletContext().setAttribute(...)) which as far as i have found in the docs, is not replicated. Is there any way to accomplish this with tomcat? If not, is there any plan to develop support for it? Do other application servers have support for this? Hope you can help me. Regards Joakim - 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: Clustering application scope replication
How does Tomcat know what to serialize? Does it just use the Reflection package and serialize out -everything- that implements java.io.Serializable? -ryan -Original Message- From: Lionel Farbos [mailto:[EMAIL PROTECTED] Sent: Friday, April 22, 2005 9:11 AM To: Tomcat Users List Cc: [EMAIL PROTECTED] Subject: Re: Clustering application scope replication Hi For your needs, you can use session replication (http://jakarta.apache.org/tomcat/tomcat-5.5-doc/cluster-howto.html) or your own mechanisms and tables with datas in a database ... Regards. On Fri, 22 Apr 2005 15:15:54 +0200 Joakim Ahlén [EMAIL PROTECTED] wrote: Ok, too bad. Is there any way of storing objects if we want them in cluster scope? An ugly hack would be to use one single HttpSession with a special session-id to store global objects, and somehow fetch objects from within this HttpSession from inside requests that belongs to other sessions. I can't see how this could be done though, since request.getSession() can't fetch other sessions than its own. This would probably also have to include some tomcat specific magic which i wouldn't want. Any help is appreciated on how to handle this problem! Thanks Joakim On Fri, Apr 22, 2005 at 08:07:21AM -0500, Jess Holle wrote: The servlet spec says this data is local to a given JVM. I suppose a servlet engine could expand beyond the spec, but I'd be surprised if Tomcat did here. Joakim Ahlén wrote: Hi! We have a cluster of two tomcat 5.5.9-machines using session replication. However, we also have data in application scope (set with getServletContext().setAttribute(...)) which as far as i have found in the docs, is not replicated. Is there any way to accomplish this with tomcat? If not, is there any plan to develop support for it? Do other application servers have support for this? Hope you can help me. Regards Joakim - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clustering application scope replication
From: Joakim Ahlén [EMAIL PROTECTED] Sent: Friday, April 22, 2005 5:54 AM Hi! We have a cluster of two tomcat 5.5.9-machines using session replication. However, we also have data in application scope (set with getServletContext().setAttribute(...)) which as far as i have found in the docs, is not replicated. You need a cluster aware caching solution. Session replication is more for failover and such. Look at something like OSCache and its ilk to get the functionality that you need. Regards, Will Hartung ([EMAIL PROTECTED]) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clustering application scope replication
From: J. Ryan Earl [EMAIL PROTECTED] Sent: Friday, April 22, 2005 7:44 AM How does Tomcat know what to serialize? Does it just use the Reflection package and serialize out -everything- that implements java.io.Serializable? When you do a setAttribute(key, object), it serializes the object out for replication, so, both your key and object needs to be serializable. It uses the generic Java writeObject method. This is why you need to use setAttribute to ensure your changes are replicated, and why you can not just change an object directly and expect it to be replicated. So, if you are storing, say, a long ArrayList of objects in your session (like, say, query results), you must use setAttribute(yourList) each time you make a change to anything in the list, and then it serializes the ENTIRE list for replication, not just your changes. (And thus we see some of the limits of replication, at least some of the things you need to be aware of.) Regards, Will Hartung ([EMAIL PROTECTED]) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clustering application scope replication
As it is explained in the doc : All your session attributes must implement java.io.Serializable On Fri, 22 Apr 2005 09:44:01 -0500 J. Ryan Earl [EMAIL PROTECTED] wrote: How does Tomcat know what to serialize? Does it just use the Reflection package and serialize out -everything- that implements java.io.Serializable? -ryan -Original Message- From: Lionel Farbos [mailto:[EMAIL PROTECTED] Sent: Friday, April 22, 2005 9:11 AM To: Tomcat Users List Cc: [EMAIL PROTECTED] Subject: Re: Clustering application scope replication Hi For your needs, you can use session replication (http://jakarta.apache.org/tomcat/tomcat-5.5-doc/cluster-howto.html) or your own mechanisms and tables with datas in a database ... Regards. On Fri, 22 Apr 2005 15:15:54 +0200 Joakim Ahlén [EMAIL PROTECTED] wrote: Ok, too bad. Is there any way of storing objects if we want them in cluster scope? An ugly hack would be to use one single HttpSession with a special session-id to store global objects, and somehow fetch objects from within this HttpSession from inside requests that belongs to other sessions. I can't see how this could be done though, since request.getSession() can't fetch other sessions than its own. This would probably also have to include some tomcat specific magic which i wouldn't want. Any help is appreciated on how to handle this problem! Thanks Joakim On Fri, Apr 22, 2005 at 08:07:21AM -0500, Jess Holle wrote: The servlet spec says this data is local to a given JVM. I suppose a servlet engine could expand beyond the spec, but I'd be surprised if Tomcat did here. Joakim Ahlén wrote: Hi! We have a cluster of two tomcat 5.5.9-machines using session replication. However, we also have data in application scope (set with getServletContext().setAttribute(...)) which as far as i have found in the docs, is not replicated. Is there any way to accomplish this with tomcat? If not, is there any plan to develop support for it? Do other application servers have support for this? Hope you can help me. Regards Joakim - 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] - 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 application scope replication
I've read that document many times, and that does not answer my question. -ryan -Original Message- From: Lionel Farbos [mailto:[EMAIL PROTECTED] Sent: Friday, April 22, 2005 9:50 AM To: Tomcat Users List Cc: [EMAIL PROTECTED] Subject: Re: Clustering application scope replication As it is explained in the doc : All your session attributes must implement java.io.Serializable On Fri, 22 Apr 2005 09:44:01 -0500 J. Ryan Earl [EMAIL PROTECTED] wrote: How does Tomcat know what to serialize? Does it just use the Reflection package and serialize out -everything- that implements java.io.Serializable? -ryan -Original Message- From: Lionel Farbos [mailto:[EMAIL PROTECTED] Sent: Friday, April 22, 2005 9:11 AM To: Tomcat Users List Cc: [EMAIL PROTECTED] Subject: Re: Clustering application scope replication Hi For your needs, you can use session replication (http://jakarta.apache.org/tomcat/tomcat-5.5-doc/cluster-howto.html) or your own mechanisms and tables with datas in a database ... Regards. On Fri, 22 Apr 2005 15:15:54 +0200 Joakim Ahlén [EMAIL PROTECTED] wrote: Ok, too bad. Is there any way of storing objects if we want them in cluster scope? An ugly hack would be to use one single HttpSession with a special session-id to store global objects, and somehow fetch objects from within this HttpSession from inside requests that belongs to other sessions. I can't see how this could be done though, since request.getSession() can't fetch other sessions than its own. This would probably also have to include some tomcat specific magic which i wouldn't want. Any help is appreciated on how to handle this problem! Thanks Joakim On Fri, Apr 22, 2005 at 08:07:21AM -0500, Jess Holle wrote: The servlet spec says this data is local to a given JVM. I suppose a servlet engine could expand beyond the spec, but I'd be surprised if Tomcat did here. Joakim Ahlén wrote: Hi! We have a cluster of two tomcat 5.5.9-machines using session replication. However, we also have data in application scope (set with getServletContext().setAttribute(...)) which as far as i have found in the docs, is not replicated. Is there any way to accomplish this with tomcat? If not, is there any plan to develop support for it? Do other application servers have support for this? Hope you can help me. Regards Joakim - 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] - 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 application scope replication
Let me rephrase the question, how does Tomcat determine what is a session attribute. What if there are classes that implement java.io.Serializable that have nothing to do with session attributes? -ryan -Original Message- From: J. Ryan Earl [mailto:[EMAIL PROTECTED] Sent: Friday, April 22, 2005 10:19 AM To: Lionel Farbos; Tomcat Users List Subject: RE: Clustering application scope replication I've read that document many times, and that does not answer my question. -ryan -Original Message- From: Lionel Farbos [mailto:[EMAIL PROTECTED] Sent: Friday, April 22, 2005 9:50 AM To: Tomcat Users List Cc: [EMAIL PROTECTED] Subject: Re: Clustering application scope replication As it is explained in the doc : All your session attributes must implement java.io.Serializable On Fri, 22 Apr 2005 09:44:01 -0500 J. Ryan Earl [EMAIL PROTECTED] wrote: How does Tomcat know what to serialize? Does it just use the Reflection package and serialize out -everything- that implements java.io.Serializable? -ryan -Original Message- From: Lionel Farbos [mailto:[EMAIL PROTECTED] Sent: Friday, April 22, 2005 9:11 AM To: Tomcat Users List Cc: [EMAIL PROTECTED] Subject: Re: Clustering application scope replication Hi For your needs, you can use session replication (http://jakarta.apache.org/tomcat/tomcat-5.5-doc/cluster-howto.html) or your own mechanisms and tables with datas in a database ... Regards. On Fri, 22 Apr 2005 15:15:54 +0200 Joakim Ahlén [EMAIL PROTECTED] wrote: Ok, too bad. Is there any way of storing objects if we want them in cluster scope? An ugly hack would be to use one single HttpSession with a special session-id to store global objects, and somehow fetch objects from within this HttpSession from inside requests that belongs to other sessions. I can't see how this could be done though, since request.getSession() can't fetch other sessions than its own. This would probably also have to include some tomcat specific magic which i wouldn't want. Any help is appreciated on how to handle this problem! Thanks Joakim On Fri, Apr 22, 2005 at 08:07:21AM -0500, Jess Holle wrote: The servlet spec says this data is local to a given JVM. I suppose a servlet engine could expand beyond the spec, but I'd be surprised if Tomcat did here. Joakim Ahlén wrote: Hi! We have a cluster of two tomcat 5.5.9-machines using session replication. However, we also have data in application scope (set with getServletContext().setAttribute(...)) which as far as i have found in the docs, is not replicated. Is there any way to accomplish this with tomcat? If not, is there any plan to develop support for it? Do other application servers have support for this? Hope you can help me. Regards Joakim - 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] - 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: Clustering application scope replication
Only objects that you put in the session would be a session attribute. Any other classes are irrelevant whether they are serializable or not. Ta Matt -Original Message- From: J. Ryan Earl [mailto:[EMAIL PROTECTED] Sent: 22 April 2005 16:24 To: Tomcat Users List; Lionel Farbos Subject: RE: Clustering application scope replication Let me rephrase the question, how does Tomcat determine what is a session attribute. What if there are classes that implement java.io.Serializable that have nothing to do with session attributes? -ryan -Original Message- From: J. Ryan Earl [mailto:[EMAIL PROTECTED] Sent: Friday, April 22, 2005 10:19 AM To: Lionel Farbos; Tomcat Users List Subject: RE: Clustering application scope replication I've read that document many times, and that does not answer my question. -ryan -Original Message- From: Lionel Farbos [mailto:[EMAIL PROTECTED] Sent: Friday, April 22, 2005 9:50 AM To: Tomcat Users List Cc: [EMAIL PROTECTED] Subject: Re: Clustering application scope replication As it is explained in the doc : All your session attributes must implement java.io.Serializable On Fri, 22 Apr 2005 09:44:01 -0500 J. Ryan Earl [EMAIL PROTECTED] wrote: How does Tomcat know what to serialize? Does it just use the Reflection package and serialize out -everything- that implements java.io.Serializable? -ryan -Original Message- From: Lionel Farbos [mailto:[EMAIL PROTECTED] Sent: Friday, April 22, 2005 9:11 AM To: Tomcat Users List Cc: [EMAIL PROTECTED] Subject: Re: Clustering application scope replication Hi For your needs, you can use session replication (http://jakarta.apache.org/tomcat/tomcat-5.5-doc/cluster-howto.html) or your own mechanisms and tables with datas in a database ... Regards. On Fri, 22 Apr 2005 15:15:54 +0200 Joakim Ahlén [EMAIL PROTECTED] wrote: Ok, too bad. Is there any way of storing objects if we want them in cluster scope? An ugly hack would be to use one single HttpSession with a special session-id to store global objects, and somehow fetch objects from within this HttpSession from inside requests that belongs to other sessions. I can't see how this could be done though, since request.getSession() can't fetch other sessions than its own. This would probably also have to include some tomcat specific magic which i wouldn't want. Any help is appreciated on how to handle this problem! Thanks Joakim On Fri, Apr 22, 2005 at 08:07:21AM -0500, Jess Holle wrote: The servlet spec says this data is local to a given JVM. I suppose a servlet engine could expand beyond the spec, but I'd be surprised if Tomcat did here. Joakim Ahlén wrote: Hi! We have a cluster of two tomcat 5.5.9-machines using session replication. However, we also have data in application scope (set with getServletContext().setAttribute(...)) which as far as i have found in the docs, is not replicated. Is there any way to accomplish this with tomcat? If not, is there any plan to develop support for it? Do other application servers have support for this? Hope you can help me. Regards Joakim - 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] - 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: 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]
clustering without loadbalancing
I want to form a two node cluster of Tomcat servers which can failover but there should be no load balancing. But it should support session replication. This should be in such a way that all request are coming to one server(active one) and other is completely free(passive one). so if this active server fails it should be able to make the failover to the other passive server with session replication. I wan't to do it on linux. Yahoo! India Matrimony: Find your life partneronline.
clustering without loadbalancing
I want to form a two node cluster of Tomcat servers which can failover but there should be no load balancing. But it should support session replication. This should be in such a way that all request are coming to one server(active one) and other is completely free(passive one). so if this active server fails it should be able to make the failover to the other passive server with session replication. I wan't to do it on linux. P.S.-sorry for the last HTML msg. Gaurav Bansal Yahoo! India Matrimony: Find your life partner online Go to: http://yahoo.shaadi.com/india-matrimony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: clustering without loadbalancing
On 4/14/05, Gaurav Bansal [EMAIL PROTECTED] wrote: I want to form a two node cluster of Tomcat servers which can failover but there should be no load balancing. But it should support session replication. I assume that you want to do it with Apache and have mod_jk handle the distribution of requests to Tomcat as well? -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: clustering without loadbalancing
is apache necessary for this and where can i get the details regarding this becoz i m new to tomcat --- David Rees [EMAIL PROTECTED] wrote: On 4/14/05, Gaurav Bansal [EMAIL PROTECTED] wrote: I want to form a two node cluster of Tomcat servers which can failover but there should be no load balancing. But it should support session replication. I assume that you want to do it with Apache and have mod_jk handle the distribution of requests to Tomcat as well? -Dave Yahoo! India Matrimony: Find your life partner online Go to: http://yahoo.shaadi.com/india-matrimony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: clustering without loadbalancing
From: Gaurav Bansal [mailto:[EMAIL PROTECTED] is apache necessary for this No - in fact, it merely introduces another single point of failure, which I assume is what you want to avoid. However, you need *something* that will choose whether the primary or standby instance receives any given request from the user. You could use any appropriate approach - changing IP addresses, one or more front-end gateways that detect failed requests, whatever meets your requirements. - Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: clustering without loadbalancing
I am using mod_jk2, and in its workers2.properties file, you can specify level attribute for channel.socket quote from http://jakarta.apache.org/tomcat/connectors-doc-archive/jk2/jk2/configwebcom.html as description to level attribute: Worker Priority. Valid values are 0-3. The functioning workers with the lowest level will be checked for the lowest lb_value, and if found will be run. The upper level workers are only checked upon failure of all workers on ALL of the levels below them. This is very useful for implementing failover withing a cluster. You could set the tomcat server local on the same machine as the apache instance to level 0 and all of the other workers to level 1. This would cause apache to only use the external tomcats when the local tomcat is down. Basically, something like: [channel.socket:machineone:8009] port=8009 host=xxx.xxx.xxx.xxx level=1 [channel.socket:machinetwo:8009] port=8009 host=xxx.xxx.xxx.xxx level=2 in your workers2.properties file all quest will go to machineone unless it is not availuable, then all request will go to machinetwo. Cheers Hang --- Gaurav Bansal [EMAIL PROTECTED] wrote: I want to form a two node cluster of Tomcat servers which can failover but there should be no load balancing. But it should support session replication. This should be in such a way that all request are coming to one server(active one) and other is completely free(passive one). so if this active server fails it should be able to make the failover to the other passive server with session replication. I wan't to do it on linux. P.S.-sorry for the last HTML msg. Gaurav Bansal Yahoo! India Matrimony: Find your life partner online Go to: http://yahoo.shaadi.com/india-matrimony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ 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]
How to use Database persistence for tomcat clustering?
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]
RE: Authentication problems with tomcat clustering.
That was exactly it! Thank you. I had changed the configs, but had not commented in that section. All is well now. Thank you very much! |)ave -Original Message- From: David Rees [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 05, 2005 6:51 PM To: Tomcat Users List Subject: Re: Authentication problems with tomcat clustering. On Apr 5, 2005 3:13 PM, David Owens [EMAIL PROTECTED] wrote: After further debug, I see this is happening because mod_jk is ignoring the sticky sessions, and continuing to lb back and forth. After looking at the mod_jk code, I see it is looking for something after the '.' character in the JSESSIONID to tell it where the session should stick. How do I setup tomcat (or is it httpd) to provide this piece of information? The name of your worker in the mod_jk config must match the value in each Tomcat instance's server.xml. For example (abbreviated configs) in tomcat-workers.properties: worker.list=tomcat1,tomcat2 And in tomcat1's server.xml: Engine jvmRoute=tomcat1/ And in tomcat2's server.xml: Engine jvmRoute=tomcat2/ Hope this helps... -Dave - 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: Authentication problems with tomcat clustering.
You can find jakarta tomcat connector 1.2.10 Apache website http://jakarta.apache.org/tomcat/connectors-doc/ Have fun. Im still struggling with mod_jk :) Need to change, restart and la la la Vaneet -Original Message- From: David Owens [mailto:[EMAIL PROTECTED] Sent: Monday, April 04, 2005 7:25 PM To: Tomcat Users List Subject: RE: Authentication problems with tomcat clustering. Are your servlets in the /servlet/ directory? Or some other name? You have only redirected /servet/*, /*.vm and /therestaurant/servlet/ControllerServlet/* You may want to try just /therestaurant/* And you may want to do this JkMount / therestaurant /* loadbalancer On my problem: So I did some more investigation, and have found that I am authenticating against one tomcat, and then being balanced over to the other tomcat. This is presumably happening before the session is replicated... still looking for a solution... perhaps synchronous replication... I am also trying to find the 1.2.10 mod_jk for my system. (linux) -Original Message- From: Vaneet Sharma [mailto:[EMAIL PROTECTED] Sent: Monday, April 04, 2005 10:09 AM To: Tomcat Users List Subject: RE: Authentication problems with tomcat clustering. Your Apache and Tomcat configuration is exactly like me.. However today I installed connector mod_jk.. Connector 1.2.10... And ... Though apache and tomcat are talking .. I cannot run my servlet page. Pls have a look below to see the configuration Thankx The connector is not loading my servlets? I am writing down my httpd.conf and workers.properties Httpd.conf LoadModule jk_module modules/mod_jk.so ifModule mod_jk.c JkWorkersFile /usr/local/jakarta-tomcat-5.5.4/conf/workers.properties JkLogFile /etc/httpd/logs/mod_jk.log JkLogLevel info JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories JkLogStampFormat [%a %b %d %H:%M:%S %Y] JkAutoAlias /usr/local/jakarta-tomcat-5.5.4/webapps JkShmFile /etc/httpd/logs/mod_jk.shm JkMount /servlet/* ajp13Worker JkMount /*.vm ajp13Worker JkMount /therestaurant/servlet/ControllerServlet/* ajp13Worker /ifModule NameVirtualHost xxx.xxx.xxx.xxx:80 VirtualHost xxx.xxx.xxx.xxx:80 ServerAdmin [EMAIL PROTECTED] DocumentRoot /usr/local/jakarta-tomcat-x.x.x/webapps/therestaurant ServerName www.therestaurant.name /VirtualHost And below is workers.properties file worker.ajp13Worker.port=8009 worker.ajp13Worker.host=xxx.xxx.xxx.xxx worker.ajp13Worker.type=ajp13 worker.ajp13Worker.lbfactor=50 worker.ajp13Worker.cachesize=10 worker.ajp13Worker.cache_timeout=600 -Original Message- From: David Owens [mailto:[EMAIL PROTECTED] Sent: Monday, April 04, 2005 6:04 PM To: tomcat-user@jakarta.apache.org Subject: Authentication problems with tomcat clustering. I have setup load balancing and clustering between two Tomcat 5.5.7 instances and Apache 2.0.50 with mod_jk. Almost everything works great. I can fail back and forth between the 2 tomcat instances with no trouble. However, I am having problems with the form based authentication. I have an index.html file which redirects the user to a secured resource. When the user hits this file through Apache, it works like normal, directing them to the login page. However, when I attempt to login I get Invalid direct reference to form login page. When I look in the logs, I see the user is being authenticated, and the correct roles are being found. If I continually try logging in, and hitting the secure page, eventually I get in. Then, if I bounce apache, the problem starts again. If I login in the exact same manner directly against one of the tomcat instances, everything works, and I continue to the secure resource. In addition, I have found that if I stop one tomcat instance, I can login on the first try even when going through apache. It's worth noting, once I get successfully logged in once through apache (after many tries), I can logout/in repeatedly with no problem. Once I bounce apache, the problem starts again. I think something strange is happening with the login stuff when tomcat is clustered... Maybe I'm logging into 1 tomcat successfully, but being load balanced over to the other one, and the session has not been completely replicated yet? Any one else out there have this issue, or have any ideas? Thanks in advance! |)ave Vaneet Sharma executive manager iDeasTank Limited an iwg business dolphins' court po 388 valletta, m-malta/europe mobile: +356 9943 8263 skype: CALLVANEET fax: +356 9952 phone: +356 9942 [EMAIL PROTECTED] call me on www.skype.com - my ID is CALLVANEET Want a signature like this? - www.plaxo.com\signature iwg is a global e-mobile company creating, building and growing new businesses. iwg founders are pioneers in creating multi-billion dollar mobile and Internet businesses in Europe, Asia and the US. www.iWG.info www.countryprofiler.com/iWG www.visitmalta.com www.mfc.com.mt Privileged/Confidential
RE: Authentication problems with tomcat clustering.
I have done some further testing and have found what I think the problem is, but I still do not know the solution. What is happening is that the first time I access the webapp through httpd, I am getting the first tomcat server. I then type in my username and password and hit submit. I see in the logs of the first tomcat server log the authentication happening successfully, however, I am then redirected to the second tomcat server where my session is not available. I am using a 'lb' type load balancer, and by default it has sticky sessions, so I wonder why I am being balanced over to the other tomcat. Is this, perhaps, a question for the mod_jk team? Is there such a mailing list? |)ave -Original Message- From: David Owens Sent: Monday, April 04, 2005 10:04 AM To: 'tomcat-user@jakarta.apache.org' Subject: Authentication problems with tomcat clustering. I have setup load balancing and clustering between two Tomcat 5.5.7 instances and Apache 2.0.50 with mod_jk. Almost everything works great. I can fail back and forth between the 2 tomcat instances with no trouble. However, I am having problems with the form based authentication. I have an index.html file which redirects the user to a secured resource. When the user hits this file through Apache, it works like normal, directing them to the login page. However, when I attempt to login I get Invalid direct reference to form login page. When I look in the logs, I see the user is being authenticated, and the correct roles are being found. If I continually try logging in, and hitting the secure page, eventually I get in. Then, if I bounce apache, the problem starts again. If I login in the exact same manner directly against one of the tomcat instances, everything works, and I continue to the secure resource. In addition, I have found that if I stop one tomcat instance, I can login on the first try even when going through apache. It's worth noting, once I get successfully logged in once through apache (after many tries), I can logout/in repeatedly with no problem. Once I bounce apache, the problem starts again. I think something strange is happening with the login stuff when tomcat is clustered... Maybe I'm logging into 1 tomcat successfully, but being load balanced over to the other one, and the session has not been completely replicated yet? Any one else out there have this issue, or have any ideas? Thanks in advance! |)ave
RE: Authentication problems with tomcat clustering.
Okay, not quite right... I first hit tomcat1 though httpd. When I submit I see successful authentication in the log for tomcat2. I then get the Invalid direct reference... message. I am now using mod_jk 1.2.10. Still no idea why this is happening... |)ave -Original Message- From: David Owens Sent: Tuesday, April 05, 2005 7:11 AM To: tomcat-user@jakarta.apache.org Subject: RE: Authentication problems with tomcat clustering. I have done some further testing and have found what I think the problem is, but I still do not know the solution. What is happening is that the first time I access the webapp through httpd, I am getting the first tomcat server. I then type in my username and password and hit submit. I see in the logs of the first tomcat server log the authentication happening successfully, however, I am then redirected to the second tomcat server where my session is not available. I am using a 'lb' type load balancer, and by default it has sticky sessions, so I wonder why I am being balanced over to the other tomcat. Is this, perhaps, a question for the mod_jk team? Is there such a mailing list? |)ave -Original Message- From: David Owens Sent: Monday, April 04, 2005 10:04 AM To: 'tomcat-user@jakarta.apache.org' Subject: Authentication problems with tomcat clustering. I have setup load balancing and clustering between two Tomcat 5.5.7 instances and Apache 2.0.50 with mod_jk. Almost everything works great. I can fail back and forth between the 2 tomcat instances with no trouble. However, I am having problems with the form based authentication. I have an index.html file which redirects the user to a secured resource. When the user hits this file through Apache, it works like normal, directing them to the login page. However, when I attempt to login I get Invalid direct reference to form login page. When I look in the logs, I see the user is being authenticated, and the correct roles are being found. If I continually try logging in, and hitting the secure page, eventually I get in. Then, if I bounce apache, the problem starts again. If I login in the exact same manner directly against one of the tomcat instances, everything works, and I continue to the secure resource. In addition, I have found that if I stop one tomcat instance, I can login on the first try even when going through apache. It's worth noting, once I get successfully logged in once through apache (after many tries), I can logout/in repeatedly with no problem. Once I bounce apache, the problem starts again. I think something strange is happening with the login stuff when tomcat is clustered... Maybe I'm logging into 1 tomcat successfully, but being load balanced over to the other one, and the session has not been completely replicated yet? Any one else out there have this issue, or have any ideas? Thanks in advance! |)ave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Authentication problems with tomcat clustering.
I suggest u do step by step again You will find the bug. Start from basic . First run one ... And then try loadbalancer.. Later on Vaneet -Original Message- From: David Owens [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 05, 2005 3:11 PM To: tomcat-user@jakarta.apache.org Subject: RE: Authentication problems with tomcat clustering. I have done some further testing and have found what I think the problem is, but I still do not know the solution. What is happening is that the first time I access the webapp through httpd, I am getting the first tomcat server. I then type in my username and password and hit submit. I see in the logs of the first tomcat server log the authentication happening successfully, however, I am then redirected to the second tomcat server where my session is not available. I am using a 'lb' type load balancer, and by default it has sticky sessions, so I wonder why I am being balanced over to the other tomcat. Is this, perhaps, a question for the mod_jk team? Is there such a mailing list? |)ave -Original Message- From: David Owens Sent: Monday, April 04, 2005 10:04 AM To: 'tomcat-user@jakarta.apache.org' Subject: Authentication problems with tomcat clustering. I have setup load balancing and clustering between two Tomcat 5.5.7 instances and Apache 2.0.50 with mod_jk. Almost everything works great. I can fail back and forth between the 2 tomcat instances with no trouble. However, I am having problems with the form based authentication. I have an index.html file which redirects the user to a secured resource. When the user hits this file through Apache, it works like normal, directing them to the login page. However, when I attempt to login I get Invalid direct reference to form login page. When I look in the logs, I see the user is being authenticated, and the correct roles are being found. If I continually try logging in, and hitting the secure page, eventually I get in. Then, if I bounce apache, the problem starts again. If I login in the exact same manner directly against one of the tomcat instances, everything works, and I continue to the secure resource. In addition, I have found that if I stop one tomcat instance, I can login on the first try even when going through apache. It's worth noting, once I get successfully logged in once through apache (after many tries), I can logout/in repeatedly with no problem. Once I bounce apache, the problem starts again. I think something strange is happening with the login stuff when tomcat is clustered... Maybe I'm logging into 1 tomcat successfully, but being load balanced over to the other one, and the session has not been completely replicated yet? Any one else out there have this issue, or have any ideas? Thanks in advance! |)ave Vaneet Sharma executive manager iDeasTank Limited an iwg business dolphins' court po 388 valletta, m-malta/europe mobile: +356 9943 8263 skype: CALLVANEET fax: +356 9952 phone: +356 9942 [EMAIL PROTECTED] call me on www.skype.com - my ID is CALLVANEET Want a signature like this? - www.plaxo.com\signature iwg is a global e-mobile company creating, building and growing new businesses. iwg founders are pioneers in creating multi-billion dollar mobile and Internet businesses in Europe, Asia and the US. www.iWG.info www.countryprofiler.com/iWG www.visitmalta.com www.mfc.com.mt Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Authentication problems with tomcat clustering.
After further debug, I see this is happening because mod_jk is ignoring the sticky sessions, and continuing to lb back and forth. After looking at the mod_jk code, I see it is looking for something after the '.' character in the JSESSIONID to tell it where the session should stick. How do I setup tomcat (or is it httpd) to provide this piece of information? Thanks! |)ave -Original Message- From: David Owens Sent: Tuesday, April 05, 2005 7:11 AM To: tomcat-user@jakarta.apache.org Subject: RE: Authentication problems with tomcat clustering. I have done some further testing and have found what I think the problem is, but I still do not know the solution. What is happening is that the first time I access the webapp through httpd, I am getting the first tomcat server. I then type in my username and password and hit submit. I see in the logs of the first tomcat server log the authentication happening successfully, however, I am then redirected to the second tomcat server where my session is not available. I am using a 'lb' type load balancer, and by default it has sticky sessions, so I wonder why I am being balanced over to the other tomcat. Is this, perhaps, a question for the mod_jk team? Is there such a mailing list? |)ave -Original Message- From: David Owens Sent: Monday, April 04, 2005 10:04 AM To: 'tomcat-user@jakarta.apache.org' Subject: Authentication problems with tomcat clustering. I have setup load balancing and clustering between two Tomcat 5.5.7 instances and Apache 2.0.50 with mod_jk. Almost everything works great. I can fail back and forth between the 2 tomcat instances with no trouble. However, I am having problems with the form based authentication. I have an index.html file which redirects the user to a secured resource. When the user hits this file through Apache, it works like normal, directing them to the login page. However, when I attempt to login I get Invalid direct reference to form login page. When I look in the logs, I see the user is being authenticated, and the correct roles are being found. If I continually try logging in, and hitting the secure page, eventually I get in. Then, if I bounce apache, the problem starts again. If I login in the exact same manner directly against one of the tomcat instances, everything works, and I continue to the secure resource. In addition, I have found that if I stop one tomcat instance, I can login on the first try even when going through apache. It's worth noting, once I get successfully logged in once through apache (after many tries), I can logout/in repeatedly with no problem. Once I bounce apache, the problem starts again. I think something strange is happening with the login stuff when tomcat is clustered... Maybe I'm logging into 1 tomcat successfully, but being load balanced over to the other one, and the session has not been completely replicated yet? Any one else out there have this issue, or have any ideas? Thanks in advance! |)ave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Authentication problems with tomcat clustering.
On Apr 5, 2005 3:13 PM, David Owens [EMAIL PROTECTED] wrote: After further debug, I see this is happening because mod_jk is ignoring the sticky sessions, and continuing to lb back and forth. After looking at the mod_jk code, I see it is looking for something after the '.' character in the JSESSIONID to tell it where the session should stick. How do I setup tomcat (or is it httpd) to provide this piece of information? The name of your worker in the mod_jk config must match the value in each Tomcat instance's server.xml. For example (abbreviated configs) in tomcat-workers.properties: worker.list=tomcat1,tomcat2 And in tomcat1's server.xml: Engine jvmRoute=tomcat1/ And in tomcat2's server.xml: Engine jvmRoute=tomcat2/ Hope this helps... -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Authentication problems with tomcat clustering.
I have setup load balancing and clustering between two Tomcat 5.5.7 instances and Apache 2.0.50 with mod_jk. Almost everything works great. I can fail back and forth between the 2 tomcat instances with no trouble. However, I am having problems with the form based authentication. I have an index.html file which redirects the user to a secured resource. When the user hits this file through Apache, it works like normal, directing them to the login page. However, when I attempt to login I get Invalid direct reference to form login page. When I look in the logs, I see the user is being authenticated, and the correct roles are being found. If I continually try logging in, and hitting the secure page, eventually I get in. Then, if I bounce apache, the problem starts again. If I login in the exact same manner directly against one of the tomcat instances, everything works, and I continue to the secure resource. In addition, I have found that if I stop one tomcat instance, I can login on the first try even when going through apache. It's worth noting, once I get successfully logged in once through apache (after many tries), I can logout/in repeatedly with no problem. Once I bounce apache, the problem starts again. I think something strange is happening with the login stuff when tomcat is clustered... Maybe I'm logging into 1 tomcat successfully, but being load balanced over to the other one, and the session has not been completely replicated yet? Any one else out there have this issue, or have any ideas? Thanks in advance! |)ave
RE: Authentication problems with tomcat clustering.
Your Apache and Tomcat configuration is exactly like me.. However today I installed connector mod_jk.. Connector 1.2.10... And ... Though apache and tomcat are talking .. I cannot run my servlet page. Pls have a look below to see the configuration Thankx The connector is not loading my servlets? I am writing down my httpd.conf and workers.properties Httpd.conf LoadModule jk_module modules/mod_jk.so ifModule mod_jk.c JkWorkersFile /usr/local/jakarta-tomcat-5.5.4/conf/workers.properties JkLogFile /etc/httpd/logs/mod_jk.log JkLogLevel info JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories JkLogStampFormat [%a %b %d %H:%M:%S %Y] JkAutoAlias /usr/local/jakarta-tomcat-5.5.4/webapps JkShmFile /etc/httpd/logs/mod_jk.shm JkMount /servlet/* ajp13Worker JkMount /*.vm ajp13Worker JkMount /therestaurant/servlet/ControllerServlet/* ajp13Worker /ifModule NameVirtualHost xxx.xxx.xxx.xxx:80 VirtualHost xxx.xxx.xxx.xxx:80 ServerAdmin [EMAIL PROTECTED] DocumentRoot /usr/local/jakarta-tomcat-x.x.x/webapps/therestaurant ServerName www.therestaurant.name /VirtualHost And below is workers.properties file worker.ajp13Worker.port=8009 worker.ajp13Worker.host=xxx.xxx.xxx.xxx worker.ajp13Worker.type=ajp13 worker.ajp13Worker.lbfactor=50 worker.ajp13Worker.cachesize=10 worker.ajp13Worker.cache_timeout=600 -Original Message- From: David Owens [mailto:[EMAIL PROTECTED] Sent: Monday, April 04, 2005 6:04 PM To: tomcat-user@jakarta.apache.org Subject: Authentication problems with tomcat clustering. I have setup load balancing and clustering between two Tomcat 5.5.7 instances and Apache 2.0.50 with mod_jk. Almost everything works great. I can fail back and forth between the 2 tomcat instances with no trouble. However, I am having problems with the form based authentication. I have an index.html file which redirects the user to a secured resource. When the user hits this file through Apache, it works like normal, directing them to the login page. However, when I attempt to login I get Invalid direct reference to form login page. When I look in the logs, I see the user is being authenticated, and the correct roles are being found. If I continually try logging in, and hitting the secure page, eventually I get in. Then, if I bounce apache, the problem starts again. If I login in the exact same manner directly against one of the tomcat instances, everything works, and I continue to the secure resource. In addition, I have found that if I stop one tomcat instance, I can login on the first try even when going through apache. It's worth noting, once I get successfully logged in once through apache (after many tries), I can logout/in repeatedly with no problem. Once I bounce apache, the problem starts again. I think something strange is happening with the login stuff when tomcat is clustered... Maybe I'm logging into 1 tomcat successfully, but being load balanced over to the other one, and the session has not been completely replicated yet? Any one else out there have this issue, or have any ideas? Thanks in advance! |)ave Vaneet Sharma executive manager iDeasTank Limited an iwg business dolphins' court po 388 valletta, m-malta/europe mobile: +356 9943 8263 skype: CALLVANEET fax: +356 9952 phone: +356 9942 [EMAIL PROTECTED] call me on www.skype.com - my ID is CALLVANEET Want a signature like this? - www.plaxo.com\signature iwg is a global e-mobile company creating, building and growing new businesses. iwg founders are pioneers in creating multi-billion dollar mobile and Internet businesses in Europe, Asia and the US. www.iWG.info www.countryprofiler.com/iWG www.visitmalta.com www.mfc.com.mt Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Authentication problems with tomcat clustering.
Are your servlets in the /servlet/ directory? Or some other name? You have only redirected /servet/*, /*.vm and /therestaurant/servlet/ControllerServlet/* You may want to try just /therestaurant/* And you may want to do this JkMount / therestaurant /* loadbalancer On my problem: So I did some more investigation, and have found that I am authenticating against one tomcat, and then being balanced over to the other tomcat. This is presumably happening before the session is replicated... still looking for a solution... perhaps synchronous replication... I am also trying to find the 1.2.10 mod_jk for my system. (linux) -Original Message- From: Vaneet Sharma [mailto:[EMAIL PROTECTED] Sent: Monday, April 04, 2005 10:09 AM To: Tomcat Users List Subject: RE: Authentication problems with tomcat clustering. Your Apache and Tomcat configuration is exactly like me.. However today I installed connector mod_jk.. Connector 1.2.10... And ... Though apache and tomcat are talking .. I cannot run my servlet page. Pls have a look below to see the configuration Thankx The connector is not loading my servlets? I am writing down my httpd.conf and workers.properties Httpd.conf LoadModule jk_module modules/mod_jk.so ifModule mod_jk.c JkWorkersFile /usr/local/jakarta-tomcat-5.5.4/conf/workers.properties JkLogFile /etc/httpd/logs/mod_jk.log JkLogLevel info JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories JkLogStampFormat [%a %b %d %H:%M:%S %Y] JkAutoAlias /usr/local/jakarta-tomcat-5.5.4/webapps JkShmFile /etc/httpd/logs/mod_jk.shm JkMount /servlet/* ajp13Worker JkMount /*.vm ajp13Worker JkMount /therestaurant/servlet/ControllerServlet/* ajp13Worker /ifModule NameVirtualHost xxx.xxx.xxx.xxx:80 VirtualHost xxx.xxx.xxx.xxx:80 ServerAdmin [EMAIL PROTECTED] DocumentRoot /usr/local/jakarta-tomcat-x.x.x/webapps/therestaurant ServerName www.therestaurant.name /VirtualHost And below is workers.properties file worker.ajp13Worker.port=8009 worker.ajp13Worker.host=xxx.xxx.xxx.xxx worker.ajp13Worker.type=ajp13 worker.ajp13Worker.lbfactor=50 worker.ajp13Worker.cachesize=10 worker.ajp13Worker.cache_timeout=600 -Original Message- From: David Owens [mailto:[EMAIL PROTECTED] Sent: Monday, April 04, 2005 6:04 PM To: tomcat-user@jakarta.apache.org Subject: Authentication problems with tomcat clustering. I have setup load balancing and clustering between two Tomcat 5.5.7 instances and Apache 2.0.50 with mod_jk. Almost everything works great. I can fail back and forth between the 2 tomcat instances with no trouble. However, I am having problems with the form based authentication. I have an index.html file which redirects the user to a secured resource. When the user hits this file through Apache, it works like normal, directing them to the login page. However, when I attempt to login I get Invalid direct reference to form login page. When I look in the logs, I see the user is being authenticated, and the correct roles are being found. If I continually try logging in, and hitting the secure page, eventually I get in. Then, if I bounce apache, the problem starts again. If I login in the exact same manner directly against one of the tomcat instances, everything works, and I continue to the secure resource. In addition, I have found that if I stop one tomcat instance, I can login on the first try even when going through apache. It's worth noting, once I get successfully logged in once through apache (after many tries), I can logout/in repeatedly with no problem. Once I bounce apache, the problem starts again. I think something strange is happening with the login stuff when tomcat is clustered... Maybe I'm logging into 1 tomcat successfully, but being load balanced over to the other one, and the session has not been completely replicated yet? Any one else out there have this issue, or have any ideas? Thanks in advance! |)ave Vaneet Sharma executive manager iDeasTank Limited an iwg business dolphins' court po 388 valletta, m-malta/europe mobile: +356 9943 8263 skype: CALLVANEET fax: +356 9952 phone: +356 9942 [EMAIL PROTECTED] call me on www.skype.com - my ID is CALLVANEET Want a signature like this? - www.plaxo.com\signature iwg is a global e-mobile company creating, building and growing new businesses. iwg founders are pioneers in creating multi-billion dollar mobile and Internet businesses in Europe, Asia and the US. www.iWG.info www.countryprofiler.com/iWG www.visitmalta.com www.mfc.com.mt Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. - To unsubscribe, e-mail
Clustering question
Hi, I have setup two tomcat 5.5.7 servers which are clustered. Everything is working and the basic session is replication. However, when I add my own custom java object to the session this is not replicated. I have made it Serializable but this object also contains other java objects which are not serializable. Is this a problem? Is there anything special I need to consider to get my custom session objects to replicate?? Thanks, Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Clustering question
Yes this is a problem. All objects contained within a serializable object must in turn be serializable themselves. -Original Message- From: Steven Pannell [mailto:[EMAIL PROTECTED] Sent: 01 April 2005 12:33 To: 'tomcat-user@jakarta.apache.org' Subject: Clustering question Hi, I have setup two tomcat 5.5.7 servers which are clustered. Everything is working and the basic session is replication. However, when I add my own custom java object to the session this is not replicated. I have made it Serializable but this object also contains other java objects which are not serializable. Is this a problem? Is there anything special I need to consider to get my custom session objects to replicate?? Thanks, Steve. - 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]
[OT] Serialization (was RE: Clustering question)
From: Dale, Matt [mailto:[EMAIL PROTECTED] Yes this is a problem. All objects contained within a serializable object must in turn be serializable themselves. Or marked as 'transient'. This omits them from serialization. - Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clustering question
Not all the objects inside your class must be serializable. Set all the objects you don't want to persist as transient. [ For instance, I don't want to persist a data connection [in this way] or a logger ] Viorel Dragomir . .. --- - Original Message - From: Dale, Matt To: Tomcat Users List Sent: Friday, April 01, 2005 13:38 Subject: RE: Clustering question Yes this is a problem. All objects contained within a serializable object must in turn be serializable themselves. -Original Message- From: Steven Pannell [mailto:[EMAIL PROTECTED] Sent: 01 April 2005 12:33 To: 'tomcat-user@jakarta.apache.org' Subject: Clustering question Hi, I have setup two tomcat 5.5.7 servers which are clustered. Everything is working and the basic session is replication. However, when I add my own custom java object to the session this is not replicated. I have made it Serializable but this object also contains other java objects which are not serializable. Is this a problem? Is there anything special I need to consider to get my custom session objects to replicate?? Thanks, Steve. - 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 question
Or they can be transient i.e. not serialized in a serialization process Sébastien Letélié -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Dale, Matt Envoyé : vendredi 1 avril 2005 13:38 À : Tomcat Users List Objet : RE: Clustering question Yes this is a problem. All objects contained within a serializable object must in turn be serializable themselves. -Original Message- From: Steven Pannell [mailto:[EMAIL PROTECTED] Sent: 01 April 2005 12:33 To: 'tomcat-user@jakarta.apache.org' Subject: Clustering question Hi, I have setup two tomcat 5.5.7 servers which are clustered. Everything is working and the basic session is replication. However, when I add my own custom java object to the session this is not replicated. I have made it Serializable but this object also contains other java objects which are not serializable. Is this a problem? Is there anything special I need to consider to get my custom session objects to replicate?? Thanks, Steve. - 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: [OT] Serialization (was RE: Clustering question)
Peter Crowther wrote: From: Dale, Matt [mailto:[EMAIL PROTECTED] Yes this is a problem. All objects contained within a serializable object must in turn be serializable themselves. Or marked as 'transient'. This omits them from serialization. If you mark them as transient, you may need need to implement a method (ReadObject I believe) that properly initializes the transient variables/objects. There is an earlier post on this list where I describe how to do this. I had a similar problem in that many of my classes had a Commons Logger object stored in them. This had to be re-instatiated correctly when the object was replicated. HTH - Richard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat clustering and NotSerializableException
This will be a problem if the requests from the frames use the same Struts form. Else it should be fine, since the framework will set the request into the Struts form for each request, so transient will still work. - Jim From: Caldarale, Charles R [mailto:[EMAIL PROTECTED] Sent: Wed 3/2/2005 12:17 PM To: Tomcat Users List Subject: RE: Tomcat clustering and NotSerializableException From: Sng Wee Jim [mailto:[EMAIL PROTECTED] Subject: RE: Tomcat clustering and NotSerializableException Indeed a reference to the HttpServletRequest is held in my Struts form (session-scope). The problem went away once I added transient to the attribute. How do you handle the situation of having multiple concurrent requests on the same session? This can easily happen with frames, users clicking refresh, etc. - 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. The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorized. If you are not an intended recipient, please notify the sender of this email immediately. You should not copy, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Capco. http://www.capco.com/
session load-balancing and clustering of tomcat
Hi, I am using tomcat 5.0.28. My question is how to setup sticky-session load-balancing and clustering of tomcat? Do I need to upgrade to tomcat 5.5.X? Note the requirement is on sticky-session. - Jim The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorized. If you are not an intended recipient, please notify the sender of this email immediately. You should not copy, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Capco. http://www.capco.com/
Re: session load-balancing and clustering of tomcat
1) In server.xml : - uncomment the AJP 1.3 Connector (on port 8009), - set the jvmRoute in each Engine example : Engine name=Standalone defaultHost=host1 debug=0 jvmRoute=t1_ajp13 2) then add the module mod_jk in apache with jk workers defined like this : worker.list=t1_ajp13,t2_ajp13,loadbalancer worker.t1_ajp13.type=ajp13 worker.t1_ajp13.host=host1 worker.t1_ajp13.port=8009 worker.t1_ajp13.lbfactor=1 worker.t1_ajp13.socket_timeout=5 worker.t1_ajp13.recycle_timeout=10 worker.t2_ajp13.type=ajp13 worker.t2_ajp13.host=host2 worker.t2_ajp13.port=8009 worker.t2_ajp13.lbfactor=1 worker.t2_ajp13.socket_timeout=5 worker.t2_ajp13.recycle_timeout=10 worker.loadbalancer.type=lb worker.loadbalancer.balanced_workers= t1_ajp13,t2_ajp13 then, you can load-balance your virtual host like this : JkMount /*.jsp loadbalancer 3) Conclusion : Thanks to mod_jk, you'll have load-balancing (with sticky sessions with JSESSION_ID like this : x.t1_ajp13 or y.t2_ajp13), and failover. This feature work with all tomcats (TC3.3-TC5) On Tue, 1 Mar 2005 18:08:59 +0800 Sng Wee Jim [EMAIL PROTECTED] wrote: Hi, I am using tomcat 5.0.28. My question is how to setup sticky-session load-balancing and clustering of tomcat? Do I need to upgrade to tomcat 5.5.X? Note the requirement is on sticky-session. - Jim The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorized. If you are not an intended recipient, please notify the sender of this email immediately. You should not copy, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Capco. http://www.capco.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: session load-balancing and clustering of tomcat
My gotcha was setting the jvmRoute in EACH/EVERY Engine! -Original Message- From: Lionel Farbos [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 01, 2005 8:20 AM To: Tomcat Users List Cc: [EMAIL PROTECTED] Subject: Re: session load-balancing and clustering of tomcat 1) In server.xml : - uncomment the AJP 1.3 Connector (on port 8009), - set the jvmRoute in each Engine example : Engine name=Standalone defaultHost=host1 debug=0 jvmRoute=t1_ajp13 2) then add the module mod_jk in apache with jk workers defined like this : worker.list=t1_ajp13,t2_ajp13,loadbalancer worker.t1_ajp13.type=ajp13 worker.t1_ajp13.host=host1 worker.t1_ajp13.port=8009 worker.t1_ajp13.lbfactor=1 worker.t1_ajp13.socket_timeout=5 worker.t1_ajp13.recycle_timeout=10 worker.t2_ajp13.type=ajp13 worker.t2_ajp13.host=host2 worker.t2_ajp13.port=8009 worker.t2_ajp13.lbfactor=1 worker.t2_ajp13.socket_timeout=5 worker.t2_ajp13.recycle_timeout=10 worker.loadbalancer.type=lb worker.loadbalancer.balanced_workers= t1_ajp13,t2_ajp13 then, you can load-balance your virtual host like this : JkMount /*.jsp loadbalancer 3) Conclusion : Thanks to mod_jk, you'll have load-balancing (with sticky sessions with JSESSION_ID like this : x.t1_ajp13 or y.t2_ajp13), and failover. This feature work with all tomcats (TC3.3-TC5) On Tue, 1 Mar 2005 18:08:59 +0800 Sng Wee Jim [EMAIL PROTECTED] wrote: Hi, I am using tomcat 5.0.28. My question is how to setup sticky-session load-balancing and clustering of tomcat? Do I need to upgrade to tomcat 5.5.X? Note the requirement is on sticky-session. - Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat clustering and NotSerializableException
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
RE: Tomcat clustering and NotSerializableException
From: Richard Mixon (qwest) [mailto:[EMAIL PROTECTED] Subject: RE: Tomcat clustering and NotSerializableException CoyoteRequestFacade is the first element in the stack trace - it is not the session stored object that is causing the NotSerializableException. Actually, the CoyoteRequestFacade _is_ the object being serialized. That class name is the explanatory text added to the exception being thrown by ObjectOutputStream at line 1054 (look at the JRE source), not the origin of the exception. Nonetheless, your points are still valid. Whatever code is sneaking a direct or indirect reference to the request into the session object needs to be changed. As you indicated, it must be an indirect reference from an attribute added to the session, since a direct one wouldn't pass the serializability check. (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:1304) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java: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.writeExternal(DeltaRequest.java:300) at org.apache.catalina.cluster.session.DeltaRequest.writeExternal(DeltaRequest.java:217) at org.apache.catalina.cluster.session.DeltaManager.unloadDeltaRequest(DeltaManager.java:393) at org.apache.catalina.cluster.session.DeltaManager.requestCompleted(DeltaManager.java:782) at org.apache.catalina.cluster.tcp.ReplicationValve.invoke(ReplicationValve.java:203) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160) 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.java:675) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:866) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683) at java.lang.Thread.run(Thread.java:534) - 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: [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 org.apache.tomcat.util.threads.ThreadPool
Re: session load-balancing and clustering of tomcat
Lionel Farbos wrote: 1) In server.xml : - uncomment the AJP 1.3 Connector (on port 8009), - set the jvmRoute in each Engine example : Engine name=Standalone defaultHost=host1 debug=0 jvmRoute=t1_ajp13 Session route *must* consists only of alphanumeric characters. See the: http://jakarta.apache.org/tomcat/connectors-doc/config/workers.html Later mod_jk releases will have that as prerequisite so that we don't need to url encode session routes. 2) then add the module mod_jk in apache with jk workers defined like this : worker.list=t1_ajp13,t2_ajp13,loadbalancer This is not quite correct, although it will work. You should set worker.list only for workers that have JkMount directive registered. Also workers that are member of load balancer *should* not be listed within worker.list Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: session load-balancing and clustering of tomcat
On Tue, 01 Mar 2005 17:55:15 +0100 Mladen Turk [EMAIL PROTECTED] wrote: Lionel Farbos wrote: 2) then add the module mod_jk in apache with jk workers defined like this : worker.list=t1_ajp13,t2_ajp13,loadbalancer This is not quite correct, although it will work. You should set worker.list only for workers that have JkMount directive registered. Also workers that are member of load balancer *should* not be listed within worker.list I put this example because it can be useful for maintenance (the JkMount directive at the instant t is possibly not the same as at the instant t+x) Example : My webapp testAppli is now loadbalanced on hosts h1 and h2. If want to upgrade my webapp testAppli. So, 1) I mono-balance testAppli on h2 (with JkMount /*.jsp h2 + apache reload) 2) I restart testAppli on the Tomcat_h1 instance 3) I mono-balance testAppli on h1 4) I restart testAppli on the Tomcat_h2 instance 5) I re-loadbalance testAppli With this principle + mod_jk 1.2.9 (with dynamic change of properties) + a graceful restart of Context I hope upgrading my webapp transparently (without interruptions)... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat clustering and NotSerializableException
Thanks to all that replied. Indeed a reference to the HttpServletRequest is held in my Struts form (session-scope). The problem went away once I added transient to the attribute. My concern is when the session is replicated to other tomcat instances, will a call to getRequest() always return null? - Jim -Original Message- From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 01, 2005 11:47 PM To: Tomcat Users List Subject: 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:1 3 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
RE: Tomcat clustering and NotSerializableException
If you specify transient on the HttpServletRequest property in your form bean (this does not seem like good design) you must make provisions when the form bean is de-serialized on the other end to initialize the property. See my post on this list for the subject titled RE: SOLVED - commons-logging logger instances - how to initialize in replicated session objectsr fo the details of one way to do this. HTH - Richard -Original Message- From: Sng Wee Jim [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 01, 2005 7:47 PM To: Tomcat Users List Subject: RE: Tomcat clustering and NotSerializableException Thanks to all that replied. Indeed a reference to the HttpServletRequest is held in my Struts form (session-scope). The problem went away once I added transient to the attribute. My concern is when the session is replicated to other tomcat instances, will a call to getRequest() always return null? - Jim -Original Message- From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 01, 2005 11:47 PM To: Tomcat Users List Subject: 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:1 3 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
RE: Tomcat clustering and NotSerializableException
From: Sng Wee Jim [mailto:[EMAIL PROTECTED] Subject: RE: Tomcat clustering and NotSerializableException Indeed a reference to the HttpServletRequest is held in my Struts form (session-scope). The problem went away once I added transient to the attribute. How do you handle the situation of having multiple concurrent requests on the same session? This can easily happen with frames, users clicking refresh, etc. - 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: session load-balancing and clustering of tomcat
Hi, I am actually trying to get sticky session load-balancing with IIS tomcat (not apache webserver, client's requirement). My worker.properties: == worker.list=tomcat1,tomcat2 worker.tomcat1.type=ajp13 worker.tomcat1.host=localhost worker.tomcat1.port=8009 worker.tomcat1.lbfactor=1 worker.tomcat1.socket_timeout=5 worker.tomcat1.recycle_timeout=10 worker.tomcat2.type=ajp13 worker.tomcat2.host=localhost worker.tomcat2.port=8209 worker.tomcat2.lbfactor=1 worker.tomcat2.socket_timeout=5 worker.tomcat2.recycle_timeout=10 worker.loadbalancer.type=lb worker.loadbalancer.balanced_workers=tomcat1 My uriworkermap.properties: === default.worker=tomcat1 /webapp/*.jsp=$(default.worker) /webapp/*.do=$(default.worker) tomcat1 seems to be hardcoded to be the default worker. So how should I configure, so that tomcat2 will be used for the load-balancing redirection too? Also tomcat1 is specified as a load-balancer worker, does that mean that if tomcat1 goes down, then load-balancing will cease too? - Jim -Original Message- From: Mladen Turk [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 02, 2005 12:55 AM To: Tomcat Users List Subject: Re: session load-balancing and clustering of tomcat Lionel Farbos wrote: 1) In server.xml : - uncomment the AJP 1.3 Connector (on port 8009), - set the jvmRoute in each Engine example : Engine name=Standalone defaultHost=host1 debug=0 jvmRoute=t1_ajp13 Session route *must* consists only of alphanumeric characters. See the: http://jakarta.apache.org/tomcat/connectors-doc/config/workers.html Later mod_jk releases will have that as prerequisite so that we don't need to url encode session routes. 2) then add the module mod_jk in apache with jk workers defined like this : worker.list=t1_ajp13,t2_ajp13,loadbalancer This is not quite correct, although it will work. You should set worker.list only for workers that have JkMount directive registered. Also workers that are member of load balancer *should* not be listed within worker.list Regards, Mladen. The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorized. If you are not an intended recipient, please notify the sender of this email immediately. You should not copy, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Capco. http://www.capco.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: session load-balancing and clustering of tomcat
Hi, Sorry for the noise. I have found the solution at http://marc.theaimsgroup.com/?l=tomcat-userm=104808785801048w=2 - Jim -Original Message- From: Sng Wee Jim Sent: Wednesday, March 02, 2005 2:14 PM To: 'Mladen Turk'; Tomcat Users List Subject: RE: session load-balancing and clustering of tomcat Hi, I am actually trying to get sticky session load-balancing with IIS tomcat (not apache webserver, client's requirement). My worker.properties: == worker.list=tomcat1,tomcat2 worker.tomcat1.type=ajp13 worker.tomcat1.host=localhost worker.tomcat1.port=8009 worker.tomcat1.lbfactor=1 worker.tomcat1.socket_timeout=5 worker.tomcat1.recycle_timeout=10 worker.tomcat2.type=ajp13 worker.tomcat2.host=localhost worker.tomcat2.port=8209 worker.tomcat2.lbfactor=1 worker.tomcat2.socket_timeout=5 worker.tomcat2.recycle_timeout=10 worker.loadbalancer.type=lb worker.loadbalancer.balanced_workers=tomcat1 My uriworkermap.properties: === default.worker=tomcat1 /webapp/*.jsp=$(default.worker) /webapp/*.do=$(default.worker) tomcat1 seems to be hardcoded to be the default worker. So how should I configure, so that tomcat2 will be used for the load-balancing redirection too? Also tomcat1 is specified as a load-balancer worker, does that mean that if tomcat1 goes down, then load-balancing will cease too? - Jim -Original Message- From: Mladen Turk [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 02, 2005 12:55 AM To: Tomcat Users List Subject: Re: session load-balancing and clustering of tomcat Lionel Farbos wrote: 1) In server.xml : - uncomment the AJP 1.3 Connector (on port 8009), - set the jvmRoute in each Engine example : Engine name=Standalone defaultHost=host1 debug=0 jvmRoute=t1_ajp13 Session route *must* consists only of alphanumeric characters. See the: http://jakarta.apache.org/tomcat/connectors-doc/config/workers.html Later mod_jk releases will have that as prerequisite so that we don't need to url encode session routes. 2) then add the module mod_jk in apache with jk workers defined like this : worker.list=t1_ajp13,t2_ajp13,loadbalancer This is not quite correct, although it will work. You should set worker.list only for workers that have JkMount directive registered. Also workers that are member of load balancer *should* not be listed within worker.list Regards, Mladen. The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorized. If you are not an intended recipient, please notify the sender of this email immediately. You should not copy, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Capco. http://www.capco.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP ool.java:683) at java.lang.Thread.run(Thread.java:534) - Jim The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorized. If you are not an intended recipient, please notify the sender of this email immediately. You should not copy, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Capco. http://www.capco.com/
RE: Tomcat clustering and NotSerializableException
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 org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP ool.java:683) at java.lang.Thread.run(Thread.java:534) - Jim The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorized. If you are not an intended recipient, please notify the sender of this email immediately. You should not copy, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Capco. http://www.capco.com/ Any opinions expressed in this E-mail may be those of the individual and not necessarily the company. This E-mail and any files transmitted with it are confidential and solely for the use of the intended recipient. If you are not the intended recipient or the person responsible for delivering to the intended recipient, be advised that you have received this E-mail in error and that any use or copying is strictly prohibited. If you have received this E-mail in error please notify the beCogent postmaster at [EMAIL PROTECTED] Unless expressly stated, opinions in this email are those of the individual sender and not beCogent Ltd. You must take full responsibility for virus checking this email and any attachments. Please note that the content of this email or any of its attachments may contain data that falls within the scope of the Data Protection Acts and that you must ensure that any handling or processing of such data by you is fully compliant with the terms and provisions of the Data Protection Act 1984 and 1998. - To unsubscribe
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 org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP ool.java:683) at java.lang.Thread.run(Thread.java:534) - Jim The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorized. If you are not an intended recipient, please notify the sender of this email immediately. You should not copy, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Capco. http://www.capco.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat clustering and NotSerializableException
But do those session objects replicate to the other tomcat instances??? I have been testing session objects that implement java.io.serializable and I have not yet been able to see these objects when fail over occurs to another instance?? Thanks, Randall -Original Message- From: Richard Mixon (qwest) [mailto:[EMAIL PROTECTED] Sent: Monday, February 28, 2005 8:13 AM 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 org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP ool.java:683) at java.lang.Thread.run(Thread.java:534) - Jim The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorized. If you are not an intended recipient, please notify the sender of this email immediately. You should not copy, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Capco. http://www.capco.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
RE: Tomcat clustering and NotSerializableException
Randall, I know that session replication works in Tomcat 5.5.7 and it may also works in 5.0.x (no experience). But to get failover restart to work properly (i.e. restarting a failed node) I had to use Tomcat 5.5.7 with a developer-supplied patch. This patch will be available with Tomcat 5.5.8. HTH- Richard Randall Svancara wrote: But do those session objects replicate to the other tomcat instances??? I have been testing session objects that implement java.io.serializable and I have not yet been able to see these objects when fail over occurs to another instance?? Thanks, Randall -Original Message- From: Richard Mixon (qwest) [mailto:[EMAIL PROTECTED] Sent: Monday, February 28, 2005 8:13 AM 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 org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP ool.java:683) at java.lang.Thread.run(Thread.java:534) - Jim The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorized. If you are not an intended recipient, please notify the sender of this email immediately. You should not copy, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Capco. http://www.capco.com
RE: Tomcat clustering and NotSerializableException
ThanksI will look at 5.5.8. I know it is in alpha status right now, but I am just testing and by the time I deploy my application, 5.5.8 will probably be stable. Thanks Randall -Original Message- From: Richard Mixon (qwest) [mailto:[EMAIL PROTECTED] Sent: Monday, February 28, 2005 8:55 AM To: Tomcat Users List Subject: RE: Tomcat clustering and NotSerializableException Randall, I know that session replication works in Tomcat 5.5.7 and it may also works in 5.0.x (no experience). But to get failover restart to work properly (i.e. restarting a failed node) I had to use Tomcat 5.5.7 with a developer-supplied patch. This patch will be available with Tomcat 5.5.8. HTH- Richard Randall Svancara wrote: But do those session objects replicate to the other tomcat instances??? I have been testing session objects that implement java.io.serializable and I have not yet been able to see these objects when fail over occurs to another instance?? Thanks, Randall -Original Message- From: Richard Mixon (qwest) [mailto:[EMAIL PROTECTED] Sent: Monday, February 28, 2005 8:13 AM 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 org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP ool.java:683) at java.lang.Thread.run(Thread.java:534) - Jim The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorized
RE: Tomcat clustering and NotSerializableException
These objects will replicate to other instances when ALL objects in the session are serializable. I suspect that nothing will be replicated if there is non serializable objects in there. Ta Matt -Original Message- From: Randall Svancara [mailto:[EMAIL PROTECTED] Sent: 28 February 2005 15:14 To: Tomcat Users List Subject: RE: Tomcat clustering and NotSerializableException But do those session objects replicate to the other tomcat instances??? I have been testing session objects that implement java.io.serializable and I have not yet been able to see these objects when fail over occurs to another instance?? Thanks, Randall -Original Message- From: Richard Mixon (qwest) [mailto:[EMAIL PROTECTED] Sent: Monday, February 28, 2005 8:13 AM 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 org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP ool.java:683) at java.lang.Thread.run(Thread.java:534) - Jim The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorized. If you are not an intended recipient, please notify the sender of this email immediately. You should not copy, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Capco. http://www.capco.com
RE: Tomcat clustering and NotSerializableException
well apparently my problem is that my cluster is not working properly. I can see the multicast broadcast messages on my network, however the objects do not seem to be replicating. The only thing I have in my logs is: INFO: Manager[/testapp], skipping state transfer. No members active in cluster group. This displays after the delta manager starts in the catalina.out file. If anyone has any good ideas on why this is happening for me, I would be willing to try anything at this point. My NIC supports multicast. I have set the distributable element in the web.xml. Thanks, Randall -Original Message- From: Dale, Matt [mailto:[EMAIL PROTECTED] Sent: Monday, February 28, 2005 11:04 AM To: Tomcat Users List Subject: RE: Tomcat clustering and NotSerializableException These objects will replicate to other instances when ALL objects in the session are serializable. I suspect that nothing will be replicated if there is non serializable objects in there. Ta Matt -Original Message- From: Randall Svancara [mailto:[EMAIL PROTECTED] Sent: 28 February 2005 15:14 To: Tomcat Users List Subject: RE: Tomcat clustering and NotSerializableException But do those session objects replicate to the other tomcat instances??? I have been testing session objects that implement java.io.serializable and I have not yet been able to see these objects when fail over occurs to another instance?? Thanks, Randall -Original Message- From: Richard Mixon (qwest) [mailto:[EMAIL PROTECTED] Sent: Monday, February 28, 2005 8:13 AM 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
