My Appserver Application is probably leaking memory very fast and I don't understand why - Forum - OpenEdge General - Progress Community

My Appserver Application is probably leaking memory very fast and I don't understand why

 Forum

My Appserver Application is probably leaking memory very fast and I don't understand why

  • After a few moments of heavy use using two servers the _proapsv.exe processes begin to consume an exobanant amount of memory (400MB each) and have a very large DBI file (800mb each) I'm going through the handles of each file that gets run with DynObjects.*:4 in the entry types, here are my findings:

    File 1

    5 handles

    1. Dataset, does not get cleaned up, gets returned by the .p

    2. Buffer, gets cleaned up properly

    3. Temp-Table, does not get cleaned up, gets added to 1

    4. Buffer, does not get cleaned up, is recieved from 1

    5. Query, gets cleaned up properly

    File 2

    4 handles

    1. Dataset, does not get cleaned up, gets returned by the .p

    2. Buffer, gets cleaned up properly

    3. Temp-Table, does not get cleaned up, gets added to 1

    4. Buffer, does not get cleaned up, is recieved from 1

    File 3

    14 handles

    1,2,3 Implicit Buffer, does not get cleaned up

    4,5    Query, gets cleaned up properly

    6,7    Dataset, does not get cleaned up, gets returned by the .p

    8       Buffer, gets cleaned up properly

    9       Implicit Buffer, gets cleaned up properly

    10     Temp-Table, does not get cleaned up, gets added to 6

    11     Implicit Buffer, does not get cleaned up, points to 11

    12     Buffer, gets cleaned up properly

    13     Temp-Table, does not get cleaned up, gets added to 6

    14     Implicit Buffer, does not get cleaned up, points to 13

    The only handles I don't see getting cleaned up are the 1, 2 and 3 in file 3 which are created on line 0 and are Implicit and those which are returned by (or are associated with those that are returned by) the .p which, to my understanding, shouldn't be cleaned up as they would be invalid handles when the .p is returned. Where am I loosing the memory?

  • TABLE-HANDLE or DATASET-HANDLE parameters?

    Dynamic widgets? Like Query Handles, Buffers Object Handles, etc.?

  • The returned datasets are dataset handles passed through a DATASET-HANDLE parameter. File 3 also recives 3 dataset handles. There are no other handles or widgets used besides those listed in the op.

  • Do you DELETE OBJECT the dataset handle parameters in the called procedure? The AVM will postpone the deletion untill after the procedure has finished (and the DATASET-HANDLE parameter was returned to the client).

    Any sample code?

  • I don't DELETE OBJECT on any of the handles that are passed or the associated pieces, the problem is that the memory stays in use after the .p has returned and stays even when the app servers are idle.

  • That's pretty likely to be your problem...

    When you are having a

    DEFINE OUTPUT PARAMETER DATASET-HANDLE phDataset .

    You need to DELETE OBJECT phDataset. Details are in the online doc - either on the DEFINE PARAMETER statement or the parameter passing syntax

  • Do I also need to do a DELETE OBJECT on the temp-tables and buffers added to the dataset?

  • I'm looking in the OpenEdge Help file (which I assume is just a local copy of the online help) and I can't see reference of what you are talking about

  • Just add the DELETE OBJECT statements for your output dataset-handle parameters if you cannot find it in the docs.

    Or post sample code to illustrate your problem.

  • Do I also need to do a DELETE OBJECT on the temp-tables and buffers added to the dataset?

    Not when you didn't create additional buffers or tables.

  • But if I created it in the application, even if its returned, it needs a DELETE OBJECT? If I can find what you are talking about in the manual I'll act ojn this but I am still not conviced that this is correct

  • I don't want to just assume you are right when nothing in the docs says otherwise since, at least the way I see it, it would make sense that when you delete an object it is no longer there and would be null or invalid when it is returned.

  • Always.

  • I don't want to just assume you are right when nothing in the docs says otherwise since

    It's in the docs. You just didn't find it.

    at least the way I see it, it would make sense that when you delete an object it is no longer there and would be null or invalid when it is returned.

    As I wrote you earlier:

    The AVM will postpone the deletion untill after the procedure has finished (and the DATASET-HANDLE parameter was returned to the client).

    It doesn't need to assume logically. It needs to work, right?

    Can't help you anymore if you don't show any code.

  • Just had a very quick look into the notes of the DELETE OBJECT statement in the online docs:

    "When a temp-table object is passed as a TABLE-HANDLE output parameter, the deletion of the object following the DELETE OBJECT statement is postponed until the procedure goes out of scope. When the procedure returns, the TABLE-HANDLE is created, receives a copy of the original temp-table, and is then returned.

    The OUTPUT TABLE-HANDLE parameter creates a TEMP-TABLE in the target procedure, which is added to the SESSION widget-pool. You must use the DELETE OBJECT statement to delete this TEMP-TABLE when it is no longer needed, or you will create a memory leak."

    The same applies to DATASET-HANDLE parameters.

    OK?