Hi. I'll answer as best I can.
I did a bunch of Inline::Java work while integrating our j2ee apps
with a legacy distributed matching system written in perl. I'll share
some of my observations.
On May 17, 2007, at 10:19 AM, Ilya Sterin wrote:
Hi, we're currently looking into the possibility of integrating our
Java JPA backend with our mod_perl front end/business layer using
Inline::Java. I've been pretty successful testing various features
that are required and have been pretty happy so far, though I have a
few questions that I'm not really clear about, so I was hoping someone
can help me out here...
1. My understanding is that Inline::Java doesn't really serialize the
whole object graph and there are no features to allow it to say
serialize the graph before transmitting the Inline::Java object over
the wire, right? I understand that it's more of a proxy and each
method call and property access call is proxied over to the JVM. Is
this correct?
Its using the same basic stuff that RMI in java uses in the general
sense. The server code doesn't really implement the proxies and
serialization. It just implements the mechanism to keep track of
references/protocol to marshall stuff back and forth. I don't really
think of it as a server in the traditional sense. I think of it more
as a data marshalling gateway. But, thats probably the same thing
really.
2. With #1 in mind, I'm a bit concerned about the stability and
scalability of the Inline::Java server. Being that it's written from
scratch and no existing server was reused, is there a reason I should
be concerned about the scalability of this in a highly concurrent
environment? Is the server piece thread safe? I will be going over
the source code in the next few weeks, but wanted to get some input.
I'm using it in a very concurrent environment, however I'm not making
extensive use of threads. Rather, the cluster of servers runs many
processes that frequently connect back to a central service. That
said, I did stumble into a couple minor problems in older versions
with regard to concurrency. We seem to have worked that out in the
current releases. To be honest, I recommend java 1.5 just for the
fact that they fixed 'volatile' , etc.
3. With JNI being the more efficient deployment option, the concern
is how it functions in the mod_perl environment. With mod_perl 1 and
mpm each process would embed the JVM and it's heap within each apache
child process? This is of course not an option, since then we have to
worry about memory constraints as well as possible XA, though I can't
think of any current requirement of transactions spread across
multiple processes. Is there a way to only embed the JVM within the
parent process and possibly use IPC for communication? I'm not that
familiar with JNI and it's requirements, so I'm just ranting here.
I'm using JNI, but for you it would be a poor choice. You can't fork
a jvm so you can't preload it into apache. Further, as you already
figured out, JNI means that perl and java share the same process
space. That means 1 jvm per process. You'll quickly starve yourself
of memory. Inline::Java supports an option where it will listen on a
socket. Use this and have all the processes connect to the shared
jvm. That way you'll cut down on memory thrashing. There is a bit of
a hit, but if you're connected via the loopback interface the
performance 'hit' is made up for by not thrashing to death under
load. That and when you think about it, unless you're making calls to
a bunch of library code that is self contained, you're probably just
going to be making RMI calls through java anyhow.
4. We're using JSE 1.5. Is there any reason to believe that we'd run
into any problems? I saw in README that it should work for the most
part and it seems to work with JPA, annotations and generics, but I'd
like to get someone with some experience using it with JSE 1.5 to
comment a bit more.
We're using it with java 1.5 and ejb3 apps here. It is working.
However, the client code to talk to ejb's is pretty abstracted into a
set of perl classes. This way return types can be marshalled into
more perlish data structures and legacy code doesn't have to be
replaced wholesale.
Finally, whenever you cross the perl=>java language boundary you're
going to take a performance hit. Your data has to be translated back
and forth, etc. Minimize calls as much as possible. The more discrete
you can keep operations, the better off you'll be. That should come
as no surprise really, but RMI is expensive. Treat every java call
like you would RMI. Don't call in tight loops, etc.
I hope that helped a bit.
--
J.
