We learn something everyday, the beauty of coding ! Thank you again.
On 8 August 2013 12:08, Klaus Espenlaub <[email protected]> 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 <[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
