1. 21 Feb, 2019 4 commits
  2. 20 Feb, 2019 1 commit
  3. 18 Feb, 2019 1 commit
  4. 01 Feb, 2019 1 commit
  5. 18 Dec, 2018 2 commits
  6. 14 Dec, 2018 2 commits
  7. 21 Nov, 2018 1 commit
  8. 14 Nov, 2018 1 commit
  9. 15 Oct, 2018 2 commits
  10. 10 Oct, 2018 3 commits
  11. 08 Oct, 2018 1 commit
  12. 04 Oct, 2018 3 commits
  13. 18 Sep, 2018 1 commit
  14. 27 Aug, 2018 2 commits
  15. 22 Aug, 2018 2 commits
  16. 16 Aug, 2018 3 commits
  17. 26 Jun, 2018 1 commit
  18. 11 Jun, 2018 2 commits
  19. 29 May, 2018 2 commits
  20. 28 May, 2018 1 commit
  21. 09 May, 2018 1 commit
  22. 07 May, 2018 2 commits
    • Peter Centgraf's avatar
      REPO-2012 Update tika to 1.18 · 7e68f584
      Peter Centgraf authored
      7e68f584
    • Ard Schrijvers's avatar
      REPO-2007 [Backport 11.2] Reset invalid RUNNING locks to free when a cluster node starts · a8536671
      Ard Schrijvers authored
      If a cluster node (say 'node1') starts and it finds locks in the lock
      table that are for 'node1', it means that the cluster node did not release
      all its locks during shutdown (graceful or ungraceful) and it did come
      up again before other cluster nodes had reset the lock to FREE because
      the lock did not yet reach its expiration time (or there were no other
      cluster nodes).
      In normal situations the DbResetExpiredLocksJanitor takes care of freeing
      expired locks, for example locks that belonged to a shut down cluster
      node. But in the scenario above, the DbResetExpiredLocksJanitor did not
      yet free the locks, resulting in
      org.onehippo.repository.lock.db.DbLockManager#createLock not allowing the
      lock to be created BUT the DbLockRefresher starts refreshing the database
      lock nonetheless, hence, no thread in any cluster node can reclaim the
      lock any more.
      A solution could be that the DbLockRefresher only refreshes locks that
      are present in the
      org.onehippo.repository.lock.AbstractLockManager#localLocks object.
      However that would make the refresh statement complexer, so instead,
      during start up now invalid live locks are reset.
      
      (cherry picked from commit 2fdd5458ae3439092b58b7febb380f69057fca7f)
      a8536671
  23. 24 Apr, 2018 1 commit