JMX and ICE

[Venkat Seeth]

Hello there,

Howdy. I'd like to know if JMX (Java Management Extensions) Technology can be integrated with ICE?

We plan to have one standard way of managing resources using JMX with Spring also offering support for it in the latest version.

It would be sweet if we can somehow integrate/expose ICE services as JMX MBeans. If not possible, what is the parallel for JMX in ICE.

Any ideas/suggestions are greatly appreciated.

Thanks,
Venkatesh

[benoit]

Hello Venkatesh,

There's currently no integration or equivalent of JMX in Ice. I don't know much about JMX, but since Ice provides a language mapping for Java, I don't see any reasons why you wouldn't be able to integrate JMX with your Ice application.

Benoit.

[Venkat Seeth]

Thanks Benoit for your message.

How do I expose the internal stats of the server? Say, how many threads are busy servicing user requests, how many are idle, etc.

I looked into the ThreadPool in an Ice.ObjectAdapter but its not exposed. I did not find any hooks to expose these stats by merely looking at the slice definitions for ICE.

Any pointers are greatly appreciated.

Thanks,
Venkatesh

[marc]

I'm afraid there is no way to access such internal stats of an Ice server (at least not with user-accessible APIs).

[Venkat Seeth]

Thanks Marc for your quick reply.

I'd like to know whats the best approach in getting the stats for a server with out changing the code for ICE.

Do you guys have any plans in the future to expose these things for monitoring purposes?

Thanks,
Venkatesh

[marc]

The only way to monitor such internal activity would be to using tracing (there are various tracing options available, please see the Ice manual), and to parse the tracing output. This could be done with a custom logger.

We currently have no plans to add APIs that allow to monitor the internal activity of Ice. For what exactly do you need this?

[Venkat Seeth]

Thanks again Mark for your reply.

We are looking to provide a single management interface and provide a way for the network management team to manage or look at different statistics of the ICE runtime. Say a service is overloaded, the number of threads could potentially be increased.

I hope I'm clear in communicating the needs of the system.

Thanks,
Venkatesh

[marc]

Ice automatically increases the number of threads. You can define the initial number of threads, as well as the maximum number of threads for every thread pool. Ice will automatically start new threads up to the maximum, and destroy these threads again when they have been idle for some time. Please see the thread pool property descriptions in the Ice manual for details.

Also note that Ice handles all this internally. There is no way to manually add or remove threads in an Ice thread pool without restarting the application.

[Venkat Seeth]

Thanks for the reply.

Good to know that I'll need to run load tests to determine the optimum number pf max threads.

Is it the same case with configuration properties?

Also, the method of tracing you recommend is for offline monitoring since I'll need to mine logs. What if want to provide a way to monitor the current usage of the server in terms of number of requests being processed, etc.

Thanks,
Venkatesh

[marc]

I'm not sure I understand the first part of your question. What is the same case for which configuration properties?

As for the second question, there is no way to monitor how many threads are currently being used, except if you redirect the logging output (by installing a custom logger) to your own application, and analyze the output in real-time. (Which admittedly is not a very elegant solution.)

[Venkat Seeth]

Lets say, I want to dynamically change certain properties at runtime in the server. For example, Ice.Trace.Network, or Ice.Trace.Protocol, can I change these at runtime without bouncing the server?

Also, what are the parts of the server that could be administered/managed by a support personnel at runtime.

Thanks,
Venkatesh

[marc]

You cannot change the tracing configuration at runtime. You could only write a custom logger that intercepts tracing and filters what you don't need.

There are no parts of the Ice core that require runtime maintenance by support personnel.

Some services require maintenance. For example, for Freeze you must have a script that removes old log files.