You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While I make my messaging layer built on top of go-nsq behave consistently w.r.t. my consumer/producer stop methods, it would be nice if go-nsq's consumer/producer stop methods behaved similarly. Is there a particular reason that Consumer.Stop() is asynchronous and Producer.Stop() is synchronous?
Would a PR making them behave similarly be welcome? I'm honestly not sure which I prefer.
The text was updated successfully, but these errors were encountered:
@grepory - I would love for them to match. I prefer the synchronous API by default (and users can choose to make it async by launching goroutines).
Unfortunately, I missed this in our cleanup for go-nsqv1.0 so, at this point, it would be a breaking change. However, I've always been on the fence about naming them Stop() anyway (because it could be misconstrued to imply they can be started again), so maybe we can introduce a consistent Close() API and deprecate Stop()?
While I make my messaging layer built on top of go-nsq behave consistently w.r.t. my consumer/producer stop methods, it would be nice if go-nsq's consumer/producer stop methods behaved similarly. Is there a particular reason that Consumer.Stop() is asynchronous and Producer.Stop() is synchronous?
Would a PR making them behave similarly be welcome? I'm honestly not sure which I prefer.
The text was updated successfully, but these errors were encountered: