Deadlock on install/refresh

[Jad Naous <ja...@nerati.com>]

I am using Gemini JPA along with EclipseLink on Apache Felix, and I can
reproduce a deadlock at will. Here's what happens:

- Gemini JPA gets installed.
- My bundle which includes persistence entities is installing.
- Gemini JPA gets notification about my bundle's status change
- Gemini JPA scans the bundle, decides it's a persistence bundle, then
calls refresh on the bundle.
- The refresh is locked waiting for the install to complete
- The install is waiting for the refresh to complete.

Anybody seen something like that happen before? What's the right way to do
this? It seems like a lock ordering problem (looking at what's being
locked, it seems one thread is waiting for the bundle lock while the other
is waiting for the global lock).

Thanks,

Jad.

Re: Deadlock on install/refresh

[Jad Naous <ja...@nerati.com>]

Hmm, now I can't reproduce that anymore. All I can reproduce is the IPOJO
deadlock problem I started another thread on. Maybe I confused that problem
for this... Sorry to bother. I'll post again if I can reproduce and
immediately capture stack traces...

Thanks,
Jad.


On Thu, Dec 20, 2012 at 1:23 PM, Jad Naous <ja...@nerati.com> wrote:

> Coming up...
>
>
> On Thu, Dec 20, 2012 at 11:51 AM, Richard S. Hall <he...@ungoverned.org>wrote:
>
>> nto the installing thread until the refresh is done? If so, that sounds
>> like the issue to me. Assuming Gemini JPA is using a synchronous bundle
>> listener to get the bundle state change event, it shouldn't turn around and
>> block that thread.
>>
>> But that's just a guess. You could provide the framework version and
>> thread stack dumps to make our guesses more accurate. :-)
>>
>
>

Re: Deadlock on install/refresh

[Jad Naous <ja...@nerati.com>]

Coming up...

On Thu, Dec 20, 2012 at 11:51 AM, Richard S. Hall <he...@ungoverned.org>wrote:

> nto the installing thread until the refresh is done? If so, that sounds
> like the issue to me. Assuming Gemini JPA is using a synchronous bundle
> listener to get the bundle state change event, it shouldn't turn around and
> block that thread.
>
> But that's just a guess. You could provide the framework version and
> thread stack dumps to make our guesses more accurate. :-)
>

Re: Deadlock on install/refresh

["Richard S. Hall" <he...@ungoverned.org>]

On 12/20/12 14:43 , Jad Naous wrote:
> I am using Gemini JPA along with EclipseLink on Apache Felix, and I can
> reproduce a deadlock at will. Here's what happens:
>
> - Gemini JPA gets installed.
> - My bundle which includes persistence entities is installing.
> - Gemini JPA gets notification about my bundle's status change
> - Gemini JPA scans the bundle, decides it's a persistence bundle, then
> calls refresh on the bundle.
> - The refresh is locked waiting for the install to complete
> - The install is waiting for the refresh to complete.
>
> Anybody seen something like that happen before? What's the right way to do
> this? It seems like a lock ordering problem (looking at what's being
> locked, it seems one thread is waiting for the bundle lock while the other
> is waiting for the global lock).

Is Gemini JPA holding onto the installing thread until the refresh is 
done? If so, that sounds like the issue to me. Assuming Gemini JPA is 
using a synchronous bundle listener to get the bundle state change 
event, it shouldn't turn around and block that thread.

But that's just a guess. You could provide the framework version and 
thread stack dumps to make our guesses more accurate. :-)

-> richard

>
> Thanks,
>
> Jad.
>