Peter,
I agree the docs for AMX can be improved.
Regarding naming: I am speaking of the JMX domain part of the MBean
ObjectName, not the Java package name.
For example, the DomainRoot MBean has ObjectName:
amx:j2eeType=X-DomainRoot,name=na
The "amx" part before the ':' is the JMX domain. All "amx" MBeans are
public. There are also "com.sun.appserv" MBeans, which are private,
and some other domains as well (private also, except for java.lang).
All of AMX interfaces (and implementation) is in the Java package
com.sun.appserv.*, so I can see how this would be confusing WRT the
JMX domain.
Lloyd
On Nov 10, 2008, at 12:19 PM, Peter Williams wrote:
> Hi Lloyd,
>
> Thanks for the comments. More of mine, inline.
>
> Lloyd Chambers wrote:
>> Peter,
>>
>> First, AMX is JMX.
>>
>> This information is available in AMX.
> No offense, but it has not been easy to find. I think maybe part of
> that my unfamiliarity with JMX naming conventions, which I read up
> on heavily on last week, so hopefully that part of the learning
> curve is past.
>
>> Private MBeans (com.sun.appserv) should not be used unless there is
>> no alternative.
> Ok, now I'm a little confused. Every single MBean reference in the
> code I have is from a subpackages of com.sun.appserv, and the
> javadoc you reference below seems to cover them too. And you are
> referencing com.sun.appserv beans in your example below? What
> packages are the public MBeans in, if not these?
>
> Or did you mean literally the classes in package com.sun.appserv? I
> don't see any classes in that package at all (presumably because
> they aren't public).
>
> I certainly don't want any code using private interfaces unless I
> have no other choice (and probably not even then).
>
>>
>> Peter, the AMX docs explain the structure of AMX, which includes
>> the apropos JSR 77 MBeans.
>> https://glassfish.dev.java.net/javaee5/amx/index.html
>> https://glassfish.dev.java.net/javaee5/amx/docs/amx.html
> I've read both of these fully, but thanks for the reference.
>>
>> In this case it's easy (might be slight typos here, going from
>> memory):
>>
>> DomainRoot dr = ...;
>> final Map<String,J2EEServer> servers =
>> domainRoot.getJ2EEDomain().getJ2EEServerMap();
>> for( final J2EEServer s : servers.values() ) {
>> final int status = s.getstate(); // see JSR 77 if ( state ==
>> STATE_RUNNING ) {
>> ...
>> }
>> }
> What I came up with on Friday is following this chain (which seems
> the same as what you describe).
>
> DomainRoot -> J2EEDomain -> J2EECluster (map) -> J2EEServer (map)
>
> It does work, FWIW.
>
> One question -- do you happen to know how much bandwidth a typical
> JMX call consumes? I noticed a substantial delay when accessing
> from a remote workstation where one channel is 192Kb (upstream
> DSL). I will probably just have to run some tests, but if you have
> any advice on minimizing the costs of a call or call aggregation, it
> would be most welcome.
>
> Thanks!
> -Peter
>
>>
>> Lloyd
>>
>> On Nov 7, 2008, at 1:51 PM, Sreenivas Munnangi wrote:
>>
>>> Peter Williams wrote:
>>>> I need to know how to get the status (stopped, running, etc.) of
>>>> a server instance inside a cluster using either the AMX api
>>>> (preferable) or JMX calls. I wasn't able to find a JMX field
>>>> that contains this information though. Does anyone know where I
>>>> should be looking?
>>>>
>>>> -Peter
>>>>
>>> I guess, you are referring to v2.
>>>
>>> JSR77 mBeans report the runtime state, for ex.
>>>
>>> * *MBean Name:*
>>>
>>> com.sun.appserv:j2eeType=J2EEServer,name=server,category=runtime
>>>
>>> If the '*stateManageable' is true then you can invoke the
>>> operation '**getRuntimeStatus*
>>> com.sun.enterprise.admin.servermgmt.RuntimeStatus
>>>
>>>
>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>