On 3/8/2010 9:20 AM, [email protected] wrote:
Thanks for all the hard work putting this together.
Just my opinion, but it looks to me that visualvm is slightly ahead of
the others in terms of functionality, etc. The only quirky thing
about VisualVm are restrictions on when you can take a snapshot
(remote vs local doesn't feel consistent). Otherwise, it provides
good capability to baseline and snapshot heap and thread.
With all of that said, the times when I need something like this in
production, it doesn't work. Too many times, the process can't be
connected to (even locally with jstack or jmap).
There are bugs in the Sun Javadatabase about this -- which seem to boil
down to an underlying use of temp files and an (invalid) assumption that
they'll not disappear during the JVM's lifespan as I recall. I agree
that this is rather unfortunate.
One can, of course, configure for remote JMX or produce alternative
means of obtaining a JMX connection for the JMX part of things, but that
does not help for things that really need the local attach API to work,
e.g. profiling.
Even the times I can
connect prove to be less than valuable because I am more worried about
getting production running again than I am debugging. What I need more
than anything else is to be able to move the running instance off to a
non production vm and spin up a new production one for the traffic.
Then, maybe, I could take the time to diagnose.
Hmmm.... Sounds like you need an environment where traffic can be routed
around that JVM and another one put into production to replace it if
necessary. That sounds like a deployment/architecture/planning issue,
not a VisualVM issue.
--
Jess Holle
--
You received this message because you are subscribed to the Google Groups "The Java
Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
