Nabble - Sun - Jmx-Forum

Re: Visual VM

2009-08-06T17:26:21Z

thankyou for your informative post

[url=http://creditimmobilierdefrance.org/][color=#FFFFFF][u]simulation taux banque credit immobilier de France[/u][/url][/color][color=#FFFFFF] - Credit immobilier de France, simulation credit immobilier. Résultat mitigé pour le crédit immobilier de France.[/color][url=http://creditimmobilierdefrance.org/][color=#FFFFFF][u]simulation taux banque credit immobilier de France[/u][/url][/color]

Jess Holle wrote:

At JavaOne, there was a fabulous little BOF on an all-in-one open-source
management and monitoring tool, a "Visual VM" project, that was
purported to be slated to become a java.net project soon.

I know some of those involved follow this mailing list. I was wondering
if anything is happening with this project any time soon.

--
Jess Holle

===========================================================================
For information on the Java Management extensions (JMX), please visit
our home page at http://java.sun.com/products/JavaManagement/
The JMX-FORUM archives are accessible at http://archives.java.sun.com
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JMX-FORUM". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Re: Visual VM

2009-08-03T00:31:25Z

Jess Holle wrote:

At JavaOne, there was a fabulous little BOF on an all-in-one open-source
management and monitoring tool, a "Visual VM" project, that was
purported to be slated to become a java.net project soon.

I know some of those involved follow this mailing list. I was wondering
if anything is happening with this project any time soon.

--
Jess Holle

===========================================================================
For information on the Java Management extensions (JMX), please visit
our home page at http://java.sun.com/products/JavaManagement/
The JMX-FORUM archives are accessible at http://archives.java.sun.com
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JMX-FORUM". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Training & jobs

2008-09-30T00:23:39Z

“Join us to make future”
FOR OPT/F-1 STUDENTS
FREE TRAINING
FOOD ACCOMODATION
H1B PROCESSING FOR L1/ L2/ H1/ H4/ EAD/ GC
EXCELLENT OPPRTUNITIES
TRAINING
PLACEMENT
Highly Competitive offers for New H1b Transfers
About Us:
V2 technology inc is serving NJ since 2005, for us our employees are of utmost importance. Our highly skilled and dedicated instructors train you explicitly in market-related technologies for today and tomorrow. We will work with you in developing marketing strategies and finding the assignments of your choice.
We not only help you get a job but we build your long lasting careers!!!
What are we Looking for:
Excellent communication skills.
Valid F1/ OPT/ CPT/ H1/ H4/ L1 or valid work status (EAD, GC).
Bachelors’ degree in CS/ IT or previous IT experience.
Preferably (not mandatory) Master's Degree in Computers/ Electronics or previous IT experience.
Willing to relocate anywhere in USA.
What’s The Deal:
H1-B sponsorship to F1/ OPT/ H4/ L1/ L2/ E3/ EAD
Transfer of H1 & L1 visas.
Green Card sponsorship through PERM
Job focused professional training in
Java/ J2EE
.NET
Documentum
Share point
Oracle
Data Modeling
Relocation assistance- airfare, hotel accommodation, car rental etc
Guarantee lowest bench period.
Employee referral program.
Effective Resume writing help, Marketing and Placement.
Technical mock interviews. Preparation of In Person Interviews
100% Guaranteed placement
Get in Touch:
Contact immediately to know more about the opportunities with us at:609-843-0312
or
write mail at jobs@v2techinc.com
Contact person : John

JMX-FORUM is being discontinued

2007-10-27T04:40:53Z

Dear JMX-FORUM subscribers,

You might have noticed that this list has been rather quiet recently. There
are several reasons for that. One is that most new users find the JMX forum
on SDN first. Another is that the answers to many questions are easily
found on the web, through the many articles and blogs about JMX technology.
And a third is that the LISTSERV infrastructure that drives this mailing
list is no longer being maintained.

Rather than let this list stagger on, we think the time has come to let it
end with dignity. I am proposing to turn this list off a week from today.
The list archives will continue to be available.

Future questions and discussions about JMX should be addressed to one of the
following places:

* For general questions and discussions, the JMX forum on the Sun Developer
Network: <http://forum.java.sun.com/forum.jspa?forumID=537>. You can
receive mail notification of new posts to this forum using the "Watch this
forum" link.

* For feedback about the JMX specifications: jmx-spec-comments@...

* For discussion about the JMX implementation in OpenJDK:
jmx-dev@...

* Daniel Fuchs has a blog entry that summarizes these and many other
resources: <http://blogs.sun.com/jmxetc/entry/where_can_i_get_my>

Thanks to everybody who contributed to this mailing list over the years!

Éamonn McManus -- JMX Spec Lead -- http://weblogs.java.net/blog/emcmanus

===========================================================================
For information on the Java Management extensions (JMX), please visit
our home page at http://java.sun.com/products/JavaManagement/
The JMX-FORUM archives are accessible at http://archives.java.sun.com
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JMX-FORUM". For general help, send email to
listserv@... and include in the body of the message "help".

Re: JMX Agent with firewall

2007-09-20T06:58:10Z

Of course that assumes you can poke a hole in your firewall and specify
a pre-main.

An alternative is to have an reverse proxy JMX connector that does
general JMX on the back end and transports over HTTP(S) on the front
end. I wrote one, but the company owns it -- sorry.

Another alternative would be the JMX web connector, but that really
needs JMX 2's cascading to be as useful in my opinion.

--
Jess Holle

Daniel FUCHS wrote:

> Hi,
>
> Please see here:
>
> http://blogs.sun.com/jmxetc/entry/connecting_through_firewall_using_jmx
>
> Hope this helps,
>
> -- daniel
> JMX, SNMP, Java, etc...
> http://blogs.sun.com/jmxetc
>
> ===========================================================================
> For information on the Java Management extensions (JMX), please visit
> our home page at http://java.sun.com/products/JavaManagement/
> The JMX-FORUM archives are accessible at http://archives.java.sun.com
> To unsubscribe, send email to listserv@... and include in the body
> of the message "signoff JMX-FORUM". For general help, send email to
> listserv@... and include in the body of the message "help".
>
>

===========================================================================
For information on the Java Management extensions (JMX), please visit
our home page at http://java.sun.com/products/JavaManagement/
The JMX-FORUM archives are accessible at http://archives.java.sun.com
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JMX-FORUM". For general help, send email to
listserv@... and include in the body of the message "help".

Re: JMX Agent with firewall

2007-09-20T04:16:37Z

Hi,

Please see here:

http://blogs.sun.com/jmxetc/entry/connecting_through_firewall_using_jmx

Hope this helps,

-- daniel
JMX, SNMP, Java, etc...
http://blogs.sun.com/jmxetc

===========================================================================
For information on the Java Management extensions (JMX), please visit
our home page at http://java.sun.com/products/JavaManagement/
The JMX-FORUM archives are accessible at http://archives.java.sun.com
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JMX-FORUM". For general help, send email to
listserv@... and include in the body of the message "help".

JMX Agent with firewall

2007-09-20T01:38:57Z

Hi,

I have a Java Application that I have JMX enabled using the Java runtime
options -Dcom.sun.management.jmxremote ... I connect to this JMX agent
from a remote Java client. My problem is when there is a firewall
between agent and client I am unable to connect to the agent. As there
are random ports opened for communication I cannot configure my firewall
appropriately.

Is there a way I can specify what ports to be used for communication on
the agent side? Is there a runtime option available for this?

From the client I believe I can provide the port while creating the JMX
Service URL.

Regards,
Jagannath

===========================================================================
For information on the Java Management extensions (JMX), please visit
our home page at http://java.sun.com/products/JavaManagement/
The JMX-FORUM archives are accessible at http://archives.java.sun.com
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JMX-FORUM". For general help, send email to
listserv@... and include in the body of the message "help".

Re: Accurate CPU timing on Windows -- How?

2007-07-19T12:17:09Z

Eamonn McManus wrote:
> Luis-Miguel Alventosa reminded me that though the implementation class is
> not public, the com.sun.management.OperatingSystemMXBean interface that it
> implements is. So you can just cast the result of
> ManagementFactory.getOperatingSystemMXBean() to that interface and access
> its getProcessCpuTime() method, or do the same thing via reflection.
>
Thanks for the pointer!

--
Jess Holle

===========================================================================
For information on the Java Management extensions (JMX), please visit
our home page at http://java.sun.com/products/JavaManagement/
The JMX-FORUM archives are accessible at http://archives.java.sun.com
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JMX-FORUM". For general help, send email to
listserv@... and include in the body of the message "help".

Re: Accurate CPU timing on Windows -- How?

2007-07-19T10:53:05Z

Jess,

>> Regarding your observation
>>> There is no more efficient way to get at the Sun-specific OS MBean
>>> attribute, "ProcessCpuTime", than
>>> PLATFORM_MBEAN_SERVER.getAttribute( OS_MBEAN_NAME,
"ProcessCpuTime" )

>>> which is not very efficient at all.
>>>
>>> It would be nice if the implementation class was public so one could look up
>>> the method via reflection at static init time and then directly invoke the
>>> method object.
>>>
>> Point taken. But if you have permission to call method.setAccessible(true)
>> then you can access the method by reflection today.
>>
> I thought about doing that, but this crossed some "skankiness" line for
> me. Instead I just decided to avoid collecting this data by default --
> and expose a attribute on my MBeans as to whether they collect this
> statistic.

Luis-Miguel Alventosa reminded me that though the implementation class is
not public, the com.sun.management.OperatingSystemMXBean interface that it
implements is. So you can just cast the result of
ManagementFactory.getOperatingSystemMXBean() to that interface and access
its getProcessCpuTime() method, or do the same thing via reflection.

Regards,
Éamonn McManus -- JMX Spec Lead -- http://weblogs.java.net/blog/emcmanus

===========================================================================
For information on the Java Management extensions (JMX), please visit
our home page at http://java.sun.com/products/JavaManagement/
The JMX-FORUM archives are accessible at http://archives.java.sun.com
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JMX-FORUM". For general help, send email to
listserv@... and include in the body of the message "help".

Re: Accurate CPU timing on Windows -- How?

2007-07-19T07:27:51Z

Eamonn McManus wrote:

> Jess,
>
> I don't know the answer to your question about
> ThreadMXBean.getCurrentThreadCpuTime(), but I've forwarded it to some people
> who might.
>
> Regarding your observation
>> There is no more efficient way to get at the Sun-specific OS MBean
>> attribute, "ProcessCpuTime", than
>> PLATFORM_MBEAN_SERVER.getAttribute( OS_MBEAN_NAME, "ProcessCpuTime" )
>> which is not very efficient at all.
>>
>> It would be nice if the implementation class was public so one could look up
>> the method via reflection at static init time and then directly invoke the
>> method object.
>>
> Point taken. But if you have permission to call method.setAccessible(true)
> then you can access the method by reflection today.
>

I thought about doing that, but this crossed some "skankiness" line for
me. Instead I just decided to avoid collecting this data by default --
and expose a attribute on my MBeans as to whether they collect this
statistic.
> Concerning the question of currentTimeMillis() vs nanoTime(), apart from the
> precision the methods also differ in their semantics. In particular, if the
> system time is adjusted (by the administrator or by NTP, for example),
> currentTimeMillis() will reflect the change. But nanoTime() is independent
> of the system time, so it is more appropriate for timings.
>
Ah... Yes, that is worth noting. I should have had more such
discussions some time back apparently as I am using currentTimeMillis()
since it seemed accurate enough at the time and nanoTime() took a bit
longer to collect..

--
Jess Holle

===========================================================================
For information on the Java Management extensions (JMX), please visit
our home page at http://java.sun.com/products/JavaManagement/
The JMX-FORUM archives are accessible at http://archives.java.sun.com
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JMX-FORUM". For general help, send email to
listserv@... and include in the body of the message "help".

Re: Accurate CPU timing on Windows -- How?

2007-07-19T07:13:37Z

Jess,

I don't know the answer to your question about
ThreadMXBean.getCurrentThreadCpuTime(), but I've forwarded it to some people
who might.

Regarding your observation:

> There is no more efficient way to get at the Sun-specific OS MBean
> attribute, "ProcessCpuTime", than
> PLATFORM_MBEAN_SERVER.getAttribute( OS_MBEAN_NAME, "ProcessCpuTime" )
> which is not very efficient at all.
>
> It would be nice if the implementation class was public so one could look up
> the method via reflection at static init time and then directly invoke the
> method object.

Point taken. But if you have permission to call method.setAccessible(true)
then you can access the method by reflection today.

Concerning the question of currentTimeMillis() vs nanoTime(), apart from the
precision the methods also differ in their semantics. In particular, if the
system time is adjusted (by the administrator or by NTP, for example),
currentTimeMillis() will reflect the change. But nanoTime() is independent
of the system time, so it is more appropriate for timings.

Regards,
Éamonn McManus -- JMX Spec Lead -- http://weblogs.java.net/blog/emcmanus

===========================================================================
For information on the Java Management extensions (JMX), please visit
our home page at http://java.sun.com/products/JavaManagement/
The JMX-FORUM archives are accessible at http://archives.java.sun.com
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JMX-FORUM". For general help, send email to
listserv@... and include in the body of the message "help".

Re: Accurate CPU timing on Windows -- How?

2007-07-19T06:43:21Z

Which all is off the main thrust of my original e-mail:

Is there any way to get more accurate thread CPU times? ThreadMXBean is
extraordinarily inaccurate in this regard!

--
Jess Holle

Jess Holle wrote:

> Michele Mazzucco wrote:
>> Jess,
>>
>> you didn't get my point. What I'm saying is that the values you get are
>> not accurate.
>>
>>
>> >From the javadoc you can see:
>> public static long currentTimeMillis()
>> Returns the current time in milliseconds. *Note that while the
>> unit of time of the return value is a millisecond, the
>> granularity of the value depends on the underlying operating
>> system and may be larger*. For example, many operating systems
>> measure time in units of tens of milliseconds.
>>
>> Returns the current value of the most precise available system timer, in
>> nanoseconds.
>>
>> This method can only be used to measure elapsed time and is not related
>> to any other notion of system or wall-clock time. The value returned
>> represents nanoseconds since some fixed but arbitrary time (perhaps in
>> the future, so values may be negative). This method provides nanosecond
>> precision, *but not necessarily nanosecond accuracy*. No guarantees are
>> made about how frequently values change. Differences in successive calls
>> that span greater than approximately 292 years (2^63 nanoseconds) will
>> not accurately compute elapsed time due to numerical overflow.
>>
> Yes, but as per my previous point you can relate nanoTime() results to
> wall clock time via some simple math on startup. Thus the only reason
> not to rework System.currentTimeMillis() to do so and guarantee
> millisecond accuracy [barring a nanoTime() timer that is not even that
> accurate] is if nanoTime() [plus the conversion necessary to relate to
> wall clock time] is too expensive. Otherwise
> System.currentTimeMillis() should go the way of the dinosaur.
>
> Unfortunately I had done some testing and found System.nanoTime() to
> be significantly more expensive than System.currentTimeMillis() --
> which leads to a tradeoff between great numbers and great speed. To
> date I'm going with speed, which I guess means it all comes down to a
> choice between really inaccurate results and paying a bit more for
> nanoTime() results.
>
> --
> Jess Holle

Re: Accurate CPU timing on Windows -- How?

2007-07-19T06:41:48Z

Michele Mazzucco wrote:

> Jess,
>
> you didn't get my point. What I'm saying is that the values you get are
> not accurate.
>
>
> >From the javadoc you can see:
> public static long currentTimeMillis()
> Returns the current time in milliseconds. *Note that while the
> unit of time of the return value is a millisecond, the
> granularity of the value depends on the underlying operating
> system and may be larger*. For example, many operating systems
> measure time in units of tens of milliseconds.
>
> Returns the current value of the most precise available system timer, in
> nanoseconds.
>
> This method can only be used to measure elapsed time and is not related
> to any other notion of system or wall-clock time. The value returned
> represents nanoseconds since some fixed but arbitrary time (perhaps in
> the future, so values may be negative). This method provides nanosecond
> precision, *but not necessarily nanosecond accuracy*. No guarantees are
> made about how frequently values change. Differences in successive calls
> that span greater than approximately 292 years (2^63 nanoseconds) will
> not accurately compute elapsed time due to numerical overflow.
>

Yes, but as per my previous point you can relate nanoTime() results to
wall clock time via some simple math on startup. Thus the only reason
not to rework System.currentTimeMillis() to do so and guarantee
millisecond accuracy [barring a nanoTime() timer that is not even that
accurate] is if nanoTime() [plus the conversion necessary to relate to
wall clock time] is too expensive. Otherwise System.currentTimeMillis()
should go the way of the dinosaur.

Unfortunately I had done some testing and found System.nanoTime() to be
significantly more expensive than System.currentTimeMillis() -- which
leads to a tradeoff between great numbers and great speed. To date I'm
going with speed, which I guess means it all comes down to a choice
between really inaccurate results and paying a bit more for nanoTime()
results.

--
Jess Holle

===========================================================================
For information on the Java Management extensions (JMX), please visit
our home page at http://java.sun.com/products/JavaManagement/
The JMX-FORUM archives are accessible at http://archives.java.sun.com
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JMX-FORUM". For general help, send email to
listserv@... and include in the body of the message "help".

Re: Accurate CPU timing on Windows -- How?

2007-07-19T06:24:17Z

Jess,

you didn't get my point. What I'm saying is that the values you get are
not accurate.

>From the javadoc you can see:
public static long currentTimeMillis()
Returns the current time in milliseconds. *Note that while the
unit of time of the return value is a millisecond, the
granularity of the value depends on the underlying operating
system and may be larger*. For example, many operating systems
measure time in units of tens of milliseconds.

Returns the current value of the most precise available system timer, in
nanoseconds.

This method can only be used to measure elapsed time and is not related
to any other notion of system or wall-clock time. The value returned
represents nanoseconds since some fixed but arbitrary time (perhaps in
the future, so values may be negative). This method provides nanosecond
precision, *but not necessarily nanosecond accuracy*. No guarantees are
made about how frequently values change. Differences in successive calls
that span greater than approximately 292 years (2^63 nanoseconds) will
not accurately compute elapsed time due to numerical overflow.

Michele

On Thu, 2007-07-19 at 07:12 -0500, Jess Holle wrote:

> Michele Mazzucco wrote:
> > Jess,
> >
> > I'm saying (a), but it's not a windows only problem. It applies to linux
> > as well (I think it applies to all non-realtime os).
> >
> Actually a little experimentation shows (a) is *not* the case.
>
> Try:
> public class Test
> {
> public static void main( String args[] )
> throws Exception
> {
> for ( int ii = 0; ii < 20; ++ii )
> {
> final long start = System.nanoTime();
> Thread.sleep( 3L );
> final long end = System.nanoTime();
> System.out.println( (double) ( end - start ) / 1.0e9 );
> }
> }
> }
> When running this, I get:
> 0.002209499
> 0.003041727
> 0.002880813
> 0.002905955
> 0.003513295
> 0.002158934
> 0.00289562
> 0.002910706
> 0.002923277
> 0.002881372
> 0.002910984
> 0.002908471
> 0.002911264
> 0.002274591
> 0.003108216
> 0.002893664
> 0.002867683
> 0.002905676
> 0.002910984
> 0.002916013
> That is clearly *far* more accurate than using
> System.currentTimeMillis() [and switching the conversion factor],
> where I get:
> 0.0
> 0.0
> 0.01
> 0.0
> 0.0
> 0.01
> 0.0
> 0.0
> 0.01
> 0.0
> 0.0
> 0.01
> 0.0
> 0.0
> 0.0
> 0.01
> 0.0
> 0.0
> 0.01
> 0.0
> [The average of these does actually give exactly 0.003 seconds, which
> is correct.]
>
> This shows that either the issue is (b) or Sun's
> System.currentTimeMillis() is unnecessarily inaccurate (though this
> may well impact more than just Windows).
>
> --
> Jess Holle
> > On Thu, 2007-07-19 at 06:35 -0500, Jess Holle wrote:
> >
> > > Michele Mazzucco wrote:
> > >
> > > > On Wed, 2007-07-18 at 15:51 -0500, Jess Holle wrote:
> > > >
> > > > > * On Windows [at least], System.currentTimeMillis()'s resolution
> > > > > is not milliseconds but rather about 0.01 seconds.
> > > > > * We could use System.nanoTime() instead, but it appears
> > > > > that acquiring this takes a bit more time. Moreover,
> > > > > for the usages in question millisecond accuracy is
> > > > > sufficient, but 0.01 seconds is not always.
> > > > >
> > > > Jess,
> > > >
> > > > this is a kernel issue (kernel precision is typically 10/15 ms), it's
> > > > not related with java.
> > > >
> > > So are you saying that System.nanoTime() is:
> > > a. No more accurate than System.currentTimeMillis() on Windows
> > > *or*
> > > b. Is sufficiently costly that Sun doesn't want to implement
> > > System.currentTimeMillis() via System.nanoTime()'s internals?
> > > Clearly (b) is possible in that one can compute an offset by examining
> > > System.currentTimeMillis() and System.nanoTime() on startup, doing all
> > > timing via nanoTime() and then using the startup numbers to convert
> > > from nanoTime() results to currentTimeMillis() results. I do it in a
> > > few places to avoid having to obtain both types of times when I
> > > already have nanoTime() for some reason. I have to assume that (b) is
> > > more costly, though -- from my own results.
> > >
> > > While all this is annoying the bigger issue is thread CPU time...
> > >
> > > --
> > > Jess Holle
>

Re: Accurate CPU timing on Windows -- How?

2007-07-19T06:22:56Z

Without knowing much in this regard, I seem to recall that
System.currentTimeMillis varies down to roughly 50 milliseconds.

If this is the case, using currentTimeMillis for timings of chunks
smaller than 50 milliseconds is not very accurate.

Regards,
Eske

Jess Holle skrev:

> Michele Mazzucco wrote:
>> Jess,
>>
>> I'm saying (a), but it's not a windows only problem. It applies to linux
>> as well (I think it applies to all non-realtime os).
>>
> Actually a little experimentation shows (a) is *not* the case.
>
> Try:
>
> public class Test
> {
> public static void main( String args[] )
> throws Exception
> {
> for ( int ii = 0; ii < 20; ++ii )
> {
> final long start = System.nanoTime();
> Thread.sleep( 3L );
> final long end = System.nanoTime();
> System.out.println( (double) ( end - start ) / 1.0e9 );
> }
> }
> }
>
> When running this, I get:
>
> 0.002209499
> 0.003041727
> 0.002880813
> 0.002905955
> 0.003513295
> 0.002158934
> 0.00289562
> 0.002910706
> 0.002923277
> 0.002881372
> 0.002910984
> 0.002908471
> 0.002911264
> 0.002274591
> 0.003108216
> 0.002893664
> 0.002867683
> 0.002905676
> 0.002910984
> 0.002916013
>
> That is clearly *far* more accurate than using
> System.currentTimeMillis() [and switching the conversion factor], where
> I get:
>
> 0.0
> 0.0
> 0.01
> 0.0
> 0.0
> 0.01
> 0.0
> 0.0
> 0.01
> 0.0
> 0.0
> 0.01
> 0.0
> 0.0
> 0.0
> 0.01
> 0.0
> 0.0
> 0.01
> 0.0
>
> [The average of these does actually give exactly 0.003 seconds, which is
> correct.]
>
> This shows that either the issue is (b) or Sun's
> System.currentTimeMillis() is unnecessarily inaccurate (though this may
> well impact more than just Windows).
>
> --
> Jess Holle
>> On Thu, 2007-07-19 at 06:35 -0500, Jess Holle wrote:
>>
>>> Michele Mazzucco wrote:
>>>
>>>> On Wed, 2007-07-18 at 15:51 -0500, Jess Holle wrote:
>>>>
>>>>> * On Windows [at least], System.currentTimeMillis()'s resolution
>>>>> is not milliseconds but rather about 0.01 seconds.
>>>>> * We could use System.nanoTime() instead, but it appears
>>>>> that acquiring this takes a bit more time. Moreover,
>>>>> for the usages in question millisecond accuracy is
>>>>> sufficient, but 0.01 seconds is not always.
>>>>>
>>>> Jess,
>>>>
>>>> this is a kernel issue (kernel precision is typically 10/15 ms), it's
>>>> not related with java.
>>>>
>>> So are you saying that System.nanoTime() is:
>>> a. No more accurate than System.currentTimeMillis() on Windows
>>> *or*
>>> b. Is sufficiently costly that Sun doesn't want to implement
>>> System.currentTimeMillis() via System.nanoTime()'s internals?
>>> Clearly (b) is possible in that one can compute an offset by examining
>>> System.currentTimeMillis() and System.nanoTime() on startup, doing all
>>> timing via nanoTime() and then using the startup numbers to convert
>>> from nanoTime() results to currentTimeMillis() results. I do it in a
>>> few places to avoid having to obtain both types of times when I
>>> already have nanoTime() for some reason. I have to assume that (b) is
>>> more costly, though -- from my own results.
>>>
>>> While all this is annoying the bigger issue is thread CPU time...
>>>
>>> --
>>> Jess Holle
>
>
> ===========================================================================
> For information on the Java Management extensions (JMX), please visit
> our home page at http://java.sun.com/products/JavaManagement/
> The JMX-FORUM archives are accessible at http://archives.java.sun.com
> To unsubscribe, send email to listserv@... and include in the body
> of the message "signoff JMX-FORUM". For general help, send email to
> listserv@... and include in the body of the message "help".
>

Re: Accurate CPU timing on Windows -- How?

2007-07-19T06:12:26Z

Michele Mazzucco wrote:

Jess,

I'm saying (a), but it's not a windows only problem. It applies to linux
as well (I think it applies to all non-realtime os).

Actually a little experimentation shows (a) is *not* the case.

Try:

public class Test
{
public static void main( String args[] )
    throws Exception
{
    for ( int ii = 0; ii < 20; ++ii )
    {
      final long start = System.nanoTime();
      Thread.sleep( 3L );
      final long end = System.nanoTime();
      System.out.println( (double) ( end - start ) / 1.0e9 );
    }
}
}

When running this, I get:

0.002209499
0.003041727
0.002880813
0.002905955
0.003513295
0.002158934
0.00289562
0.002910706
0.002923277
0.002881372
0.002910984
0.002908471
0.002911264
0.002274591
0.003108216
0.002893664
0.002867683
0.002905676
0.002910984
0.002916013

That is clearly *far* more accurate than using System.currentTimeMillis() [and switching the conversion factor], where I get:

0.0
0.0
0.01
0.0
0.0
0.01
0.0
0.0
0.01
0.0
0.0
0.01
0.0
0.0
0.0
0.01
0.0
0.0
0.01
0.0

[The average of these does actually give exactly 0.003 seconds, which is correct.]

This shows that either the issue is (b) or Sun's System.currentTimeMillis() is unnecessarily inaccurate (though this may well impact more than just Windows).

--
Jess Holle

On Thu, 2007-07-19 at 06:35 -0500, Jess Holle wrote:

Michele Mazzucco wrote:

On Wed, 2007-07-18 at 15:51 -0500, Jess Holle wrote:

      * On Windows [at least], System.currentTimeMillis()'s resolution
        is not milliseconds but rather about 0.01 seconds.
              * We could use System.nanoTime() instead, but it appears
                that acquiring this takes a bit more time.  Moreover,
                for the usages in question millisecond accuracy is
                sufficient, but 0.01 seconds is not always.

Jess,

this is a kernel issue (kernel precision is typically 10/15 ms), it's
not related with java.

So are you saying that System.nanoTime() is:
     a. No more accurate than System.currentTimeMillis() on Windows
        *or*
     b. Is sufficiently costly that Sun doesn't want to implement
        System.currentTimeMillis() via System.nanoTime()'s internals?
Clearly (b) is possible in that one can compute an offset by examining
System.currentTimeMillis() and System.nanoTime() on startup, doing all
timing via nanoTime() and then using the startup numbers to convert
from nanoTime() results to currentTimeMillis() results.  I do it in a
few places to avoid having to obtain both types of times when I
already have nanoTime() for some reason.  I have to assume that (b) is
more costly, though -- from my own results.

While all this is annoying the bigger issue is thread CPU time...

--
Jess Holle

=========================================================================== For information on the Java Management extensions (JMX), please visit our home page at http://java.sun.com/products/JavaManagement/ The JMX-FORUM archives are accessible at http://archives.java.sun.com To unsubscribe, send email to listserv@... and include in the body of the message "signoff JMX-FORUM". For general help, send email to listserv@... and include in the body of the message "help".

Re: Accurate CPU timing on Windows -- How?

2007-07-19T05:54:42Z

Jess,

I'm saying (a), but it's not a windows only problem. It applies to linux
as well (I think it applies to all non-realtime os).

Michele

On Thu, 2007-07-19 at 06:35 -0500, Jess Holle wrote:

> Michele Mazzucco wrote:
> > On Wed, 2007-07-18 at 15:51 -0500, Jess Holle wrote:
> >
> > > * On Windows [at least], System.currentTimeMillis()'s resolution
> > > is not milliseconds but rather about 0.01 seconds.
> > > * We could use System.nanoTime() instead, but it appears
> > > that acquiring this takes a bit more time. Moreover,
> > > for the usages in question millisecond accuracy is
> > > sufficient, but 0.01 seconds is not always.
> > >
> > Jess,
> >
> > this is a kernel issue (kernel precision is typically 10/15 ms), it's
> > not related with java.
> >
> So are you saying that System.nanoTime() is:
> a. No more accurate than System.currentTimeMillis() on Windows
> *or*
> b. Is sufficiently costly that Sun doesn't want to implement
> System.currentTimeMillis() via System.nanoTime()'s internals?
> Clearly (b) is possible in that one can compute an offset by examining
> System.currentTimeMillis() and System.nanoTime() on startup, doing all
> timing via nanoTime() and then using the startup numbers to convert
> from nanoTime() results to currentTimeMillis() results. I do it in a
> few places to avoid having to obtain both types of times when I
> already have nanoTime() for some reason. I have to assume that (b) is
> more costly, though -- from my own results.
>
> While all this is annoying the bigger issue is thread CPU time...
>
> --
> Jess Holle
>

Re: Accurate CPU timing on Windows -- How?

2007-07-19T05:35:37Z

Michele Mazzucco wrote:

On Wed, 2007-07-18 at 15:51 -0500, Jess Holle wrote:

      * On Windows [at least], System.currentTimeMillis()'s resolution
        is not milliseconds but rather about 0.01 seconds.
              * We could use System.nanoTime() instead, but it appears
                that acquiring this takes a bit more time.  Moreover,
                for the usages in question millisecond accuracy is
                sufficient, but 0.01 seconds is not always.

Jess,

this is a kernel issue (kernel precision is typically 10/15 ms), it's
not related with java.

So are you saying that System.nanoTime() is:

No more accurate than System.currentTimeMillis() on Windows *or*
Is sufficiently costly that Sun doesn't want to implement System.currentTimeMillis() via System.nanoTime()'s internals?

Clearly (b) is possible in that one can compute an offset by examining System.currentTimeMillis() and System.nanoTime() on startup, doing all timing via nanoTime() and then using the startup numbers to convert from nanoTime() results to currentTimeMillis() results. I do it in a few places to avoid having to obtain both types of times when I already have nanoTime() for some reason. I have to assume that (b) is more costly, though -- from my own results.

While all this is annoying the bigger issue is thread CPU time...

--
Jess Holle

=========================================================================== For information on the Java Management extensions (JMX), please visit our home page at http://java.sun.com/products/JavaManagement/ The JMX-FORUM archives are accessible at http://archives.java.sun.com To unsubscribe, send email to listserv@... and include in the body of the message "signoff JMX-FORUM". For general help, send email to listserv@... and include in the body of the message "help".

Re: Accurate CPU timing on Windows -- How?

2007-07-19T02:59:38Z

On Wed, 2007-07-18 at 15:51 -0500, Jess Holle wrote:
> * On Windows [at least], System.currentTimeMillis()'s resolution
> is not milliseconds but rather about 0.01 seconds.
> * We could use System.nanoTime() instead, but it appears
> that acquiring this takes a bit more time. Moreover,
> for the usages in question millisecond accuracy is
> sufficient, but 0.01 seconds is not always.

Jess,

this is a kernel issue (kernel precision is typically 10/15 ms), it's
not related with java.

Michele

===========================================================================
For information on the Java Management extensions (JMX), please visit
our home page at http://java.sun.com/products/JavaManagement/
The JMX-FORUM archives are accessible at http://archives.java.sun.com
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JMX-FORUM". For general help, send email to
listserv@... and include in the body of the message "help".

Accurate CPU timing on Windows -- How?

2007-07-18T14:49:41Z

We've done a good amount of JMX instrumentation of our application -- including various embedded timing metrics, both wall clock and CPU times.

The issue we're seeing is that at least on Windows the CPU thread times produced by ThreadMXBean.getCurrentThreadCpuTime() are horribly inaccurate. We attempt to time various relatively short-lived requests and they all give an elapsed CPU time of 0. I can see that granularity in the timer might lead to some of this, but we have many such requests and they all show an elapsed time of 0 -- whereas one would expect that granularity would lead to sudden large timer jumps during in some measurement intervals.

Is this a known issue?
Are there plans to address this?
Have others worked around this?

Overall, the results are bad enough that we're starting to consider dropping use of ThreadMXBean in favor of JNI code on some platforms (structured such that if the JNI stuff can't be loaded we fallback to using ThreadMXBean, of course). I'd really like to hope that either this is being addressed in an upcoming Java update or that at least someone else has recognized the issue and that there is freely available JNI stuff to use.

--
Jess Holle

P.S. I have noticed other substantial issues in this area as well, including:

On Windows [at least], System.currentTimeMillis()'s resolution is not milliseconds but rather about 0.01 seconds.

We could use System.nanoTime() instead, but it appears that acquiring this takes a bit more time. Moreover, for the usages in question millisecond accuracy is sufficient, but 0.01 seconds is not always.

There is no more efficient way to get at the Sun-specific OS MBean attribute, "ProcessCpuTime", than

PLATFORM_MBEAN_SERVER.getAttribute( OS_MBEAN_NAME, "ProcessCpuTime" )

which is not very efficient at all.

It would be nice if the implementation class was public so one could look up the method via reflection at static init time and then directly invoke the method object.

=========================================================================== For information on the Java Management extensions (JMX), please visit our home page at http://java.sun.com/products/JavaManagement/ The JMX-FORUM archives are accessible at http://archives.java.sun.com To unsubscribe, send email to listserv@... and include in the body of the message "signoff JMX-FORUM". For general help, send email to listserv@... and include in the body of the message "help".

Re: Interpreting error message

2007-07-17T09:07:43Z

Vibha,

The stack trace you show is normal when a remote JMX client connects to a
server. But if you are seeing 1300 threads with the same stack trace then
that normally means you have 1300 remote JMX connections. You might want to
check this with system tools (such as netstat on Unix-like systems).

Another thing you can try is to turn on JMX logging. I usually do this by
running my application with
-Djava.util.logging.config.file=$HOME/java/jmx.logging.properties, where
that file contains the following:

handlers= java.util.logging.ConsoleHandler
javax.management.level=FINEST

java.util.logging.ConsoleHandler.level = FINEST
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter

Setting the property on the command line and logging to System.err, as here,
might not be appropriate in your environment, but you should be able to
figure out alternatives if necessary.

Hope this helps,
Éamonn McManus -- JMX Spec Lead -- http://weblogs.java.net/blog/emcmanus

On Sun, 15 Jul 2007 16:19:55 -0700, Vibha Harikar <vharikar@...> wrote:

>Hi,
> We have a Java (1.5) app (running on Tomcat 5.5.X)
>that is experiencing some production issues. At times
>one one of the Tomcat instances will lockup and cause
>the entire application to be unresponsive. In the
>thread dumps of one of the JVM's we see a large number
>of messages like (apart from many others) :
>
>"JMX server connection timeout 38" daemon prio=1
>tid=0x08aa9b20 nid=0x596c in Object.wait()
>[0x670fc000..0x670fcda0]
> at java.lang.Object.wait(Native Method)
> - waiting on <0x72af9090> (a [I)
> at
>com.sun.jmx.remote.internal.ServerCommunicatorAdmin$Timeout.run(ServerCommunicatorAdmin.java:150)
> - locked <0x72af9090> (a [I)
> at java.lang.Thread.run(Thread.java:595)
>
>There's at least 1300 threads in this state. What does
>this signify ? Is this significant or just a symptom
>of some other problem we could be facing ..?
>
>Any pointers would be appreciated.
>
>Thanks,
>Vibha.

generation of JMX file using PHP ?

2007-07-16T11:29:33Z

hay ,
can any buddy please tell me

how can we generate or create *.JMX file from PHP programming language ? actually i want to run .jmx at jmeter and i want php to create direct jmx file that can have entries of jemter's arguments and parameter ?

Thanx friends.

Interpreting error message

2007-07-15T17:19:55Z

Hi,
We have a Java (1.5) app (running on Tomcat 5.5.X)
that is experiencing some production issues. At times
one one of the Tomcat instances will lockup and cause
the entire application to be unresponsive. In the
thread dumps of one of the JVM's we see a large number
of messages like (apart from many others) :

"JMX server connection timeout 38" daemon prio=1
tid=0x08aa9b20 nid=0x596c in Object.wait()
[0x670fc000..0x670fcda0]
at java.lang.Object.wait(Native Method)
- waiting on <0x72af9090> (a [I)
at
com.sun.jmx.remote.internal.ServerCommunicatorAdmin$Timeout.run(ServerCommunicatorAdmin.java:150)
- locked <0x72af9090> (a [I)
at java.lang.Thread.run(Thread.java:595)

There's at least 1300 threads in this state. What does
this signify ? Is this significant or just a symptom
of some other problem we could be facing ..?

Any pointers would be appreciated.

Thanks,
Vibha.

____________________________________________________________________________________
Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7

===========================================================================
For information on the Java Management extensions (JMX), please visit
our home page at http://java.sun.com/products/JavaManagement/
The JMX-FORUM archives are accessible at http://archives.java.sun.com
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JMX-FORUM". For general help, send email to
listserv@... and include in the body of the message "help".

Re: MBeanServerNotificationFilter and ObjectName pattern

2007-07-06T02:23:33Z

Bonjour Elodie,

Indeed, MBeanServerNotificationFilter does not work as you might expect when
given an ObjectName pattern. You have to add an explicit list of ObjectNames.

It is easy enough to define your own NotificationFilter implementation that
does recognize ObjectName patterns (using ObjectName.apply to match), but
that does require both your client and server to have this class present.
You might also have problems serializing the NotificationFilter with some
connectors. (The standard RMI and JMXMP connectors have no problem, though.)

I have logged a Request For Enhancement to track this, which you will be
able to see at <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6577604>
shortly. But because this is a change in behaviour, we can only make it in
a new release of the Java platform. That means you'll see it in JDK 7 but
not before.

Regards,
Éamonn McManus -- JMX Spec Lead -- http://weblogs.java.net/blog/emcmanus

On Thu, 5 Jul 2007 10:29:21 -0600, Elodie Descarpentries
<elodie.descarpentries@...> wrote:

>Hello,
>
>I want to listen to MBeanServerNotification related to some MBeans,
>therefore I use the MBeanServerNotificationFilter,
>but when specifying pattern ObjectName (with wildcard) in my filter
>criteria I do not receive the MBeanServerNotification I'm expecting.
>
>The test I made :
>MBeanServerNotificationFilter.enableObjectName(new ObjectName
>("mydomain:mykey1=myvalue1,mykey2=myvalue2"))
> ==> notification correctly received
>MBeanServerNotificationFilter.enableObjectName(new ObjectName
>("mydomain:*"))
> ==> No notification received
>MBeanServerNotificationFilter.enableObjectName(new ObjectName
>("mydomain:mykey1=myvalue1,*"))
> ==> No notification received
>
>Does MBeanServerNotificationFilter.enableObjectName(ObjectName)
>support "pattern ObjectName" ?
>
>Thanks
>Elodie

MBeanServerNotificationFilter and ObjectName pattern

2007-07-05T10:29:21Z

Hello,

I want to listen to MBeanServerNotification related to some MBeans,
therefore I use the MBeanServerNotificationFilter,
but when specifying pattern ObjectName (with wildcard) in my filter
criteria I do not receive the MBeanServerNotification I'm expecting.

The test I made :
MBeanServerNotificationFilter.enableObjectName(new ObjectName
("mydomain:mykey1=myvalue1,mykey2=myvalue2"))
==> notification correctly received
MBeanServerNotificationFilter.enableObjectName(new ObjectName
("mydomain:*"))
==> No notification received
MBeanServerNotificationFilter.enableObjectName(new ObjectName
("mydomain:mykey1=myvalue1,*"))
==> No notification received

Does MBeanServerNotificationFilter.enableObjectName(ObjectName)
support "pattern ObjectName" ?

Thanks
Elodie

===========================================================================
For information on the Java Management extensions (JMX), please visit
our home page at http://java.sun.com/products/JavaManagement/
The JMX-FORUM archives are accessible at http://archives.java.sun.com
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JMX-FORUM". For general help, send email to
listserv@... and include in the body of the message "help".

Re: CompositeDataSupport/i18N

2007-06-04T13:05:37Z

As I see it these names are not really amenable to localization -- unless you want all potential programmatic access code to have to do stuff like:

data.get( bundle.getString( "myField", locale ) )

The descriptions of the fields are, however, amenable to localization -- but I'm not sure which JMX consoles expose these...

--
Jess Holle

Stephanie Smith wrote:

When an MBean exposes CompositeData and uses the CompositeDataSupport
class, the itemNames must be passed in. These names are used by the various
consoles when displaying the composite data information.
Is it a best practice to internationalize these names vs just
hard coding within the mbean implementation?

===========================================================================
For information on the Java Management extensions (JMX), please visit
our home page at http://java.sun.com/products/JavaManagement/
The JMX-FORUM archives are accessible at http://archives.java.sun.com
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JMX-FORUM".  For general help, send email to
listserv@... and include in the body of the message "help".

=========================================================================== For information on the Java Management extensions (JMX), please visit our home page at http://java.sun.com/products/JavaManagement/ The JMX-FORUM archives are accessible at http://archives.java.sun.com To unsubscribe, send email to listserv@... and include in the body of the message "signoff JMX-FORUM". For general help, send email to listserv@... and include in the body of the message "help".

CompositeDataSupport/i18N

2007-06-04T12:26:53Z

When an MBean exposes CompositeData and uses the CompositeDataSupport
class, the itemNames must be passed in. These names are used by the various
consoles when displaying the composite data information.
Is it a best practice to internationalize these names vs just
hard coding within the mbean implementation?

===========================================================================
For information on the Java Management extensions (JMX), please visit
our home page at http://java.sun.com/products/JavaManagement/
The JMX-FORUM archives are accessible at http://archives.java.sun.com
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JMX-FORUM". For general help, send email to
listserv@... and include in the body of the message "help".

Re: NotificationListener

2007-05-31T10:04:05Z

Bonjour Manuel,

First of all, you shouldn't need to call jmxc.close() when you get a CLOSED
or FAILED notification. The connector is already dead at that point.

If somebody does mbsc.addNotificationListener(name, listener, null, null)
then the connector has a reference to the listener only as long as the
connection is alive. So unless something else is referencing the listener,
it will be ready for garbage collection as soon as the connector fails or is
closed.

Regards,
Éamonn McManus -- JMX Spec Lead -- http://weblogs.java.net/blog/emcmanus

On Thu, 31 May 2007 11:15:25 -0400, DARVEAU Manuel <mdarveau@...> wrote:

>Bonjour,
>
>
>
>I have a question about NotificationListeners and network failure.
>
>
>
>If I bind a NotificationListener on an MBean and the connection between
>the listener and the MBean drop, will the NotificationListener still be
>called when the connection return?
>
>
>
>When I create the JMXConnector, I add a ConnectionNotificationListener:
>
>JMXConnector jmxc;
>
>private void createConnection(JMXServiceURL url){
>
> jmxc = JMXConnectorFactory.connect(url, null);
>
> jmxc.addConnectionNotificationListener(this, null, this);
>
>}
>
>
>
>
>
>When I get a notification that the connection dropped, I reset the old
>connection and create a new one:
>
>public void handleNotification(Notification notification, Object
>handback) {
>
> String notificationType = notification.getType();
>
> if (notificationType.equals(JMXConnectionNotification.CLOSED) ||
>notificationType.equals(JMXConnectionNotification.FAILED)) {
>
> // Remove the listener to avoid infinite recursion
>
>jmxc.removeConnectionNotificationListener(JmxContext.this);
>
> try {
>
> jmxc.close();
>
> } catch (IOException e) {
>
> // Don't care
>
>}
>
>
>
>if(the connection should really be closed){
>
> return;
>
>}
>
>
>
>// Create the new connection
>
>createConnection();
>
> }
>
>}
>
>
>
>So back to the question, If somebody added a MBean NotificationListener
>using:
>
>mbsc.addNotificationListener(new ObjectName(name), listener, null,
>null);
>
>
>
>and the connection drop. When the connectionNotificationListener
>recreate the connection, will the NotificationListener on the MBean will
>still be valid? Will it continue to receive notifications?
>
>If not, will this create a NotificationListener leak on the server side?
>
>
>
>Thank you very much.
>
>
>
>Manuel
>
>
>
>P.S.: Do you have any documentation on how the connection failures are
>handled by JMX or the rmi connector?

NotificationListener

2007-05-31T09:15:25Z

Bonjour,

I have a question about NotificationListeners and network failure.

If I bind a NotificationListener on an MBean and the connection between the listener and the MBean drop, will the NotificationListener still be called when the connection return?

When I create the JMXConnector, I add a ConnectionNotificationListener:

JMXConnector jmxc;

private void createConnection(JMXServiceURL url){

jmxc = JMXConnectorFactory.connect(url, null);

jmxc.addConnectionNotificationListener(this, null, this);

}

When I get a notification that the connection dropped, I reset the old connection and create a new one:

public void handleNotification(Notification notification, Object handback) {

String notificationType = notification.getType();

if (notificationType.equals(JMXConnectionNotification.CLOSED) || notificationType.equals(JMXConnectionNotification.FAILED)) {

// Remove the listener to avoid infinite recursion

jmxc.removeConnectionNotificationListener(JmxContext.this);

try {

jmxc.close();

} catch (IOException e) {

// Don’t care

}

if(the connection should really be closed){

return;

}

// Create the new connection

createConnection();

}

So back to the question, If somebody added a MBean NotificationListener using:

mbsc.addNotificationListener(new ObjectName(name), listener, null, null);

and the connection drop. When the connectionNotificationListener recreate the connection, will the NotificationListener on the MBean will still be valid? Will it continue to receive notifications?

If not, will this create a NotificationListener leak on the server side?

Thank you very much.

Manuel

P.S.: Do you have any documentation on how the connection failures are handled by JMX or the rmi connector?

=========================================================================== For information on the Java Management extensions (JMX), please visit our home page at http://java.sun.com/products/JavaManagement/ The JMX-FORUM archives are accessible at http://archives.java.sun.com To unsubscribe, send email to listserv@... and include in the body of the message "signoff JMX-FORUM". For general help, send email to listserv@... and include in the body of the message "help".

Re: Visual VM

2007-05-31T00:06:21Z

Is there any early information available on the project? Any websites or URL?

Best Regards,

Sanket

On 5/30/07, Mandy Chung <Mandy.Chung@...> wrote:

Hi Jess,

The VisualVM project will be hosted on java.net and will be
open-source.  The VisualVM is in an early development phase.  The
details and timeline are being worked out.  Before the source is made
available, we are considering making the prototype as a binary available
to get started.  This may take a month or two depending on the process
of getting legal approvals.

I'm including Arseniy, who is the owner of this project, to provide
additional information.

Please stay tuned.

Thanks
Mandy

Jess Holle wrote:

> At JavaOne, there was a fabulous little BOF on an all-in-one open-source
> management and monitoring tool, a "Visual VM" project, that was
> purported to be slated to become a java.net project soon.
>
> I know some of those involved follow this mailing list.  I was wondering
> if anything is happening with this project any time soon.
>
> --
> Jess Holle
>
> ===========================================================================
>
> For information on the Java Management extensions (JMX), please visit
> our home page at http://java.sun.com/products/JavaManagement/
> The JMX-FORUM archives are accessible at http://archives.java.sun.com
> To unsubscribe, send email to listserv@... and include in the
> body
> of the message "signoff JMX-FORUM".  For general help, send email to
> listserv@... and include in the body of the message "help".

===========================================================================
For information on the Java Management extensions (JMX), please visit
our home page at http://java.sun.com/products/JavaManagement/
The JMX-FORUM archives are accessible at http://archives.java.sun.com
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JMX-FORUM".  For general help, send email to
listserv@... and include in the body of the message "help".

=========================================================================== For information on the Java Management extensions (JMX), please visit our home page at http://java.sun.com/products/JavaManagement/ The JMX-FORUM archives are accessible at http://archives.java.sun.com To unsubscribe, send email to listserv@... and include in the body of the message "signoff JMX-FORUM". For general help, send email to listserv@... and include in the body of the message "help".

Re: Visual VM

2007-05-30T12:17:32Z

Hi Jess,

The VisualVM project will be hosted on java.net and will be
open-source. The VisualVM is in an early development phase. The
details and timeline are being worked out. Before the source is made
available, we are considering making the prototype as a binary available
to get started. This may take a month or two depending on the process
of getting legal approvals.

I'm including Arseniy, who is the owner of this project, to provide
additional information.

Please stay tuned.

Thanks
Mandy

Jess Holle wrote:

> At JavaOne, there was a fabulous little BOF on an all-in-one open-source
> management and monitoring tool, a "Visual VM" project, that was
> purported to be slated to become a java.net project soon.
>
> I know some of those involved follow this mailing list. I was wondering
> if anything is happening with this project any time soon.
>
> --
> Jess Holle
>
> ===========================================================================
>
> For information on the Java Management extensions (JMX), please visit
> our home page at http://java.sun.com/products/JavaManagement/
> The JMX-FORUM archives are accessible at http://archives.java.sun.com
> To unsubscribe, send email to listserv@... and include in the
> body
> of the message "signoff JMX-FORUM". For general help, send email to
> listserv@... and include in the body of the message "help".

Visual VM

2007-05-29T15:07:45Z

At JavaOne, there was a fabulous little BOF on an all-in-one open-source
management and monitoring tool, a "Visual VM" project, that was
purported to be slated to become a java.net project soon.

I know some of those involved follow this mailing list. I was wondering
if anything is happening with this project any time soon.

--
Jess Holle

===========================================================================
For information on the Java Management extensions (JMX), please visit
our home page at http://java.sun.com/products/JavaManagement/
The JMX-FORUM archives are accessible at http://archives.java.sun.com
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JMX-FORUM". For general help, send email to
listserv@... and include in the body of the message "help".

Re: External JMX comments

2007-05-12T06:14:14Z

Hi

I have a JMX JSR 160 compliant application. I want to monitor it with HP
OpenView JMX. As per the documentation, I have to create and register a JMX
connector to be able to manage any MBean Server otehr than Weblogic and
WebSphere.

Why is it required?
What is meant by registration?

Regards,

Mohan Kumar

===========================================================================
For information on the Java Management extensions (JMX), please visit
our home page at http://java.sun.com/products/JavaManagement/
The JMX-FORUM archives are accessible at http://archives.java.sun.com
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JMX-FORUM". For general help, send email to
listserv@... and include in the body of the message "help".

ClientNotifForwarder wait infinitly

2007-04-23T12:00:50Z

Hi everyone,

Has anybody ever seen ClientNotifForwarder wait infinitly?

I have a case where a thread wait infinitly while holding a lock on an object and that makes other thread blocked and eventually creating a thread leak on my system.

Name: Thread-142568

State: WAITING on javax.management.remote.rmi.RMIConnector$RMINotifClient@14ba7fe

Total blocked: 0 Total waited: 1

Stack trace:

java.lang.Object.wait(Native Method)

java.lang.Object.wait(Object.java:474)

com.sun.jmx.remote.internal.ClientNotifForwarder.beforeRemove(ClientNotifForwarder.java:745)

com.sun.jmx.remote.internal.ClientNotifForwarder.removeNotificationListener(ClientNotifForwarder.java:167)

javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.removeNotificationListener(RMIConnector.java:1204)

com.miranda.commons.management.JmxContext.removeNotificationListener(JmxContext.java:177)

com.miranda.commons.management.JmxConnectionManager.removeNotificationListener(JmxConnectionManager.java:177)

com.miranda.adapters.agent.router.RouterClientJMX$2.run(RouterClientJMX.java:222)

I have two other suspicious threads:

Name: ClientNotifForwarder-297

State: WAITING on [I@1180ab3

Total blocked: 67 Total waited: 1

Stack trace:

java.lang.Object.wait(Native Method)

java.lang.Object.wait(Object.java:474)

com.sun.jmx.remote.internal.ClientCommunicatorAdmin.restart(ClientCommunicatorAdmin.java:82)

com.sun.jmx.remote.internal.ClientCommunicatorAdmin.gotIOException(ClientCommunicatorAdmin.java:34)

javax.management.remote.rmi.RMIConnector$RMIClientCommunicatorAdmin.gotIOException(RMIConnector.java:1413)

javax.management.remote.rmi.RMIConnector$RMINotifClient.fetchNotifs(RMIConnector.java:1293)

com.sun.jmx.remote.internal.ClientNotifForwarder$NotifFetcher.fetchNotifs(ClientNotifForwarder.java:508)

com.sun.jmx.remote.internal.ClientNotifForwarder$NotifFetcher.run(ClientNotifForwarder.java:399)

com.sun.jmx.remote.internal.ClientNotifForwarder$LinearExecutor$1.run(ClientNotifForwarder.java:83)

Looking at the code, I see that ClientNotifForwarder.postReconnection should do beingReconnected = false; notifyAll(); but it is stalled waiting:

Name: Thread-34

State: WAITING on javax.management.remote.rmi.RMIConnector$RMINotifClient@14ba7fe

Total blocked: 130 Total waited: 2

Stack trace:

java.lang.Object.wait(Native Method)

java.lang.Object.wait(Object.java:474)

com.sun.jmx.remote.internal.ClientNotifForwarder.postReconnection(ClientNotifForwarder.java:314)

javax.management.remote.rmi.RMIConnector$RMIClientCommunicatorAdmin.reconnectNotificationListeners(RMIConnector.java:1512)

javax.management.remote.rmi.RMIConnector$RMIClientCommunicatorAdmin.doStart(RMIConnector.java:1577)

com.sun.jmx.remote.internal.ClientCommunicatorAdmin.restart(ClientCommunicatorAdmin.java:106)

com.sun.jmx.remote.internal.ClientCommunicatorAdmin.access$500(ClientCommunicatorAdmin.java:16)

com.sun.jmx.remote.internal.ClientCommunicatorAdmin$Checker.run(ClientCommunicatorAdmin.java:178)

java.lang.Thread.run(Thread.java:595)

My guess is that the state was changed to TERMINATED but the method setState does not call notifyAll when the state is changed to TERMINATED.

I tried to unplug and plug the network cable to force a state change but it does not seem to change anything…

Should I report a bug? I made a search on the database and found bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6199899 but it was closed and the situation described is “impossible”.

Anyone has an idea?

Thank you very much!

Manuel Darveau

P.S.: I have a report of the state and stack trace for every threads in my application so if you would like to take a look at it, I can send it in private.

P.P.S.: Anyone know if it is possible to make contrib to jconsole?

=========================================================================== For information on the Java Management extensions (JMX), please visit our home page at http://java.sun.com/products/JavaManagement/ The JMX-FORUM archives are accessible at http://archives.java.sun.com To unsubscribe, send email to listserv@... and include in the body of the message "signoff JMX-FORUM". For general help, send email to listserv@... and include in the body of the message "help".

addNotificationListener not adding multiple listeners

2007-04-12T00:42:12Z

Hi,
made the listener unique by adding a unique handbackobject.
and add a listener in each server.
but when I invoke the bean method (which creates the notification), only 1 listener is getting notified?

when i do getnotificationIndo I do see only 1 listener.

this I tried using jsr-160 api in weblogic too. but to no avail.
only 1 listener gets called.

this seems like a bug/issue in wls92.not sure how to get over it.

rgds.