Return-Path: Delivered-To: apmail-incubator-esme-dev-archive@minotaur.apache.org Received: (qmail 35058 invoked from network); 20 Nov 2009 08:01:34 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 20 Nov 2009 08:01:34 -0000 Received: (qmail 19437 invoked by uid 500); 20 Nov 2009 08:01:34 -0000 Delivered-To: apmail-incubator-esme-dev-archive@incubator.apache.org Received: (qmail 19380 invoked by uid 500); 20 Nov 2009 08:01:33 -0000 Mailing-List: contact esme-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: esme-dev@incubator.apache.org Delivered-To: mailing list esme-dev@incubator.apache.org Received: (qmail 19370 invoked by uid 99); 20 Nov 2009 08:01:33 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Nov 2009 08:01:33 +0000 X-ASF-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of markus.kohler@gmail.com designates 209.85.217.225 as permitted sender) Received: from [209.85.217.225] (HELO mail-gx0-f225.google.com) (209.85.217.225) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Nov 2009 08:01:30 +0000 Received: by gxk25 with SMTP id 25so2947033gxk.0 for ; Fri, 20 Nov 2009 00:01:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=FoNHyi/Ooz7DFiab30yUHLp2yO6tj+vheH5ixOPdMUo=; b=qdZ40h/5Gap9C/zD894a77SFv66c/ar/wmYqJFB3ahYTHG9gkIEjQBiKiVLKYp+/PD l4x+VOiFZnNo2sU33wNUoqzStgX97YEPyaaT1TPVzH5v28KHG9pS2YfejoiMB2BwCWRB rYpiV4bY9p4V8OIfO9WNAw/6H6o31CCTUFkUw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=LIDkPrSFr0cK7NfHBVwdVPO3L6BQyLh57GRZ7AL3U+6EO8V1fS9KvjzN25HYqDs/Ao VCJ1La6u7OCDVqIUG5U8W2HRw7Uh/JXdRT405XEXdkwly2zFzDq1WGzU03tjrRt+b03G 0PG9g8R16t9URX1P1jG1bHmvsWioxR3RBNRmQ= MIME-Version: 1.0 Received: by 10.90.24.18 with SMTP id 18mr1686080agx.97.1258704069061; Fri, 20 Nov 2009 00:01:09 -0800 (PST) In-Reply-To: References: <8d32b3490911191855y25a19f9cybe7005839375c0be@mail.gmail.com> Date: Fri, 20 Nov 2009 09:01:09 +0100 Message-ID: <771905290911200001v48c95d7cw9ca0b9da291e8c9b@mail.gmail.com> Subject: Re: Requesting feedback on JMX REST API... From: Markus Kohler To: esme-dev@incubator.apache.org Content-Type: multipart/alternative; boundary=001636164a29e9eb370478c8e090 --001636164a29e9eb370478c8e090 Content-Type: text/plain; charset=ISO-8859-1 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 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 > 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 > 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 > >> 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] > >>> > >>> pone > >>> 123 > >>> > >>> > >>> POST /jmx/mbean/[mbean name/set - sets a single attribute > >>> > >>> > >>> POST /jmx/mbean/[mbean name]/set - sets multiple attributes > >>> > >>> > >>> > >>> > >>> > >>> == SAMPLES == > >>> > >>> GET /jmx/mbeans > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> GET /jmx/mbean/org.apache.esme.stats:type=Stats/attributes > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> GET /jmx/mbean/org.apache.esme.stats:type=Stats/info > >>> > >>> > >>> > >>> description="counter" > >>> isReadable="true" name="counter_userCount" isWritable="false"/> > >>> description="counter" > >>> isReadable="true" name="counter_liftSessions" isWritable="false"/> > >>> description="gauge" > >>> isReadable="true" name="gauge_users" isWritable="false"/> > >>> description="gauge" > >>> isReadable="true" name="gauge_listener" isWritable="false"/> > >>> > >>> > >>> >>> returnType="java.lang.String" name="clear"> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> ================= > >>> > >>> 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 > >>> > >> > > > --001636164a29e9eb370478c8e090--