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@marathontechnologies.com
www.marathontechnologies.com <http://www.marathontechnologies.com/>
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@marathontechnologies.com
www.marathontechnologies.com <http://www.marathontechnologies.com/>
Attached Files:
-
image001.jpg (3.03 KB)