<div dir="ltr">Hi Klaus,<div><br></div><div>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.</div>

<div>I will give the multi-session a try ASAP and see if I can have this multi-lock heaven. Thank you!</div><div><br></div><div>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...</div>

<div>Again, thank you for the detailed & clear explaination. I'll dare to turn on the verbose log and see how it works.</div><div><br></div><div>Max<br></div><div><br></div><div>PS : so I don't die stupid, what does MOR stand for? Google doesn't give me interesting results...</div>

<div><br></div><div><div class="gmail_extra"><br><div class="gmail_quote">On 7 August 2013 18:05, Klaus Espenlaub <span dir="ltr"><<a href="mailto:klaus.espenlaub@oracle.com" target="_blank">klaus.espenlaub@oracle.com</a>></span> wrote:<br>

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