Deadlock using ConfigAdmin? about ipopo HOT 7 OPEN

Hi,
I've been able to reproduce the bug.
Does it happen from scratch or just when (re)starting the app/component with an existing configuration ?

The issue doesn't seem directly connected to ConfigAdmin: it's more likely a reentry in a service event handler that causes the lock.
The issue only occurs if ConfigAdmin is started after the managed services, seems like an internal dead lock there.

from ipopo.

So the issue is in ConfigurationAdmin._update, when we wait for all notifications to have been sent.
If this occurs at the moment when ConfigurationAdmin is called by iPOPO in an event that starts it (validation, binding of a required service), then:

• iPOPO is locked until ConfigAdmin returns
• ConfigAdmin won't return until all managed services have been updated, knowing that updated occur in a separate thead.

But in this case, the managed service updates a property of a registered service, which means iPOPO will have to send events to notify listeners (from the thread start by ConfigAdmin).
And here is the lock: iPOPO is waiting for the ConfigAdmin instance to be available, which waits for its managed service to be updated.

The quick fix is to stop configadmin from waiting, but that could remove the ordering of update notifications in some cases.

from ipopo.

I've made an issue_114 branch that avoids this deadlock by calling the initial update in the iPOPO thread.
Could you try with that version?

from ipopo.

The branch issue_114 solves the problem. Also starting ConfigAdmin before managed services does work.
Thanks a lot!

from ipopo.

OK thanks for the feedback.
The preferred way is to start config admin first (I'll add a note in the doc).
I'll make the behaviour of the issue_114 branch configurable via a framework property to ensure retro-compatibility.

from ipopo.

I just realized this issue does still exist (deadlock in updated() method). Somehow occuring very rarely when accessing config-admin in the component validate function and setting the self._name property. Yes I am using the isse_114 branch.

I think there is some race condition still existing.

BR

from ipopo.

OK, I'll take a look into it this week

from ipopo.