During the experiment, under heavy workload, some client's request to delete a file reaches namenode after it is already deleted by other client (it deletes the parent directory of the file).
Namenode replies with an exception saying the file doesn't exist.  The exception stored in the reply includes a stack trace of the exception and the trace may include some class name that seem to get created dynamically.
Line 21933 in the following example is one. ( GeneratedMethodAccessor22 ) In other replica, the corresponding name was GeneratedMethodAccessor20 and this caused the replies from and checkpoints of replicas to be different.
As a simple temporary fix, I replaced all GeneratedMethodAccessor22  with GeneratedMethodAccessor?? in the replies.  

at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.checkLease(FSNamesystem.java:1669)
21929   at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.checkLease(FSNamesystem.java:1660)
21930   at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getAdditionalBlockInternal(FSNamesystem.java:1529)
21931   at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getAdditionalBlock(FSNamesystem.java:1473)
21932   at org.apache.hadoop.hdfs.server.namenode.NameNode.addBlock(NameNode.java:418)
21933   at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source)
21934   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
21935   at java.lang.reflect.Method.invoke(Method.java:597)
21936   at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:452)
21937   at org.apache.hadoop.ipc.Server$Handler.run(Server.java:888)