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

Question: Paranoid Pirate Pattern auto re-connect for workers and clients on queue restart #9

Open
vxmark opened this issue Sep 18, 2019 · 2 comments · May be fixed by #10
Open

Question: Paranoid Pirate Pattern auto re-connect for workers and clients on queue restart #9

vxmark opened this issue Sep 18, 2019 · 2 comments · May be fixed by #10

Comments

@vxmark
Copy link
Contributor

vxmark commented Sep 18, 2019

This question is related to the Paranoid Pirate Pattern sample project:

Is it by intention that the Paranoid Pirate Pattern is not supposed to recover from a restart of the Queue component or is this an error of the sample implementation (or even NetMQ core) which needs to be fixed?

Steps to reproduce:

  1. start queue
  2. start a worker
  3. start a client
  4. stop queue
  5. wait for a timeout message of worker and/or client printed to console
  6. restart queue

After these steps messages from clients wont be processed anymore despite all components (queue + worker + client) are up and running again after step 6.

@vxmark
Copy link
Contributor Author

vxmark commented Sep 19, 2019

Problem located inside the worker component.

On every (heartbeat-) timeout inside the worker it will completely dispose the DealerSocket and then create a new one. But for this newly created DealerSocket the event wireup for ReceiveReady is missing. This way the new DealerSocket won't react to any incoming messages.

@vxmark vxmark linked a pull request Sep 19, 2019 that will close this issue
@vxmark
Copy link
Contributor Author

vxmark commented Sep 20, 2019

For reproduction of the actual error I would recommend to disable the "crash simulation" inside the worker component. This simulation will most probably fire before one is able to see the actual error which I am addressing with this issue / pull request.

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

Successfully merging a pull request may close this issue.

1 participant