tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "" <>
Subject Re: Accessing context information remotely - Context.getAvailable() etc.
Date Sat, 08 Jan 2011 11:30:38 GMT
Yes I guess you are right that launching the jmx every minute could be expensive resourcewise...
i am wondering whether it will be less expensive if I just start a thread and same it up every
minute... this way the jmx engine will only be started once... 

I can't really have the monitoring tool inside my webapp or in the tomcat instance.. the reason
for this is that the tool I am writing checks the availability of tomcat itself. This means
that if tomcat itself dies the monitoring tool will also die... 

-- Sent from my HTC Desire --

----- Reply message -----
From: "Christopher Schultz" <>
Date: Fri, Jan 7, 2011 15:05
Subject: Accessing context information remotely - Context.getAvailable() etc.
To: "Tomcat Users List" <>

Hash: SHA1


On 1/7/2011 6:53 AM, Ziggy wrote:
> Will a "full JMX" be started on the Tomcat JVM or on the JVM in which i am
> running the process to connect to the Tomcat instance?

Your client process, obviously: JMX is already started in the Tomcat JVM
in order to serve JMX requests.

> presumably if it is
> the latter then it will shutdown once the client tool completes? The tool
> should only take a few seconds to run on each iteration.

Yes. Rainer is only pointing-out that the JVM + the JMX subsystem is a
pretty heavy thing to be launching, say, every minute from a cron job.
On the other hand, you could use a shell script + wget and get the same
effect if you had access to the manager app because of the jmxproxy feature.

Of course, you could also write your own JMX proxy service and connect
to /that/. I wonder how easy it would be to hack the jmxproxy out of the
manager webapp and either insert it into another (your) webapp or just
deploy it on its own.

- -chris
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message