On Thu, Apr 21, 2016 at 02:16:02PM +0200, u-myfx_at_aetey.se wrote:
> We did not see any practical problems or extra stalls caused by
> synchronous DNS resolution. Definitely not an issue in our workloads.
> Of course nothing precludes changing to asynchronous resolution if
> needed but the effort and possible dependencies are hardly justified.

I am literally fuming reading this. I don't know if you remember, but
several years ago you had me chasing down a server 'deadlock' issue
related to callbacks, which I was unable to reproduce and I spend about
a week on this going back and forth with new patches trying to turn
readlocks into writelocks in the hope it would avoid some possible lock
ordering issue, adding global timeouts to the callback break multirpc
calls and other workarounds....

You were running your servers with clients that were doing ******
synchronous DNS lookups? And you don't think that would be causing any
practival problems or extra stalls?

> If not otherwise, the presence of callbacks is much more of a concern.
> In a file system where clients go disconnected as a matter of normal
> operation, callbacks do not give much benefit, at the same time callback
> breaking _does_ cause stalls.

And on top of that you are blaming the callbacks for your woes.

Sorry, but I have to cool down before I can respond to any of the rest
of your email. In the mean time I'll be busy finding and reverting the
patch that introduced a global timeout for callback rpcs and any other
possible regressions that may have been introduced.

Jan