Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 9 of 9 total
Thread ElevateDB Error #9999 Handle objects container capacity (2048) exceeded
Wed, May 4 2022 12:44 PMPermanent Link

Javierus

CYBER Informatica Avanzada, S.L.

I'm quite sure it's a resource leak, 'cause it happens when the application has been running a bunch of hours

Is there any way I can get the number of handles in use at a given moment? a property or value somewhere?

Thanks in advance
Wed, May 4 2022 1:42 PMPermanent Link

Jose Eduardo Helminsky

HPro Informatica

Javierus wrote:

<<
I'm quite sure it's a resource leak, 'cause it happens when the application has been running a bunch of hours

Is there any way I can get the number of handles in use at a given moment? a property or value somewhere?
>>

Usually it is. I do not know how can you get the number of current handles but you have to search code where a dataset (table of query) is created (in runtime) and not destroyed.

var T: TEDBTable;
begin
   T := TEDBTable.Create(self);
   // configure T
   T.Open;
   // Use table T
end;

T is not freed and keep then handle active at server side. I hope you find the place where the situation happen.

Eduardo
Wed, May 4 2022 5:40 PMPermanent Link

Raul

Team Elevate Team Elevate

On 5/4/2022 12:44 PM, Javierus wrote:
> I'm quite sure it's a resource leak, 'cause it happens when the application has been running a bunch of hours
>
> Is there any way I can get the number of handles in use at a given moment? a property or value somewhere?

I would simply log all active sessions and datasets and see if anything
stands out that ought to be closed.

Use the engine Sessions property to get all sessions and for each
session you can list all Databases and for each one of those list all
DataSets (which would be actual queries and tables).

That should show anything open in the app and anything that is not closed.

Raul
Thu, May 5 2022 2:23 AMPermanent Link

Javierus

CYBER Informatica Avanzada, S.L.

Hi all,

I should have added that the application can be compiled to run with BDE and with ElevateDB, and with the BDE there are no memory leaks, so there are no TxxSession, TxxDatabase, TxxTable, or TxxQuery unfreed

Thet's why I was asking about how to get the EDB handle count at any given moment, so I could check it before and after some actions
Thu, May 5 2022 7:29 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Javierus


I just did a search of this newsgroup and found a number of posts about this issue. Every time the answer is leaving things (tables, queries, sessions) open so I suspect it will be the same here. My bet, without knowing your code would be threads not being closed or leaving things open.

Whilst there may be something in Tim's code to check for how many handles are on the go I don't know what it is but a quick google gave me

https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-getprocesshandlecount


However, something like:

procedure TForm1.Button1Click(Sender: TObject);
var
Cntr: integer;
SubCntr: integer;
begin
nlhTable1.Close;
if nlhEngine1.Active and nlhSession1.Connected then begin
 for Cntr := 0 to nlhSession1.DatabaseCount - 1 do begin
  showmessage(nlhSession1.Databases[Cntr].Name + ' ' + inttostr(nlhSession1.Databases[Cntr].DataSetCount));
 end;
end;
end;

using your session would give you what you want - I think. It shows how many datasets for a session are active.

Roy Lambert
Mon, May 9 2022 1:59 PMPermanent Link

Javierus

CYBER Informatica Avanzada, S.L.

Hi Roy,

Thanks for your interest, but I'm certain I'm not missing any dataset, database or session

My application was developed for BDE, and there is a unit that implements the TxxTable, TxxDatabase, TxxQuery and TxxSession so a compiler switch decides if it inherits from BDE or ElevateDB components

So the application itself knows zero and depends zero from BDE or ElevateDB components

Wich means, it opens exactly the same datasets with both engines

And with BDE it has zero memoty leaks; there are no Datasets lost anywhere
Tue, May 10 2022 2:22 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Javierus


I understand what you're saying but its worth remembering that BDE and ElevateDB are different and operate in different ways.

Can you produce a demo that causes the problem? If not its going on for impossible to provide any assistance other than to point out the culprit in previous occurrences.


Roy Lambert
Tue, May 10 2022 9:21 PMPermanent Link

Raul

Team Elevate Team Elevate

On 5/9/2022 1:59 PM, Javierus wrote:
> Thanks for your interest, but I'm certain I'm not missing any dataset, database or session
>
> My application was developed for BDE, and there is a unit that implements the TxxTable, TxxDatabase, TxxQuery and TxxSession so a compiler switch decides if it inherits from BDE or ElevateDB components
>
> So the application itself knows zero and depends zero from BDE or ElevateDB components
>
> Wich means, it opens exactly the same datasets with both engines
>
> And with BDE it has zero memoty leaks; there are no Datasets lost anywhere

It still looks like something is not being freed or closed in your code
properly - 2048 is the limit for open statements per session so in this
case start with query instances.

Raul
Fri, Aug 26 2022 6:24 AMPermanent Link

Javierus

CYBER Informatica Avanzada, S.L.

Fixed it; it was my fault, but it was not on the application code itself, but on a component
No tables or queries undestroyed

In case if someone is curious enough, I explain it (TL;DR)

First a complain:
it has been more difficult than it should have been due to the generic message: there are many resources handled by that Object Handles container class, so the only hint was the 2048 number, but more than half of those handle containers have that same limit: 2048

So first step was changing the constants to 2048+number, so I could get a more accurate hint
No luck: same message
Second step: added to the handle container object constructor a text tag (what it was used for)
Weirdly, the messages where still the same

So recompiled the server itself: Hit!
Seems the client gets the message from the server; now I got to know that it was a problem with SessionManager.Cursors

Easy peasy: it was a bug on my TEDBTable-derived component; it had overriden DestroyHandle, and was lacking a call to inherited DestroyHandle

Fixed and fine
Image