Here is the "big" memory leak that I found. The cvs at source forge is not
currently functional, so I will just put the code here. Is there anyone
"leading" interclient development? What should I do with my fix?

The statement is allcoated in the call to executeUpdateStatement. The
pointer is on the stack and never stored anywhere else. The code never
deleted the statement.

OLD_CODE:
void
JIBSRemote::execute_update_statement ()
{
IB_Statement *statement;
IB_STRING cursorName;
IB_STRING sql;
IB_SSHORT16 timeout;
IB_SSHORT16 maxFieldSize;
IB_SLONG32 fetchSize;

getStatementExecuteData (statement,
cursorName,
sql,
timeout,
maxFieldSize,
fetchSize);

IB_SLONG32 updateCount;
session_.executeUpdateStatement (statement,
updateCount,
sql,
(IB_SLONG32) timeout,
maxFieldSize,
cursorName);

jibsNet_.resetMessage ();
jibsNet_.put_code (MessageCodes::SUCCESS);
jibsNet_.put_ref ((IB_REF) statement);
jibsNet_.put_slong32 (updateCount);
}



NEW_CODE:
void
JIBSRemote::execute_update_statement ()
{
IB_Statement *statement;
IB_STRING cursorName;
IB_STRING sql;
IB_SSHORT16 timeout;
IB_SSHORT16 maxFieldSize;
IB_SLONG32 fetchSize;

getStatementExecuteData (statement,
cursorName,
sql,
timeout,
maxFieldSize,
fetchSize);

IB_SLONG32 updateCount;
session_.executeUpdateStatement (statement,
updateCount,
sql,
(IB_SLONG32) timeout,
maxFieldSize,
cursorName);

jibsNet_.resetMessage ();
jibsNet_.put_code (MessageCodes::SUCCESS);
jibsNet_.put_ref ((IB_REF) statement);
jibsNet_.put_slong32 (updateCount);

delete statement;
}

-----Original Message-----
From: Ken Richard [mailto:kenr@...]
Sent: Monday, September 18, 2000 7:34 AM
To: IB-Java@egroups.com
Subject: RE: [IB-Java] runaway process



I would never create statements in a tight loop, but I would keep a database
connection around for a long time inside a pool that is available to the web
server. Perhaps this is not a good simulation, but I still think that the
interserver should release the memory. And yes, I am sure that
interserver.exe is using memory.

Looking at the interserver.exe code, I have already found at least one
memory leak. I am not setup to compile interserver, so I can't fire up the
debugger to see if the leak I found is large enough to cause the problem.

Also - what is the cvs command line parameter to checkout the interclient
1.6?


-----Original Message-----
From: Helen Borrie [mailto:helebor@...]
Sent: Friday, September 15, 2000 11:34 PM
To: IB-Java@egroups.com
Subject: RE: [IB-Java] runaway process



At 02:05 PM 15-09-00 -0400, you wrote:

>I unsuccessfully tried to recreate the problem. However, I did notice that
>interserver.exe seems to use a lot of memory when there are a large number
>of sql statements executed on a connection.
>
>The following code makes interserver.exe go to 31MB ram (according to win2k
>task manager). The memory is released when the connection is closed and

the

>interserver.exe process ends.
>for i = 1 to 10000 {
> create statement
> statement.execute sql
> close statement
>}

In practice, you would never do this. You would set up the statement
first, start a transaction, prepare the statement, go into your loop,
iterate right through the loop and commit the transaction at the end. The
effect of doing what the above code describes is to make the gap between
the OAT (oldest active transaction) and the current transaction ever
wider. That is what eats CPU time.

>I was going to use interbase as the backend for a servlet web system - and
>implement a simple connection pooling class. This makes it look like only
>one statement should be created per connection - and the statement should

be

>cached in the pool with the connection. It looks like the statement memory
>is never getting cleaned up in interserver.exe.

Are you sure that it is interserver that is eating the resources? It looks
more like a problem of garbage accumulation in the database server. Having
thousands of uncommitted transactions sitting inside this looping process
completely prevents garbage collection.

As a rule of thumb, if you have an OAT gap which is greater than twice the
number of connections, you really need to take a serious look at the
architecture of your application...

Helen

All for Open and Open for All
InterBase Developer Initiative · http://www.interbase2000.org
___________________________________________________
Project JEDI · http://delphi-jedi.org
___________________________________________________

To unsubscribe from this group, send an email to:
IB-Java-unsubscribe@egroups.com





To unsubscribe from this group, send an email to:
IB-Java-unsubscribe@egroups.com