1. 13 May, 2019 1 commit
    • antirez's avatar
      Fix test false positive introduced by threaded I/O. · 4f4676a1
      antirez authored
      Now clients that are ready to be terminated asynchronously are processed
      more often in beforeSleep() instead of being processed in serverCron().
      This means that the test will not be able to catch the moment the client
      was terminated, also note that the 'omem' figure now changes in big
      steps, because of the new client output buffers layout.
      
      So we have to change the test range in order to accomodate for that.
      Yet the test is useful enough to be worth taking, even if its precision
      is reduced by this commit. Probably if we get more problems, a thing
      that makes sense is just to check that the limit is < 200k. That's more
      than enough actually.
      4f4676a1
  2. 05 May, 2019 1 commit
    • Oran Agra's avatar
      make replication tests more stable on slow machines · ba809f26
      Oran Agra authored
      solving few replication related tests race conditions which fail on slow machines
      
      bugfix in slave buffers test: since the test is executed twice, each time with
      a different commands count, the threshold for the delta can't be a constant.
      ba809f26
  3. 08 Apr, 2019 2 commits
  4. 24 Mar, 2019 2 commits
  5. 15 Mar, 2019 2 commits
  6. 12 Mar, 2019 1 commit
  7. 08 Mar, 2019 1 commit
    • Steve Webster's avatar
      Increment delivery counter on XCLAIM unless RETRYCOUNT specified · f1e7df4b
      Steve Webster authored
      The XCLAIM docs state the XCLAIM increments the delivery counter for
      messages. This PR makes the code match the documentation - which seems
      like the desired behaviour - whilst still allowing RETRYCOUNT to be
      specified manually.
      
      My understanding of the way streamPropagateXCLAIM() works is that this
      change will safely propagate to replicas since retry count is pulled
      directly from the streamNACK struct.
      
      Fixes #5194
      f1e7df4b
  8. 30 Jan, 2019 1 commit
  9. 28 Jan, 2019 6 commits
  10. 18 Jan, 2019 1 commit
  11. 17 Jan, 2019 1 commit
  12. 28 Nov, 2018 1 commit
  13. 19 Nov, 2018 2 commits
  14. 12 Nov, 2018 1 commit
  15. 17 Oct, 2018 1 commit
  16. 16 Oct, 2018 2 commits
  17. 13 Oct, 2018 1 commit
  18. 10 Oct, 2018 2 commits
  19. 09 Oct, 2018 2 commits
  20. 30 Sep, 2018 1 commit
  21. 11 Sep, 2018 1 commit
  22. 05 Sep, 2018 1 commit
  23. 21 Aug, 2018 1 commit
    • Oran Agra's avatar
      Fix unstable tests on slow machines. · c8452ab0
      Oran Agra authored
      Few tests had borderline thresholds that were adjusted.
      
      The slave buffers test had two issues, preventing the slave buffer from growing:
      1) the slave didn't necessarily go to sleep on time, or woke up too early,
         now using SIGSTOP to make sure it goes to sleep exactly when we want.
      2) the master disconnected the slave on timeout
      c8452ab0
  24. 13 Aug, 2018 1 commit
  25. 02 Aug, 2018 1 commit
    • antirez's avatar
      Test: new sorted set skiplist order consistency. · d506334b
      antirez authored
      This should be able to find new bugs and regressions about the new
      sorted set update function when ZADD is used to update an element
      already existing.
      
      The test is able to find the bug fixed at 2f282aee immediately.
      d506334b
  26. 01 Aug, 2018 1 commit
  27. 24 Jul, 2018 1 commit
    • Oran Agra's avatar
      fix slave buffer test suite false positives · d4ae76d1
      Oran Agra authored
      it looks like on slow machines we're getting:
      [err]: slave buffer are counted correctly in tests/unit/maxmemory.tcl
      Expected condition '$slave_buf > 2*1024*1024' to be true (16914 > 2*1024*1024)
      
      this is a result of the slave waking up too early and eating the
      slave buffer before the traffic and the test ends.
      d4ae76d1
  28. 18 Jul, 2018 1 commit
    • Oran Agra's avatar
      make active defrag test more stable · f89c93c8
      Oran Agra authored
      on slower machines, the active defrag test tended to fail.
      although the fragmentation ratio was below the treshold, the defragger was
      still in the middle of a scan cycle.
      
      this commit changes:
      - the defragger uses the current fragmentation state, rather than the cache one
        that is updated by server cron every 100ms. this actually fixes a bug of
        starting one excess scan cycle
      - the test lets the defragger use more CPU cycles, in hope that the defrag
        will be faster, but also give it more time before we give up.
      f89c93c8