Hi James. Strange that no one else has responded to you on this list as yet; I'm all for reorganising the JMX names to suit Hawt.io, but not by default since it will affect our JON/RHQ plugins. Care to create a JIRA in Infinispan to allow a JVM system parameter to swap the JMX name components around as you propose? Regarding a Hawt.io plugin for Infinispan, I'd love to see this. What additional operations are you suggesting? Cheers Manik On 27 Feb 2013, at 15:54, James Strachan <james.strachan(a)gmail.com&gt; wrote: > Howdy folks! > > I'm working on a HTML5 web console called hawtio (http://hawt.io) > which is a pluggable & modular console for various Java libraries, > frameworks and containers. e.g. today it has plugins for Apache Camel, > ActiveMQ, Fuse Fabric as well as JMX, OSGi & Logging - then plugins > for containers like Tomcat, Jetty, JBoss, Karaf/ServiceMix. We've a > cute dashboard & wiki which uses git to store its configuration/files > too. > > Anyway the reason I bring this up is yesterday we had our first > Infinispan issue with hawtio: > https://github.com/hawtio/hawtio/issues/134 > > its now fixed; but it got me thinking if we could have a nice little > hawtio plugin for Infinispan so folks could make dashboards of real > time metrics of caches, browse caches etc. > > > I enabled metrics and managed to get a basic JMX tree going with real > time metrics on attributes/charts on a single Cache using vanilla JMX > in hawtio with Infinispan. I've attached an example of how it looks if > you're interested. > > The thing is, there's no way to easily click on a folder and get all > the MBeans for the Statistics. If that were the case then hawtio would > show a sortable table of all the metrics of all the caches in one > table view; or we could easily chart any of the metrics of all the > caches in one real time chart easily. > > It'd be a fairly minor change; we'd just need to change the ObjectName > used for the Cache mbeans from this naming convention: > > Infinispan:type=Cache,name="drink(local)",manager="DefaultCacheManager",component=Statistics > > to this (just moving the "name" property to the end) > > Infinispan:type=Cache,manager="DefaultCacheManager",component=Statistics,name="drink(local)" > > then in the hawtio JMX tree we could select the "Statistics" folder > and see all of the mbeans in a table and so you could sort the table > by metric, see all the values on a single screen & create real time > charts of any permutation of cache & metric. > > I wondered if folks fancied either adopting this naming convention > (putting the name last and the component kind before it) or adding a > configuration flag so we could enable this kind of JMX naming > convention style? It'd make things much more hawt when using hawtio > and infinispan! :). You'd get nice HTML5 statistics in hawtio > instantly on all caches. > > > I also wondered if folks fancied adding a few more operations to the > Cache mbean so that we could build a little console in hawtio for > Infinispan; to view/update contents of the caches or flush them etc? > > As a background; since JMX is usually the lowest common denominator, > hawtio defaults to using it to detect whats in a JVM. If we discover a > particular kind of MBean we then enable/disable different parts of the > hawtio UI dynamically. e.g. if you're viewing a JVM then you deploy > some Apache Camel, hey presto, the Camel UI in hawtio appears as a > tab. > >> From a technology perspective hawtio is all static HTML5 / JavaScript > on the client; it then communicates with the MBeans via an awesome > library called jolokia (http://jolokia.org/) which exposes JMX over > HTTP/JSON. > > So hawtio could totally use the Infinispan REST API (but it'd be nice > if there was an mbean registered to indicate the REST API is running > and where to find it so hawtio could discover it). However you can > usually rely more on JMX being there (folks don't always deploy > Infinispan inside a web container with a REST API). So I wondered if > folks fancied adding a simple little JMX API to query / update / flush > the cache that we could then use to build a little HTML5 console in > hawtio? > > e.g something valuely like: > > interface CacheMBean { > ... > > String getJson(String key) > > void setJson(String key, String value); > > // lets browse the keys - in a simple paginated way some how.. > Set<String> getCacheKeys( String from, int count); > } > > You could return Objects; jolokia automarshalls things to JSON; though > maybe having a specific JSON reading/writing mbean (using > jolokia/jackson under the covers) might be neater as it'd work with > all JMX tools? > > > So in summary, I'm happy to help hack a little hawtio plugin for > infinispan if anyone's interested. Making the cache ObjectName change > would be a nice quick win & if more operations get added to the MBeans > we can then easily build a better hawtio plugin for Infinispan. > > Thoughts? > > -- > James > ------- > Red Hat > > Email: jstracha(a)redhat.com > Web: http://fusesource.com > Twitter: jstrachan, fusenews > Blog: http://macstrac.blogspot.com/ > > Open Source Integration > <hawtio-infinispan.png>_______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani manik(a)jboss.org twitter.com/maniksurtani Platform Architect, JBoss Data Grid http://red.ht/data-grid _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 03/19/2013 06:55 PM, Dennis Reed wrote: > This is an invalid use of the MBean names. > > The keys in an ObjectName are unordered. It is a bug to depend on a > specific ordering of the keys. Thanks Dennis, I was about to write that.

> On 03/19/2013 10:07 AM, Manik Surtani wrote: >> >> On 27 Feb 2013, at 15:54, James Strachan <james.strachan(a)gmail.com&gt; wrote: >> I also wondered if folks fancied adding a few more operations to the >> Cache mbean so that we could build a little console in hawtio for >> Infinispan; to view/update contents of the caches or flush them etc? This is actually trickier than you think: Infinispan can theoretically use any kind of data for keys/values (including custom Java classes). Furthermore these keys/values may be wrapped by service-specific containers making it very difficult to implement some kind of CRUD interface. You could probably latch on to the Infinispan CLI server component (which incidentally is also exposed as an MBean) and provides solutions for most of the above problems.

Tristan _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 03/20/2013 11:35 AM, Manik Surtani wrote: > As in, the JMX spec does not guarantee the order of ObjectName > components? Indeed. > Does this mean that [1] is solved by an existing MBean? > > [1] https://issues.jboss.org/browse/ISPN-2926 Yes, each CacheManager gets an "Interpreter" MBean which handles the parsing/execution of the CLI commands. https://github.com/infinispan/infinispan/blob/master/cli/cli-server/src/m... Tristan _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 03/19/2013 06:55 PM, Dennis Reed wrote: > This is an invalid use of the MBean names. > > The keys in an ObjectName are unordered. It is a bug to depend on a > specific ordering of the keys. Thanks Dennis, I was about to write that. > On 03/19/2013 10:07 AM, Manik Surtani wrote: >> >> On 27 Feb 2013, at 15:54, James Strachan <james.strachan(a)gmail.com&gt; wrote: >> I also wondered if folks fancied adding a few more operations to the >> Cache mbean so that we could build a little console in hawtio for >> Infinispan; to view/update contents of the caches or flush them etc? This is actually trickier than you think: Infinispan can theoretically use any kind of data for keys/values (including custom Java classes). Furthermore these keys/values may be wrapped by service-specific containers making it very difficult to implement some kind of CRUD interface. You could probably latch on to the Infinispan CLI server component (which incidentally is also exposed as an MBean) and provides solutions for most of the above problems.

On 19 March 2013 17:55, Dennis Reed <dereed(a)redhat.com&gt; wrote: > This is an invalid use of the MBean names. > > The keys in an ObjectName are unordered. It is a bug to depend on a > specific ordering of the keys. If the order really is unimportant then noone will mind if we change it :) Though really tools tend to assume a certain order. Though really most JMX related tools build trees from the MBean property names; so order dictates how the tree is drawn.

If the order really is unimportant then noone will mind if we change it :) Though really tools tend to assume a certain order. Though really most JMX related tools build trees from the MBean property names; so order dictates how the tree is drawn.

So as it turns out I've added a workaround to the MBean naming issue; I've just created a new custom UI for Infinispan inside hawtio. (Feel free to close the JIRA if you like). I've attached a little screenshot of what I've got so far in case anyone's interested. I'm now about to try add in CLI support...

Many thanks! BTW does this exception ring any bells: ERROR | qtp581815510-700 | ISPN019003: Interpreter error java.lang.NullPointerException at org.infinispan.cli.interpreter.Interpreter.execute(Interpreter.java:161) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.infinispan.jmx.ResourceDMBean.invoke(ResourceDMBean.java:287) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:791)

Incidentally do the session IDs timeout after a while? Seems like I saw that once or twice (though could be a hawtio bug :). If so I'm wondering if it might be easier to have a new method executeWithTemporarySessionId(cacheName, sql) or something like that so we don't have to keep track of when a session ID is stale or have to do 2 operations when we don't mind about the session ID (i.e. use one session ID per operation)?.

On the hawtio server I emailed you off-list - can you enter any CLi statements without getting the NPE?

It'd be nice to get a nicer parser exception message than an NPE BTW :). "Incorrect character at 8,1, expected 'x'" or something would help; then we could highlight the dodgy bit of the CLI command in the UI

What state is there between commands? If the commands are basically a "get" or a "put" and they execute immediately on the cache; there's not much state to lose right?

How about if we added a new JMX method which didn't take a session ID, but allowed you to pass in the codec (e.g. in hawtio's case "json")? Then from infinispan server side's perspective it can eagerly timeout sessions?

Hi James, Infinispan 5.3.0.Alpha1 has just been released which should provide much better error information when parsing CLI commands and also supports the "null" session for one-shot execution. Can you please let me know if it satisfies your requirements ? Trisan On 03/27/2013 04:40 PM, Tristan Tarrant wrote: > On 03/27/2013 04:31 PM, James Strachan wrote: >> How about if we added a new JMX method which didn't take a session ID, >> but allowed you to pass in the codec (e.g. in hawtio's case "json")? >> Then from infinispan server side's perspective it can eagerly timeout >> sessions? > The "codec" in question has nothing to do with how data is displayed, > but on how it is stored within the cache. get and put actually allow > specifying it as a switch, so I guess we could assume a "null" session > means a temporary throwaway session. > > Tristan > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 04/10/2013 03:19 PM, James Strachan wrote: > > after much dismay I started noodling all the junit test cases and > discovered the use of '";" as a terminator. And hey presto, adding ";" > on the end I can now actually execute commands :). Yay! (You might > want to make this a bit more clear on the Syntax section of the wiki > page) Actually the antlr grammar defines EOF as a valid terminator and it works when issuing commands from the CLI. I need to check that.

> I tried passing null as the sessionId; but then it doesn't know which > cache I want to execute the commands on; I guess I could try prefix > the command with some dummy command, like "cache foo; " + "get > 'blah';" or something? Is there a command to say 'the next commands > operate on a named cache?". cache namedcache; put a a;

> Also it'd be awesome if there was a CLI command that could return the > keys (maybe using a range) so I could implement a cache browser by > just asking for keys 0..100 and then 100..200 etc; then for each key I > can then do a 'get $value;" command. > Yes there's a plan for that, although providing ranges/windowing is not easy.