Re: RPG/Java memory leaks? Possible?

Or would it be better to compile the ILE module calling the
Java application with this?

On Tue, 12 Apr 2005 17:47:27 -0500
 "Bob Cozzi" <cozzi@xxxxxxxxx> wrote:
> Try recompiling your GETURI with the following keyword on
> your header
> specification and see if it makes a difference>
> H THREAD(*SERIALIZE) 
> 
> 
> -Bob Cozzi
> www.RPGxTools.com
> If everything is under control, you are going too slow.
> - Mario Andretti
> 
> 
> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx
> [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
> On Behalf Of Brad Stone
> Sent: Tuesday, April 12, 2005 5:39 PM
> To: RPG programming on the AS400 / iSeries
> Subject: Re: RPG/Java memory leaks? Possible?
> 
> I've ruled out my application for now as it doesn't alloc
> or use any pointers except for those required by APIs
> (get
> host name, etc....)
> 
> All variables are defined as DSs or standalone fields.
> 
> I imagine the first time the encryption program works
> because it creates a new JVM and everything is "fresh".
>  But on the subsequent calls I believe it may be doing
> something wrong (either at the JVM level or within the
> app)
> that is causing corrupt data.  
> 
> You'd think if it were initializing everything on every
> call that memory leaks wouldn't be an issue, as each time
> the memory in question would simply be reinitialized.
> 
> On Tue, 12 Apr 2005 17:31:35 -0500
>  "Bob Cozzi" <cozzi@xxxxxxxxx> wrote:
> > Hi Brad,
> > I don't know how your RPG GETURI program works, but I
> > would suspect that
> > either it or the encryption program (do they have the
> > source for it?) has
> > the memory leak. 
> > A assume you know the consequences of memory leaks so I
> > won't go on, but
> > check the RPG GetUri program. It may use ALLOC without
> a
> > corresponding
> > DeAlloc, or even worse, it may be using a based
> variable
> > that is based on a
> > parameter that is a different size than the based
> > variable--this could be
> > why it works the first time.
> > 
> > 
> 
> -Bob Cozzi
> > www.RPGxTools.com
> > If everything is under control, you are going too slow.
> > - Mario Andretti
> > 
> > 
> > -----Original Message-----
> > From: rpg400-l-bounces@xxxxxxxxxxxx
> > [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
> > On Behalf Of Brad Stone
> > Sent: Tuesday, April 12, 2005 4:49 PM
> > To: RPG programming on the AS400 / iSeries
> > Subject: RPG/Java memory leaks? Possible?
> > 
> > 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!
> > -- 
> > This is the RPG programming on the AS400 / iSeries
> > (RPG400-L) mailing list
> > To post a message email: RPG400-L@xxxxxxxxxxxx
> > To subscribe, unsubscribe, or change list options,
> > visit:
> > http://lists.midrange.com/mailman/listinfo/rpg400-l
> > or email: RPG400-L-request@xxxxxxxxxxxx
> > Before posting, please take a moment to review the
> > archives
> > at http://archive.midrange.com/rpg400-l.
> > 
> > 
> > 
> > 
> > -- 
> > This is the RPG programming on the AS400 / iSeries
> > (RPG400-L) mailing list
> > To post a message email: RPG400-L@xxxxxxxxxxxx
> > To subscribe, unsubscribe, or change list options,
> > visit:
> > http://lists.midrange.com/mailman/listinfo/rpg400-l
> > or email: RPG400-L-request@xxxxxxxxxxxx
> > Before posting, please take a moment to review the
> > archives
> > at http://archive.midrange.com/rpg400-l.
> > 
> 
> Bradley V. Stone
> BVS.Tools
> www.bvstools.com
> -- 
> This is the RPG programming on the AS400 / iSeries
> (RPG400-L) mailing list
> To post a message email: RPG400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit:
> http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the
> archives
> at http://archive.midrange.com/rpg400-l.
> 
> 
> 
> 
> -- 
> This is the RPG programming on the AS400 / iSeries
> (RPG400-L) mailing list
> To post a message email: RPG400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit:
> http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the
> archives
> at http://archive.midrange.com/rpg400-l.
> 

Bradley V. Stone
BVS.Tools
www.bvstools.com