To follow up—
The ideal scenario is for MBeans to wait until AMX loads -- lazy
loading, so as to avoid consuming resources. I don't think anyone
will use the monitoring MBeans until/unless the rest of AMX loads.
The best way to do this is to wait for a MBeanServerNotification that
DomainRoot has loaded, then call waitAMXReady() on it. One doesn't
even need a thread for this, just a NotificationListener.
I'll write this code so that anyone can use the technique.
Lloyd
On Jun 29, 2009, at 1:41 PM, Lloyd Chambers wrote:
> OK, thanks.
>
> Yes, it's fine to register them prior to the parent existing, but
> once AMX loads, it will want the correct behavior from getParent().
>
> There is a potential race condition: AMX starts the validation
> thread as soon as DomainRoot and its immediate children load.
>
> If the parent is an MBean that is not yet registered by the time the
> validation thread checks, then validation would fail, because the
> parent would not be found.
>
> Lloyd
>
> On Jun 29, 2009, at 1:37 PM, Ken Cavanaugh wrote:
>
>> Lloyd Chambers wrote:
>>>
>>> There is one other potential problem: when are the MBeans being
>>> created?
>>>
>>> If they are created before DomainRoot, how can they have a parent?
>> So long as they are created with the correct ObjectName of the
>> parent, creation is fine.
>> The parent isn't actually needed until someone calls getParent on
>> the Gmbal ManagedObjectManager root,
>> which must result in the ObjectName of the parent.
>>>
>>> Could that be the problem?
>> Doesn't seem like it.
>>
>> Ken.
>>>
>>> Lloyd
>>>
>>> On Jun 29, 2009, at 1:17 PM, Ken Cavanaugh wrote:
>>>
>>>> Lloyd Chambers wrote:
>>>>> Someone has been creating AMX MBeans in Glassfish V3 using Gmbal
>>>>> (good).
>>>>>
>>>>> Except that the MBeans are in violation of the AMX spec: the
>>>>> Parent attribute is being returned as null. This will cause all
>>>>> sorts of downstream problems, namely breaking any client proxy
>>>>> code involving any non-complaint MBeans. It is also causing a
>>>>> mess in the server log and interfering with my progress
>>>>> elsewhere in AMX.
>>>>>
>>>>> In particular, the following MBeans fail when asked for the
>>>>> critical 'Parent' attribute, returning 'null':
>>>>>
>>>>> v3:type=JVMClassLoadingStatsProvider,name=jvm/class-loading-
>>>>> system,pp=/mon/server-mon[das]
>>>>> v3:type=JVMRuntimeStatsProvider,name=jvm/runtime,pp=/mon/server-
>>>>> mon[das]
>>>>> v3:type=JVMMemoryStatsProvider,name=jvm/memory,pp=/mon/server-
>>>>> mon[das]
>>>>> v3:type=JVMGCStatsProvider,name=jvm/garbage-collectors,pp=/mon/
>>>>> server-mon[das]
>>>>> v3:type=JVMCompilationStatsProvider,name=jvm/compilation-
>>>>> system,pp=/mon/server-mon[das]
>>>>> v3:type=JVMOSStatsProvider,name=jvm/operating-system,pp=/mon/
>>>>> server-mon[das]
>>>>> v3:pp=/mon/server-
>>>>> mon[das],type=HttpServiceStatsProvider,name=http-service/__asadmin
>>>>>
>>>>> Will whoever is responsible for these MBeans please contact me
>>>>> to resolve this--thanks.
>>>>>
>>>> Keep me in the loop on this, in case this is a Gmbal problem.
>>>> I'm concerned about
>>>> MBeans registered at the Gmbal root using a ManagedObjectManager
>>>> that was created
>>>> with createFederated (the normal case in GFv3). I'm checking my
>>>> tests and investigating this now.
>>>>
>>>> Thanks,
>>>>
>>>> Ken.
>>>>
>>>>
>>>
>>> Lloyd Chambers
>>> lloyd.chambers_at_sun.com
>>> GlassFish Team
>>>
>>>
>>>
>>
>
> Lloyd Chambers
> lloyd.chambers_at_sun.com
> GlassFish Team
>
>
>
Lloyd Chambers
lloyd.chambers_at_sun.com
GlassFish Team