Alvin, >Hi, >I think there is no ready-made here to >increase the Ping duration. >But one can do (for now) stop the pinger by >doing something like: > >HostContext.getInvocationHandler().close() . > >Checkout the impl'n: > >*.altrmi.client.AbstractClientInvocationHandler.close() >method ... > What Viany says is true. But you have another option - you can if you want replace the DefaultConnectionPinger with PerpetualConnectionPinger or one that you write yourself in your codebase. It is designed to be settable.
>Maybe as you mentioned rightly , >This should be implemented at each >ConcreteInvocationHandler level too so that they >can also close/release the socket connections >to the server. > A transport that establishes new connections per invocation ? I think that could work but be amazingly slow. Is not the proposition that it is some sort of thread sharing solution on the server side. A few other teams have done this sort of work on sockets at Apache, I'll see what code can be stolen.. >>How does the client indicate that there are no >>more requests for a >>long time [ie: waiting for the user's next command]? >> At the moment, the client does nothing proactive to say that the connection is idle. I am sure we could patch into the pinging mechanism so that the server could note "that is the 20th ping without real method request". We are thinking about our distributed garbage collection needs. That is, when a client has truly finished with a proxy on the client side it is dropped by AltRMI on that side too and then communicated back to the server that it is no longer in use by that client. This could be done by something that is working like the pinger, in that periodically a weak hash map is perused looking for dead entries, elements are then trimmed from the map and reported as such to the server (or reported then trimmed). Maybe the last issue here is that we are still evolving AltRMI. We are pleased to a see others using it, but you must be aware that we have not tested this for bullet-proof-ness. That said we would welcome ideas, patches and even involvement from interested parties such as yourself. Regards, - Paul H -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
