Method, apparatus and computer program product for automatically restarting an RPC server without losing client RPC calls

[0002] This invention relates, in general, to switching server versions in a distributed environment and, in particular, to providing continuous server service to client calls when switching from a current server version to a new server version.

[0003] In a distributed environment, socket-based server applications or remote procedure call (RPC) servers are generally arranged to receive and subsequently process remotely-made client calls. Typical RPC servers allow for numerous client TCP/IP (Transmission Control Protocol/Internet Protocol) network connections and are implemented to address a large number of client requests. A typical arrangement for these servers is to establish a local network representation by binding a socket to a fixed port which allows client calls to be received by the server.

[0004] From time to time, the servers are required to be updated from a current server version to a new server version in order to enhance server functionality or to address any server problems. These updates are performed by first shutting down the current server version, and subsequently starting the new server version. However, client requests cannot be processed immediately after the current server version stops listening for client requests and closes its socket. Per TCP/IP architecture, before the socket may close, it must wait for a period of time before allowing the local network representation.(i.e., the local IP address and port number) to be reused. This prevents the new server version from immediately binding again to the same fixed port number. Only when the new server version is able to bind to the port number and listen for client calls on the socket can the server process client requests. As a result, any client calls received during this time are unable to be processed by either the current server version or the new server version. Thus, client calls received during this time are not processed and are instead returned to the clients with an error message indicating that the server is not available.

[0005] In mission critical systems, running twenty-four hours a day, seven days a week, continuous service is vital and such a loss of service is not tolerable. Thus a need exists for a system and a method which provide continuous server service during switching from a current server version to a new server version in a distributed environment.

[0006] The shortcomings of the prior art are overcome to some extent through provision of an address reuse socket option which has been implemented to allow the socket associated with the current server version to be reused by the new server version without having to wait for the socket to completely time out. Thus with the address reuse socket option, client calls may be received immediately after the new server version has completed its start up procedures.

[0007] Additional shortcomings of the prior art are overcome and further advantages are provided through the provision of a method of providing continuous server service during switching from a current server version to a new server version in a distributed environment. The current server version receives client calls through an associated static port with a socket bound thereto. The method includes: initiating switching from the current server version to the new server version while maintaining the socket open for receiving client calls; buffering any received client calls during switching from the current server version to the new server version; and upon switching to the new server version, processing any buffered client calls.

[0008] In another aspect of the invention, a method of providing continuous server service during switching from a current server version to a new server version, in a distributed environment, is disclosed. The current server version receives client calls through an associated static port with a socket bound thereto. The method includes: receiving client calls during switching from the current server version to the new server version by leaving the socket open; associating the static port with the socket bound thereto with the new server version; and processing by the new server version, any client calls received during switching so that no client calls are lost.

[0009] In yet another aspect of the invention, a system capable of providing continuous server service during switching from a current server version to a new server version, in a distributed environment is disclosed. The a system includes: a server having a static port with a socket bound thereto which is associated with the current server version, the server being operable to leave the socket open when the current server version is switched to the new server version so that the server is able to continue to receive client calls received through the socket during switching, the server further comprising a buffer adapted to queue client calls received during switching from the current server version to the new server version, wherein the server is adapted to have the new server version process any queued client calls received during switching after switching to the new server is complete.

[0010] In yet another aspect of the invention, a system for providing continuous server service during switching from a current server version to a new server version, in a distributed environment is disclosed. The current server version receives client calls through an associated static port with a socket bound thereto. The system includes: means for initiating switching from the current server version to the new server version while maintaining the socket open for receiving client calls; means for buffering any received client calls during switching from the current server version to the new server version; and means for processing, upon switching to the new server version, any buffered client calls.

[0011] In yet another aspect of the invention, a system for providing continuous server service during switching from a current server version to a new server version, in a distributed environment is disclosed. The current server version receives client calls through an associated static port with a socket bound thereto. The system includes: means for receiving client calls during switching from the current server version to the new server version by leaving the socket open; means for associating the static port with the socket bound thereto with the new server version; and

[0012] means for processing, by the new server version, any client calls received during switching so that no client calls are lost.

[0013] In yet another aspect of the invention, an article of manufacture is provided. The article of manufacture comprises a computer useable medium having computer readable program code means embodied therein causing the providing of continuous server service during switching from a current server version to a new server version, in a distributed environment, where the current server version receives client calls through an associated static port with a socket bound thereto. The computer readable program code means in the article of manufacture includes: computer readable program code means for causing initiating switching from the current server version to the new server version while maintaining the socket open for receiving client calls; computer readable program code means for causing buffering of any received client calls during switching from the current server version to the new server version; and computer readable program code means for causing, upon switching to the new server version, processing of any buffered client calls.

[0014] In yet another aspect of the invention, an article of manufacture is provided. The article of manufacture comprises a computer useable medium having computer readable program code means embodied therein causing the providing of continuous server service during switching from a current server version to a new server version, in a distributed environment, where the current server version receives client calls through an associated static port with a socket bound thereto. The computer readable program code means in the article of manufacture includes: computer readable program code means for causing receiving client calls during switching from the current server version to the new server version by leaving the socket open; computer readable program code means for causing associating of the static port with the socket bound thereto with the new server version; and computer readable program code means for causing processing, by the new server version, of any client calls received during switching so that no client calls are lost.

[0015] Thus, presented herein is a method and system for providing continuous server service during switching from a current server version to a new server version. In order to provide such continuous server service the method and the system leave open sockets associated with the current server version during switching from the current server version to the new server version so that client calls made during switching continue to be received. In addition, leaving open the socket associated with the current server version allows the new server version to utilize the socket without having to perform standard startup procedures. Furthermore, any client calls received during switching are buffered so that they may be subsequently processed by the new server version upon completion of switching. By buffering the client calls made during switching and subsequently processing the buffered client calls, no client calls are returned with error messages to their respective clients. Hence, in the present invention, no client calls are lost during switching and, as a result, server versions may be updated to enhance functionality and to address server problems with the appearance of continuous server service.

[0016] Additional features and advantages are realized through the techniques of the present invention. Other embodiments and aspects of the invention are described in detail herein and are considered a part of the claimed invention.

[0017] The subject matter which is regarded as the invention is particularly pointed out and distinctly claimed in the claims at the conclusion of the specification. The foregoing and other objects, features, and advantages of the invention are apparent from the following detailed description taken in conjunction with the accompanying drawings in which:

[0018] FIG. 1 depicts one example of a distributed environment implementing and using the continuous server service of the present invention;

[0019] FIG. 2 depicts one example of a logic block diagram for providing continuous server service, in accordance with the principles of the present invention;

[0020] FIG. 3 depicts a time line illustrating one process example of providing continuous server service, in accordance with the principles of the present invention;

[0021] FIG. 4 depicts a time line illustrating one process example of switching server versions; and

[0022] FIG. 5 depicts a time line illustrating another process example of switching server versions.

[0023] In accordance with the principles of the present invention, continuous server service is provided during switching from a current server version to a new server version. One example of a distributed environment incorporating and using the present invention is described in detail with reference to FIG. 1.

[0024] FIG. 1 depicts one example of a distributed environment 100 incorporating the continuous server service of the present invention. In this embodiment, distributed environment 100 includes a server 110 which is implemented to run a current server version 120. In addition, distributed environment 100 also includes a plurality of client systems 152, 154, 156 which are connected to server 110 via a plurality of network connections 153, 155, 157. Each of these network connections 153, 155, 157 is connected at one end to a client system 152, 154, 156 and at an opposite end to server 110 through an open socket 140 associated with current server version 120. Beside being associated with current server version 120, socket 140 is also bound to a static port (not shown), and is “listened on” by current server version 120. Thus through the implementation of this particular example, client calls made by client systems 152, 154, 156 to server 110 are transmitted through network connections 153, 155, 157 to the static port and socket 140, where they are received by server 110 and processed by current server version 120.

[0025] During the course of operation, as noted above, it often becomes necessary to update the current server version 120 in order to, for example, implement enhanced functionality provided by a new server version 130. In accordance with the principles of the present invention, this updating generally involves switching from current server version 120 to new server version 130 while leaving open socket 140. This process is described in greater detail below with reference to FIG. 2.

[0026] Referring now to FIG. 2, which illustrates one example of the present invention, STEP 210 denotes an action or request to deactivate and restart server 110 with new server version 130. In particular, server 110 commences or initiates switching upon the detection of such a request or action. In one embodiment, these detections or checks occur based on two independent schedules or detection schemes. Specifically, a first check is made after each client call is dispatched to be processed by server 110, and if a restart request is detected, the client call is processed and then restart is commenced. In addition to this first check, a periodic second check is also made according to a timer or timer thread so that restart requests may be detected in the absence of client calls.

[0027] After initiating switching, socket 140 (which as mentioned above is associated with current server version 120) is left open, STEP 220. At the same time, current server version 120 stops listening on socket 140 and deactivation and activation of current server version 120 and new server version 130 are respectively commenced.

[0028] By leaving socket 140 open with the respective commencement of deactivation and activation of current server version 120 and new server version 130, client calls made after initiating switching are not returned with error messages to the client systems 152, 154, 156. Instead, the client calls continue to be received by server 110 through socket 140. However, because current server version 120 has commenced deactivation, client calls made after the initiation of switching to new server version 130 are not able to be processed by current server version 120. Likewise, because new server version 130 has not yet completed activation, the same client calls are also not yet able to be processed by new server version 130. Thus, in accordance with the principles of the present invention, these client calls made after the initiation of switching and before the completion of switching are buffered by server 110, STEP 230. In this particular example, the client calls are buffered in a queue associated with the static port and socket 140.

[0029] In addition to the buffered client calls received after initiation of switching and before completion of the activation of the new server version 130, some additional client calls received before the initiation of switching may also need to be addressed. In this regard, client calls received by server 110 before the initiation of switching are typically processed in an orderly manner by current server version 120. But because it is not known when a restart request will be received and because the time required to fully process a client request varies according to the services required by the particular client call, it is conceivable that restart requests could be received while a client call is in the middle of being processed. In these cases, the client calls will not yet have had an opportunity to be fully processed when switching commences. To address this issue, current server version 120 remains active long enough, after switching initiates, to finish processing any client calls received before the initiation of switching, STEP 240. In this manner, client calls received before the initiation of switching, which are not yet fully processed, are not lost during switching.

[0030] Switching from the current server version 120 to the new server version 130 subsequently continues with server 110 determining whether switching was initiated by a restart procedure, INQUIRY 250. If server 110 determines that switching was not initiated by a restart procedure, for example because switching was initiated by an actual startup request, server 110 follows standard startup procedures (e.g., open new socket, bind port to socket, and listen on new socket), STEP 260. On the other hand, if server 110 determines that switching was initiated by a restart procedure, the static port and socket 140 are associated with the new server version 130, STEP 270. Specifically, before current server version 120 completes deactivation, current server version 120 saves information including socket descriptors relating to the identification of the socket 140. Furthermore, the socket descriptors of any open sockets are saved. After saving these socket descriptors, current server version 120 completes deactivation. These socket descriptors are then retrieved by new server version 130 and are used by new server version 150 to identify socket 140 (or any other sockets which may have been open). Socket 140, along with the static port bound thereto, are then associated with new server version 130. Thus by saving and later retrieving the socket descriptors, the socket descriptors may be utilized by the new server version 130 to reuse socket 140 (and any other open sockets) and hence new server version 130 avoids having to open a new socket during which time incoming client calls would be lost.

[0031] After associating the static port and socket 140 with the new server version 130, new server version 130 begins listening on socket 140 and processes the buffered client calls received after initiating switching, STEP 280. Shortly afterwards, switching and activation of new server version 130 become complete and server 110 resumes processing client calls and again begins to check for restart requests.

[0032] Examples of the continuous server service capability of the present invention are now discussed with reference to the time lines depicted in FIGS. 3-5. Initially, times T0-T6 in each of FIGS. 3-5 are identical, and in this regard, times T0-T4 illustrate a standard startup procedure. In particular, a request to start server 110 is received at time TO and is followed by the activation of server 110 running current server version 120 at time T1. At time T2, socket 140 is opened, and is subsequently bound to the static port at time T3. After socket 140 is bound to the static port, current server version 120 begins listening on socket 140, denoted by time T4, and the activation of server 110 becomes complete. Therefore, in each of FIGS. 3-5, client calls begin to be received after time T4.

[0033] Times T5 and T6 in each of FIGS. 3-5 are also identical and illustrate the initial steps of the updating or switching procedure. Specifically, a request to switch from current server version 120 to new server version 130 is detected by server 110 at time T5, and as a result causes server 110 to initiate switching. Subsequent to the initiation of switching, current server version 120 stops listening on socket 140, time T6. Consequently, as current server version 120, in each of FIGS. 3-5, begins listening on socket 140 at time T4 and does not stop listening until time T6, any client calls made between time T4 and time T6 will be received and processed by current server version 120.

[0034] Focusing now on FIGS. 4 and 5, times T7-T10 illustrate the completion of deactivation of current server version 120 and the initial steps of activation of new server version 130. At time T7, current server 120 closes socket 140 and as a result causes client calls received at that time to be rejected with a communication error. Sometime after time T7, current server version 120 completes deactivation, denoted in FIGS. 4 and 5 as time T8, and new server version 130 begins activation, denoted in FIGS. 4 and 5 as time T9. In addition, although FIGS. 4 and 5 show completion of deactivation of current server version 120 time T8 occurring before initiation of activation of new server version 130 time T9, the order of the two steps may be reversed. Next, at time T10, new server version 130 opens a new socket (not shown) which will, in turn, be used to receive client calls as discussed below.

[0035] Focusing again on FIGS. 4 and 5, times T11-T13 illustrate the completion of activation of new server version 130 and also the completion of switching. Addressing, first, the example shown in FIG. 4, before the new server version 130 of FIG. 4 may begin receiving client calls, two requirements must be satisfied. Specifically, socket 140 must first be closed or “timed out” to free up-or make available the static port, and then, the static port must be bound to the new socket. Thus, in the example of FIG. 4, socket 140 is timed out at time T11, and then, the static port is bound to the new socket at time T12. To complete the activation of new server version 130 and hence to complete switching, new server version 130 associates itself with the static port and the new socket at time T13. At that time, new server version 130 begins listening on the new socket, and also subsequently begins receiving client calls, and processing newly received client calls. Thus, as client calls are not received by new server version 130 until time T13, in the example of FIG. 4, client calls made between time T6, when current server version 120 stops listening on socket 140, and time T13 are rejected with communication errors and are not processed. Finally, although FIG. 4 shows socket 140 timing out after time T10, the exact occurrence of time out T11 may occur any time after time T7.

[0036] Addressing, next, the example shown in FIG. 5, a socket address reuse option is utilized and, as a result, alleviates the need for socket 140 to time out before the static port may be bound to the new socket. Hence, in this example, the static port is bound to the new socket at time T12 without having to wait for socket 140 to time out. Then at time T13, new server version 130 associates itself with the static port and the new socket, and, like the example of FIG. 4, begins listening on the new socket, receiving client calls, and processing newly received client calls, thereby completing activation. Thus, as with the example of FIG. 4, client calls made between time T6 and T13 are rejected with communication errors and are not processed.

[0037] Turning now to the example illustrated in FIG. 3, after current server version 120 stops listening on socket 140 at time T6, socket 140 is not closed, as was the case in the examples of FIGS. 4 and 5. Instead, socket 140 remains open and calls received after time T6 are buffered by server 110. Consequently, client calls received after time T6 are not rejected with communication errors. Then, subsequent to time T6, the example of FIG. 3 proceeds with the completion of deactivation of current server version 120, denoted by time T8, and with the initiation of activation of new server. version 130, denoted by time T9. Also at this time, during this deactivation and activation, the socket descriptor of socket 140 is saved by current server version 120 and later retrieved by new server version 130 for use in reusing socket 140. Furthermore, as with the examples of FIGS. 4 and 5, although FIG. 3 shows the completion of deactivation of current server version 120 time T8 occurring before the initiation of activation of new server version 130 time T9, the relative order of the two steps may be reversed. Then at time T10, using the socket descriptor saved by current server version 120, new server version 130 associates itself with socket 140 and the static port, and subsequently begins listening on the new socket, receiving client calls, and processing newly received client calls. However, in addition to beginning to listen on socket 140, the example of FIG. 3 also processes any client calls buffered between time T6 and time T10. As a result, no client calls are rejected, and continuous server service is provided.

[0038] The present invention can be included in an article of manufacture (e.g., one or more computer program products) having, for instance, computer usable media. The media has embodied therein, for instance, computer readable program code means for providing and facilitating the capabilities of the present invention. The article of manufacture can be included as a part of a computer system or sold separately. Additionally, at least one program storage device readable by a machine, tangibly embodying at least one program of instructions executable by the machine to perform the capabilities of the present invention can be provided.

[0039] The flow diagrams depicted herein are just exemplary. There may be many variations to these diagrams or the steps (or operations) described therein without departing from the spirit of the invention. For instance, the steps may be performed in a differing order, or steps may be added, deleted or modified. All of these variations are considered a part of the claimed invention.

[0040] Although preferred embodiments have been depicted and described in detail herein, it will be apparent to those skilled in the relevant art that various modifications, additions, substitutions and the like can be made without departing from the spirit of the invention and these are therefore considered to be within the scope of the invention as defined in the following claims.