Tim,
unfortunatly negativ.
the server is running as service, installed with the /nointeract installation switch. On the console of the server is no icon for edbsrvr present.
nevertheless i tried the "No User Interface" switch that you suggested: no change.

Also: With the commandline server the same memory consumption happens - and I wouldnt think that the command-line Server has a UI worth mentioning.
Since we didnt licence ElevateDB with sourcecode  I dont know what is happening when a session connects and disconnects, but I dont believe that it is just
"Windows-does-take-its-good-'ole-sweet-time-reclaiming" the memory

Peter Moser
sys.team software GmbH


"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:

Peter,

<< I tried the default wodgenerator with the same result: 4 k memory loss
per session. >>

Are you running with the server UI present ?  If so, then turn it off via
this .INI switch:

No User Interface = 1;

in the edbsrvr.ini file here:

C:\Documents and Settings\All Users\Application Data\Elevate
Software\ElevateDB Server

The issue is the list view being used for the interface.  It's not leaking
memory, but Windows does take its good 'ole sweet time reclaiming it.  You
can force it to reclaim the memory by minimizing the server UI, but that
doesn't really help for CGI applications.

I'm going to be separating out the server UI from the server itself shortly,
so this will cease to be an issue.  But, for now the No User Interface
switch does the same thing.

--
Tim Young
Elevate Software
www.elevatesoft.com

Peter,

<< unfortunatly negativ.
the server is running as service, installed with the /nointeract
installation switch. On the console of the server is no icon for edbsrvr
present. nevertheless i tried the "No User Interface" switch that you
suggested: no change. >>

My apologies - I just did the following test:

procedure TForm1.Button1Click(Sender: TObject);
var
  I: Integer;
begin
  for I:=1 to 1000 do
     begin
     EDBSession1.Connected:=False;
     EDBSession1.Connected:=True;
     end;
  EDBSession1.Connected:=False;
end;

And yes, the VM Size increases.  I did some further investigation, and there
is indeed an issue with two files being created by the configuration
database manager, that aren't freed until the internal virtual file system
is destroyed.  Thus, the memory accumulates, but it doesn't show up as an
actual leak when you shut down the server.  This, combined with the fact
that the memory increase was so small, was the part that was throwing me off
the trail.

A fix will be in B3.  Using the above test, previously the VM Size as 40
megs after 1000 connections, but is now the same as when it started - 8
megs.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,
happy to hear that you found the problem.  Thanks a lot!
For us still ElevateDBv1 users: shoudn't that be 1.09 build 5?
And: do you have a timeframe for the new build?

Peter

<< A fix will be in B3.  Using the above test, previously the VM Size as 40
<< megs after 1000 connections, but is now the same as when it started - 8
<< megs.

Peter,

<< happy to hear that you found the problem.  Thanks a lot! For us still
ElevateDBv1 users: shoudn't that be 1.09 build 5? And: do you have a
timeframe for the new build? >>

Well, V1 is definitely taking a back seat to V2.  There aren't any format
changes between the two, so we would prefer that customers upgrade and don't
intend to keep on with bug fixes for V1 for very long.  Anything after that
we will provide in the form of spot fixes, if the bug is serious enough.

However, I'll get a bug fix out for 1.09, it will just be later than V2 B3,
probably later next week around Friday.  Its a bit of a big switch in our
build system to switch from V2 to V1 and vice-versa, so it will take a
couple of days.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,
got the hint. We will upgrade to V2.
Hope the problem is serious enough to have a fix soon.
We urgently need it.  Thanks.

Peter
sys.team software GmbH


"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:
Peter,

<< Well, V1 is definitely taking a back seat to V2.  There aren't any format
<< changes between the two, so we would prefer that customers upgrade and don't
<< intend to keep on with bug fixes for V1 for very long.  Anything after that
<< we will provide in the form of spot fixes, if the bug is serious enough.


--
Tim Young
Elevate Software
www.elevatesoft.com

Peter,

<< got the hint. We will upgrade to V2. >>

Thanks, although you bought fairly recently, so I really wasn't referring to
you directly.

<< Hope the problem is serious enough to have a fix soon. We urgently need
it.  Thanks. >>

Yes, indeed.  Memory leaks always qualify as serious.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

We upgraded to V2: when can we expect build 3?
You had mentioned friday. Is this still valid?

I am a bit in trouble because I promised my customer to get it working by monday.
Right now we are restarting the Databaseserver every ten minutes...

Please, is there something you can offer us?!
Peter  

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:

Peter,


<< got the hint. We will upgrade to V2. >>

Thanks, although you bought fairly recently, so I really wasn't referring to
you directly.

<< Hope the problem is serious enough to have a fix soon. We urgently need
it.  Thanks. >>

Yes, indeed.  Memory leaks always qualify as serious.

--
Tim Young
Elevate Software
www.elevatesoft.com

Peter,

<< We upgraded to V2: when can we expect build 3?  You had mentioned friday.
Is this still valid? >>

My apologies.  We had a change of plans due to a bug found late last week
that is going to require a new minor release (2.01) instead due to a minor
version number increment.  This posed a bit of a delay because we had to
finish up the CF support for 2.01 before the release.  I should have the
2.01 release available in the next couple of days.

<< I am a bit in trouble because I promised my customer to get it working by
monday. Right now we are restarting the Databaseserver every ten minutes...

Please, is there something you can offer us?! >>

If you want, I can send you a V2 database server that fixes the issue.  Just
email me and I'll respond with the fixed server.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,
installed V2.01 B1:
No change.
With the example code you had given:
The server still consumes memory: 4120 kb per thousend opened and closed sessions.

I hope your next suggestion is not - after I upgraded to from V1 to V2 - that I should upgrade to V2 with source and look for the bug myself...

Peter


"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:

Peter,

<< unfortunatly negativ.
the server is running as service, installed with the /nointeract
installation switch. On the console of the server is no icon for edbsrvr
present. nevertheless i tried the "No User Interface" switch that you
suggested: no change. >>

My apologies - I just did the following test:

procedure TForm1.Button1Click(Sender: TObject);
var
  I: Integer;
begin
  for I:=1 to 1000 do
     begin
     EDBSession1.Connected:=False;
     EDBSession1.Connected:=True;
     end;
  EDBSession1.Connected:=False;
end;

And yes, the VM Size increases.  I did some further investigation, and there
is indeed an issue with two files being created by the configuration
database manager, that aren't freed until the internal virtual file system
is destroyed.  Thus, the memory accumulates, but it doesn't show up as an
actual leak when you shut down the server.  This, combined with the fact
that the memory increase was so small, was the part that was throwing me off
the trail.

A fix will be in B3.  Using the above test, previously the VM Size as 40
megs after 1000 connections, but is now the same as when it started - 8
megs.

--
Tim Young
Elevate Software
www.elevatesoft.com

Peter,

<< No change.
With the example code you had given:
The server still consumes memory: 4120 kb per thousend opened and closed
sessions. >>

It's a different issue, and I'm looking into it right now.

The issue that I fixed is definitely fixed (it's in our test framework), and
there is definitely a difference in the memory consumption with 2.01.
Previously with 2.00 B2, 1000 connects/disconnects would cause the memory to
hit 50-60 megs.  It's still going up, but at a much smaller rate.

I hope your next suggestion is not - after I upgraded to from V1 to V2 -
that I should upgrade to V2 with source and look for the bug myself... >>

What is the purpose of this comment, exactly ?  Have we ever responded to
you in a fashion that would warrant this type of comment ?  We treat you
with prompt and respectful answers, and we expect the same in return.
Implying that we would even consider giving you such a response is
completely dishonest.  Never in our 10 years of doing business have we ever
told someone to get the source code and find the bug for themselves.

And for the record, I did not tell you that you had to upgrade from V1 to V2
to get a fix for this.  What I said was that 2.x is getting priority for
fixes ahead of 1.x.  I am still going to issue a 1.x update to fix this
issue with 1.x, as I indicated in my response to you.

--
Tim Young
Elevate Software
www.elevatesoft.com