-
15. Re: ClassLoader behaviour on remote clustering tests
There is one issue with the default aopc.
We have few tests that are time sensitive, testing things like expiration time.. things like that.
Those tests are failing with the default aopc and passing with the ClassicVersion.
That makes suspect that there is some performance issue (maybe excessive classLoader) with the newer version. You should investigate.
From our side I will keep using the Classic when calling aopc. -
16. Re: ClassLoader behaviour on remote clustering tests
Being more specific org.jboss.test.messaging.jms.clustering.DistributedQueueTest is failing with default instrumentation and passing with classic.
to test it you could either use runtest or:
cd ./test
ant -Dtest-mask=DistributedQueueTest clustering-tests compile-report
Something is taking more time when we send a message. -
17. Re: ClassLoader behaviour on remote clustering tests
I'll take a look.
My bet is that the lazy generation of classes is affecting your test performance. The default instrumentation mode generates classes only when the affected joinpoint are executed for the first time. On the other hand, the classical instrumentation does not generate any classes in this moment... everything is generated during aopc execution solely.
I'll let you know when I have a better answer. -
18. AOP taking more time on calls WAS: ClassLoader behaviour
All the test does is send and receive messages.
Those methods were used before the call that caused the failure.
At the time the message is taking more time to perform a send call, the pseudo internal class on AOP should be already generated. -
19. Re: ClassLoader behaviour on remote clustering tests
Clebert,
I am seeing 348 calls to the joinpoint class generation code during the execution of your tests. The weird is that there are only 28 entry points (method wrappers) that call this code.
8 of those 28 entry points are called thousands times each. The other 20 are called only a few times each, and if we sum up all the times they are called, we will get to 339 calls.
Thanks to the cache of generated classes, only 205 of the 348 calls to the generation of classes actually result in a class generation. The other calls just retrieve classes from the cache.
Anyway, I don't see why would the class generation ocurr so many times if you told me that those tests don't perform any dynamic addition/removal of aspects. My initial thought is that we should see one class generation call for each one of those 28 methods, and this should occur the first time those methods are called.
Probably I'm missing something here... I'll continue looking for what is causing this. -
20. Re: ClassLoader behaviour on remote clustering tests
Oh,yes. I forgot to let you know how much time is being taken with this piece of the code.
The 348 calls to the joinpoint class generation is taking a total of 9548ms to execute. The 205 real class generation that takes place takes a total of 9137ms.
Notice that I haven't evaluated the isolated performance during execution of the failed test methods. All these numbers regard the performance of the execution of the whole test execution (i.e., the 8 test methods). -
21. Re: ClassLoader behaviour on remote clustering tests
I'm not happy with this lazy generation - can we just switch back to the non lazy generation please?
(I.e. the way that AOP used to work)
10 seconds is way too long. Also bear in mind that messaging systems must not provide reasonably stable latency, Suddenly pausing for 10s is not an option. -
22. Re: ClassLoader behaviour on remote clustering tests
"timfox" wrote:
I'm not happy with this lazy generation - can we just switch back to the non lazy generation please?
Then use the ClassicInstrumentor. -
23. Re: ClassLoader behaviour on remote clustering tests
"kabir.khan@jboss.com" wrote:
"timfox" wrote:
I'm not happy with this lazy generation - can we just switch back to the non lazy generation please?
Then use the ClassicInstrumentor.
That's what we are doing now.
I raised the issue of the performance problem with Flavia for AOP's benefit. I believed something weird was going on and it looks like Flavia confirmed that looking at those numbers.
From our side we are using ClassicInstrumentator and that is fixing our problem, but this might affect other users using AOP for other ends. -
25. Re: ClassLoader behaviour on remote clustering tests
Thanks to the messaging tests, we were able of detecting this performance failure before JBoss AOP go GA.
I have spotted the cause of the overhead and I'm working on it:
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4145045#4145045