Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Commits on Sep 12, 2011
  1. @galderz
Commits on Sep 9, 2011
  1. @galderz

    ISPN-1365 - Don't allow remote distributed tasks to start until the c…

    Dan Berindei authored galderz committed
    …ache has finished starting up
Commits on Sep 8, 2011
  1. @maniksurtani

    ISPN-1343 - Don't send the commit command to all members that receive…

    Dan Berindei authored maniksurtani committed
    …d the prepare command, since they could have already left the cluster.
    
    JGroups will wait for the response message until the timeout replication expires, while holding the locks for the modified keys. So other transactions could time out waiting for our locks.
  2. @maniksurtani

    ISPN-1343 - Stop waiting for a cache to start up in InboundInvocation…

    Dan Berindei authored maniksurtani committed
    …HandlerImpl if the entire cache manager is stopping
  3. @maniksurtani

    ISPN-1123 - Log exceptions in tests before the @After methods that do…

    Dan Berindei authored maniksurtani committed
    … the cleanup.
  4. @maniksurtani

    ISPN-1343 - Fixed the check if the previous rehash unblocked transact…

    Dan Berindei authored maniksurtani committed
    …ions or not
  5. @maniksurtani

    ISPN-1343 - The retry queue processor was not waiting for the cache t…

    Dan Berindei authored maniksurtani committed
    …o start properly
    
    This allowed an inbound command to start before the initial rehash even started.
Commits on Sep 7, 2011
  1. @maniksurtani

    ISPN-1375 - A transaction thread can fail to acquire the transaction …

    Dan Berindei authored maniksurtani committed
    …logger lock even if the latch was open
    
    Sometimes the rehasher can acquire the write lock after a transaction thread has called latch.await() but before readLock.lock(). If that happens we need to retry the lock acquisition in the transaction thread.
  2. @maniksurtani

    ISPN-1106 - Allow the users to start multiple caches at once

    Dan Berindei authored maniksurtani committed
    This is no longer strictly necessary for ISPN-1106, as we are waiting
    with a shorter timeout on transactions with locks and so the rehash
    does not block for a very long period of time.
    
    It is recommended however to start all caches on application startup,
    and this method provides an easy way for users to start all their caches.
  3. @maniksurtani

    ISPN-1255 - Ongoing transactions waiting on locks are blocking the re…

    Dan Berindei authored maniksurtani committed
    …hash from finishing
    
    The generic scenario involves multiple caches.
    Say we have transactions Tx1 and Tx2 spanning caches C1 and C2.
    A new node joins the cluster, starting C1 and C2.
    With the following sequence of events rehashing will be blocked for lockAcquisitionTimeout.
    
    1. Tx1 prepares on C1 locking K1
    2. Tx2 wants to prepare on C2, Tx2 gets the tx lock
    3. Tx2 now waits to lock K1 while holding the tx lock on C2
    4. Rehash starts on C2 but it can't proceed because Tx2 has the tx lock
    5. Tx1 now wants to prepare on C2, but can't acquire the tx lock
    
    I've implemented a crude "deadlock detection" scheme: a new tx will wait
    the full lockAcquisitionTimeout for the tx lock, but a tx that already
    has locks acquired will only wait 1/100 of that. So if there is a cycle
    it will break much quicker and allow rehashing to proceed.
    
    There is also a simpler variant where the transactions work with a single cache.
    In that case if the remote command can't acquire the tx lock with 0 timeout it knows
    that it has the tx lock on the origin node and it's in a deadlock situation.
  4. @maniksurtani

    ISPN-1106 - Moved the lock cleanup back from the DataRehashed event t…

    Dan Berindei authored maniksurtani committed
    …o the TopologyChanged event.
  5. @maniksurtani

    ISPN-1106 - Separated the rehash completion into two phases so Rebala…

    Dan Berindei authored maniksurtani committed
    …nceTask can invalidate the keys after rehashing is done but before the cache listeners (e.g. KeyAffinityService) know it.
  6. @maniksurtani

    ISPN-1106 - Fixed an error in the LockControlCommand constructor.

    Dan Berindei authored maniksurtani committed
  7. @maniksurtani

    ISPN-1106 - Log more information about locks and rehashing

    Dan Berindei authored maniksurtani committed
    * In LockManagerImpl log the other keys owned by the current transaction.
    * In DefaultCacheManager push the cache name to the NDC during cache startup.
    * Improved toString() for RehashControlCommand and DistributedExecuteCommand.
    * In InboundInvocationHandler log the cache name.
    * Log cache start/stop.
    * Log the read lock owners in JGroupsDistSync.
  8. @maniksurtani

    ISPN-1123 - Fixed some more mismatched test names

    Dan Berindei authored maniksurtani committed
    Fixed mismatchedTestNames.sh script.
  9. @maniksurtani

    ISPN-1123 - Some tests were creating a non-default cache but then the…

    Dan Berindei authored maniksurtani committed
    …y were waiting for the default cache to finish rehashing.
  10. @mlinhard @maniksurtani
  11. @rhusar @maniksurtani
  12. @Sanne @maniksurtani
Commits on Aug 8, 2011
  1. @maniksurtani

    Fix broken build

    maniksurtani authored
  2. @Sanne @maniksurtani
  3. @maniksurtani
Commits on Aug 5, 2011
  1. @maniksurtani

    ISPN-1170 - If the number of joiners >= numOwners the owner sets befo…

    Dan Berindei authored maniksurtani committed
    …re and after rehash can be disjoint
  2. @maniksurtani

    ISPN-1123 - log locks

    Dan Berindei authored maniksurtani committed
  3. @maniksurtani

    ISPN-1106 - fixed resend for commit

    Dan Berindei authored maniksurtani committed
  4. @maniksurtani

    ISPN-1106 - cleanup locks on any exception, not just timeouts

    Dan Berindei authored maniksurtani committed
  5. @maniksurtani

    ISPN-1106 - Ensure commits succeed even if a rehash started on the re…

    Dan Berindei authored maniksurtani committed
    …mote nodes
    
    If a rehash started on a remote node, and we're already holding the lock on the origin there's a potential for deadlock.
    So we unlock the tx lock to allow rehash to progress on the local node and retry all the remote calls.
  6. @maniksurtani

    ISPN-1106 - Log the currently held locks when lock acquisition fails

    Dan Berindei authored maniksurtani committed
  7. @maniksurtani

    ISPN-1123 - SyncReplImplicitLockingTest: Allow more time for the time…

    Dan Berindei authored maniksurtani committed
    …out to kick in
  8. @maniksurtani

    ISPN-1123 - Make the joins really concurrent in ConcurrentJoinTest

    Dan Berindei authored maniksurtani committed
  9. @maniksurtani

    ISPN-1123 - rehashtestbase should let waitforrehashcompletion do all …

    Dan Berindei authored maniksurtani committed
    …the waiting
  10. @maniksurtani

    ISPN-1123 - Fixed mismatched test names

    Dan Berindei authored maniksurtani committed
  11. @maniksurtani

    ISPN-1123 - fixed waiting for new views in rehash tests

    Dan Berindei authored maniksurtani committed
  12. @maniksurtani

    ISPN-1106/1123 - better logging

    Dan Berindei authored maniksurtani committed
  13. @maniksurtani

    ISPN-1123 - Waiting for rehashing to finish is not enough, we must en…

    Dan Berindei authored maniksurtani committed
    …sure that we also got the updated views
Something went wrong with that request. Please try again.