> |I guess that Rama is talking about milliseconds... the JBoss TX
> |and security
> |layers adds lots of overhead. The argument (de)marshalling
> and the actual
> |transportation of a no-args call over the network layers
> should typically
> |not take more than 0.5 - 1.5 milliseconds to complete.
>
> To see that run the tomcat test that ship with jboss-tomcat (under
> http://localhost:8082/jboss)
>
Thanks for the tip. However there's a small typo in the URL. It should read
http://localhost:8080/jboss.
> You will see 2 tests in JBoss one with optimizations on and
> one without.
Ok.
> Run these, I would be VERY surprised if you ran the
> optimized one above 0.1
> milliseconds. This is the time the ***container*** takes,
> anything else is
> something else (DB queries non optimized, serialization of
> keys etc etc)
>
Optimized calls took approximately 0.1 msecs and non-optimized calls
approximately 1 msecs (JBoss 2.2.1, SUN:s JVM 1.3). 0.1 msecs (if the tests
are correct) for an in-VM call is still a long time compared to a "normal"
in-VM method invocation.
Does the JBoss optimized container invoker (or whatever it's called...)
serialize arguments in order to preserve RMI semantics (i.e. pass-by-value)
and short-circuit the RMI layer?
If that's the case I guess that RMI doesn't have collocation detection
intelligence otherwise the optimizion would not have been necessary. But of
course I could be completely wrong on this one;-)
Will the new Local interfaces introduced in the EJB 2.0 pfd improve things
with its pass-by-reference semantics (except that Java does not supports
"true" pass-by-reference as it lacks direct pointer/address manipulation)?
Cheers,
Per
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
