You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by LERBSCHER JEAN-PIERRE <jl...@hotmail.com> on 2008/01/18 18:08:08 UTC
ConcurrentModificationException on tomcat cluster with
SimpleTcpCluster strategy
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=xxxxxxxxx
worker.asur.port=8009
worker.asur.type=ajp13
worker.asur.lbfactor=1
worker.asur.activation=disabled
worker.asmar.host=xxxxxxx
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: ConcurrentModificationException on tomcat cluster with SimpleTcpClusterstrategy
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Caldarale, Charles R wrote:
>> From: Filip Hanik - Dev Lists [mailto:devlists@hanik.com]
>> Subject: Re: ConcurrentModificationException on tomcat
>> cluster with SimpleTcpClusterstrategy
>>
>> that is correct, we thought of this scenario and decided that we
>> wouldn't support it.
>>
>
> Not unreasonable to avoid the performance hit for the 99% usual cases.
>
> However, I'd still like to know what triggers the session replication
> across the nodes of the cluster. If it's some particular set of API
> calls (e.g., closing the output stream), then it might be possible for
> applications that need it to synchronize their own behavior with regards
> to the session, and not run the risk of interfering with the
> replication.
>
hey Chuck,
quite simple. Replication is triggered by the "ReplicationValve", ie
when the request is complete (complete defined/interpreted by the
servlet API as the thread backing out-in Tomcat's API this is when the
invoke method to the
next valve down the chain is complete) the changes in the session are
then extract through a diff based on setAttribute/removeAttribute events
and are propagated.
removeAttribute events are propagated as events, not serialized data, so
the same remove happens on the other nodes.
Filip
> - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you
> received this in error, please contact the sender and delete the e-mail
> and its attachments from all computers.
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: ConcurrentModificationException on tomcat cluster with SimpleTcpClusterstrategy
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Filip Hanik - Dev Lists [mailto:devlists@hanik.com]
> Subject: Re: ConcurrentModificationException on tomcat
> cluster with SimpleTcpClusterstrategy
>
> that is correct, we thought of this scenario and decided that we
> wouldn't support it.
Not unreasonable to avoid the performance hit for the 99% usual cases.
However, I'd still like to know what triggers the session replication
across the nodes of the cluster. If it's some particular set of API
calls (e.g., closing the output stream), then it might be possible for
applications that need it to synchronize their own behavior with regards
to the session, and not run the risk of interfering with the
replication.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: ConcurrentModificationException on tomcat cluster with SimpleTcpClusterstrategy
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Caldarale, Charles R wrote:
>> From: Filip Hanik - Dev Lists [mailto:devlists@hanik.com]
>> Subject: Re: ConcurrentModificationException on tomcat
>> cluster with SimpleTcpClusterstrategy
>>
>> given that the session should represent a client state,
>> and by the time the cluster tries to serialize it, the
>> request is over.
>>
>
> That ignores the situation where multiple requests from the same client
> are being processed concurrently. What are the conditions that provoke
> replication (and therefore serialization)? What mechanism is provided
> for request processors to synchronize with the replicator?
>
that is correct, we thought of this scenario and decided that we
wouldn't support it.
the problem with the scenario above is not only that the same client can
have multiple requests, it can have multiple requests hitting different
nodes in the cluster.
this would require implement distributed locking and there is no way of
doing that without suffering too much of a performance degradation.
Filip
> - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you
> received this in error, please contact the sender and delete the e-mail
> and its attachments from all computers.
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: ConcurrentModificationException on tomcat cluster with SimpleTcpClusterstrategy
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Filip Hanik - Dev Lists [mailto:devlists@hanik.com]
> Subject: Re: ConcurrentModificationException on tomcat
> cluster with SimpleTcpClusterstrategy
>
> given that the session should represent a client state,
> and by the time the cluster tries to serialize it, the
> request is over.
That ignores the situation where multiple requests from the same client
are being processed concurrently. What are the conditions that provoke
replication (and therefore serialization)? What mechanism is provided
for request processors to synchronize with the replicator?
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: ConcurrentModificationException on tomcat cluster with SimpleTcpCluster
strategy
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: ConcurrentModificationException on tomcat cluster with SimpleTcpCluster
strategy
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: ConcurrentModificationException on tomcat cluster with SimpleTcpCluster
strategy
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: ConcurrentModificationException on tomcat cluster with SimpleTcpCluster
strategy
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: ConcurrentModificationException on tomcat cluster with SimpleTcpCluster
strategy
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: ConcurrentModificationException on tomcat cluster with SimpleTcpCluster
strategy
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: ConcurrentModificationException on tomcat cluster with SimpleTcpCluster
strategy
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: ConcurrentModificationException on tomcat cluster with SimpleTcpCluster
strategy
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: ConcurrentModificationException on tomcat cluster with SimpleTcpCluster
strategy
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: ConcurrentModificationException on tomcat cluster with SimpleTcpCluster
strategy
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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=xxxxxxxxx
> worker.asur.port=8009
> worker.asur.type=ajp13
> worker.asur.lbfactor=1
> worker.asur.activation=disabled
>
> worker.asmar.host=xxxxxxx
> 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: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org