Applied direct reply-to logic - next steps and feedback

[npaschos]

I changed the callback_queue from a user-created one to amq.rabbitmq.reply-to. This has resolved the issues described in the README, but I fail to understand why the previous approach did not work.

Also, the code now always uses the direct reply-to logic, is this the best choice?

I would also like some feedback on the things to consider when expanding this code base to a client and server that can recover from connection issues and whether I should start compiling an example of a non-blocking connection.

[lukebakken]

I'm assuming you've read this?

https://www.rabbitmq.com/direct-reply-to.html

Update - I see you mention that document in your pull request. Unfortunately I have not had time to review this code in depth.

My first thought is that any production-ready RPC server and client should be built using SelectConnection and not BlockingConnection since the latter requires hacks like calling process_data_events and sleep to work. I suggest that your next step be to look at the asynchronous producer / consumer example code for Pika and use those as a starting point.