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
func (r*Consumer) onConnError(c*Conn, data []byte) {}
Maybe instead of using just one delegate, we could have a slice of ConnDelegates in the consumer? Since those are not exported, that would not change the API and will not affect the existing users.
In order to keep backwards compatibility, we'd have to create a
Constructor, or even better, looking into the future where someone else may need configuring something else, the constructor may accept functional options with something like:
Of course, another option would be adding a ConnDelegate slices into the existing Config, but I'm not sure how open is that for accepting behaviours instead of just values.
The text was updated successfully, but these errors were encountered:
Of course, another option would be adding a ConnDelegate slices into the existing Config, but I'm not sure how open is that for accepting behaviours instead of just values.
I'm curious at what this implementation would look like, as I'd prefer to not have the "how should we set options" debate and instead more specifically think through the tradeoffs of making it possible for users to chain delegates.
We want to instrument our NSQ clients and detect the
E_FIN_FAILED
errors received here:go-nsq/conn.go
Lines 530 to 532 in 61f49c0
It looks like the best way of doing this would be to implement a custom
ConnDelegate
listening to theOnError
method:go-nsq/delegates.go
Lines 66 to 68 in 61f49c0
Instead of just calling
consumerConnDelegate
go-nsq/delegates.go
Line 111 in 61f49c0
Which actually does nothing
go-nsq/consumer.go
Line 680 in 61f49c0
Maybe instead of using just one delegate, we could have a slice of
ConnDelegate
s in the consumer? Since those are not exported, that would not change the API and will not affect the existing users.In order to keep backwards compatibility, we'd have to create a
Constructor, or even better, looking into the future where someone else may need configuring something else, the constructor may accept functional options with something like:
Of course, another option would be adding a
ConnDelegate
slices into the existingConfig
, but I'm not sure how open is that for accepting behaviours instead of just values.The text was updated successfully, but these errors were encountered: