Further reducing the failure number of FetchData request under high system load about rpc-frmwrk

[zhiming99]

commit 47a3d06 replaced the DBusLocalPdo with DBusLoopbackPdo2 between the user server and the built-in rpcrouter's CRpcReqForwarderProxy. The FetchData timeout issue is gone in the same test which used to have 50 occurances of FetchData timeout. The result is cheerful, and we can close this issue now

[zhiming99]

Test on another machine shows there are still some FetchData timeout occurance, but not as severe as before. We are still in good shape to close this issue. But there is another bug showing up...

[zhiming99]

when testing with auth-disabled, the FetchData timeout came back. I will add a temporary solution by setting a customized timeout value for FetchData request, so that the server can finally complete the FetchData request before the deadline.

[zhiming99]

one reason is that the connections are loopback connections, which means the large number of client processes are running on the same host, we should eliminate this interference for a real test.

[zhiming99]

commit cdc8ec8 fixed this issue #32 and issue #22 once for all. The cause turns out to be the terrible performance of timer service and the grand lock in object creation/destroy combined to make this issue significant. The fix has made it very easy to support a surge of 500 incoming connections without a single failure, and endured through the stress test afterwards.