Why can't you save all jconsole info?

[Robert M. Gary]

Looking at jconsole it would be great to ask customers to run jconsole
and save the output so I can review it all in the lab. However, it
doesn't appear that jconsole has a way to save its info. Are there
other tools that would collect the same info as jconsole and save them
in a way I can see them in the lab?
Our technical support group always has to gather a large list of info
from the customer about the JVM, it would sure be nice if I could tell
them "just have the customer run jconsole and send us the output
file".

-Robert

 

[Andrew Thompson]

Looking at jconsole it would be great to ask customers to run jconsole
and save the output so I can review it all in the lab.

Great for you, or the customer?* It sounds a little too
technical for most customers as proposed, but I have
been looking to incorporate a similar end-result in a
generic web start based frame I am developing.

Are the applications trusted?

My approach is to redirect System.out/System.err into
an Object I can control (the size of) and later write out.
OTOH that is only intended to capture the output of other
classes (that are put into the frame) that use System.out/err,
and that possibility is unavavailable to sandboxed apps.

A better strategy though, is to implement logging throughout
the app. Then you can decide what happens to the information
in the log (and indeed, at what level the log is recording).

Sandboxed apps. can only access anonymous loggers (at
least to add a custom handler), though all-permissions apps.
can get named loggers.

Are they (the applications) being launched using web start?

If so - it offers sandoxed ways to export the data to local disk,
though it might be easier to submit it directly back to a server-side
'bug report' script.

Our technical support group always has to gather a large list of info
from the customer about the JVM, it would sure be nice if I could tell
them "just have the customer run jconsole and send us the output
file".

* It'd be even nicer for the user could 'click a button' and after
reviewing the data 'authorize' it to be returned direct to
your server, no?

Assuming the server-side support cannot be provided,
you might look to using the web start based
BasicDocument.showDocument(URL) or the J2SE
based Desktop.mail(URI) with an email address, to
at least prompt the user where to send the report.

--
Andrew Thompson
http://www.physci.org/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200712/1

 

[Manish Pandit]

Great for you, or the customer?* It sounds a little too
technical for most customers as proposed, but I have
been looking to incorporate a similar end-result in a
generic web start based frame I am developing.

Are the applications trusted?

My approach is to redirect System.out/System.err into
an Object I can control (the size of) and later write out.
OTOH that is only intended to capture the output of other
classes (that are put into the frame) that use System.out/err,
and that possibility is unavavailable to sandboxed apps.

A better strategy though, is to implement logging throughout
the app. Then you can decide what happens to the information
in the log (and indeed, at what level the log is recording).

Sandboxed apps. can only access anonymous loggers (at
least to add a custom handler), though all-permissions apps.
can get named loggers.

Are they (the applications) being launched using web start?

If so - it offers sandoxed ways to export the data to local disk,
though it might be easier to submit it directly back to a server-side
'bug report' script.


* It'd be even nicer for the user could 'click a button' and after
reviewing the data 'authorize' it to be returned direct to
your server, no?

Assuming the server-side support cannot be provided,
you might look to using the web start based
BasicDocument.showDocument(URL) or the J2SE
based Desktop.mail(URI) with an email address, to
at least prompt the user where to send the report.

Andrew - I believe the OP is talking about persisting JMX (Java
Management Extensions) information.

It is not related to logging, but VM management information. This
information includes threads, memory, heap/non-heap allocation, loaded
classes, operating system and other MBeans that can provide more
information about the internal components (like JMS, JDBC, etc.).

Often vendors' support services need this information to diagnose/
identify bugs or issues in their software, which might be what the OP
is looking for.

-cheers,
Manish

 

[Andrew Thompson]

...
Andrew - I believe the OP is talking about persisting JMX (Java
Management Extensions) information.

Ooooh. *That* jconsole. Now I look at it - I think that makes
perfect sense. I was (of course) talking about the generic
'java console'.

It is not related to logging, but VM management information. ..

OK. I see no options in either the jconsole GUI, nor the
command line parameters, that suggests the information
can be exported. It looks as though it would have to be
managed from within code using the javax.management.*
API.

But look on the bright side. This way, you can easily
customize and hone the information being monitored.

 

[Manish Pandit]

Ooooh. *That* jconsole. Now I look at it - I think that makes
perfect sense. I was (of course) talking about the generic
'java console'.


OK. I see no options in either the jconsole GUI, nor the
command line parameters, that suggests the information
can be exported. It looks as though it would have to be
managed from within code using the javax.management.*
API.

But look on the bright side. This way, you can easily
customize and hone the information being monitored.

Yep. Too bad there is no save snapshot option with jconsole (and other
JMX clients I've come across).

I did use CA Wily Introscope last year or so, that saves this sort of
information as a CSV that can be analyzed later, but it costs a lot of
$$$.

-cheers,
Manish

 

[Robert M. Gary]

Andrew - I believe the OP is talking about persisting JMX (Java
Management Extensions) information.

Yes. I saw jconsole, thought it had great information and then
throught, how can I get this type of information from customers? Of
course I can ask the customer for remote access into their system but
we usually like to have our technical support department gather the
data and have the lab people review what was provided. Anytime you log
into a customer's system it takes longer to diagnose the problem, vs.
being able to review everything from the support case that was
created. Developers are often working on several things at once for
several different customers and it just makes it easier to juggle.

-robert

 

[Robert M. Gary]

Yep. Too bad there is no save snapshot option withjconsole(and other
JMX clients I've come across).

I did use CA Wily Introscope last year or so, that saves this sort of
information as a CSV that can be analyzed later, but it costs a lot of
$$$.

Does Wily support Java apps too? I couldn't quiet figure that out from
their web site but it appears that they may only support web apps.

-Robert

 

[Manish Pandit]

Does Wily support Java apps too? I couldn't quiet figure that out from
their web site but it appears that they may only support web apps.

-Robert

You may be right..most if not all of their stuff is around J2EE
application servers. Also, unlike JMX, Wily needs byte code
instrumentation and installation of agents in the VM running the code
to be able to trace it.

I used it with BEA Aqualogic stack in a cluster, and was very
impressed. There is no performance drag, and the information can be
fine grained and traced across layers (requests all the way from a
portal coming down to the JDBC level via EJBs).

-cheers,
Manish