Conversation
|
I don't think it makes sense to have two methods to unsubscribe on a topic. What about the current method doesn't work for you? Also, the method you introduced has a memory leak in that the pool isn't being cleared when the client is closed, so the handlers are kept in memory forever. |
|
as any other event based library I think it makes sense to unsubscribe a specific handler ( event ) from the registry, There are scenarios where events ( handlers ) are dynamic and temporary, I've being part of complex real time micro service infrastructures and Thanks for the catch, I'll add a commit to clear the pool on |
|
This is a pretty breaking change, would you mind if we got more people to chime in that they want it before going forward? It'd also make sense to remove the existing |
|
Also, it'd be better to have the pool be a property under nsp since then you wouldn't have any global variables and it would be garbage collected along with the nsp instance. |
|
Sure, lets have more minds on what makes more sense. I added it basically because I need it on a current app I'm working on. Also I think we can split the code on methods ( if you think is a good idea ) like |
Add
.offand.unsubscribeGiven
We currently can subscribe a handler to a channel
This PR adds the ability to unsubscribe a handler from a channel