[vbox-dev] deleteConfig in VirtualBox 4.3.x

[Klaus Espenlaub]

John,

please stay on the mailing list. This is a public service, if you want 
personal support I have to ask for your Oracle customer support 
identifier...

On 05.03.2014 20:16, john alexander sanabria ordonez wrote:
> Hi Klaus,
>
> I read the documentation but (from my experience) it does not behave 
> as I was expecting. For instance, I do understand that the 
> deleteConfig method does not reach the 100 percent if there is an 
> error but why the library does not throw an exception informing about 
> it. In addition, why if the previous method (delete) works with no 
> errors this time "deleteConfig" will generate any error?
The asynchronous part of the deletion might fail (and that's exactly the 
same as in older versions, just the method name has been changed), and 
your code will simply hang as it doesn't properly check for completion. 
Failed async operations usually will never reach 100% - why should they, 
they failed before.

These failures will NOT cause exceptions from the progress object method 
calls, you have to check for them explicitly. It's been always like 
that, and there's lots of sample code out there which shows how to do 
this properly.
> About the wait, this is the actual code
>
>                         out << "To delete "
>                         mediums.each {
>                                 out << it.name <http://it.name> + " "
>                         }
>                         def iprogress = machine.delete(mediums)
>                         out << "\nDeleting "
>                         while (iprogress.percent != 100) {
Do not check for 100%, check if iprogress.getCompletion returns non-zero 
(dunno if the true/false stuff makes it all the way to Groovy).
>                                 out << "."
>                                 out.flush()
>                                 Thread.sleep(500)
Again, you're ignoring that you should wait using the method from the 
progress object, iprogress.waitForCompletion(500) as this gives the API 
middleware the opportunity to run its event queues and so on.

PLEASE have a look at the Java sample (TestVBox.java), it contains many 
useful code sequences which are verified to be sensible (not that all of 
them go into extreme error checking, but at least do the bare minimum 
necessary to avoid hangs).

Klaus
>                         }
> John,
>
>
>
> On 4 March 2014 13:55, Klaus Espenlaub <klaus.espenlaub at oracle.com 
> <mailto:klaus.espenlaub at oracle.com>> wrote:
>
>     Hi,
>
>     On 04.03.2014 14:44, john alexander sanabria ordonez wrote:
>     > Hi,
>     >
>     > I wrote a Groovy script to use the Java binding to manage virtual
>     > machines through the VirtualBox web service interface. My script
>     worked
>     > well in VirtualBox 4.2.x but when I updated to version 4.3 I
>     noted that
>     > my unregistervm procedure does not work. First, the IMachine.delete
>     > method was not available and it was changed by IMachine.deleteConfig
>     > which basically works similarly to the delete method. I made the
>     > corresponding modifications however it does not delete the mediums
>     > returned by the IMachine.unregister method.
>
>     This is documented in the SDK reference, for the API changes in 4.3.
>     >
>     > My unregistervm methods looks similar to this
>     >
>     > def mediums =
>     machine.unregister(CleanupMode.DetachAllReturnHardDisksOnly)
>     > def iprogress = machine.deleteConfig(mediums)
>     > while (iprogress.percent < 100) {
>     >    out << "."
>     > }
>     >
>     > and it never ends because the iprogress.percent never reaches 100.
>     >
>     > What I am doing wrong? Thanks for your help.
>
>     The percentage will never reach 100 if there is any error. You
>     should be
>     adding more flexible progress checking (there should be enough working
>     samples out there, including the Java sample code). What you have is
>     asking for hangs. Also, you should at least have some wait for
>     completion (if you prefer with very low timeout), as otherwise you're
>     simply burning CPU cycles.
>
>     Klaus
>
>     >
>     > John,
>     > 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20140306/417f7b78/attachment.html>