Permalink
Commits on Feb 1, 2012
Commits on Nov 24, 2011
  1. ISPN-1550 fix typo

    mlinhard committed with maniksurtani Nov 24, 2011
Commits on Nov 3, 2011
  1. ISPN-1347 LIRS eviction not evicting correctly

    Rework LIRS according to ideas from fry@google.com (Charles Fry)
    vblagoje committed with maniksurtani Nov 2, 2011
Commits on Oct 21, 2011
  1. ISPN-1468: Upgrade to Spring 3.1.0.RC1

    - replace DefaultValueWrapper with ValueWrapperImpl (class renamed in Spring)
    mbogoevici committed Oct 21, 2011
  2. ISPN 1377, ISPN-1420: Upgrade to Spring 3.1.0.M2 & fix ConfigurationO…

    …verride to match Infinispan 5.1
    
    - abide by Spring 3.1 M2 Cache/CacheManager interfaces
    - replaced evictionWakeUpInterval with expirationWakeUpInterval (non-backwards compatible)
    mbogoevici committed Sep 12, 2011
Commits on Sep 26, 2011
  1. ISPN-1418 FileCacheStore.purgeInternal was trying to release the buck…

    …et lock even if it didn't acquire it.
    Dan Berindei committed with Sanne Sep 25, 2011
  2. ISPN-1417 Inefficient and unnecessary clearing of looked up entries w…

    …hen a context is reset
    maniksurtani committed Sep 26, 2011
Commits on Sep 14, 2011
Commits on Sep 9, 2011
  1. ISPN-1365 - Don't allow remote distributed tasks to start until the c…

    …ache has finished starting up
    Dan Berindei committed with galderz Sep 9, 2011
Commits on Sep 8, 2011
  1. ISPN-1343 - Don't send the commit command to all members that receive…

    …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.
    Dan Berindei committed with maniksurtani Sep 6, 2011
  2. ISPN-1343 - Stop waiting for a cache to start up in InboundInvocation…

    …HandlerImpl if the entire cache manager is stopping
    Dan Berindei committed with maniksurtani Sep 6, 2011
  3. ISPN-1123 - Log exceptions in tests before the @After methods that do…

    … the cleanup.
    Dan Berindei committed with maniksurtani Sep 6, 2011
  4. ISPN-1343 - Fixed the check if the previous rehash unblocked transact…

    …ions or not
    Dan Berindei committed with maniksurtani Sep 4, 2011
  5. ISPN-1343 - The retry queue processor was not waiting for the cache t…

    …o start properly
    
    This allowed an inbound command to start before the initial rehash even started.
    Dan Berindei committed with maniksurtani Sep 1, 2011
Commits on Sep 7, 2011
  1. ISPN-1375 - A transaction thread can fail to acquire the transaction …

    …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.
    Dan Berindei committed with maniksurtani Sep 5, 2011
  2. ISPN-1106 - Allow the users to start multiple caches at once

    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.
    Dan Berindei committed with maniksurtani Aug 5, 2011
  3. ISPN-1255 - Ongoing transactions waiting on locks are blocking the re…

    …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.
    Dan Berindei committed with maniksurtani Aug 3, 2011
  4. ISPN-1106 - Moved the lock cleanup back from the DataRehashed event t…

    …o the TopologyChanged event.
    Dan Berindei committed with maniksurtani Aug 2, 2011
  5. ISPN-1106 - Separated the rehash completion into two phases so Rebala…

    …nceTask can invalidate the keys after rehashing is done but before the cache listeners (e.g. KeyAffinityService) know it.
    Dan Berindei committed with maniksurtani Aug 2, 2011
  6. ISPN-1106 - Log more information about locks and rehashing

    * 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.
    Dan Berindei committed with maniksurtani Aug 3, 2011
  7. ISPN-1123 - Fixed some more mismatched test names

    Fixed mismatchedTestNames.sh script.
    Dan Berindei committed with maniksurtani Aug 2, 2011
  8. ISPN-1123 - Some tests were creating a non-default cache but then the…

    …y were waiting for the default cache to finish rehashing.
    Dan Berindei committed with maniksurtani Aug 2, 2011
Commits on Aug 8, 2011
  1. Fix broken build

    maniksurtani committed Aug 8, 2011
Commits on Aug 5, 2011
  1. ISPN-1170 - If the number of joiners >= numOwners the owner sets befo…

    …re and after rehash can be disjoint
    Dan Berindei committed with maniksurtani Aug 3, 2011
  2. ISPN-1123 - log locks

    Dan Berindei committed with maniksurtani Aug 3, 2011
  3. ISPN-1106 - fixed resend for commit

    Dan Berindei committed with maniksurtani Aug 3, 2011
  4. ISPN-1106 - Ensure commits succeed even if a rehash started on the re…

    …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.
    Dan Berindei committed with maniksurtani Aug 3, 2011