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 <[email protected]
<mailto:[email protected]>> 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
[email protected]
https://www.virtualbox.org/mailman/listinfo/vbox-dev
