Discussion:
[redis-db] Streams: real-world connection management tactics
Seandon Mooy
2018-06-26 22:30:11 UTC
Permalink
Hello!

I'm working with the new XADD/XREAD commands, and am trying to devise a
client library for working with the streams feature. XREAD is a blocking
call, but accepts multiple streams to read per XREAD call. I certainly
don't want to design a system where, for example, an API to make use of
redis streams to provide real-time streaming logs, per-user, I would need
one connection to redis per user (ie: one connection for one stream). I
would like to "pool" the subscriptions and read from multiple streams - but
this implies that I must wait the full BLOCK time to add a subscription.
Put another way, if I limit myself to one-redis-connection-per-application,
how do I effectively read from more than one stream, on demand.

I have built a very crude pool system, where I allow up to N number of
redis connections, adding new XREAD calls as requests for subscriptions
come in. When an XREAD returns, I check to see if another XREAD is handling
this connection's streams, and if not I issue a new one for all desired
streams - ie: trying hard to eventually wind up with 1 XREAD. With a
"BLOCK" of one second, this effectively limits response time after _N
requests per second_! This is a scaling issue for me and feels like a poor
design on my part.

Does anyone have any ideas on this? I've been looking for a signal I can
send down the connection that will "cancel" an XREAD call, but all I can
manage to do is quit the connection entirely :P

Thanks for reading!

P.S. huge redis fan / user - I gave a talk at RedisConf17 and would love to
do another some day!

- Seandon
--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+***@googlegroups.com.
To post to this group, send email to redis-***@googlegroups.com.
Visit this group at https://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/d/optout.
Salvatore Sanfilippo
2018-06-27 10:57:20 UTC
Permalink
This is a very interesting question Seandon, thanks for asking :-)

I could reply you with a pragmatic solution, that is: for every
connection, you can just also XREAD for an "unblocking" dummy stream
called UNBLOCK_<connection-id>, and then XADD to that from another
connection to trigger an immediate return of the call, so that you can
add the other keys to monitor to the next call. However that would be
practically useful but insufficient to really reply to your question.
Probably we should consider if it is useful to have a "CLIENT UNBLOCK
<id>" call, so that other connections can unblock clients in any
blocking call in a more clean way. I'm not considering ways to unblock
a connection directly from the connection itself by sending some
special control sequence, because it looks like out of scope right now
(but potentially applicable to RESP3) and because to use a different
connection is probably simpler in practical terms for almost every
possible use.

So I asked this on Twitter, to see what is the general feeling:
https://twitter.com/antirez/status/1011921121648762885

Cheers,
Salvatore
Post by Seandon Mooy
Hello!
I'm working with the new XADD/XREAD commands, and am trying to devise a client library for working with the streams feature. XREAD is a blocking call, but accepts multiple streams to read per XREAD call. I certainly don't want to design a system where, for example, an API to make use of redis streams to provide real-time streaming logs, per-user, I would need one connection to redis per user (ie: one connection for one stream). I would like to "pool" the subscriptions and read from multiple streams - but this implies that I must wait the full BLOCK time to add a subscription. Put another way, if I limit myself to one-redis-connection-per-application, how do I effectively read from more than one stream, on demand.
I have built a very crude pool system, where I allow up to N number of redis connections, adding new XREAD calls as requests for subscriptions come in. When an XREAD returns, I check to see if another XREAD is handling this connection's streams, and if not I issue a new one for all desired streams - ie: trying hard to eventually wind up with 1 XREAD. With a "BLOCK" of one second, this effectively limits response time after _N requests per second_! This is a scaling issue for me and feels like a poor design on my part.
Does anyone have any ideas on this? I've been looking for a signal I can send down the connection that will "cancel" an XREAD call, but all I can manage to do is quit the connection entirely :P
Thanks for reading!
P.S. huge redis fan / user - I gave a talk at RedisConf17 and would love to do another some day!
- Seandon
--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
Visit this group at https://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/d/optout.
--
Salvatore 'antirez' Sanfilippo
open source developer - Redis Labs https://redislabs.com

"If a system is to have conceptual integrity, someone must control the
concepts."
— Fred Brooks, "The Mythical Man-Month", 1975.
--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+***@googlegroups.com.
To post to this group, send email to redis-***@googlegroups.com.
Visit this group at https://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/d/optout.
Salvatore Sanfilippo
2018-06-27 11:53:31 UTC
Permalink
P.S. I just pushed an implementation of "CLIENT UNBLOCK" into the
"client-unblock" branch at Github.
Post by Salvatore Sanfilippo
This is a very interesting question Seandon, thanks for asking :-)
I could reply you with a pragmatic solution, that is: for every
connection, you can just also XREAD for an "unblocking" dummy stream
called UNBLOCK_<connection-id>, and then XADD to that from another
connection to trigger an immediate return of the call, so that you can
add the other keys to monitor to the next call. However that would be
practically useful but insufficient to really reply to your question.
Probably we should consider if it is useful to have a "CLIENT UNBLOCK
<id>" call, so that other connections can unblock clients in any
blocking call in a more clean way. I'm not considering ways to unblock
a connection directly from the connection itself by sending some
special control sequence, because it looks like out of scope right now
(but potentially applicable to RESP3) and because to use a different
connection is probably simpler in practical terms for almost every
possible use.
https://twitter.com/antirez/status/1011921121648762885
Cheers,
Salvatore
Post by Seandon Mooy
Hello!
I'm working with the new XADD/XREAD commands, and am trying to devise a client library for working with the streams feature. XREAD is a blocking call, but accepts multiple streams to read per XREAD call. I certainly don't want to design a system where, for example, an API to make use of redis streams to provide real-time streaming logs, per-user, I would need one connection to redis per user (ie: one connection for one stream). I would like to "pool" the subscriptions and read from multiple streams - but this implies that I must wait the full BLOCK time to add a subscription. Put another way, if I limit myself to one-redis-connection-per-application, how do I effectively read from more than one stream, on demand.
I have built a very crude pool system, where I allow up to N number of redis connections, adding new XREAD calls as requests for subscriptions come in. When an XREAD returns, I check to see if another XREAD is handling this connection's streams, and if not I issue a new one for all desired streams - ie: trying hard to eventually wind up with 1 XREAD. With a "BLOCK" of one second, this effectively limits response time after _N requests per second_! This is a scaling issue for me and feels like a poor design on my part.
Does anyone have any ideas on this? I've been looking for a signal I can send down the connection that will "cancel" an XREAD call, but all I can manage to do is quit the connection entirely :P
Thanks for reading!
P.S. huge redis fan / user - I gave a talk at RedisConf17 and would love to do another some day!
- Seandon
--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
Visit this group at https://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/d/optout.
--
Salvatore 'antirez' Sanfilippo
open source developer - Redis Labs https://redislabs.com
"If a system is to have conceptual integrity, someone must control the
concepts."
— Fred Brooks, "The Mythical Man-Month", 1975.
--
Salvatore 'antirez' Sanfilippo
open source developer - Redis Labs https://redislabs.com

"If a system is to have conceptual integrity, someone must control the
concepts."
— Fred Brooks, "The Mythical Man-Month", 1975.
--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+***@googlegroups.com.
To post to this group, send email to redis-***@googlegroups.com.
Visit this group at https://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/d/optout.
Seandon Mooy
2018-06-27 18:34:44 UTC
Permalink
Fantastic! Exactly what I was looking for - using a different connection to
UNBLOCK is perfect (and probably better / more flexible). Will give the
"client-unblock" branch a go later tonight!

Thanks!
Post by Salvatore Sanfilippo
P.S. I just pushed an implementation of "CLIENT UNBLOCK" into the
"client-unblock" branch at Github.
Post by Salvatore Sanfilippo
This is a very interesting question Seandon, thanks for asking :-)
I could reply you with a pragmatic solution, that is: for every
connection, you can just also XREAD for an "unblocking" dummy stream
called UNBLOCK_<connection-id>, and then XADD to that from another
connection to trigger an immediate return of the call, so that you can
add the other keys to monitor to the next call. However that would be
practically useful but insufficient to really reply to your question.
Probably we should consider if it is useful to have a "CLIENT UNBLOCK
<id>" call, so that other connections can unblock clients in any
blocking call in a more clean way. I'm not considering ways to unblock
a connection directly from the connection itself by sending some
special control sequence, because it looks like out of scope right now
(but potentially applicable to RESP3) and because to use a different
connection is probably simpler in practical terms for almost every
possible use.
https://twitter.com/antirez/status/1011921121648762885
Cheers,
Salvatore
Post by Seandon Mooy
Hello!
I'm working with the new XADD/XREAD commands, and am trying to
devise a client library for working with the streams feature. XREAD is a
blocking call, but accepts multiple streams to read per XREAD call. I
certainly don't want to design a system where, for example, an API to make
use of redis streams to provide real-time streaming logs, per-user, I would
need one connection to redis per user (ie: one connection for one stream).
I would like to "pool" the subscriptions and read from multiple streams -
but this implies that I must wait the full BLOCK time to add a
subscription. Put another way, if I limit myself to
one-redis-connection-per-application, how do I effectively read from more
than one stream, on demand.
Post by Salvatore Sanfilippo
Post by Seandon Mooy
I have built a very crude pool system, where I allow up to N number
of redis connections, adding new XREAD calls as requests for subscriptions
come in. When an XREAD returns, I check to see if another XREAD is handling
this connection's streams, and if not I issue a new one for all desired
streams - ie: trying hard to eventually wind up with 1 XREAD. With a
"BLOCK" of one second, this effectively limits response time after _N
requests per second_! This is a scaling issue for me and feels like a poor
design on my part.
Post by Salvatore Sanfilippo
Post by Seandon Mooy
Does anyone have any ideas on this? I've been looking for a signal I
can send down the connection that will "cancel" an XREAD call, but all I
can manage to do is quit the connection entirely :P
Post by Salvatore Sanfilippo
Post by Seandon Mooy
Thanks for reading!
P.S. huge redis fan / user - I gave a talk at RedisConf17 and would
love to do another some day!
Post by Salvatore Sanfilippo
Post by Seandon Mooy
- Seandon
--
You received this message because you are subscribed to the Google
Groups "Redis DB" group.
Post by Salvatore Sanfilippo
Post by Seandon Mooy
To unsubscribe from this group and stop receiving emails from it, send
<javascript:>.
Post by Salvatore Sanfilippo
Post by Seandon Mooy
Visit this group at https://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/d/optout.
--
Salvatore 'antirez' Sanfilippo
open source developer - Redis Labs https://redislabs.com
"If a system is to have conceptual integrity, someone must control the
concepts."
— Fred Brooks, "The Mythical Man-Month", 1975.
--
Salvatore 'antirez' Sanfilippo
open source developer - Redis Labs https://redislabs.com
"If a system is to have conceptual integrity, someone must control the
concepts."
— Fred Brooks, "The Mythical Man-Month", 1975.
--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+***@googlegroups.com.
To post to this group, send email to redis-***@googlegroups.com.
Visit this group at https://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/d/optout.
Salvatore Sanfilippo
2018-06-27 20:44:47 UTC
Permalink
Thanks! Nice we had this exchange turning into a feature.
Post by Seandon Mooy
Fantastic! Exactly what I was looking for - using a different connection
to UNBLOCK is perfect (and probably better / more flexible). Will give the
"client-unblock" branch a go later tonight!
Thanks!
Post by Salvatore Sanfilippo
P.S. I just pushed an implementation of "CLIENT UNBLOCK" into the
"client-unblock" branch at Github.
Post by Salvatore Sanfilippo
This is a very interesting question Seandon, thanks for asking :-)
I could reply you with a pragmatic solution, that is: for every
connection, you can just also XREAD for an "unblocking" dummy stream
called UNBLOCK_<connection-id>, and then XADD to that from another
connection to trigger an immediate return of the call, so that you can
add the other keys to monitor to the next call. However that would be
practically useful but insufficient to really reply to your question.
Probably we should consider if it is useful to have a "CLIENT UNBLOCK
<id>" call, so that other connections can unblock clients in any
blocking call in a more clean way. I'm not considering ways to unblock
a connection directly from the connection itself by sending some
special control sequence, because it looks like out of scope right now
(but potentially applicable to RESP3) and because to use a different
connection is probably simpler in practical terms for almost every
possible use.
https://twitter.com/antirez/status/1011921121648762885
Cheers,
Salvatore
Post by Seandon Mooy
Hello!
I'm working with the new XADD/XREAD commands, and am trying to
devise a client library for working with the streams feature. XREAD is a
blocking call, but accepts multiple streams to read per XREAD call. I
certainly don't want to design a system where, for example, an API to make
use of redis streams to provide real-time streaming logs, per-user, I would
need one connection to redis per user (ie: one connection for one stream).
I would like to "pool" the subscriptions and read from multiple streams -
but this implies that I must wait the full BLOCK time to add a
subscription. Put another way, if I limit myself to
one-redis-connection-per-application, how do I effectively read from more
than one stream, on demand.
Post by Salvatore Sanfilippo
Post by Seandon Mooy
I have built a very crude pool system, where I allow up to N number
of redis connections, adding new XREAD calls as requests for subscriptions
come in. When an XREAD returns, I check to see if another XREAD is handling
this connection's streams, and if not I issue a new one for all desired
streams - ie: trying hard to eventually wind up with 1 XREAD. With a
"BLOCK" of one second, this effectively limits response time after _N
requests per second_! This is a scaling issue for me and feels like a poor
design on my part.
Post by Salvatore Sanfilippo
Post by Seandon Mooy
Does anyone have any ideas on this? I've been looking for a signal
I can send down the connection that will "cancel" an XREAD call, but all I
can manage to do is quit the connection entirely :P
Post by Salvatore Sanfilippo
Post by Seandon Mooy
Thanks for reading!
P.S. huge redis fan / user - I gave a talk at RedisConf17 and would
love to do another some day!
Post by Salvatore Sanfilippo
Post by Seandon Mooy
- Seandon
--
You received this message because you are subscribed to the Google
Groups "Redis DB" group.
Post by Salvatore Sanfilippo
Post by Seandon Mooy
To unsubscribe from this group and stop receiving emails from it,
Visit this group at https://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/d/optout.
--
Salvatore 'antirez' Sanfilippo
open source developer - Redis Labs https://redislabs.com
"If a system is to have conceptual integrity, someone must control the
concepts."
— Fred Brooks, "The Mythical Man-Month", 1975.
--
Salvatore 'antirez' Sanfilippo
open source developer - Redis Labs https://redislabs.com
"If a system is to have conceptual integrity, someone must control the
concepts."
— Fred Brooks, "The Mythical Man-Month", 1975.
--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at https://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+***@googlegroups.com.
To post to this group, send email to redis-***@googlegroups.com.
Visit this group at https://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/d/optout.
Seandon Mooy
2018-11-04 23:28:28 UTC
Permalink
Hello!

I published a working Node.js module that wraps XREAD / CLIENT UNBLOCK
semantics such that new subscriptions can be added to a single connection
in real-time without needing more than 2 redis client handles (one for
XREAD and one for CLIENT UNBLOCK and other writes). Hopefully this makes
working with Redis streams extremely easy for any Node programmers out
there!

Thanks again Salvatore!

- Seandon Mooy
Post by Salvatore Sanfilippo
Thanks! Nice we had this exchange turning into a feature.
Post by Seandon Mooy
Fantastic! Exactly what I was looking for - using a different connection
to UNBLOCK is perfect (and probably better / more flexible). Will give the
"client-unblock" branch a go later tonight!
Thanks!
Post by Salvatore Sanfilippo
P.S. I just pushed an implementation of "CLIENT UNBLOCK" into the
"client-unblock" branch at Github.
Post by Salvatore Sanfilippo
This is a very interesting question Seandon, thanks for asking :-)
I could reply you with a pragmatic solution, that is: for every
connection, you can just also XREAD for an "unblocking" dummy stream
called UNBLOCK_<connection-id>, and then XADD to that from another
connection to trigger an immediate return of the call, so that you can
add the other keys to monitor to the next call. However that would be
practically useful but insufficient to really reply to your question.
Probably we should consider if it is useful to have a "CLIENT UNBLOCK
<id>" call, so that other connections can unblock clients in any
blocking call in a more clean way. I'm not considering ways to unblock
a connection directly from the connection itself by sending some
special control sequence, because it looks like out of scope right now
(but potentially applicable to RESP3) and because to use a different
connection is probably simpler in practical terms for almost every
possible use.
https://twitter.com/antirez/status/1011921121648762885
Cheers,
Salvatore
Post by Seandon Mooy
Hello!
I'm working with the new XADD/XREAD commands, and am trying to
devise a client library for working with the streams feature. XREAD is a
blocking call, but accepts multiple streams to read per XREAD call. I
certainly don't want to design a system where, for example, an API to make
use of redis streams to provide real-time streaming logs, per-user, I would
need one connection to redis per user (ie: one connection for one stream).
I would like to "pool" the subscriptions and read from multiple streams -
but this implies that I must wait the full BLOCK time to add a
subscription. Put another way, if I limit myself to
one-redis-connection-per-application, how do I effectively read from more
than one stream, on demand.
Post by Salvatore Sanfilippo
Post by Seandon Mooy
I have built a very crude pool system, where I allow up to N
number of redis connections, adding new XREAD calls as requests for
subscriptions come in. When an XREAD returns, I check to see if another
XREAD is handling this connection's streams, and if not I issue a new one
for all desired streams - ie: trying hard to eventually wind up with 1
XREAD. With a "BLOCK" of one second, this effectively limits response time
after _N requests per second_! This is a scaling issue for me and feels
like a poor design on my part.
Post by Salvatore Sanfilippo
Post by Seandon Mooy
Does anyone have any ideas on this? I've been looking for a signal
I can send down the connection that will "cancel" an XREAD call, but all I
can manage to do is quit the connection entirely :P
Post by Salvatore Sanfilippo
Post by Seandon Mooy
Thanks for reading!
P.S. huge redis fan / user - I gave a talk at RedisConf17 and would
love to do another some day!
Post by Salvatore Sanfilippo
Post by Seandon Mooy
- Seandon
--
You received this message because you are subscribed to the Google
Groups "Redis DB" group.
Post by Salvatore Sanfilippo
Post by Seandon Mooy
To unsubscribe from this group and stop receiving emails from it,
Visit this group at https://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/d/optout.
--
Salvatore 'antirez' Sanfilippo
open source developer - Redis Labs https://redislabs.com
"If a system is to have conceptual integrity, someone must control the
concepts."
— Fred Brooks, "The Mythical Man-Month", 1975.
--
Salvatore 'antirez' Sanfilippo
open source developer - Redis Labs https://redislabs.com
"If a system is to have conceptual integrity, someone must control the
concepts."
— Fred Brooks, "The Mythical Man-Month", 1975.
--
You received this message because you are subscribed to the Google Groups
"Redis DB" group.
To unsubscribe from this group and stop receiving emails from it, send an
<javascript:>.
Visit this group at https://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+***@googlegroups.com.
To post to this group, send email to redis-***@googlegroups.com.
Visit this group at https://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/d/optout.
Seandon Mooy
2018-11-04 23:29:25 UTC
Permalink
And as it's usually helpful to -link- to something when you post about
it.....*facepalm*...... https://github.com/erulabs/redis-streams-aggregator
Post by Seandon Mooy
Hello!
I published a working Node.js module that wraps XREAD / CLIENT UNBLOCK
semantics such that new subscriptions can be added to a single connection
in real-time without needing more than 2 redis client handles (one for
XREAD and one for CLIENT UNBLOCK and other writes). Hopefully this makes
working with Redis streams extremely easy for any Node programmers out
there!
Thanks again Salvatore!
- Seandon Mooy
Post by Salvatore Sanfilippo
Thanks! Nice we had this exchange turning into a feature.
Post by Seandon Mooy
Fantastic! Exactly what I was looking for - using a different connection
to UNBLOCK is perfect (and probably better / more flexible). Will give the
"client-unblock" branch a go later tonight!
Thanks!
Post by Salvatore Sanfilippo
P.S. I just pushed an implementation of "CLIENT UNBLOCK" into the
"client-unblock" branch at Github.
Post by Salvatore Sanfilippo
This is a very interesting question Seandon, thanks for asking :-)
I could reply you with a pragmatic solution, that is: for every
connection, you can just also XREAD for an "unblocking" dummy stream
called UNBLOCK_<connection-id>, and then XADD to that from another
connection to trigger an immediate return of the call, so that you
can
Post by Salvatore Sanfilippo
add the other keys to monitor to the next call. However that would be
practically useful but insufficient to really reply to your question.
Probably we should consider if it is useful to have a "CLIENT UNBLOCK
<id>" call, so that other connections can unblock clients in any
blocking call in a more clean way. I'm not considering ways to
unblock
Post by Salvatore Sanfilippo
a connection directly from the connection itself by sending some
special control sequence, because it looks like out of scope right
now
Post by Salvatore Sanfilippo
(but potentially applicable to RESP3) and because to use a different
connection is probably simpler in practical terms for almost every
possible use.
https://twitter.com/antirez/status/1011921121648762885
Cheers,
Salvatore
Post by Seandon Mooy
Hello!
I'm working with the new XADD/XREAD commands, and am trying to
devise a client library for working with the streams feature. XREAD is a
blocking call, but accepts multiple streams to read per XREAD call. I
certainly don't want to design a system where, for example, an API to make
use of redis streams to provide real-time streaming logs, per-user, I would
need one connection to redis per user (ie: one connection for one stream).
I would like to "pool" the subscriptions and read from multiple streams -
but this implies that I must wait the full BLOCK time to add a
subscription. Put another way, if I limit myself to
one-redis-connection-per-application, how do I effectively read from more
than one stream, on demand.
Post by Salvatore Sanfilippo
Post by Seandon Mooy
I have built a very crude pool system, where I allow up to N
number of redis connections, adding new XREAD calls as requests for
subscriptions come in. When an XREAD returns, I check to see if another
XREAD is handling this connection's streams, and if not I issue a new one
for all desired streams - ie: trying hard to eventually wind up with 1
XREAD. With a "BLOCK" of one second, this effectively limits response time
after _N requests per second_! This is a scaling issue for me and feels
like a poor design on my part.
Post by Salvatore Sanfilippo
Post by Seandon Mooy
Does anyone have any ideas on this? I've been looking for a
signal I can send down the connection that will "cancel" an XREAD call, but
all I can manage to do is quit the connection entirely :P
Post by Salvatore Sanfilippo
Post by Seandon Mooy
Thanks for reading!
P.S. huge redis fan / user - I gave a talk at RedisConf17 and would
love to do another some day!
Post by Salvatore Sanfilippo
Post by Seandon Mooy
- Seandon
--
You received this message because you are subscribed to the Google
Groups "Redis DB" group.
Post by Salvatore Sanfilippo
Post by Seandon Mooy
To unsubscribe from this group and stop receiving emails from it,
Visit this group at https://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/d/optout.
--
Salvatore 'antirez' Sanfilippo
open source developer - Redis Labs https://redislabs.com
"If a system is to have conceptual integrity, someone must control
the
Post by Salvatore Sanfilippo
concepts."
— Fred Brooks, "The Mythical Man-Month", 1975.
--
Salvatore 'antirez' Sanfilippo
open source developer - Redis Labs https://redislabs.com
"If a system is to have conceptual integrity, someone must control the
concepts."
— Fred Brooks, "The Mythical Man-Month", 1975.
--
You received this message because you are subscribed to the Google
Groups "Redis DB" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at https://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+***@googlegroups.com.
To post to this group, send email to redis-***@googlegroups.com.
Visit this group at https://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/d/optout.
Loading...