On 6/28/11 10:14, Carsten Ziegeler wrote:
Hi,
we're experiencing some deadlocks or more precisely starvations in the
framework. At some point we have three threads where two are waiting
for the bundle lock and one for the global lock. But noone is actually
holding this lock. So it seems that no notification has been send to
get one of these threads out of the wait state.
We're not sure yet, what the exact problem is and unfortunately it
seems that this is very hard to reproduce. This happens with 3.0.7.
I know had a quick look at the framework code and (with trunk) I see
two places where potentially a global lock might not be released:
- StatefulResolver#resolve : this method requests the global lock, but
before the try / finally block starts, an exception is thrown, but the
lock is not released
Yes, this is bug, so i'll fix it, but it is definitely not related to
anything to 3.0.7, since it is some new hacking I've done so support
resolver hooks in OSGi R4.3.
- Felix#refreshPackages : there is a lot of code between the
acquireGlobalLock and the try / finally block. If an exception would
occur here, the lock would not be released (though chances might be
low)
The same is in Felix#startBundle with the bundle lock (again chances
might be very low)
Are my assumptions correct or am I missing something?
Well, you are correct that if exceptions occurred in these places, we'd
have an issue. Seems unlikely, but a quick test would be simply, just
move the "try" up where you have doubts. However, you'd be better of
doing this on a checked out version of 3.0.7, since things have changed
substantially on trunk.
-> richard
Regards
Carsten
