- clusterWriteDone() and clusterWriteHandler() are now using LL_DEBUG verbosity instead of LL_WARNING to inform about not-so-mportant events
Solves #14
- src/aof.c was initially not correctly merged (Redis 4.0.2 merged with MS OpenTech's Redis 3.2.100) which caused
errors when rewriting AOF file
- bumping version to 4.0.2.2
Fixes#12
In case there are larger amounts of data to be sent back to client they are normally split into up to 64K chunks (unless server exceeds "maxmemory" which causes it to send as much as possible). When writeToClient() returns and has pending replies to be sent - it is scheduled in event loop and when IOCP signals that the socket is writeable again - sendReplyToClient() handler is called and sends additional chunk via writeToClient(). This however behaves differently under Windows and in order to send the following pedning replies - we need to schedule sendReplyToClient() again. Furthermore when we are sending data too fast and receive WSAEWOULDBLOCK error/warning - we back off again and re-schedule sending.
Fixes#11
- when output is a TTY - always enable linenoise history (regardless if history file name can be determined)
- adjusted redis-cli/getDotfilePath() to use %HOMEDRIVE%%HOMPATH% environment variables to find user's home folder
- when output is a TTY - always enable linenoise history (regardless if history file name can be determined)
- adjusted redis-cli/getDotfilePath() to use %HOMEDRIVE%%HOMPATH% environment variables to find user's home folder
- removed separate project for redis-check-aof
- both tools are now a copy of redis-server.exe
- running given tool calls proper action and causes
the application to exit
- updated installer
Fixes#2
This bug most experienced effect was an inability of Redis to
reconfigure back old masters to slaves after they are reachable again
after a failover. This was due to failing to reset the count of the
pending commands properly, so the master appeared fovever down.
Was introduced in Redis 3.2 new Sentinel connection sharing feature
which is a lot more complex than the 3.0 code, but more scalable.
Many thanks to people reporting the issue, and especially to
@sskorgal for investigating the issue in depth.
Hopefully closes#3285.
I recently introduced populating the autocomplete help array with the
COMMAND command if available. However this was performed before parsing
the arguments, defaulting to instance 6379. After the connection is
performed it remains stable.
The effect is that if there is an instance running on port 6339,
whatever port you specify is ignored and 6379 is connected to instead.
The right port will be selected only after a reconnection.
Close#3314.
Reference issue #3218.
Checking the code I can't find a reason why the original RESTORE
code was so opinionated about restoring only the current version. The
code in to `rdb.c` appears to be capable as always to restore data from
older versions of Redis, and the only places where it is needed the
current version in order to correctly restore data, is while loading the
opcodes, not the values itself as it happens in the case of RESTORE.
For the above reasons, this commit enables RESTORE to accept older
versions of values payloads.
Comment format fixed + local var modified from camel case to underscore
separators as Redis code base normally does (camel case is mostly used
for global symbols like structure names, function names, global vars,
...).
Israel Lot