Re: [oscar-devel] Instantiation deadlock: A bug?

[Richard S. H. <he...@un...>]

Manuel Santillan Palencia wrote:

>I've already used a similar approach, by extracting all the problematic
>code from bundle B and putting it in a bundle event listener which
>executes itself when the bundle B is already started. 
>
>The thing is that if bundle B is in INSTALLED, RESOLVED OR STARTED
>state, then there is no problem in bundle A accesing a class from bundle
>B. However, if bundle A tries to access a class exported when bundle B
>is STARTING, he won't be able to do it. Is this the correct way of
>acting? Or should bundle A be able to access bundle B classes at any
>time?
>  
>

I think that Michel is correct when he states that it has nothing to do 
with the STARTING state, however, it could very likely be an Oscar issue 
in some respects. Oscar has to do some sanity locking so that it can 
ensure that refreshes don't happen in the middle of other operations, 
for example.

It is difficult to explain the approach, but Oscar uses two locks, where 
one is intended for simple operations and one is intended for 
adminstrative operations. An administrative operation can ensure 
complete mutex by getting both locks.

So what do I guess is happening in your case? Well, I haven't used RMI 
in a long, long time, but if I remember correctly, it uses threads. Most 
likely, Oscar calls out to your code, which then calls back into Oscar 
on a different thread trying to access the other bundle, which creates 
some sort of cycle.

My guess is you could recreate the problem without RMI, but by just 
creating a separate thread that tries to load the class.

>I mean, I 've already found workarounds for this problem. But I do not
>know if this is a bug (and therefore should need a fix) or is it just
>the way the spec says it should work. :)
>

If you can create a small example that demonstrates the problem, I will 
look into whether/how it is possible to loosen the concurrency control, 
but this is a very tricky issue. Obviously, Oscar cannot necessarily 
deal with people grabbing its thread in callbacks and then sending in a 
new thread.

-> richard