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?
Regards Dennis On Nov 12, 2010, at 600AM, Tom Hobbs wrote: > In the past I've worked on an application that was made up of a series > of (Jini 2.1) services on a controlled/secure subnet. One of my areas > of responsibility for this project was a piece of management software > which monitored the services, worked out their relative "healths", > worked out which was talking to whom, starting/stopping and other > things of that nature. > > One of the things that was missing, which I believe should be in the > service provision layer (i.e. in Jini/River code) is a way to ask a > proxy for specific information about it's runtime. For example, free > memory, number of threads, hostname, etc. I heard a rumour that way > back when, something similar was discussed by the Jini team and thrown > out as being not needed or the argument being that such data should > not be made available at this level or something like that. I forget > the specifics. > > So I was wondering if that is still the consideration of the > community. I'm proposing writing something along the lines of a > "VmAdmin" to provide some of these features. In the example I gave > above, we implemented these things by adding additional methods to the > service interface, but it would have been a better solution to have > them in the infrastructure. > > My questions are: > - Are there still the same/any objections to having this Administrable > made available > - Even in the face of objections, if I supply the code, is there any > real reason why it can't find it was into the distribution > - Are there any particular kinds of data people would like to see in a > VmAdmin? > > Cheers, > > Tom
