Daniel P. Berrange wrote:
On Mon, Sep 17, 2007 at 03:49:37PM +0100, Richard W.M. Jones wrote:Daniel Veillard wrote:Is there a configuration knob in the RPC layer to lower the timeout delay ? Some calls are slow, but we should not reach a 2mn timeout, that's very very long I think.Migrations might take some time.In any case the RPC code just does 'sendto' followed by 'recvfrom'. There is no timeout to adjust on the client side.Shuveb's problem is that TCP doesn't gracefully handle the case where the ethernet cable is pulled out. There may be a socket option which helps for this.That depends on your definition of graceful. Shuveb's definition is that he wants the connection to fail & give an error back to the app. My definition is that TCP should keep retrying until I plug the cable back in, so I don't get unneccessary failures if i'm just switching cables around. Likewise if there's temporary outages anywhere else in the link between the client & server.
Yes actually I agree with you on that one. On the other hand there is no way for Shuveb to set TCP socket options on the socket other than making a private copy of the libvirt code and hacking it. So a patch to add yet another query string flag to the remote URI or to expose the remote socket somehow might be acceptable.
Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list