<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi Max,<br>
    <br>
    <div class="moz-cite-prefix">On 07.08.2013 23:10, Maxime Dor wrote:<br>
    </div>
    <blockquote
cite="mid:CAMnjrBDZan60Dq6ypHc2JhiKBuzsS05DHjcHuez-ZtotZ1K5cA@mail.gmail.com"
      type="cite">
      <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 &amp; 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>
    </blockquote>
    <br>
    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),&nbsp; thus we
    had to invent our own clever scheme.<br>
    <br>
    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...<br>
    <br>
    Klaus<br>
    <br>
    <blockquote
cite="mid:CAMnjrBDZan60Dq6ypHc2JhiKBuzsS05DHjcHuez-ZtotZ1K5cA@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        <div>
          <div class="gmail_extra"><br>
            <div class="gmail_quote">On 7 August 2013 18:05, Klaus
              Espenlaub <span dir="ltr">&lt;<a moz-do-not-send="true"
                  href="mailto:klaus.espenlaub@oracle.com"
                  target="_blank">klaus.espenlaub@oracle.com</a>&gt;</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>
                  &gt; Hi Devs,<br>
                  &gt;<br>
                  &gt; After playing around with the Java WS API for a
                  while now, I would<br>
                  &gt; appreciate some clarification and confirmation on
                  some assumptions I am<br>
                  &gt; making for a while now. Here we go :<br>
                  &gt;<br>
                  &gt; When getting several ISession object accross the
                  code, I ended up<br>
                  &gt; realizing that these objects actually point to
                  the same session on the<br>
                  &gt; remote site. This also mean that I can only have
                  one VM locked at the<br>
                  &gt; same time.<br>
                  &gt; 1. Is this on purpose to only have one VM
                  lockable at the same time? Is<br>
                  &gt; this also the case in the XPCOM binding? Is it
                  possible to get a<br>
                  &gt; 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 moz-do-not-send="true"
                  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>
                  &gt; 2. Am I correct to understand that the only way
                  to get a lock on several<br>
                  &gt; machines at the same time is to have several
                  connections, each with its<br>
                  &gt; 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>
                  &gt; 3. Is there any recommended way (if even
                  possible) to get several locks<br>
                  &gt; 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>
                  &gt; ----------------------------------------<br>
                  &gt;<br>
                  &gt; Related to the objects living in on the remote
                  side. In the SDK<br>
                  &gt; documentation, we are informed that we are
                  supposed to use the<br>
                  &gt; releaseRemote() method on objects we get, so they
                  don't build up on the<br>
                  &gt; "other side", being the webservice server or the
                  XPCOM(?). While writing<br>
                  &gt; my code, the way I did at least, I am having a
                  hard time releasing the<br>
                  &gt; object at the proper time. Putting the
                  releaseRemote() a bit too<br>
                  &gt; defensively only ends up producing exception on
                  further calls (Object<br>
                  &gt; reference is not found...), meaning that the
                  actual remote object<br>
                  &gt; doesn't exist anymore. Obviously, since I
                  released it earlier. The fear<br>
                  &gt; 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>
                  &gt; 1. What is the actual build up rate? Is it
                  dangerous to keep these<br>
                  &gt; objets in memory on the other side? Could it
                  crash the webserver? The<br>
                  &gt; context would be a single java process connected
                  one time (possibly<br>
                  &gt; 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>
                  &gt; 2. If you use the findMachine() method several
                  times, using the same<br>
                  &gt; machine UUID, would you end up re-using the same
                  remote object or is a<br>
                  &gt; remote object created each time? If the remote
                  object is the same, I<br>
                  &gt; could live with the object residing in memory,
                  this can only make things<br>
                  &gt; 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>
                  &gt; 3. Is there a auto-release in Java code using the
                  finalize() method of<br>
                  &gt; 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>
                  &gt; 4. Any recommended way to deal with this? I am
                  thinking of using a<br>
                  &gt; helper tatic class to fetch the objects and a
                  timeout logic to release<br>
                  &gt; 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>
                  &gt;<br>
                  &gt; -----------------------------------------<br>
                  &gt;<br>
                  &gt; Thank you in advance for your time and wisdom on
                  this.<br>
                  &gt;<br>
                  &gt; Best regards,<br>
                  &gt; Max</div>
              </blockquote>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
  </body>
</html>