AMI and Thread Handling

Oct 11, 2013 at 3:15 PM
I had an email this week from an AsterNET user who asked about the thread handling in the ManagerConnection class of AsterNET's Manager framework.

The question related to an issue I've found myself when handling large volumes of AMI events.

When an event is received in the ConnectionManager.cs class it's fired off using:
internalEvent.BeginInvoke(this, e, new AsyncCallback(eventComplete), null);
This basically multiple events to be fired off without having to wait for the previous event to have been handled! Most of the time this is fine, but now and then this can cause issues, for example, with DTMF events. If a user enters a sequence of DTMF events, it's possible for the events to be received out of order in any application listening for DTMF events.

In the past, before I took over the job of maintaining the AsterNET framework, I implemented a dirty fix for this myself, buy changing the fireEvent method as follows:

Old Code
private void fireEvent(ManagerEvent e)
            if (enableEvents && internalEvent != null)
                internalEvent.BeginInvoke(this, e, new AsyncCallback(eventComplete), null);
New Code
private void fireEvent(ManagerEvent e)
            if (enableEvents && internalEvent != null)
                internalEvent.Invoke(this, e);
This simple change ensures that all AMI events are handled in order. However, if you are not worried about the order of events, this may not be ideal.

I've not implemented this change in AsterNET, but look to our community for feedback on this please. Is this an issue many are running into? Are there any better suggestions on how this issue can be addressed?
Oct 11, 2013 at 5:30 PM
(crasca please edit out the email rubbish from your reply)

All AMI events can be fixed using this method, but that's not to say it's the right way to do it.
Oct 11, 2013 at 5:35 PM
Ok sorry i'll try to remember.

I look for code for others events.

bye !!

Naso GianMario
via L. da Vinci, 215
17021 ALASSIO (SV)
Tel: 0182-640866

Ai sensi del Decreto Legislativo n. 196/2003,
si precisa che le informazioni contenute
in questo messaggio e negli eventuali allegati
sono riservate e per uso esclusivo del destinatario.
Persone diverse dallo stesso non possono copiare
o distribuire il messaggio a terzi.
Chiunque riceva questo messaggio per errore,
è pregato di distruggerlo e di informare
[email removed]
Oct 11, 2013 at 5:41 PM
HI there,
I'm the one report the problem, and using same "dirty" fix as your :-). I think we should have some configuration and user can choose they can spawn new thread when they fire an event, or finish fire event before fire next event.
For me, order of all events are critical in my business, and there is no need to spawn new thread when fire each event. If you want to have multiple threads to fire multiple events then do it outside of this scope, so you know when your program have multiple threads, and when it is not.
Oct 22, 2013 at 10:59 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.