Yes.
I'm tracking down the precise cause.
But some side effect of those MBeans causes DomainRoot to get a
NullPointerException while it's being validated by the AMXValidator.
Validation failures unregister failing MBeans, in this case
DomainRoot, which causes the entire AMX hierarchy to also be
unregistered.
I'm tracking down why the ORB MBeans cause a NPE in DomainRoot.
Lloyd
On Sep 2, 2009, at 5:25 PM, Ken Cavanaugh wrote:
> Lloyd Chambers wrote:
>> This a know issue.
>>
>> Ken Cavanaugh and I are working on tracking down the cause right
>> now. Something fairly complex is going on that corrupts the domain
>> somehow when running the full QL suite.
> I have a locally-installed b025 of the ORB that does not register
> MBeans. When I run QLs against the resulting GFv3 build,
> I get 4 adminconsole test failures and 19 AMX failures (instead of
> 38 or so in AMX). I'm not sure this is reproducible: I've run it
> twice now
> with differing results. It does seem clear though that starting the
> ORB (which runs fine) somehow does something to AMX that
> causes other tests to fail. The ordering is not clear in QL either
> to me at this point.
>
> One issue here is that direct clients of Gmbal (like the ORB and
> Metro) will register MBeans against the ManagedObjectManager's
> rootParent ObjectName regardless of whether AMX is running or not.
> This certainly causes some of the problems, but it's
> still unclear if this is the root cause of the QL failures or not.
> I think the solution we MAY wish to adopt is to have
> gmbal register a listener against the rootParent, and register/de-
> register it's MBeans according to the state of the rootParent.
> That way we can deal with the apparent desire of GFv3 to be able to
> start (and stop, and re-start, ...) the use of AMX
> dynamically. My incorrect assumption for gmbal was that either we
> would use MBeans (and use the full gmbal), or not
> use MBeans (and use gmbal-api-only, for distributions that do not
> require management). Fixing the will take 2-3 days
> assuming no interruptions, but we can simply avoid registering ORB
> MBeans until that fix is available and continue to
> make forward progress (at least we would have the latest ORB in the
> SCF GFv3).
>
> Ken.
Lloyd Chambers
lloyd.chambers_at_sun.com
GlassFish Team