RE: [JBoss-dev] new PooledInvoker: speeds up invocations

[Hiram Chirino]

I agree.. same socket bi-directionality is exotic and does not have to be in the public interface.   Currently, it's not very nice how the proxy going back client gets setup.  I won't go into details about the current way I do it (it sucks). Here's the route I hope I can change too soon: 1) client sends a proxy object down an invocation to the server.. 2) server invoker sets either (a) an Invocation attribute or (b) and ThreadLocal to identify the socket the invocation came over. 3) When the proxy object is de-serialized, he looks up the object in (2) to setup the callback channel to go through the original socket.   But for this to work in the (a) case  the proxy object would need to be able to access the Invocation object during deserization. And for it to work in the (b) case the proxy object has to be deserialized while in the context of the thread the invocation came in.   I don't think I'll be able to do this the way invocations are done right now.  You think this is a bad route?    Regards, Hiram   -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bill Burke Sent: Sunday, November 17, 2002 11:16 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] new PooledInvoker: speeds up invocations I agree Scott (no public interface for bi-directionality).  It will be tricky to implement the bi-directional behavior if Invokers don't have a bi-directional public interface.  I wonder how you abstract this out now Hiram.   One way to do this would be to use the trick I used with EJBs and multiple-invokers.    1. Have a proxy factory. 2. Pass this information with the client request. 3. Look up the proxy factory whenever you have to create proxies via the tag in the invocation.   Bill -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Scott M Stark Sent: Saturday, November 16, 2002 1:49 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] new PooledInvoker: speeds up invocations It should be possible to route invocations over the incoming channel, but it cannot be a requirement. This does not imply the invocation interfaces are bi-directional however. There simply needs to be the ability to compose the invokers such that there is a shared communications channel.   xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx ----- Original Message ----- From: Victor Langelo To: [EMAIL PROTECTED] Sent: Friday, November 15, 2002 7:11 PM Subject: Re: [JBoss-dev] new PooledInvoker: speeds up invocations Hiram Chirino wrote: Hiram Chirino wrote: > Anyways. JMS need bi-directional invocations (BADLY). Should this > become a requirement for the other invokers?? I completely disagree. There is no reason server to client communication has to go over the back channel of a client to server I might have said this before, but there is one reason it's a nice feature: This allows callback to clients that are sitting behind a firewall. Let me agree with Hiram. I would add it is essential to use the client connection if the client network is using NAT (network address translation). With the advent of new security measures, many of our clients are adding firewalls and NAT. The worst case is when the server has a public IP and the local LAN clients are on the otherside of a NAT router. --Victor