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 its 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, Id like to try it out. Also, Ive 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 cant 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]
