Fixed some functional issues and improved code readability #3
Conversation
there's possibility of memory leak when if goroutine exits not normally.
There's possibility of infinite loop in code. Resolved it by defining maxRetries
|
Welcome, Interval-0. Thank you for your first contribution! |
asheswook
added
enhancement
| @@ -136,6 +137,7 @@ func TestStreamConsumer_ConsumeClaim(t *testing.T) { | |||
| msg.DataChan = make(chan *sarama.ConsumerMessage, 1) | |||
|
|
|||
| go func() { | |||
| defer close(msg.DataChan) | |||
There was a problem hiding this comment.
Closing the channel is used as a signal that the channel is no longer in use. It is not related to memory leaks. So, 'close' should be called when the data transfer ends, rather than when the goroutine ends (defer).
There was a problem hiding this comment.
In this case deleted the code line (close) below and used the defer instead.
| for { | ||
| retryCount := 0 | ||
| maxRetries := 30 | ||
| for retryCount < maxRetries { |
There was a problem hiding this comment.
A transaction must be canceled if some error occurs, for exactly-once. So this is good for infinite loop, but this doesn't look good for business policy. In my opinion, it would be better to delay processing (time.Sleep) or log if cross the attempt threshold in a loop. (actually my suggestion is another business feature)
There was a problem hiding this comment.
If a transaction error occurs, it will one day be processed if the producer is okay, so no worry to infinite loop. If there is a problem with the producer, it is prevented by handling producer.TxnStatus()& sarama.ProducerTxnFlagFatalError
Title goes desc. lol