Abstract: A technique for reliably multicasting a message within a router network is provided. At least one special router in the network has associated persistent storage for logging a message being routed to one or more clients. When a message is received at this logger node, the logger places the message in persistent storage and sends a logging acknowledgment back to those routers to which the message was originally routed, as well as back towards the source of the message. The logger acknowledgment includes the message id, the logger id, and a logging number. When the logger acknowledgment is received by a router, it looks up the routing information from the original message, and sends the acknowledgment to those neighboring routers to which the original message was sent, excluding the link from which the logger acknowledgment was received. If the original message corresponding to the logger acknowledgment was buffered at this router waiting to be delivered, the message is then delivered to its client nodes.

Abstract: Program product for an application programming interface that unifies a plurality of mechanisms into a single framework. The interface includes a mechanism for communicating between members of a process group of related processes, and a mechanism for synchronizing the related processes of the process group. Additionally, the application programming interface may include mechanisms for managing membership of the process group or a processor group of processors, and/or a mechanism for controlling a group state value for the process group.

Abstract: A scalable merge technique for information retrieval across a distributed network is provided, as well as a fault tolerant technique for communicating information across the distributed network. The merge technique includes multicasting a query request across a spanning tree of the distributed network from a root node to multiple clients of the tree, and receiving back at the root node, a merged response produced from responses from at least some of the clients of the spanning tree. The fault tolerant technique for communicating information across the distributed network includes assigning a unique identifier to each query request, automatically reconfiguring the network upon detection of a failure of a node of the network, and retransmitting the query request and/or any responses thereto within the reconfigured network.

Abstract: The number of instances of an application running in a computing environment are controlled by monitoring the current load on the application, and altering the current number of instances of the application based on results of the monitoring. The load may be monitored by monitoring the current number of instances of the application running in the computing environment. Where a maximum, minimum and/or initial number on startup, of instances of the application are specified, the altering is done based on comparing the current number to one or more of the specified numbers of instances.

Abstract: A technique for reliably multicasting a message within a router network in a sequenced order with other messages is provided. At least one special router in the network has associated persistent storage for sequencing a message being routed to one or more clients. When a message is received at this sequencer node, the sequencer places a sequence number for the message in persistent storage and sends a sequencing acknowledgment back to those routers to which the message was originally routed, as well as back towards the source of the message. The sequencer acknowledgment includes the message id, and the sequencing number. When the sequencer acknowledgment is received by a router, it looks up the routing information from the original message, and sends the acknowledgment to those neighboring routers to which the original message was sent, excluding the link from which the sequencer acknowledgment was received.

Abstract: Resources are checkpointed in order to save the state of the resources. The resources can then be brought back to the same running state, during a restart procedure, by making use of the saved state. The determination of when to take a checkpoint or when to restart a resource is made by an entity, such as a cluster manager, external to the entity initiating or taking the checkpoint or performing the restart. The decision to checkpoint/restart a resource is provided by the cluster manager to a resource manager associated with the resource. This communication is facilitated by interfaces to the cluster manager provided by the resource manager.

Abstract: Within a computer cluster usage reference counts are maintained for replicated databases within a computer cluster using cluster membership and cluster voting services. Such a method includes the maintaining of a local reference count for all open distributed data resources within a given node, tracking by a group services client of those nodes that have the open distributed data resources, and using cluster membership services to update the local reference counts for node failures.

Abstract: Program product for an application programming interface that unifies a plurality of mechanisms into a single framework. The interface includes a mechanism for communicating between members of a process group of related processes, and a mechanism for synchronizing the related processes of the process group. Additionally, the application programming interface may include mechanisms for managing membership of the process group or a processor group of processors, and/or a mechanism for controlling a group state value for the process group.

Abstract: A generalized search data structure is used to match consumers to events in event computing systems. The search data structure includes one or more paths from a root of the structure to one or more leaves of the structure. Each path has at least one level and each level corresponds to a filter attribute. The value of at least one filter attribute in at least one path is a don't care value indicating traversal of that path is guaranteed to proceed. In addition to following the path with the don't care value, one or more additional paths may also be followed. Thus, traversal of the search data structure may yield zero or more results, indicating that zero or more consumers match the specified event. Various optimizations of the search data structure are possible.

Abstract: A method and program product for managing membership of process groups of a distributed computing environment. Requests to alter membership of a first process group are received and presented to the first process group as a batched request. However, requests to change the membership of a second process group are received and presented to the second process group serially. Thus, the manner in which requests are presented can be different for various process groups. Additionally, different types of requests can be presented to the same process group in a differing manner. For instance, requests to join a process group can be presented as a batched request and requests to leave the process group can be presented serially, or vice versa.

Abstract: A router within a network uses the data of a message received at the router to determine on which links out of the router the message needs to be forwarded. The router does not need any destination information from the message, and thus, the message need not include any destination information. Instead, the router uses an annotated search data structure to determine which links correspond to consumers interested in receiving the message. The message is sent only over those links.

Abstract: A barrier synchronization system in a distributed computing environment. A group of members, including a plurality of related processes executing on one or more processors of the distributed computing environment, is provided a protocol having a dynamic number of synchronization phases. The protocol is voted on by one or more members of the group to determine how the protocol should proceed for the group of members. The protocol may complete successfully, continue to another synchronization phase or be rejected. The group of members determines how many synchronization phases the protocol is to include.

Abstract: An application programming interface that unifies a plurality of mechanisms into a single framework. The interface includes a mechanism for communicating between members of a process group of related processes, and a mechanism for synchronizing the related processes of the process group. Additionally, the application programming interface may include mechanisms for managing membership of the process group or a processor group of processors, and/or a mechanism for controlling a group state value for the process group.

Abstract: A barrier synchronization program product in a distributed computing environment. A group of members, including a plurality of related processes executing on one or more processors of the distributed computing environment, is provided a protocol having a dynamic number of synchronization phases. The protocol is voted on by one or more members of the group to determine how the protocol should proceed for the group of members. The protocol may complete successfully, continue to another synchronization phase or be rejected. The group of members determines how many synchronization phases the protocol is to include.

Abstract: Detecting the failure of the name server node and consulting a membership list of nodes in the domain to determine the crown prince (CP) node who is next in line to become the name server. The other available nodes in the domain periodically send recover messages to the CP node, and responsive to receiving the recover messages from all the other available nodes in the domain, the CP node perform a two phase takeover whereby the CP node becomes the name server for managing said processors in the domain. After the CP node becomes the name server, the other available nodes in the domain send data to the new name server necessary for the name server to manage the other available nodes in the domain. All request messages requesting management by the name server are stored locally until after the CP becomes the name server. The locally stored request messages are then processed by the other available nodes such that no request messages are lost during recovery.

Abstract: Managing membership of a domain of processors in a distributed computing environment including determining the lowest numbered node available in the domain and periodically sending grovel messages from the other available nodes to the lowest numbered node in the domain. Responsive to receiving all of the grovel messages by the lowest numbered node, the lowest numbered node performs a two phase commit whereby the lowest numbered node becomes a name server for managing the processors in the domain. The two phase commit includes sending an insert phase 1 (P1) message to the other available nodes from the lowest numbered node and, responsive to the insert P1 message, sending an acknowledge (ACK) message from the other available nodes to the lowest numbered node. Responsive to the ACK messages, a commit message is sent to the other available nodes notifying them that the lowest numbered node has become the name server.

Abstract: Recovery of a name server managing membership of a domain of processors in a distributed computing environment which includes detecting the failure of the name server node and consulting a membership list of nodes in the domain to determine the crown prince (CP) node who is next in line to become the name server. The other available nodes in the domain periodically send recover messages to the CP node, and responsive to receiving the recover messages from all the other available nodes in the domain, the CP node perform a two phase takeover whereby the CP node becomes the name server for managing said processors in the domain. After the CP node becomes the name server, the other available nodes in the domain send data to the new name server necessary for the name server to manage the other available nodes in the domain. All request messages requesting management by the name server are stored locally until after the CP becomes the name server.

Abstract: In a distributed computing environment having a plurality of groups of processors, each processor group maintains its own set of ordered messages. A message is sent to a group of processors. In particular, a request to multicast a message is sent to a leader of the group of processors, i.e., a group leader, and the group leader assigns a sequence number to the message to be sent, thereby providing an ordered message. Then, the group leader multicasts the ordered message to the group of processors. When the processors of the group receive the ordered message, each determines whether the message is in proper sequence order. If the message is out of order for a particular processor indicating that a message has been missed, then that particular processor requests the missing message from a processor within the group.

Abstract: System managing membership of a group of processors in a distributed computing environment. Specific actions are identified and performed in order to manage the group membership. A processor requests to join the group of processors and thus, is added to the group. Similarly, processors may request to leave the group or may fail and then are removed from the group. The group of members also receives multicasts initiated from one member of the group to other members of the group. Additionally, each group of processors within a distributed computing environment has a group leader that controls the actions being performed for the group of members.

Abstract: Managing group events by a name server for a group of processors in a distributed computing environment by receiving a message by said name server from one of the nodes requesting an event, determining what event is being requested by the message, determining which group the event is for, and storing an identification of the requesting node in an interested party set for the group. The name server determines if the group has a group leader, and if the group does not have a group leader, stores the event to be performed responsive to the message in a lookup queue to be processed when a group leader has been established. The first node requesting an event for a group is established by the name server as the group leader. The state of the group may have a first state wherein no group is established, a second state wherein the group is established but has no group leader, or a third state wherein the group is established and the group has a group leader.