[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-API] Java API

  • To: <xen-api@xxxxxxxxxxxxxxxxxxx>
  • From: "Alan Greenspan" <agreenspan@xxxxxxxxxxxxxxxxxxxxxxxx>
  • Date: Tue, 5 Jun 2007 12:04:40 -0400
  • Delivery-date: Tue, 05 Jun 2007 09:02:44 -0700
  • List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>
  • Thread-index: AcenizkIFHzTypBGRbyc+n/K0HyzJA==
  • Thread-topic: Java API



Client threading:

I could be reading this incorrectly but the API seems to have a per-thread connection requirement which is unusual.  This is evidenced by the use of a ThreadLocal to maintain the URL/Session and that EVERY API throws ConnectionHelper.NoConnectionOnThisThreadException.   So if threading is used on the client (Swing App) and the Xen objects ever float between threads, issues are going to arise.


Number of Xen servers a client can connect to:

There is no obvious way for a client to connect to more than one Xen server.   This seems to be tied up with the threading issue.   There are other issues lurking here as well that relate to this – for example, the various SoftReference caches are keyed by Object referenced ids which are not guaranteed to be unique amongst a set of XenServers.


I think a preferable approach would be to make each Xen Object (VM, host, etc) explicitly retain a reference to the session that was used to create it (passed in via the constructor).    A session to XmlRpcClient mapping would be used to carry out API calls to the appropriate server.    Then all the threading and single server issues go away.



The various Record.toMap() APIs appear to return Maps of Strings to Java Objects (sometimes these are collections of the various Xen Objects, e.g. a Map returned by VM.Record.toMap contains “VIFs” -> Set<VIF>.   It would appear that these Maps could not be used as parameters to create calls since they don’t contain XML primitives as values.   Ultimately the marshalling code would resolve the values via toString, but no toString conversions to refids are provided.


The Java classes are in com.xensource.xenapi.   Is this an appropriate package given that the API was developed outside of Xensource and not supported by XenSource?   If the API was developed at the University of Cambridge, I would expect the code to be in a university specific package.



Alan Greenspan
System Architect

Marathon Technologies Corp.
295 Foster Street
Littleton, MA 01460
(v) 978.489.1168  (f) 978.489.1101


xen-api mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.