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
Is your feature request related to a problem? Please describe.
Currently, producer.SendAsync can quickly become a blocking call if either:
The queue (set with maxPendingMessages) becomes full
The event channel (for enqueueing, handling disconnects, etc) becomes full (with a hardcoded 10 messages)
This can be really undesirable as it is unexpected that SendAsync becomes a blocking call.
Describe the solution you'd like
The golang producer needs an option equivalent to the java producerBuilder.blockIfQueueFull call. In this mode, any SendAsync call against a full queue (case 1 above) should result in an error. The semaphore implementation around the maxPendingMessages does not have a timeout or tryAcquire, but if it did, it should be easy to make work (perhaps consider switching to golang/x/sync/semaphore package?) and in the event the semaphore can't be acquired, then pop an error.
It seems to also make sense that if the internal eventChannel is also full, we should also error (case 2 above). For example, this can happen when a producer is disconnected and is waiting for a re-connect. The call to re-connect is blocking and (AFAICT) blocks further messages being processed on the eventChannel, which quickly fills up and then results in a blocking behavior on SendAsync. A non-blocking send into the eventChannel would probably work here, though we may need to increase the eventChannel size a bit
Describe alternatives you've considered
None
The text was updated successfully, but these errors were encountered:
Thanks @addisonj feedback, we designed this deliberately, when the sending speed is too fast, it will be blocked instead of returning an error to the user. Maybe we can change the documentation of sendAsync() to give users a clearer explanation.
Is your feature request related to a problem? Please describe.
Currently,
producer.SendAsync
can quickly become a blocking call if either:This can be really undesirable as it is unexpected that
SendAsync
becomes a blocking call.Describe the solution you'd like
The golang producer needs an option equivalent to the java
producerBuilder.blockIfQueueFull
call. In this mode, anySendAsync
call against a full queue (case 1 above) should result in an error. The semaphore implementation around the maxPendingMessages does not have a timeout or tryAcquire, but if it did, it should be easy to make work (perhaps consider switching to golang/x/sync/semaphore package?) and in the event the semaphore can't be acquired, then pop an error.It seems to also make sense that if the internal eventChannel is also full, we should also error (case 2 above). For example, this can happen when a producer is disconnected and is waiting for a re-connect. The call to re-connect is blocking and (AFAICT) blocks further messages being processed on the eventChannel, which quickly fills up and then results in a blocking behavior on
SendAsync
. A non-blocking send into the eventChannel would probably work here, though we may need to increase theeventChannel
size a bitDescribe alternatives you've considered
None
The text was updated successfully, but these errors were encountered: