Hi Jose,
Thanks for your attention again,
Jose Luna-2 wrote:
>
> You have to be sure to include the reply-to destination in the request,
> and then you know which destination to check for the response. Since we
> don't have access to temporary destinations, we simply make sure that
> destinati
> If I understood right, then each requesting service A (A1...An) should
> maintain its own unique correlation id (permanent during the connection's
> life).
My initial suggestion was actually to have a unique correlation-id for each
request. This provides greater granularity than the above pro
Jose,
Thank you for the solution. =)
If I understood right, then each requesting service A (A1...An) should
maintain its own unique correlation id (permanent during the connection's
life). That way message broker could decide which requesting service An to
route message to if two or more request
You can use two normal (non-temporary) queues, one for requests and one for
responses. Each request will have a correlation-id header. Let's call the
requesting service A and the responding service B. Service A will send to
/queue/requests. Service B will receive (consume) the request, and
