1. 27 Feb, 2018 1 commit
    • antirez's avatar
      ae.c: introduce the concept of read->write barrier. · e6043981
      antirez authored
      AOF fsync=always, and certain Redis Cluster bus operations, require to
      fsync data on disk before replying with an acknowledge.
      In such case, in order to implement Group Commits, we want to be sure
      that queries that are read in a given cycle of the event loop, are never
      served to clients in the same event loop iteration. This way, by using
      the event loop "before sleep" callback, we can fsync the information
      just one time before returning into the event loop for the next cycle.
      This is much more efficient compared to calling fsync() multiple times.
      
      Unfortunately because of a bug, this was not always guaranteed: the
      actual way the events are installed was the sole thing that could
      control. Normally this problem is hard to trigger when AOF is enabled
      with fsync=always, because we try to flush the output buffers to the
      socekt directly in the beforeSleep() function of Redis. However if the
      output buffers are full, we actually install a write event, and in such
      a case, this bug could happen.
      
      This change to ae.c modifies the event loop implementation to make this
      concept explicit. Write events that are registered with:
      
          AE_WRITABLE|AE_BARRIER
      
      Are guaranteed to never fire after the readable event was fired for the
      same file descriptor. In this way we are sure that data is persisted to
      disk before the client performing the operation receives an
      acknowledged.
      
      However note that this semantics does not provide all the guarantees
      that one may believe are automatically provided. Take the example of the
      blocking list operations in Redis.
      
      With AOF and fsync=always we could have:
      
          Client A doing: BLPOP myqueue 0
          Client B doing: RPUSH myqueue a b c
      
      In this scenario, Client A will get the "a" elements immediately after
      the Client B RPUSH will be executed, even before the operation is persisted.
      However when Client B will get the acknowledge, it can be sure that
      "b,c" are already safe on disk inside the list.
      
      What to note here is that it cannot be assumed that Client A receiving
      the element is a guaranteed that the operation succeeded from the point
      of view of Client B.
      
      This is due to the fact that the barrier exists within the same socket,
      and not between different sockets. However in the case above, the
      element "a" was not going to be persisted regardless, so it is a pretty
      synthetic argument.
      e6043981
  2. 02 May, 2016 3 commits
    • antirez's avatar
      ae.c: Fix delay until next timer event. · 29645f1f
      antirez authored
      This fix was written by Anthony LaTorre.
      The old code mis-calculated the amount of time to wait till next event.
      29645f1f
    • antirez's avatar
      aa79c1f1
    • antirez's avatar
      Fix ae.c to avoid timers infinite loop. · 0b69c986
      antirez authored
      This fix was suggested by Anthony LaTorre, that provided also a good
      test case that was used to verify the fix.
      
      The problem with the old implementation is that, the time returned by
      a timer event (that is the time after it want to run again) is added
      to the event *start time*. So if the event takes, in order to run, more
      than the time it says it want to be scheduled again for running, an
      infinite loop is triggered.
      0b69c986
  3. 08 Aug, 2014 1 commit
  4. 28 Jun, 2013 1 commit
  5. 19 Jan, 2013 1 commit
  6. 03 Jan, 2013 1 commit
  7. 05 Oct, 2012 1 commit
  8. 04 Oct, 2012 1 commit
    • Jokea's avatar
      Force expire all timer events when system clock skew is detected. · b7b2a1cc
      Jokea authored
      When system time changes back, the timer will not worker properly
      hence some core functionality of redis will stop working(e.g. replication,
      bgsave, etc). See issue #633 for details.
      
      The patch saves the previous time and when a system clock skew is detected,
      it will force expire all timers.
      
      Modiifed by @antirez: the previous time was moved into the eventLoop
      structure to make sure the library is still thread safe as long as you
      use different event loops into different threads (otherwise you need
      some synchronization). More comments added about the reasoning at the
      base of the patch, that's worth reporting here:
      
      /* If the system clock is moved to the future, and then set back to the
       * right value, time events may be delayed in a random way. Often this
       * means that scheduled operations will not be performed soon enough.
       *
       * Here we try to detect system clock skews, and force all the time
       * events to be processed ASAP when this happens: the idea is that
       * processing events earlier is less dangerous than delaying them
       * indefinitely, and practice suggests it is. */
      b7b2a1cc
  9. 23 May, 2012 1 commit
  10. 15 May, 2012 1 commit
  11. 06 Apr, 2012 1 commit
  12. 08 Feb, 2012 1 commit
  13. 25 Jan, 2012 2 commits
  14. 16 Dec, 2011 1 commit
  15. 15 Dec, 2011 1 commit
  16. 21 Nov, 2011 1 commit
  17. 01 Jul, 2010 1 commit
    • antirez's avatar
      redis.c split into many different C files. · e2641e09
      antirez authored
      networking related stuff moved into networking.c
      
      moved more code
      
      more work on layout of source code
      
      SDS instantaneuos memory saving. By Pieter and Salvatore at VMware ;)
      
      cleanly compiling again after the first split, now splitting it in more C files
      
      moving more things around... work in progress
      
      split replication code
      
      splitting more
      
      Sets split
      
      Hash split
      
      replication split
      
      even more splitting
      
      more splitting
      
      minor change
      e2641e09
  18. 19 Feb, 2010 1 commit
  19. 28 Jan, 2010 1 commit
  20. 20 Jan, 2010 1 commit
  21. 28 Nov, 2009 2 commits
  22. 23 Nov, 2009 2 commits
  23. 22 Mar, 2009 1 commit