-
Notifications
You must be signed in to change notification settings - Fork 62
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
remove group member, subscriber and workers when unsubscribing #96
Conversation
@pedro-gutierrez Thanks very much! We'll check this out. I need to remember what I was thinking with #59. 😄 |
@pedro-gutierrez One thing I was thinking about after I read my comments in #59 was the results from |
Hey @objectuser thanks for having a look at that! Actually, I did check with the observer, and I had the impression processes where properly removed, but please let me come back with some screenshots, so we can both confirm it. |
Hey, so I did a simple test, as follows. I start with 4 topics, named "topic.a", "topic.b", "topic.c" and "topic.d". Here is the state of my supervision tree: Then I call:
As a result, the new state of my supervision tree becomes: That seems to remove the subscriber process ok. However if I try to unsubscribe from multiple topics in a single call, it crashes.
I think the way I am stopping workers is not correct, or I am stopping too many workers, or both :) |
I removed the code that attempts to stop the consumer group worker, and now it seems to behave better. Here is my supervision tree after I unsubscribe from topic.a: Then if I unsubscribe from the rest of the topics:
I end up with this tree: I guess I would still need to delete worker_0, but only when there are |
@pedro-gutierrez I wonder if this is really trying to do more work than necessary. I called Would it be enough to just kill the subscriber and update the state? However, if the intent is that the other subscribers should not be impacted, I don't think this has the desired effect, since they're all killed anyway. For example, I didn't see this statement ever logged: Logger.debug("Stopping worker: #{topic} / #{partition}") Are you seeing something different? |
This PR iterates on the work done a while ago by @dams in #59.
It is still a bit rough, and it probably deserves some more testing, however at this stage, I was wondering whether the approach is correct or not?
Thanks!