On 23/09/2016 2:18 AM, Zhai, Edwin wrote:
> > There are many targets(topics)/endpoints in above ceilometer code. But > in AODH, we just have one topic, 'alarm.all', and one endpoint. If it is > still multi-threaded, there is already potential race condition here, > but event-alarm tiemout make it worse. > > https://github.com/openstack/aodh/blob/master/aodh/event.py#L61-L63 see my reply to other message, but yes, it is multithreaded. there's not race currently because we don't do anything that needs to honour ordering. > > event evaluator is triggered by event only, that is, it's not called at > all until next event comes. If no event comes, evaluator just sleeps so > that can't check timeout and update_alarm. In other words, 'timeout.end' > is just for waking up evaluator. > what's the purpose of the thread being created? i thought the idea was to receive alarm.timeout.start event -> creates a thread? can we not: 1. receive alarm.timeout.start -> create an alarm with timeout thread 2a. if event received, kill timeout thread, update alarm. 2b. if timeout reached, send alarm notification, update alarm. ^ that is just a random thought, i didn't think about exactly how to implement. right now i'm not clear who is generating this alarm.timeout.end event and why it needs to do that at all. cheers, -- gord __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
