[vbox-dev] API questions

Wed Aug 7 21:10:48 GMT 2013

Hi Klaus,

Thank you very much for the detailed explaination of the inner-working of
the session - I never understood it this way. Reading back the SDK after
your explaination, it sure makes perfect sense. Never understood it this
way before.
I will give the multi-session a try ASAP and see if I can have this
multi-lock heaven. Thank you!

About the objects, I am glad to hear the hard work has been done already. I
will therefore leverage the built-in timeout of objects in the vboxwebsrv
and not do it on my side. This will make things *a lot* easier...
Again, thank you for the detailed & clear explaination. I'll dare to turn
on the verbose log and see how it works.

Max

PS : so I don't die stupid, what does MOR stand for? Google doesn't give me
interesting results...

On 7 August 2013 18:05, Klaus Espenlaub <klaus.espenlaub at oracle.com> wrote:

> Hi Maxime,
>
> On 07.08.2013 17:07, Maxime Dor wrote:
> > Hi Devs,
> >
> > After playing around with the Java WS API for a while now, I would
> > appreciate some clarification and confirmation on some assumptions I am
> > making for a while now. Here we go :
> >
> > When getting several ISession object accross the code, I ended up
> > realizing that these objects actually point to the same session on the
> > remote site. This also mean that I can only have one VM locked at the
> > same time.
> > 1. Is this on purpose to only have one VM lockable at the same time? Is
> > this also the case in the XPCOM binding? Is it possible to get a
> > different session for each call of IVirtualbox::getSessionObject()
>
> Huh? I guess you mean IWebsessionManager::getSessionObject().
>
> There's actually documentation for how to get several sessions from the
> webservice, see
> https://www.virtualbox.org/sdkref/interface_i_session.html - and I
> really think the ISession documentation is where one would look for
> information how sessions are handled.
>
> Bottom line: every logon gives one session, and actually there's no
> relevant limit to the number of logons you can do.
>
> Yes, I agree this could be handled differently, but it's been like this
> since the webservice was useable. It is consistent and if we'd change
> this then the setup code for a client talking to a new VirtualBox
> version would have to be different, before the client has a chance to
> check the API version number. Not nice.
>
> Oh, and don't mix up logons and HTTP connections. The latter is quite
> meaningless to the webservice, some SOAP clients open a new connection
> for each and every request, others use keepalive (and vboxwebsrv by
> default closes connections after 100 requests, expecting the client to
> open a new one).
>
> > 2. Am I correct to understand that the only way to get a lock on several
> > machines at the same time is to have several connections, each with its
> > session? Or will this lead to issues?
>
> That's possible, but separate (HTTP) connections are not required to get
> multiple sessions. Separate connections are useful with multi-threaded
> clients as they eliminate the need to synchronize access to the
> connection by the threads.
>
> > 3. Is there any recommended way (if even possible) to get several locks
> > in a thread-safe way?
>
> Most SOAP/WSDL libraries don't handle the use of one connection by
> several threads too well, you definitely have to be careful and consult
> the documentation of the respective implementation.
>
> > ----------------------------------------
> >
> > Related to the objects living in on the remote side. In the SDK
> > documentation, we are informed that we are supposed to use the
> > releaseRemote() method on objects we get, so they don't build up on the
> > "other side", being the webservice server or the XPCOM(?). While writing
> > my code, the way I did at least, I am having a hard time releasing the
> > object at the proper time. Putting the releaseRemote() a bit too
> > defensively only ends up producing exception on further calls (Object
> > reference is not found...), meaning that the actual remote object
> > doesn't exist anymore. Obviously, since I released it earlier. The fear
> > is to release "too late" and leave such objects orphan of any control.
>
> Yes, releaseRemote() is very hard to use properly, if there's any chance
> of concurrent use by another thread (unless you're setting up the
> websession in each thread, then the MORs are not shared across threads).
> Don't worry about this too much, because...
>
> > 1. What is the actual build up rate? Is it dangerous to keep these
> > objets in memory on the other side? Could it crash the webserver? The
> > context would be a single java process connected one time (possibly
> > several times depending on your answer at the previous section).
>
> The build up rate depends on how many different MORs (which is
> approximately equal to the different objects in the API) are needed by
> the client.
>
> Even if you're never ever releasing anything, there's the expiration
> time-based garbage collector in vboxwebsrv. Its parameters are tuneable
> (see manual) when starting the webservice. By default, if a MOR is not
> used for 300 seconds, it will be thrown away, freeing the resources
> which might be behind it, doing all necessary cleanup.
>
> Generally, if you use the API in a straightforward way then there's no
> significant waste of memory, neither in vboxwebsrv nor in VBoxSVC if you
> never use releaseRemote.
>
> The most critical situations are obviously if a lot of time passes
> between the use of a MOR - you have to avoid this or increase the
> timeout parameter.
>
> > 2. If you use the findMachine() method several times, using the same
> > machine UUID, would you end up re-using the same remote object or is a
> > remote object created each time? If the remote object is the same, I
> > could live with the object residing in memory, this can only make things
> > faster at the cost of using memory. Am I right in this assumption?
>
> MORs are reused within one websession (which is actually the reason for
> the "problem" with releaseRemote you mentioned above), and that means no
> matter how often you get a reference to one object in the API, it will
> not need more memory or cleanup effort.
>
> > 3. Is there a auto-release in Java code using the finalize() method of
> > the object? or such cleanup must be done by the developper?
>
> No, there's no auto-release as such (because the client bindings doesn't
> know if a MOR is used somewhere else, too, and we agree that
> releaseRemote is unsafe except in a few very well defined cases), but
> the expiration will take care of the garbage.
>
> > 4. Any recommended way to deal with this? I am thinking of using a
> > helper tatic class to fetch the objects and a timeout logic to release
> > them. Some kind of cache really.
>
> That's exactly the strategy implemented in vboxwebsrv if you don't do
> anything :)
>
> If you're really curious what exactly is going on (warning: causes
> severe log bloat!), you can enable verbose mode of the webservice, and
> have a look what ~/.VirtualBox/vboxwebsrv.log says about MOR creation
> and the corresponding explicit or timeout based releases. Depending on
> how many API calls your client is making there can be fast log rotation
> (but the 10 last logs are kept by default, each either containing one
> day or 100MB of logs by default, everything relevant is tuneable).
>
>
> Hope this helps,
> Klaus
>
> >
> > -----------------------------------------
> >
> > Thank you in advance for your time and wisdom on this.
> >
> > Best regards,
> > Max
>
> _______________________________________________
> vbox-dev mailing list
> vbox-dev at virtualbox.org
> https://www.virtualbox.org/mailman/listinfo/vbox-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20130807/3c3b0d2a/attachment.html>