> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Hiram > Chirino > Sent: Thursday, November 14, 2002 8:20 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] new PooledInvoker: speeds up invocations > > > > > scenario. The PooledInvoker is 300% faster than the default > > > RMI Invoker. > > > > > > 2nd scenario: > > > invokor is 30% faster than the default RMI based invoker. > > > > > P.S. This code is extremely more simple than the Trunk > > > Invoker and I've been told that the Trunk Invoker provides no > > > performance boost. > > > > Plus the name sucks. Let's stir clear of 'cute names', PooledInvoker > > clearly describes what it is. > > > > Yes the 'trunk' name sucks.. > > Maybe you can help me give it a better name. here are the things it does: > > - bi-directional invocations. client can invoke the server, server can > invoke the client.
Ahh...Ok then that's the reason for most of the complexity. > - Thread pooling (same as the PooledInvoker). When I looked at code it looked like there still was a thread being spawned for each invocation. Sure, when you hand off the message, there is a pool there, but there seemed to be a thread spawn before this. This needs to be avoided. > - Connection sharing. Multiple invocations can be sent to the > server at the > same time. Sending an invocation down the socket does not stop other > invocation from going down the pipe. Is this possible? Doesn't the socket get synchronized (and thus serialized invocations) when a lot of threads hit it? > - Uses NIO if running under java 1.4, normal blocking IO if on 1.3 > > My performance testing did not show it was better than RMI. Perhaps I was > running a bad test, perhaps I need to add connection pooling so that more > than one socket is established from the client to the server. Perhaps all > this functionality is just adding too much overhead. > I'll add the benchmark to the pooled test in the testsuite. It already benchmarks RMI vs. Pooled. > Anyways. JMS need bi-directional invocations (BADLY). Should > this become a > requirement for the other invokers?? > Could a InvocationResponse object be used instead? Or, if you had detyped invocations, couldn't you just pass a callback object along with the request via a client-side interceptor? Just curious...why do you need bi-directional invocations? Acknowledgements? Callbacks? Is David using the bi-directional capability for Distributed Trans callbacks? The whole point of the Invoker architecture is to detach the transport layer from the actual service. Bill ------------------------------------------------------- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
