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.