> > - 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.
>

Perhaps..  I've not double checked the pool code.  The first time an
invocation comes though shure, but the second time, the pooled thread should
get reused.

> > - 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?
>

Yep.. But this is good, if servicing requests has a delay in it..  You can
sqeeze more requests into one socket.  I need to make the connections pooled
also so that a single socket does not get over-used.

> > - 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.
>

thanks.

> > 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.
>

The JMS server uses callbacks.  Thats how it drives asynchronous message
delivery.  A normal RMI callback object cannot allways be used since the
client may be behind a firewall.  I want to be able to communicate with the
client over the same socket that he established with the server.  Make
sense??

Regards,
Hiram

> 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



-------------------------------------------------------
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

Reply via email to