KR20010041297A - Method and apparatus for the suspension and continuation of remote processes - Google Patents

Abstract

A method and apparatus are provided for enabling blocked remote methods to transfer threads and other resources to remote methods on a server system. In a distributed computing environment, remote methods are numerous network resources, but are blocked while waiting for operations such as waiting from other processes. If enough remote methods are blocked, threads and other network resources can be exhausted. Client systems that require server services may experience slower response times. This method and system provides a technique for relinquishing network resources such as threads so that remote methods can use other methods while the methods are blocked. Once the condition that causes the remote method to be blocked is released, the remote method continues executing. This technology enables large client-server transaction systems to utilize threads and other resources more efficiently in a distributed computing environment.

Description

METHODE AND APPARATUS FOR THE SUSPENSION AND CONTINUATION OF REMOTE PROCESSES

As the distributed computing paradigm is increasingly used, it is becoming increasingly important that resources on server systems become available to satisfy requests by client systems. Each request from a client typically causes a server process that handles a resource that includes one or more threads to process this request. A thread, often called a lightweight process, is a separate sequence of instructions within a process with separate control flows. A thread must run resources from the system as needed to satisfy a particular request. If resources such as memory and data are available, multiple threads can run in parallel to satisfy multiple tasks.

By a process that coordinates the parallel execution of threads based on the thread's priority, execution state (ie sleep, alive, dead, running) and dependencies between the various threads Thread schedulers can be used. The thread scheduler on a single process system distributes the processor's computing power among many threads to provide the illusion that threads actually execute in parallel. Many different scheduling methods that can be used, including first-come-first-served, shortest-thread-first, priority scheduling, and preemptive scheduling techniques such as round robin. Techniques exist. Hybrid scheduling techniques may also be used that combine these techniques as needed by a particular implementation. In a multiprocessor system, the scheduler associates different threads with different processes, executes the threads in parallel, and uses the added computing power.

Unfortunately, if these resources were immediately available, the thread could not continue execution and would be blocked from further processing. This blocked thread of execution is held on server resources such as memory as well as the data and control structures associated with its thread. Ultimately, the server can run out of threads and allocate incoming client requests. Incoming client requests can be reused and the server will be effectively removed from the distributed computing environment. This blocking scenario can also reduce the server's ability to service existing requests due to the overhead associated with the service rejecting incoming calls.

Existing distributed computing systems are not intended to correct this problem of allocating threads. These systems do not release threads and associated resources when the remote server process is blocked waiting for resources or specific events. As a result, a distributed computing environment in which transactions are the focus may have the blocking scenario problem described above. For example, suppose a server process receives a number of requests to download a file from a number of clients over the Internet. The server process receives multiple threads from the server operating system and processes the requests in parallel, but the requested file is locked by another processor and cannot be used. The conventional system would block the secondary processing for each thread and wait for the file to not be locked. Threads on the server will remain idle even if other processes can use the thread resources to handle other tasks. If a large number of threads on the server system are exhausted, the server process will deny service to incidental clients. Ultimately, server systems will have difficulty handling common tasks.

On many distributed computing systems, the inability to allocate threads and other resources will negatively impact overall processing yield. Although threads and other resources are not efficiently located on server systems, even the high speed bands available in distributed computing networks will not be used.

Based on the above problems found in conventional systems, it is desirable to improve the allocation of threads and other resources used in a distributed computing environment.

The present invention provides a typical distributed computing system in which the computing power of a server and many servers is made available to many different clients over a network. Typically, a client machine uses a remote procedure call (RPC) system to access processing credentials on a server machine. The RPC system processes the request for the remote machine and returns the desired result to the requesting client. The network used to send the request and return the results may be a local area network (LAN), a broadband network (WAN), and may also include the Internet. Advanced distributed computing applications on the Internet use this client-server configuration to provide e-commerce, telecomputing, and interactive entertainment services around the world.

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate some embodiments in accordance with the invention, and together with the description serve to explain the subject matter of the invention.

1 is a network diagram suitable for use in the method and system according to the present invention.

2 is a block diagram of a computer system suitable for use in the method and system according to the present invention.

3 is a block diagram of a client-server networking environment suitable for use in the method and system according to the present invention.

4 is a block diagram of a subsystem used to abort and continue remote method call processing in accordance with the method and system of the present invention.

5 is a flow chart of the steps performed to abort the remote method call processing in accordance with the method and system of the present invention.

6 is a flow chart of the steps performed to abort a remote method call in accordance with the method and system of the present invention.

7 is a flow chart of the steps performed to continue a remote method call in accordance with the method and system of the present invention.

According to the present invention, as illustrated and broadly described herein, a method and apparatus for enabling a remote method to stop processing and transfer resources to a server system receives a request from a remote method call on a client system. It involves doing. One system-level kind of resource is a thread. This method determines whether any general resources needed to process the remote method are currently not available. A general resource can be any resource on which memory, disk storage, data or system resources may depend. When a remote method relies on general resources that are not available, the remote method is suspended from incidental processing and system resources are transferred to the server system.

The method according to the invention enables previously interrupted remote methods to continue processing for the server system and to generate results for the client application. The method includes receiving an indication that a continuation event associated with a suspended remote method has occurred. System resources and general resources are allocated to remote methods that are prepared to continue processing remote methods. The remote method uses the allocated allocated resources to continue execution and produce the result. These results are sent from the server system to the client application on the client system using a remote procedure call (RPC) system such as remote method call (RMI).

Embodiments of the present invention will now be described in detail with reference to the accompanying drawings. Like reference numerals will be used throughout the drawings and the description to refer to the same or like parts.

The system according to the invention assumes that a computer system can manage client or server functions. These roles assumed by each computer in the computer system depend on the particular call made between the client and server. For example, client processes typically request services generated by server processes located on remote machines. Conversely, the server process is located on the machine that receives the client request and services it. Thus, the same computer system can act as a client when requesting a service and as a server when satisfying a request for a service.

The system according to the invention corrects the disadvantages of the prior art and provides a method and apparatus for interruption and continuation of a remote process. In the past, remote procedure call (RPC) systems did not enable remote processes to release resources while they were blocked waiting for events to occur or resources to be released. This technique keeps the connection between the client process and the server process active, but keeps critical resources such as threads, memory, and auxiliary memory idle. In contrast, the system according to the present invention enables a remote server process that is blocked from incidental processing to transfer threads and other resources without dropping the connection between the client and the server system. This new technology allows other processes to use server resources even when the remote process is blocked. In particular, this prevents remote server processes from denying clients access to the system. As a result, embodiments of the present invention increase the effective yield of distributed computing systems by using threads and other resources more efficiently.

Incidentally, the system according to the invention is also advantageous in that it is compatible with clients on existing client-server systems. This is particularly important in heterogeneous network computing environments such as the Internet. Since the server is modified to allocate and retrieve resources more efficiently, the present invention does not affect the design and operation of the client system. Thus, the client will not need modifications to work with the system designed according to the present invention.

Overview of Distributed Systems

The method and system according to the present invention operate in a distributed system ("exemplary distributed system") having various components including both hardware and software. An example distributed system includes (1) tools and programming patterns that enable users of the system to share services and resources across a network of devices, and (2) to enable the development of reliable and secure distributed systems. Programmers, and (3) simplify the task of managing distributed systems. To achieve this goal, an exemplary distributed system utilizes a Java ^™ programming environment that allows both code and data to be moved from device to device in a consistent manner. Thus, an exemplary distributed system is layered on top of a Java programming environment and exploits the characteristics of the environment, including the security provided by it and the strong typing provided by it. The Java programming environment is described more clearly in Jaworski, Java 1.1 Developer's Guide, Sams.net (1997), incorporated herein by reference.

In an example distributed system, different computers and devices are integrated into what appears to the user as a single system. By making it appear to be a single system, the example distributed system provides the simplicity and sharing of access that can be provided by a single system without giving up the flexibility and customization response of a personal computer or workstation. The example distributed system is graphically distributed, but may include a number of devices operated by users that meet basic annotations of trust, administration, and policy.

Within the exemplary distributed system there are various logical groupings of services provided by one or more devices, each such logical grouping known as Djinn. A "service" refers to a resource, data, or function that may be accessed by a user, program, device, or other service and that may be related to computing, storage, communication, or providing access to another user. Examples of services provided as part of Djinn include devices such as printers, displays, and disks; And software such as programs or utilities; Information such as databases and files; And a user of the system.

Both the user and the device can be Djinn. Combining Djinn, a user or device adds zero or more services to Djinn, and can access any of the services included under security restrictions. Thus, the device and the user are integrated into Djinn for access to the service. Djinn's services appear programmatically as objects in the Java programming environment that may include other objects, software components or hardware devices written in different programming languages. The service has an interface that defines the operations that can request the service, and the type of service determines the interface that composes the service.

1 illustrates an example distributed system 100 that includes a computer 102, a computer 104, and an apparatus 106 interconnected by a network 108. Device 106 may be any of many devices, such as a printer, fax machine, storage device, computer, or other device. The network 108 may be a local area network, a broadband network or the internet. Although only two computers and one device are shown to constitute the exemplary distributed system 100, those skilled in the art will appreciate that the exemplary distributed system 100 may include additional computers or devices. will be.

2 depicts a computer 102 detailing many of the software components of the example distributed system 100. Those skilled in the art will appreciate that computer 104 or device 106 may be similarly configured. Computer 102 includes memory 202, auxiliary storage 204, central processing unit (CPU) 206, input device 208, and video display 210. Memory 202 includes lookup service 212, discovery server 214, and Java ^™ runtime system 216. The Java runtime system 216 includes a Java ^TM remote method call (RMI) system 218 and a Java ^TM virtual machine 220. The secondary storage 204 includes a JavaSpace ^TM 222.

As noted above, the example distributed system 100 is based on a Java programming environment and thus uses the Java runtime system 216. Java runtime system 216 includes a Java ^TM API that enables programs running on top of the Java runtime system to access various system functions, including the windowing and networking capabilities of the host operating system, in a platform-independent manner. do. Because the Java API provides a single common API across all operating systems on which the Java runtime system 216 is ported, programs running on top of the Java runtime system are platform independent regardless of the operating system or hardware configuration of the host platform. Run Java runtime system 216 is provided as part of a Java software development kit available from Sun Microsystems, Inc., Mountain View, California.

Java virtual machine 220 also facilitates platform independence. The Java virtual machine 2200 behaves like an abstract computing machine that receives instructions from a program in the form of bytecodes, dynamically converts these bytecodes into execution forms such as object code, and interprets them by executing them. RMI 218 facilitates remote method invocation by having an object running on one computer or device invoke a method of an object running on another computer or device. Both RMI and the Java Virtual Machine are provided as part of the Java Software Development Kit.

Lookup service 212 defines the services available to a particular Djinn. That is, there may be one or more lookup services in one or more Djinn, eventually exemplary distribution systems 100. Lookup service 212 includes one object for each service in Djinn, and each object includes various methods that facilitate access to the corresponding service. Lookup service 212 is described in detail in currently pending US patent application Ser. No. 09 / 044,826 entitled "Method and System for Facilitating Access to a Lookup Service", which is incorporated herein by reference.

The discovery server 214 detects when a new device is added to the distributed system 100 during a process called associating or discovery with the boot, and when such a new device is detected, the discovery server can service the lookup service to the new device. By passing a reference to 212, the new device registers the service with the lookup service, allowing it to become a member of Djinn. After registration, the new device becomes a member of Djinn and, in turn, can access all services included in lookup service 212. The process of booting and combining is described in US patent application Ser. No. 09 / 044,939 entitled "Apparatus and Method for providing Downlodable Code for Use in Communicating with a Device in a Distributed System", which is incorporated herein by reference.

JavaSpace 222 is an object store used by a program in an example distributed system 100 that stores objects. Programs use JavaSpace 222 to persistently store objects as well as make them accessible to other devices in the example distributed system. JavaSpace is currently pending US patent application Ser. No. 08 / 971,529 entitled "Database System Employing Polymorphic Entry and Entry Matching" (filed Nov. 17, 1997), assigned to the assignee of the present invention and incorporated herein by reference. It is explained in detail in. Those skilled in the art will appreciate that the exemplary distributed system 100 can include a lookup service, discovery server, and JavaSpace.

Although the systems and methods according to the present invention have been described as operating in an exemplary distributed system and Java programming environment, those skilled in the art will appreciate that the present invention may be practiced in other systems and other programming environments. Incidentally, although the features of the present invention have been described as being stored in a memory, those skilled in the art will also appreciate that such features may also be used in various types of computer readable media such as auxiliary storage devices such as hard disks, floppy disks or CD-ROMs. ; Carrier from the Internet; Or it may be stored on or read from other forms of RAM or ROM. Sun, Sun Microsystems, Inc., Sun Logo, Java, and trademarks based on Java are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.

Example Client-Server System

3 illustrates a client-server system and an exemplary distributed system 100 in accordance with the present invention. Accordingly, the client-server system 300 may include a client computer 302 called client 302, a server computer 312 referred to as server 312, and a network 310 coupled between client 302 and server 312. It is composed of This particular client-server system can be implemented using the Java ^TM object oriented language. However, those skilled in the art will appreciate that they may be practiced using general purpose remote procedure call (RPC) systems and other object and non-object oriented languages.

Client 302 has a client application 304 having a remote method call 306, a remote stub 308, and a remote method runtime 309. The client application 304 is typically software developed by the user and has a remote method call 306 to call a process for the server 312. For example, client application 304 may be a Java ^™ application written in the Java ^™ programming language. Remote method call 306 may be implemented using an RPC mechanism such as RMI.

The remote method stub 308 marshals data and parameters provided by the remote method call 306. The data and parameters are arranged in a predetermined format that can be unmarshalled by the remote method skeleton 315 on the server 312. The remote method runtime 309 tracks the state of the process associated with the remote method call 306 as it is processed for the server 312. The remote method runtime 309 also determines whether the communication link between the client application 304 and the server 312 is connected or shorted. The remote method runtime 309 can query the server 312 for the status of the link. If no response is made within the appropriate time period, or if server 312 indicates that the link is short, remote method runtime 309 notifies the client application that the remote method call has ended.

The network 310 provides a communication link between the client 3020 and the server 312. The network 312 may be the Internet or an intranet of a company or school.The network 310 may be TCP / IP, or Novell Netware, AppleTalk. Any other network protocol may be used, including any other network capable of supporting an RPC system such as X, 25 or RMI.

Server 312 includes corresponding remote method runtime 314 and remote method skeleton 315. In contrast to the client 302, the server 312 also includes a general purpose resource manager 316, an event handler 317, a remote method resource manager 322, a remote event handler 323, and many remote method resources 324. It includes. Server 312 also includes a remote object A 318 and a remote object B 320. Each remote object is associated with a number of methods (not shown) that the client application 304 can call using the remote method call 306. Alternate configurations of server 312 may include any number of remote methods for performing remote methods, if desired by a particular system.

The remote method runtime 314 is responsible for continuously notifying the client 302 of the remote method execution status. The remote method runtime 314 provides the client 314 with information indicating that the remote method is processing data. According to the present invention, the processing state is not interrupted even when the remote method is interrupted. Instead, the remote method runtime 314 maintains a connection with the client 302 until the remote method completes processing the requested task. The remote method runtime 314 also points to the client 302 even when the remote method ends abnormally or is an error.

The method determines whether any general resources needed to process the remote method are not currently available. A general resource can be any resource on which memory, disk storage, data or system resources may depend.

The remote method Skelton 315 is responsible for unmarshalling data and parameters transmitted over the network 310. Parameters and data are used as arguments for executing remote methods on the server 312.

The general purpose resource manager 316 and the event handler 317 manage resources used by local processes and methods executed on the server 312. Local methods executed on server 312 refer to general resource manager 316 and event handler 317 to coordinate the allocation and retrieval of generic resources. These common resources may include main storage, such as memory, or auxiliary storage, such as disk and tape drives. Unlike the system resources described below, generic resources are typically not used to satisfy remote method requests. The event handler 317 detects an event associated with the local process, so the details of the event handler 317 are not included herein. Essentially, general purpose resource manager 316 and event handler 317 are used solely to manage resources associated with processes and methods that are not invoked remotely from a client, such as client 302.

In contrast, remote method resource manager 322 and remote event handler 323 are responsible for allocating and retrieving remote method resource 324 if needed by the remote method. The remote method resource 324 may be considered to be a system resource because it enables the method to use system level resources such as networking. Often, system resources will have dependencies on the general resources described above.

The remote method resource manager 322 transfers the remote method resource 324 between the remote method 318, the remote object 320, and the remote method associated with another object (not shown). The remote event handler 323 detects when the resource is released so that the remote method needs to handle a particular task. Passing these remote method resources is facilitated using embodiments of the present invention as described below.

Stopping and continuing the remote method

The suspend method is called when the remote method is about to be blocked. This typically occurs just before the remote method is blocked waiting for a resource to become available. The abort method marks the remote method as suspended, and the remote method resource manager returns threads and other resources back to the server system. Once the resource is available, the remote method resource manager and the continuous method work together to allocate threads and other remote method resources to the suspended remote method. Ultimately, the remote method runtime calls the suspended remote method so that it can continue processing. For example, a remote method waiting for a write operation enters a blocking state preparation and transfers threads and other resources by invoking the interrupted operation. The aborted operation marks the remote method as aborted, and the remote method resource manager returns the thread to the thread pool associated with the server system. Once the write operation occurs, the continuous method marks the suspended remote method as executable, the remote method resource manager allocates a thread, and then allocates another resource to the suspended remote process. The remote method runtime invokes a previously suspended remote method that enables the remote method to read data.

4 is a block diagram illustrating the essential software subsystem used to abort and continue remote method processing. This software subsystem has a remote method resource 324, a remote method resource manager 322, and an example resource object A 318 having a remote method 416 and an execution state 418.

The remote method resource 324 of FIG. 4 includes a thread pool 402 having a thread 404 in use, a thread 406 available, and an RPC state 408. The thread in use 404 contains a reference to the thread currently being used by the remote method while the available thread 406 includes the thread currently available for use by the remote method. The RPC state 408 is maintained at the remote method resource 324 to store information used by the RPC system, such as RMI, when the remote method is interrupted. This information includes information about the RPC system to continue processing aborted remote methods and return the results to the client. In alternative embodiments, remote method resource 324 may also include resources other than threads. These other network resources may include main storage, auxiliary storage, and any other resources used to combine with processing remote methods.

The remote method resource manager 322 includes an abort method 410, a continuous method 412 and a state store 414. The abort method 410 includes an execution state 418 from the remote method 416, and an RPC state 408 from the remote method resource 324. This state information is stored in the state store 414 before the remote method 416 is stopped. Typically, the abort method 410 marks the remote method 406 as suspended when it indicates that the remote method 416 is about to be blocked and that it has threads and other resources. Ultimately, remote method resource manager 322 returns threads and other resources to server 312, and remote method 416 stops further processing. For example, assume that remote method 416 attempts to read data from a temporarily empty queue. If the remote method 416 detects that the queue is empty, the remote method 416 will call the abort method 410 to initiate the abort process.

Continuous method 412 is a companion to abort method 410. Typically, continuous method 412 is called when resources are available or when a particular event occurs. For example, by writing data to a specific queue, one can trigger a continuous event that can call the continuous method 412. Continuous method 412 finds the suspended remote method waiting for the resource and marks it as executable. Ultimately, remote method resource manager 322 allocates threads and other resources to previously interrupted remote methods. The execution state 418 and the RPC state stored in the storage 414 are used to ensure that processing continues at a suitable point in time before the remote method 416 is interrupted.

In operation, the abort and contiguous methods are used together to manage threads and other resources on the server system 312. 5 is a flow chart illustrating the steps performed to abort and continue a remote call in accordance with the method and system of the present invention.

Initially, server 312 receives a request from remote method call 306 on client 312 to process remote method 416. Thus, the remote method skeleton 315 unmarshals the data and parameters sent in the request (step 506). After the data and parameters are decoded by the remote method skeleton 315, it is passed to the remote method 416.

The remote method runtime 314 on the server 312 indicates to the remote method runtime 309 on the client 302 that the server 312 has received a request to call the remote method 416 and is processing the request ( Step 507). The client application 304 continues to receive an indication that the server is processing the request even when the remote method 416 has stopped and the thread and other resources have been transferred.

The remote method resource manager 322 assigns threads and other resources to the remote method 416 that is about to be called (step 508). The thread assigned to the remote method 416 is retrieved from the available thread 406 in the thread pool 402. Multiple threads can be used to process several remote methods or tasks in parallel. Assuming threads and other resources are available, the remote method runtime 314 calls the remote method 416 instead of the client application 304 (step 510). If the remote method resource manager cannot allocate a thread or other resource to the remote method 416, it is placed on a run queue that queues the release of another resource or thread from another process.

The remote method 416 includes instructions for determining whether a break state exists (step 512). These instructions also include information to determine whether a continuous state exists. Termination status occurs when the remote method 416 relies on resources that are not available or events that have not yet occurred. In contrast, a continuous state occurs when a resource is available or when an event occurs. As an interruption state example, assume that the remote method 416 samples the data points and stops the long time period between each sampling. During this long interruption, the remote method 416 may block waiting for a timer event indicating the end of the next time period.

If a stall condition is detected, remote method 416 transfers resources and registers a continuous instruction with remote event handler 323 to monitor for any resources and events (step 516). Next, the remote method 416 stops from further processing and waits for a particular continuous event to continue processing (step 518).

If a continuation event occurs, resources are allocated to the remote method, and the remote method resumes processing (step 520). A continuous event is an event that is raised when an event occurs when a resource becomes available or when a suspended remote method follows additional processing. The remote event handler 323 processes subsequent commands registered by the aborted remote method 416. The remote method completes the task and returns the result back to the client application 304 (step 514). It should be noted that remote methods can be aborted and contiguous before completing work and returning results to the client.

Break of remote method

6 is a flowchart of steps performed to abort a remote call in accordance with the method and system of the present invention. Initially, the remote method 416 detects that a break event has occurred and chooses to relinquish the thread and other resources (step 602). The remote method is marked as aborted by abort method 410. Before being aborted, the remote method 416 provides the remote method resource manager 322 with an execution state 418, an RPC state 408, and relinquishes threads and other resources (step 604). The remote method resource manager 322 relocates these threads back to the available thread 406. Optionally, the remote method 416 may choose to abort processing without transferring any threads or resources.

Execution state 418 records state information related to remote method 418, including local variables related to remote method 416, program counters, and any other information when interrupted. As discussed above, the RPC state 408 records state information associated with the RPC system, such as RMI, when the remote method 416 is interrupted. RPC state 408 enables the RPC system to communicate with the client and return a result when the remote method 416 continues executing.

Next, origin method resource manager 322 stores RPC state 408 and execution state 418 (step 608). The remote method resource manager 322 stores this state information in order to continue processing the remote method that was interrupted at some point in the future. The remote method 416 also registers a serial command with the remote event handler 323, which optionally monitors resources and events. In general, continuous instructions are used to preprocess the data and to contact the appropriate interrupted process. Finally, the remote method 416 blocks from further processing and waits for a continuous event to occur (step 610).

Sequence of remote methods

7 is a flowchart of the steps performed to continue a previously interrupted remote method, such as remote method 41, in accordance with the method and system according to the present invention. Typically, each step of this process occurs asynchronously as certain conditions are met.

Initially, the remote event handler 323 receives an indication that a particular status event has occurred. The remote event handler 323 associates the continuous event with a particular remote method (step 702) and invokes the corresponding continuous command. A continuous event is an event that is generated when a resource is available or when an event that follows a remote method that has been suspended for further processing occurs. For example, a continuation event occurs when information is written to a queue waiting for the remote method to stop reading.

The continuation instruction calls the continuation method 412 which marks the interrupted remote method 416 as an executable process. Ultimately, the remote method resource manager 322 can now detect the status of the aborted method 416 indicating that the remote method is executable and continue processing (step 704). Step 704 is typically an asynchronous process that occurs when the remote method resource manager checks the state for a stopped process and does not necessarily occur when the state of the remote process is not executable. Remote method resource manager 322 assigns a resource, such as a thread, to remote method 416 (step 706).

The remote method runtime 314 loads the execution state 418 and the RPC state 408 from the state store 414. Execution state 418 prepares the remote method 416 to continue processing at the point left before abort (step 708). To implement this in software, the remote method 416 can be several pieces of interlaced code, each starting where the previous portion of code stopped before being interrupted. Optionally, the remote method 416 may be implemented as a single code segment with execution starting at different points in the code segment. As discussed above, RPC state 408 enables an RPC system such as RMI 218 to continue processing and return the result to the appropriate remote method call 306.

The remote method runtime 314 enables the remote method 416 to continue execution. The remote method 416 then continues processing for the server using the allocated threads and other resources (step 710). Ultimately, the result is generated by the remote method 416 and provided to the remote method skeleton 315 for encoding and packaging (step 712). These code results are passed through the network 310 to the remote method stub 308 which is decoded and provided to the remote method call 306 (step 714).

Although specific embodiments have been described by way of example, various modifications may be made without departing from the spirit and scope of the invention. Accordingly, the invention is not limited to the above embodiments, but instead is defined by the appended claims in light of the full scope of equivalents.

Claims (39)

A method performed on a server system having resources operatively coupled to a client system over a network, the method comprising: enabling remote methods to interrupt processing and transfer resources corresponding to the server system, the method comprising: Receiving a request from a client system with a remote method call sent using a remote procedure call (RPC) system Including, the receiving step, Indicating to the client system that the server system has received the request to invoke a remote method, Allocating resources to the remote method, Invoking the remote method, Determining whether the remote method depends on any resources that are not available or events that have not yet occurred, and Discontinuing further processing of the remote method and relinquishing resources from the remote method when the remote method relies on unavailable resources or events that have not yet occurred Including, but the transfer step, Transferring resources previously allocated to the remote method system for use by other processes and methods on the server system, Providing an execution state associated with the remote method, and a remote procedure call (RPC) state associated with the remote method call to continue processing the remote method in an appropriate time period; and Blocking further processing of the remote method until the resource that is not available is released and becomes available to the remote method or the event that caused the remote method to cease. A method performed on a server system having a plurality of resources operatively coupled to a client system over a network, the method being performed to enable processing of the server system by continuing to enable a previously interrupted remote method. Receiving an indication that a continuation event associated with a suspended remote method has occurred, wherein the continuation event is generated when a required resource for the remote method becomes available or an event has occurred that previously caused the abort of the remote method -; Allocating a resource to the remote method prepared to continue processing, wherein the allocating step indicates to the remote method resource manager that the remote method can continue processing, and the resource controlled by the remote method resource manager. Distributing to the remote method; Continuing execution of the remote method using the allocated resource;-the continuing step comprises the remote method having an execution state and a remote procedure call (RPC) system having an RPC state; Including information associated with a remote method, wherein the RPC state includes information associated with the remote method invocation; and generating a result from the remote method; And Sending the results from the server system to a client application on the client system. A method performed on a server system and enabling a remote method to continue processing and handing resources over to the server system operatively coupled to the client system over a network, the method comprising: Receiving a request from a remote method call to a client system; Allocating system resources to the remote method associated with the server system; Invoking the remote method associated with the server system; Determining availability of general resources needed to process the remote method; And Stopping further processing of the remote method when the remote method relies on a general resource that is not available. 4. The method of claim 3, wherein the server system includes a processor, main storage, auxiliary storage, display, and an input / output mechanism. 4. The method of claim 3, wherein the system comprises a thread. 4. The method of claim 3, wherein said general resource comprises data. 4. The method of claim 3, wherein the request is sent using a remote method call (RMI) system. The method of claim 3, wherein the stopping step, Transferring system resources and general resources to the server system, and Blocking further processing of the remote method until the resource that is not available is released and made available to the remote method. 9. The method of claim 8, wherein the abort step provides a running state associated with the remote method, and a remote procedure call (RPC) state associated with the remote method to continue processing for the remote method in a suitable time period. How to include more. Runs on the server system and enables previously interrupted remote methods to continue processing for the server system and to generate results for client applications on the client system operably coupled to the server system over a network. In the way, Receiving an indication that a continuation event associated with the aborted remote method has occurred; Allocating system resources and general resources to the prepared remote method to continue processing; Continuing execution of the remote method using the allocated resource; And Generating a result from the remote method; And Sending the result from the server system to a client application on the client system. 11. The method of claim 10, wherein the server system comprises a processor, main storage, auxiliary storage, display, and an input / output mechanism. The method of claim 10, wherein the system comprises a thread. 11. The method of claim 10, wherein said general resource comprises data. The method of claim 10, wherein continuing execution of the remote method comprises: The remote method having an execution state and a remote procedure call (RPC) system having an RPC state, the execution state including information associated with the remote method before being interrupted, the RPC state containing information associated with the remote method call Initializing, and Generating a result from the remote method. The method of claim 10, wherein said transmitting step uses a remote method call (RMI) system. A computer readable medium comprising instructions for enabling a remote method executed on a computer server system to continue processing for the computer server system and to transfer resources thereto. Receiving a request from a remote method call to a client system; Allocating system resources to the remote method associated with the server system; Invoking the remote method associated with the server system; Determining availability of general resources needed to process the remote method; And Stopping the further processing of the remote method when the remote method relies on a general resource that is not available. 17. The computer readable medium of claim 16, wherein the system comprises a thread. 17. The computer readable medium of claim 16, wherein the general resource comprises data. 17. The computer readable medium of claim 16, wherein the request is transmitted using a remote method call (RMI) system. The method of claim 16, wherein the interruption is A transfer module configured to transfer system resources and general resources to the server system, and a blocking module configured to block further processing of the remote method until the unavailable resource is released and made available to the remote method. Computer readable medium further performed. A computer readable medium comprising instructions for enabling a previously interrupted remote method to continue processing for a server system and for generating a result for a client application on the client system. Receiving an indication that a continuation event associated with the aborted remote method has occurred; Allocating system resources and general resources to the prepared remote method to continue processing; Continuing execution of the remote method using the allocated resource; And Generating a result from the remote method; And And transmitting the result from the server system to a client application on the client system. The computer readable medium of claim 21, wherein the system comprises a thread. 23. The computer readable medium of claim 21, wherein the general resource comprises data. 22. The computer readable medium of claim 21, wherein the transmitting step uses a remote method call (RMI) system. An apparatus for enabling a remote method to continue processing and for transferring resources over a network to a server system operatively coupled to the client system, A receiver module configured to receive a request from a remote method call to a client system; An allocation module configured to allocate system resources to the remote method associated with the server system; A calling module configured to call the remote method associated with the server system; A determining module, configured to determine whether general resources required to process the remote method are not available; And And an abort module configured to abort further processing of the remote method when the remote method relies on general resources that are not available. 27. The apparatus of claim 25, wherein the server system comprises a processor, main storage, auxiliary storage, display, and input / output mechanism. 27. The apparatus of claim 25, wherein the system comprises a thread. 27. The apparatus of claim 25, wherein the general resource comprises data. 27. The apparatus of claim 25, wherein the request is sent using a remote method call (RMI) system. The method of claim 25, wherein the stop module, A transfer module configured to transfer system resources and general resources to the server system, and And a blocking module configured to block further processing of the remote method until the resource that is not available is released and made available to the remote method. An apparatus for enabling a previously aborted remote method to continue processing for a server system and to generate a result for a client application for a client system operatively coupled to the server system over a network, the method comprising: A receiver module configured to receive an indication that a continuation event associated with an aborted remote method has occurred; An allocation module, configured to allocate system resources and general resources to the prepared remote method to continue processing; A continuous module configured to continue execution of the remote method using the allocated resource; A generation module configured to generate a result from the remote method; And And a sending module, configured to send the result from the server system to the client application on the client system. 32. The apparatus of claim 31, wherein the server system comprises a processor, main storage, auxiliary storage, display, and input / output mechanism. 32. The apparatus of claim 31 wherein the system comprises a thread. 32. The apparatus of claim 31 wherein the general resource comprises data. 32. The apparatus of claim 31, wherein the transmitting module uses a remote method call (RMI) system. 17. An apparatus for coupling resources to a server system coupled to a server system and enabling remote methods to be operatively coupled to a client system over a network, the apparatus comprising: Means for receiving a request from a remote method call to a client system; Means for assigning system resources to the remote method associated with the server system; Means for invoking the remote method associated with the server system; Means for determining the availability of general resources needed to process the remote method; And Means for stopping further processing of the remote method when the remote method relies on a general resource that is not available. 37. The apparatus of claim 36, further comprising a client system operatively coupled to the server system. Results for the client application for the client system coupled to the server system, enabling the remote method that was previously interrupted, to continue processing for the server system, and operably coupled to the server system over the network. In the apparatus for generating a, Means for receiving an indication that a continuation event associated with an aborted remote method has occurred; Means for allocating system resources and general resources to the prepared remote method to continue processing; Means for continuing execution of the remote method using the allocated resource; Means for generating a result from the remote method; And Means for sending the result from the server system to the client application on the client system. 39. The apparatus of claim 38, further comprising a client system operatively coupled to the server system.