1. 25 Jan, 2018 2 commits
  2. 23 Jan, 2018 1 commit
  3. 16 Jan, 2018 2 commits
  4. 03 Jan, 2018 3 commits
  5. 04 Dec, 2017 2 commits
  6. 23 Nov, 2017 3 commits
  7. 16 Nov, 2017 4 commits
  8. 13 Nov, 2017 3 commits
  9. 07 Nov, 2017 1 commit
  10. 03 Nov, 2017 4 commits
    • Ate Douma's avatar
      REPO-1881: [Backport 11.2] load HippoEnterpriseRepository instead of... · a70298c4
      Ate Douma authored
      REPO-1881: [Backport 11.2] load HippoEnterpriseRepository instead of LocalHippoRepository, if available
      
        (cherry picked from commit b07f4308)
        (cherry picked from commit 6c3b3782)
        (cherry picked from commit 79148a61)
      a70298c4
    • Ate Douma's avatar
      REPO-1881 [Backport 11.2] Implement new LockManager service and replace all... · b05161a4
      Ate Douma authored
      REPO-1881 [Backport 11.2] Implement new LockManager service and replace all deprecated HippoLock and HippoLockManager usages
      
      This is a cherry-picked and squashed backport from REPO-1811, REPO-1873, REPO-1874 and REPO-1875:
      
        REPO-1811 Implement in-memory lock manager
      
          (cherry picked from commit dfa6f279)
      
        REPO-1811 To the RepositoryImpl add a Journal ConnectionHelper accessor
      
          Via this Journal ConnectionHelper we can access the Journal DataSource
          via the ConnectionHelperDataSourceAccessor.
      
          Admittedly, a bit clumsy but we need access to the Journal DataSource
          because we need to know whether we are dealing with a database *and*
          whether we have a clustered setup : Only in that case, the lock mechanism
          has to be upgraded from in memory locking to db base locking because
          needs to be cluster wide
      
          (cherry picked from commit 4750450f)
      
        REPO-1811 Support for a Database lock manager
      
          The Database lock manager interaction is pretty much exactly the same
          as the MemoryLockManager interaction. The biggest difference is that
          the DbLockManager creates database based locks and the MemoryLockManager
          creates MemoryLocks. Note that a DbLock is the same as the MemoryLock
          but only contains a #destroy implementation that releases the database
          lock.
      
          The DbLockManager is still work in progress
      
          (cherry picked from commit e0f19fab)
      
        REPO-1811 Fix the LockClusterTest setup
      
          (still ignored but the setup failed since we do not allow SNS
          below jcr:root any more)
      
          (cherry picked from commit 1dba0d49)
      
        REPO-1811 Support database locking
      
          (cherry picked from commit 92c914ef)
      
        REPO-1811 Support background jobs in the Memory or Db LockManager
      
          - All the background jobs are run by a single thread
          - By default they run every 5 seconds with an initial delay of 5 seconds
          - Every background job is wrapped in a 'synchronized runnable' the synchronized
            on the LockManager instance: The reason for this is that we do not want
            background jobs to write concurrently to possibly the same records as
            other (background) jobs
          - We have the following background jobs:
            1) UnlockStoppedThreadJanitor : releases database locks for records
               that were held by a thread that is not alive any more
            2) DbResetExpiredLocksJanitor : Resets all database rows which have
               expired locks (rows with status 'RUNNING' or 'ABORT' and expirationTime
               has passed
            3) DbLockRefresher: Refreshes the expiresTime of a lock to currentTime + refreshRateSeconds
            4) LockThreadInterrupter : Interrupts the Thread that holds the lock that has been marked 'ABORT'
      
          (cherry picked from commit cbf14aed)
      
        REPO-1811 Make sure getLocks and isLocked works cluster wide in case of a database
      
          (cherry picked from commit 441beff4)
      
        REPO-1811 Fix sql statement
      
          (cherry picked from commit d3d25849)
      
        REPO-1811 Extract abstract test and add an 'abort' test
      
          (cherry picked from commit 5ab1e55f)
      
        REPO-1811 use getHoldCount() instead of protected access
      
          (cherry picked from commit 7027fce3)
      
        REPO-1811 improve feedback
      
          (cherry picked from commit 0bf87cb5)
      
        REPO-1811 use getHoldCount() instead of protected access
      
          (cherry picked from commit a268b5e6)
      
        REPO-1811 Fix abort statement
      
          (cherry picked from commit dac8d9cc)
      
        REPO-1811 Encapsulate the localLocks object
      
          Since localLocks is a hashmap, all access to it should be synchronized.
          This can be easier achieved by encapsulating it and whenever needed by
          other classes, return a new object containing the same locks
      
          (cherry picked from commit cc3e10d9)
      
        REPO-1811 Enhance abort tests
      
          (cherry picked from commit 43f17029)
      
        REPO-1811 use auto closable in integration tests
      
          (cherry picked from commit 05143edd)
      
        REPO-1811 Correct the expiresTime parameter
      
          (cherry picked from commit 62bd68c2)
      
        REPO-1811 Locks in status ABORT should also be refreshed
      
          Namely if a lock is in status ABORT and the lock is for the *CLUSTER NODE*
          on which the DbLockRefresher runs, then it means that on this cluster
          node the Thread that should be aborted did not yet abort (for example
          still busy with its job). All we can do is wait until that job finishes
      
          (cherry picked from commit f038ec5b)
      
        REPO-1811 remove unneeded auto commit
      
          (cherry picked from commit 591ff099)
      
        REPO-1811 If a Thread is already interrupted, don't interrupt again
      
          (cherry picked from commit 8a6b58b3)
      
        REPO-1811 Integration tests that confirm the correct working of the DbLockRefresher
      
          (cherry picked from commit a3bc5d1f)
      
        REPO-1811 Tests to confirm lock expiration
      
          Integration tests that confirm the correct working of the
          DbResetExpiredLocksJanitor
      
          (cherry picked from commit c2284223)
      
        REPO-1811 only run expires db lock test in integration test
      
          (cherry picked from commit 79490e41)
      
        REPO-1811 Fix test to have flexible logger node test
      
          (cherry picked from commit 547542ef)
      
        REPO-1811 Improve exception handling and logging
      
          (cherry picked from commit 4fdb9278)
      
        REPO-1811 Improved destroy of the LockManager and other improvements
      
          (cherry picked from commit 589c19b8)
      
        REPO-1811 Remove the 'refreshRateSeconds' logic
      
          Just fixed 60 seconds refresh rate
      
          (cherry picked from commit b51f32d9)
      
        REPO-1811 Deprecate JCR (hippo) locking
      
          Note all usages of JCR Locking still need to be replaced
      
          (cherry picked from commit 04c17617)
      
        REPO-1811 Use the new LockManager instead of JCR Locking
      
          (cherry picked from commit 8ddbbc21)
      
        REPO-1811 Implement autocloseable LockResource and integration tests
      
          (cherry picked from commit ac0b839d)
      
        REPO-1811 Use auto closeable
      
          (cherry picked from commit 6938d49c)
      
        REPO-1811 Add a cleanup background job that removes rows from database of old locks
      
          (cherry picked from commit bb1f233b)
      
        REPO-1811 Implement new LockResource getters
      
          (cherry picked from commit e209d242)
      
        REPO-1811 Better tearDown
      
          Make sure tearDown with clearing the repository still removes
          also the database entries because if they are kept, consequent runs can fail
      
          (cherry picked from commit ffb7b9a6)
      
        REPO-1811 shorter keys
      
          (cherry picked from commit 87e1cb4b)
      
        REPO-1811 Support all databases and most specifically Oracle
      
          (cherry picked from commit 03072bf6)
      
        REPO-1811 Handle the interrupted exception gracefully
      
          When the lockmanager has an indication for 'abort' for the lock for the
          thread that is executing the UpdateExecutor, it means, that the current
          or a different cluster node has requested the task to be stopped. Invoking
          #cancel is the graceful stop of the job
      
          (cherry picked from commit 6354174b)
      
        REPO-1811 further refactoring and cleanup of the new (Db)LockManager
      
          - construction moved to LocalHippoRepository as well as further generalized
          - LockManagerFactory moved to DbLockManagerFactory and now only is responsible for constructing a DbLockManager
          - DbLockManager: added support for schemaObjectPrefix and schemaCheckEnabled, like all JR schema definitions
          - Added (handling for) new AlreadyLockedException, indicating a lock retry might be feasible
          - Merged DbHelper logic into DbLockManager (which ittself now gets passed into background Runnables) and use JR ConnectionHelper to check if table already exists
          - Added LockManagerUtilsTest, in test module, for services-api provided LockManagerUtils
      
          (cherry picked from commit 035c7ff9)
      
        REPO-1811 Improve the logging statement
      
          (cherry picked from commit 11f334ee)
      
        REPO-1811 Make sure the lockThread finishes before tearDown kicks in
      
          (cherry picked from commit f81fb33e)
      
        REPO-1811 license header
      
        (cherry picked from commit ab46d905)
      
        REPO-1811 fix unit tests
      
          (cherry picked from commit 84858ae4)
      
        REPO-1873 Support closing a LockResource by a different thread - implementation
      
          (cherry picked from commit 8e614323)
      
        REPO-1873 improve LocalHippoRepository instantiation extensibility
      
          (cherry picked from commit 79f365d3)
      
        REPO-1874 Leverage LockManager for the RepositoryScheduler replacing the deprecated HippoLock usage
      
          (cherry picked from commit 7e91d6c3)
      
        REPO-1875 add support for mssql (Microsoft SQL Server)
      
          Also added test configurations for mssql, postgresql and oracle in repository-test module, and updated/aligned the repository.xml and test/connection parameters for each of these.
      
          (cherry picked from commit 92213cda)
      
      (cherry picked from commit fceda60165179a1aee27e095c7c649553debd36e)
      b05161a4
    • Ate Douma's avatar
    • Ate Douma's avatar
      REPO-1882 [Backport 11.2] Provide (log4j1) Log4jInterceptor test utility class... · b7e24944
      Ate Douma authored
      REPO-1882 [Backport 11.2] Provide (log4j1) Log4jInterceptor test utility class to suppress and/or capture log events during unit tests
      b7e24944
  11. 26 Oct, 2017 2 commits
  12. 16 Oct, 2017 2 commits
  13. 26 Sep, 2017 2 commits
  14. 20 Jul, 2017 1 commit
  15. 11 Jul, 2017 1 commit
  16. 03 Jul, 2017 2 commits
  17. 12 Jun, 2017 1 commit
  18. 22 May, 2017 1 commit
  19. 17 May, 2017 2 commits
    • Ard Schrijvers's avatar
      REPO-1671 [Backport 4.2] use the correct session because anonymous user is not... · 090b87ea
      Ard Schrijvers authored
      REPO-1671 [Backport 4.2] use the correct session because anonymous user is not allowed to write the setTimeout properties
      
      (cherry picked from commit 13719c3a)
      090b87ea
    • Ard Schrijvers's avatar
      REPO-1671 [Backport 4.2] make sure to synchronize on the jcr session to avoid thread safety issues · d9c77150
      Ard Schrijvers authored
      If we synchronize on the monitor object, there is room for concurrent access on the jcr session
      because code that created the lock can call for example #isLive which can work on the
      same jcr session as the background executor job does that refreshes the lock.
      
      Also made sure that if #setTimeout fails with a repository exception, that this exception
      is propagated and results in a lock exception. Before this exception would only be logged,
      and situations were seen that the background thread that refreshes the lock would log
      a repository exception in #setTimeout every 52 seconds (default 1 minute minus 8 second delay)
      were it should abandon the refreshing completely.
      
      In case of an exception, always log the stacktrace and not just in debug mode
      
      (cherry picked from commit 2aa0536f)
      d9c77150
  20. 11 May, 2017 1 commit