Re: ConcurrentModificationException on tomcat cluster with SimpleTcpCluster strategy
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Filip, Filip Hanik - Dev Lists wrote: | no, its just common sense, given that the session should represent a | client state, | and by the time the cluster tries to serialize it, the request is over. There's no guarantee that the request is complete before session changes are replicated, is there? In that case, you can never manipulate any collection you put into the session. If you want to change something, you have to first remove it from the session, then change it, then put it back. In fact, you still are not covered, because removing the object from the session merely removes the reference. If the session replicator is running and copying, say, a Map to another machine in the cluster, you can't even remove it from the session in order to modify it: you /must/ make a copy of it and work on the copy. That's ridiculous IMHO. read the source code and enlighten yourself instead of making assumptions and making comments like that. | developers misuse sessions all the time, I would add this into that | category. Of course they do, but modifying a collection that's in the session while the replicator just happens to be trying to serialize the session is simply unreasonable to prevent. | one can use a technology like terracotta that handles replication | completely separate from the request flow, and at the field level. | that technology doesn't suffer from the problem described above I'm not sure it would... iterating over a collection (which I assume is what the session replicator is doing) while another thread (a request) is making legitimate changes to it would lead to a CME no matter what replication technology is being used. even terracotta is open source, read the source code there, and correct yourself Filip - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkeXsiMACgkQ9CaO5/Lv0PBfmgCcCFnKujLG269RQ+y/vqyPTBMB sVQAn1z1mIrDf92g0UsFKeKgH/etyY3F =MCCh -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ConcurrentModificationException on tomcat cluster with SimpleTcpCluster strategy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Filip, Filip Hanik - Dev Lists wrote: | In fact, you still are not covered, because removing the object from the | session merely removes the reference. If the session replicator is | running and copying, say, a Map to another machine in the cluster, you | can't even remove it from the session in order to modify it: you /must/ | make a copy of it and work on the copy. | | That's ridiculous IMHO. | | read the source code and enlighten yourself instead of making | assumptions and making comments like that. Thanks for the condescending attitude, dude. I appreciate it. Which source code do you suggest? | I'm not sure it would... iterating over a collection (which I assume is | what the session replicator is doing) while another thread (a request) | is making legitimate changes to it would lead to a CME no matter what | replication technology is being used. | | even terracotta is open source, read the source code there, and correct | yourself I'm not interested in terracotta. I'm interested in how Tomcat reacts. The OP said that it was blowing up. I'm positive it was his code doing the concurrent modification of the Map. That's not the problem. From your comments, it seems like you aren't allowed to modify any collections in the session for fear of interfering with the replicator. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkeZCXIACgkQ9CaO5/Lv0PBYQQCePVmHM8SVwBLM2f1ALDdcSXaM aucAnjgViqbZA0GnIpCuhYntUx9v2OTw =kVv9 -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ConcurrentModificationException on tomcat cluster with SimpleTcpCluster strategy
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Filip, Filip Hanik - Dev Lists wrote: | if you look at the stack trace, there is no error in the clustering | code. something is modifying your session attribute while the cluster is | trying to send it I'm suggesting that this should not be considered an error: there's nothing in the API or servlet spec that says you can't modify an object as it sits in the session. no, its just common sense, given that the session should represent a client state, and by the time the cluster tries to serialize it, the request is over. developers misuse sessions all the time, I would add this into that category. While I would not consider this a bug in Tomcat, the fact remains that there is no reasonable way to protect against this (save working on a separate copy of the object and then replacing the one in the session). one can use a technology like terracotta that handles replication completely separate from the request flow, and at the field level. that technology doesn't suffer from the problem described above Filip - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ConcurrentModificationException on tomcat cluster with SimpleTcpCluster strategy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Filip, Filip Hanik - Dev Lists wrote: | no, its just common sense, given that the session should represent a | client state, | and by the time the cluster tries to serialize it, the request is over. There's no guarantee that the request is complete before session changes are replicated, is there? In that case, you can never manipulate any collection you put into the session. If you want to change something, you have to first remove it from the session, then change it, then put it back. In fact, you still are not covered, because removing the object from the session merely removes the reference. If the session replicator is running and copying, say, a Map to another machine in the cluster, you can't even remove it from the session in order to modify it: you /must/ make a copy of it and work on the copy. That's ridiculous IMHO. | developers misuse sessions all the time, I would add this into that | category. Of course they do, but modifying a collection that's in the session while the replicator just happens to be trying to serialize the session is simply unreasonable to prevent. | one can use a technology like terracotta that handles replication | completely separate from the request flow, and at the field level. | that technology doesn't suffer from the problem described above I'm not sure it would... iterating over a collection (which I assume is what the session replicator is doing) while another thread (a request) is making legitimate changes to it would lead to a CME no matter what replication technology is being used. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkeXsiMACgkQ9CaO5/Lv0PBfmgCcCFnKujLG269RQ+y/vqyPTBMB sVQAn1z1mIrDf92g0UsFKeKgH/etyY3F =MCCh -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ConcurrentModificationException on tomcat cluster with SimpleTcpCluster strategy
if you look at the stack trace, there is no error in the clustering code. something is modifying your session attribute while the cluster is trying to send it Filip Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Filip, Filip Hanik - Dev Lists wrote: | the solution is to not store stuff in the session modified by other | threads, if that's the case, then its not really something you wanna | store in a session What's wrong with modifying something in a session? It's not being modified by other threads... it's being modified by request-handling threads. The only synchronization issue is that the replication code basically needs to take a snapshot of the session, but that's not possible because there is no standard way to do it. I suppose if you have to modify something in the session, you can copy-and-modify and then put it back... but that's not very efficient. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkeUs58ACgkQ9CaO5/Lv0PC0+gCgkJ4m+eEoozj6fFth0KIE+tC+ mYEAn0oYsxUCiFoGxA7U2Ub+aWE/NcBX =YrnX -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ConcurrentModificationException on tomcat cluster with SimpleTcpCluster strategy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Filip, Filip Hanik - Dev Lists wrote: | if you look at the stack trace, there is no error in the clustering | code. something is modifying your session attribute while the cluster is | trying to send it I'm suggesting that this should not be considered an error: there's nothing in the API or servlet spec that says you can't modify an object as it sits in the session. While I would not consider this a bug in Tomcat, the fact remains that there is no reasonable way to protect against this (save working on a separate copy of the object and then replacing the one in the session). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkeWjO8ACgkQ9CaO5/Lv0PCKLQCgvrBiJngd5J8cbjAufcCNOCz3 R/gAoJX2MR3pwVF2Ziw6+RsVnCVJzmFe =j+bL -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ConcurrentModificationException on tomcat cluster with SimpleTcpCluster strategy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Filip, Filip Hanik - Dev Lists wrote: | the solution is to not store stuff in the session modified by other | threads, if that's the case, then its not really something you wanna | store in a session What's wrong with modifying something in a session? It's not being modified by other threads... it's being modified by request-handling threads. The only synchronization issue is that the replication code basically needs to take a snapshot of the session, but that's not possible because there is no standard way to do it. I suppose if you have to modify something in the session, you can copy-and-modify and then put it back... but that's not very efficient. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkeUs58ACgkQ9CaO5/Lv0PC0+gCgkJ4m+eEoozj6fFth0KIE+tC+ mYEAn0oYsxUCiFoGxA7U2Ub+aWE/NcBX =YrnX -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ConcurrentModificationException on tomcat cluster with SimpleTcpCluster strategy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Filip, Filip Hanik - Dev Lists wrote: | this is not a cluster error, basically, you are storing a map in the | session, and someone is modifying the map while the cluster is trying to | replicate it How should this be solved? The OP could really only synchronize his own code against either an external monitor, or the Map itself. On the other hand, how should the application's code interact with the cluster replication code to avoid such concurrent modifications? Does the servlet spec provide a mechanism to protect session replication against this? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkeRKeYACgkQ9CaO5/Lv0PAF5ACeIlYZAami/vJv8q4DJsOuCl0G v20AoK2+svEmZuyZMJd16P7N8PIfnfMJ =mTNL -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ConcurrentModificationException on tomcat cluster with SimpleTcpCluster strategy
this is not a cluster error, basically, you are storing a map in the session, and someone is modifying the map while the cluster is trying to replicate it org.apache.commons.collections.LRUMap Filip LERBSCHER JEAN-PIERRE wrote: Hi, We work on Tomcat clustered server (5.5) and we have this exception in the log (at 5-10 TPS). Could you explain us what's hapenning. Have you a solution? Thanks. Exception: SEVERE: Failed to serialize the session! java.util.ConcurrentModificationException at org.apache.commons.collections.SequencedHashMap$OrderedIterator.next(SequencedHashMap.java:757) at org.apache.commons.collections.LRUMap.writeExternal(LRUMap.java:174) at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1310) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1288) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302) at org.apache.catalina.session.StandardSession.writeObject(StandardSession.java:1478) at org.apache.catalina.session.StandardSession.writeObjectData(StandardSession.java:948) at org.apache.catalina.cluster.session.ReplicatedSession.writeObjectData(ReplicatedSession.java:189) at org.apache.catalina.cluster.session.SimpleTcpReplicationManager.writeSession(SimpleTcpReplicationM anager.java:353) at org.apache.catalina.cluster.session.SimpleTcpReplicationManager.requestCompleted(SimpleTcpReplicat ionManager.java:317) at org.apache.catalina.cluster.tcp.ReplicationValve.send(ReplicationValve.java:549) at org.apache.catalina.cluster.tcp.ReplicationValve.sendMessage(ReplicationValve.java:536) at org.apache.catalina.cluster.tcp.ReplicationValve.sendSessionReplicationMessage(ReplicationValve.ja va:518) at org.apache.catalina.cluster.tcp.ReplicationValve.sendReplicationMessage(ReplicationValve.java:428) at org.apache.catalina.cluster.tcp.ReplicationValve.invoke(ReplicationValve.java:362) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:200) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:773) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:703) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:895) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Thread.java:595) Env: Tomcat Version 5.5.25 Platform OS Linux xxx 2.6.9-67.ELsmp #1 SMP Wed Nov 7 13:56:44 EST 2007 x86_64 x86_64 x86_64 GNU/Linux JVM : java version 1.5.0_12 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) BEA JRockit(R) (build R27.4.0-90-89592-1.5.0_12-20070928-1715-linux-x86_64, compiled mode) Web Server Apache 2.0.59 and mod_jk-1.2.25 Apache jk/worker conf: -- worker.list=balancer worker.balancer.type=lb worker.balancer.balance_workers=asur,asmar worker.balancer.sticky_session=1 worker.asur.host=x worker.asur.port=8009 worker.asur.type=ajp13 worker.asur.lbfactor=1 worker.asur.activation=disabled worker.asmar.host=xxx worker.asmar.port=8009 worker.asmar.type=ajp13 worker.asmar.lbfactor=1 worker.asmar.redirect=asur Cluster configuration: -- _ Microsoft vous offre un logiciel pour classer, retoucher et partager vos photos ! http://www.windowslive.fr/galerie/ - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ConcurrentModificationException on tomcat cluster with SimpleTcpCluster strategy
the solution is to not store stuff in the session modified by other threads, if that's the case, then its not really something you wanna store in a session Filip Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Filip, Filip Hanik - Dev Lists wrote: | this is not a cluster error, basically, you are storing a map in the | session, and someone is modifying the map while the cluster is trying to | replicate it How should this be solved? The OP could really only synchronize his own code against either an external monitor, or the Map itself. On the other hand, how should the application's code interact with the cluster replication code to avoid such concurrent modifications? Does the servlet spec provide a mechanism to protect session replication against this? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkeRKeYACgkQ9CaO5/Lv0PAF5ACeIlYZAami/vJv8q4DJsOuCl0G v20AoK2+svEmZuyZMJd16P7N8PIfnfMJ =mTNL -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]