[oscar-devel] Re: deadlock issues and a start level one.

[Manuel S. P. <san...@di...>]

Hello!


> 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.

> 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.
> 
> 
I'm sorry, but I cannot recreate the problem :(( I've tried, it but it
works correctly. Maybe the problem lies elsewhere. The real architecture
is that bundle A has got a JMX's MBeanServer with a RMI connector
server, which listens for incoming requests.
At startup time, bundle B invokes a method from bundle A (the agent),
through reflection and RMI (ie, a JMX remote connection), which provokes
that: 
1. A file is loaded. This works fine.
2. From that file, it reads which components it must instantiate. This
also works fine. 
3. It tries to instantiate all the stated components. Some of the
components's classes are in bundle B (exported by it).
4. It returns.
5. Bundle B finishes starting

However, the thing is that the system hangs, even the tui, so you must
kill oscar. But if I extract the code and put it inside a BundleListener
which checks that the bundle event corresponds to BundleB.STARTED, then
it works fine. If I find a bit of time, I shall try to recreate it, for
the moment I have not been able... 

Another thing, regarding start level:

When a started bundle is updated it is restarted. Then when packages are
refreshed, it is restarted with the new code.

If a bundle is started, and then you change the platform start level to
be higher than its startlevel, it stops. If you update the bundle and
refresh and change again the platform start level to be lower than the
bundle level, it is not started. Should not the service remember which
bundles were in started state for a given startlevel even if they are
updated?

> -> richard


Regards,

Manuel