Client should not block on GOMAXPROCS receivers.#574
Client should not block on GOMAXPROCS receivers.#574n3wscott merged 6 commits intocloudevents:masterfrom
Conversation
Signed-off-by: Scott Nichols <snichols@vmware.com>
Signed-off-by: Scott Nichols <snichols@vmware.com>
Signed-off-by: Scott Nichols <snichols@vmware.com>
Signed-off-by: Scott Nichols <snichols@vmware.com>
|
@liu-cong can you try this patch and let me know if it solves your issue? |
Signed-off-by: Scott Nichols <snichols@vmware.com>
…ow with the blocking tests. Bump integration timeout. Signed-off-by: Scott Nichols <snichols@vmware.com>
| cecontext.LoggerFrom(ctx).Warnf("Error while handling a message: %s", err) | ||
| } | ||
| // Do not block on the invoker. | ||
| wg.Add(1) |
There was a problem hiding this comment.
Do we really need to synchronize the Invoke on the wg? If Invoke ends after these goroutines loop, is this a potential issue?
There was a problem hiding this comment.
it just lets us know to block if invoke is happening when the process is spinning down
There was a problem hiding this comment.
that's my point, do we need to wait for invoke to finish before spinning down these goroutines? isn't this done automatically by the runtime?
There was a problem hiding this comment.
It is not done automatically. We would return from this loop and exit the process before the invokers had a chance to finish on a soft sig-term
|
Ping on @liu-cong @slinkydeveloper want to LGTM? |
|
/lgtm Thanks @n3wscott for the quick fix! I haven't tried this patch. However, I previously tried a similar/same patch locally so I believe it will work as expected :) |
Fixes: #569
Signed-off-by: Scott Nichols snichols@vmware.com