search

mxriverlynn / rabbus

A micro-service bus with built-in messaging patterns, for NodeJS and RabbitMQ
116 stars 26 forks source link

Response / Request - creating the Responder without exchange and routingKey not working #23

Open dimaxweb opened 8 years ago

dimaxweb commented 8 years ago

Hello,

In the demo example we supposed to create the response with following options :

exchange: "req-res.exchange", queue: { name: "req-res.queue", limit: 1 }, routingKey: "req-res.key"

and this is working.

If I understand correctly the implementation creates response queue per request and that's why we need routing key and exchange in Consumer ..? Because generally consumer only need queue name ..?

We need implementation of queue per client as described here

using the correlation_id .Is it possible with Rabbus ?

shurik239 commented 8 years ago

Consumer definition needs exchange and routing key to define binding. Without this message is not coming to consumer queue.

Regarding reply with correlation_id please take a look to this discussion - #17

mxriverlynn commented 8 years ago

@shurik239 is right, at this point. the current release of rabbus requires either a routing key or message type. there is work being done in #21 to make it so that you don't have to specify a routing key, though. part of the work in #21 relies on a new release of the underlying wascally library, though. release of this next major rabbus version will depend on wascally, then.

If I understand correctly the implementation creates response queue per request

not quite right - the basic request/response pattern is baked into wascally, and creates a response queue per client connection (i think). if you have one consumer process, you will probably have 1 response queue created already. wascally handles the management of correlation id to make sure the reply gets to the right callback method.

We need implementation of queue per client

the underlying library, wascally, makes this slightly difficult at the moment. there's a compounding issue with the message type that wascally supports. there's some info about this in the rabbus readme (look for "message type") and in the wascally library, too.

the next release of wascally will fix this, so that message type is no longer required, and a consumer can be bound to a specific queue, only.

in general, though, you can achieve what you are looking for, with the current release. it just gets slightly more complex when adding message type into the mix.