Distinguish redis queues for multiple rmb-peer instances

[scottyeager]

The use case here is running multiple rmb-peer instances on the same system, to cover different networks (main, test, qa, dev). Currently, the rmb-peer input and reply queues are hard coded so each rmb-peer needs its own redis server, as far as I can see.

A simple way to accommodate multiple peers per redis would be allowing the user to pass in a namespace to add to the queue names. For example:

rmb-peer --namespace test ...

Resulting in these queue names:

test-msgbus.system.local
test-msgbus.system.replies

Or:

msgbus.test.system.local
msgbus.test.system.replies

[xmonader]

I think it could be also achieved by running multiple redis instances and specify the redis url to the rmb-peer arguments, but we aren't planning to do any changes at the moment in rmb regarding this in 3.11 :)

[scottyeager]

Yep, multiple redis instances should work and that's what I'll use for now.

No rush on this one. Just seems like a sensible and low effort feature to add :)

[muhamadazmy]

I agree with @xmonader , the rmb-peer was not designed to support running multiple instances and it's not a very common use case. The problem is that creation of namespaces means the client(s) also need to know about the namespace which can lead to confusions and mistakes. Peer clients are suppose to only to connect to local redis so multiple clients can share the same redis instance to talk to the peer.

I am not saying it's not possible, adding a namespace is not that hard, it's just against the concept imho. and for full separation multiple redis instances can be started on the node.