- 04 9月, 2013 6 次提交
-
-
由 antirez 提交于
-
由 antirez 提交于
Handshake nodes should turn into normal nodes or be freed in a reasonable amount of time, otherwise they'll keep accumulating if the address they are associated with is not reachable for some reason.
-
由 antirez 提交于
The code freed a reply object that was never created, resulting in a segfault every time randomkey returned a key that was deleted before we queried it for size.
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
- 03 9月, 2013 5 次提交
-
-
由 Maxim Zakharov 提交于
-
由 Maxim Zakharov 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
The code used to copy the header *after* the 'hdr' pointer was already switched to the new buffer. Of course we need to do the reverse.
-
- 30 8月, 2013 1 次提交
-
-
由 antirez 提交于
-
- 29 8月, 2013 2 次提交
-
-
由 antirez 提交于
-
由 antirez 提交于
Multiple missing calls to lua_pop prevented the error handler function pushed on the stack for lua_pcall() to be popped before returning, causing a memory leak in almost all the code paths of EVAL (both successful calls and calls returning errors). This caused two issues: Lua leaking memory (and this was very visible from INFO memory output, as the 'used_memory_lua' field reported an always increasing amount of memory used), and as a result slower and slower GC cycles resulting in all the CPU being used. Thanks to Tanguy Le Barzic for noticing something was wrong with his 2.8 slave, and for creating a testing EC2 environment where I was able to investigate the issue.
-
- 27 8月, 2013 9 次提交
-
-
由 yihuang 提交于
-
由 antirez 提交于
-
由 antirez 提交于
We are sure the string is large, since when the sds optimization branch is entered it means that it was not possible to encode it as EMBSTR for size concerns.
-
由 antirez 提交于
When no encoding is possible, at least try to reallocate the sds string with one that does not waste memory (with free space at the end of the buffer) when the string is large enough.
-
由 antirez 提交于
We are sure that a string that is longer than 21 chars cannot be represented by a 64 bit signed integer, as -(2^64) is 21 chars: strlen(-18446744073709551616) => 21
-
由 antirez 提交于
The call to sdsMakeRoomFor() did not accounted for the amount of data already present in the query buffer, resulting into over-allocation.
-
由 antirez 提交于
This command is only useful for low-level debugging of memory issues due to sds wasting memory as empty buffer at the end of the string.
-
由 antirez 提交于
-
由 antirez 提交于
-
- 26 8月, 2013 1 次提交
-
-
由 antirez 提交于
This feature was implemented in the initial days of the Redis Cluster implementaiton but is not a good idea at all. 1) It depends on clocks to be synchronized, that is already very bad. 2) Moreover it adds a bug where the pong time is updated via gossip so no new PING is ever sent by the current node, with the effect of no PONG received, no update of tables, no clearing of PFAIL flag. In general to trust other nodes about the reachability of other nodes is a broken distributed programming model.
-
- 22 8月, 2013 6 次提交
-
-
由 antirez 提交于
The commit using listenToPort() introduced this bug by no longer creating the event handler to handle incoming messages from the cluster bus.
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
This was broken by the IPv6 support patches.
-
由 antirez 提交于
Somewhat a previous commit broken this so CLUSTER MEET was no longer working.
-
- 21 8月, 2013 3 次提交
-
-
由 antirez 提交于
-
由 antirez 提交于
-
由 Salvatore Sanfilippo 提交于
fixed initServer fail problem
-
- 20 8月, 2013 2 次提交
- 19 8月, 2013 5 次提交
-
-
由 antirez 提交于
-
由 antirez 提交于
Also a warning was suppressed by including unistd.h in redisassert.h (needed for _exit()).
-
由 antirez 提交于
By using redisassert.h version of assert() you get stack traces in the log instead of a process disappearing on assertions.
-
由 antirez 提交于
The previous hashing used the trivial algorithm of xoring the integers together. This is not optimal as it is very likely that different hash table setups will hash the same, for instance an hash table at the start of the rehashing process, and at the end, will have the same fingerprint. Now we hash N integers in a smarter way, by summing every integer to the previous hash, and taking the integer hashing again (see the code for further details). This way it is a lot less likely that we get a collision. Moreover this way of hashing explicitly protects from the same set of integers in a different order to hash to the same number. This commit is related to issue #1240.