|
[
Permlink
| « Hide
]
Olof Jönsson added a comment - 03/Sep/08 11:04 AM
A patch that synchronizes / serializes the registering of the dependency listener and the completion of the tasks
The previous update didn't take into account that reference might be resolved when registering the dependency listener in the same thread (i. e. with the same monitor). This is exactly what happens in OsgiListenerUtils.addServiceListener().
This new patch handles this by checking (again) if the dependencies are resolved after the registration and within the synchronized block. Hi Olof. I had to look at the patch since from the issue description, I wasn't sure what the bug was all about. I think the case that might have affected you was that the watchdog task might have started after it was stopped. I've addressed this.
Note that checking for a status (pooling) isn't really an option since the status can change between two statements. The approach taken in Spring-DM is to use a simple counter (barrier) that indicates if the dependencies have been satisfied no matter the order. The fix has been committed and is available in the TRUNK. It would be swell if you could give this a try today at some point (or by tomorrow morning) before 1.2.x is released. I'll trigger a nightly build later on to have the snapshot ready just in case - ofc, you can build the sources yourself. Thanks, Olof, I've triggered the nightly build - it should be available in 30 minutes or so. See this link (http://build.springframework.org/browse/OSGI-NIGHTLY/latest) for more info (or the issue build tab for more info).
Cheers, Hello Costin,
Sorry for being overly terse, and you were right on the mark on what the problem was. I'll download the nightly build as soon as it is ready, I'm at a bad internet connection right now (3G that disconnects intermittently) and I'm having some serious problems getting the source from SVN. I've done an ocular review through the changes and they seem to handle this issue correctly. However, the refresh()-method doesn't seem to handle multiple invocations anymore since the watchdogTask is only created once (in the constructor). That's not a problem for me though. Anyway, as soon as tested the nightly build for this issue I'll update here with my results. Thanks for the great work, and especially for getting 1.2 ready so quickly! Olof, the nightly build was completed - if you'll update now the snapshot should contain the change. You are right about multiple invocations not being supported but this was never the plan. Since the context is handled by the extender, double creation never occurs (it's always create -> refresh -> close).
P.S. Tomorrow 1.2.0 M1 is scheduled for release - there is still some work to be done before 1.2.0 final :) I haven't been able to reproduce this issue with the latest nightly snapshot so I'd way we're good to go!
Regarding the multiple invocations, I thought mainly of the fact that the application context is published as an OSGi service under the ConfigurableApplicationContext interface which would make it possible that client code could invoke refresh() on it multiple times. Looking forward to the release tomorrow (even if it's not final :) ), good night! Thanks for the report Olof. refresh() contract doesn't imply multiple invocations - each implementation can throw an IllegalStateException if this is not the case.
The Delegated ApplicationContext uses that since it's considerably easier and nicer to just create another object rather then refresh the existing context due to the number of locks, synchronization and management issues that arrise from supporting multiple refresh. Additionally, with a delegated context, the execution and creation is driven by the extender and not by the user. Nevertheless, if there is a case where multiple refresh make sense, let me know and we'll see what we can do about it. Cheers, |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Major
Concurrency issue when waiting for dependencies
