You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@esme.apache.org by Andy the destroyer <an...@gmail.com> on 2009/11/20 03:55:14 UTC
Requesting feedback on JMX REST API...
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="com.sun.management:type=HotSpotDiagnostic"/>
<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
Re: Requesting feedback on JMX REST API...
Posted by Markus Kohler <ma...@gmail.com>.
Hi Andy,
Great!
Regarding your question.
I was just wondering whether one could just allways post to /jmx/mbean/[mbean
name and the "Servlet" would be smart enough to understand that attributes
should be set.
Might not make a big difference though.
Regards,
Markus
On Fri, Nov 20, 2009 at 8:28 PM, Andy the destroyer <
andythedestroyer@gmail.com> wrote:
> Markus, great feedback. Thanks!
> Responses below...
>
> On Thu, Nov 19, 2009 at 11:10 PM, Markus Kohler <markus.kohler@gmail.com
> >wrote:
>
> > Hi Andy,
> > See my comments below...
> >
> > On Fri, Nov 20, 2009 at 3:55 AM, Andy the destroyer <
> > andythedestroyer@gmail.com> 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
> > >
> >
> > I would suggest returning the urls in the next line directly. That would
> > make it compliant with the HATEOS constraint.
> > The advantage is that the client does not need to know how to construct
> the
> > URL.
> >
>
> I agree. Good idea. I will work on making this HTTP API more RESTful.
>
> >
> >
> > > GET /jmx/mbean/[mbean name]/info - returns MBeanInfo for specified
> mbean
> > > GET /jmx/mbean/[mbean name]/attributes - returns attribute name and
> > string
> > > values
> > >
> > >
> > Would it make sense to support GET /jmx/mbean/[mbean name] as well, which
> > would return everything?
> >
>
> I originally did that but due to a bug in lift I could not end a URI with
> the bean name so I just included everything separately. I got a message
> from
> DPP yesterday saying the bug was fixed. I will add it.
>
>
> >
> >
> > > 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>
> > >
> > >
> > Hmm, partially updating a resource is an recurring pattern. I'm not a
> 100%
> > sure yet what would be the best way to do it, but couldn't one just do it
> > without the "set" postfix?
> >
>
> I'm not sure I understand what you are saying. With the above resources I
> am
> just providing an API to MBeanServer.invoke, MBeanServer.setAttribute and
> MBeanServer.setAttributes.
>
>
> >
> >
> > > == 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="com.sun.management:type=HotSpotDiagnostic"/>
> > > <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
> > >
> >
> >
> > Regards,
> > Markus
> >
>
Re: Requesting feedback on JMX REST API...
Posted by Andy the destroyer <an...@gmail.com>.
Markus, great feedback. Thanks!
Responses below...
On Thu, Nov 19, 2009 at 11:10 PM, Markus Kohler <ma...@gmail.com>wrote:
> Hi Andy,
> See my comments below...
>
> On Fri, Nov 20, 2009 at 3:55 AM, Andy the destroyer <
> andythedestroyer@gmail.com> 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
> >
>
> I would suggest returning the urls in the next line directly. That would
> make it compliant with the HATEOS constraint.
> The advantage is that the client does not need to know how to construct the
> URL.
>
I agree. Good idea. I will work on making this HTTP API more RESTful.
>
>
> > GET /jmx/mbean/[mbean name]/info - returns MBeanInfo for specified mbean
> > GET /jmx/mbean/[mbean name]/attributes - returns attribute name and
> string
> > values
> >
> >
> Would it make sense to support GET /jmx/mbean/[mbean name] as well, which
> would return everything?
>
I originally did that but due to a bug in lift I could not end a URI with
the bean name so I just included everything separately. I got a message from
DPP yesterday saying the bug was fixed. I will add it.
>
>
> > 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>
> >
> >
> Hmm, partially updating a resource is an recurring pattern. I'm not a 100%
> sure yet what would be the best way to do it, but couldn't one just do it
> without the "set" postfix?
>
I'm not sure I understand what you are saying. With the above resources I am
just providing an API to MBeanServer.invoke, MBeanServer.setAttribute and
MBeanServer.setAttributes.
>
>
> > == 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="com.sun.management:type=HotSpotDiagnostic"/>
> > <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
> >
>
>
> Regards,
> Markus
>
Re: Requesting feedback on JMX REST API...
Posted by Markus Kohler <ma...@gmail.com>.
Hi Andy,
See my comments below...
On Fri, Nov 20, 2009 at 3:55 AM, Andy the destroyer <
andythedestroyer@gmail.com> 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
>
I would suggest returning the urls in the next line directly. That would
make it compliant with the HATEOS constraint.
The advantage is that the client does not need to know how to construct the
URL.
> GET /jmx/mbean/[mbean name]/info - returns MBeanInfo for specified mbean
> GET /jmx/mbean/[mbean name]/attributes - returns attribute name and string
> values
>
>
Would it make sense to support GET /jmx/mbean/[mbean name] as well, which
would return everything?
> 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>
>
>
Hmm, partially updating a resource is an recurring pattern. I'm not a 100%
sure yet what would be the best way to do it, but couldn't one just do it
without the "set" postfix?
> == 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="com.sun.management:type=HotSpotDiagnostic"/>
> <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
>
Regards,
Markus
Re: Requesting feedback on JMX REST API...
Posted by Andy the destroyer <an...@gmail.com>.
On Thu, Nov 19, 2009 at 8:51 PM, Richard Hirsch <hi...@gmail.com>wrote:
> Just had another idea.
>
> @Andy: Is the pure JMX interface gone or just not active? I think it
> would be a interesting idea to be able to turn the real JMX interface
> on and off. If you can use the JMX interface (for example, behind the
> firewall in an on-premise installation), you turn it on. If you are in
> the cloud and can't use traditional JMX or don't have a use a
> enterprise monitoring system that understands JMX (for example, in
> smaller organizations), you turn it off.
>
Pure JMX interface is always available to jconsole on localhost as long as
our MBeans are registered with the platform server.
>
> That way we could have the best of both worlds.
>
> Or another idea would be to offer a small component that reads the
> REST API and creates JMX out of it. If companies want JMX instead of
> REST, they could install this component. This solution might have
> performance probs though....
>
I don't think the REST or HTTP api would be a good intermediary between esme
and another JMX adaptor. We would have to enable marshalling objects through
HTTP which is more trouble than it is worth.
Thanks again for the suggestions.
Andy
>
> D.
>
> On Fri, Nov 20, 2009 at 5:43 AM, Richard Hirsch <hi...@gmail.com>
> wrote:
> > Posted message about SolutionManager and REST on the SDN forum:
> > http://forums.sdn.sap.com/thread.jspa?threadID=1536884
> >
> > D.
> >
> > On Fri, Nov 20, 2009 at 5:31 AM, Richard Hirsch <hi...@gmail.com>
> 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
> >> (
> http://blogs.sun.com/jmxnetbeans/entry/restful_access_to_jmx_instrumentation
> ).
> >> 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
> >> (http://code.google.com/p/polarrose-jmx-rest-bridge/) where the author
> >> mentions using Cacti (Cacti is a complete network graphing solution:
> >> http://www.cacti.net/) 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
> >> <an...@gmail.com> 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="com.sun.management:type=HotSpotDiagnostic"/>
> >>> <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
> >>>
> >>
> >
>
Re: Requesting feedback on JMX REST API...
Posted by David Pollak <fe...@gmail.com>.
On Fri, Nov 20, 2009 at 9:19 AM, Richard Hirsch <hi...@gmail.com>wrote:
> Sounds like a good idea: what about calling it: ESME JMX HTTP-based API
>
Hmmm... I'm getting the sense that this could be made more generic and
turned into a subproject... it's exciting on its own.
>
> D.
>
> On Fri, Nov 20, 2009 at 4:36 PM, Ethan Jewett <es...@gmail.com> wrote:
> > This looks very cool! :-)
> >
> > I don't have much to add here, but I will reiterate what has become my
> > usual request: Can we try to stick to calling these APIs "HTTP APIs"
> > not "REST APIs".
> >
> > I want to avoid getting into another flamewar with the web about how
> > the ESME team doesn't adhere to REST orthodoxy. It just isn't worth
> > it.
> >
> > Ethan
> >
> > On Fri, Nov 20, 2009 at 2:01 AM, Markus Kohler <ma...@gmail.com>
> wrote:
> >> Hi all,
> >> Most enterprise monitoring systems understand JMX . IIRC the issue was
> >> always that the remote JMX interface was vendor specific. Not sure
> whether
> >> that's still the case.
> >> JMX is rather inefficent I think. Most enterprises use products such as
> >> Wiley Introscope (defacto SAP standard) or Dynatrace.
> >>
> >> We should probably look what interfaces they offer. Usually the main
> issue
> >> is to find the right instrumentation points in the code.
> >>
> >>
> >> Regards,
> >> Markus
> >>
> >> On Fri, Nov 20, 2009 at 5:51 AM, Richard Hirsch <hirsch.dick@gmail.com
> >wrote:
> >>
> >>> Just had another idea.
> >>>
> >>> @Andy: Is the pure JMX interface gone or just not active? I think it
> >>> would be a interesting idea to be able to turn the real JMX interface
> >>> on and off. If you can use the JMX interface (for example, behind the
> >>> firewall in an on-premise installation), you turn it on. If you are in
> >>> the cloud and can't use traditional JMX or don't have a use a
> >>> enterprise monitoring system that understands JMX (for example, in
> >>> smaller organizations), you turn it off.
> >>>
> >>> That way we could have the best of both worlds.
> >>>
> >>> Or another idea would be to offer a small component that reads the
> >>> REST API and creates JMX out of it. If companies want JMX instead of
> >>> REST, they could install this component. This solution might have
> >>> performance probs though....
> >>>
> >>> D.
> >>>
> >>> On Fri, Nov 20, 2009 at 5:43 AM, Richard Hirsch <hirsch.dick@gmail.com
> >
> >>> wrote:
> >>> > Posted message about SolutionManager and REST on the SDN forum:
> >>> > http://forums.sdn.sap.com/thread.jspa?threadID=1536884
> >>> >
> >>> > D.
> >>> >
> >>> > On Fri, Nov 20, 2009 at 5:31 AM, Richard Hirsch <
> hirsch.dick@gmail.com>
> >>> 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
> >>> >> (
> >>>
> http://blogs.sun.com/jmxnetbeans/entry/restful_access_to_jmx_instrumentation
> >>> ).
> >>> >> 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
> >>> >> (http://code.google.com/p/polarrose-jmx-rest-bridge/) where the
> author
> >>> >> mentions using Cacti (Cacti is a complete network graphing solution:
> >>> >> http://www.cacti.net/) 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
> >>> >> <an...@gmail.com> 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="com.sun.management:type=HotSpotDiagnostic"/>
> >>> >>> <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
> >>> >>>
> >>> >>
> >>> >
> >>>
> >>
> >
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
Re: Requesting feedback on JMX REST API...
Posted by Richard Hirsch <hi...@gmail.com>.
Sounds like a good idea: what about calling it: ESME JMX HTTP-based API
D.
On Fri, Nov 20, 2009 at 4:36 PM, Ethan Jewett <es...@gmail.com> wrote:
> This looks very cool! :-)
>
> I don't have much to add here, but I will reiterate what has become my
> usual request: Can we try to stick to calling these APIs "HTTP APIs"
> not "REST APIs".
>
> I want to avoid getting into another flamewar with the web about how
> the ESME team doesn't adhere to REST orthodoxy. It just isn't worth
> it.
>
> Ethan
>
> On Fri, Nov 20, 2009 at 2:01 AM, Markus Kohler <ma...@gmail.com> wrote:
>> Hi all,
>> Most enterprise monitoring systems understand JMX . IIRC the issue was
>> always that the remote JMX interface was vendor specific. Not sure whether
>> that's still the case.
>> JMX is rather inefficent I think. Most enterprises use products such as
>> Wiley Introscope (defacto SAP standard) or Dynatrace.
>>
>> We should probably look what interfaces they offer. Usually the main issue
>> is to find the right instrumentation points in the code.
>>
>>
>> Regards,
>> Markus
>>
>> On Fri, Nov 20, 2009 at 5:51 AM, Richard Hirsch <hi...@gmail.com>wrote:
>>
>>> Just had another idea.
>>>
>>> @Andy: Is the pure JMX interface gone or just not active? I think it
>>> would be a interesting idea to be able to turn the real JMX interface
>>> on and off. If you can use the JMX interface (for example, behind the
>>> firewall in an on-premise installation), you turn it on. If you are in
>>> the cloud and can't use traditional JMX or don't have a use a
>>> enterprise monitoring system that understands JMX (for example, in
>>> smaller organizations), you turn it off.
>>>
>>> That way we could have the best of both worlds.
>>>
>>> Or another idea would be to offer a small component that reads the
>>> REST API and creates JMX out of it. If companies want JMX instead of
>>> REST, they could install this component. This solution might have
>>> performance probs though....
>>>
>>> D.
>>>
>>> On Fri, Nov 20, 2009 at 5:43 AM, Richard Hirsch <hi...@gmail.com>
>>> wrote:
>>> > Posted message about SolutionManager and REST on the SDN forum:
>>> > http://forums.sdn.sap.com/thread.jspa?threadID=1536884
>>> >
>>> > D.
>>> >
>>> > On Fri, Nov 20, 2009 at 5:31 AM, Richard Hirsch <hi...@gmail.com>
>>> 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
>>> >> (
>>> http://blogs.sun.com/jmxnetbeans/entry/restful_access_to_jmx_instrumentation
>>> ).
>>> >> 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
>>> >> (http://code.google.com/p/polarrose-jmx-rest-bridge/) where the author
>>> >> mentions using Cacti (Cacti is a complete network graphing solution:
>>> >> http://www.cacti.net/) 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
>>> >> <an...@gmail.com> 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="com.sun.management:type=HotSpotDiagnostic"/>
>>> >>> <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
>>> >>>
>>> >>
>>> >
>>>
>>
>
Re: Requesting feedback on JMX REST API...
Posted by Andy the destroyer <an...@gmail.com>.
Sure thing. It shall now be known as the JMX HTTP API :) . Also, regarding
comments from Markus above, I will make it more RESTful. Who knows maybe
someday we may actually adhere to the orthodoxy. It is good to have goals.
-A
On Fri, Nov 20, 2009 at 7:36 AM, Ethan Jewett <es...@gmail.com> wrote:
> This looks very cool! :-)
>
> I don't have much to add here, but I will reiterate what has become my
> usual request: Can we try to stick to calling these APIs "HTTP APIs"
> not "REST APIs".
>
> I want to avoid getting into another flamewar with the web about how
> the ESME team doesn't adhere to REST orthodoxy. It just isn't worth
> it.
>
> Ethan
>
> On Fri, Nov 20, 2009 at 2:01 AM, Markus Kohler <ma...@gmail.com>
> wrote:
> > Hi all,
> > Most enterprise monitoring systems understand JMX . IIRC the issue was
> > always that the remote JMX interface was vendor specific. Not sure
> whether
> > that's still the case.
> > JMX is rather inefficent I think. Most enterprises use products such as
> > Wiley Introscope (defacto SAP standard) or Dynatrace.
> >
> > We should probably look what interfaces they offer. Usually the main
> issue
> > is to find the right instrumentation points in the code.
> >
> >
> > Regards,
> > Markus
> >
> > On Fri, Nov 20, 2009 at 5:51 AM, Richard Hirsch <hirsch.dick@gmail.com
> >wrote:
> >
> >> Just had another idea.
> >>
> >> @Andy: Is the pure JMX interface gone or just not active? I think it
> >> would be a interesting idea to be able to turn the real JMX interface
> >> on and off. If you can use the JMX interface (for example, behind the
> >> firewall in an on-premise installation), you turn it on. If you are in
> >> the cloud and can't use traditional JMX or don't have a use a
> >> enterprise monitoring system that understands JMX (for example, in
> >> smaller organizations), you turn it off.
> >>
> >> That way we could have the best of both worlds.
> >>
> >> Or another idea would be to offer a small component that reads the
> >> REST API and creates JMX out of it. If companies want JMX instead of
> >> REST, they could install this component. This solution might have
> >> performance probs though....
> >>
> >> D.
> >>
> >> On Fri, Nov 20, 2009 at 5:43 AM, Richard Hirsch <hi...@gmail.com>
> >> wrote:
> >> > Posted message about SolutionManager and REST on the SDN forum:
> >> > http://forums.sdn.sap.com/thread.jspa?threadID=1536884
> >> >
> >> > D.
> >> >
> >> > On Fri, Nov 20, 2009 at 5:31 AM, Richard Hirsch <
> hirsch.dick@gmail.com>
> >> 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
> >> >> (
> >>
> http://blogs.sun.com/jmxnetbeans/entry/restful_access_to_jmx_instrumentation
> >> ).
> >> >> 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
> >> >> (http://code.google.com/p/polarrose-jmx-rest-bridge/) where the
> author
> >> >> mentions using Cacti (Cacti is a complete network graphing solution:
> >> >> http://www.cacti.net/) 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
> >> >> <an...@gmail.com> 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="com.sun.management:type=HotSpotDiagnostic"/>
> >> >>> <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
> >> >>>
> >> >>
> >> >
> >>
> >
>
Re: Requesting feedback on JMX REST API...
Posted by Ethan Jewett <es...@gmail.com>.
This looks very cool! :-)
I don't have much to add here, but I will reiterate what has become my
usual request: Can we try to stick to calling these APIs "HTTP APIs"
not "REST APIs".
I want to avoid getting into another flamewar with the web about how
the ESME team doesn't adhere to REST orthodoxy. It just isn't worth
it.
Ethan
On Fri, Nov 20, 2009 at 2:01 AM, Markus Kohler <ma...@gmail.com> wrote:
> Hi all,
> Most enterprise monitoring systems understand JMX . IIRC the issue was
> always that the remote JMX interface was vendor specific. Not sure whether
> that's still the case.
> JMX is rather inefficent I think. Most enterprises use products such as
> Wiley Introscope (defacto SAP standard) or Dynatrace.
>
> We should probably look what interfaces they offer. Usually the main issue
> is to find the right instrumentation points in the code.
>
>
> Regards,
> Markus
>
> On Fri, Nov 20, 2009 at 5:51 AM, Richard Hirsch <hi...@gmail.com>wrote:
>
>> Just had another idea.
>>
>> @Andy: Is the pure JMX interface gone or just not active? I think it
>> would be a interesting idea to be able to turn the real JMX interface
>> on and off. If you can use the JMX interface (for example, behind the
>> firewall in an on-premise installation), you turn it on. If you are in
>> the cloud and can't use traditional JMX or don't have a use a
>> enterprise monitoring system that understands JMX (for example, in
>> smaller organizations), you turn it off.
>>
>> That way we could have the best of both worlds.
>>
>> Or another idea would be to offer a small component that reads the
>> REST API and creates JMX out of it. If companies want JMX instead of
>> REST, they could install this component. This solution might have
>> performance probs though....
>>
>> D.
>>
>> On Fri, Nov 20, 2009 at 5:43 AM, Richard Hirsch <hi...@gmail.com>
>> wrote:
>> > Posted message about SolutionManager and REST on the SDN forum:
>> > http://forums.sdn.sap.com/thread.jspa?threadID=1536884
>> >
>> > D.
>> >
>> > On Fri, Nov 20, 2009 at 5:31 AM, Richard Hirsch <hi...@gmail.com>
>> 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
>> >> (
>> http://blogs.sun.com/jmxnetbeans/entry/restful_access_to_jmx_instrumentation
>> ).
>> >> 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
>> >> (http://code.google.com/p/polarrose-jmx-rest-bridge/) where the author
>> >> mentions using Cacti (Cacti is a complete network graphing solution:
>> >> http://www.cacti.net/) 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
>> >> <an...@gmail.com> 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="com.sun.management:type=HotSpotDiagnostic"/>
>> >>> <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
>> >>>
>> >>
>> >
>>
>
Re: Requesting feedback on JMX REST API...
Posted by Richard Hirsch <hi...@gmail.com>.
I've added Andy's initial description to the wiki as a placeholder:
http://cwiki.apache.org/confluence/display/ESME/JMX+REST+API
@Andy: You may want to submit an Apache iCLA then you could edit the
page yourself.
D.
On Sat, Nov 21, 2009 at 10:36 AM, Markus Kohler <ma...@gmail.com> wrote:
> Hi Andy,
> Dynatrace rocks, and Introscope is kind of the "old defacto standard. They
> both can get the more detailed stats you mentioned below, but can also get
> simple KPI's such as GC information. SNMP might also be an option to expose
> simple KPI's.
>
> All we need is a list of methods that we would want to measure.
> Those tools are then able to measure cpu time, elapsed time, nr. of calls
> etc.
> I
> f we are really serious about this I think we should go for Dynatrace first.
> I haven't checked whether they have an evaluation license. If not maybe we
> can arrange some agreement with them. I happen to know some key people
> there, because I once did an evaluation.
>
> Regards,
> Markus
>
> On Fri, Nov 20, 2009 at 9:33 PM, Andy the destroyer <
> andythedestroyer@gmail.com> wrote:
>
>> I am not familiar with Inroscope or Dynatrace. I will check them out. As
>> far
>> as instrumentation points, I think we need to find the use cases and they
>> will dicate the technology or tools used. Right now we are just collecting
>> Stats and we can change logging levels. With some changes to how esme and
>> lift is configured we could do things like injecting new db servers to a
>> connection pool, new request analyzers etc. However that sort of
>> instrumentation is in my opinion better accomplished through OSGi.
>>
>> In stats collection I looked at some profiling tools that can collect
>> method
>> call counts, durations, exceptions thrown etc. I didn't use any of these
>> because they slow down the JVM. From the names it sounds like Dynatrace
>> provides this sort of data. Ill look into it.
>>
>> -Andy
>>
>> On Fri, Nov 20, 2009 at 12:01 AM, Markus Kohler <markus.kohler@gmail.com
>> >wrote:
>>
>> > Hi all,
>> > Most enterprise monitoring systems understand JMX . IIRC the issue was
>> > always that the remote JMX interface was vendor specific. Not sure
>> whether
>> > that's still the case.
>> > JMX is rather inefficent I think. Most enterprises use products such as
>> > Wiley Introscope (defacto SAP standard) or Dynatrace.
>> >
>> > We should probably look what interfaces they offer. Usually the main
>> issue
>> > is to find the right instrumentation points in the code.
>> >
>> >
>> > Regards,
>> > Markus
>> >
>> > On Fri, Nov 20, 2009 at 5:51 AM, Richard Hirsch <hirsch.dick@gmail.com
>> > >wrote:
>> >
>> > > Just had another idea.
>> > >
>> > > @Andy: Is the pure JMX interface gone or just not active? I think it
>> > > would be a interesting idea to be able to turn the real JMX interface
>> > > on and off. If you can use the JMX interface (for example, behind the
>> > > firewall in an on-premise installation), you turn it on. If you are in
>> > > the cloud and can't use traditional JMX or don't have a use a
>> > > enterprise monitoring system that understands JMX (for example, in
>> > > smaller organizations), you turn it off.
>> > >
>> > > That way we could have the best of both worlds.
>> > >
>> > > Or another idea would be to offer a small component that reads the
>> > > REST API and creates JMX out of it. If companies want JMX instead of
>> > > REST, they could install this component. This solution might have
>> > > performance probs though....
>> > >
>> > > D.
>> > >
>> > > On Fri, Nov 20, 2009 at 5:43 AM, Richard Hirsch <hirsch.dick@gmail.com
>> >
>> > > wrote:
>> > > > Posted message about SolutionManager and REST on the SDN forum:
>> > > > http://forums.sdn.sap.com/thread.jspa?threadID=1536884
>> > > >
>> > > > D.
>> > > >
>> > > > On Fri, Nov 20, 2009 at 5:31 AM, Richard Hirsch <
>> hirsch.dick@gmail.com
>> > >
>> > > 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
>> > > >> (
>> > >
>> >
>> http://blogs.sun.com/jmxnetbeans/entry/restful_access_to_jmx_instrumentation
>> > > ).
>> > > >> 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
>> > > >> (http://code.google.com/p/polarrose-jmx-rest-bridge/) where the
>> > author
>> > > >> mentions using Cacti (Cacti is a complete network graphing solution:
>> > > >> http://www.cacti.net/) 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
>> > > >> <an...@gmail.com> 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="com.sun.management:type=HotSpotDiagnostic"/>
>> > > >>> <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
>> > > >>>
>> > > >>
>> > > >
>> > >
>> >
>>
>
Re: Requesting feedback on JMX REST API...
Posted by Markus Kohler <ma...@gmail.com>.
Hi Andy,
Dynatrace rocks, and Introscope is kind of the "old defacto standard. They
both can get the more detailed stats you mentioned below, but can also get
simple KPI's such as GC information. SNMP might also be an option to expose
simple KPI's.
All we need is a list of methods that we would want to measure.
Those tools are then able to measure cpu time, elapsed time, nr. of calls
etc.
I
f we are really serious about this I think we should go for Dynatrace first.
I haven't checked whether they have an evaluation license. If not maybe we
can arrange some agreement with them. I happen to know some key people
there, because I once did an evaluation.
Regards,
Markus
On Fri, Nov 20, 2009 at 9:33 PM, Andy the destroyer <
andythedestroyer@gmail.com> wrote:
> I am not familiar with Inroscope or Dynatrace. I will check them out. As
> far
> as instrumentation points, I think we need to find the use cases and they
> will dicate the technology or tools used. Right now we are just collecting
> Stats and we can change logging levels. With some changes to how esme and
> lift is configured we could do things like injecting new db servers to a
> connection pool, new request analyzers etc. However that sort of
> instrumentation is in my opinion better accomplished through OSGi.
>
> In stats collection I looked at some profiling tools that can collect
> method
> call counts, durations, exceptions thrown etc. I didn't use any of these
> because they slow down the JVM. From the names it sounds like Dynatrace
> provides this sort of data. Ill look into it.
>
> -Andy
>
> On Fri, Nov 20, 2009 at 12:01 AM, Markus Kohler <markus.kohler@gmail.com
> >wrote:
>
> > Hi all,
> > Most enterprise monitoring systems understand JMX . IIRC the issue was
> > always that the remote JMX interface was vendor specific. Not sure
> whether
> > that's still the case.
> > JMX is rather inefficent I think. Most enterprises use products such as
> > Wiley Introscope (defacto SAP standard) or Dynatrace.
> >
> > We should probably look what interfaces they offer. Usually the main
> issue
> > is to find the right instrumentation points in the code.
> >
> >
> > Regards,
> > Markus
> >
> > On Fri, Nov 20, 2009 at 5:51 AM, Richard Hirsch <hirsch.dick@gmail.com
> > >wrote:
> >
> > > Just had another idea.
> > >
> > > @Andy: Is the pure JMX interface gone or just not active? I think it
> > > would be a interesting idea to be able to turn the real JMX interface
> > > on and off. If you can use the JMX interface (for example, behind the
> > > firewall in an on-premise installation), you turn it on. If you are in
> > > the cloud and can't use traditional JMX or don't have a use a
> > > enterprise monitoring system that understands JMX (for example, in
> > > smaller organizations), you turn it off.
> > >
> > > That way we could have the best of both worlds.
> > >
> > > Or another idea would be to offer a small component that reads the
> > > REST API and creates JMX out of it. If companies want JMX instead of
> > > REST, they could install this component. This solution might have
> > > performance probs though....
> > >
> > > D.
> > >
> > > On Fri, Nov 20, 2009 at 5:43 AM, Richard Hirsch <hirsch.dick@gmail.com
> >
> > > wrote:
> > > > Posted message about SolutionManager and REST on the SDN forum:
> > > > http://forums.sdn.sap.com/thread.jspa?threadID=1536884
> > > >
> > > > D.
> > > >
> > > > On Fri, Nov 20, 2009 at 5:31 AM, Richard Hirsch <
> hirsch.dick@gmail.com
> > >
> > > 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
> > > >> (
> > >
> >
> http://blogs.sun.com/jmxnetbeans/entry/restful_access_to_jmx_instrumentation
> > > ).
> > > >> 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
> > > >> (http://code.google.com/p/polarrose-jmx-rest-bridge/) where the
> > author
> > > >> mentions using Cacti (Cacti is a complete network graphing solution:
> > > >> http://www.cacti.net/) 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
> > > >> <an...@gmail.com> 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="com.sun.management:type=HotSpotDiagnostic"/>
> > > >>> <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
> > > >>>
> > > >>
> > > >
> > >
> >
>
Re: Requesting feedback on JMX REST API...
Posted by Andy the destroyer <an...@gmail.com>.
I am not familiar with Inroscope or Dynatrace. I will check them out. As far
as instrumentation points, I think we need to find the use cases and they
will dicate the technology or tools used. Right now we are just collecting
Stats and we can change logging levels. With some changes to how esme and
lift is configured we could do things like injecting new db servers to a
connection pool, new request analyzers etc. However that sort of
instrumentation is in my opinion better accomplished through OSGi.
In stats collection I looked at some profiling tools that can collect method
call counts, durations, exceptions thrown etc. I didn't use any of these
because they slow down the JVM. From the names it sounds like Dynatrace
provides this sort of data. Ill look into it.
-Andy
On Fri, Nov 20, 2009 at 12:01 AM, Markus Kohler <ma...@gmail.com>wrote:
> Hi all,
> Most enterprise monitoring systems understand JMX . IIRC the issue was
> always that the remote JMX interface was vendor specific. Not sure whether
> that's still the case.
> JMX is rather inefficent I think. Most enterprises use products such as
> Wiley Introscope (defacto SAP standard) or Dynatrace.
>
> We should probably look what interfaces they offer. Usually the main issue
> is to find the right instrumentation points in the code.
>
>
> Regards,
> Markus
>
> On Fri, Nov 20, 2009 at 5:51 AM, Richard Hirsch <hirsch.dick@gmail.com
> >wrote:
>
> > Just had another idea.
> >
> > @Andy: Is the pure JMX interface gone or just not active? I think it
> > would be a interesting idea to be able to turn the real JMX interface
> > on and off. If you can use the JMX interface (for example, behind the
> > firewall in an on-premise installation), you turn it on. If you are in
> > the cloud and can't use traditional JMX or don't have a use a
> > enterprise monitoring system that understands JMX (for example, in
> > smaller organizations), you turn it off.
> >
> > That way we could have the best of both worlds.
> >
> > Or another idea would be to offer a small component that reads the
> > REST API and creates JMX out of it. If companies want JMX instead of
> > REST, they could install this component. This solution might have
> > performance probs though....
> >
> > D.
> >
> > On Fri, Nov 20, 2009 at 5:43 AM, Richard Hirsch <hi...@gmail.com>
> > wrote:
> > > Posted message about SolutionManager and REST on the SDN forum:
> > > http://forums.sdn.sap.com/thread.jspa?threadID=1536884
> > >
> > > D.
> > >
> > > On Fri, Nov 20, 2009 at 5:31 AM, Richard Hirsch <hirsch.dick@gmail.com
> >
> > 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
> > >> (
> >
> http://blogs.sun.com/jmxnetbeans/entry/restful_access_to_jmx_instrumentation
> > ).
> > >> 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
> > >> (http://code.google.com/p/polarrose-jmx-rest-bridge/) where the
> author
> > >> mentions using Cacti (Cacti is a complete network graphing solution:
> > >> http://www.cacti.net/) 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
> > >> <an...@gmail.com> 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="com.sun.management:type=HotSpotDiagnostic"/>
> > >>> <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
> > >>>
> > >>
> > >
> >
>
Re: Requesting feedback on JMX REST API...
Posted by Markus Kohler <ma...@gmail.com>.
Hi all,
Most enterprise monitoring systems understand JMX . IIRC the issue was
always that the remote JMX interface was vendor specific. Not sure whether
that's still the case.
JMX is rather inefficent I think. Most enterprises use products such as
Wiley Introscope (defacto SAP standard) or Dynatrace.
We should probably look what interfaces they offer. Usually the main issue
is to find the right instrumentation points in the code.
Regards,
Markus
On Fri, Nov 20, 2009 at 5:51 AM, Richard Hirsch <hi...@gmail.com>wrote:
> Just had another idea.
>
> @Andy: Is the pure JMX interface gone or just not active? I think it
> would be a interesting idea to be able to turn the real JMX interface
> on and off. If you can use the JMX interface (for example, behind the
> firewall in an on-premise installation), you turn it on. If you are in
> the cloud and can't use traditional JMX or don't have a use a
> enterprise monitoring system that understands JMX (for example, in
> smaller organizations), you turn it off.
>
> That way we could have the best of both worlds.
>
> Or another idea would be to offer a small component that reads the
> REST API and creates JMX out of it. If companies want JMX instead of
> REST, they could install this component. This solution might have
> performance probs though....
>
> D.
>
> On Fri, Nov 20, 2009 at 5:43 AM, Richard Hirsch <hi...@gmail.com>
> wrote:
> > Posted message about SolutionManager and REST on the SDN forum:
> > http://forums.sdn.sap.com/thread.jspa?threadID=1536884
> >
> > D.
> >
> > On Fri, Nov 20, 2009 at 5:31 AM, Richard Hirsch <hi...@gmail.com>
> 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
> >> (
> http://blogs.sun.com/jmxnetbeans/entry/restful_access_to_jmx_instrumentation
> ).
> >> 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
> >> (http://code.google.com/p/polarrose-jmx-rest-bridge/) where the author
> >> mentions using Cacti (Cacti is a complete network graphing solution:
> >> http://www.cacti.net/) 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
> >> <an...@gmail.com> 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="com.sun.management:type=HotSpotDiagnostic"/>
> >>> <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
> >>>
> >>
> >
>
Re: Requesting feedback on JMX REST API...
Posted by Richard Hirsch <hi...@gmail.com>.
Just had another idea.
@Andy: Is the pure JMX interface gone or just not active? I think it
would be a interesting idea to be able to turn the real JMX interface
on and off. If you can use the JMX interface (for example, behind the
firewall in an on-premise installation), you turn it on. If you are in
the cloud and can't use traditional JMX or don't have a use a
enterprise monitoring system that understands JMX (for example, in
smaller organizations), you turn it off.
That way we could have the best of both worlds.
Or another idea would be to offer a small component that reads the
REST API and creates JMX out of it. If companies want JMX instead of
REST, they could install this component. This solution might have
performance probs though....
D.
On Fri, Nov 20, 2009 at 5:43 AM, Richard Hirsch <hi...@gmail.com> wrote:
> Posted message about SolutionManager and REST on the SDN forum:
> http://forums.sdn.sap.com/thread.jspa?threadID=1536884
>
> D.
>
> On Fri, Nov 20, 2009 at 5:31 AM, Richard Hirsch <hi...@gmail.com> 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
>> (http://blogs.sun.com/jmxnetbeans/entry/restful_access_to_jmx_instrumentation).
>> 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
>> (http://code.google.com/p/polarrose-jmx-rest-bridge/) where the author
>> mentions using Cacti (Cacti is a complete network graphing solution:
>> http://www.cacti.net/) 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
>> <an...@gmail.com> 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="com.sun.management:type=HotSpotDiagnostic"/>
>>> <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
>>>
>>
>
Re: Requesting feedback on JMX REST API...
Posted by Richard Hirsch <hi...@gmail.com>.
Posted message about SolutionManager and REST on the SDN forum:
http://forums.sdn.sap.com/thread.jspa?threadID=1536884
D.
On Fri, Nov 20, 2009 at 5:31 AM, Richard Hirsch <hi...@gmail.com> 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
> (http://blogs.sun.com/jmxnetbeans/entry/restful_access_to_jmx_instrumentation).
> 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
> (http://code.google.com/p/polarrose-jmx-rest-bridge/) where the author
> mentions using Cacti (Cacti is a complete network graphing solution:
> http://www.cacti.net/) 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
> <an...@gmail.com> 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="com.sun.management:type=HotSpotDiagnostic"/>
>> <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
>>
>
Re: Requesting feedback on JMX REST API...
Posted by Andy the destroyer <an...@gmail.com>.
Thanks for the feedback! Responses below.
Andy
On Thu, Nov 19, 2009 at 8:31 PM, Richard Hirsch <hi...@gmail.com>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?
>
>
I haven't played with lift authorization yet. I am not sure how it works. I
know to adhere to being RESTful we should use WWW-Authenticate. I don't know
if lift supports this I will look into it. I so far left security as an
after thought while I nail down the api.
> >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.
>
Cool.
> 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
> (
> http://blogs.sun.com/jmxnetbeans/entry/restful_access_to_jmx_instrumentation
> ).
> 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
> (http://code.google.com/p/polarrose-jmx-rest-bridge/) where the author
> mentions using Cacti (Cacti is a complete network graphing solution:
> http://www.cacti.net/) to graph the material. Maybe we could try and
> use Cacti as well to graph our data.
>
Yes, I also saw that project. We should be able to try Cacti. I can see if I
still remember all the horrible PHP coding I did for years. ( Cacti is in
PHP )
> 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.
>
It could be used to integrate a third party monitoring system with ESME in a
cloud env.
> 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.
>
I should have some time this weekend to work in the suggestions from this
email thread and I will send a patch when I finish.
Thanks again for the input.
-A
>
> Thanks.
>
> D.
>
> On Fri, Nov 20, 2009 at 3:55 AM, Andy the destroyer
> <an...@gmail.com> 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="com.sun.management:type=HotSpotDiagnostic"/>
> > <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
> >
>
Re: Requesting feedback on JMX REST API...
Posted by Richard Hirsch <hi...@gmail.com>.
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
(http://blogs.sun.com/jmxnetbeans/entry/restful_access_to_jmx_instrumentation).
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
(http://code.google.com/p/polarrose-jmx-rest-bridge/) where the author
mentions using Cacti (Cacti is a complete network graphing solution:
http://www.cacti.net/) 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
<an...@gmail.com> 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="com.sun.management:type=HotSpotDiagnostic"/>
> <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
>