Hi<div><br></div><div>The reason for this is to speed up DB access times and improve scalability. There are two types of queries:</div><div><br></div><div>1.- PoolInfos. This gives an overview (not all information about the object is returned) of the elements of the pool, it basically access the corresponding DB table. Also, OpenNebula caches part of the DB in memory, so the memory footprint of oned is under control, this means that if you need a VM that is not in the cache it is loaded from the DB, replacing another VM entry in the cache. PoolInfo methods do not modified the cache and goes to DB directly for the information (dump methods is a SELECT + xml formatting).</div>
<div><br></div><div>2.- Info. This gives extended information for a given object (in-memory). For example VM includes history (that is not returned in VMPoolInfo), VirtualNetworks includes leases and so on. (info methods is XML marshaling of a C++ class)</div>
<div><br></div><div>Those are the two main reasons: 1.- efficiency in DB access 2.- different information is returned.</div><div><br></div><div>Also there is a dump_extended for VMs. The reason here is to help schedulers in large-scale deployments. For example scheduling 15K VMs will require 1 pool info + 15K VMinfo method with the associated cache trashing. Dump extended performs a couple of joins in the DB tables so a scheduler can get all the needed information without overloading oned.</div>
<div><br></div><div>Hope now it is clearer ;) </div><div><br></div><div>Cheers</div><div><br></div><div>Ruben<br><br><div class="gmail_quote">On Mon, Oct 11, 2010 at 10:24 AM, Tiago Batista <span dir="ltr"><<a href="mailto:tiagosbatista@gmail.com">tiagosbatista@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Any insight on this from the original developers?<br>
<br>
I too looked at the source code, and this struck me as odd...<br>
<br>
TIA<br>
<font color="#888888"><br>
Tiago<br>
</font><div><div></div><div class="h5"><br>
On Fri, Oct 8, 2010 at 11:54 AM, Tiago Batista <<a href="mailto:tiagosbatista@gmail.com">tiagosbatista@gmail.com</a>> wrote:<br>
> Thanks,<br>
><br>
> This is my first JAXB experience, so looking at someone else's code<br>
> actually helped a lot on what I am doing...<br>
><br>
> I am mostly writing stylesheets for the rpc responses, so I am still<br>
> not at the point where I want to be, my current purpose with this is<br>
> to expose most or all of the functionality to a java experienced<br>
> programmer, removing as much of the opennebula specific parlance as<br>
> possible (notice that *Pool becomes a list() as an example).<br>
><br>
> As a test application, I am exposing the methods as a web service<br>
> (opennebula specific), something like a soap interface for the rpc...<br>
> If there is interest, I think I can release the full app (have to ask<br>
> my superiors)...<br>
><br>
> As for the rpc responses, I have found a few inconsistencies, mostly<br>
> between the *.info and the *<a href="http://pool.info" target="_blank">pool.info</a> methods that are slowing me down<br>
> a bit as I have to account for them... Is this expected behavior or a<br>
> bug?<br>
><br>
> As an example note the USERNAME:<br>
><br>
> <xs:complexType name="vmType"><br>
> <xs:sequence><br>
> <xs:element name="ID" type="xs:int" /><br>
> <xs:element name="UID" type="xs:int" /><br>
> <xs:element name="USERNAME" type="xs:string" minOccurs="0"<br>
> /> <!-- only on the pool --><br>
> <xs:element name="NAME" type="xs:string" /><br>
> <xs:element name="LAST_POLL" type="xs:unsignedLong" /><br>
> <xs:element name="STATE" type="xs:string" /><br>
> <xs:element name="LCM_STATE" type="xs:string" /><br>
> <xs:element name="STIME" type="xs:unsignedLong" /><br>
> <xs:element name="ETIME" type="xs:unsignedLong" /><br>
> <xs:element name="DEPLOY_ID" type="xs:string" /><br>
> <xs:element name="MEMORY" type="xs:unsignedLong" /><br>
> <xs:element name="CPU" type="xs:unsignedLong" /><br>
> <xs:element name="NET_TX" type="xs:unsignedLong" /><br>
> <xs:element name="NET_RX" type="xs:unsignedLong" /><br>
> <xs:element name="LAST_SEQ" type="xs:unsignedLong" /><br>
><br>
> <xs:element name="TEMPLATE" type="vmTemplateType" minOccurs="0"/><br>
> <xs:element name="HISTORY" type="vmHistoryType" minOccurs="0"/><br>
> </xs:sequence><br>
> </xs:complexType><br>
><br>
><br>
> The username appears only in the pool method, but not on the info<br>
> method... The same is valid for vnet methods if I recall.<br>
><br>
> Again, thanks for your input!<br>
><br>
> Tiago<br>
><br>
> On Thu, Oct 7, 2010 at 11:46 PM, <Carsten.Friedrich@csiro.au> wrote:<br>
>> Hi Tiago,<br>
>><br>
>><br>
>><br>
>> I did something similar some time ago (attached for your perusal, you need<br>
>> to add the JAXB libraries yourself). The binding of returned templates is a<br>
>> bit patchy, but it works well enough for me here. It supports most 2.0<br>
>> features.<br>
>><br>
>><br>
>><br>
>> Carsten<br>
>><br>
>><br>
>><br>
>> From: <a href="mailto:users-bounces@lists.opennebula.org">users-bounces@lists.opennebula.org</a><br>
>> [mailto:<a href="mailto:users-bounces@lists.opennebula.org">users-bounces@lists.opennebula.org</a>] On Behalf Of Tiago Batista<br>
>> Sent: Thursday, 7 October 2010 21:06<br>
>> To: <a href="mailto:Users@lists.opennebula.org">Users@lists.opennebula.org</a><br>
>> Subject: [one-users] Alternative java bindings<br>
>><br>
>><br>
>><br>
>> I am in the process of creating alternative java bindings for OpenNebula.<br>
>> (Dont ask and I wont tell why!)<br>
>><br>
>> They are now at a very embrionary state, and I would like to expose them a<br>
>> little. There are some parts that are specific to my setup, and a lot of<br>
>> refactoring is required but most of the code is automatically generated.<br>
>><br>
>> I use JAXB to bind the xmlrpc responses to POJOs, and I use a catchall class<br>
>> to perform the required operations on the server. A usage example:<br>
>><br>
>> Client client = new Client("username", "password",<br>
>> "<a href="http://hostname:2633/RPC2" target="_blank">http://hostname:2633/RPC2</a>");<br>
>> VMOperations vmOps = new VMOperations(client);<br>
>> VmType vm = vmOps.info(id);<br>
>><br>
>> This way, adding features is as simple as editing the apropriate xsd. By the<br>
>> way, extensions to the existing xsd, or new xsd files are welcome! With a<br>
>> little refactoring I think I can wrap the VmType that is read only on a<br>
>> class that allows some operations to be performed over it...<br>
>><br>
>> Also, this is better for environments where the data must be used across a<br>
>> network, as the classes (although not marked as such) should face no<br>
>> serialization problems. Even is none of the code seems useful, you should<br>
>> really consider replacing the standard Client class with a serializable one!<br>
>><br>
>> What do you think of this?<br>
><br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opennebula.org">Users@lists.opennebula.org</a><br>
<a href="http://lists.opennebula.org/listinfo.cgi/users-opennebula.org" target="_blank">http://lists.opennebula.org/listinfo.cgi/users-opennebula.org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Dr. Ruben Santiago Montero<br>Associate Professor (Profesor Titular), Complutense University of Madrid<br><br>URL: <a href="http://dsa-research.org/doku.php?id=people:ruben" target="_blank">http://dsa-research.org/doku.php?id=people:ruben</a><br>
Weblog: <a href="http://blog.dsa-research.org/?author=7" target="_blank">http://blog.dsa-research.org/?author=7</a><br>
</div>