- 27 Feb, 2018 1 commit
-
-
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.
-
- 02 May, 2016 3 commits
-
-
antirez authored
This fix was written by Anthony LaTorre. The old code mis-calculated the amount of time to wait till next event.
-
antirez authored
-
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.
-
- 08 Aug, 2014 1 commit
-
-
Jim Howard authored
Reason: https://github.com/antirez/redis/pull/1450#issuecomment-30432925 Closes #1450
-
- 28 Jun, 2013 1 commit
-
-
antirez authored
-
- 19 Jan, 2013 1 commit
-
-
guiquanz authored
-
- 03 Jan, 2013 1 commit
-
-
antirez authored
In this way the caller is able to perform better error checking or to use strerror() without the risk of meaningless error messages being displayed.
-
- 05 Oct, 2012 1 commit
-
-
antirez authored
-
- 04 Oct, 2012 1 commit
-
-
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. */
-
- 23 May, 2012 1 commit
-
-
jokea authored
-
- 15 May, 2012 1 commit
-
-
Dave Pacheco authored
-
- 06 Apr, 2012 1 commit
-
-
jokea authored
-
- 08 Feb, 2012 1 commit
-
-
antirez authored
-
- 25 Jan, 2012 2 commits
-
-
antirez authored
patch by Mukund Sivaraman, modified by me to make it simpler and to use my coding style).
-
Mukund Sivaraman authored
-
- 16 Dec, 2011 1 commit
-
-
antirez authored
loop is never destroyed in Redis). Thanks to @anydot for noticing it.
-
- 15 Dec, 2011 1 commit
-
-
antirez authored
-
- 21 Nov, 2011 1 commit
-
-
antirez authored
-
- 01 Jul, 2010 1 commit
-
-
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
-
- 19 Feb, 2010 1 commit
-
-
antirez authored
A problem with replication with multiple slaves connectiong to a single master fixed. It was due to a typo, and reported on github by the user micmac. Also the copyright year fixed from many files.
-
- 28 Jan, 2010 1 commit
-
-
antirez authored
-
- 20 Jan, 2010 1 commit
-
-
antirez authored
ae.c event loop does no longer support exception notifications, as they are fully pointless. Also a theoretical bug that never happens in practice fixed.
-
- 28 Nov, 2009 2 commits
-
-
antirez authored
ifdefs added to use kevent on Free Open and Net BSD as well. INFO and ae.c modified in order to report the multiplexing API in use
-
Harish Mallipeddi authored
-
- 23 Nov, 2009 2 commits
- 22 Mar, 2009 1 commit
-
-
antirez authored
-