I've been studying the invokers while working on the xid-based transaction propagation and plan to do some refactoring if there are no strong objections.
1. I plan to make both the client (sending) and server (receiving) halves of the invokers layered with aspects or interceptors. This will enable reuse of everything except the transport layer across most invokers. 2. I have not yet tried performance tests on these, but have noticed that the principal structural difference between the pooled invoker and the trunk invoker is that the trunk invoker multiplexes simultaneous requests asynchronously over the same socket, whereas the pooled invoker ties up the socket for the entire duration of server-side request processing. I would expect this would translate into slightly better performance for the pooled invoker with a single threaded client, due to the lack of the synchronization and queueing between requests and responses, but enormously better performance for the trunk invoker with a multithreaded client (and perhaps multi-processor server). I may not understand all that is going on in the pooled invoker: my assumption is that each client obtains a single socket connection to the server, and it is reused for all requests from a single client, and that it is served by a single server thread. If I'm wrong I'd welcome correction. 3. In order to use the work import contracts, I plan to make all the invokers asynchronous, as the trunk invoker is today. The Work object will include both the code to call the mbean target (i.e. ejb) and the information necessary to return the result back through the transport mechanism. It's possible that separate inbound and outbound interceptor/aspect stacks may be desirable. 4. There has been some discussion about two way transport, as implemented in the trunk invoker. It seems to me that any way of calling an ejb has in it 2 communication channels, one in each direction. If these are based on accessible sockets, the channels can be used in the opposite direction and order, thus providing two way transport. I propose to provide this two way transport when the underlying transport supports these separable transport directions (for instance, my impression is that rmi does not). If there are problems with this approach I'd like to know about them. If you disagree with this approach please explain why the in and out streams from a socket should not be used in both directions for this purpose and explain in at least a little detail an alternative approach. Thanks david jencks ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
