esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Hirsch <>
Subject Re: Requesting feedback on JMX REST API...
Date Fri, 20 Nov 2009 04:43:44 GMT
Posted message about SolutionManager and REST on the SDN forum:


On Fri, Nov 20, 2009 at 5:31 AM, Richard Hirsch <> wrote:
> Looks great.
>>>There is no security on the api. This obviously should not stay like this and
should only be accessable with an administrator >>account.
> You are probably correct about the necessity of authorization added to
> the interface but this might just be necessary for those interfaces
> that write / change settings, What about using the lift authorization
> mechanism here to distinguish it from the ESME user base?
>>It is worth thinking about switching to a property api like Configgy which uses mutable
data structures for properties.
> This is a good idea. First we must determine which properties might be
> useful to be to change on the fly. I once started a list of such
> properties in the wiki. I'll finish it and publish the link.
> I really like the fact that JMX data is available via REST. I started
> looking and found there is a a related JSR 262, Web Services Connector
> for JMX Agents where the author examined rest-based access
> (
>  The author has some interesting ideas (for example, creating an Ajax
> based application to follow the JMX changes), I also found a very old
> Google Code project that looked at this topic
> ( where the author
> mentions using Cacti (Cacti is a complete network graphing solution:
> to graph the material. Maybe we could try and
> use Cacti as well to graph our data.
> So you could probably create a very cool administration application
> for ESME (written in whatever language you want) that allows you to
> monitor everything in ESME. What I'd like to see is a very basic admin
> app (maybe separate from ESME). Creating more complicated admin apps
> would then be a business opportunity for someone.
> What we have to look at as well is how to deal with those enterprises
> that already have monitoring environments in place (for example,
> SolMan).  I don't know if such applications can deal with REST. I'll
> do some research here.
> So, in my opinion, it looks v. cool. Send me a patch and I'll commit
> it.  Once we get the foundation up and running, we should talk about
> what other measures we want to monitor.
> Thanks.
> D.
> On Fri, Nov 20, 2009 at 3:55 AM, Andy the destroyer
> <> wrote:
>> FYI & RFC
>> I have finished a REST api for generic jmx MBeans. It allows for listing
>> mbeans, getting mbeaninfo, reading and setting attributes and invoking
>> operations with parameters that can be represented as Strings ( i.e. String,
>> Long etc. serialized classes don't count).
>> Before I send to code to Richard I would like some feedback to see if I am
>> missing something or should do something different.
>> Here is the api and sample returns. Bad requests or errors will return
>> BadResponse.
>> GET /jmx/mbeans - returns a list of mbean names
>> GET /jmx/mbean/[mbean name]/info - returns MBeanInfo for specified mbean
>> GET /jmx/mbean/[mbean name]/attributes - returns attribute name and string
>> values
>> POST /jmx/mbean/[mbean name]/invoke/[operation name]
>> <Params>
>>  <Param>pone</Param>
>>  <Param signature="java.lang.Long">123</Param>
>> </Params>
>> POST /jmx/mbean/[mbean name/set - sets a single attribute
>> <Attribute name="attr" value="val" />
>> POST /jmx/mbean/[mbean name]/set - sets multiple attributes
>> <AttributeList>
>>  <Attribute name="att1" value="val1" />
>>  <Attrubute name="att2" value="val2" />
>> </AttributeList>
>> == SAMPLES ==
>> GET /jmx/mbeans
>> <esme_api operation="mbeans" success="true">
>> <MBeans>
>> <MBean name="java.lang:type=Memory"/>
>> <MBean name="java.lang:type=GarbageCollector,name=Copy"/>
>> <MBean name="java.lang:type=MemoryPool,name=Code Cache"/>
>> <MBean name="java.lang:type=Runtime"/>
>> <MBean name="java.lang:type=ClassLoading"/>
>> <MBean name="java.lang:type=MemoryPool,name=Perm Gen [shared-rw]"/>
>> <MBean name="java.lang:type=Threading"/>
>> <MBean name="java.util.logging:type=Logging"/>
>> <MBean name="java.lang:type=MemoryPool,name=Perm Gen [shared-ro]"/>
>> <MBean name="java.lang:type=Compilation"/>
>> <MBean name="java.lang:type=MemoryPool,name=Eden Space"/>
>> <MBean name="org.apache.esme.stats:type=Stats"/>
>> <MBean name="StatsAgent:name=htmlAdaptor,port=9092"/>
>> <MBean name=""/>
>> <MBean name="java.lang:type=GarbageCollector,name=MarkSweepCompact"/>
>> <MBean name="java.lang:type=MemoryPool,name=Survivor Space"/>
>> <MBean name="java.lang:type=MemoryPool,name=Tenured Gen"/>
>> <MBean name="java.lang:type=MemoryPool,name=Perm Gen"/>
>> <MBean name="java.lang:type=OperatingSystem"/>
>> <MBean name="JMImplementation:type=MBeanServerDelegate"/>
>> <MBean name="java.lang:type=MemoryManager,name=CodeCacheManager"/>
>> </MBeans>
>> </esme_api>
>> GET /jmx/mbean/org.apache.esme.stats:type=Stats/attributes
>> <esme_api operation="mbean" success="true">
>> <MBeanAttributes name="org.apache.esme.stats:type=Stats">
>> <MBeanAttribute value="1" name="counter_userCount"/>
>> <MBeanAttribute value="1" name="counter_liftSessions"/>
>> <MBeanAttribute value="1.0" name="gauge_users"/>
>> <MBeanAttribute value="1.0" name="gauge_listener"/>
>> </MBeanAttributes>
>> </esme_api>
>> GET /jmx/mbean/org.apache.esme.stats:type=Stats/info
>> <esme_api operation="mbean" success="true">
>> <MBeanInfo name="org.apache.esme.stats:type=Stats">
>> <MBeanAttributes>
>> <MBeanAttributeInfo isIs="false" type="java.lang.Long" description="counter"
>> isReadable="true" name="counter_userCount" isWritable="false"/>
>> <MBeanAttributeInfo isIs="false" type="java.lang.Long" description="counter"
>> isReadable="true" name="counter_liftSessions" isWritable="false"/>
>> <MBeanAttributeInfo isIs="false" type="java.lang.Long" description="gauge"
>> isReadable="true" name="gauge_users" isWritable="false"/>
>> <MBeanAttributeInfo isIs="false" type="java.lang.Long" description="gauge"
>> isReadable="true" name="gauge_listener" isWritable="false"/>
>> </MBeanAttributes>
>> <MBeanOperations>
>> <MBeanOperationInfo impact="ACTION" description="Remove all Counters,
>> Timers, Gauges and restart gathering timestamp."
>> returnType="java.lang.String" name="clear">
>> <Signature>
>> </Signature>
>> </MBeanOperationInfo>
>> </MBeanOperations>
>> <MBeanNotifications/>
>> </MBeanInfo>
>> </esme_api>
>> =================
>> There is no security on the api. This obviously should not stay like this
>> and should only be accessable with an administrator account.
>> I tested it with the Stats MBean and the java.util.Logging MBean and it is
>> working. I can access stats, reset them and change logging levels.
>> It would be nice to be able to change runtime properties though JMX however
>> most of the Lift and ESME code uses vals and immutable data structures that
>> are set when the app is originally loaded. The lift Props object used by
>> esme is totally immutable after it is constructed. It is worth thinking
>> about switching to a property api like Configgy which uses mutable data
>> structures for properties.
>> We could change in real time things like resent & links period, refresh
>> intervals, analyzer settings like long query time, db connection pool sizes
>> etc.
>> I didn't enable sending serialized objects through the REST api because it
>> seems like more trouble than it's worth. Besides that sort of JMX
>> functionality is only useful between servers and this api is really just for
>> the cloud environment like stax which doesn't allow you to bind to ports.
>> I welcome any comments or suggestions of Stats or JMX features to add before
>> I send the code to Richard. Should invalid requests return specific error
>> messages or just BadResponse?
>> Thanks,
>> Andy

View raw message