Jason, that definitelly helps, thanks. When you say minimize calls, as of course you would with any remote operations, though you have J2EE patterns like remote proxy, Transfer Objects, etc... I take it you're refering to just good all RMI practices, right? There is no way to say optimize Inline::Java to minimize the RMI invocations, since my understanding is that right now the remote interface is invoked on each method/field invocation?
Ilya On 5/17/07, Jason Stelzer <[EMAIL PROTECTED]> wrote:
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.
