1. 28 Mar, 2018 1 commit
    • antirez's avatar
      Fix ae.c when a timer finalizerProc adds an event. · 8ac7af1c
      antirez authored
      While this feature is not used by Redis, ae.c implements the ability for
      a timer to call a finalizer callback when an timer event is deleted.
      This feature was bugged since the start, and because it was never used
      we never noticed a problem. However Anthony LaTorre was using the same
      library in order to implement a different system: he found a bug that he
      describes as follows, and which he fixed with the patch in this commit,
      sent me by private email:
      
          --- Anthony email ---
      
      've found one bug in the current implementation of the timed events.
      It's possible to lose track of a timed event if an event is added in
      the finalizerProc of another event.
      
      For example, suppose you start off with three timed events 1, 2, and
      3. Then the linked list looks like:
      
      3 -> 2 -> 1
      
      Then, you run processTimeEvents and events 2 and 3 finish, so now the
      list looks like:
      
      -1 -> -1 -> 2
      
      Now, on the next iteration of processTimeEvents it starts by deleting
      the first event, and suppose this finalizerProc creates a new event,
      so that the list looks like this:
      
      4 -> -1 -> 2
      
      On the next iteration of the while loop, when it gets to the second
      event, the variable prev is still set to NULL, so that the head of the
      event loop after the next event will be set to 2, i.e. after deleting
      the next event the event loop will look like:
      
      2
      
      and the event with id 4 will be lost.
      
      I've attached an example program to illustrate the issue. If you run
      it you will see that it prints:
      
      ```
      foo id = 0
      spam!
      ```
      
      But if you uncomment line 29 and run it again it won't print "spam!".
      
          --- End of email ---
      
      Test.c source code is as follows:
      
          #include "ae.h"
          #include <stdio.h>
      
          aeEventLoop *el;
      
          int foo(struct aeEventLoop *el, long long id, void *data)
          {
      	printf("foo id = %lld\n", id);
      
      	return AE_NOMORE;
          }
      
          int spam(struct aeEventLoop *el, long long id, void *data)
          {
      	printf("spam!\n");
      
      	return AE_NOMORE;
          }
      
          void bar(struct aeEventLoop *el, void *data)
          {
      	aeCreateTimeEvent(el, 0, spam, NULL, NULL);
          }
      
          int main(int argc, char **argv)
          {
      	el = aeCreateEventLoop(100);
      
      	//aeCreateTimeEvent(el, 0, foo, NULL, NULL);
      	aeCreateTimeEvent(el, 0, foo, NULL, bar);
      
      	aeMain(el);
      
      	return 0;
          }
      
      Anthony fixed the problem by using a linked list for the list of timers, and
      sent me back this patch after he tested the code in production for some time.
      The code looks sane to me, so committing it to Redis.
      8ac7af1c
  2. 26 Mar, 2018 1 commit
  3. 25 Mar, 2018 2 commits
    • antirez's avatar
      2b2652d7
    • antirez's avatar
      AOF: enable RDB-preamble rewriting by default. · 28d28ef3
      antirez authored
      There are too many advantages in doing this, RDB is faster to persist,
      more compact, much faster to load back. The main issues here are that
      the code is less tested because this was not the old default (so we are
      enabling it for the new 5.0 release), and that the AOF is no longer a
      trivially parsable format from now on. However the non-preamble mode
      will be supported in the future as well, if new data types will be
      added.
      28d28ef3
  4. 23 Mar, 2018 2 commits
  5. 22 Mar, 2018 12 commits
  6. 21 Mar, 2018 3 commits
  7. 20 Mar, 2018 6 commits
  8. 19 Mar, 2018 1 commit
  9. 16 Mar, 2018 6 commits
  10. 15 Mar, 2018 6 commits
    • antirez's avatar
      RDB: make RDB check aware of LFU/LRU opcodes. · b1aae86f
      antirez authored
      b1aae86f
    • antirez's avatar
      RDB: LRU/LFU branches missed continue. · 8176a2ee
      antirez authored
      8176a2ee
    • antirez's avatar
      RDB: Ability to load LFU/LRU info. · 1ce50a7a
      antirez authored
      1ce50a7a
    • antirez's avatar
      RDB: Ability to save LFU/LRU info. · d7a5c0eb
      antirez authored
      This is a big win for caching use cases, since on reloading Redis will
      still have some idea about what is worth to evict and what not.
      However this only solves part of the problem because the information is
      only partially propagated to slaves (on write operations). Reads will
      not affect slaves LFU and LRU counters, so after a failover the eviction
      decisions are kinda random until keys start to collect some aging/freq info.
      
      However since new slaves are initially populated via RDB file transfer,
      this means that if we spin up a new slave from a master, and perform an
      immediate manual failover (for instance in order to upgrade the master),
      the slave will have eviction informations to use for some time.
      
      The LFU/LRU info is persisted only if the maxmemory policy is set to one
      of the relevant type, even if no actual "maxmemory"  memory limit is
      set.
      d7a5c0eb
    • antirez's avatar
      CG: XINFO STREAM. · 66143616
      antirez authored
      66143616
    • antirez's avatar
      CG: XINFO GROUPS + output format changes. · d7d8cd0b
      antirez authored
      XINFO is mainly an observability command that will be used more by
      humans than computers, and even when used by computers it will be a very
      low traffic command. For this reason the format was changed in order to
      have field names. They'll consume some bandwidth and CPU cycles, but in
      this context this is much better than having to understand what the
      numbers in the output array are.
      d7d8cd0b