Excellent. Thanks, Felix.
I have tried to create a test case from the one example you sent me.
Overall it works, but I cannot figure out how to make the test case
completely clean. For example, when I test it on the snapshot everything
is fine, but if I test it on an older version that exhibited deadlock, I
cannot interrupt the thread when I timeout so the test case cannot clean
up the threads. In the end, the test case hangs.
I guess this test case could be good enough, since if we regress tests
will hang, so we will know to fix it, but it would be nicer if I could
break the deadlock somehow. I will think about it a little more and will
eventually commit it to my sandbox bnd testing harness.
-> richard
Felix Meschberger wrote:
Hi Richard,
Thanks for the information. In the Apache Sling project we are making
heavy use of Declarative Services, which happened to show some of the
deadlock situations.
So far, I did not encounter the known deadlock situations anymore.
I will include your last SNAPSHOT in the SNAPSHOT build of the Apache
Sling Launcher I will deploy today. This should -- hopefully -- generate
more information.
Regards and Thanks
Felix
Richard S. Hall schrieb:
Hey guys,
I think we will start to gear up for a 1.6.0 release of framework and
main. I just deployed a 1.5.0 snapshot for your pleasure or feel free to
build from trunk. I hope people will spend some time playing with this
snapshot since it has seen some major refactoring under the covers.
There are two main areas where there was a lot of refactoring:
1. The structure of the code was simplified to remove a lot of the
generic module layer and make it more specific to OSGi, since in
all likelihood we will never implement a different module system
on top of the module layer. These changes are not complete, but
since they are implementation details we can finish this
refactoring in later releases. Hopefully, these changes will not
impact anyone.
2. The locking/concurrency approach was refactored quite a bit.
Mainly, we try to be a little more precise and strict in our
locking. However, since strictness and precision can lead to
deadlocks, we have tried to make the locking interruptible in the
case a potential deadlock is detected. I just committed the final
changes (I hope) in this area for this snapshot. It is possible
that these changes will impact users, so testing by people using
multiple threads is greatly appreciated.
Please report any issues back to the mailing list or with JIRA, thanks.
-> richard
