Consumability of vdsm via libvdsm.so

[Yair Zaslavsky]

On 08/14/2012 05:09 PM, Adam Litke wrote:
> On Mon, Aug 13, 2012 at 04:54:18PM -0400, Ayal Baron wrote:
>>
>>
>> ----- Original Message -----
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Yaniv Kaul" <ykaul at redhat.com>
>>>> To: "Adam Litke" <agl at us.ibm.com>
>>>> Cc: arch at ovirt.org
>>>> Sent: Monday, August 13, 2012 11:49:21 AM
>>>> Subject: Re: Consumability of vdsm via libvdsm.so
>>>>
>>>>
>>>>
>>>> On 08/13/2012 06:21 PM, Adam Litke wrote:
>>>>
>>>>
>>>> Hi all,
>>>>
>>>> We just finished a lively discussion regarding the ongoing effort
>>>> to
>>>> stabilize
>>>> the vdsm API using a C library called libvdsm.  There are many
>>>> things
>>>> that need
>>>> discussion, but I would like to focus this thread on one in
>>>> particular:
>>>>
>>>> Can ovirt-engine consume libvdsm via JNI?
>>>>
>>>> libvdsm provides a full-featured C interface to the vdsm API using
>>>> GObject.
>>>> Java bindings are provided automatically by jGIR[1].  The library
>>>> communicates
>>>> with vdsmd using an internal transport which is not exposed to end
>>>> users
>>>> (including ovirt-engine).  I would like to learn from folks with
>>>> deep
>>>> Java
>>>> knowledge if this approach is workable.  What are the technical
>>>> challenges to
>>>> integrating in this way?  Please save discussion of AMQP and other
>>>> bindings for
>>>> other threads.
>>>>
>>>> Thanks!
>>>>
>>>> [1] https://live.gnome.org/JGIR
>>>> How mature/maintained is JGIR?
>>>> Last commit seems to be 2010-02-09.
>>>> The author is: Alexander Kurtakov <akurtako at redhat.com>
>>>> His status in our organizational chart:
>>>> Employee Type: Ex-employee
>>> It will need some work to get it up to par with the rest of the
>>> gobject generators
>>
>> It's been dead since 2009, that doesn't seem very promising (http://www.ohloh.net/p/java-gobject-introspection)
>>
>> It also states: "It also includes a custom GLib/GObject interface layer adapted from gstreamer-java." and looking at gstreamer-java yields: "An unofficial/alternative set of java bindings for the gstreamer multimedia framework"
>>
>> Again, doesn't look like something you want to base your API on.
>> Sounds to me like the 'free' java bindings come at a very high cost (bringing JGIR up to date and maintaining it).
>>
>> What are the alternatives?

Hi Adam,
Bare in mind that invoking JNI from Java EE violates Java EE spec.
In addition, if you have a bug at your library (i.e - you build some 
abstraction layer library above some C API in order to simplify calls 
that will be made from java code) - this bug may cause segmentation 
fault, which will cause your JVM to crash -> meaning your jboss 
application server will crash.
I know we only run the engine enterprise application on Jboss (although 
an application server can co-host several application servers - in this 
case, your penalty will be higher).
What I've seen in some enterprise application is a light java server 
serving an application server to invoke risky/native code.
You of course pay for the traffic between the application server and 
this "jni server" but at least you guarantee your application server 
does not crash.

These are my 2 cents on this subject

Yair


>
> There are two other alternatives (and one bad idea) that come to mind:
>
> 1.) Generate our own Java bindings to libvdsm.so during the vdsm build process.
>
> I prefer this option from an API cleanliness POV because the transport code
> would only be written once (in libvdsm.so).  This form of generation should be
> simple because we are just wrapping the library so it can be called via JNI.
>
>
> 2.) Generate a native Java "library" that is equivalent to libvdsm.so.
>
> This gets us into the business of libvirt-style bindings generation which I
> think is a mistake.  It opens the door to us maintaining parallel
> implementations of "libvdsm"s (one per language).
>
>
> -1.) Standardize the transport around JSON-RPC and make that the supported
> interface.
>
> I am only mentioning it because I am certain someone will bring it up.  I think
> it's a bad idea and it's off-topic for this particular thread anyway.
>