[infinispan-issues] [JBoss JIRA] Commented: (ISPN-1106) Rehashing into a running cluster causes shared processing lock contention
[
https://issues.jboss.org/browse/ISPN-1106?page=com.atlassian.jira.plugin....
]
Dan Berindei commented on ISPN-1106:
------------------------------------
The cache probably became unusable because of the NPE in JGroupsTransport. The transaction
cleanup was broken after ISPN-1000, and I had to make some changes to the transaction
logger to ensure modifications are blocked *before* they happen.
Even after these fixes the attached test case still got a lot of errors in the distributed
executor because a new node would get a lot of requests while still starting up (the old
nodes would update their CH the moment they saw the new node). I changed the configuration
to use the jgroups-udp.xml JGroups configuration supplied with Infinispan and the cache
startup got a lot faster, so I'm not seeing any errors any more. I think it was
because the timeouts in the test's udp.xml configuration were too high.
Rehashing into a running cluster causes shared processing lock
contention
-------------------------------------------------------------------------
Key: ISPN-1106
URL: https://issues.jboss.org/browse/ISPN-1106
Project: Infinispan
Issue Type: Bug
Affects Versions: 5.0.0.CR2
Reporter: Erik Salter
Assignee: Dan Berindei
Attachments: cacheTest.zip
On our initial test of 5.0.0.CR2, we wanted to test the cluster's rehashing
behavior/performance and if all locks were cleaned up.
The test was to start two nodes, then add a third node, all the while issuing commands to
it.
Upon adding a third node, the cluster becomes inoperable. The stack traces is in the
following location:
http://dl.dropbox.com/u/10929737/5.0.0.CR2/server_node1.log,
http://dl.dropbox.com/u/10929737/5.0.0.CR2/server_node2.log,
http://dl.dropbox.com/u/10929737/5.0.0.CR2/server_node3.log
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira