WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-api

[Xen-API] Java API

To: <xen-api@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-API] Java API
From: "Alan Greenspan" <agreenspan@xxxxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 5 Jun 2007 12:04:40 -0400
Delivery-date: Tue, 05 Jun 2007 09:02:44 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-api-request@lists.xensource.com?subject=help>
List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>
List-post: <mailto:xen-api@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcenizkIFHzTypBGRbyc+n/K0HyzJA==
Thread-topic: Java API

Questions/concerns:

 

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.

 

Observations:

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
agreenspan@xxxxxxxxxxxxxxxxxxxxxxxx
www.marathontechnologies.com

 

_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-API] Java API, Alan Greenspan <=