1. 07 Jun, 2018 1 commit
  2. 28 Mar, 2018 1 commit
  3. 23 Mar, 2018 1 commit
  4. 21 Mar, 2018 1 commit
  5. 07 Mar, 2018 4 commits
  6. 27 Feb, 2018 1 commit
  7. 26 Feb, 2018 2 commits
  8. 23 Feb, 2018 2 commits
  9. 16 Feb, 2018 1 commit
  10. 15 Feb, 2018 3 commits
  11. 13 Feb, 2018 1 commit
  12. 12 Feb, 2018 1 commit
  13. 11 Feb, 2018 2 commits
    • Ate Douma's avatar
      REPO-1939 correct lockKey column length · 034e6aba
      Ate Douma authored
      034e6aba
    • Ard Schrijvers's avatar
      REPO-1939 Fix hippo lock table creation for MySQL · 90938409
      Ard Schrijvers authored
      Make sure that *if* the Hippo lock table exists, that it really contains
      an index on lockKey (regardless whether it is a primary key or a unique
      index). If it doesn't contain one, the lock table was not created
      correctly and contains locks that do not work. Hence, truncating the
      lock table is ok. After that, correct the table scheme. Right after
      the table scheme has been fixed, other running cluster nodes can log
      some errors wrt locks. This is not a problem and expected
      90938409
  14. 09 Feb, 2018 4 commits
  15. 08 Feb, 2018 7 commits
  16. 07 Feb, 2018 1 commit
    • Ard Schrijvers's avatar
      REPO-1934 Make sure PersistedEventListeners can always proceed with events · 8cb0bb76
      Ard Schrijvers authored
      Before this commit, the logic was such that first an attempt was
      done to find which listener should be used for processing events.
      
      This was done in BroadcastModule#getNextJob which would return
      the listener (say A) with the oldest 'hippobroadcast:lastProcessed' value.
      
      The problem however was that if all the events to process
      would be filtered for listener A because of the #getCategory to
      listen to (and no events for the category), the listener A
      would not process any events and would not update the
      'hippobroadcast:lastProcessed' value, resulting in the next
      run again to use Listener A (while there might already be
      more than enough events for Listener B which doesn't
      filter on a category)
      
      The changes in this commit first of all change
      BroadcastModule#getNextJob to not return a single listener
      to process events for, but instead *all* listeners that
      are registered, where every listener has its own 'lastProcessed'
      value and Classloader stored in a Triple. We cannot use a
      global last processed unfortunately because of the
      listener.onlyNewEvents() concept.
      
      After we have all the listeners, a BroadcastJobImpl
      containing all listeners and the globalLastProcessed. In
      the Broadcaster.JobRunner we now fetch *all* events
      after globalLastProcessed and then give every event
      to BroadcastModule.BroadcastJobImpl#publish in which we check
      for every listener whether it should process the event.
      
      The big difference is that instead of querying for all
      event items *per* listener, one listener after another,
      we query once for all event items, and feed them to every
      listener is the listener doesn't filter out the event
      8cb0bb76
  17. 05 Feb, 2018 2 commits
  18. 02 Feb, 2018 4 commits
  19. 01 Feb, 2018 1 commit
    • Ard Schrijvers's avatar
      REPO-1 Correct the cms-testutils dependency usage · 3472e690
      Ard Schrijvers authored
      In dependency mgt the cms-testutils has scope 'test'. Downstream project
      relying on the hippo-repository-testutils however 'expect' the
      cms-testutils to be transitively pulled in by hippo-repository-testutils.
      
      Hence I removed the scope for every cms-testutils usage and in
      hippo-repository-testutils I did set the scope to 'compile' such that
      downstream projects get cms-testutils pulled in when they include
      hippo-repository-testutils (as test dependency)
      3472e690