Raymond Auge wrote:
>> > What we have is a typical event handler scenario:
>> >
>> > processEvent(Event event) {
>> > Handler[] handlers = getHandlers(key);
>> >
>> > for (Handler handler : handlers) {
>> > handler.process(event);
>> > }
>> > }
>> >
>> > I'd like to be able to use osgi to affect the handlers result set
>> during
>> runtime.
I wrote:
>> This is a classic use case for the "whiteboard" pattern; the handler
registers itself as a provider of the Handler service and the event source
>> uses the framework to track changes in the Handler population. This is
very easy using Declarative Services, but it can also be done with a good
>> ol' ServiceTracker. That does mean that your handlers have to register
with the framework, but this can be as easy as "serviceRegistration =
bundleContext.registerService(Handler.class.getName(), this, new
Hashtable())" on the way in and "serviceRegistration.unregister()" on the
>> way out.
> [Ray]
> This is great. I'm glad that I was at least on the right track.
>
> However, I do have some concerns with this:
>
> - currently a handler is instantiated then released (to GC aether)
>
> This insures, among other things, that no state is mistakenly preserved
[...]
This is indeed stretching the envelope of the "whiteboard pattern", which
is more often used when each handler will be invoked many times during its
lifetime, as opposed to just once.
> - thread safety (we're not exactly sure that some plugin developer won't
break the system with non-thread safe code) [...]
In my example you would need to control the lifecycle of the handlers in
order to perform the registration and deregistration, so simply abandoning
them to the tender mercies of GC is probably not an option.
> - low to no contention for simply getting the list of handlers? Namely,
was
> the bellow example indended to support a high degree of
> concurrency/contention?
>
> Collection<ServiceReference<Handler>> references =
> _bundleContext.getServiceReferences(Handler.class, filter.toString());
>
> for (ServiceReference<Handler> reference : references) {
> Handler handler = _bundleContext.getService(reference);
>
> handler.init(context);
> handler.doSomething();
>
> _bundleContext.ungetService(reference);
> }
>
>
> I'm kind of concerned with the fact that there is an implied
registration
> here which in this particular scenario sounds either too costly or
simply
> not nessecary.
This code avoids the problem of creating a list of direct references to
the handlers by creating a list of ServiceReferences instead. SRs are
reference-counted, so the get/ungetService calls in this example are
basically just incrementing/decrementing a counter.
If the turnover of the handlers is as high as you say then some degree of
contention is inevitable. A COW list should minimise the impact on the
list traversal.
> Basicly I guess I'm asking how much abuse this pattern can take, say it
if
> were to trigger potentially thousands of times per request (not all for
the
> same event handler)?
I'm still a bit unsure about how your system works. How are all of these
single-use event handlers conjured into existence?
BTW it should be said that Peter Kriens is patron saint of whiteboards, so
you should pay extra attention to what he says on the subject.
- Chris
> Perhaps I'm over thinking it problem (or just entirely incorrectly,
which
> is quite possible)?
>
> - Ray
>
>
>> HTH
>> Chris
>> _______________________________________________
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
<http://twitter.com/#!/rotty3000> | Senior Software Architect |
*Liferay,
> Inc.* <http://www.liferay.com> <https://twitter.com/#!/liferay>
>
> ---
>
> 24-25 October 2012 |* Liferay **Spain Symposium* |
> liferay.com/spain2012<http://www.liferay.com/spain2012>
>
> 16 November 2012 |* Liferay **Italy Symposium* |
> liferay.com/italy2012<http://www.liferay.com/italy2012>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
