Running JBoss with JBossMX

[adrian.brock]

Thought I'd start a progress report.

There are three outstanding problems.
1) Remove get/set Attribute through invoke()
2) Querying needs to be completed for the JSR77 discovery
code.
3) Sun's JMX HTML adaptor only works with jmxri.jar
it uses the trace classes. (Might be able to run it
underneath until we have our own?)

I've started doing (1)
Trevor, are you still working on (2) ?
What are we going to about (3) ?

Regards,
Adrian

[squirest]

> 2) Querying needs to be completed for the JSR77
> discovery
> code.

Damn, I had no bloody idea that was the case.

As far as completeness goes, I've got query support in the registry - i.e. it handles ObjectName patterns.

There's outstanding issues related to resovling an ObjectName with an unspecified domain (caller expects the MBeanServer to create a new oname with its default domain filled in). These are minor.

There is significant donkeywork involved in implementing the queryexp releted classes.

Adrian, would you be willing to take this stuff on? I'm still stuck trying to complete a unified call routing mechanism for reflection based invokes() - model and std mbeans.

This BCEL stuff has thrown a spanner in the works but if done right it could make invocations obscenely fast. I really want to pursue it but I don't want to hold everything else up.

If you're up for it I'll email you my revised BasicMBeanRegistry and testcases.

> 3) Sun's JMX HTML adaptor only works with jmxri.jar
> it uses the trace classes. (Might be able to run it
> underneath until we have our own?)

If it's just the Trace class I wonder if we could just pull it out of the RI jar and stick it into the jmxtools jar. May be licensing issue with that...

Trev

[adrian.brock]

Ok,

Querying
Send me what you have, or commit it if you like.

HTML adaptor
I haven't tried it, but we might be able to move
jmxri.jar to lib/ext for the com.sun classes.
It depends on whether Sun's adaptor takes short-cuts
around javax.management.

Regrds,
Adrian

[adrian.brock]

Trevor,

Can you post to the dev-list an explanation about why invoke
shouldn't be used for attributes?

I could do it myself, but I think you probably know
more of the arguments. :-)

Regards,
Adrian

[adrian.brock]

I've got good news and bad news.

First the goods news
1) JBoss works with JBossMX :-)
2) It doesn't break anything in the testsuite
3) In fact it fixes a couple of problems in the
WebIntegerationTestCase
Now the bad news
1) It only runs if the testsuite uses JBossMX. Using
jmxri has a serialverid problem with ObjectName
2) It is slower.
jmxri takes 480 secs to run the testsuite
we take 600 secs (580 without my recent TCL fix).
Is this a serialization/marshalling problem?
Is there too much ObjectName creation in JBoss?
Investigating...

Regards,
Adrian

[adrian.brock]

I should point out to people who don't know,
JBossMX is currently an alpha release.

It's performance still has to be measured and tuned

The one part we have measured is local invokes()

Dynamic MBeans time for 100,000 invocations
jmxri 90 to 110 ms
JBossMX 60 to 75 ms

Standard MBeans time for 100,000 invocations
jmxri 1240 to 4650 ms
JBossMX 430 to 850 ms

Default Domain with no arguments
jmxri 2100 (dynamic) 3700 (standard)
JBossMX 110 (dynamci) 440 (standard)

This depends on the argument types and of course
the cpu speed.

Regards,
Adrian

[squirest]

WRT point 2 in the bad news:

ObjectName creation times per Million:

jboss-mx: 1 key property - 15 seconds
jboss-mx: 4 key properties - 35 seconds

RI: 1 key property - 18 seconds
RI: 4 key properties 88 seconds

So I don't think our ObjectName is the culprit.

I also tested to see how we were for MBean registration and unregistration. Across 100K registration/unregistration pairs we have:

jboss-mx: 29 seconds
RI: 32 seconds

IMHO that leaves marshalling as the only culprit that could have 120 seconds worth of impact. Perhaps we're doing something that causes annotations to be huge?

I'm stumped.
Trev

[adrian.brock]

Hi Trevor,

That is my guess as well.

I only mentioned ObjectNames because the testsuite
does a lot of deploy/undeploy. Translated into JMX
that is registration/deregistraion.
Your numbers show this isn't the problem.

We shouldn't optimize for this anyway.
deploy/undeploy doesn't happen during normal operation,
invoke and get/set attribute is what we need to optimize.

Given invoke is much is better than the RI
(attibutes need testing but they aren't used much in
JBoss) that leaves serializing objects between different
contexts (Marshalling).

Whatever the problem is, it is systematic.
In plain English, it applies to all tests.
Once we've tracked it down we are going to fly.

I don't think 2 minutes overhead out of 10 is too bad to
say we haven't event looked at this area yet.

Regards,
Adrian

[marc.fleury]

hmmmmm

strange

why would the change of JMX impl have any effect on the marshalling? we don't even use the MLets so... that should even be portable.

But I agree such a large difference is only accountable on the basis of serialization. Can you make sure the path is the "optimized" one in the codebase?

[adrian.brock]

Time to eat humble pie. (Always repeat your tests)

The systematic problem must have been me running
something intensive during the JBossMX tests :-p

Tried running the testsuite again last night both
the RI and JBossMX run it in about 450ms

Just to show the relative importance (performance)
of the JMX implementation compared to database,
I increased the invocation count of the Bank Stress Test
to 1000 and ran it with both JMX implementations.
They both do it in 370 secs.

Regards,
Adrian

[adrian.brock]

Java 1.4 and SingleJBoss,

We don't have the get/is bug :-)

I tried it with j2sdk1.4-beta3.

Regards,
Adrian

[adrian.brock]

I tested running Sun's html adaptor with
jmxri.jar in "lib", the adaptor works fine
with JBossMX

We need to check the license on that one.

Are we allowed to replace part of this library by
putting our implementation in a parent classloader?

Regards,
Adrian

[squirest]

Good news about the get/is bug not being present.

I'm confused about the 450ms for the testcase. Which testcase and are you saying that the RI did it in 450ms and JBossMX did it in 450ms?

Trev

[adrian.brock]

The whole thing. All 500 tests in the JBoss testsuite.

JMX is relatively unimportant.

The performance hits are rmi and database.

Regards,
Adrian

[adrian.brock]

Oh yeah,

I meant 450 secs not 400ms :-)

That's to the nearest 10 secs. I think from memory
it was JBossMX 451, jmxri 454.

But it varies on my PC between 450 and 480 secs,
so don't read too much into JBossMX being faster.

Regards,
Adrian