One of my event listening task (event_handler) is taking long time to processing. So is there any way to emit the event and let it work as async function without await? Thank !!
Can you explain in more detail what you’re trying to achieve?
The event_handler entrypoint is async by default – there is no client waiting for an answer. The only thing that waits for the method to finish is the ACK of the event message. It is implemented this way to make sure that, if the worker is interrupted somehow, the message is requeued for another handler to pick up.
Hi mattbennett, Thank for your response.
My requerment is just want to dispatch the event handler without waiting, but in my case after dispatching the event_handler the EventDispatcher is keep waiting until the event_handler done process. Is ACK will respond back after the process done? or is there any configuration that I missed ?
I have attached some references to my case, as you can see there is a sleep for 20s in test event_handler. When I dispatched this event, I expected it to take less than 20 seconds, but it almost never did. As I noted, the dispatcher will complete after the event_handler done its operation.
Event dispatching service
Event listening service
Reuslt
Addition
I expected this event dispatcher to work, such as when I wrap event dispatcher in thread, since it worked when I use eventlet.spawn(event dispatcher).
You’re right to be confused. The “dispatch duration” printed should be milliseconds.
How are you running these services? It looks to me like you have not applied the eventlet monkey patch.
Hi @mattbennett thank for your response.
I have applied the eventlet monkey patch in my project.
And I found that, it because I run rpc and event handler service in ServiceRunner. It turn woking well asynchronously when I run service Individually. I got the same behavior when I tested with the nameko shell to run services. So mostly we don’t run rpc and event handler service in the same ServiceRunner?
I’m glad that applying the monkey patch solved your problem.
Nameko can run multiple services inside the same runner without any problem. It’s often helpful to do this, for example when testing multiple services interoperating, but in production I recommend using a runner per service. That makes it easier to reason about things, and you generally get more capacity because (on a multi-core host) each service runner will potentially occupy its own core.