felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Felix 1.5.0 snapshot
Date Wed, 04 Mar 2009 14:47:36 GMT
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

View raw message