On 02/18/2014 07:02 AM, Pasquale Dir wrote: > I am using the java api bindings. > > I'd like to set a connection timeout on the Connect class as sometimes it > takes just too long. Which particular API takes too long? There are some APIs like migration that take a long time, but where you can use another thread on the same connection object (or even a separate connection object) to track the status of it. Newer APIs such as block-pull were designed to start an asynchronous job and return immediately, where you can then track job status and/or abort the job early via separate API calls. We already need to enhance our job control APIs to support parallel jobs (qemu just added the concept of a block-backup for image fleecing, and there is some desire to be able to fleece images from multiple points in time which would require multiple jobs) - as part of enhancing job support there, we might also be able to enhance migration to have a asynchronous mode instead of blocking for the entire operation. We also want to add job control for various storage volume operations, which are currently long-running but can't be interrupted easily. Most APIs return as fast as possible after taking effect (although on a heavily loaded machine, that can take a while). Depending on the command, aborting early because of a timeout may actually be worse than using a different thread to track progress, unless the command is already associated with job control.

On 02/19/2014 04:06 AM, Daniel P. Berrange wrote: > FWIW, for the initial 'virConnectOpen' API I think it probably would > be worthwhile us supporting a standardized "timeout" URI parameter. > That way if the remote service doesn't respond at all for some > reason users can have fine control. That's a sufficiently targetted > use case that it'd be easy to do, compared to timeouts for arbitrary > APIs. Indeed - having a timeout on the initial connection attempt is much more useful than worrying about individual APIs when you have a responsive connection, since it is the indeterminate time of establishing a remote connection that may be the problem here. But does that mean yet another C API? We already have virConnectOpen{,ReadOnly,Auth}. Or are you envisioning this just in the language bindings (Java, python - but not C)?