Feedback
Did this article resolve your question/issue?

   

Article

Can a remote server _mprosrv or _sqlsrv2 be stopped without shutting the database down?

« Go Back

Information

 
TitleCan a remote server _mprosrv or _sqlsrv2 be stopped without shutting the database down?
URL NameP42984
Article Number000145600
EnvironmentProduct: Progress OpenEdge
Version: All supported versions
OS: All supported platforms
Question/Problem Description
Why is memory not released from a remote server when a user logs off ?
Is there an environment variable that controls the _mprosrv timeout?
When no remote clients are connected to a remote spawned server, how long does the _mprosrv stay active for ?
Can a database remote ABL or 4GL server, _mprosrv, be stopped without shutting the database down?
Can a database remote SQL server, _sqlsrv2, be stopped without shutting the database down?
Steps to Reproduce
Clarifying Information
Error Message
Defect Number
Enhancement Number
Cause
Resolution
For client/server connections, once the database has been started and the primary login broker initialised, remote servers are spawned “as needed”. There is an overhead in their initialisation, so once they have been started they will remain active for the entire multi-user session. In other words, as can be seen in the closing messages of a database log file during a normal termination, they will not be removed until the database is shut down.

Example:

SHUT 4: Server shutdown started by <user-id> on <tty>. (542)
BROKER 0: Begin normal shutdown (2248)
SRV 2: Stopped. (2520) << here
SRV 1: Logout usernum <num>, userid <name>, on <tty/node>. (739)
SRV 1: Stopped. (2520) << and here, once connected clients have been successfully terminated
BROKER : Multi-user session end. (334)


There are no environment variables or client session startup parameters to control the termination of the remote servers. These can only be controlled as to how they are initially spawned which, is managed by how they are configured.

When the database is started, the primary login broker process (_mprosrv) is initialised on the Server.
This then listens on the listening port (-S) for remote clients (prowin32, _progres, proadsv, java, sql, odbc clients connecting with the -S connection parameter) requesting a connection.
It is only when the primary login broker receives a connection request, that it then spawns a remote server (_mprosrv, or_sqlsrv2 for SQL-only servers) on the portrange {-minport,-maxport },
then hands the remote client over to communicate with the database through this channel (the port number of the remote server).
The login broker will continue spawning remote servers depending on the number of client requests and on the values of the relevant client session startup parameters.
These govern when a new remote server is spawned and how the client connections are allocated to each remote server:
  • (-Mn): Maximum Number of Remote Servers that can be spawned - The TOTAL number of remote servers for the database.
  • (-Mpb): Maximum Number of Remote Servers that can be spawned per broker - A subset of -Mn, per broker type (SQL or 4GL) set on each login broker (in the case of more than one login broker being defined in the architecture with the –m3 startup parameter for example).
  • (-Mi): Minimum Number of Clients connected per Remote Server before spawning another Remote Server.
  • (-Ma): Maximum Number of Clients allowed to connect per Remote Server
  • (-n): Maximum Number of connections to the database. - The TOTAL number of connections, irrespective of connection type (backup, batch, writers, self-service, client-server, appserver etc)
When a Remote Client connects to a Remote Server, the server allocates RAM as needed from the operating system to satisfy the current requirements of the queries of all its connected users (-Ma).
The server does not release this memory, it holds the memory until it needs the memory again and will then use it.
There is an overhead in spawning these servers, so they remain instate until the database is shut down.

A higher -Mn means that potentially more _mprosrv processes are going to be in memory,
whereas a higher -Ma will mean that more clients connect to the database over any one remote server process, which can result in resource contention between these connections.
This configuration needs to be balanced and tuned to give the best performance at each site.

In Summary:

Is the remote server removed after a user logs off?

NO, once spawned, it will remain active until the database is shut down.

Is there an environment variable to control the _mprosrv timeout?

NO, TCP KEEPALIVE will manage dead clients and -clienttimeout (on Windows only) will manage idle client connections, but there are no startup parameters or environment variables to manage remote server termination, only initialisation.

When no remote clients are connected to a remote spawned server, how long does the _mprosrv stay active for?

As long as the database is up and running.

Can the remote server be terminated without shutting down the database?

Yes, since Progress 9.1E for 4GL/ABL remote servers and OpenEdge 10.1C for SQL92 remote servers can be terminated through PROMON. For further detail refer to Article:
Workaround
Notes
Last Modified Date11/20/2020 7:27 AM
Attachment 
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.