Hi Joel, yes, we noticed some performance problems as well - apart from the problem you mentioned in our case it was a very high load on the service registry (which in addition could also cause deadlocks in the framework). So I reimplemented the whole thing (FELIX-3321). You can find the code now in the latest trunk, so you could just build the version from trunk and see how it performs. It basically changes the way how event handlers are fetched from the registry and how the event topic is compared - filters are now only used if really required, the main checks are done by simple string comparisons.
For our really simple performance test case with more than 1 million events, it took more than 30 seconds with the old implementation, the new one processes the same amount in less than a second. Not sure about your problem if events getting eaten up. With the new impl it should be much easier to track this down (if it still happens) Regards Carsten 2012/4/4 Joel Schuster <[email protected]> > Carsten et al.,**** > > ** ** > > I've been running some profiling against some test components using > EventAdmin. I'm seeing some really degenerate behavior that's causing some > real slowdowns for message delivery coming from a few places.**** > > ** ** > > Environment: running 400+ messages per second and with 15+ topics with > various levels of hierarchy.**** > > ** ** > > Because of the general ‘brute force’ means by which > org.apache.felix.framework.capabilityset.CapabilitySet.convertArrayToList > works, and how the multiple layers of > org.apache.felix.framework.capabilityset.CapabilitySet.match work when > topics have multiple layers of hierarchy with the names I can double the > throughput of EventAdmin by simply changing my topic names to one layer of > hierarchy. Of course I lose the advantages of the fiters, but if I can > double the throughput then it seems worth it.**** > > ** ** > > Even then it’s still taking more than half a millisecond (optimally, > sometimes many tens of milliseconds) for any particular message to make its > way through the EventAdmin system, being pushed and handled. That seems > like a long time. Part of the overhead comes from the > org.apache.felix.framework.ServiceRegistry.getService and ungetService > calls that happen for every single message push.**** > > ** ** > > It seems to me that some sort of caching of previous search results in > each of these domains would be well worth the effort.**** > > ** ** > > Carsten, I noticed that you had commented about an improved EventAdmin in > the sandbox. Can you please point that out to me, I’d like to try it out.* > *** > > ** ** > > Also, I’ve notice that the EventAdmin is not delivering all the events > that are pushed to a topic. Small percentages (1 / 1000) are simply being > eaten up somewhere… I can’t seem to track down any reason or log for why > the events simply disappeared.**** > > ** ** > > ** ** > > Thanks all for consideration.**** > > ** ** > > ** ** > > ** ** > > **** > > ** ** > > - Joel**** > > ** ** > > ** ** > > > -----Original Message----- > > > From: Carsten Ziegeler [mailto:[email protected]] > > > Sent: Tuesday, January 24, 2012 2:55 AM > > > To: [email protected] > > > Subject: Re: EventAdmin Asynchronous/Parallel EventHandler > > > > > > Hi, > > > > > > we haven't implemented this feature yet but will do once the final > > > spec is publically available. > > > > > > I've written a new implementation of the event admin which is in the > > > felix sandbox atm, this one is significanlty faster than the old > > > implementation from trunk. > > > > > > Regards > > > Carsten > > > > > > 2012/1/18 DBinSD <[email protected]>: > > > > > > > > Thanks Holger, this is exactly the info I was looking for. It sounds > like > > > > the Async Unordered Events might get me the performance I was looking > > > for > > > > (though the implications of 'unordered' events might be a problem in > some > > > > applications). I will keep an eye out for an implementation of this > > > > feature. > > > > > > > > Thanks again > > > > Chris > > > > > > > > > > > > > > > > Holger Hoffstätte-4 wrote: > > > >> > > > >> On 18.01.2012 03:35, DBinSD wrote: > > > >>> Does the felix implementation of the EventAdmin service support the > > > >>> delivery > > > >>> of events, asynchronously and in parallel to multiple listeners at > once? > > > >>> It > > > >> > > > >> This was addressed as part of RFC 157 ("Updates to EventAdmin") > > > sometime > > > >> in 2010 and accepted, though I don't remember offhand what the > > > >> implementation status was/is. IIRC it was part of 4.3. > > > >> > > > >> The solution added a set of constants that express basic delivery > > > >> behaviour/expectations. Not really enforceable end-to-end QoS > > > constraints > > > >> (which are impossible in Java anyway) but better than nothing. > > > >> > > > >> --snip-- > > > >> > > > >> 5.2 Asynchronous Unordered Events > > > >> > > > >> The following constants are added to EventConstants. This allows an > > > Event > > > >> Handler to indicate that it is willing to relax the event ordering > > > >> requirements so that Event Admin can optimize delivery. > > > >> > > > >> String EVENT_DELIVERY = "event.delivery" > > > >> Service Registration property specifying the delivery qualities > requested > > > >> by an Event Handler service. > > > >> > > > >> Event handlers MAY be registered with this property. Each value of > this > > > >> property is a string specifying a delivery quality for the Event > handler. > > > >> > > > >> The value of this property must be of type String, String[], or > > > >> Collection<String>. > > > >> > > > >> Since: > > > >> 1.3 > > > >> See Also: > > > >> DELIVERY_ASYNC_ORDERED > > > >> DELIVERY_ASYNC_UNORDERED > > > >> > > > >> String DELIVERY_ASYNC_ORDERED = "async.ordered" > > > >> Event Handler delivery quality value specifying the Event Handler > requires > > > >> asynchronously delivered events be delivered in order. Ordered > delivery > > > is > > > >> the default for asynchronously delivered events. > > > >> > > > >> This delivery quality value is mutually exclusive with > > > >> DELIVERY_ASYNC_UNORDERED. However, if both this value and > > > >> DELIVERY_ASYNC_UNORDERED are specifed for an event handler, this > > > value > > > >> takes precedence. > > > >> > > > >> Since: > > > >> 1.3 > > > >> See Also: > > > >> EVENT_DELIVERY > > > >> > > > >> String DELIVERY_ASYNC_UNORDERED = "async.unordered" > > > >> Event Handler delivery quality value specifying the Event Handler does > > > not > > > >> require asynchronously delivered events be delivered in order. This > may > > > >> allow an Event Admin implementation to optimize asynchronous event > > > >> delivery by relaxing ordering requirements. > > > >> > > > >> This delivery quality value is mutually exclusive with > > > >> DELIVERY_ASYNC_ORDERED. However, if both this value and > > > >> DELIVERY_ASYNC_ORDERED are specifed for an event handler, > > > >> DELIVERY_ASYNC_ORDERED takes precedence. > > > >> > > > >> Since: > > > >> 1.3 > > > >> > > > >> See Also: > > > >> EVENT_DELIVERY > > > >> > > > >> --snip-- > > > >> > > > >> Also see > > > >> http://stackoverflow.com/questions/7018762/when-to-use-osgi- > > > eventadmin-and-when-not > > > >> for BJ's official answer. > > > >> > > > >> hope this helps > > > >> Holger > > > >> > > > >> --------------------------------------------------------------------- > > > >> To unsubscribe, e-mail: [email protected] > > > >> For additional commands, e-mail: [email protected] > > > >> > > > >> > > > >> > > > > > > > > -- > > > > View this message in context: http://old.nabble.com/EventAdmin- > > > Asynchronous-Parallel-EventHandler-tp33158446p33162303.html > > > > Sent from the Apache Felix - Users mailing list archive at Nabble.com. > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > -- > > > Carsten Ziegeler > > > [email protected] > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > -- Carsten Ziegeler [email protected]
