[
https://issues.jboss.org/browse/ISPN-1106?page=com.atlassian.jira.plugin....
]
Erik Salter commented on ISPN-1106:
-----------------------------------
Good to hear.
I'm a little concerned about the JGroups usage. I used TCP in production since my
DIST node cluster was going to be < 100 nodes, per the wiki
(
http://community.jboss.org/wiki/ClusteredConfigurationQuickStart). Do you think the wiki
may need to have more detail about using JGroups in these high-throughput situations?
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
Fix For: 5.0.0.CR4
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