|
Hi Larry, I'm not a fan of RPG to Java calls. When interprocess communication is necessary, I normally use asynchronous messaging. It avoids a lot of overhead and typically improves throughput. In this case, if you were starting from scratch, I'd suggest all Java, primarily for the standards-based XML capabilities. Since you already have a ( working? ) set in RPG, in the interest of time I would probably use RPG for everything, with embedded SQL. It sounds as though you have a lot invested already. > > into SQL insert statements. These are then executed over > > the database on the iSeries. To do this I utilise the Java > > Native Interface (JNI) to create and use java objects. > > C) Run the whole process in java - I could execute the SQL using JDBC. > > (but would that just be even slower???) I don't understand these two statements taken together; aren't you using JDBC already? As of V5R2, if the program runs any length of time, runtime compilation is recommended over CRTJVAPGM. Joe Sam Joe Sam Shirah - http://www.conceptgo.com conceptGO - Consulting/Development/Outsourcing Java Filter Forum: http://www.ibm.com/developerworks/java/ Just the JDBC FAQs: http://www.jguru.com/faq/JDBC Going International? http://www.jguru.com/faq/I18N Que Java400? http://www.jguru.com/faq/Java400 ----- Original Message ----- From: "Aaron Bartell" <albartell@xxxxxxxxx> To: "Java Programming on and around the iSeries / AS400" <java400-l@xxxxxxxxxxxx> Sent: Wednesday, May 18, 2005 5:18 PM Subject: Re: Calling java from RPG - how to increase performance > Why do you even have RPG in the mix? Java has much better > capabilities in the realms of XML, XSLT, and SQL. I would reconsider > my architecture before I tried to get RPG to Java performance better. > Or just take RPG all the way through. > > > I have written a handful of RPG to Java pieces (ie > http://mowyourlawn.com/html/RPGMail.php) and each time I can never get > enterprise ready performance out of it. IMO, RPG to Java is not yet > ready for prime time. Java to RPG on the other hand performs quite > well (at least when you have the Java running in a more cached > environment than that of OS/400 - Tomcat for instance). > > Those are my thoughts, > Aaron Bartell > > On 5/18/05, Larry Ducie <Larry_Ducie@xxxxxxxxxxx> wrote: > > Hi chaps, > > > > I posted the following on the RPG forum and got a couple of responses, but I > > was advised to fire it at you chaps for more info. As a result of the > > responses on the RPG forum I'm now using jt400Native.jar instead of > > jt400.jar to get a little extra oomph, but I'm still not sure if I've set > > the JVM up with the right values to optimise my application - basically, I'm > > looking for some advice on what inputOpts I should set when starting the JVM > > using JNI. I'm not even sure what options there are! I'm even starting to > > question the idea of using JNI at all, as I'm not sure what overhead each > > RPG-to-Java call actually adds. It seems almost impossible to get any > > banchmarks for this stuff. Any help on this would be most welcome. > > > > Anyway, here's the post... > > > > Hi, > > > > I have written a RPG service program that transforms XML [using transform > > stylesheets (XSLT)] into SQL insert statements. These are then executed over > > the database on the iSeries. > > > > To do this I utilise the Java Native Interface (JNI) to create and use java > > objects. Basically, I create a transformer object. I then pass the object an > > XML stream source to transform, and a stream result to hold the transformed > > data. > > > > For each transformation (assuming the transformer object does not change) I > > have to create a new StreamSource object: > > > > To create the stream source object from RPG I have to perform the following > > steps: > > > > 1) Create a String object from the XML file path. (RPG-to-Java) > > 2) Create a File object from the String. (RPG-to-Java) > > 3) Free the String object - no longer needed. (RPG-to-Java) > > 4) Create a StreamSource object from the File object. (RPG-to-Java) > > 5) Free the File object - no longer needed. (RPG-to-Java) > > > > I create a StreamResult object for each job that runs this process, so I > > only perfrom the following once: > > > > 1) Create a String object from the result file path. (RPG-to-Java) > > 2) Create a File object from the String. (RPG-to-Java) > > 3) Free the String object - no longer needed. (RPG-to-Java) > > 4) Create a StreamResult object from the File object. (RPG-to-Java) > > 5) Free the File object - no longer needed. (RPG-to-Java) > > > > Now, this all works fine - I'm just not sure it's running as fast as it > > could be - approx 0.2 seconds for each transformation. After a few hundred > > transformations it seems to slow down - could this be the Garbage Collector? > > I start the JVM manually using JNI (with version 1.4.2 set). I also set the > > classpath manually (using putenv). The XML file path is retrieved from a > > data queue, and the result file path is created by the program. All RPG > > object references are freed one-at-a-time, not by pushing/popping the local > > frame. > > > > So, what are the best ways to speed things up??? > > > > I've considered the following: > > A) Create a custom java class that performs the conversions from file path > > to StreamSource/StreamResult and just call it with the two byte arrays. > > B) Allocate more memory to the JVM - what's the best size? What's the > > default size? > > C) Run the whole process in java - I could execute the SQL using JDBC. (but > > would that just be even slower???) > > D) I've not compiled the XML jar files (Xerces.jar, Xalan.jar, etc) because > > I believe the JIT compilers are better than CRTJVAPGM. Is this true? > > E) I've not copied and compiled jt400.jar to put in my classpath - should I > > need to? > > > > Basically, does the JNI carry a large overhead? Should I minimise the number > > of RPG-to-Java calls by writing a custom class? Should I optimise the java > > environment by allocating memory or compiling objects? I need your wise > > words. > > > > The program source is available if it helps. (We're running at V5R2M0) > > > > Thanks > > > > Larry Ducie > > --
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.