Abstract: A system for managing objects in a clustered network includes a file system containing at least one copy of a data object. The system can include several clustered servers in communication with the file system. A lead server is selected, which contains a distributed consensus algorithm for selecting a host server, and which utilizes multicasting while executing rounds of the algorithm. The selected host server can contain a copy of the data object, such as in local cache, providing access to the local copy to any other server in the cluster. Any change made to an item hosted by the host server can also be updated in the file system. If the host server becomes unable to host the object, a new host can be chosen using the distributed consensus algorithm. The other servers are then notified of the new host by multicast messaging.

Abstract: A Node Manager monitors the status of multiple servers. The Node Manager detects server failures, periodically monitors server health status, and performs server maintenance. When the Node Manager detects a server failure, it determines whether or not the server should be restarted. While periodically monitoring servers, the Node Manager may determine how often to trigger a health check, how long to wait for a response, and how to proceed if the server is deemed failed. The Node Manager may be controlled by an Administrative Server directly or by an external administrative agent. An administrative agent may control the Node Manager by interfacing with the Administrative Server. The Node Manager and AS may authenticate each other and encode their communications to each other for increased security.

Abstract: A migration framework provides for the migration of services in a cluster. A migratable target contains a list of servers in the cluster capable of hosting a migratable service. A migration manager can migrate the service between servers in the migratable target, and can activate an instance of the service on the selected host server. The migration manager ensures that only one active instance of the service exists in the cluster. A service stub can serve a user request on servers in the migration target, such as by order of preference, until the user request is served on the server hosting the active instance. A lease manager can assign a lease period to determine how long a server hosts an active instance.

Abstract: A Node Manager monitors the status of multiple servers. The Node Manager detects server failures, periodically monitors server health status, and performs server maintenance. When the Node Manager detects a server failure, it determines whether or not the server should be restarted. While periodically monitoring servers, the Node Manager may determine how often to trigger a health check, how long to wait for a response, and how to proceed if the server is deemed failed. The Node Manager may be controlled by an Administrative Server directly or by an external administrative agent. An administrative agent may control the Node Manager by interfacing with the Administrative Server. The Node Manager and AS may authenticate each other and encode their communications to each other for increased security.

Abstract: A Node Manager monitors the status of multiple servers. The Node Manager detects server failures, periodically monitors server health status, and performs server maintenance. When the Node Manager detects a server failure, it determines whether or not the server should be restarted. While periodically monitoring servers, the Node Manager may determine how often to trigger a health check, how long to wait for a response, and how to proceed if the server is deemed failed. The Node Manager may be controlled by an Administrative Server directly or by an external administrative agent. An administrative agent may control the Node Manager by interfacing with the Administrative Server. The Node Manager and AS may authenticate each other and encode their communications to each other for increased security.

Abstract: A server self health monitor (SHM) system monitors the health of the server it resides on. The health of a server is determined by the health of all of a server's sub-systems and deployed applications. The SHM may make health check inquiries to server sub-systems periodically or based on external trigger events. The sub-systems perform self health checks on themselves and provide sub-system health information to requesting entities such as the SHM. Sub-systems self health updates may be based on internal events such as counters or changes in status or based on external entity requests. Corrective action may be performed upon sub-systems by the SHM depending on their health status or the health status of the server. Corrective action may also be performed by a sub-system upon itself.

Abstract: A server self health monitor (SHM) system monitors the health of the server it resides on. The health of a server is determined by the health of all of a server's sub-systems and deployed applications. The SHM may make health check inquiries to server sub-systems periodically or based on external trigger events. The sub-systems perform self health checks on themselves and provide sub-system health information to requesting entities such as the SHM. Sub-systems self health updates may be based on internal events such as counters or changes in status or based on external entity requests. Corrective action may be performed upon sub-systems by the SHM depending on their health status or the health status of the server. Corrective action may also be performed by a sub-system upon itself.

Abstract: A server self health monitor (SHM) system monitors the health of the server it resides on. The health of a server is determined by the health of all of a server's sub-systems and deployed applications. The SHM may make health check inquiries to server sub-systems periodically or based on external trigger events. The sub-systems perform self health checks on themselves and provide sub-system health information to requesting entities such as the SHM. Sub-systems self health updates may be based on internal events such as counters or changes in status or based on external entity requests. Corrective action may be performed upon sub-systems by the SHM depending on their health status or the health status of the server. Corrective action may also be performed by a sub-system upon itself.

Abstract: A clustered enterprise distributed processing system. The distributed processing system includes a first and a second computer coupled to a communication medium. The first computer includes a virtual machine (JVM) and kernel software layer for transferring messages, including a remote virtual machine (RJVM). The second computer includes a JVM and a kernel software layer having a RJVM. Messages are passed from a RJVM to the JVM in one computer to the JVM and RJVM in the second computer. Messages may be forwarded through an intermediate server or rerouted after a network reconfiguration. Each computer includes a Smart stub having a replica handler, including a load balancing software component and a failover software component. Each computer includes a duplicated service naming tree for storing a pool of Smart stubs at a node.

Abstract: A migration framework provides for the automatic migration of services in a cluster. A migratable target list contains a list of servers in the cluster capable of hosting a migratable service. A consensus subsystem can select a host server from the migratable target list. A migration manager can migrate the service from a current host to the host selected by the consensus subsystem, and can activate an instance of the service on the selected host server. The migration manager ensures that only one active instance of the service exists in the cluster. A service stub can serve a user request on servers in the migration target, such as by order of preference, until the user request is served on the server hosting the active instance. A lease manager can assign a lease period to determine how long a server hosts an active instance.

Abstract: A system for managing objects in a clustered network includes a file system containing at least one copy of a data object. The system can include several clustered servers in communication with the file system. A lead server is selected, which contains a distributed consensus algorithm for selecting a host server, and which utilizes multicasting while executing rounds of the algorithm. The selected host server can contain a copy of the data object, such as in local cache, providing access to the local copy to any other server in the cluster. Any change made to an item hosted by the host server can also be updated in the file system. If the host server becomes unable to host the object, a new host can be chosen using the distributed consensus algorithm. The other servers are then notified of the new host by multicast messaging.

Abstract: A clustered enterprise Java™ distributed processing system is provided. The distributed processing system includes a first and a second computer coupled to a communication medium. The first computer includes a Java™ virtual machine (JVM) and kernel software layer for transferring messages, including a remote Java™ virtual machine (RJVM). The second computer includes a JVM and a kernel software layer having a RJVM. Messages are passed from a RJVM to the JVM in one computer to the JVM and RJVM in the second computer. Messages may be forwarded through an intermediate server or rerouted after a network reconfiguration. Each computer includes a Smart stub having a replica handler, including a load balancing software component and a failover software component. Each computer includes a duplicated service naming tree for storing a pool of Smart stubs at a node. The computers may be programmed in a stateless, stateless factory, or a stateful programming model.

Abstract: A system for managing a JMS message store in a clustered network includes an object acting as a message store for Java Message Service (JMS). A lead server is selected from several clustered servers. The lead server uses a distributed consensus algorithm to select a host server, utilizing multicast messaging while executing rounds of the algorithm. The selected host server hosts the JMS message store, providing sole access to JMS. The other servers are notified of the new host by multicast messaging. All servers in the cluster can use JMS, but they must send messages to the message store on the host and pick up any messages from the message store.

Abstract: A session replication system provides real-time data replication without unnecessarily slowing down the user experience. A system in accordance with the present invention may utilize a primary server to serve requests from a network client, as well as a secondary server to replicate the session information. When a request is received on the session, an attempt may be made to serve the request on the primary server. If the primary is unable to receive or respond to the request, the request may be served on the secondary application server or on a new primary server. If the secondary server receives the request, the secondary server may become the new primary server. If a new primary server is selected, the new primary may request the session information from the secondary server.

Abstract: A session replication system provides real-time data replication without unnecessarily slowing down the user experience. A system in accordance with the present invention may utilize a primary server to serve requests from a network client, as well as a secondary server to replicate the session information. When a request is received on the session, an attempt may be made to serve the request on the primary server. If the primary is unable to receive or respond to the request, the request may be served on the secondary server or on a new primary server. If the secondary server receives the request, the secondary server may become the new primary server. If a new primary server is selected, the new primary may request the session information from the secondary server.

Abstract: A clustered enterprise Java™ distributed processing system is provided. The distributed processing system includes a first and a second computer coupled to a communication medium. The first computer includes a Java™ virtual machine (JVM) and kernel software layer for transferring messages, including a remote Java™ virtual machine (RJVM). The second computer includes a JVM and a kernel software layer having a RJVM. Messages are passed from a RJVM to the JVM in one computer to the JVM and RJVM in the second computer. Messages may be forwarded through an intermediate server or rerouted- after a network reconfiguration. Each computer includes a Smart stub having a replica handler, including a load balancing software component and a failover software component. Each computer includes a duplicated service naming tree for storing a pool of Smart stubs at a node. The computers may be programmed in a stateless, stateless factory, or a stateful programming model.

Abstract: A clustered enterprise Java™ distributed processing system is provided. The distributed processing system includes a first and a second computer coupled to a communication medium. The first computer includes a Java™ virtual machine (JVM) and kernel software layer for transferring messages, including a remote Java™ virtual machine (RJVM). The second computer includes a JVM and a kernel software layer having a RJVM. Messages are passed from a RJVM to the JVM in one computer to the JVM and RJVM in the second computer. Messages may be forwarded through an intermediate server or rerouted after a network reconfiguration. Each computer includes a Smart stub having a replica handler, including a load balancing software component and a failover software component. Each computer includes a duplicated service naming tree for storing a pool of Smart stubs at a node. The computers may be programmed in a stateless, stateless factory, or a stateful programming model.