Abstract: A system and method implements an event service of a platform. The platform executes a set of containers and component services to support the set of containers. The method tracks subscribers for events and facilitates distribution of the events to the subscribers. The events include information about changes to the state of at least one of the set of containers, where subscribers are processes in communication with the platform. The method includes receiving, at the event service, a subscriber request to subscribe for events of a container from the set of containers, receiving, at the event service, an event from a component service in the set of component services of the platform, and sending, by the event service, the event to the subscriber.

Abstract: A method and system manages access to resources within a virtualization platform using an application token, where the application token includes information to enable identification of an associated application. The method includes receiving a request from an application programming interface (API) server to instantiate an application, where the application is provided the application token based on a verified caller token, generating the application token derived from the verified caller token or a virtualization platform policy, and providing the application token to the application in a container for the application.

Abstract: A method and system that implements a container manger that manages access to resources within a virtualization platform with the use of application tokens. An application token includes information identifying a primary application that can be used to manage access to the resources for the primary application. The method includes generating an application token for the primary application, where the primary application is in a first container. The method further instantiates an application helper and a second container for the application helper and provides the application token to the application helper to manage on behalf of the primary application.

Abstract: A cluster manager manages copies of a mid-tier database as a mid-tier database cluster. The cluster manager may concurrently manage a backend database system. The cluster manager is configured to monitor for and react to failures of mid-tier database nodes. The cluster manager may react to a mid-tier database failure by, for example, assigning a new active node, creating a new standby node, creating new copies of the mid-tier databases, implementing new replication or backup schemes, reassigning the node's virtual address to another node, or relocating applications that were directly linked to the mid-tier database to another host. Each node or an associated agent may configure the cluster manager during initialization, based on common cluster configuration information. Each copy of the mid-tier database may be, for example, a memory resident database. Thus, a node must reload the entire database into memory to recover a copy of the database.

Abstract: A method for a self-testing clusterware agent is provided. A clusterware agent that includes clusterware-side components and application-side components is configured to interface between a cluster manager and an application. The application-side components are invoked by clusterware-side components via an application programming interface, or API that includes API functions that are invocable by a cluster manager. Without any cluster manager invoking the clusterware agent, one or more of the API functions are invoked.

Abstract: A clusterware manager on a cluster of nodes interprets a resource profile. The resource profile defines resource profile attributes. The attributes include at least one attribute that defines a cluster dependency based on resource type. The attribute does not identify any particular resource of that resource type. Dependencies between resources are managed based on the attribute that specifies the cluster dependency.

Abstract: A cluster manager is configured to manage a plurality of copies of a mid-tier database as a mid-tier database cluster. The cluster manager may concurrently manage a backend database system. The cluster manager is configured to monitor for and react to failures of mid-tier database nodes. The cluster manager may react to a mid-tier database failure by, for example, assigning a new active node, creating a new standby node, creating new copies of the mid-tier databases, implementing new replication or backup schemes, reassigning the node's virtual address to another node, or relocating applications that were directly linked to the mid-tier database to another host. Each node or an associated agent may configure the cluster manager to behave in this fashion during initialization, based on common cluster configuration information. Each copy of the mid-tier database may be, for example, a memory resident database. Thus, a node must reload the entire database into memory to recover a copy of the database.

Abstract: Allowing for resource attributes that may change dynamically while the resource is in use, provides for dynamic changes to the manner in which such resources are managed. Management of dynamic resource attributes by clusterware involves new entry points to clusterware agent modules, through which resource-specific user-specified instructions for discovering new values for resource attributes, and for performing a user-specified action in response to the new attribute values, are invoked. A clusterware policy manager may know ahead of time that a particular resource has dynamic attributes or may be notified when a resource's dynamic attribute has changed and, periodically or in response to the notification, request that the agent invoke the particular resource-specific instructions for discovering new values for attributes for the particular resource and/or for performing a user-specified action in response to the new attribute values. During the majority of this process, the resource remains available.

Abstract: A method for a self-testing clusterware agent is provided. A clusterware agent that includes clusterware-side components and application-side components is configured to interface between a cluster manager and an application. The application-side components are invoked by clusterware-side components via an application programming interface, or API that includes API functions that are invocable by a cluster manager. Without any cluster manager invoking the clusterware agent, one or more of the API functions are invoked.

Abstract: A clusterware manager on a cluster of nodes interprets a resource profile. The resource profile defines resource profile attributes. The attributes include at least one attribute that defines a cluster dependency based on resource type. The attribute does not identify any particular resource of that resource type. Dependencies between resources are managed based on the attribute that specifies the cluster dependency.

Abstract: A cluster manager is configured to manage a plurality of copies of a mid-tier database as a mid-tier database cluster. The cluster manager may concurrently manage a backend database system. The cluster manager is configured to monitor for and react to failures of mid-tier database nodes. The cluster manager may react to a mid-tier database failure by, for example, assigning a new active node, creating a new standby node, creating new copies of the mid-tier databases, implementing new replication or backup schemes, reassigning the node's virtual address to another node, or relocating applications that were directly linked to the mid-tier database to another host. Each node or an associated agent may configure the cluster manager to behave in this fashion during initialization, based on common cluster configuration information. Each copy of the mid-tier database may be, for example, a memory resident database. Thus, a node must reload the entire database into memory to recover a copy of the database.

Abstract: A method and mechanism for failing over applications in a clustered computing system is provided. In an embodiment, the methodology is implemented by a high-availability failover mechanism. Upon detecting a failure of an application that is currently designated to be executing on a particular node of the system, the mechanism may attempt to failover the application onto a different node. The mechanism keeps track of a number of nodes on which a failover of the application is attempted. Then, based on one or more factors including the number of nodes on which a failover of the application is attempted, the mechanism may cease to attempt to failover the application onto a node of the system.

Abstract: Techniques are provided for managing a resource in a High Availability (HA) system. The techniques involve incrementing a count when a particular type of remedial action is performed on a resource, so that the count that reflects how often the particular type of remedial action has been performed for the resource. When it is determined that the resource has been in stable operation, the count is automatically reduced. After a failure, the count is used to determine whether to attempt to perform the particular type of remedial action on the resource. Examples of remedial actions include restarting the resource, and relocating the resource to another node of a cluster. By using the count, the system insures that a faulty resource does not get constantly “bounced”. By reducing the count when a resource has become stable, there is less likelihood that failure of otherwise stable resources will require manual intervention.

Abstract: Selecting a master node in a multi-node computer system is described. Each node of the multi-node computer system selects a timeout value (e.g., randomly). Each node starts a timer, which is set to expire at the selected timeout value of its corresponding node. The node with the timer that expires earliest broadcasts an election message to the other nodes of the multi-node computer system, which informs the other nodes that the broadcasting node is a candidate for mastership over the multi-node computer system. The other nodes respond to the election message upon receiving it. In the absence of a refusal message from one or more of the other nodes, the candidate is established as master node in the multi-node computer system and wherein the other nodes function as slave nodes therein.

Abstract: A method and mechanism for failing over applications in a clustered computing system is provided. In an embodiment, the methodology is implemented by a high-availability failover mechanism. Upon detecting a failure of an application that is currently designated to be executing on a particular node of the system, the mechanism may attempt to failover the application onto a different node. The mechanism keeps track of a number of nodes on which a failover of the application is attempted. Then, based on one or more factors including the number of nodes on which a failover of the application is attempted, the mechanism may cease to attempt to failover the application onto a node of the system.

Abstract: Allowing for resource attributes that may change dynamically while the resource is in use, provides for dynamic changes to the manner in which such resources are managed. Management of dynamic resource attributes by clusterware involves new entry points to clusterware agent modules, through which resource-specific user-specified instructions for discovering new values for resource attributes, and for performing a user-specified action in response to the new attribute values, are invoked. A clusterware policy manager may know ahead of time that a particular resource has dynamic attributes or may be notified when a resource's dynamic attribute has changed and, periodically or in response to the notification, request that the agent invoke the particular resource-specific instructions for discovering new values for attributes for the particular resource and/or for performing a user-specified action in response to the new attribute values. During the majority of this process, the resource remains available.

Abstract: Techniques are provided for managing a resource in a High Availability (HA) system. The techniques involve incrementing a count when a particular type of remedial action is performed on a resource, so that the count that reflects how often the particular type of remedial action has been performed for the resource. When it is determined that the resource has been in stable operation, the count is automatically reduced. After a failure, the count is used to determine whether to attempt to perform the particular type of remedial action on the resource. Examples of remedial actions include restarting the resource, and relocating the resource to another node of a cluster. By using the count, the system insures that a faulty resource does not get constantly “bounced”. By reducing the count when a resource has become stable, there is less likelihood that failure of otherwise stable resources will require manual intervention.

Abstract: A method and apparatus are provided for computing degrees of parallelism for parallel operations in a computer system. The degree of parallelism for a given parallel operation is computed based on a set of factors. The set of factors includes a target degree of parallelism that represents a desired total amount of parallelism in the computer system, a current workload and a requested degree of parallelism.