Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Timing: request calls #167

Open
ptusch opened this issue Jul 19, 2018 · 0 comments
Open

Timing: request calls #167

ptusch opened this issue Jul 19, 2018 · 0 comments

Comments

@ptusch
Copy link

ptusch commented Jul 19, 2018

There's an issue with the request.
Say you want to create a fresh connection and make your request, you might run into timing issues related to the replyQueue.

Upon connection creation, the replyQueue will be created (and bound) as well. Unfortunately, this event is not waited on - the addConnection call resolved as soon as a connection is created.
So when you make a request right after that you might run into a timing issue that you subscribe after the handler (server) already sent an answer.

Due to the nature of replyQueue, this message would be lost forever.
The fix for this seems easy to implement; in the topology, you gotta wait for the replyQueue.ready event from the queue. For even better safety, you should send the replyQueue.ready event, when you bound the queue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant