You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Jacques-Olivier Goussard <jo...@gmail.com> on 2009/02/13 19:39:26 UTC
RegisterService and asynchronicity
Hi
I just found a deadlock in our code that was the result of the lack of
asynchronicity. When a service is registered in felix, the trackers are
notified in the same thread. Is
it the intended behavior ?
Looks to me that could lead to a very deep stack of invocation, no ? Of
course I can fix this by doing my service regsitration in a separate thread,
but I wanted
to check first with you for input.
Thanks
/jog
Here I paste an exerpt of the stack trace I have:
at
com.oz.platform.messaging.routing.RoutingManager.handleServiceEvent(RoutingManager.java:592)
at
com.oz.platform.osgi.ComponentPlatform$ServiceNotifier.addingService(ComponentPlatform.java:244)
at
org.osgi.util.tracker.ServiceTracker$Tracked.trackAdding(ServiceTracker.java:1030)
at
org.osgi.util.tracker.ServiceTracker$Tracked.track(ServiceTracker.java:1008)
at
org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:941)
at
org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:765)
at
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:623)
at
org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:554)
at
org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3566)
at org.apache.felix.framework.Felix.access$200(Felix.java:37)
at org.apache.felix.framework.Felix$2.serviceChanged(Felix.java:833)
at
org.apache.felix.framework.ServiceRegistry.fireServiceChanged(ServiceRegistry.java:559)
at
org.apache.felix.framework.ServiceRegistry.registerService(ServiceRegistry.java:75)
at org.apache.felix.framework.Felix.registerService(Felix.java:2713)
at
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:252)
at
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:230)
at
com.oz.platform.osgi.ComponentPlatform.registerService(ComponentPlatform.java:130)
Re: RegisterService and asynchronicity
Posted by Jacques-Olivier Goussard <jo...@gmail.com>.
Ok. It has not much to do with locks - just having potentially a very
deep stack that could contain loops.
Fortunately, I have my own abstraction on top of the bundle context,
so it would be easy for me to push the registration in a separate
thread - you experts don't see any pb with this right ?
On 2/13/09, Richard S. Hall <he...@ungoverned.org> wrote:
> ServiceEvents are defined in the spec as being delivered on the calling
> thread (i.e., synchronously). I agree, this sucks and shouldn't be that
> way, but the spec says so.
>
> -> richard
>
> Jacques-Olivier Goussard wrote:
>> Hi
>> I just found a deadlock in our code that was the result of the lack of
>> asynchronicity. When a service is registered in felix, the trackers are
>> notified in the same thread. Is
>> it the intended behavior ?
>> Looks to me that could lead to a very deep stack of invocation, no ? Of
>> course I can fix this by doing my service regsitration in a separate
>> thread,
>> but I wanted
>> to check first with you for input.
>> Thanks
>> /jog
>> Here I paste an exerpt of the stack trace I have:
>>
>> at
>> com.oz.platform.messaging.routing.RoutingManager.handleServiceEvent(RoutingManager.java:592)
>>
>> at
>> com.oz.platform.osgi.ComponentPlatform$ServiceNotifier.addingService(ComponentPlatform.java:244)
>>
>> at
>> org.osgi.util.tracker.ServiceTracker$Tracked.trackAdding(ServiceTracker.java:1030)
>>
>> at
>> org.osgi.util.tracker.ServiceTracker$Tracked.track(ServiceTracker.java:1008)
>>
>> at
>> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:941)
>>
>> at
>> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:765)
>>
>> at
>> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:623)
>>
>> at
>> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:554)
>>
>> at
>> org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3566)
>>
>> at org.apache.felix.framework.Felix.access$200(Felix.java:37)
>>
>> at
>> org.apache.felix.framework.Felix$2.serviceChanged(Felix.java:833)
>>
>> at
>> org.apache.felix.framework.ServiceRegistry.fireServiceChanged(ServiceRegistry.java:559)
>>
>> at
>> org.apache.felix.framework.ServiceRegistry.registerService(ServiceRegistry.java:75)
>>
>> at
>> org.apache.felix.framework.Felix.registerService(Felix.java:2713)
>>
>> at
>> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:252)
>>
>> at
>> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:230)
>>
>> at
>> com.oz.platform.osgi.ComponentPlatform.registerService(ComponentPlatform.java:130)
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Sent from my mobile device
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: RegisterService and asynchronicity
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Todor Boev wrote:
> Richard S. Hall wrote:
>>
>> Perhaps you'd like this approach better if we had integrated
>> transactions. :-)
>>
> Just out of curiosity and if it's not too much trouble....what would
> these look like? :)
Peter will have to answer that.
I am more than content enough with being defensive and opportunistic:
Always be prepared for exceptions, if you get one check to see if the
service reference is no longer valid; if it is invalid, switch to a
different service.
-> richard
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: 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: RegisterService and asynchronicity
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Peter Kriens wrote:
> Hey, I have proposed transactions in OSGi in 1999!!!!!!
Which is why I threw them into the mix... :-)
-> richard
>
> Kind regards,
>
> Peter Kriens
>
> On 17 feb 2009, at 19:00, Todor Boev wrote:
>
>> Richard S. Hall wrote:
>>>
>>> Perhaps you'd like this approach better if we had integrated
>>> transactions. :-)
>>>
>> Just out of curiosity and if it's not too much trouble....what would
>> these look like? :)
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: 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: RegisterService and asynchronicity
Posted by Peter Kriens <pe...@aqute.biz>.
Hey, I have proposed transactions in OSGi in 1999!!!!!!
Kind regards,
Peter Kriens
On 17 feb 2009, at 19:00, Todor Boev wrote:
> Richard S. Hall wrote:
>>
>> Perhaps you'd like this approach better if we had integrated
>> transactions. :-)
>>
> Just out of curiosity and if it's not too much trouble....what would
> these look like? :)
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: 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: RegisterService and asynchronicity
Posted by Todor Boev <t....@prosyst.bg>.
Richard S. Hall wrote:
>
> Perhaps you'd like this approach better if we had integrated
> transactions. :-)
>
Just out of curiosity and if it's not too much trouble....what would
these look like? :)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: RegisterService and asynchronicity
Posted by "Richard S. Hall" <he...@ungoverned.org>.
In the end, we just disagree on this one. You typically say don't rely
on ordering, because it may work some of the time, but it will always
bite you at the worst time. I think the same thing applies with
services. You shouldn't assume a service will always cleanly shut down;
rather, you should assume a service is always likely to throw an
exception, just like a remote reference. Then, if it does throw an
exception, try to find a replacement.
Perhaps you'd like this approach better if we had integrated
transactions. :-)
-> richard
Peter Kriens wrote:
> The reason I object to INITIALIZATION ordering is that there is a very
> good mechanism that can handle the underlying problem in a more
> generic fashion: services. If these events become async, I am not sure
> what will happen with that story.
>
> Making the service events asynchronous will make this model a lot less
> reliable because the window of vulnerability becomes larger. Lets face
> it, both models suck, but I am not sure sync sucks more than async in
> practice. Anyway, from my point of view as a user it is trivial to
> turn a sync event into an async event. The other way around is
> impossible. There are also some scenarios, like Device Access, that
> will become impossible.
>
> It would be interesting to get use cases for deadlocks caused by
> synchronous events. Anybody on the list some horror stories? Maybe
> there are some common patterns that can solve the problems.
>
> Kind regards,
>
> Peter Kriens
>
>
>
> On 16 feb 2009, at 17:14, Richard S. Hall wrote:
>
>> For someone who preaches "no dependencies on ordering!", synchronous
>> events are just ordering in sheep's clothing. :-P
>>
>> -> richard
>>
>> Peter Kriens wrote:
>>> I am not sure I fully agree. Though I do see the problems with
>>> synchronous events I also see advantages. It is true that the
>>> synchronous nature of external devices is not very relevant, but
>>> most services are software based. In OSGi, services are often used
>>> as dependency anchors. Treating these async, will make this less
>>> reliable ... I think.
>>>
>>> Interestingly, bundle events are async but a couple of years ago we
>>> added synchronous bundle events because many people felt they were
>>> needed. It is easy to blame what you know and idealize what you have
>>> not ...
>>>
>>> So I think it is not a black and white issue. Programmers should be
>>> careful to use the synchronous events but I am not ready to declare
>>> them all evil. It is easy to go from sync to async, vice versa is
>>> impossible.
>>>
>>> Kind regards,
>>>
>>> Peter Kriens
>>>
>>>
>>>
>>>
>>>
>>> On 13 feb 2009, at 21:51, Richard S. Hall wrote:
>>>
>>>> I agree this is the theory, but it (i.e., services blowing up when
>>>> you use them) is not something that can really be prevented.
>>>> Services can go away at any time, so you never know when you use
>>>> one if it will blow up, you have to treat them like remote
>>>> references and assume they always could blow up.
>>>>
>>>> Further, just because the OSGi framework holds onto a
>>>> registration/reference/object does not give you any guarantees that
>>>> you can do anything graceful in a synchronous event. If the object
>>>> is the front-end to a bluetooth device and the devices was powered
>>>> off or went out of range, no amount of synchronicity by the
>>>> framework is going to stop the service object from blowing up when
>>>> you touch it.
>>>>
>>>> Of course, people like the warm and fuzzy feeling that the
>>>> framework is providing them some guarantees. :-)
>>>>
>>>> -> richard
>>>>
>>>> Todor Boev wrote:
>>>>> The synchronous event delivery is an attempt to make service
>>>>> unregistration more graceful. This is the only way to provide an
>>>>> 'unregistering' event as opposed to 'unregistered'. E.g. when you
>>>>> receive the event the service is still up and you can gracefully
>>>>> stop using it. So before the call to "unregister()" returns there
>>>>> is room for some final calls to your service as users get notified
>>>>> and shut down.
>>>>>
>>>>> If the service events were asynchronous the users of the service
>>>>> would potentially blow up with an exception while attempting to
>>>>> use it and only than receive an "unregistered" event. So the whole
>>>>> point of the event goes down the drain - you want to know it's
>>>>> going to go down before it does so you can avoid crashing with
>>>>> exceptions right? At the same time the caller of "unregister()"
>>>>> wants to know that when his call returns the service is no longer
>>>>> used by no one and he can proceed to release the resources of the
>>>>> service with no fear that someone will call in and mess something up.
>>>>>
>>>>> Put all of these considerations together and it seems to me only a
>>>>> synchronous unregistration event will work. And since the
>>>>> unregistration must be synchronous it will be evil to make the
>>>>> registration asynchronous don't you think? :)
>>>>>
>>>>> Cheers,
>>>>> Todor
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: 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: RegisterService and asynchronicity
Posted by Peter Kriens <pe...@aqute.biz>.
The reason I object to INITIALIZATION ordering is that there is a very
good mechanism that can handle the underlying problem in a more
generic fashion: services. If these events become async, I am not sure
what will happen with that story.
Making the service events asynchronous will make this model a lot less
reliable because the window of vulnerability becomes larger. Lets face
it, both models suck, but I am not sure sync sucks more than async in
practice. Anyway, from my point of view as a user it is trivial to
turn a sync event into an async event. The other way around is
impossible. There are also some scenarios, like Device Access, that
will become impossible.
It would be interesting to get use cases for deadlocks caused by
synchronous events. Anybody on the list some horror stories? Maybe
there are some common patterns that can solve the problems.
Kind regards,
Peter Kriens
On 16 feb 2009, at 17:14, Richard S. Hall wrote:
> For someone who preaches "no dependencies on ordering!", synchronous
> events are just ordering in sheep's clothing. :-P
>
> -> richard
>
> Peter Kriens wrote:
>> I am not sure I fully agree. Though I do see the problems with
>> synchronous events I also see advantages. It is true that the
>> synchronous nature of external devices is not very relevant, but
>> most services are software based. In OSGi, services are often used
>> as dependency anchors. Treating these async, will make this less
>> reliable ... I think.
>>
>> Interestingly, bundle events are async but a couple of years ago we
>> added synchronous bundle events because many people felt they were
>> needed. It is easy to blame what you know and idealize what you
>> have not ...
>>
>> So I think it is not a black and white issue. Programmers should be
>> careful to use the synchronous events but I am not ready to declare
>> them all evil. It is easy to go from sync to async, vice versa is
>> impossible.
>>
>> Kind regards,
>>
>> Peter Kriens
>>
>>
>>
>>
>>
>> On 13 feb 2009, at 21:51, Richard S. Hall wrote:
>>
>>> I agree this is the theory, but it (i.e., services blowing up when
>>> you use them) is not something that can really be prevented.
>>> Services can go away at any time, so you never know when you use
>>> one if it will blow up, you have to treat them like remote
>>> references and assume they always could blow up.
>>>
>>> Further, just because the OSGi framework holds onto a registration/
>>> reference/object does not give you any guarantees that you can do
>>> anything graceful in a synchronous event. If the object is the
>>> front-end to a bluetooth device and the devices was powered off or
>>> went out of range, no amount of synchronicity by the framework is
>>> going to stop the service object from blowing up when you touch it.
>>>
>>> Of course, people like the warm and fuzzy feeling that the
>>> framework is providing them some guarantees. :-)
>>>
>>> -> richard
>>>
>>> Todor Boev wrote:
>>>> The synchronous event delivery is an attempt to make service
>>>> unregistration more graceful. This is the only way to provide an
>>>> 'unregistering' event as opposed to 'unregistered'. E.g. when
>>>> you receive the event the service is still up and you can
>>>> gracefully stop using it. So before the call to "unregister()"
>>>> returns there is room for some final calls to your service as
>>>> users get notified and shut down.
>>>>
>>>> If the service events were asynchronous the users of the service
>>>> would potentially blow up with an exception while attempting to
>>>> use it and only than receive an "unregistered" event. So the
>>>> whole point of the event goes down the drain - you want to know
>>>> it's going to go down before it does so you can avoid crashing
>>>> with exceptions right? At the same time the caller of
>>>> "unregister()" wants to know that when his call returns the
>>>> service is no longer used by no one and he can proceed to release
>>>> the resources of the service with no fear that someone will call
>>>> in and mess something up.
>>>>
>>>> Put all of these considerations together and it seems to me only
>>>> a synchronous unregistration event will work. And since the
>>>> unregistration must be synchronous it will be evil to make the
>>>> registration asynchronous don't you think? :)
>>>>
>>>> Cheers,
>>>> Todor
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: 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: RegisterService and asynchronicity
Posted by "Richard S. Hall" <he...@ungoverned.org>.
For someone who preaches "no dependencies on ordering!", synchronous
events are just ordering in sheep's clothing. :-P
-> richard
Peter Kriens wrote:
> I am not sure I fully agree. Though I do see the problems with
> synchronous events I also see advantages. It is true that the
> synchronous nature of external devices is not very relevant, but most
> services are software based. In OSGi, services are often used as
> dependency anchors. Treating these async, will make this less reliable
> ... I think.
>
> Interestingly, bundle events are async but a couple of years ago we
> added synchronous bundle events because many people felt they were
> needed. It is easy to blame what you know and idealize what you have
> not ...
>
> So I think it is not a black and white issue. Programmers should be
> careful to use the synchronous events but I am not ready to declare
> them all evil. It is easy to go from sync to async, vice versa is
> impossible.
>
> Kind regards,
>
> Peter Kriens
>
>
>
>
>
> On 13 feb 2009, at 21:51, Richard S. Hall wrote:
>
>> I agree this is the theory, but it (i.e., services blowing up when
>> you use them) is not something that can really be prevented. Services
>> can go away at any time, so you never know when you use one if it
>> will blow up, you have to treat them like remote references and
>> assume they always could blow up.
>>
>> Further, just because the OSGi framework holds onto a
>> registration/reference/object does not give you any guarantees that
>> you can do anything graceful in a synchronous event. If the object is
>> the front-end to a bluetooth device and the devices was powered off
>> or went out of range, no amount of synchronicity by the framework is
>> going to stop the service object from blowing up when you touch it.
>>
>> Of course, people like the warm and fuzzy feeling that the framework
>> is providing them some guarantees. :-)
>>
>> -> richard
>>
>> Todor Boev wrote:
>>> The synchronous event delivery is an attempt to make service
>>> unregistration more graceful. This is the only way to provide an
>>> 'unregistering' event as opposed to 'unregistered'. E.g. when you
>>> receive the event the service is still up and you can gracefully
>>> stop using it. So before the call to "unregister()" returns there is
>>> room for some final calls to your service as users get notified and
>>> shut down.
>>>
>>> If the service events were asynchronous the users of the service
>>> would potentially blow up with an exception while attempting to use
>>> it and only than receive an "unregistered" event. So the whole point
>>> of the event goes down the drain - you want to know it's going to go
>>> down before it does so you can avoid crashing with exceptions right?
>>> At the same time the caller of "unregister()" wants to know that
>>> when his call returns the service is no longer used by no one and he
>>> can proceed to release the resources of the service with no fear
>>> that someone will call in and mess something up.
>>>
>>> Put all of these considerations together and it seems to me only a
>>> synchronous unregistration event will work. And since the
>>> unregistration must be synchronous it will be evil to make the
>>> registration asynchronous don't you think? :)
>>>
>>> Cheers,
>>> Todor
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: 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: RegisterService and asynchronicity
Posted by Peter Kriens <pe...@aqute.biz>.
I am not sure I fully agree. Though I do see the problems with
synchronous events I also see advantages. It is true that the
synchronous nature of external devices is not very relevant, but most
services are software based. In OSGi, services are often used as
dependency anchors. Treating these async, will make this less
reliable ... I think.
Interestingly, bundle events are async but a couple of years ago we
added synchronous bundle events because many people felt they were
needed. It is easy to blame what you know and idealize what you have
not ...
So I think it is not a black and white issue. Programmers should be
careful to use the synchronous events but I am not ready to declare
them all evil. It is easy to go from sync to async, vice versa is
impossible.
Kind regards,
Peter Kriens
On 13 feb 2009, at 21:51, Richard S. Hall wrote:
> I agree this is the theory, but it (i.e., services blowing up when
> you use them) is not something that can really be prevented.
> Services can go away at any time, so you never know when you use one
> if it will blow up, you have to treat them like remote references
> and assume they always could blow up.
>
> Further, just because the OSGi framework holds onto a registration/
> reference/object does not give you any guarantees that you can do
> anything graceful in a synchronous event. If the object is the front-
> end to a bluetooth device and the devices was powered off or went
> out of range, no amount of synchronicity by the framework is going
> to stop the service object from blowing up when you touch it.
>
> Of course, people like the warm and fuzzy feeling that the framework
> is providing them some guarantees. :-)
>
> -> richard
>
> Todor Boev wrote:
>> The synchronous event delivery is an attempt to make service
>> unregistration more graceful. This is the only way to provide an
>> 'unregistering' event as opposed to 'unregistered'. E.g. when you
>> receive the event the service is still up and you can gracefully
>> stop using it. So before the call to "unregister()" returns there
>> is room for some final calls to your service as users get notified
>> and shut down.
>>
>> If the service events were asynchronous the users of the service
>> would potentially blow up with an exception while attempting to use
>> it and only than receive an "unregistered" event. So the whole
>> point of the event goes down the drain - you want to know it's
>> going to go down before it does so you can avoid crashing with
>> exceptions right? At the same time the caller of "unregister()"
>> wants to know that when his call returns the service is no longer
>> used by no one and he can proceed to release the resources of the
>> service with no fear that someone will call in and mess something up.
>>
>> Put all of these considerations together and it seems to me only a
>> synchronous unregistration event will work. And since the
>> unregistration must be synchronous it will be evil to make the
>> registration asynchronous don't you think? :)
>>
>> Cheers,
>> Todor
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: 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: RegisterService and asynchronicity
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Yes! Exactly my point.
-> richard
Todor Boev wrote:
> Yup. It's just an "attempt" to make unregistration work - a failed
> one. Lately I am leaning ever more to the view that the only
> reasonable way to use services is to do it opportunistically like so:
>
> http://code.google.com/p/peaberry/issues/detail?id=27&can=1#c3
>
> In this light all the hubbub with the synchronous events goes away.
> Now the user needs
>
> 1) a "registered" event to start trying to use the service.
> 2) an "unregistered" event to stop trying to use the service and
> conserve CPU resources.
>
> Here we only need to guarantee that "registered" always precedes
> "unregistered". Too bad the super-strong synchronous design is already
> in the spec. It's always easier to strengthen the constraints than to
> weaken them.
>
> Cheers,
> Todor
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: 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: RegisterService and asynchronicity
Posted by Todor Boev <t....@prosyst.bg>.
Yup. It's just an "attempt" to make unregistration work - a failed one.
Lately I am leaning ever more to the view that the only reasonable way
to use services is to do it opportunistically like so:
http://code.google.com/p/peaberry/issues/detail?id=27&can=1#c3
In this light all the hubbub with the synchronous events goes away. Now
the user needs
1) a "registered" event to start trying to use the service.
2) an "unregistered" event to stop trying to use the service and
conserve CPU resources.
Here we only need to guarantee that "registered" always precedes
"unregistered". Too bad the super-strong synchronous design is already
in the spec. It's always easier to strengthen the constraints than to
weaken them.
Cheers,
Todor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: RegisterService and asynchronicity
Posted by "Richard S. Hall" <he...@ungoverned.org>.
I agree this is the theory, but it (i.e., services blowing up when you
use them) is not something that can really be prevented. Services can go
away at any time, so you never know when you use one if it will blow up,
you have to treat them like remote references and assume they always
could blow up.
Further, just because the OSGi framework holds onto a
registration/reference/object does not give you any guarantees that you
can do anything graceful in a synchronous event. If the object is the
front-end to a bluetooth device and the devices was powered off or went
out of range, no amount of synchronicity by the framework is going to
stop the service object from blowing up when you touch it.
Of course, people like the warm and fuzzy feeling that the framework is
providing them some guarantees. :-)
-> richard
Todor Boev wrote:
> The synchronous event delivery is an attempt to make service
> unregistration more graceful. This is the only way to provide an
> 'unregistering' event as opposed to 'unregistered'. E.g. when you
> receive the event the service is still up and you can gracefully stop
> using it. So before the call to "unregister()" returns there is room
> for some final calls to your service as users get notified and shut down.
>
> If the service events were asynchronous the users of the service would
> potentially blow up with an exception while attempting to use it and
> only than receive an "unregistered" event. So the whole point of the
> event goes down the drain - you want to know it's going to go down
> before it does so you can avoid crashing with exceptions right? At the
> same time the caller of "unregister()" wants to know that when his
> call returns the service is no longer used by no one and he can
> proceed to release the resources of the service with no fear that
> someone will call in and mess something up.
>
> Put all of these considerations together and it seems to me only a
> synchronous unregistration event will work. And since the
> unregistration must be synchronous it will be evil to make the
> registration asynchronous don't you think? :)
>
> Cheers,
> Todor
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: 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: RegisterService and asynchronicity
Posted by Todor Boev <t....@prosyst.bg>.
The synchronous event delivery is an attempt to make service
unregistration more graceful. This is the only way to provide an
'unregistering' event as opposed to 'unregistered'. E.g. when you
receive the event the service is still up and you can gracefully stop
using it. So before the call to "unregister()" returns there is room for
some final calls to your service as users get notified and shut down.
If the service events were asynchronous the users of the service would
potentially blow up with an exception while attempting to use it and
only than receive an "unregistered" event. So the whole point of the
event goes down the drain - you want to know it's going to go down
before it does so you can avoid crashing with exceptions right? At the
same time the caller of "unregister()" wants to know that when his call
returns the service is no longer used by no one and he can proceed to
release the resources of the service with no fear that someone will call
in and mess something up.
Put all of these considerations together and it seems to me only a
synchronous unregistration event will work. And since the
unregistration must be synchronous it will be evil to make the
registration asynchronous don't you think? :)
Cheers,
Todor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: RegisterService and asynchronicity
Posted by "Richard S. Hall" <he...@ungoverned.org>.
ServiceEvents are defined in the spec as being delivered on the calling
thread (i.e., synchronously). I agree, this sucks and shouldn't be that
way, but the spec says so.
-> richard
Jacques-Olivier Goussard wrote:
> Hi
> I just found a deadlock in our code that was the result of the lack of
> asynchronicity. When a service is registered in felix, the trackers are
> notified in the same thread. Is
> it the intended behavior ?
> Looks to me that could lead to a very deep stack of invocation, no ? Of
> course I can fix this by doing my service regsitration in a separate thread,
> but I wanted
> to check first with you for input.
> Thanks
> /jog
> Here I paste an exerpt of the stack trace I have:
>
> at
> com.oz.platform.messaging.routing.RoutingManager.handleServiceEvent(RoutingManager.java:592)
>
> at
> com.oz.platform.osgi.ComponentPlatform$ServiceNotifier.addingService(ComponentPlatform.java:244)
>
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.trackAdding(ServiceTracker.java:1030)
>
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.track(ServiceTracker.java:1008)
>
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:941)
>
> at
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:765)
>
> at
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:623)
>
> at
> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:554)
>
> at
> org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3566)
>
> at org.apache.felix.framework.Felix.access$200(Felix.java:37)
>
> at org.apache.felix.framework.Felix$2.serviceChanged(Felix.java:833)
>
> at
> org.apache.felix.framework.ServiceRegistry.fireServiceChanged(ServiceRegistry.java:559)
>
> at
> org.apache.felix.framework.ServiceRegistry.registerService(ServiceRegistry.java:75)
>
> at org.apache.felix.framework.Felix.registerService(Felix.java:2713)
>
> at
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:252)
>
> at
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:230)
>
> at
> com.oz.platform.osgi.ComponentPlatform.registerService(ComponentPlatform.java:130)
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: RegisterService and asynchronicity
Posted by Neil Bartlett <nj...@gmail.com>.
Yes, notifications to ServiceListeners (and therefore ServiceTrackers)
should occur synchronously in the thread that caused the
registration/unregistration of the service. Because of this it is
generally unwise to hold any locks when registering or unregistering a
service.
In many cases you should be able to avoid holding a lock and therefore
should not have to create a separate thread.
Regards
Neil
On Fri, Feb 13, 2009 at 6:39 PM, Jacques-Olivier Goussard
<jo...@gmail.com> wrote:
> Hi
> I just found a deadlock in our code that was the result of the lack of
> asynchronicity. When a service is registered in felix, the trackers are
> notified in the same thread. Is
> it the intended behavior ?
> Looks to me that could lead to a very deep stack of invocation, no ? Of
> course I can fix this by doing my service regsitration in a separate thread,
> but I wanted
> to check first with you for input.
> Thanks
> /jog
> Here I paste an exerpt of the stack trace I have:
>
> at
> com.oz.platform.messaging.routing.RoutingManager.handleServiceEvent(RoutingManager.java:592)
>
> at
> com.oz.platform.osgi.ComponentPlatform$ServiceNotifier.addingService(ComponentPlatform.java:244)
>
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.trackAdding(ServiceTracker.java:1030)
>
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.track(ServiceTracker.java:1008)
>
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:941)
>
> at
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:765)
>
> at
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:623)
>
> at
> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:554)
>
> at
> org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3566)
>
> at org.apache.felix.framework.Felix.access$200(Felix.java:37)
>
> at org.apache.felix.framework.Felix$2.serviceChanged(Felix.java:833)
>
> at
> org.apache.felix.framework.ServiceRegistry.fireServiceChanged(ServiceRegistry.java:559)
>
> at
> org.apache.felix.framework.ServiceRegistry.registerService(ServiceRegistry.java:75)
>
> at org.apache.felix.framework.Felix.registerService(Felix.java:2713)
>
> at
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:252)
>
> at
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:230)
>
> at
> com.oz.platform.osgi.ComponentPlatform.registerService(ComponentPlatform.java:130)
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org