Kbase P17286: Why does the user number in the logfile start at the value where it does?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
4/6/2006 |
|
Status: Verified
GOAL:
Why does the user number in the logfile start at the value where it does?
GOAL:
Where are the missing user numbers?
GOAL:
Why are user numbers not assigned in ascending order?
FIX:
The user numbers that appear in the logfile when users connect depend on the values for the -n and -Mn parametes when the database is started up. The servers that get started when remote users connect will take up the lower values. Please have a look under promon when you have remote users connected.
The following demonstrates the principle:
1. proserve sports -N tcp -H astra -S prosv03 -Mn 4 -Ma 1 -n 16
The lg file shows:
14:21:53 BROKER 0: Maximum Number of Clients Per Server (-Ma): 1. (4257)
14:21:53 BROKER 0: Maximum Number of Servers (-Mn): 5. (4258)
14:21:53 BROKER 0: Minimum Clients Per Server (-Mi): 1. (4259)
14:21:53 BROKER 0: Maximum Number of Users (-n): 17. (4260)
Note that for -Mn and -n both values are incremented by 1 more than what they are actually set to at the command line or from script. For example, if you set -n 20, it appears as -n 21 in the database lg file - this is so that there is always a free slot in the user table so that proshut (the _mprshut process) can always connect to the database; if you set -Mn 4, it appears as -Mn 5 in the lg - this is to account for the database Login broker.
2. promon sports - promon counts towards -n, but not towards the licenced users.
promon > 1. User Control > Display all entries shows:
Usr Name Type Wait Trans PID Sem Srv Login Time
0 jacarter BROK -- 0 0 14584 3 0 01/13/03 14:21
5 jacarter MON -- 0 0 14585 8 0 01/13/03 14:22
[Note that this promon session doesn't appear in the lg (which is due to a bug in the test environment).}
3. proapw sports
The lg file:
14:23:53 APW 6: Started. (2518)
promon:
Usr Name Type Wait Trans PID Sem Srv Login Time
0 jacarter BROK -- 0 0 14584 3 0 01/13/03 14:21
5 jacarter MON -- 0 0 14585 8 0 01/13/03 14:22
6 APW -- 0 0 14590 9 0 01/13/03 14:23
4. I start 4 remote clients:
Usr Name Type Wait Trans PID Sem Srv Login Time
0 jacarter BROK -- 0 0 14584 3 0 01/13/03 14:21
1 jacarter SERV -- 0 0 14596 4 0 01/13/03 14:33
2 jacarter SERV -- 0 0 14604 5 0 01/13/03 14:37
3 jacarter SERV -- 0 0 14606 6 0 01/13/03 14:38
4 jacarter SERV -- 0 0 14608 7 0 01/13/03 14:38
5 jacarter MON -- 0 0 14585 8 0 01/13/03 14:22
6 APW -- 0 0 14590 9 0 01/13/03 14:23
17 Jacarter REMC -- 0 178 0 10 4 01/13/03 14:38
18 Jacarter REMC -- 0 177 0 11 3 01/13/03 14:38
19 Jacarter REMC -- 0 176 0 12 2 01/13/03 14:37
20 Jacarter REMC -- 0 174 0 13 1 01/13/03 14:33
So remote users 20 through 17 don't actually connect to the database directly, but to servers 1-4, which are connecting to the database directly. These slots are reserved for the servers at database startup, thus the self-servicel connections (eg: promon, apw) will start with the next number after -Mn. The user numbers for the remote connections decrement: the value they start at is the sum of the values for -Mn and -n that are set at the command line or from script, as can be seen from my example here.