[Asterisk-java-users] Advanced Event Filtering

[Aaron E. <aar...@gm...>]

I would like to propose a feature for more advanced event filtering,
beyond what AMI provides.

I have a situation where I am interested in extension state changes
only.  So I can cut down the number of events by using the "cal" event
mask.

However, I am connecting to about a dozen asterisk servers all with
relatively high load.

I am concerned that with the number of events flowing into my
application I am worried about performance.

Event though my event listener may only process these extension status
change events, discarding all others, the asterisk java API will still
be building a very large number of these event objects at a very quick
rate.

Although the objects will be immediately available for garbage
collection, at the rate they are produced, the heap space could fill
quickly causing very frequent garbage collection.  Frequent garbage
collection can be very detrimental to JVM performance, depending on
the implementation.

I might be being overly cautious here. If you think I am, please say
something as I don't really want to make more work for myself
unnecessarily.

In order to supply the functionality I am describing, I think I may
add some kind of HashSet of eventTypes to act as a filter. If the set
is null or empty, then that means all events. Otherwise, it would be
limited to those in the set.

In order to avoid creating these ManagerEvent objects, I'm thinking
I'll inject the filter check in the buildEvent method of the
ManagerReaderImpl class.

This brings me to my next point/request.  While I could provide my own
ManagerReaderImpl by overriding the factory method in
ManagerConnectionImpl, the buildEvent method is private. :(

This means I can't just extend and override the ManagerReaderImpl.  In
fact, if I make a copy of this implementation to my application's
source tree, there are a great deal of classes and interfaces that are
not visible in the org.asteriskjava.manager.internal package (the
Dispatcher interface for example).  I guess that is kind of the point
of the "internal" package since these aren't really supposed to be
part of the API for developers.

However, in this case, I have no choice but to modify the source
rather than supplying my own implementation (short of copying a great
many classes to my applications source tree).

At the very least, I would propose making some of the methods of the
ManagerReaderImpl and ManagerWriterImpl classes protected rather than
private.

Comments?

-aaron