[vbox-dev] API questions

Thu Aug 8 12:47:25 GMT 2013

We learn something everyday, the beauty of coding !
Thank you again.

On 8 August 2013 12:08, Klaus Espenlaub <klaus.espenlaub at oracle.com> wrote:

>  Hi Max,
>
>
> On 07.08.2013 23:10, Maxime Dor wrote:
>
> 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...
>
>
> Hehe... seems we don't use this acronym anywhere in the API docs.
> MOR=managed object reference. SOAP/WSDL isn't really object oriented (it's
> belongs to the RPC family, and actually a rather simple minded one as
> there's no predefined way to represent references),  thus we had to invent
> our own clever scheme.
>
> You use the 'glue' Java webservice bindings, with the consequence that the
> MORs are actually not visible anywhere in your code, as there are
> abstracted away by the client side wrapper objects - with the
> releaseRemote() method doing a direct release of the underlying MOR. That's
> where they shine through slightly...
>
> Klaus
>
>
>
>
> 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/20130808/92d48002/attachment.html>