Question: Reliable queue using blocking commands

[lefig]

Hi,

We currently use Redis as a reliable queue and implement the reliable queue pattern using various commands that ultimately block. This avoids having a weak point in the architecture involving pubsub where there is no listener available.

I have taken a look at the multiplex guidance
https://stackexchange.github.io/StackExchange.Redis/PipelinesMultiplexers

This seems strange. Is the guidance saying that publishing/subscribing is required as a work around (for no blocking calls)?

Thank you

Fig

[mgravell]

if you want to avoid the pub/sub problem: perhaps consider redis streams; ultimately the architecture of the library is not amenable to blocking operations at the current time, unless I switch to a multi-connection pooled approach

[lefig]

Thanks for that. Yes, Thats what I thought but we are still with Redis 4.0 (without streams support). I have read some posts about using the interface to issue some "raw" commands such as
string foo = (string)db.Execute(
"JSON.GET", key, "[1].foo");
But this doesnt seem to be the reliable way to go.

[mgravell]

If you use the raw commands API to execute blocking operations, you should expect bad things to happen. For example, from the connection's perspective, it won't be responding to periodic heartbeat health checks, so it will sever the connection every so often...

…

On Wed, 10 Apr 2019, 19:01 lefig, ***@***.***> wrote: Thanks for that. Yes, Thats what I thought but we are still with Redis 4.0 (without streams support). I have read some posts about using the interface to issue some "raw" commands such as string foo = (string)db.Execute( "JSON.GET", key, "[1].foo"); But this doesnt seem to be the reliable way to go. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1117 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABDsOfSgTj_8PzvoKSVj3ohngoyDDrfks5vfibfgaJpZM4cm26T> .

[lefig]

I see. Thank you for confirming and for making this such an excellent product. We happen to use another Redis client that is rather connection pool focused. Initially I thought that this would be beneficial for performance. But the single connection multiplex design has made me rethink this.

[mgravell]

I do actually have a plan to experiment with a small implicit pool internally, for some specific scenarios, but: I also have 2 dozen other things I need to do (the new version of RESP, for example, for v6) - so it is a bit of a juggling act which things get done in which order.

…

On Thu, 11 Apr 2019, 09:25 lefig, ***@***.***> wrote: I see. Thank you for confirming and for making this such an excellent product. We happen to use another Redis client that is rather connection pool focused. Initially I thought that this would be beneficial for performance. But the single connection multiplex design has made me rethink this. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1117 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABDsKoS98ypgv3hJlKd1nq7os8XX_XXks5vfvGAgaJpZM4cm26T> .

[NickCraver]

Closing this due to inactivity, seems like we're good for the time being here.