Peter,
To dump OjbectNames (and much more), I use my own 'jxmcmd' which I'm
hoping to open source as its own project soon.
The two MBean names you cite are related; the AMX one delegates to the
com.sun.appserv one. This means that the underlying subsystem is not
cleaning up properly. The AMX MBean will remain around as long as its
delegate com.sun.appserv one remains around.
Monitoring MBeans should definitely *not* stay around after
rundeployment. This situation is definitely a bug.
Lloyd
..............................................
Lloyd Chambers
GlassFish team, LSARC member
On Jan 5, 2009, at 9:35 AM, Peter Williams wrote:
> Lloyd Chambers wrote:
>> Peter,
>>
>> Could you please check if similar MBeans are there in the JMX
>> com.sun.appserv domain? These are the "delegate" MBeans to which
>> AMX delegates. AMX reflects what the underlying system is doing.
>>
>> I see two possibilities:
>> 1) the com.sun.appserv MBeans exist and so naturally the AMX ones
>> do also. Then the bug lies deeper in the system.
> I think the com.sun.appserv beans still exist. How do I (easily)
> dump all the object names, as you request below?)
>
> For example, I undeployed an EAR that was named ServiceEARY. Both
> of the following beans still exist
>
> amx:X-ServerRootMonitor=server,j2eeType=X-
> ApplicationMonitor,name=ServiceEARY
> com
> .sun
> .appserv:name
> =ServiceEARY,type=application,category=monitor,server=server
>
> I'm not certain they are related to each other, but it's the closest
> match I could find. Note config beans related to this EAR no longer
> exist (consistent with it being undeployed.)
>
> Is it conceivable that someone decided monitoring beans should stay
> around so any data they possessed was still accessible (until
> restart at least)?
>
> -Peter
>
>> 2) the com.sun.appserv MBeans do not exist, but the AMX ones do.
>> That would indicate an AMX bug.
>>
>>
>> If you can just dump all MBeans (ObjectNames) in all domains I can
>> take a look.
>>
>> Lloyd
>>
>> ..............................................
>> Lloyd Chambers
>> lloyd.chambers_at_sun.com <mailto:lloyd.chambers_at_sun.com>
>> GlassFish team, LSARC member
>>
>>
>>
>>
>>
>>
>> On Jan 3, 2009, at 3:07 PM, Peter Williams wrote:
>>
>>> I discovered that if I have monitoring enabled (LOW on
>>> everything), undeploying and then deploy an EAR *with a new name*
>>> creates new monitors with the new name, but the old monitor mbeans
>>> ("amx:X-ApplicationMonitor") stay in existence until the server is
>>> restarted.
>>>
>>> This EAR contains web services and the old web service mbeans
>>> (specifically "amx:WebServiceEndpoint") also stay alive, though
>>> they can be detected due to their container element being invalid.
>>>
>>> Is this a bug or a feature?
>>>
>>> To me, it seems like a memory leak, as the entries seem to be
>>> obsolete (accessing them causes all kinds of trouble) but I was
>>> unable to get them to be GC'd.
>>>
>>> This is with GlassFish V21 B60e (also B60c), cluster profile
>>> (though no cluster or standalone instances were configured -- just
>>> "server").
>>>
>>> -Peter
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>