Zhitao Li

The draft implementation above will bring deadlock. All RPC threads are waiting for conditional variable, and no threads can handle that an issued request has finished and wakeup other threads...

Thanks for your reply. The draft above has deadlock bug and now we let FSAL to return ERR_FSAL_DELAY if there are too many inflight requests. The error code will be...

> It would be better to do something that blocks the client's IP stream. I agree with you that it would be better to add throttling mechanism in RPC layer.

I don't submit a patch because the initial design brings deadlock.

Thanks for your reply. I will look more at this enhancement in my spare time :)

The process has been restarted. I will use GDB next time :)

This issue may result from thread model of nfs-ganesha. If some "svc_" thread blocks, some important work may never be scheduled to be handled.

I quite agree with you and throttling mechanism is in need :)

This issue reappears in our environment. Nfs-ganesha doesn't respond to new connection events on port 2049. The `Recv-Q` of the connection is 129, meaning that the accept queue is full....

This is an occasional issue. The above patch doesn't change the monitoring in mdcache_handle.cc, so I think it will not work.