You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Caldarale, Charles R" <Ch...@unisys.com> on 2008/01/23 23:33:51 UTC
RE: ConcurrentModificationException on tomcat cluster with SimpleTcpClusterstrategy
> 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 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