request-repsonse pattern with multiple clients and servers

[alexmalev]

In an architecture where i have multiple replicas of an http-server and multiple replicas of a microservice.

Say that each http server gets a request via REST and send a message to a microservice to perform a task and waits for its response.
How would you go about it using this lib as a transport?

specifically - if there are multiple http server clients that send messages to the microservices- how do i know that the same http-server that sends a message also gets the response and not the other http-server replica?

do i need to have a unique replyTopice / replySubscription per http-service (aka the publishing client)?

[alex-y-su]

I think there's no issue with the implementation of the transfer wrapper. Getting sticky sessions and pub/sub to work correctly can be quite challenging, regardless of the transport wrappers involved.

[p-fedyukovich]

In an architecture where i have multiple replicas of an http-server and multiple replicas of a microservice.

Say that each http server gets a request via REST and send a message to a microservice to perform a task and waits for its response. How would you go about it using this lib as a transport?

specifically - if there are multiple http server clients that send messages to the microservices- how do i know that the same http-server that sends a message also gets the response and not the other http-server replica?

do i need to have a unique replyTopice / replySubscription per http-service (aka the publishing client)?

Just checked the code and probably response message might be lost. I will explain: when client sends a message to microservice it generates unique id and stores with a message callback which is supposed to be executed once response message is received. If you have multiple client in this case response might be delivered to not original message producer and message will be just acked without response handling since id and callback pair is stored in different client. There are 2 ways to fix it:

1. have separate subscription per client replica.
2. nack message on client side if message handler is not found. Eventually message will be handled by original client

Second option IMO is better, since applications don't depend on infrastructure

[p-fedyukovich]

The second approach is implemented in #23