Abstract: A transactional replicator applying group commit and barrier concepts is disclosed. Group commit means that the transactional replicator commits multiple transactions in a group and is not restricted to committing single transactions one-at-a-time and is not limited to operating on a single state provider. Barrier means that the transactional replicator does not move forward to commit additional transactions until the previous group of transactions are completed. All state providers must apply their transactions and update state before additional transactions will be committed. A quorum acknowledgement “unlocks” any locks that were acquired to update the state within a state provider. However, as long as there are no lock conflicts, additional transactions can continue to create new group commits as necessary.

Abstract: A transactional replicator applying group commit and barrier concepts is disclosed. Group commit means that the transactional replicator commits multiple transactions in a group and is not restricted to committing single transactions one-at-a-time and is not limited to operating on a single state provider. Barrier means that the transactional replicator does not move forward to commit additional transactions until the previous group of transactions are completed. All state providers must apply their transactions and update state before additional transactions will be committed. A quorum acknowledgement “unlocks” any locks that were acquired to update the state within a state provider. However, as long as there are no lock conflicts, additional transactions can continue to create new group commits as necessary.

Abstract: A transactional replicator applying group commit and barrier concepts is disclosed. Group commit means that the transactional replicator commits multiple transactions in a group and is not restricted to committing single transactions one-at-a-time and is not limited to operating on a single state provider. Barrier means that the transactional replicator does not move forward to commit additional transactions until the previous group of transactions are completed. All state providers must apply their transactions and update state before additional transactions will be committed. A quorum acknowledgement “unlocks” any locks that were acquired to update the state within a state provider. However, as long as there are no lock conflicts, additional transactions can continue to create new group commits as necessary.

Abstract: Embodiments are directed to managing multiple different types of applications using service groups. In one scenario, a computer system receives an indication of one or more application dependencies and characteristics that are to be implemented when an application is provisioned on a distributed host computer system. The computer system creates an application manifest that declaratively defines application dependencies and characteristics for various different service groups. Each service group includes applications that match the declaratively defined application dependencies and characteristics. The computer system also sends the manifest to the distributed host computer system which loads those applications that fit the manifest criteria onto available nodes of the distributed host computer system according to the service groups specified in the manifest.

Abstract: A transactional replicator applying group commit and barrier concepts is disclosed. Group commit means that the transactional replicator commits multiple transactions in a group and is not restricted to committing single transactions one-at-a-time and is not limited to operating on a single state provider. Barrier means that the transactional replicator does not move forward to commit additional transactions until the previous group of transactions are completed. All state providers must apply their transactions and update state before additional transactions will be committed. A quorum acknowledgement “unlocks” any locks that were acquired to update the state within a state provider. However, as long as there are no lock conflicts, additional transactions can continue to create new group commits as necessary.

Abstract: A model checking system is described herein that more effectively verifies and validates the design of distributed applications by providing a model and a generic framework to check application invariant properties, detect anomaly behaviors, and monitor application health. The model checking system checks on-line application behavior against application models derived from formal descriptions of the application. The system formulates the concrete application as an abstract model and a number of rules or properties that are expected to hold for the application under all conditions. The model checker compares the actual application execution with the models and either confirms that the properties hold true or reports that the properties are violated. Thus, the model checking system provides more efficient and thorough validation of distributed applications under more realistic production conditions.

Abstract: Embodiments are directed to managing multiple different types of applications using service groups. In one scenario, a computer system receives an indication of one or more application dependencies and characteristics that are to be implemented when an application is provisioned on a distributed host computer system. The computer system creates an application manifest that declaratively defines application dependencies and characteristics for various different service groups. Each service group includes applications that match the declaratively defined application dependencies and characteristics. The computer system also sends the manifest to the distributed host computer system which loads those applications that fit the manifest criteria onto available nodes of the distributed host computer system according to the service groups specified in the manifest.

Abstract: A model checking system is described herein that more effectively verifies and validates the design of distributed applications by providing a model and a generic framework to check application invariant properties, detect anomaly behaviors, and monitor application health. The model checking system checks on-line application behavior against application models derived from formal descriptions of the application. The system formulates the concrete application as an abstract model and a number of rules or properties that are expected to hold for the application under all conditions. The model checker compares the actual application execution with the models and either confirms that the properties hold true or reports that the properties are violated. Thus, the model checking system provides more efficient and thorough validation of distributed applications under more realistic production conditions.

Abstract: A steady state value of each parameter in a set of one or more parameters of a computer system under test is defined, and acts related to the parameter are performed while the system under test is processing one or more test workloads. The acts can include comparing a working value of the parameter with the steady state value of the parameter, as well as operating on one or more workloads to bring the working value closer to a steady state value. This can include increasing or decreasing the working value of the parameter, such as by admitting one or more workloads to the system under test or cancelling one or more workloads from the system under test.

Abstract: A fully distributed system for testing a distributed computing system utilizes test services exposed in conjunction by independent test components deployed on one or more computing nodes of the distributed computing system. The test services ensure dynamic and adaptive coordination amongst the test components. The test services include but are not limited to: an atomic synchronization service; a distributed shared memory service; a lock manager service; a publish/subscribe service; and a producer/consumer service.

Abstract: A fully distributed system for testing a distributed computing system utilizes test services exposed in conjunction by independent test components deployed on one or more computing nodes of the distributed computing system. The test services ensure dynamic and adaptive coordination amongst the test components. The test services include but are not limited to: an atomic synchronization service; a distributed shared memory service; a lock manager service; a publish/subscribe service; and a producer/consumer service.

Abstract: A steady state value of each parameter in a set of one or more parameters of a computer system under test is defined, and acts related to the parameter are performed while the system under test is processing one or more test workloads. The acts can include comparing a working value of the parameter with the steady state value of the parameter, as well as operating on one or more workloads to bring the working value closer to a steady state value. This can include increasing or decreasing the working value of the parameter, such as by admitting one or more workloads to the system under test or cancelling one or more workloads from the system under test.