On 3/21/15 05:52 , Carsten Ziegeler wrote:
Am 20.03.15 um 18:41 schrieb David Bosschaert:
Some more thoughts about this...
The wait() call in the getService() method is as follows:
synchronized (this)
{
// First make sure that no existing operation is currently
// being performed by another thread on the service registration.
for (Object o = m_lockedRegsMap.get(reg); (o != null); o =
m_lockedRegsMap.get(reg))
{
// We don't allow cycles when we call out to the
service factory.
if (o.equals(Thread.currentThread()))
{
throw new ServiceException(
"ServiceFactory.getService() resulted in a cycle.",
ServiceException.FACTORY_ERROR,
null);
}
// Otherwise, wait for it to be freed.
try
{
wait();
}
catch (InterruptedException ex)
{
Thread.currentThread().interrupt();
}
}
I'm wondering why the code doesn't break out of the loop in the catch block?
Good question - The call to interrupt() is wrong. If the thread gets
interrupted while in wait(), the catch block resets the interrupt flag
and the current thread stays in the for loop. Then it hits wait and as
the interrupted flag is set, it throws an interrupted exception, and the
game starts again. So this will basically create a busy loop once this
thread gets interrupted.
I assume, as the thread is holding the lock on this and it's a busy
loop, the other thread who wants to get the lock on this has no chance
as once this thread is interrupted, it never waits. This would explain
why it never leaves the loop.
Question remains, why the thread got interrupted in the first place.
It was something that you did as part of FELIX-4806:
https://fisheye6.atlassian.com/browse/felix/trunk/framework/src/main/java/org/apache/felix/framework/ServiceRegistry.java?r=1661592
Not sure why, though. It doesn't seem related to the issue.
-> richard
Carsten
