Do you set encryption variable to null after the encryption returned ?
You maybe need to create a method
void setEncryptionDataNull()
{
encryptiondata = null;
}
After encryptionData returned, then call the method to manual reset it
and GC will do normal thing.
If you want use RPG calling Java,sometimes still need to take care more
about pointer string. I don't know whyit's happend. Maybe iSeries JVM
still need to do memory usage enhanced. Sometimes if your RPGjava PGM
crashed, you could not get normal result under the crashed JVM session,
you need start another job to test the RPGJava. Does IBM know about
what's happend ? Very hard to debug for this condition which problems
drivened from JVM.
Best regards,
Vengoal
Brad Stone æå:
This is a weird one.
A customer is using my GETURI application to communicate
with a web service. This works fine.
They recently implemented an encryption application to
encrypt CC numbers.
The two applications are not used together at all. Except
for possibly being called one after another in the same
job, they do not interact or share data with each other.
When they call the encryption app alone, it works fine.
When they call GETURI, then call they encryption app it
works fine the first time. Any subsequent calls to the
encryption app returns bogus data only if they follow a
call to GETURI. But GETURI still funtions fine. This is
only if done in the same job.
Starting a new job (ie signing off, then signing back on)
will result in the same scenario. Call GETURI then
encryption app, works fine. call GETURI then the
encryption app again and bogus data is returnd from the
encryption application.
The encryption app is an ILE app that calls a Java method
using JNI. The ILE app and GETURI both run in the QILE
activation group.
We tested changing the AG of the encryption app and that
had no effect.
Is it possible that a Java app can have a memory leak
outside of the AG at the Job level? This is our first
guess before diving deeper into this. But, I'm not sure
how Java/JNI and AGs work on the iSeries.
Thanks!