I agree, that running with only one node in the cluster shouldn't require "sticky
sessions=true".
When we do run with more than one cluster node, we need to enable "sticky
sessions" to avoid multiple http session attribute changes (to the same http session
attribute) coming from different nodes (at the same time).
Thank you for explaining this part of the problem. Of course, it goes deeper than not
configuring the http load-balancer (please always enable "sticky http sessions"
:-)
anonymous wrote : The problem as it seems to be is the web session gets modified while it
is been serialized. Specifically the serialization of an org.ajax4jsf.util.LRUMap instance
holding some JSF(?) state is failing with ConcurrentModificationException, so I've
first thought it could be a RichFaces library problem.
From your description of the problem, it sounds like the following
events have occurred:
An HTTP request is received for user Sharon, during the processing of this request (R1),
an HTTP session attribute change is made. As part of the HTTP processing after request
processing, we attempt to replicate the attribute change. Meanwhile, another HTTP request
(R2) for user Sharon was also processed that generated an HTTP session attribute change.
As part of R2 processing, the same attribute change was transmitted (from a different HTTP
client service thread) and applied to the collection (while the R1 client request handling
thread is iterating through the collection).
The java.util.ConcurrentModificationException occurs when iterating through the
collection, while another thread modifies the collection.
Before we discuss possible solutions, lets see if we agree on the above. If I am not
stating things correctly above, please explain your understanding of what is happening.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4239560#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...