#83 It is difficult to process events in order - Adhearsion

Type	To find
responsible:me	tickets assigned to you
tagged:"@high"	tickets tagged @high
milestone:next	tickets in the upcoming milestone
state:invalid	tickets with the state invalid
created:"last week"	tickets created last week
sort:number, importance, updated	tickets sorted by #, importance or updated
Combine keywords for powerful searching.
Use advanced searching »

#83 ✓invalid

It is difficult to process events in order

Reported by dimas | September 14th, 2009 @ 07:45 AM

i'm writign standalone Ruby application which hooks into AMI event stream and reacts to some events. The application does something like:

require 'adhearsion/events_support'
  Adhearsion::Events.framework_theatre.start!
  Adhearsion::Events.register_callback %w[asterisk manager_interface] do |event|
    puts event.inspect
  end

except that it does some real processing instead of "puts event.inspect"

The problem is that sometimes I receive events in wrong order. To my understanding this happens because the Theatre created by events_support is initialized with default 6 thread count so if events come in fast but processing of some of them takes time, another event will can be pulled by another thread and processed first.

Putting critical section/monitor/whatever inside my event processing loop does not help because the Theatre can still dequeue event in one thread, then context switch occurs and another thread dequeues and processes another event. Some sort of race conditions.

What could help me is to tell Theatre to use only one thread. However I can not do that because Theatre initialization is controlled by events_support which does not let specifying thread count...

Comments and changes to this ticket

You flagged this item as spam.
dimas November 14th, 2009 @ 06:17 PM
In 0.8.3 I saw
```
        # TODO: Extract number of threads to use from AHN_CONFIG
        @@framework_theatre = Theatre::Theatre.new
```
which looks like a Good Thing :)
However if the whole config stuff needs to be designed first (soeey I'm not aware of what is there already), it can take very long time.

How about adding theatre_thread_count static (class) variable to Adhearsion::Events which defaults to nil but calling code can change its value. If value is not nil it is passed to Theatre.new.
Later when config is added, you can extend the check like:
1. if theatre_thread_count is not nil - use it
2. if theatre_thread_count is not overriden load a value from config.
3. if config does not specify value, use default.

This way you can quickly add ability to specify number of threads while still allow doing the same with config when it is ready.
Jay Phillips November 14th, 2009 @ 08:19 PM
- State changed from “new” to “open”
If you're using this in a standalone Ruby process and want only to capture events in order, I'd probably recommend subclassing ManagerInterface and overriding event_message_received():
```
class MyManager < Adhearsion::VoIP::Asterisk::Manager::ManagerInterface
  def event_message_received(event)
    p event
  end
end

# Connect MyManager to Asterisk...
MyManager.connect ........ # normal args here
```
You flagged this item as spam.
dimas November 14th, 2009 @ 08:45 PM
Hmmm... how stupid of me.
Yeah I guess it will work and it probably much more clean approach than trying to tune Theatre for my needs.

I believe this one can be closed.
Ben Klang August 2nd, 2010 @ 02:38 PM
- State changed from “open” to “invalid”
- Milestone order changed from “0” to “0”
Closing per reporter.

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.