[libvirt] Is it possible to set a timeout to the Connection class?
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. Is there any way/workaround?
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.
Is there any way/workaround?
Without knowing your exact goal, it's hard to say. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On Tue, Feb 18, 2014 at 04:13:19PM -0700, Eric Blake wrote:
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.
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. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
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)? -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On Wed, Feb 19, 2014 at 07:54:54AM -0700, Eric Blake wrote:
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)?
I was actually thinking of (ab)using the URI for this eg qemu+tcp://somehost/system?timeout=60 Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Am 18.02.2014 15:02, schrieb Pasquale Dir:
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.
This depends on the driver you're using. If the connection is established over the network, you'd have to change the TCP connection timeout for your OS. (Other than that, libvirt does not provide a method to change this per connection AFAIK)
Is there any way/workaround?
Create your Connect object in another thread using a Future. Then, await the result of that future using a custom timeout. Claudio
participants (4)
-
Claudio Bley -
Daniel P. Berrange -
Eric Blake -
Pasquale Dir