From @rizplate on Fri Jul 20 2018 18:42:24 GMT+0000 (UTC)
If max_workers setting is set to 1, does it mean that nameko waits until the service class method is completed and then sends the next message? i.e. work as a regular queue?
also is there a way that I can log or see current state of system i.e.
- num of services
- num of services-methods active
- num of request/response for each service-method
does nameko provide at-least once or at most once guarantees, is it configurable? i.e. how does retry happens? does it offload retries to rabbitmq or does something on its own, i.e. timeout or exception retry?
Copied from original issue: https://github.com/nameko/nameko/issues/558
From @mattbennett on Fri Jul 27 2018 19:50:39 GMT+0000 (UTC)
Q1: It means that exactly one worker executes at a time. If your worker is consuming from a queue (e.g. an event hander or RPC queue) then I think yes, it’s working as you expect as a “regular queue”
Q2: Not out of the box, no. You may find the nameko-tracer project useful for tracking request/responses though. It would not be hard to build a service-registration extension to track the number of services and their entrypoints either.
Q3: For the AMQP extensions, it is at-least-once and it’s not currently configurable. Messages are ack’d at the end of the service method, and if the connection is lost after delivery but before acknowledgement, RabbitMQ will reclaim and redeliver the message. You could change this behaviour with custom extensions that acknowledged the message before executing the service method.
If you have more questions about retries and timeouts, please ask them on the mailing list