A custom requst/reply topology builder.

[mzabolotko]

Hello. I need to use a custom request/reply topology builder. How can I inject this into the chinchilla bus instance? Or what do you think about approaches to implement this?

[jonnii]

Right now there's no easy way to do that. You'd need to pull out the entire RequesterFactory and implement that whole thing yourself. The Request/Response works, but isn't really ready for prime time yet. For example it doesn't yet have a way to turn on publisher confirms etc... What kind of topology do you want to build for request/reply?

[mzabolotko]

I want to use named queues and exchanges. For example, the requester defines the exchange (with provided name) where request messages will send to, and create the reply subscriber. The reply subscriber will create the exchange and queue (with provided name) where reply messages will send to. The DeliveryContext will use the "reply-to" property to find the exchange created by the reply subscriber to send reply messages.

[jonnii]

So here are the problems with request/response as it is currently implemented:

• Requester.Start has hardcoded topology builder and delivery strategy. The whole subscription strategy should be customisable.
• Request.Start creates a really basic publisher, the reply-to queue name is set to the subscription queue. It should be able to be configured to use publisher confirms etc...
• Right now the requester response handler is very opinionated about errors (it throws lots of exceptions), this should be configurable
• DeliveryContext does the simplest thing possible, which is create a new publisher and publish a reply to that message on it using the reply to. It does not build any topology, but assumes that the requester has created all the necessary plumbing (which it probably should...), unless you want to use topic based responses, or header based responses, in which case that should be configurable (maybe?). Either way, the fact that the publisher is single use isn't great, but I'm not sure what the right solution is given the current design.

I think each of those should be a separate pull request, as they're all incremental improvements.

How would you like to tackle this? IMO the DeliveryContext change is the most intrusive as it will probably require extending the IBus interface to add some kind of Publisher cache or something.