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 <[email protected]> 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 <[email protected]> > 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 <[email protected] > >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 <[email protected]> > >> 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 < > [email protected]> > >> 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 > >> >> <[email protected]> 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 > >> >>> > >> >> > >> > > >> > > >
