Typical Queue implementation looks missing in redis

[ocmvin]

Typical point-to-point (i.e. queue) semantics where e.g. multiple receivers are registered with a single queue and as soon as a message is pushed to the queue it will be processed by only 1 receiver (listener)
Unlike PUBLISH -SUBSCRIBE redis commands there is no direct support to queue Though there is alternative as below
1 : LPUSH msgqueue
2: loop till the message is available as below
while running
BRPOP msgqueue
# process popped item
done

#2 downside of this is that redis client has to unnecessary query to msgqueue and kind of westing of resources. Ideally redis should push the messages to listeners who are listening on give queue .

[itamarhaber]

Hello @ocmvin

unnecessary query to msgqueue and kind of westing of resources

The client is blocked, it isn't actively querying but simply waiting for the server to send a message (i.e. "push the messages") until the timeout is exhausted.

[ocmvin]

@itamarhaber Thanks. But expecting simillar behaviour as Queue .Where Producer would send say 100 messages and for those 100 messages we have to keep 100 clients blocked right ? There is no direct call back from redis in typical asynchronous way .
I have a requirement where I need to read a file and put on middleware and on other end listener would process the each message sent by sender.As a workaround I have while loop running with time out as 0 (which blocks until a message is read )
Also as a Workaround I can do like

1: Put messages on Queue
redis 127.0.0.1:6379> LPUSH QUE ttt
(integer) 1
redis 127.0.0.1:6379> LPUSH QUE ttt1
(integer) 1
redis 127.0.0.1:6379> LPUSH QUE ttt12

2: Check length of messages in queue
redis 127.0.0.1:6379> LLEN QUE
(integer) 3

2: block client those many times ie 3
Alls together need to handle at client side implementation