Kbase P21639: Clients connecting cilent/server failing to connect with 1890 message
Autor |
  Progress Software Corporation - Progress |
Acesso |
  Público |
Publicação |
  5/31/2005 |
|
Status: Verified
SYMPTOM(s):
Remote clients getting 1890 message when connecting:
Broker could not spawn a server (1890)
Fail to connect Client/Server to database
Remote client connections fail where self-service connections don't
Broker could not spawn a server. (1157)
CAUSE:
The maximum number of servers (-Mn) wasn't set high enough and had been reached.
FIX:
Ensure that the -Ma, -Mn, -n database start-up parameters are set correctly to allow the required number of remote connections.
These are specifically:
1.) Maximum Number of Clients Per Server (-Ma)
This value represents the maximum number of remote clients that are allowed to connect to each remote server (-Mn).
NOTE: It is suggested that -Ma is never greater than 10 for performance reasons.
2.) Maximum Number of Servers (-Mn)
This value represents the maximum number of remote servers that can be spawned to service the remote client connections. This value, together with the -Ma value is where the "Broker could not spawn a server" error is coming from. We have exceeded the number of remote connections available as configured.
NOTE: The -Mn value as recorded in the database log file will always be +1 greater than the value specified in the database startup parameter. This additional -Mn is for the login broker itself when the database is started (proserve).
3.) Minimum Clients Per Server (-Mi)
This value represents the minimum number of remote client connections per remote server before a new remote server is spawned. Remote servers will be spawned until -Mn is reached. Then the remaining remote clients will be connected to the remote servers in a round-robin fashion until -Ma is reached on each of these. Then the next remote client connecting, will get this "Broker could not spawn a server" error as recorded in the log file.
4.) Maximum Number of Users (-n)
You need to know how many Client/Server connections there need to be. Then to this you add +1 for every self-service and batch client that will access the database.
This gives you the Maximum Number of Users (-n). iow; the maximum number of concurrent connections to the database allowed at any given time. Then the product of -Ma * -Mn must therefore /always/ be less than -n.
NOTE: The -n value as recorded in the database log file will always be +1 greater than the value specified in the database startup parameter. This additional -n is for the for the _mproshut process.
The current number of connections per remote server can be viewed through the promon screen:
promon dbname
Enter your selection: R&D
1. Status Displays ...
3. Servers
Essentially, to avoid this Client/Server connection problem, you need to increase the -Mn -Ma startup parameters and balance these against -n to ensure that you have enough remote connections available. If there are multiple databases served by the same machine, it is worth uniquely defining the -minport and -maxport range for each database to avoid port conflict when remote servers are spawned.
The above discussion assumes no SQL-92 connections.