× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi Matt,

Thanks for your response...

<snip>
It sounds like a resource leak to me. You need to check to make sure that
you're cleaning up objects used by the transformer and parser classes. I
don't know if this is an issue or not but it sure sounds like it.
</snip>

As far as I'm aware, I only need to free objects created directly by the RPG
program. I assume that all objects created internally within java will be
garbage collected automatically once they are eligible (no non-circular
references). As it stands, I am freeing all objects created by RPG-to-Java
calls: I would class (no pun intended) a java object to be deemed created
via a RPG-to-Java call as any object returned to my RPG program from a *JAVA
procedure call. I would assume it is simply this reference that is being
freed - not the object itself (as it could be referenced by another object
within java).

I free all of the intermediary objects I create to get my transformer, but I
do not (and can not) free any objects created within java when I use the
transformer. So, I'm assuming that is all OK.
  
<snip>
You should also make sure that jt400ntv.jar is in your classpath since it
has hooks into native (read that as faster) ways of accessing certain
things.
</snip>

I did this, and it DID make a noticeable difference. I'm going to run some
bench tests to see exactly how much difference it made, but it did seem to
run quicker. Thanks.

One point of note on this: Once you gave me the heads-up on this I had a
look around and I discovered a IBM document on the jt400ntv.jar file - it
has changed in V5. I've enclosed the doc at the foot of this mail, but it
basically says that we should now be using jt400Native.jar in place of
jt400.jar AND jt400ntv.jar. I replaced jt400.jar with jt400Native.jar during
my tests as I'm running a 1.4.2 JVM on a V5R2M0 iSeries - it worked very
well.

I'm starting to think that too-frequent garbage collection may be causing
the eventual slowdown, but I can't find ANY documentation on what inputOpts
I can set when I start the JVM via JNI. I've read all of chapter 11 in the
RPG programmers guide, but it doesn't give a list of options. I know I can
set poolsize, but I'm not sure what a safe/reasonable size is. I'm not even
sure if this is what I want. I'd like to allocate a large enough amount of
memory to stop garbage collection kicking in too often, but I don't want to
hog resources.

I'm going to look into creating a custom class that I simply instantiate via
a RPG-to-Java call - I'll get this to create the transformer and
StreamResult objects. I can then simply create a method that takes a byte
array, and I'll create the StreamSource object within java. That way I'll
only have one object referenced within my RPG program - my custom class.
This object will never be cleaned up as long as the job runs. This should
run quicker (I think).

Again, thanks for your response. Any further thoughts on this would be most
welcome.

Larry Ducie

<IBM doc>
Document Title 
Version 5 Classpath Changes for Native Optimizations

Document Description
IBM Toolbox for Java includes a set of classes that enable special functions
when run on an iSeries JVM. These classes are referred to as the native
optimizations. In R450 and earlier, the native optimizations were packaged
in the file /qibm/proddata/Java400/jt400ntv.jar. Applications typically
specified a classpath that included:
"/qibm/proddata/Java400/jt400ntv.jar:/QIBM/ProdData/HTTP/Public/jt400/lib/jt
400.jar". 

Starting with OS/400 R510, the preferred method to use the native
optimizations is to include only
/QIBM/ProdData/OS400/jt400/lib/jt400Native.jar in the classpath (jt400.jar
should not be included with jt400Native.jar). Although jt400ntv.jar is no
longer documented, it can still be used. To allow older applications to
continue to function on R510 and later systems,
/qibm/proddata/Java400/jt400ntv.jar is created as symbolic link to
/QIBM/ProdData/OS400/jt400/lib/jt400Native11x.jar. 

The Version 4 jt400ntv.jar should not be copied or restored to a R510
system. If it is, the application will encounter usual exceptions. One such
error is a ClassNotFoundException for class
/com/ibm/as400/system/UnixSocketUser.class. In Version 5 this class is in
/com/ibm/as400/access. 

The file /QIBM/ProdData/OS400/jt400/lib/jt400Native.jar includes all classes
in jt400.jar and the native optimizations. Use the following jar file when
an application runs on the iSeries. jt400Native.jar ships with IBMR OS/400R
or IBMR i5/OS(tm).

The file /QIBM/ProdData/OS400/jt400/lib/jt400Native11x.jar contains only the
native optimizations. If you are running on the iSeries JVM and want to use
jt400.jar, include jt400Native11x.jar in your CLASSPATH rather than
jt400Native.jar. jt400Native11x.jar ships with OS/400 or i5/OS and resides
in directory /QIBM/ProdData/OS400/jt400/lib.
</IBM doc>


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.