Print

[pbecker]

Why does JPPF not use the JMX technology for administration and monitoring? Benefits would be that administration of JPPF could be integrated into other management consoles, and the JPPF Admin console could make use of the built-in MBeans of the JVM.
There may be disadvantages that I don't see at the moment. So I think it's worth to discuss.

Peter

[lolo]

The only disadvantages I can see are the potential overhead on the server, in terms of ease of deployment and performance. I just want top make sure it doesn't impose a strain on the server if it doesn't have to.
Otherwise, I think it's a great idea, so why not go with it? One big advantage I can see is that it will make it easy to connect the admin console to multiple JPPF drivers.
It should also allow us to easily build a Web-based console.

What would be your plans on this feature?

-Laurent

[pbecker]

I have no plans with this feature. I just wondered why JMX was not used. But I add it on the bottom of my todo list.

Peter

[iammahendra]

Some more thoughts -

One can create MBeans register them and then create fields to monitor and change at runtime. The jconsole comes with other more useful out of box features like -
a) Memory Analysis
b) Threads

Hence efault jconsole which comes with Java5 has overhead of  providing memory and thread analysis(though very useful for debugging !!).

So if we can create MBeans through which we can configure and change parameter from jconsole that can be one way to go with an overhead with we may or may not want.

IMHO, i can not see it as full blown web console for an application.
The better way to go about, IMHO is -

a) Have built in JMX server
b) Have MBeans created for the management of parameter and register it with Java5 built in JMX server.
c) Build a web-console (not the jconsole) of our own.

I see we have already a UI built with substance so we should see if we can change and modify it to have it display the JMX Server and MBeans registered and then provide monitoring and management features through that for any running instances.

What do you guys think about this ?

Regards
Mahendra

[lolo]

Hi Mahendra,

That's plenty of good ideas.
My vision of it is that, since we already have an admin and monitoring tool, to switch it to a JMX-based communication model. There's already plenty of functionality in our tool, and the UI is already done, and looks better than the JConsole. What JMX is going to bring here, is an actual managment and monitoring protocol, which will make it very much easier to add capabilities to our existing admin tool.
I think we should start with this. Then, it should be easy enough to plug in a new Web UI to handle the same server interfaces, by just switching form a socket or RMI based JMX connector to an HTTP one.

What do you think? Would you like to work on this? That'd be great.

-Laurent

[iammahendra]

Yes ofcourse. I can take this up.

I will have a look at our current UI and relevant code base.

We will then have a talk about what we would like to be monitored and managed and freeze on this.

I have one more quick Q (as i havent seen the entire code base yet)-

Do we require to configuration file changes within JPPF to be loaded at run time ? i.e. if JPPF is running, can we currently change the configuration and JPPF then uses the changed value henceforth.

If yes, is it currently handled , if not then i can suggest some ways to go about it.

- Mahendra

[lolo]

Do we require to configuration file changes within JPPF to be loaded at run time ? i.e. if JPPF is running, can we currently change the configuration and JPPF then uses the changed value henceforth.

- nodes don't handle dynamic reconfiguration, except through disconnect then reconnect to the server
- server: most of it can be changed dynamically through the admin console. However, setting are not persisted on the server side, they're persisted only on the admin console host.
- clients don't handle it

One word of caution: I want to make sure that any solution scales to a very large number of nodes, please think about tens or hundreds of thousands of nodes.
There's definitely plenty of room for improvement here, and I'm glad that you have ways to do this. Please feel free to share with us, and implement your ideas as well.