My use case is (or was) this. We had a system running which required management. Certain information which was useful to us was supplied by the infrastructure (River). This included things like hostname, which other services it was talking to, and administrative features (e.g. destroy).
We eventually got hostname and similar data off each service by adding applicable methods to the service interface. We had to do something special things for lookup services/transaction managers/spaces because obviously we couldn't have modified those service interfaces. We also wanted JVM information (threads, memory usage etc) which we ended up doing via JMX. It was my original intention to provide a VmAdmin which could be plugged into the River services and used by other services which could be used to get this information, thus providing a common place/method where such data can be retrieved. Then we started talking about JMX and I got confused because I don't know much about JMX. I think that it useful to have something in the infrastructue (i.e. River) to give some rudimentary data about a certain service. That's what I meant by the VmAdmin. Enabling/Providing/Turning on/Using JMX for additional data would then be a different issue which is up to the owner of the JVM/service. So if these two things are different. Back to my original question, does anyone (maybe still) object to the presence of a VmAdmin? Thanks Patricia, you're right this should go out to the users list as well. I'm interested to get the opinion of the Jini old-hands first. :-) Cheers. Tom On Fri, Nov 12, 2010 at 12:54 PM, Dennis Reedy <dennis.re...@gmail.com> wrote: > Hi Tom, > > Not sure I understand. If you can create a JMX connection to the service's > JVM what exactly does River need to do? I'm not sure you need to "supply" > anything, or am I misunderstanding you? > > Dennis > > On Nov 12, 2010, at 736AM, Tom Hobbs wrote: > >> I'm happy to implement using JMX rather than an Admin implementation. >> Thanks for the suggestion (I often forget that JMX exists...) >> >> I'm guessing then that the idea of supplying this kind of data is not >> objectionable to you? >> >> On Fri, Nov 12, 2010 at 12:28 PM, Sim IJskes - QCG <s...@qcg.nl> wrote: >>> On 12-11-10 13:23, Dennis Reedy wrote: >>>> >>>> Would using the the JSR 160 approach where a service adds >>>> net.jini.look.entry.jmx.* attributes to its collection of attributes >>>> it maintains with it's service registration also work? That way a JMX >>>> connection can be established to the service's JVM, allowing jconsole >>>> or visualvm to display (even profile) JVM details? >>> >>> JMX would be nice. >>> >>> Gr. Sim >>> >>> -- >>> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl >>> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397 >>> > >
