[one-users] Alternative java bindings
Ruben S. Montero
rubensm at dacya.ucm.es
Mon Oct 11 14:14:59 PDT 2010
Hi
The reason for this is to speed up DB access times and improve scalability.
There are two types of queries:
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).
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)
Those are the two main reasons: 1.- efficiency in DB access 2.- different
information is returned.
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.
Hope now it is clearer ;)
Cheers
Ruben
On Mon, Oct 11, 2010 at 10:24 AM, Tiago Batista <tiagosbatista at gmail.com>wrote:
> Any insight on this from the original developers?
>
> I too looked at the source code, and this struck me as odd...
>
> TIA
>
> Tiago
>
> On Fri, Oct 8, 2010 at 11:54 AM, Tiago Batista <tiagosbatista at gmail.com>
> wrote:
> > Thanks,
> >
> > This is my first JAXB experience, so looking at someone else's code
> > actually helped a lot on what I am doing...
> >
> > I am mostly writing stylesheets for the rpc responses, so I am still
> > not at the point where I want to be, my current purpose with this is
> > to expose most or all of the functionality to a java experienced
> > programmer, removing as much of the opennebula specific parlance as
> > possible (notice that *Pool becomes a list() as an example).
> >
> > As a test application, I am exposing the methods as a web service
> > (opennebula specific), something like a soap interface for the rpc...
> > If there is interest, I think I can release the full app (have to ask
> > my superiors)...
> >
> > As for the rpc responses, I have found a few inconsistencies, mostly
> > between the *.info and the *pool.info methods that are slowing me down
> > a bit as I have to account for them... Is this expected behavior or a
> > bug?
> >
> > As an example note the USERNAME:
> >
> > <xs:complexType name="vmType">
> > <xs:sequence>
> > <xs:element name="ID" type="xs:int" />
> > <xs:element name="UID" type="xs:int" />
> > <xs:element name="USERNAME" type="xs:string" minOccurs="0"
> > /> <!-- only on the pool -->
> > <xs:element name="NAME" type="xs:string" />
> > <xs:element name="LAST_POLL" type="xs:unsignedLong" />
> > <xs:element name="STATE" type="xs:string" />
> > <xs:element name="LCM_STATE" type="xs:string" />
> > <xs:element name="STIME" type="xs:unsignedLong" />
> > <xs:element name="ETIME" type="xs:unsignedLong" />
> > <xs:element name="DEPLOY_ID" type="xs:string" />
> > <xs:element name="MEMORY" type="xs:unsignedLong" />
> > <xs:element name="CPU" type="xs:unsignedLong" />
> > <xs:element name="NET_TX" type="xs:unsignedLong" />
> > <xs:element name="NET_RX" type="xs:unsignedLong" />
> > <xs:element name="LAST_SEQ" type="xs:unsignedLong" />
> >
> > <xs:element name="TEMPLATE" type="vmTemplateType"
> minOccurs="0"/>
> > <xs:element name="HISTORY" type="vmHistoryType"
> minOccurs="0"/>
> > </xs:sequence>
> > </xs:complexType>
> >
> >
> > The username appears only in the pool method, but not on the info
> > method... The same is valid for vnet methods if I recall.
> >
> > Again, thanks for your input!
> >
> > Tiago
> >
> > On Thu, Oct 7, 2010 at 11:46 PM, <Carsten.Friedrich at csiro.au> wrote:
> >> Hi Tiago,
> >>
> >>
> >>
> >> I did something similar some time ago (attached for your perusal, you
> need
> >> to add the JAXB libraries yourself). The binding of returned templates
> is a
> >> bit patchy, but it works well enough for me here. It supports most 2.0
> >> features.
> >>
> >>
> >>
> >> Carsten
> >>
> >>
> >>
> >> From: users-bounces at lists.opennebula.org
> >> [mailto:users-bounces at lists.opennebula.org] On Behalf Of Tiago Batista
> >> Sent: Thursday, 7 October 2010 21:06
> >> To: Users at lists.opennebula.org
> >> Subject: [one-users] Alternative java bindings
> >>
> >>
> >>
> >> I am in the process of creating alternative java bindings for
> OpenNebula.
> >> (Dont ask and I wont tell why!)
> >>
> >> They are now at a very embrionary state, and I would like to expose them
> a
> >> little. There are some parts that are specific to my setup, and a lot of
> >> refactoring is required but most of the code is automatically generated.
> >>
> >> I use JAXB to bind the xmlrpc responses to POJOs, and I use a catchall
> class
> >> to perform the required operations on the server. A usage example:
> >>
> >> Client client = new Client("username", "password",
> >> "http://hostname:2633/RPC2");
> >> VMOperations vmOps = new VMOperations(client);
> >> VmType vm = vmOps.info(id);
> >>
> >> This way, adding features is as simple as editing the apropriate xsd. By
> the
> >> way, extensions to the existing xsd, or new xsd files are welcome! With
> a
> >> little refactoring I think I can wrap the VmType that is read only on a
> >> class that allows some operations to be performed over it...
> >>
> >> Also, this is better for environments where the data must be used across
> a
> >> network, as the classes (although not marked as such) should face no
> >> serialization problems. Even is none of the code seems useful, you
> should
> >> really consider replacing the standard Client class with a serializable
> one!
> >>
> >> What do you think of this?
> >
> _______________________________________________
> Users mailing list
> Users at lists.opennebula.org
> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>
--
Dr. Ruben Santiago Montero
Associate Professor (Profesor Titular), Complutense University of Madrid
URL: http://dsa-research.org/doku.php?id=people:ruben
Weblog: http://blog.dsa-research.org/?author=7
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20101011/53436eeb/attachment-0003.htm>
More information about the Users
mailing list