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