I dont follow the above exactly?
It's basically a Java issue. Interrupting a process that is doing some i/o is complex, and difficult to do in the same way on all platforms. So the JVM guys went for the solution that was implementable on all platforms: close the socket when there is an interrupt.
What will 'name' be?
The same name as the reader, postfixed with 'writer').
yet another thread in client seems crazy
Yeah. But I think that we're not far from being able to put a single pool for all the region servers, instead of 1 thread per region server as today (and with this new option on). There is this nasty rpcTimeout, and then we're clean enough to do the change I think. It's something I would like to do with a direct buffer write. Ir's more or less mandatory to scale on large sized cluster imho.
ThreadCallSender should be CallRunner or Call Executor
I don't know. It does not execute much, it just writes on the socket. It uses the output stream of the connection, so it has to be an instance if I want to limit the impact on the existing code.
+ callsToWrite.remove(cts); Do you have to cancel the future itself too?
setting call.done allows the reading thread to skip this part
removing it from the callsToWrite list allows us to not send the call to the remote server at all.
So we do both.
Now if the call was sent to the server, it's not stopped (at least with this patch , just that we will skip the answer. Canceling on the server is interesting, but on the other hand it's another rpc call.
Imlement Closeable since it has a close? Not necessary at all but...
agreed. Will do.
Can you write up a big class comment on the mechanism you are instituting here so it is clear what is going on both for reviewers and for the folks who come along afterward trying to make sense of it all
Sure. I'm polishing a doc as well that I will put in this jira.