Configure OpenEdge properties
- Last Updated: February 24, 2025
- 21 minute read
- OpenEdge
- Version 12.2
- Documentation
The following content focuses on the ABL-centric options available in the conf/openedge.properties file.
The openedge.properties.README file, included in every OpenEdge installation and PAS for OpenEdge instance created, contains settings definitions. While openedge.properties.README groups settings by their functional area, this document organizes them by purpose. Furthermore, this content is by no means exhaustive; only specific properties have been called out with additional context as deemed relevant to improve clarity.
This configuration file is similar in behavior to the old
ubroker.properties file, where settings initially defined and per
ABL application instance values are treated as global defaults unless specifically
overridden. For example, a property in [AppServer.SessMgr] is used as
the default unless specified in a distinct ABL Application declaration such as
[AppServer.SessMgr.oepas1], where the override affects only that
ABL Application.
You may add, edit, and change properties directly through editing of the
openedge.properties file through a true file editor, or by use of
the oeprop utility as found in the CATALINA_BASE/bin/
directory. Of these two options, the latter is recommended to avoid introducing errors
into the file or corrupting it, perhaps with incorrect line endings or hidden
characters.
These values are modified to ensure PAS for OpenEdge instances work within the bounds of OS resources, such as CPU and memory, while also making the most efficient use of allotted resources without sitting idle for extended periods.
Agent and Session Limits
- maxAgents=10
- Definition: Maximum number of concurrent MS Agent OS processes an individual ABL application can start on the AppServer.
- Context: The minimal ideal case for stateless ABL application models is a maximum
of 2 MS Agents and a sufficient number of ABL sessions to handle the
expected concurrent requests for the ABL application.
- At least one MS Agent available per ABL application for a PAS for OpenEdge instance to start and operate properly.
- The case for setting this value to
2is that it provides at minimum a primary MS Agent for all requests and a warm spare if the primary MS Agent either needs to be terminated, or the number of requests exceeds its current connection capacity. - In most use cases, it was observed that setting a value higher
than
2did not yield a significantly better experience for the server, primarily due to context switching between the processes by the OS. In contrast, the more meaningful solution for managing expected load lies in the maxConnectionsPerAgent setting.
- minAgents=0
- Definition: Minimum number of MS Agents expected at any time. If the number of MS
Agents drops below this number, a client request causes the session
manager to start enough MS Agents to equal this number.
- Default setting of 0 means that
minAgentsis disabled. - Any value greater than 0, it is used for
minAgents. - If
minAgentsis greater thanmaxAgents, theminAgentvalue is lowered to match themaxAgents.
- Default setting of 0 means that
- Context: To fit with prior recommendations, setting the minAgents equal to the maxAgents (recommended: 2) ensures that the termination of any MS Agents triggers the start of a new MS Agents process to replace it (whether from manual termination or a result of the idleResourceTimeout).
- Definition: Minimum number of MS Agents expected at any time. If the number of MS
Agents drops below this number, a client request causes the session
manager to start enough MS Agents to equal this number.
- agentStartLimit=1
- Definition: Determines the maximum number of MS Agents that may be started at the same time. If this value is zero or not defined, then no limit is enforced.
- Context: This configuration throttles how many MS Agents are started simultaneously
when the Session Manager determines more MS Agents are needed. The
Session Manager smooths out the proliferation of MS Agents when PAS for
OpenEdge dynamic ABL session scaling would otherwise cause a phenomenon
referred to as an agent storm.
- To avoid a potential agent storm of multiple new MS
Agents starting at once, set this property to
1, though a value less than or equal tominAvailableABLSessionsis recommended. - For more information, see the following documents:
- To avoid a potential agent storm of multiple new MS
Agents starting at once, set this property to
- numInitialAgents=1
- Definition: Number of MS Agents to start when AppServer is started.
- Context: Should always be a non-zero value, ideally set to the same value as minAgents to ensure the minimum number of MS Agents are available when the ABL Application first starts.
- numInitialSessions=5
- Definition: Indicates the number of initial sessions that are pre-started by the Application Server.
- Context: The only MS Agent session value configured at the agent level (all others
are in the Session Manager group), this value should be set 10-20% of
maxConnectionsPerAgentto ensure enough sessions are started to handle the initial request load of your application. As always, load-testing your application after modifying properties is the best way to determine if a set value is effective. - Keep this value less than
maxABLSessionsPerAgent.
- maxABLSessionsPerAgent=200
- Definition: Maximum number of sessions a MS Agent can run.
- Context: The effect of this setting lies between Session Manager and an MS Agent
that governs the (maximum) pool of ABL sessions used to process
concurrent connections, which may or may not be bound to a client
connection.
- When used with Session Free (state-free or stateless)
connections, such as REST, WEB, or SOAP transports, this value
can be set equal to the
maxConnectionsPerAgent. In this situation the MS Agent session has a connection to a session manager (client) session only when it is running a request. - When used with a Session Managed application (for example, the
APSV transport), this value must be greater than
maxConnectionsPerAgent. In this way, you can control CPU usage, and still have client context that is persistent and awaiting the next request by a user not currently making a request. The memory usage is also proportionally larger since the sessions are higher than concurrent connections. - For more information, see the following:
- KB #142382 "How to configure maxConnectionsPerAgent and maxABLSessionsPerAgent for a PASOE instance"
- KB #121540 "Tuning PASOE OpenEdge Database Connections"It is particularly true if expected that an MS Agent session will become bound to a client (programmatically or via the client running a persistent procedure on the server); then that ABL session becomes reserved for a client and may not be used to service other requests.
- When used with Session Free (state-free or stateless)
connections, such as REST, WEB, or SOAP transports, this value
can be set equal to the
- maxConnectionsPerAgent=16
- Definition: Maximum number of concurrent TCP connections between session manager and multi-session agent.
- Context: Sets the maximum number of MS Agent sessions which may be started for each
MS Agent. In essence, this controls the total AVM runtimes available to
execute ABL code concurrently.
- The best performance for a PAS instance is achieved by keeping
the number of MS Agents (from
maxAgents) value as minimal as possible while maximizing the number of connections for concurrent client requests per MS Agent. - Setting the
maxConnectionsPerAgentproperty is related to the OS process memory, file limits, or both. Each MS Agent session that runs your ABL application code consumes memory and other process resources. Do not set the maximum ABL sessions to a higher number than the OS process supports. - See KB #142382 "How to configure maxConnectionsPerAgent and maxABLSessionsPerAgent for a PASOE instance".
- The best performance for a PAS instance is achieved by keeping
the number of MS Agents (from
- minAvailableABLSessions=1
- Definition:It is particularly true if expected that an MS Agent specifies the
smallest number of available ABL sessions to be maintained by the MS
Agent during its operation. While processing requests, if the number of
available ABL sessions falls below this threshold, the MS Agent
prestarts sufficient ABL sessions to bring the number of available
sessions up to this level.
- The minimum and default value of this property is 1. If you specify any lesser value, then the value will be reset to 1 internally.
- Context: Directs the MS Agent to keep ahead of new requests by the given amount, up
to the designated
maxABLSessionsPerAgent. Setting this value to 2 or 3 might enable the MS Agent to keep ahead of a burst of requests that would otherwise be sent to the secondary MS Agent. The exact value should be balanced between the expected number of requests beyond average, and the number of ABL sessions remaining idle if requests drop below average.- This value cannot ever be zero because the MS Agent code will
automatically set the value internally to 1 to create an extra
session over and above the number of sessions actively being
used, up to the
maxABLSessionsPerAgentproperty. - It is the availability of this extra session tells the session manager that it is okay to send another request to that agent. The only time the MS Agent has no available sessions is if it has reached the configured maximum. In this case, the session manager knows that the MS Agent is "full", and will spawn a second MS Agent with at least one available session, letting the session manager know that a session is ready to run a request.
- This value cannot ever be zero because the MS Agent code will
automatically set the value internally to 1 to create an extra
session over and above the number of sessions actively being
used, up to the
- Definition:It is particularly true if expected that an MS Agent specifies the
smallest number of available ABL sessions to be maintained by the MS
Agent during its operation. While processing requests, if the number of
available ABL sessions falls below this threshold, the MS Agent
prestarts sufficient ABL sessions to bring the number of available
sessions up to this level.
See ABL Session Manager and Session Pool for more information.
Resource Bounds
Networking:
- agentMaxPort=62202
- agentMinPort=62002
- Definition: Specifies the range of OS network port numbers that OpenEdge will
search through to dynamically assign a listening port to a new MS Agent
process. That opened listening port is opened by the MS Agent. It
enables the ABL application’s Session Manager to send client requests to
the MS Agent for execution in one of its ABL sessions.
- Generally, if you set
agentMinPort, setagentMaxPortso that you specify a well-defined range. - Their possible values are 1024 to 65535.
- This property can be dynamically updated. Dynamic changes affect only new MS Agents that are started after this value is changed.
- Generally, if you set
- Context: Much like the min/max port range values found in the Classic AppServer, an
instance requires network (TCP) ports to be used when starting each MS
Agent. No standard services should overlap with the default ports though
that may not always be the case. The following outlines the need for
these ports and when/how these values may need to be altered.
- When the PAS for OpenEdge container (Tomcat server) starts, the
Session Manager looks for an open port in the given range (max -
min) before starting each MS Agent, which listens on that port
for all interfaces (0.0.0.0) of the host (where host may
be a physical machine, virtual machine, or a container).
- If viewing ports are in use for a host, an established connection will be found on 1 or more local host IPs between the Tomcat PID and any MS Agent PIDs.
- By default, the range of 200 ports should be sufficient for a
substantial number of MS Agents across all ABL Applications, on
all PAS for OpenEdge instance across a host. Therefore, you
should not change the default values as the need to change the
port range should be an exception, not a rule.
- If the port range must be altered, a very basic formula for calculating a new range is to account for the maximum number of MS Agents across all ABL Applications of the instance, plus admin access for the Session Manager, plus some extra allowance. For example, ( (maxAgents + 1 [session manager admin access]) * num-instances-per-host ) + extra allowance.
- The goal is to find through the monitoring a port range sufficiently wide to fit the requirements. This goal may require monitoring the application and container or OS for error messages which indicate an open port cannot be found. That indicator should prompt for the expansion of the default port range or choosing another range with sufficient width.
- When the PAS for OpenEdge container (Tomcat server) starts, the
Session Manager looks for an open port in the given range (max -
min) before starting each MS Agent, which listens on that port
for all interfaces (0.0.0.0) of the host (where host may
be a physical machine, virtual machine, or a container).
- Definition: Specifies the range of OS network port numbers that OpenEdge will
search through to dynamically assign a listening port to a new MS Agent
process. That opened listening port is opened by the MS Agent. It
enables the ABL application’s Session Manager to send client requests to
the MS Agent for execution in one of its ABL sessions.
- ipver=IPv4
- Definition: The internet protocol (IP) used the server for
network communication. By default, it is set to IPv4/IPv6, where:
- IPv4 accepts only IPv4 connections, and
- IPv6 accepts IPv6 connections and IPv4 connections that use address mapping (where supported).
- Definition: The internet protocol (IP) used the server for
network communication. By default, it is set to IPv4/IPv6, where:
- tcpNoDelay=1
- Definition: If the value of this property is not a zero, then the
PAS for OpenEdge Session Manager automatically sets the TCP
option—
TCP_NODELAYfor all socket connection that are created between the Session Manager and the multi-session agents of the PAS for OpenEdge.
- Definition: If the value of this property is not a zero, then the
PAS for OpenEdge Session Manager automatically sets the TCP
option—
- agentHost
- Definition: Specifies the network adapter used for communication between the Session Manager and multi-session agent of the PAS for OpenEdge. The specified value can either be a host name or an IPv4 address.
- agentStartupProc
- Definition: Specifies a startup procedure used for a multi-session agent. The procedure specified must be a valid procedure on the PROPATH of the application service.
- agentShutdownProc
- Definition: Specifies a shutdown procedure that is used for a multi-session agent. The shutdown procedure must be a valid procedures on the PROPATH of the application service.
- agentStartupProcParam
- Definition: Specifies a character parameter that is passed into the agentStartupProc procedure.
- infoVersion=9010
- Definition: This property is for internal use only.Note: Do not modify this property.
- Definition: This property is for internal use only.
- lockAllExtLib
- Definition: Setting this property locks the use of external
libraries, whether they are thread-safe or not. This property allows
only one external library to be accessed at a time.
- 0 — Do not apply a lock to protect access to external library.
- 1 — Apply lock to protect access to external library.
- Definition: Setting this property locks the use of external
libraries, whether they are thread-safe or not. This property allows
only one external library to be accessed at a time.
- lockAllNonThreadSafeExtLib
- Definition: This property causes the MS Agent to acquire a lock before it calls a non-thread-safe libraries. This ensures that only one non-thread-safe library is invoked concurrently.
- PROPATH=${CATALINA_BASE}/openedge,${DLC}/tty,${DLC}/tty/netlib/OpenEdge.Net.pl
- Definition: Specifies the PROPATH, which is a Progress environment variable, that contains a list of directories that the AVM uses to search for files and procedures to run.
- sessionActivateProc
- Definition: Specifies the activate procedure for the session. The procedure must be a valid procedure on the PROPATH of the application service.
- sessionConnectProc
- Definition: Specifies the connect procedure for session-managed sessions. This connect procedure must be a valid procedure on the PROPATH if the application service.
- sessionDeactivateProc
- Definition: Specifies the deactivate procedure for the session. This deactivate procedure must be a valid procedure on the PROPATH of the application service.
- sessionDisconnProc
- Definition: Specifies the disconnect procedure for session-managed session. This disconnect procedure must be a valid procedure on the PROPATH of the application service.
- sessionShutdownProc
- Definition: Specifies the shutdown procedure for the server. This shutdown procedure must be a valid procedure on the PROPATH of the application service.
- sessionStartupProc
- Definition: Specifies a startup procedure for the server. This startup procedure must be a valid procedure on the PROPATH of the application service.
- sessionStartupProcParam
- Definition: Specifies the startup parameter that each session uses when the MS Agent starts it. Changing the parameter dynamically affects only the new MS Agents that are started after changing this value.
- using ThreadSafeExtLib
- Definition: Setting this property indicates to the agent that it
can assume that all external libraries references by ABL applications
are thread-safe.
- 0 — Do not assume that all external libraries are thread-safe.
- 1 — Assume that all external libraries are thread-safe.
- Definition: Setting this property indicates to the agent that it
can assume that all external libraries references by ABL applications
are thread-safe.
- uuid
- Definition: Specifies a universally unique identifier for this uuid broker.
- agentExecFile=${psc.as.oe.dlc}/bin/_mproapsv
- Definition: Specifies the server executable used for the MS Agents that is
configured while installing the server.Note: Do not modify this property.
- Definition: Specifies the server executable used for the MS Agents that is
configured while installing the server.
- agentStartupParam=-T "${catalina.base}/temp"
- Definition: Specifies the server or agent startup parameters that each process uses
when the broker starts. For example, specify the Database (-db)
parameter to connect to the application database.
You can dynamically update this property. Dynamic changes affect only new MS Agents that start after you change this value.
- Definition: Specifies the server or agent startup parameters that each process uses
when the broker starts. For example, specify the Database (-db)
parameter to connect to the application database.
- publishDir=${catalina.base}/openedge
- Definition: Specifies the location where the Progress Developer Studio for OpenEdge should publish the r-code for the active session manager.
- workDir=${CATALINA_BASE}/work
- Definition: Specifies the working directory of the project.
- fileUploadDirectory
- Definition: Specifies a directory where web transport can upload
the files. The following HTML snippet shows how to use this feature:
<HTML> <BODY> <FORM ENCTYPE="multipart/form-data" ACTION="http://<yourhost>/<msngr path>/<msngr>/ping" METHOD="POST"> <INPUT type="file" name="filename"> <INPUT type="submit"> </FORM> </BODY> </HTML>By default, this capability is disabled. Specify an upload directory to enable this property. You can only upload a text file. Uploading of binary file is not supported.
File paths specified by the client that results in writing the file to any location other than the
fileUploadDirectory, or one of its subdirectories, will be rejected.
- Definition: Specifies a directory where web transport can upload
the files.
- binaryUploadMaxSize
- Definition: Specifies the maximum size, in bytes, of the binary
files that the web transport will handle. The application can access the
content of the binary files through the 4GL language.
- 0 — Binary upload is disabled
- -1 — Binary upload is enabled. This option enables any non-zero binary upload.
- n — "n" is a positive integer that specifies the maximum binary upload size.
Note: This property is not related to thefileUploadDirectoryproperty. Hence, web transport will not upload the file to a directory.
- Definition: Specifies the maximum size, in bytes, of the binary
files that the web transport will handle. The application can access the
content of the binary files through the 4GL language.
Operating System:
Each OS controls the maximum number of sockets, either per OS or per process, depending on the type. For example, in UNIX, the limit is per process socket with a maximum number for the TCP stack.
An MS Agent can only concurrently execute the same number of client requests as local socket
connections with the Session Manager, which automatically scales up to the
maxConnectionsPerAgent limit while looking for a free (idle)
ABL session to execute a client request. A byproduct of managing the number of local
socket connections is the MS Agents management of its pool of OS threads reserved
for executing client requests. Each time a new local socket connection is created, a
new OS thread is started to execute client requests arriving through that socket.
Each time a local socket connection is closed, an OS thread from the pool is
stopped. Once a local socket connection is created and an OS thread exists to
execute client requests, it can be used by any client request regardless of the
bound-client state.
Socket Tuning tips:
- Do not set the maximum number of local socket connections per MS Agent process higher than the maximum number of ABL Sessions.
- Do not set the sum of local socket connections for all MS Agents larger than the PAS thread
pool for executing HTTP requests as they will never be used
(
psc.as.executor.maxthreads). - Choosing the appropriate number of socket connections per MS Agent is related to client
request response times.
- Too few sockets means a fewer number of concurrently executing client request. Those requests become queued until an open socket is available. If client requests are queued too often and or too long, the client will see this as a non-responsive application.
- Too many sockets means a higher number of concurrently executing client requests, which will push the MS Agent process into consuming more CPU and I/O from the OS. This has an effect on all software products running in the OS. When you multiply the per MS Agent socket limit by the number of MS Agents, you then have the total CPU and I/O load on the OS.
- The choosing of an appropriate number of local socket connections is closely tied to the implementation of the ABL application. If the ABL application uses high levels of file, database, or socket input or output, you must increase the number of socket connections and ABL sessions because many of them will have high idle times where CPU resources can be used for executing CPU-bound ABL language statements.
Timeouts
The order of operations for timeout properties:
- agentListenerTimeout
- connectionWaitTimeout + requestWaitTimeout
- idleConnectionTimeout
- sessionExecutionTimeLimit
- connectionWaitTimeout + requestWaitTimeout
- idleSessionTimeout
- idleAgentTimeout
- agentListenerTimeout=300000
- Definition: Maximum amount of time in milliseconds the session manager waits for an MS Agent to start up on connect.
- Context: When the session manager starts an MS Agent process, the process must
initialize itself, then connect back to the session manager and identify
itself. It sends its PID, listening port, and a security token to
confirm that the MS Agent process has started, which must occur within
the time specified by the
agentListenerTimeout. If the timeout expires, the session manager assumes that the MS Agent process initialization has failed, and throws an error. The effect of this error depends on the circumstances under which the MS Agent is being started. Unlike classic AppServer, it is not considered a fatal condition during startup.- The longer the
agentListenerTimeoutproperty is set, the longer the PAS for OpenEdge instance takes to start when for any reason the MS Agent process has startup failures. Too short a time and the PAS instance may start sooner but the Session Manager may consider the MS Agent unavailable.
- The longer the
- connectionWaitTimeout=3000
- Definition: Maximum amount of time in milliseconds that session
manager waits for a connection to be freed up before creating a new
connection.Note: When the session manager is waiting for a connection, the Tomcat execution thread (from the executor pool) is waiting. When the Tomcat execution thread is waiting, it is not available to be used by any other inbound client requests, causing those client requests to be queued.
- Context: Related to the
requestWaitTimeout, it should be viewed with the context of that timeout, as stated below.
- Definition: Maximum amount of time in milliseconds that session
manager waits for a connection to be freed up before creating a new
connection.
- requestWaitTimeout=15000
- Definition: Maximum amount of time in milliseconds a request waits in the session manager for a connection to be available before rejecting the request.
- Context: To run a request, the session manager tries to reserve a connection to an
existing MS Agent. If no connection is available before the
connectionWaitTimeout(default 3 seconds) expires, then the session manager attempts to start a new MS Agent. The request continues to wait for a connection to be available. If no connection is available before therequestWaitTimeout(default 15 seconds), then a no connections available exception (as a possible example) may be thrown. These two timeout periods are consecutive.- The value of this property should exceed the sum of the
agentListenerTimeout + connectionWaitTimeout +
time-to-start-session + time-to-start-agent.
The agent and startup times must include time spent in the
sessionStartupProcandagentStartupProcevent procedures (if any). A number of factors may affect the time taken to complete the event procedures, including database locks and OS resource contention. The agent startup time is added to allow for an instance to scale up and potentially start another MS Agent process if server load requires it. A newly-started MS Agent may start servicing requests once a single ABL session is available, so this time does not need to take the number of initial ABL sessions into account.
- The value of this property should exceed the sum of the
agentListenerTimeout + connectionWaitTimeout +
time-to-start-session + time-to-start-agent.
The agent and startup times must include time spent in the
- idleConnectionTimeout=300000
- Definition: Timeout value in milliseconds applicable for socket connections between the Session Manager and MS Agent. If a socket connection is idle for more than the specified timeout value, then it will cleaned when idleResource cleanup is done.
- Context: If no activity has occurred on a connection between the session manager and MS Agent within this interval then the connection is closed. These actual socket connections are created on-demand, up to the configured limit; the number of connections determines the maximum number of concurrent requests that can execute on a given MS Agent. These connections are not related to binding of client sessions; when a client session is bound, it does NOT retain the connection to that client, just the identity of the ABL session. Unfortunately, the phrase client connection gets used imprecisely throughout our informal discussions of PAS for OpenEdge, and is the cause of some amount of confusion. We do not have connections to clients, we maintain sessions with clients.
- sessionExecutionTimeLimit=
- Definition: Specifies the number of seconds in which a request may execute in the MS Agent before a STOP condition is raised in that session. The value of 0 indicates that execution time is not limited.
- Context: Effectively places a "stop after" on all ABL code
execution, allowing you to place a limit on how long a client request
may take before it is stopped on the server side. For example, if set to
60 (seconds), a STOP request will be raised after a minute, and if your
application correctly handles STOP, it should cancel the request and
return a 500 response, which can be better than the server (session)
hanging and never returning. It is related to
psc.as.stuckthreadthresholdincatalina.properties, though that will merely report that a thread took longer than the threshold and does not stop ABL execution, onlysessionExecutionTimeLimitwill trigger that behavior.
- completeActiveReqTimeout=600000
- Definition: Maximum amount of time in milliseconds that an agent waits to complete any active request in case of an emergency shutdown.
Internal/Management Timeouts
- agentWatchdogTimeout=3000
- Definition: Watches for MS Agents to terminate events, and wakes up every 3 seconds for instance shutdown messages. Do not change the default value of 3000 unless directed by OpenEdge development.
- Context: It is strictly for internal usage, and has minimal impact on performance at its default value.
- idleResourceTimeout=0
- Definition: Timeout value in milliseconds to determine the frequency with which the PAS for OpenEdge server checks for idle resources. Any resource (for example, connection, MS Agent, or client session) that has not been accessed more recently than the specified timeout for that property will be terminated. If this property is set to zero, then idle resource checking is disabled.
- Context: Specifies how often the pools of resources are checked
to see if any have timed out, based on last activity. Must be a non-zero
value to activate this check.Note: The
idleResourceTimeoutproperty did not operate properly prior to 11.7.5.
- idleSessionTimeout=1800000
- Definition: Timeout value in milliseconds for an idle Session
Manager session. The APSV transport uses this value to set the
expiration time of the HTTP Session when using HTTP Sessions. It
defaults to 30 minutes, which is the same value used by the other
transports. Their HTTP Session expiration is controlled in
web.xml and does not require
idleResourceTimeoutto be set because it is handled by Tomcat. - Context: There is no persistent connection maintained between the client and the PAS for OpenEdge server since it is HTTP. This property dictates how long a client session can remain inactive between requests (in other words, send no requests) before the session is terminated. This property has no effect on long running RPC calls to the MS Agent. When this timeout expires, the Session Manager removes the session from the session pool, and invalidates the HTTP session by expiring the JSESSIONID cookie. Subsequent attempts by a client to issue a request using this session fail with a no such session error or similar message.
- Definition: Timeout value in milliseconds for an idle Session
Manager session. The APSV transport uses this value to set the
expiration time of the HTTP Session when using HTTP Sessions. It
defaults to 30 minutes, which is the same value used by the other
transports. Their HTTP Session expiration is controlled in
web.xml and does not require
- idleAgentTimeout=300000
- Definition: Timeout value in milliseconds for an idle MS Agent. If an MS Agent is idle for more than the specified timeout value, then the session is deleted when idleResource cleanup is done.
- Context: If no activity has occurred on an MS Agent within this time interval, then the MS Agent is automatically shut down.
- socketTimeout=3000
- Definition: Maximum amount of polling interval time in milliseconds that session manager waits for a connection to be freed up before creating a new connection.
- defaultAgentWaitToFinish=30000
- Definition: Timeout value in milliseconds to wait for a busy
agent to finish work during a shutdown caused by the expiration
of the
idleAgentTimeout. This value should be greater than the normal execution time of the the application's longest running request. - Context: Offers time for an MS Agent to gracefully complete a request when that
agent receives a command to terminate. This value may be from the
idleAgentTimeoutas noted or via OEM-API or OEJMX management commands. The value may be adjusted based on the average request duration for an ABL application.
- Definition: Timeout value in milliseconds to wait for a busy
agent to finish work during a shutdown caused by the expiration
of the
- defaultAgentWaitAfterStop=30000
- Definition: Timeout value in milliseconds to wait for a stopping agent to finish work during a shutdown caused by the expiration of the idleAgentTimeout. When this timeout expires, the agent is forcibly shut down. This value should be greater than the longest time required to handle a normal STOP condition for the application.
- Context: If an MS Agent which was requested to stop did not complete the servicing of a request during the defaultAgentWaitToFinish then it will be allotted the time from defaultAgentWaitAfterStop before being forcefully terminated.
The article KB #180611 "How to configure PASOE to clean up idle resources automatically" provides valuable information about cleaning up idle resources: HTTP sessions, MS Agents, and ABL sessions.
Metrics and Logging
- allowRuntimeUpdates=0
- Definition: Allows certain properties to be dynamically
updated.
- 0 for not allowing
- 1 for allowing
- Context: Enabling this property for a production instance allows
for changing of properties at runtime such as logging levels, which can
be useful if there may be a need to debug a situation without restarting
the instance to pick up the configuration changes. This list may be
subject to change in the future, but these are the properties which can
be affected through use of this flag:
agentExecFileagentStartupParamagentLoggingLevelagentLogEntryTypesdefrdlognumlinesdefrdloggingleveldefrdlogentrytypesipvernumInitialAgents(validated to "make sense")maxAgents(validated to "make sense")minAgents(validated to "make sense")agentStartLimitmaxABLSessionsPerAgentmaxConnectionsPerAgentagentListenerTimeoutagentWatchdogTimeoutconnectionWaitTimeoutrequestWaitTimeoutsocketTimeoutPROPATHallowRuntimeUpdatesNote: Allows disabling without restart but enabling needs a restart.
- Definition: Allows certain properties to be dynamically
updated.
- collectMetrics=1
- Definition: Enables or disables the collection of metrics used by
oemanager.
- 0 disables the collection of metrics used by oemanager.
- 1 enables the collection of count metrics used by oemanager.
- 2 enables the collection of timing metrics used by oemanager.
- 3 enables both count and timing metrics by oemanager.
- Default is 1 (enabled) for Development and 0 (disabled) for Production.
- Context: If there may be a need to get more insight on behavior of requests, then setting this to 3 will track both the count and timing values. The slight overhead for tracking this data may be worth the outcome especially while attempting to tune or debug a PAS for OpenEdge instance.
- Definition: Enables or disables the collection of metrics used by
oemanager.
- statusEnabled=1
- Definition: Enables or disables the return of the server or
transport status information in JSON.
- 0 disables the return of the server or transport status information in JSON.
- 1 enables the return of the server or transport status information in JSON.
- Definition: Enables or disables the return of the server or
transport status information in JSON.
- agentLogEntryTypes
- Definition: A single entry or comma delimited list of logging entry types for MS
Agent log buffer. By default, it is set to
uBroker.basic. - agentLogFile
- Definition: The MS Agent log file that has the location, name, and roll-over of
the MS Agent details.
If you want the MS Agent log file roll-over at midnight, then add {yyy-MM-dd}. For example:
<path-to>/<instance name>.agent.{yyyy-MM-dd}.log
- Definition: The MS Agent log file that has the location, name, and roll-over of
the MS Agent details.
- Definition: A single entry or comma delimited list of logging entry types for MS
Agent log buffer. By default, it is set to
- agentLoggingLevel=2
- Definition: Logging level for messages into the MS Agent log buffer.
- 0 - No log file written
- 1 - Error only
- 2 - Basic
- 3 - Verbose
- 4 - Extended
- Definition: Logging level for messages into the MS Agent log buffer.
- collectStatsData=0
- Definition: This property has not been defined yet and has been created for future use.
- flushStatsData=0
- Definition: This property has not been defined yet and has been created for future use.
- defrdLogNumLines=0
- Definition: The maximum number of lines of log information that may be written to the deferred log buffer, shared by all ABL sessions in an MS Agent. The default value is 0, which disables the feature.
- Context: Allows shunting certain log messages to the deferred log output, which can be programmatically dumped when needed or will be automatically dumped in the event of an unexpected MS Agent termination. For a high-transaction environment, set to 1000 or higher, to ensure enough relevant data is captured for analysis, though this may also increase memory usage for storage of the buffered data.
- defrdLoggingLevel=0
- Definition: Logging level for messages into the deferred log
buffer.
- 0 No log file written
- 1 Error only
- 2 Basic
- 3 Verbose
- 4 Extended
- Context: One of the values to be picked up if
allowRuntimeUpdatesis enabled. A value of at least 2 should provide useful information. By increasing this value, more data is captured prior to a crash or flush event, though it may likely increase memory consumption for that buffered data.
- Definition: Logging level for messages into the deferred log
buffer.
- defrdLogEntryTypes=
- Definition: A single entry or comma delimited list of logging entry types for the deferred log buffer.
- Context: Unlike the traditional log entry types, the deferred
logging system accepts only certain types (for example, 4GLTrace but not
DynObjects). Though similar to the standard log entry types, you may
still provide a distinct logging level for each type in the format of
log-entry-type:logging-level.
- For an example use-case, certain behaviors within the MS Agent have required need for
observation by engineering or tech support, which was enabled
through the following types and their related logging level:
MSASAdmin:3,MSASSessions:4,MSASSignals:2 - More information about Deferred Logging for PAS for OpenEdge may be found in Use deferred logging in PAS for OpenEdge and KB #155287: What is Deferred Logging for PASOE?.
- For an example use-case, certain behaviors within the MS Agent have required need for
observation by engineering or tech support, which was enabled
through the following types and their related logging level: