Last Updated: August 13, 2004
Applies to versions of GemStone/S prior to 6.2; applicable to later versions of GemStone/S and GemStone/S 64-bit, except some operations performed by pagemanager.
This describes the sequence of events that occur when an application on a machine that is remote from the GemStone server, logs in linked to GemStone. With GemStone version 6.1 and later, remote linked logins – or gems executing on machines remote from the stone – require a shared page cache to be started on the remote machine.
1. Client application (Topaz, GBS, or GCI): loads libraries with gem code, if not already loaded.
2. Client application contacts the netldi on host machine (Netldi A), using its well-known socket, requesting the stone’s service.
In the host’s netldi -d log, see the following lines:
0: Wed 07 Apr 2004 11:17:06 AM PDT Attempting accept... ...succeeded accepting client from <IP address>, connection = 2 0: Wed 07 Apr 2004 11:17:06 AM PDT Finished reading client request: Client is a rpc gem or a linked application. !#encrypted:<username>@password#netldi:<netldiname>#server!<stonename>'
3. Netldi A (on host) looks up the stone’s port, which is encoded in the <stonename>..LCK file, in the standard location for lock files.
4. Netldi A (on host) passes the stone’s port back to the client application.
In the host’s netldi -d log, see the following lines:
0: Wed 07 Apr 2004 11:17:06 AM PDT Reply to client started: 'SUCCESS 35840' 0: Wed 07 Apr 2004 11:17:06 AM PDT Done writing reply to client. 0: Wed 07 Apr 2004 11:17:06 AM PDT Disposed. elapsed time = 0
Where 35840 is the well-known port that the stone is listening on.
5. Client application contacts the stone on this socket, and requests login.
6. Stone receives the login request.
7. Stone checks internally for the existence of a shared page cache on the remote machine. If one already exists, indicating that either linked clients or gems are running on that machine, it proceeds with step 20.
8. Stone contacts the netldi on the client machine (Netldi B), to request a page server.
In the client’s netldi -d log, see the following lines:
0: Wed 07 Apr 2004 11:17:06 PDT
Attempting accept...
...succeeded accepting client from <IP Address>, connection = 2
0: Wed 07 Apr 2004 11:17:06 PDT
Finished reading client request:
Client is a stone.
Trusted client.
'!#encrypted:<username>#netldi:<netldiname>!runpgsvr<stonename>@<IP Address>
1250 46 0 -1 -1 1'
9. Netldi B (on client) sets up a callback port to handle this request, and starts listening on it. See step 11 for the specific port number.
10. Netldi B (on client) looks up the service ‘runpgsvr’. By default it finds this in the services.dat on the client, and the default translation is to execute pgsvrmain.
11. Netldi B (on client) launches pgsvrmain, telling it the number of the callback port it should use to reply (the port set up in step 9).
In the client’s netldi -d log, see the following lines:
0: Wed 07 Apr 2004 11:17:06 PDT
Successful fork; Child's Pid: 1050 command is:
'<hostpath>/pgsvrmain <stonename>@<IP Address> 1250 46 0 -1 -1 1 TCP 49429 30'
Where 1050 is the pid of the pgsvrmain (the page server on the client’s machine), and 49429 is the port that the netldi is listening on for the reply from pgsvrmain, and 30 is the timeout in seconds.
The other parameters define the shared page cache that will be started on the client machine; in this example, 1250 is the size of the cache in pages (based on the default SHR_PAGE_CACHE_SIZE_KB, which is 10000), 46 is the maximum processes that can attach (based on the default STN_MAX_SESSIONS, which is 40, plus extra allowance for page servers, etc), and so on. The shrpcmonitor log will include corresponding information, see step 14 and 15.
At this point there will be a log for the pgsvrmain, with a name of the form pgsvrmain<pid><clientmachine>.log, in the gemstone user’s home directory.
12. Pgsvrmain B (on client) initializes itself.
14. Pgsvrmain B (on client) launches the startshrpcmon script, which executes the shrpcmonitor executable.
At this point there will be a log file for the cache, with a name of the form startshrpcmon<pid><clientmachine>.log, in the gemstone user’s home directory.
15. Shrpcmonitor (on client) starts up. This may take some time.
16. Pgsvrmain B (on client) starts free frame page servers as configured
17. Pgsvrmain B (on client) replies on callback port (to Netldi B) with the port it will listen on for the client connection, and waits on that port. See step 18 for the port it will listen on.
18. Netldi B (on client) passes the number of the pgsvrmain’s service port to the stone.
In the client’s netldi -d log, see the following lines:
0: Wed 07 Apr 2004 11:17:07 PDT
Reply to client started:
'SUCCESS 49432'
0: Wed 07 Apr 2004 11:17:07 PDT
Done writing reply to client.
0: Wed 07 Apr 2004 11:17:07 PDT
Disposed. elapsed time = 1
Where 49432 is the socket that the page server will wait on for contact from the stone. Note the elapsed time; this is the entire time taken by the netldi to service this request, including time for the pgsvrmain and shrpcmonitor to start up. If this time approaches the timeout value set for the netldi, you risk login failures due to netldi timeout.
19. Stone connects to Pgsvrmain B (on client) on the port specified.
In the client’s pgsvrmain log file, pgsvrmain<pid><clientmachine>.log, see the following lines:
[11:17:07.54] Pgsvrshr is now accepting its client... [11:17:07.63] Network connection has been established. Entering Service Loop ClientPid: 12409
Where 12409 is the pid of the stone.
20. Stone replies to client to continue login, with all the information the client needs about the repository.
21. Client application initiates attaching each of the extent files; the following steps are repeated for each extent file, with exceptions noted.
22. Client application gets information about the stone. To do this, it requests to Netldi A (on the host) to get the stone service.
23. Netldi A (on host) retrieves stone’s service, and replies to the client.
24. Client application determines that the extent files are remote, and a page server is needed.
25. Client application checks for a remote page server on the host machine.
26. If no remote page server is found (i.e., when attaching the first extent), the client application requests to Netldi A (on host) to start a page server. For extents after the first one, skip to step 34.
In the host’s netldi -d log, see the following lines:
0: Wed 07 Apr 2004 11:17:07 AM PDT
Attempting accept...
...succeeded accepting client from <IP address>, connection = 2
0: Wed 07 Apr 2004 11:17:07 AM PDT
Finished reading client request:
Client is a rpc gem or a linked application.
Trusted client.
'!#encrypted:<username>#netldi:<netldiname>!runpgsvr'
27. Netldi A (on host) sets up a callback port to handle this request, and starts listening on it.
28. Netldi A (on host) looks up the service ‘runpgsvr’; by default it finds this in the services.dat file on the host, and the default translation is to execute pgsvrmain.
29. Netldi A (on host) launches pgsvrmain, telling it the number of the callback port it should use.
In the host’s netldi -d log, see the following lines:
0: Wed 07 Apr 2004 11:17:07 AM PDT
Successful fork; Child's Pid: 12536 command is:
'<path>/pgsvrmain TCP 35860 30'
Where 12536 is the pid of the newly created pgsvrmain, and 35860 is the callback port the netldi is listening on for a reply from the pgsvrmain, and 30 is the timeout in seconds.
At this point there will be a log for the pgsvrmain, with a name of the form pgsvrmain<pid><hostmachine>.log, in the gemstone user’s home directory.
30. Pgsvrmain A (on host) initializes itself.
31. Pgsvrmain A (on host) replies on callback port (to Netldi A) with the port it will listen on, and waits on that port.
32. Netldi A (on host) passes the number of the pgsvrmain’s service port to the client application.
In the host’s netldi -d log, see the following lines:
0: Wed 07 Apr 2004 11:17:07 AM PDT
Reply to client started:
'SUCCESS 35861'
0: Wed 07 Apr 2004 11:17:07 AM PDT
Done writing reply to client.
0: Wed 07 Apr 2004 11:17:07 AM PDT
Disposed. elapsed time = 0
Where 35861 is the port the page server is listening on.
33. Client application connects to Pgsvrmain A (on host) directly on the socket returned by the netldi.
In the host’s pgsvrmain log file, pgsvrmain<pid><hostmachine>.log, see the following lines:
Pgsvrshr is now accepting its client... [11:17:07.82] Network connection has been established. Entering Service Loop ClientPid: 1049
Where 1049 is the pid of the client application.
34. Pgsrvmain B (on host) attaches to the extent file.
In the host’s pgsvrmain log file, pgsvrmain<pid><hostmachine>.log, see the following lines:
Attach SharedPageCache: rep 0 extent 0 numPages 1250, numProcs 249, lockMemory 0, spinLockCount -1,
locationStr <stonename>@<IP address> cacheSlot 5
35. Once all extents are attached, the client application completes login.