You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by DBinSD <cd...@gmail.com> on 2012/01/18 03:35:47 UTC
EventAdmin Asynchronous/Parallel EventHandler
Does the felix implementation of the EventAdmin service support the delivery
of events, asynchronously and in parallel to multiple listeners at once? It
appears as though the EventAdmin.postEvent( ) call properly immediately
returns to the caller as one would expect, however, the receivers of that
event are called in serial. It appears as though the
EventHandler.handleEvent( ) call is a blocking call, regardless of how the
event was received (postEvent or sendEvent) and all event handlers will be
iterated through in a serial fashion, blocking on each one until completion
or until the timeout is reached.
If this is the expected default behavior, thats OK. However the spec seems
to imply that is is possible for the EventAdmin to publish events
asynchronously with multiple threads as long as it keeps the event ordering:
According to the OSGi service copendium, section 113.7.3, "...The Event
Admin service can use more than one thread to deliver events..."
The functionality I am looking for is the ability to post an event,
asynchronously, and have 100 EventHandlers of that event receive the event
pseudo-simultaneously, regardless of how long it takes any one of those
particular EventHanlders to process the event. If it means threading the
event handling process, so be it, however if there is a more elegant OSGi
way to do it, im all ears.
Thanks!
Chris
--
View this message in context: http://old.nabble.com/EventAdmin-Asynchronous-Parallel-EventHandler-tp33158446p33158446.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: EventAdmin Asynchronous/Parallel EventHandler
Posted by Neil Bartlett <nj...@gmail.com>.
Delivery of events to handlers is an implementation detail. So long as the ordering guarantees are maintained, a compliant implementation can use single-threaded or multi-threaded delivery.... the idea being to allow different implementations to compete on details such as these.
The Felix EventAdmin implementation complies with the specification but it is not the most powerful or feature-ful implementation that one could imagine. It's possible that a commercial implementation exists with the features you want.
Regards,
Neil
On Wednesday, 18 January 2012 at 02: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
> appears as though the EventAdmin.postEvent( ) call properly immediately
> returns to the caller as one would expect, however, the receivers of that
> event are called in serial. It appears as though the
> EventHandler.handleEvent( ) call is a blocking call, regardless of how the
> event was received (postEvent or sendEvent) and all event handlers will be
> iterated through in a serial fashion, blocking on each one until completion
> or until the timeout is reached.
>
> If this is the expected default behavior, thats OK. However the spec seems
> to imply that is is possible for the EventAdmin to publish events
> asynchronously with multiple threads as long as it keeps the event ordering:
>
> According to the OSGi service copendium, section 113.7.3, "...The Event
> Admin service can use more than one thread to deliver events..."
>
> The functionality I am looking for is the ability to post an event,
> asynchronously, and have 100 EventHandlers of that event receive the event
> pseudo-simultaneously, regardless of how long it takes any one of those
> particular EventHanlders to process the event. If it means threading the
> event handling process, so be it, however if there is a more elegant OSGi
> way to do it, im all ears.
>
> Thanks!
> Chris
>
>
>
> --
> View this message in context: http://old.nabble.com/EventAdmin-Asynchronous-Parallel-EventHandler-tp33158446p33158446.html
> Sent from the Apache Felix - Users mailing list archive at Nabble.com (http://Nabble.com).
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org (mailto:users-unsubscribe@felix.apache.org)
> For additional commands, e-mail: users-help@felix.apache.org (mailto:users-help@felix.apache.org)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: EventAdmin Asynchronous/Parallel EventHandler
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <cd...@gmail.com>:
>
> 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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
> --
> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
--
Carsten Ziegeler
cziegeler@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: EventAdmin Asynchronous/Parallel EventHandler
Posted by DBinSD <cd...@gmail.com>.
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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
--
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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: EventAdmin Asynchronous/Parallel EventHandler
Posted by Holger Hoffstätte <ho...@googlemail.com>.
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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org