[infinispan-issues] [JBoss JIRA] Updated: (ISPN-1106) Rehashing into a running cluster causes shared processing lock contention

Dan Berindei (JIRA) jira-events at lists.jboss.org
Wed Jun 1 05:21:01 EDT 2011


     [ https://issues.jboss.org/browse/ISPN-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dan Berindei updated ISPN-1106:
-------------------------------

              Status: Pull Request Sent  (was: Open)
    Git Pull Request: https://github.com/infinispan/infinispan/pull/353


Two commits:

1. NPE in JGroupsTransport.toJGroupsAddress

Ensure that JGroupsTransport populates the members list properly before doing allowing DistributionManagerImpl to start.
Ensure that DistributionManagerImpl doesn't attempt to use the consistent hash before it has initialized it.

2. Rehashing into a running cluster causes shared processing lock contention

* Block new transactions before updating the CH instead of after.
* Changed TransactionLoggerImpl to use a single ReentrantReadWriteLock instead of two gates, this will ensure we have no ongoing modifications during the RebalanceTask execution.
* Updated StaleTransactionCleanup to use the new TopologyChanged event to roll back invalid transactions (along with ViewChanged for replicated caches).
* ClusteredGetCommand should never do a remote get call.


> 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

        


More information about the infinispan-issues mailing list