The RPC client will send out the request asynchronously.
Asynchronously is what it does - so it does not fail even without this patch.
The problem is that it takes 200-300ms to send it out, by which time another IPC update has already queued up for the same connection.
See the two threads locked against each other in the bug report, where one is doing a NameNode operation and another is doing an ApplicationMaster update - which need never lock against each other in reality.
Because they both use the same ipc.Client singleton.
If you want to revisit this fix, please remove the Client singleton or find another way to remove the synchronization barrier around the getConnection() & the way it prevents reopening connections for IPC.
The current IPC implementation works asynchronously, but is too slow to keep up with sub-second performance on a multi-threaded daemon which uses a singleton locked object for 24 cores doing everything (namenode lookups, app master heartbeats, data movement events, statistic updates, error recovery).