-
1. Re: Changes to Client that require connect() be called
tom.elrod May 21, 2006 1:15 PM (in response to tom.elrod)BTW, one of the reason I think this is reasonable is that calling disconnect() *is* required when finsihed using Client, so having to call connect() before using Client seems logical.
-
2. Re: Changes to Client that require connect() be called
timfox May 21, 2006 2:25 PM (in response to tom.elrod)From my POV this is fine.
-
3. Re: Changes to Client that require connect() be called
bill.burke May 21, 2006 10:56 PM (in response to tom.elrod)not sure what it means to clean up a client invoker once it is finished with it. Does this mean closing the socket? If so, then this new approach is bad. The whole idea of keeping connections around on the client is avoid opening connections to the server (which is expensive). Also, referencing counting is never really a great idea either as the VM does this for you. You might be better off with weak references.
-
4. Re: Changes to Client that require connect() be called
tom.elrod May 22, 2006 8:21 AM (in response to tom.elrod)Each Client contains a reference to a client invoker (e.g. SocketClientInvoker, RMIClientInvoker, etc.). Is possible to have multiple Clients for the same server, which in remoting means they use the same invoker locator (e.g. socket://myhost.com:8900). The Client actually gets their client invoker instances from the InvokerRegistry. So when the first Client gets a client invoker for locator socket://myhost.com:8900 from the InvokerRegistry, a new one will be created. If another Client gets a client invoker for locator socket://myhhost.com:8900, it will get a reference to the one already created. If either of these Clients calls disconnect(), the InvokerRegistry will know that there is still another Cient referencing the client invoker and do nothing. If the second Client calls disconnect, InvokerRegistry will see no one else has a reference to the client invoker and is ok to close any client socket connections.