You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Tom Hobbs <tv...@googlemail.com> on 2010/11/12 12:00:10 UTC
Service Specifics
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
Re: Service Specifics
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 12-11-10 12:00, Tom Hobbs wrote:
> 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.
To recap what i understand until now:
You want to include code, that presents itself as a service, and
provides telemetry about a vm.
If thats the case no objections. I like the idea of more telemetry. JMX
is implemented with remoting. So if we divide the problem, whe have the
telemetry hooks into the jini kernel, and the transport.
JMX can have all kind of transports, so if you model it a bit like
MBeans we can later add a jini based JMX agent to it. Currently i have
RMI based JMX transports in use, and i don't like the firewall issues
with RMI. I would be very nice, if there is a service for every VM where
you can get your JMX data from.
And if you export all the MBean look-a-likes through a central method,
you can cook whatever security model you like there.
Where do you expect you want to amend the jini apis?
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Service Specifics
Posted by Sim IJskes - QCG <si...@qcg.nl>.
I don't have made up my mind on what kind of data to supply over jmx,
but information like the number of active ObjectEndpoints or Endpoints
or any other data that might help to diagnose performance or other
transient problems during production would have my blessing.
I'm not specifically talking about jsr-160.
JMX has helped me in the past on several occasions, and when i talk to
system administrators who even are not allowed access to JMX data
supplied by just the VM alone, i feel sorry for them.
Its about turning the black box into a lighter color.
But confessing my love for JMX is probably not answering the original
question you asked.
Gr. Sim
On 12-11-10 13:36, 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<si...@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
>>
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Service Specifics
Posted by Patricia Shanahan <pa...@acm.org>.
On 11/12/2010 7:04 AM, Tom Hobbs wrote:
...
> So if these two things are different. Back to my original question,
> does anyone (maybe still) object to the presence of a VmAdmin?
...
It may have security implications, as an extra channel, so I suggest
providing a very strong way of disabling it. Subject to that, it seems
harmless in most situations, and extremely valuable to any performance
analyst trying to debug a bottleneck.
Patricia
Re: Service Specifics
Posted by Tom Hobbs <tv...@googlemail.com>.
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 <de...@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 <si...@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
>>>
>
>
Re: Service Specifics
Posted by Dennis Reedy <de...@gmail.com>.
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 <si...@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
>>
Re: Service Specifics
Posted by Tom Hobbs <tv...@googlemail.com>.
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 <si...@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
>
Re: Service Specifics
Posted by Sim IJskes - QCG <si...@qcg.nl>.
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
Re: Service Specifics
Posted by Dennis Reedy <de...@gmail.com>.
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
Re: Service Specifics
Posted by Patricia Shanahan <pa...@acm.org>.
Tom Hobbs wrote:
...
> - Are there any particular kinds of data people would like to see in a VmAdmin?
...
Maybe this question should also be asked on the user mailing list?
Several of my previous jobs involved system performance analysis. I love
data, so I'm in favor of this idea.
Patricia