OK, I've looked into this issue quite a bit. The thing that surprised me about Uma's description of the problem is that the proxy object (like all Objects) should have an implementation of toString(), so I was surprised that anything would throw a noSuchMethodException. For that matter, note that the last line of the stack trace Uma posted references RetryInvocationHandler.java:70, which is inside a catch clause which only gets reached if the method invocation fails. I was obviously surprised that a call to toString() would throw an exception.
Turns out this happens because RetryInvocationHandler.invoke assumes that the interface implemented by the proxy declares all the methods which get invoked on it. This is done to check for the @Idempotent annotation on the method, and this is what throws the NoSuchMethodException. The reason the call to toString() throws an exception is because the underlying WritableRpcEngine checks for the declaring class's (Object's) versionID field, which obviously doesn't exist on Object.
So, this patch doesn't really introduce the issue, except to cause toString() to be potentially called on an implementation of ClientProtocol. Ideally we would do something to allow the calling of toString() on RPC proxy objects without weird exceptions, but that seems like it's beyond the scope of this JIRA. I'll file a separate one to address the issue of calling toString on a proxy object. The patch Uma supplied won't quite work as-is, since the proxy and invocationHandler objects can't be assumed to be non-null, but it's close. I'll file a separate JIRA to get this addressed as well.