Abstract: Technologies for managing fault recovery in a cloud computing environment may be used after faults of various sizes, including faults which put total functioning capacity below subscribed capacity. Computing services have repair priorities. A fault recovery manager selects a higher priority service whose capacity is below a minimum availability, and chooses a lower priority service still above its minimal availability, and reassigns capacity from the lower priority service to the higher priority service without depriving the lower priority service of operability. Capacity reassignment continues at least until the higher priority service is at or above minimal availability, or the lower priority service is at minimal availability. Lower priority services may also be terminated entirely to free up resources for higher priority services. New deployments may be prevented until all services are at or above minimal availability. Spare capacity may be reserved against demand fluctuations or further faults.

Abstract: In various embodiments, methods and systems for optimizing allocation of dynamic resources are provided. A user service request resource instance is received at an allocator. The user service request resource instance is based on a dynamic resource protocol that supports generating and communicating resource instances between components in a resource allocation platform. The dynamic resource protocol also defines a set of rules for translating and representing resources as logical resource types and logical units. At a node, a node resource instance is generated and communicated, based on the dynamic resource protocol, from the node to the allocator. The node resource instance specifically comprises a resource interaction matrix that indicates dependencies between resource types. A resource allocation instance is generated at the allocator for the user service request resource instance.

Abstract: Tenant and server platform coordination of the performance of atomic tasks that are to be performed by the platform, but which have at least a potential impact on the tenant. The server platform allows a particular tenant a timeframe within which the tenant itself may approve of initiation of each of one or more tasks. The server platform may protect itself from delayed action by imposing time constraints on the timeframe such that after the timeframe is elapsed, the tenant no longer has control over triggering the initiation of the particular task. Accordingly, the tenant is provided with flexibility on controlling initiation of a task performed by the server platform, while the server platform maintains a level of control to protect its resources and balances the needs of the various tenants.

Abstract: Technologies for managing fault recovery in a cloud computing environment may be used after faults of various sizes, including faults which put total functioning capacity below subscribed capacity. Computing services have repair priorities. A fault recovery manager selects a higher priority service whose capacity is below a minimum availability, and chooses a lower priority service still above its minimal availability, and reassigns capacity from the lower priority service to the higher priority service without depriving the lower priority service of operability. Capacity reassignment continues at least until the higher priority service is at or above minimal availability, or the lower priority service is at minimal availability. Lower priority services may also be terminated entirely to free up resources for higher priority services. New deployments may be prevented until all services are at or above minimal availability. Spare capacity may be reserved against demand fluctuations or further faults.

Abstract: In various embodiments, methods and systems for optimizing allocation of multi-priority service instances are provided. In embodiments, a packing quality metric associated with each candidate node to which a service instance could be allocated are determined. An eviction cost associated with at least a portion of the candidate nodes to which the service instance could be allocated are determined. The eviction costs generally indicate a cost to evict a service instance from a corresponding node such that another service instance can be allocated to that node. At least a portion of the packing quality metrics and the eviction costs are used to select a node from the candidate nodes to which to allocate the service instance.

Abstract: Systems and methods are taught for providing customers of a cloud computing service to control when updates affect the services provided to the customers. Because multiple customers share the cloud's infrastructure, each customer may have conflicting preferences for when an update and associated downtime occurs. Preventing and resolving conflicts between the preferences of multiple customers while providing them with input for scheduling a planned update may reduce the inconvenience posed by updates. Additionally, the schedule for the update may be transmitted to customers so that they can prepare for the downtime of services associated with the update.

Abstract: Technologies for managing fault recovery in a cloud computing environment may be used after faults of various sizes, including faults which put total functioning capacity below subscribed capacity. Computing services have repair priorities. A fault recovery manager selects a higher priority service whose capacity is below a minimum availability, and chooses a lower priority service still above its minimal availability, and reassigns capacity from the lower priority service to the higher priority service without depriving the lower priority service of operability. Capacity reassignment continues at least until the higher priority service is at or above minimal availability, or the lower priority service is at minimal availability. Lower priority services may also be terminated entirely to free up resources for higher priority services. New deployments may be prevented until all services are at or above minimal availability. Spare capacity may be reserved against demand fluctuations or further faults.

Abstract: In various embodiments, methods and systems for optimizing allocation of dynamic resources are provided. A user service request resource instance is received at an allocator. The user service request resource instance is based on a dynamic resource protocol that supports generating and communicating resource instances between components in a resource allocation platform. The dynamic resource protocol also defines a set of rules for translating and representing resources as logical resource types and logical units. At a node, a node resource instance is generated and communicated, based on the dynamic resource protocol, from the node to the allocator. The node resource instance specifically comprises a resource interaction matrix that indicates dependencies between resource types. A resource allocation instance is generated at the allocator for the user service request resource instance.

Abstract: Methods, systems, and computer storage media for updating instances of a service application within nodes of a data center are provided. The system includes a state machine equipped for designating an earlier version of software running on some instances as a basement version and a newer version of software running on other instances as a latest version. The system also includes a compatibility mechanism responsible for allowing the basement version, the latest version, and other versions of the service application therebetween to interact using a data structure associated within the earlier version, or lowest common version of the service application. The compatibility mechanism is located apart from core logic of the service application. The activities of the state machine and the compatibility mechanism allow the instances to communicate with each other (using the lowest common version) while exposing just the validated version(s) of the service application to the client.

Abstract: A laser resonator comprises a cylindrical gain medium, a cooling system and a coupling member. The cylindrical gain medium comprises a central axis, an outer side surface, two opposing end faces and a first depression in the outer side surface. The cooling system comprises a cooling jacket disposed around the gain medium that defines a cooling cavity, in which cooling fluid is guided over the side surface of the gain medium. In one embodiment, the cooling jacket comprises a second depression. The coupling member is received within the first and second depressions. Movement of the first depression along the central axis relative to the cooling jacket is restricted by the coupling member.

Abstract: In various embodiments, methods and systems for optimizing allocation of dynamic resources are provided. A user service request resource instance is received at an allocator. The user service request resource instance is based on a dynamic resource protocol that supports generating and communicating resource instances between components in a resource allocation platform. The dynamic resource protocol also defines a set of rules for translating and representing resources as logical resource types and logical units. At a node, a node resource instance is generated and communicated, based on the dynamic resource protocol, from the node to the allocator. The node resource instance specifically comprises a resource interaction matrix that indicates dependencies between resource types. A resource allocation instance is generated at the allocator for the user service request resource instance.

Abstract: Tenant and server platform coordination of the performance of atomic tasks that are to be performed by the platform, but which have at least a potential impact on the tenant. The server platform allows a particular tenant a timeframe within which the tenant itself may approve of initiation of each of one or more tasks. The server platform may protect itself from delayed action by imposing time constraints on the timeframe such that after the timeframe is elapsed, the tenant no longer has control over triggering the initiation of the particular task. Accordingly, the tenant is provided with flexibility on controlling initiation of a task performed by the server platform, while the server platform maintains a level of control to protect its resources and balances the needs of the various tenants.

Abstract: Methods, systems, and computer storage media for updating instances of a service application within nodes of a data center are provided. The system includes a state machine equipped for designating an earlier version of software running on some instances as a basement version and a newer version of software running on other instances as a latest version. The system also includes a compatibility mechanism responsible for allowing the basement version, the latest version, and other versions of the service application therebetween to interact using a data structure associated within the earlier version, or lowest common version of the service application. The compatibility mechanism is located apart from core logic of the service application. The activities of the state machine and the compatibility mechanism allow the instances to communicate with each other (using the lowest common version) while exposing just the validated version(s) of the service application to the client.

Abstract: Message intermediation for multiple service instances, while allowing the service instance to control whether messages are processed under a transaction. The message intermediator chooses to dispatch messages among different backend service instances based on any routing rules. The message intermediator performs a peek-lock of message from a forward-end queue, and assigns the message to a service instance. The message is provided into a backward-end queue specific to the assigned service instance. The service instance may then process the message, perhaps under a transaction created at the service instance. Upon completion of processing, the message is deleted in the back-end queue, which causes the forward-end queue to delete the message under the same transaction created by the service instance. Whether or not this deletion at the forward-end is committed or rolled back depends on whether the transaction created at the service instance is committed or rolled back.

Abstract: The present invention includes an induction motor soft starter that includes a bypass contactor loop on which is disposed two anti-parallel connected SCRs and a current limiting reactor that limits the current rise during the switching on of the SCRs.

Abstract: In one embodiment, a computer system instantiates a queue manager configured to process a plurality of existing queue manager commands on messages in a message queue. The computer system instantiates a virtualized instance of a queue manager in a virtual layer associated with the queue manager in the computing system. The a virtualized queue manager instance provides supplemental queue manager commands usable in addition to existing queue manager commands, such that the queue manager can be used to implement the supplemental commands without substantial modification. The computer system receives an indication that a message in a message queue is to be accessed according to a specified command provided by the instantiated virtualized queue manager instance that is not natively supported by the queue manager and the virtualized queue manager performs the specified supplemental command as indicated by the received indication by performing one or more existing queue manager commands.

Abstract: Message intermediation for multiple service instances, while allowing the service instance to control whether messages are processed under a transaction. The message intermediator chooses to dispatch messages among different backend service instances based on any routing rules. The message intermediator performs a peek-lock of message from a forward-end queue, and assigns the message to a service instance. The message is provided into a backward-end queue specific to the assigned service instance. The service instance may then process the message, perhaps under a transaction created at the service instance. Upon completion of processing, the message is deleted in the back-end queue, which causes the forward-end queue to delete the message under the same transaction created by the service instance. Whether or not this deletion at the forward-end is committed or rolled back depends on whether the transaction created at the service instance is committed or rolled back.

Abstract: A transactional memory processing system provides for the integration of transactional memory concepts at the compiler-level into a higher-level traditional transaction processing system. Atomic blocks at the compiler-level can be specified as atomic block transactions and include the features of atomicity and isolation. Actions within this atomic block transaction include the enlistment of resource managers from a repository. The repository can now include a pre-programmed memory resource manager to manage the transactional memory. As in traditional transactions, a commit protocol can be used to determine if the actions are valid and can be exposed outside of the transaction. Unlike traditional transactions, however, the transaction is not necessarily doomed if all of the actions are not validated. Rather, memory conflicts can cause a rollback and re-execution of the atomic block transaction, which can be repeated as long as necessary, until the memory resource manger votes to commit.

Abstract: A transaction manager virtualization layer is provided for supporting multiple active transaction managers in a cluster or node. By virtualizing the transaction managers, applications and services are enabled to migrate across cluster nodes or even outside a cluster that includes relevant recovery mechanisms for transactions that are not completed at the time of migration. Multiple implementations of a transaction manager may be enabled to run side-by-side in a node or cluster allowing a rolling upgrade of transaction managers in clusters.

Abstract: Aspects of the subject matter described herein relate to transactions. In aspects, a consistency requester such as a shadow copy service requests to have a consistent view of a set of resources. In response, transactions that are in a problematic state are allowed to exit the problematic state while new and existing transactions that are not in the problematic state are allowed to perform any work except work that takes them into the problematic state. After no transactions are in the problematic state, a consistent view of the set of resources is available. This view may be used by the consistency requester as desired. Afterwards, the consistency requester may indicate that a consistent view is no longer needed. Transactions are then allowed to enter the problematic state. Transactions may also be allowed to enter the problematic state if a timeout elapses.