@event_handler('trainproxy', 'timer_alert', handler_type=SINGLETON)

32 views
Skip to first unread message

coddericko

unread,
Jul 26, 2018, 6:50:35 PM7/26/18
to nameko-dev
Hi,

I have a question howe nameko works.

We are create a nameko service as a proxy to another service that is not using eventing (eg: we need to poll it to check status)

Since we are using polling, we initially using @timer constructor to do this polling and firing event on this service that we are trying to eventized. 

The trouble comes when our system is under stress, timer method is still running and another timer get triggered.

In order to avoid using DB locks, we continue to use a timer method, but use it to dispatch an event that will be consumer by another event_handler

In the event handler, we do this construct:
@event_handler('trainproxy', 'timer_alert', handler_type=SINGLETON)

We hope this means that only one and only one instance is handing a event. This will be still true if we have multiple instances of the service. Is this correct?


KBNi

unread,
Jul 27, 2018, 2:36:58 AM7/27/18
to nameko-dev
I believe you are correct, but if the service which has the timer runs multiple times you will still have multiple executions..

foode...@gmail.com

unread,
Jul 27, 2018, 3:15:59 AM7/27/18
to nameko-dev
My idea is this...

@timer(interval=os.getenv('TRAIN_TIMER', DEFAULT_TIME_INTERVAL))
def _ping(self):

This will send a message in a queue periodically... so even if my event_handler method slows to a crawl.. only 1 method can be running at the same time even with multiple instance of the service with:

@event_handler('trainproxy', 'timer_alert', handler_type=SINGLETON)

So that is why i hope we are using SINGLETON as expected. Thanks for your feedback !

foode...@gmail.com

unread,
Jul 27, 2018, 1:01:54 PM7/27/18
to nameko-dev
Yesterday,

I ran a performance/ stress on this piece of code... We realize that when the system is loaded... we can get 2 copies of running code from the timer at the same time. We tot we fix this using this 'smart' way where only 1 event can be consume at a time... but it turns out that this is not true. We saw that the events are consume out of order and at the same time too. We are scratching our heads now... Out of order is a concern but for this is not bad... but 2 events being consume even after SINGLETON was used... is weird... 

Not sure if somebody can give some advice. It still could be a bug on our side... but we double check... all our persistence and logic seems right. Appreciate any tips...

Matt Yule-Bennett

unread,
Jul 27, 2018, 3:14:16 PM7/27/18
to nameko-dev
The "singleton" handler type doesn't mean that only one worker can execute at a time. If you want this behaviour, you must either set max_workers=1 for the whole service, or limit the prefetch_count of the event handler's consumer.

In the current version of Nameko it's not straightforward to set the prefetch_count. See https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!/nameko-dev/E91Yc81hzZg/-WPOH47XCAAJ for details. Overriding the prefetch_count will get much easier once https://github.com/nameko/nameko/pull/542 lands.

FYI what the "singleton" event hander actually means is that exactly one service instance across an entire cluster will receive the event, irrespective of the name of the service. Contrast this to "broadcast" (all instances receive the event) and "service pool" (the default, where exactly one instance of each uniquely named service receives the event). The "singleton" handler type is quite unintuitive and is likely to be removed in a future version. 
Reply all
Reply to author
Forward
0 new messages