The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

michaelmcgrady (14) [Avatar] Offline
#1
The discussion of using synchronous listeners is not helpful in actually specifying what the problems are. The creation of concurrency issues is not due, as stated, to "try[ing] to do too much within the callback". Keeping things short might make the evil appear less frequently but will fix nothing without addressing the real issues.
richard.hall (87) [Avatar] Offline
#2
Re: Section 3.3.5 Events
Perhaps saying "keep it simple" is too terse, but the issue here is there is nothing that can be done to address the real issues. When servicing synchronous listeners, the framework must often hold locks. Calling out to foreign code while holding locks is bad, since the foreign code won't necessarily know which locks the framework is holding and can cause lock acquisition to happen in unforeseen orders, all of which are problematic.

I think it is safe to say that the OSGi framework spec cannot be implemented without the possibility of deadlock, given how it is specified. I personally see this as a shortcoming in the spec and in people's unwillingness to let go of control. From my point of view, there should be no synchronous events in OSGi.

Since synchronous listeners do exist, however, by keeping them simple (e.g., just taking care of bookkeeping, not making calls back into the framework, etc.), you can avoid the evil. Perhaps, this is less than satisfying, but that's the unfortunate reality.
michaelmcgrady (14) [Avatar] Offline
#3
Re: Section 3.3.5 Events
I see what you are saying now. I think that was not clear. The message, I think, is to never, ever, forever, make calls into the framework in this context. I am not happy to hear about the issue you raise. OSGi should definitely take steps to alleviate this problem. The state of the art is beyond these issues. Thanks.
richard.hall (87) [Avatar] Offline
#4
Re: Section 3.3.5 Events
Perhaps we can try to make that more clear in the chapter. Unfortunately, I don't see an easy fix coming for this type of thing. In fact, it is only getting worse because more users are demanding support for more complicated use cases. The service hooks of R4.2 are a prime example, while they provide a lot of power, they also open the door for abuse. This is not an OSGi issue necessarily; all technology is pushed into new directions as it evolves.