Methods and apparatus for managing deactivation and shutdown of a server

• US 5,907,675 A
• Filed: 03/22/1995
• Issued: 05/25/1999
• Est. Priority Date: 03/22/1995
• Status: Expired due to Term

• Current Assignee: Sun Microsystems Incorporated (Oracle Corporation)
• Original Assignee: Sun Microsystems Incorporated (Oracle Corporation)
• Inventors: Aahlad, Yeturu
• Primary Examiner(s): TOPLU, LUCIEN
• Assistant Examiner(s): Park, Alice
• Application Number:
  US08/408,627
• Time in Patent Office: 1,525 Days
• Field of Search: 395/650, 395/700, 395/672, 395/673, 395/674, 395/800, 395/670-678, 395/680.85, 395/200.33, 395/200.57, 364/246.8
• US Class Current: 709/203
• CPC Class Codes: G06F 9/465 Distributed object oriented systems remote method invocation [RMI] G06F9/548

Abstract

A number of methods and apparatus for managing clients of a computer server. In particular, the usher implements an orderly and predictable server deactivation and/or shut down strategy in generally the following manner. The usher continuously maintains a transaction counter indicative of the number of clients actively utilizing services. For example, the usher may increment the transaction counter when a service is requested and then decrement the transaction counter when a service is completed or terminated. However, at some point in the server operation, the usher may receive a lock up request. This may occur because a client has invoked a deactivation and/or shut down operation, or the server may decide to shut down itself. In any event, upon receiving the lock up request, the usher will not perform any new client requests. Thus the usher controls the accessibility of the server to external clients by preventing new client requests for service in preparation for shut down. Nevertheless, the usher utilizes a gentle strategy and only eliminates clients through attrition. Hence the usher implements a shut down strategy which, while not accepting new client requests, will complete any services active at the time deactivation and/or shut down was requested. In some embodiments of the present invention, an usher is an internal component of or is used by a server such as a computer process, a computer service, or a target object.

Claims

1. A computer implemented method for managing clients of a server that is arranged to provide services to a plurality of clients, the server being responsive to service requests from various clients and deactivation requests, the method including the computer controlled steps of:

(a) in response to each service request, determining only once for a particular service request whether the server is in a locked state, wherein when the server is in the locked state the server will reject and not handle the service request and thus the server will never perform a requested service corresponding to the particular service request if the particular service request was received while the server is in the locked state, but, when the server is in an unlocked state, the server will accept and subsequently handle the service request, and incrementing a transaction counter by a predetermined value when it is determined that the server is in the unlocked state, the transaction counter being indicative of the number of service requests actively utilizing the server;

(b) performing the requested service when it is determined in step (a) that the server is in the unlocked state;

(c) decrementing the transaction counter by the predetermined value after each requested service having a corresponding service request that was accepted has been completed;

(d) in response to a deactivation request, setting the server to the locked state and checking the transaction counter to determine whether there are any active service requests prior to deactivating the server; and

(e) when it is determined that there is at least one active service request, waiting to deactivate the server until it is determined based on the transaction counter that all of the active service requests have been completed, wherein the server is deactivated only after it is determined that all of the active service requests have been completed,

whereby when the server is to be deactivated, new service requests are refused since the server is in the locked state and existing service requests are completed prior to deactivation.

2. A computer implemented method as recited in claim 1 wherein the server is a server computer process.

3. A computer implemented method as recited in claim 1 wherein the server is a server object.

4. A computer implemented method as recited in claim 1 wherein the server is a computer service including a plurality of objects.

5. A computer implemented method as recited in claim 1 wherein in response to each service request, the server invokes a check in operation which accomplishes the locked state determining and the transaction counter incrementing steps.

6. A computer implemented method as recited in claim 5 wherein the state of the server is indicated by a lock flag.

7. A computer implemented method as recited in claim 6 wherein the check in operation further comprises a computer controlled step of returning said state of said lock flag to said server.

8. A computer implemented method as recited in claim 6 wherein said check in operation further comprises the computer controlled steps of:

prior to both the locked state determining and the transaction counter incrementing steps, locking a mutex associated with said lock flag and said transaction counter such that said lock flag and said transaction counter are protected from all other computer threads of execution; and

subsequent to both the locked state determining and the transaction counter incrementing steps, unlocking said mutex.

9. A computer implemented method as recited in claim 1 wherein at the completion of each requested service, the server invokes a check out operation which accomplishes the transaction counter decrementing step.

10. A computer implemented method as recited in claim 9 wherein the check out operation further comprises the steps of:

prior to said transaction counter decrementing step, locking a mutex associated with said transaction counter such that said transaction counter is protected from all other computer threads of execution;

subsequent to said transaction counter decrementing step, determining if said transaction counter indicates that there are active service requests;

broadcasting on a condition variable associated with said mutex when it is determined that there are no active service requests; and

subsequent to said transaction counter decrementing step, unlocking said mutex.

11. A computer implemented method as recited in claim 1 wherein in response to a deactivation request, the server invokes a lock up operation which accomplishes the setting the server to the locked state step.

12. A computer implemented method as recited in claim 11 wherein the state of the server is indicated by a lock flag.

13. A computer implemented method as recited in claim 12 wherein the lock up operation accomplishes the setting the server to the locked state step by setting the lock flag.

14. A computer implemented method as recited in claim 13 wherein the lock up operation further comprises the computer controlled steps of:

prior to said setting the server to the locked state step, locking a mutex associated with said lock flag such that said lock flag is protected from all other computer threads of execution; and

subsequent to said setting the server to the locked state step, unlocking said mutex.

15. A computer implemented method as recited in claim 1 wherein in response to a deactivation request, the server invokes a flush operation which performs the checking the transaction counter step.

16. A computer implemented method as recited in claim 15 wherein when it is determined that there is at least one active service request the flush operation further comprises the computer controlled steps of:

blocking a thread of execution associated with said flush operation on a condition variable associated with said transaction counter; and

in response to a broadcast on said condition variable, unblocking said flush operation thread of execution.

17. A computer implemented method as recited in claim 15 wherein when it is determined that there are no active server requests, the flush operation further comprises a computer controlled step of notifying the server that the flush operation is complete.

18. A computer implemented method as recited in claim 15 wherein when it is determined that there are no active server requests, the flush operation further comprises a computer controlled step of deleting the server.

19. A computer implemented method as recited in claim 15 wherein the flush operation further comprises the computer controlled steps of:

prior to said checking the transaction counter step, locking a mutex associated with said transaction counter such that said transaction counter is protected from all other computer threads of execution; and

subsequent to said checking the transaction counter step, unlocking said mutex.

20. A computer implemented method as recited in claim 1 further including a step of setting the server to the unlocked state in response to an activation request.

21. A computer implemented method as recited in claim 20 wherein said server invokes a reopen operation which accomplishes the setting the server to the unlocked state step.

22. A computer implemented method as recited in claim 21 wherein the state of the server is indicated by a lock flag.

23. A computer implemented method as recited in claim 22 wherein the reopen operation comprises the computer controlled step of setting the lock flag to indicate that the state of the server is unlocked.

24. A computer implemented method as recited in claim 23 wherein the reopen operation further comprises the computer controlled steps of:

prior to said step of setting the lock flag, locking a mutex associated with said lock flag such that said lock flag is protected from all other computer threads of execution; and

subsequent to said step of setting the lock flag, unlocking said mutex.

25. A computer implemented method for managing clients of a server that is arranged to provide services to a plurality of clients, the server being responsive to service requests from various clients and deactivation requests, the method including the computer controlled steps of:

in response to each service request, invoking a check in operation, the check in operation including the computer controlled steps of determining only once for a particular service request whether the server is in a locked state, wherein when the server is in the locked state the server will reject and not handle the service request and thus the server will never perform a requested service corresponding to the particular service request if the particular service request was received while the server is in the locked state, but, when the server is in an unlocked state the server will accept and subsequently handle the service request, and incrementing a transaction counter by a predetermined value when it is determined that the server is in the unlocked state, the transaction counter being indicative of the number of service requests actively utilizing the server;

performing the requested service when it is determined that the server is in the unlocked state;

in response to a service request being completed, invoking a check out operation that decrements the transaction counter by the predetermined value;

in response to a deactivation request, invoking a lock up operation that sets the server to the locked state, wherein in the locked state the server completes all active service requests but rejects new service requests;

in response to a deactivation request, performing any necessary deactivation functions and then invoking a flush operation that checks the transaction counter to determine whether there are any active service requests prior to deactivating the server; and

when it is determined that there is at least one active service request, waiting to deactivate the server until after it is determined based on the transaction counter that all of the active services have been completed,

whereby when the server is to be deactivated, new service requests are refused and existing service request are completed prior to deactivation.

26. A computer implemented method as recited in claim 25 wherein the server is selected from the group consisting of a server process, a server object and a computer service comprising a plurality of objects.

27. A computer implemented method as recited in claim 25 wherein the state of the server is indicated by a lock flag.

28. A computer implemented method as recited in claim 27 wherein the check in operation further comprises the computer controlled step of returning said state of said lock flag to said server.

29. A computer implemented method as recited in claim 28 wherein the lock up operation accomplishes the setting the server to the locked state step by setting the lock flag.

30. An usher device for use on a computer system, said usher device being arranged to manage a plurality of clients of a computer server and assist in an orderly shutdown of said computer server, said usher device comprising:

a transaction counter indicative of the number of client service requests actively utilizing said computer server, a client service request that is actively utilizing said computer server being a client service request that has been accepted by the usher but has not yet been completed by the computer server;

a check in device operable to increment said transaction counter by a predetermined value;

a check out device operable to decrement said transaction counter by said predetermined value;

a lock up device operable to lock up said computer server such that when said computer server is locked up it does not accept new client service requests but continues performing any active service requests, whereby said computer server will never perform new client service requests received while the computer server is locked up; and

a flush device operable to shut down said usher device when said computer server is locked up and after waiting until said transaction counter indicates that there are no active service requests, wherein the flush device is operable to deactivate the server when it is determined based on the transaction counter that there are not active service requests.

31. An usher device as recited in claim 30 wherein said flush device is further operable to broadcast to said computer server when it has completed its functions.

32. An usher device as recited in claim 30 further comprising a reopen device operable to unlock said computer server such that said computer server can perform services for said plurality of clients.

33. An usher device as recited in claim 30 wherein said computer server is a computer process.

34. An usher device as recited in claim 30 wherein said computer server is an object.

35. An usher device as recited in claim 30 wherein said computer server is a computer service comprising a plurality of objects arranged to work together to provide services to said plurality of clients.

36. An usher device as recited in claim 30 wherein said usher device is resident within said computer server.

37. An usher device as recited in claim 30 wherein said usher device is resident external to said computer server.

38. An usher device as recited in claim 30 wherein said lock up device includes a lock up flag indicating the state of the computer server.

39. An usher device as recited in claim 38 wherein said lock up device is arranged to set said lock up flag to indicate that the state of the computer server is locked.

40. An usher device as recited in claim 38 further including a mutex associated with said transaction counter and said lock flag.

41. An usher device as recited in claim 40 wherein said check in device is further operable to:

lock said mutex such that said transaction counter and said lock flag are protected from all other threads of execution;

determine the state of said lock flag and, when the state of said lock flag indicates that said computer server is unlocked, increment said transaction counter by said predetermined value; and

unlock said mutex.

42. An usher device as recited in claim 30 further comprising a mutex associated with said transaction counter.

43. An usher device as recited in claim 42 wherein said check out device is further operable to:

lock said mutex such that said transaction counter is protected from all other threads of execution; and

unlock said mutex.

44. An usher device as recited in claim 40 wherein said lock up device is further operable to:

lock said mutex such that said lock flag is protected from all other threads of execution; and

unlock said mutex.

45. An usher device as recited in claim 44 further including a condition variable associated with said transaction counter.

46. An usher device as recited in claim 45 wherein when said transaction counter indicates that there is at least one active service request, said flush device responds by blocking a thread of execution associated with said flush device on said condition variable.

47. An usher device as recited in claim 46 wherein when said transaction counter transitions from indicating that there is one active service request to indicating that there are no active service requests, said check out device responds by broadcasting a thread wakeup call on said condition variable.

48. An usher device as recited in claim 47 wherein said flush device responds to said thread wakeup call by unblocking said thread of execution associated with said flush device.

49. A computer system comprising:

a central processing unit;

a memory device accessed by said central processing unit; and

an usher device as recited in claim 48.

50. A computer system as recited in claim 49 further including an input/output device coupled to at least one of central processing unit and said memory device.

51. A distributed object operating environment comprising:

a plurality of computers as recited in claim 50; and

a computer network interconnecting said plurality of computer systems via the input/output device of each one of said plurality of computer systems.