Should I use DELETE WIDGET-POOL in an AppServer disconnect procedure? - Progress Community

Loading

Skip to Main Content

Should I use DELETE WIDGET-POOL in an AppServer disconnect procedure?

Can DELETE WIDGET-POOL be used in an AppServer disconnect procedure or shutdown procedure to clean up dynamic objects created during the AppServer agent session and avoid memory leaks?

Nov 4, 2016
Knowledge

Title

Should I use DELETE WIDGET-POOL in an AppServer disconnect procedure?

URL Name

should-i-use-delete-widget-pool-in-an-appserver-disconnect-procedure

Article Number

000179449

Environment

Product: OpenEdge Version: All supported versions OS: All supported platforms

Question/Problem Description

Can DELETE WIDGET-POOL be used in an AppServer disconnect procedure or shutdown procedure to clean up dynamic objects created during the AppServer agent session and avoid memory leaks?

What is the scope of DELETE WIDGET-POOL?

What is the scope of an unnamed widget pool?

Does DELETE WIDGET-POOL have any effect on objects in the session widget pool?

Steps to Reproduce

Clarifying Information

Error Message

Defect Number

Enhancement Number

Cause

Resolution

Although DELETE WIDGET-POOL is a valid statement in any ABL procedure, even one with no CREATE WIDGET-POOL statement, using this statement in an AppServer disconnect or shutdown procedure to avoid memory leaks will usually be ineffective. Here's why:

1. The AVM creates a "session widget pool" for each session. In the case of an AppServer, this is the agent runtime session that lasts from the time the agent is started until it is shut down. If no CREATE WIDGET-POOL statement is used in a procedure, all dynamic objects created in that procedure go into the session widget pool. The DELETE WIDGET-POOL statement has no effect on the session widget pool.

2. If the CREATE WIDGET-POOL statement is used without a name in a procedure, another unnamed widget pool is created that is scoped to that procedure. All objects created after the CREATE WIDGET-POOL statement is executed go into that unnamed widget pool instead of the session widget pool (unless the statement creating the object specifies a named widget pool), until the procedure goes out of scope. When the procedure goes out of scope, the unnamed pool and all the objects in it are deleted. A DELETE WIDGET-POOL statement within that procedure scope deletes the unnamed pool for that procedure, and all the objects in that pool, immediately.

The implications for an AppServer disconnect or shutdown procedure are:

1. The DELETE WIDGET-POOL statement in a disconnect or shutdown procedure deletes only those dynamic objects created within the scope of the disconnect/shutdown procedure, and only if there was a CREATE WIDGET-POOL statement to create a default unnamed widget pool scoped to the procedure. It does not delete any objects that were created in the session widget pool, even if they were created in the scope of the disconnect/shutdown procedure. It does not delete any objects created in named widget pools.

2. The DELETE WIDGET-POOL statement in a disconnect or shutdown procedure does not delete any dynamic objects that still exist from procedures that were run earlier in the session. This includes any objects that were created in startup or connect procedures.

3. Dynamic objects created in the unnamed widget pool of a procedure that has ended will have been deleted when the procedure ended. If dynamic objects are still in memory when a disconnect or shutdown procedure is run, and they were not created in the disconnect/shutdown procedure itself, they were created in one of the following ways:

a. In the session widget pool (the most likely case).

b. In a named widget pool.

c. In a widget pool that was created with the PERSISTENT option.

d. In the default widget pool of a procedure (possibly a persistent procedure) that is still running or a class-based object that is still instantiated.

A DELETE WIDGET-POOL statement in a disconnect or shutdown procedure will not delete any of the above objects.

Workaround

Notes

If there is concern about a memory leak in an AppServer application, the code in article How to check for leaked dynamic objects? may be added to a disconnect or shutdown procedure to see what objects still exist at disconnect or shutdown time. However, this code cannot tell where the objects were created.

Keyword Phrase

Last Modified Date

11/20/2020 7:19 AM

Drop Files

Upload FilesOr drop files

Disclaimer

The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.

Loading

Should I use DELETE WIDGET-POOL in an AppServer disconnect procedure? - Progress Community