Flags can occur in any order in format string, so we can't assume any order.
In original code, the redisvFormatCommand can process " %#+d" correctly,
but can't process "%+#d".
Closes#257
[Cleaned up:
- name of function: freeRedis... -> redisFree...
- return value of function (free doesn't return anything)
- parameter type for function.
- we don't need to free a char**, the char** is just
for returning from the assignment functoin.]
Closes#250
[This introduces some new API functions.]
* Adds new flag to the connection context indicating SO_REUSEADDR
should be set.
* Adds max number of retries constant for when connect() hits
EADDRNOTAVAIL.
* Adds new function, redisAsyncConnectBindWithReuse(), letting
clients enable this functionality.
[Removed trailing whitespace in new header lines.]
Closes#264
OK, perhaps the second time is a charm. I forgot that I had
hiredis forked from a long time ago, so the initial pull
request was hosed. :)
* Pulled in sdscatfmt() from Redis, and modified it to accept a
size_t (%T) style format specifier.
* Pulled in sdsll2str() and sdsull2str() from Redis (needed by
sdscatfmt).
* Added a new method, redisFormatSdsCommandArgv() which takes
and sds* as the target, rather than char* (and uses sdscatfmt
instead of sprintf for the construction).
I get roughly the following improvement:
Old: 1.044806
New: 0.481620
The benchmark code itself can be found here:
https://gist.github.com/michael-grunder/c92ef31bb632b3d0ad81Closes#260
SDS is now broken out of Redis into its own project, so include
the latest version from the SDS repo.
This is a backport of the Redis commit doing the same to the bundled hiredis:
320fa02b9b
Some environments require binding to specific source addresses instead
of letting the system determine which IP a connection should originate
from.
Closes#233
The struct timeval argument in redisConnectWithTimeout(),
redisConnectUnixWithTimeout(), redisSetTimeout(),
redisContextSetTimeout(), redisContextConnectTcp()
and redisContextConnectUnix() is never modified and can
therefore be marked as const.
Signed-off-by: Noah Williamsson <noah.williamsson@gmail.com>
It was verified experimentally that this value, on Linux kernels, provides
better performances compared to the 2k value. However larger values
apparently don't produce any noticeable effect on performances.
Hiredis can handle multi bulk replies with a fixed (hardcoded) level of
nesting. This should be changed in the future in order to avoid
hardcoded limits. As a quick fix this commit moves the max nesting from 2
to 7, so that there are no problems when processing replies from the SLOWLOG
command, from Redis Sentinel, or generated by Redis Lua Scripts (that are
allowed to generate replies with any level of nesting).
Hiredis used to free unused redisReader buffers bigger than 16k. Now
this limit is configurable (see the documentation updated by this commit)
in order to allow working with big payloads without incurring to speed
penalty.
This reverts commit 77540aa316. The change
in buffer strategy is too large to put in a minor release. It is put in
a separate branch in the meantime, so it can be refined and released
together with a minor version bump.
This is done by only truncating the read buffer once a full reply has
been read. The buffer is no longer truncated halfway through reading a
reply. In addition: pass offset/length of protocol and content via the
read tasks.
