Abstract: Conventional techniques for shutting down preempted nodes includes drawbacks to cloud users and service providers alike. The disclosed techniques are directed to mitigating or eliminating these drawbacks. Upon receiving a preemptible node request, a preemptible node may be generated, labeled as having a particular capacity type, and added to a cluster managed by a cluster manager. In response to detecting the label, the cluster manager may deploy a containerized application to the preemptible node. The containerized application may monitor node metadata to detect preemption of the node. Node metadata may be provided by node metadata service executing at a smart network interface card connected to a host on which the preemptible node executes. In response to detecting preemption, the containerized application may initiate shutdown and/or replacement operations of the preemptible node to reduce or eliminate the negative impact of preemption.

Abstract: Techniques for migrating worker nodes within clusters to a new manager instance. One technique includes receiving a request to migrate or update a configuration of a cluster within a container system, where the migration or update includes switching from a first communication pathway to a second communication pathway between worker nodes and a manager instance; creating a component and associated IP address for the second communication pathway; communicating a pod specification that includes the IP address for the second communication pathway to the manager instance, where the pod specification will cause a container tool to update each of the worker nodes with the IP address for the second communication pathway; receiving a notification that all worker nodes have been updated with the IP address; and removing a component and associated IP address for the first communication pathway from the cluster.

Abstract: Techniques for migrating worker nodes within clusters to a new manager instance. One technique includes receiving a request to migrate or update a configuration of a cluster within a container system, where the migration or update includes switching from a first communication pathway to a second communication pathway between worker nodes and a manager instance; creating a component and associated IP address for the second communication pathway; communicating a pod specification that includes the IP address for the second communication pathway to the manager instance, where the pod specification will cause a container tool to update each of the worker nodes with the IP address for the second communication pathway; receiving a notification that all worker nodes have been updated with the IP address; and removing a component and associated IP address for the first communication pathway from the cluster.

Abstract: Techniques for migrating worker nodes within clusters to a new manager instance. One technique includes receiving a request to migrate or update a configuration of a cluster within a container system, where the migration or update includes switching from a first communication pathway to a second communication pathway between worker nodes and a manager instance; creating a component and associated IP address for the second communication pathway; communicating a pod specification that includes the IP address for the second communication pathway to the manager instance, where the pod specification will cause a container tool to update each of the worker nodes with the IP address for the second communication pathway; receiving a notification that all worker nodes have been updated with the IP address; and removing a component and associated IP address for the first communication pathway from the cluster.

Abstract: In accordance with an embodiment, described herein is a system and method for managed server independence for deployment (MSI-D) of software applications and libraries, for use in a cloud computing, application server, or other environment. Software applications or libraries can be prepared for deployment as multi-version format application(s) or library(s). A deployment configuration tool enables use of an input file which specifies one or more deployment configuration overrides data that provide additional pieces of information for each MSI-D/multi-version format application and library. A managed server can independently poll for changes to the deployment configuration overrides, for example to update one or more of its deployed applications or libraries, from a first version to a second version. The system can be used to provide eventual consistency of the deployed application and library versions within a plurality of managed servers.

Abstract: In accordance with an embodiment, described herein is a system and method for classloading in a multitenant application server environment. The system includes a domain with a plurality of partitions, and a resource group template including one or more applications, each configured with code shareable across the plurality of partitions. A class loader hierarchy can be created for each application instance in a partition, wherein the class loader hierarchy includes a class loader structure for that application instance, a partition class loader for the partition, and a shared application class loader for all instances of that application. At runtime, the class loader structure for an application instance can use the partition class loader as a parent class loader to load classes visible to the partition, and use the shared application class loader as an alternative parent class loader.

Abstract: In accordance with an embodiment, described herein is a system and method for managed server independence for deployment (MSI-D) of software applications and libraries, for use in a cloud computing, application server, or other environment. Software applications or libraries can be prepared for deployment as multi-version format application(s) or library(s). A deployment configuration tool enables use of an input file which specifies one or more deployment configuration overrides data that provide additional pieces of information for each MSI-D/multi-version format application and library. A managed server can independently poll for changes to the deployment configuration overrides, for example to update one or more of its deployed applications or libraries, from a first version to a second version. The system can be used to provide eventual consistency of the deployed application and library versions within a plurality of managed servers.

Abstract: In accordance with an embodiment, described herein is a system and method for supporting deployment in an application server environment. A resource, for example an application or library, can be deployed to different resource groups in different partitions in a domain, to a resource group template referenced by the different resource groups, or to a domain-level resource group. One or more additional deployment operations can be performed on a deployed resource by a partition administrator or a system administrator. A deployment API can be provided to enable a plurality of deployment clients to perform the deployment operations, and can be used to derive partition information and target information for the deployment operations when the information is not provided by a partition administrator. Different deployment scopes are defined to allow a same resource to be deployed in different partitions of a domain and outside any partition in the domain.

Abstract: In accordance with an embodiment, described herein is a system and method for classloading in a multitenant application server environment. The system includes a domain with a plurality of partitions, and a resource group template including one or more applications, each configured with code shareable across the plurality of partitions. A class loader hierarchy can be created for each application instance in a partition, wherein the class loader hierarchy includes a class loader structure for that application instance, a partition class loader for the partition, and a shared application class loader for all instances of that application. At runtime, the class loader structure for an application instance can use the partition class loader as a parent class loader to load classes visible to the partition, and use the shared application class loader as an alternative parent class loader.

Abstract: In accordance with an embodiment, described herein is a system and method for supporting deployment in an application server environment. A resource, for example an application or library, can be deployed to different resource groups in different partitions in a domain, to a resource group template referenced by the different resource groups, or to a domain-level resource group. One or more additional deployment operations can be performed on a deployed resource by a partition administrator or a system administrator. A deployment API can be provided to enable a plurality to deployment clients to perform the deployment operations, and can be used to derive partition information and target information for the deployment operations when the information is not provided by a partition administrator. Different deployment scopes are defined to allow a same resource to be deployed in different partitions of a domain and outside any partition in the domain.

Abstract: A model for extending application server functionality includes two types of libraries: an automatically-referenced (auto-ref) library and a superseding library. The auto-ref library includes a special tag that identifies it as the auto-ref library and a pattern that restricts the application types that can refer to it. Once the auto-ref library is deployed, it is automatically referred to by all applications as long as they are not excluded by the restricting pattern. The code contained in the auto-ref library is merged into the application code and the configuration of the library is merged into the application configuration at deployment time. The superseding library also includes an identifying tag and a restriction pattern. At deployment, however, the code and configuration data in the superseding library overrides the corresponding application configuration and code. The remaining code of the application that is not overridden by the superseding library is used without any modification.

Abstract: A claims-based factory pattern is described for creating objects on an application server. The pattern extends the functionality of factories to include the operations of staking a claim to creating particular objects and re-evaluating their claim in light of other factories staking claims. A process to create an object includes checking all registered factories to see whether they are willing to stake a claim. The claims are then compared to select a factory having the highest claim. If two or more factories have the same claim, they are asked to re-evaluate the claim by providing them information regarding other factories that have also staked a claim. Once the factories have re-evaluated their claims, their number can be reduced to a single factory that will be used to create the object. Alternatively, if no factory can be singled out, the caller can be informed of the deadlock.

Abstract: A model for extending application server functionality includes two types of libraries: an automatically-referenced (auto-ref) library and a superseding library. The auto-ref library includes a special tag that identifies it as the auto-ref library and a pattern that restricts the application types that can refer to it. Once the auto-ref library is deployed, it is automatically referred to by all applications as long as they are not excluded by the restricting pattern. The code contained in the auto-ref library is merged into the application code and the configuration of the library is merged into the application configuration at deployment time. The superseding library also includes an identifying tag and a restriction pattern. At deployment, however, the code and configuration data in the superseding library overrides the corresponding application configuration and code. The remaining code of the application that is not overridden by the superseding library is used without any modification.

Abstract: A claims-based factory pattern is described for creating objects on an application server. The pattern extends the functionality of factories to include the operations of staking a claim to creating particular objects and re-evaluating their claim in light of other factories staking claims. A process to create an object includes checking all registered factories to see whether they are willing to stake a claim. The claims are then compared to select a factory having the highest claim. If two or more factories have the same claim, they are asked to re-evaluate the claim by providing them information regarding other factories that have also staked a claim. Once the factories have re-evaluated their claims, their number can be reduced to a single factory that will be used to create the object. Alternatively, if no factory can be singled out, the caller can be informed of the deadlock.