Congratulations!
And thank you for sharing this important information: I'm afraid that
our commercial project has got into the same performance trap.
Best regards,
Oleg
Rickard �berg wrote:
R�> All,
R�> Some important performance problems were found and eliminated yesterday.
R�> jboss-user version:
R�> Fix is in CVS. After a clean rebuild, jboss-client.jar is updated so you
R�> need to redistribute it to your clients.
R�> jboss-dev version:
R�> This wasn't "deep" as I first thought. It was "deep, move to a parallel
R�> dimension, back again, through a black hole, and then some". The basic
R�> problem was that if a method returned an EJBObject proxy (such as home
R�> methods, or some bean methods) the call would take about 80ms. Crap
R�> performance in laymans terms. After A LOT of digging, testing, and JDK
R�> source reading, I found out that it was the *deep breath* container stub
R�> class descriptor RMI codebase annotation during serialization of dynamic
R�> proxies that through the internal RMI classloader involved extraction of
R�> multiple URL's from the MLet classloader, and in the process required
R�> FilePermission checks on all JAR's in classpath. *breeaatthhee oouutt*..
R�> (Note: what finally led to me this conclusion was that I did new
R�> Exception().printStacktrace() from within the SecurityManagers
R�> checkPermission method. Most illuminating)
R�> Did you get that? :-)
R�> Basically, A WHOLE LOT OF THINGS GOING ON FOR EACH CALL!
R�> So, by placing the stub classes (which are in jboss-client.jar) in the
R�> Class-Path: manifest header of run.jar, they were instead available from
R�> the system loader, hence bypassing the lengthy process of MLet URL
R�> extraction and verification, and instead uses the RMI codebase system
R�> property.
R�> Result? Well, instead of 80ms for a call to a method involving returning
R�> of proxies, it takes about 4 ms. :-)
R�> During my travels through the jBoss code I also updated the classes that
R�> were sent frequently between client and server (mainly the proxy
R�> InvocationHandlers and RemoteMethodInvocation classes) to implement
R�> Externalizable instead of Serializable. My research for the Mastering
R�> RMI book has shown that this optimization can provide quite large
R�> performance improvements for this type of objects.
R�> Happy happy.
R�> Well, that's it. As above, the fixes are in CVS now. Go get 'em.
R�> regards,
R�> Rickard
