Computer-implemented method, computer program product, and remote computer server for repairing a crashed application (Remote repair of a crashed process)

Abstract

To provide a computer implemented method, a computer program product, and a remote computer server for remote recovery of a crashed process.SOLUTION: A method for recovering a crashed application includes detecting a crash of an application operating on a host computing device. The application is migrated to a remote computer server. While the application is resident on the remote computer server, the remote computer server provisions a computing resource to the application. A restarted operation of the application is executed using the computing resource provisioned in the remote computer server. An execution result is generated from the application in the remote computer server. The generated execution result is migrated from the application to the host computing device.SELECTED DRAWING: Figure 3B

Description

[Technical Field]

[0001] The present disclosure relates generally to networks, and more particularly to a system and method for remotely repairing a crashed process. [Background technology]

[0002] Users of computationally intensive applications, such as computer simulations or training artificial intelligence (AI) models, may initially attempt to run those applications on their computing devices because it is not readily apparent to the user before running the application what the actual application resources involved are. When attempting to run the simulation or AI model, such applications may not start running due to insufficient memory or some accelerator devices being missing or unavailable on the host computing device. A more complex scenario is when the user application starts running and is allowed to run for a while, e.g., several hours. After running for a while, the application crashes due to limitations on the user computing device.

[0003] One approach to prevent application crashes is to use application checkpoints. Checkpoints are usually explicitly programmed or set before system execution, requiring extra effort and time from the user. The user must explicitly program the checkpoint criteria. A checkpoint typically involves stopping the application, copying the necessary data from memory to reliable storage, and continuing execution. If the application supports a checkpoint mechanism, the user can resume the application from the last saved checkpoint. If not, the application will be restarted from scratch, wasting several hours of processing that was previously executed. Summary of the Invention [Problem to be solved by the invention]

[0004] A computer-implemented method, computer program product, and remote computer server for remote recovery of a crashed process are provided. [Means for solving the problem]

[0005] According to one embodiment of the present disclosure, a computer-implemented method for repairing a crashed application includes detecting a crash of an application running on a host computing device. The application is migrated to a remote computer server. Because the application resides on the remote computer server, the remote computer server provisions computing resources for the application. Operations of the application are executed at the remote computer server using the provisioned computing resources. Execution results are generated from the application at the remote computer server. The generated execution results are migrated from the application to the host computing device.

[0006] In one embodiment, it is determined whether the crash was caused by a resource constraint. Provisioning computing resources at a remote computer server allocates computing resources to meet the resource constraint. As can be appreciated, the remote computer server serves as a secondary source for application execution when the original host computer cannot meet the requirements for running the application. This may be a temporary situation for the host computer, such as when the host computer is performing more operations than it can currently handle. Alternatively, it may be an on-demand service that allows users to access high-end applications that require more resources than the current computer can handle.

[0007] According to another embodiment of the present disclosure, a computer program product for repairing a crashed application includes one or more computer-readable storage media and program instructions collectively stored on the one or more computer-readable storage media. The program instructions include detecting a crash of an application running on a host computing device. The application is migrated to a remote computer server. Because the application resides on the remote computer server, the remote computer server provisions computing resources for the application. Operations of the application are executed at the remote computer server using the provisioned computing resources. Execution results are generated from the application at the remote computer server. The generated execution results are migrated from the application to the host computing device.

[0008] According to one embodiment, the instructions identify one or more computing resource types for execution of the application, where a lack of the identified computing resource type caused the crash, and provisioning the computing resource includes providing, by a remote computer server, the identified computing resource type for execution of the application.

[0009] This functionality demonstrates flexibility in the subject technology, where embodiments can distinguish between, for example, memory requirements, hardware, and software instructions. The subject technology can identify what types of resources were missing from the host computing device and then locate those types of resources within the remote server environment.

[0010] According to another embodiment of the present disclosure, a remote computer server for repairing a crashed application on a host computing device includes a network connection, one or more computer-readable storage media, a processor coupled to the network connection and coupled to the one or more computer-readable storage media, and a computer program product, the computer program product including program instructions collectively stored on the one or more computer-readable storage media, the program instructions including detecting a crash of an application running on the host computing device over the network connection. The application is migrated to the remote computer server over the network connection. Because the application resides on the remote computer server, the remote computer server provisions computing resources for the application. Operations of the application are executed at the remote computer server using the provisioned computing resources. Execution results are generated from the application at the remote computer server. The generated execution results are migrated from the application to the host computing device.

[0011] According to one embodiment, the program instructions may also include identifying a pre-crash state of the application. The pre-crash state includes the current state of the execution results. The instructions roll back the application to the pre-crash state at the remote computer server before provisioning computing resources. This functionality can eliminate duplication of execution steps, thus saving time and computing resources from re-executing steps that already have results on file. This functionality can also lead to a seamless end-user experience.

[0012] Further, in general to the embodiments disclosed above, it will be appreciated that the functionality of the subject technology provides an alternative means of computing resources when a local computing device cannot handle the requirements needed by an application. In some instances, a local device may be able to handle some of the requirements for running an application, but subsequently, the device may lack one (or more) of the requirements. It will be appreciated that by migrating an application to a remote server, the application is exposed to a more robust computing environment with access to larger memory pools, newer, more powerful hardware devices, and newer, improved versions of software tools, all of which can accommodate the load that the local device cannot handle. In another example scenario, a computing device is typically fully functional with the software applications available at the time of the device's purchase. However, as software applications are updated to new versions or new applications are designed and their computing requirements increase, the computing device's hardware and software may quickly become outdated or unable to keep up with the new requirements. By migrating applications to a remote server and provisioning resources accessible from the remote server, the local computing device's capabilities essentially become equivalent to those of the remote computer server, allowing the local device to operate some applications that it would not normally be able to physically run.

[0013] The techniques described herein may be implemented in many ways. Exemplary implementations are provided below with reference to the following figures. [Brief explanation of the drawings]

[0014] The drawings depict exemplary embodiments. They do not illustrate all embodiments. Other embodiments may be used in addition or instead. To save space or for a more effective explanation, details that may be obvious or unnecessary may be omitted. Some embodiments may be practiced with additional components or steps, or without all of the components or steps shown, or both. When the same numeral appears in different drawings, it refers to the same or similar components or steps.

[0015] [Figure 1] FIG. 1 is a block diagram of an architecture for remote repair of crashed applications, according to an example embodiment. [Figure 2] FIG. 2 is a block diagram of a system for remote repair of crashed applications in accordance with an example embodiment. [Figure 3A] FIG. 3A is a flowchart of a method for remotely repairing a crashed application, according to some embodiments. [Figure 3B] FIG. 3B is a flowchart of a method for remotely repairing a crashed application according to some embodiments. [Figure 4] FIG. 4 is a flowchart of a method for identifying missing computing resources according to some embodiments. [Figure 5] FIG. 5 is a functional block diagram of a specially configured computer hardware platform capable of communicating with various networked components consistent with an exemplary embodiment. [Figure 6] FIG. 6 is a diagram illustrating a cloud computing environment consistent with an illustrative embodiment. [Figure 7] FIG. 7 is a diagram illustrating abstraction model layers, consistent with an illustrative embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0016] (overview) In the following detailed description, numerous specific details are set forth by way of example in order to provide a thorough understanding of the relevant teachings. However, it should be apparent that the present teachings may be practiced without such details. In other instances, well-known methods, procedures, components, or circuits, or combinations thereof, have been described at a relatively high-level, without detail, in order to avoid unnecessarily obscuring aspects of the present teachings.

[0017] The present disclosure generally relates to systems and methods for repairing crashed applications by remotely provisioning resources. Generally, embodiments may be implemented in the fields of computer networking and data processing. As will be appreciated, aspects of the subject disclosure transfer a crashed application to a remote computer server where the application can be resumed and run to its intended results. Technical aspects of the subject technology free applications to run without knowledge of the resources involved in running the application process. This relieves end users from having to design some applications with a conservative approach to resource requirements. Furthermore, by leveraging the resource capabilities of an online remote computing system, applications can be locally run that exceed the physical capabilities of the local computing device. Furthermore, the subject technology allows local devices to take advantage of newly developed resources, including, for example, new processing chips, accelerators, read / write devices, etc., without necessarily having to upgrade the local computing device. Some embodiments of the subject technology may automatically provide crash repair in a seamless manner such that the end user is unaware that a crash occurred, as execution results can be provided back to the host device in a manner transparent to the user.

[0018] (Example architecture) 1 illustrates an example of an architecture 100 for remote repair of crashed applications. The architecture 100 includes a network 106 that enables various computing devices 102(1)-102(N) to communicate with each other, as well as other elements connected to the network 106, such as a troubleshooting strategy handler module 112, a remote application recovery server 116, and a cloud 120. In the context of providing crash recovery services in accordance with the subject disclosure, the computing devices 102(1)-102(N) may be end-user devices with insufficient resources to run computationally intensive applications. One or more of the computing devices 102(1)-102(N) have experienced an application crash that is remedied by aspects of the system 100, as disclosed in more detail herein and in the following figures. Generally, when one of the computing devices 102(1)-102(N) experiences an application crash, the remote application recovery engine 110 may detect the crash event and may respond by repairing the application remotely from the host source device (the computing device 102(1)-102(N)), resuming execution of the application at the server level, and providing a service that delivers the execution results back to the original host device.

[0019] The network 106 may be, but is not limited to, a local area network ("LAN"), a virtual private network ("VPN"), a cellular network, the Internet, or a combination thereof. For example, the network 106 may include a mobile network communicatively coupled to a private network, sometimes referred to as an intranet, that provides various auxiliary services, such as communication with various application stores, libraries, and the Internet. The network 106 enables a remote application recovery engine 110, which is a software program running on a remote application recovery server 116, to communicate with and provide data processing to a troubleshooting strategy handler module 112, the computing devices 102(1)-102(N), and the cloud 120. The troubleshooting strategy handler module 112 may provide a crash data recovery solution that may be used to process one or more of the techniques described herein. In one embodiment, the crash recovery process is performed at least in part on the cloud 120, leveraging resources from multiple sources, including physical and virtual devices. In a cloud-based embodiment, resources may be collected from different computing devices connected to the cloud network. Thus, when reference is made to “provisioning of resources by a remote computer server,” it will be understood that the actual use of the resources may occur at multiple devices or locations within cloud 120 .

[0020] For later discussion, several user devices appear in the drawing to represent some example computing devices that may be sources of data analyzed for underlying crash causes, application resource requirements, application execution, and outcomes. Aspects of application data / documents (e.g., 103(1) and 103(N)) can be communicated over network 106 to remote application recovery engine 110 of remote application recovery server 116. Today, user devices typically take the form of portable handsets, smartphones, tablet computers, personal digital assistants (PDAs), and smartwatches, although they may also be implemented in other form factors, including consumer and business electronic devices.

[0021] While the troubleshooting strategy handler module 112 and the remote application recovery engine 110 are illustrated as being on different platforms, it will be understood that in various embodiments, the troubleshooting strategy handler module 112 and the remote application recovery server 116 may be combined. In other embodiments, these computing platforms may be implemented by virtual computing devices in the form of virtual machines or software containers hosted on the cloud 120, thereby providing a resilient architecture for processing and storage.

[0022] 2, a remote infrastructure 200 for repairing crashed applications is shown, according to one embodiment. The infrastructure 200 may generally include elements used to retrieve and repair a crashed application 205 from a local computing device 102. The crashed application 205, once processed under the subject technology, resumes execution on the remote server system 116 (shown as resumed application 240). An operation system crash handler 210 may generally reside on the local computing device. The operation system crash handler 210 may retrieve and provide the memory state 220 of the crashed application to the remote infrastructure 200.

[0023] In the infrastructure 200, the memory state handler module 230 may receive a memory state image of the crashed application from the local computing device 102. The resource constraint identifier module 215 may receive retrieved data related to the crashed application 205, including a copy of the application and the current state of the application's execution before the crash. The troubleshooting strategy handler module 112 may be accessed to provide a process for identifying the root cause(s) of the crash and identifying the resources needed to resume the application's execution on the server side. The migration handler module 225 may coordinate the migration of the crashed application 205 to the remote application recovery server(s) 116 and the resulting migration of the resumed application 240 back to the local computing device 102. While the network 106, the remote server(s) 116, the resource constraint identifier module 215, and the migration handler module 225 are shown as separate elements, it will be understood that embodiments may generally integrate the resource constraint identifier module 215 and the migration handler module 225 into the server(s) 116, and the server(s) 116 may be part of the network 106.

[0024] (Example of method) 3A and 3B, a method 300 for remotely repairing a crashed application is shown, according to an example embodiment. As noted above, the following functions may generally occur at a computer server located remotely from the local computing device that executes the application. Thus, references to a "system" may refer to one or more elements located remotely from the local device.

[0025] Generally, the operations of method 300 may be triggered by the system detecting, at 310, that an application running on a local device has experienced an execution interruption / crash. A remote computer server (e.g., remote application recovery server 116) may identify, at 315, the reason for the application crash. For example, using resource constraint identifier module 215 (see FIG. 2), operating system metrics may be monitored (e.g., elevated memory or storage utilization), and log files (from both the operating system and the application) may be used to identify the resource constraint that caused the application to crash. Examples of crash sources include application execution interruption due to a limited amount of memory required by the application, or application execution requiring GPU instructions that are unavailable on the user device at a given time. The process's memory state file may also be examined. The memory state may be searched for illegal instruction signals and bus error signals received by the process. Error codes and messages may be retrieved from the top frame of each thread belonging to that memory state to help determine the reason for such a crash.

[0026] Referring momentarily to FIG. 4, an exemplary embodiment illustrates a crash recovery troubleshooting architecture 400 for identifying the root cause of a crash. The architecture 400 may be implemented by the troubleshooting strategy handler module 112 (FIG. 1). Generally, the architecture 400 may be triggered when an application 405 encounters an illegal instruction. The operating system 410 of the local computing device may include an illegal instruction trap handler module 415. In an exemplary implementation, a running software application 405 crashes, generating a software or hardware trap that is captured by the operating system 410 of the local device. The operating system 410 of the local device may collect the memory state of one or more processes associated with that software application 405 by capturing an image of the state. The illegal instruction trap handler module 415 saves the data image of the memory state to a file on disk. The illegal instruction file information may include the values ​​of CPU registers at the time of the crash. A remote server system is then notified of the crash and receives a pointer to the memory state file of the process. In some embodiments, the remote computer server includes the resource constraint identifier module 215.

[0027] The resource limit identifier module 215 may read a captured image of the memory state provided by the local computing device. Additionally, signals delivered to the process may be checked. The resource limit identifier module 215 may query the troubleshooting strategy handler module 112 to identify faulty or missing resources.

[0028] The troubleshooting strategy handler module 112 can read the captured image from the resource limit identifier module 440 and analyze the CPU-related information 420, GPU-related information 425, and system-related information 430. For example, if a process receives a "KILL" signal, the system can analyze the syslog to use the script "find_keywords.py" to investigate why the signal was killed. This can occur, for example, when an out-of-memory condition occurs or when a program logic bug corrupts the process's memory. As another example, if a process receives a "SIGILL" signal, the process image can be scanned for illegal instructions and the program counter and register values ​​can be extracted using the "parse_registers.py" script. This script searches the CPU-related information table 420 for the program counter and register values.

[0029] In some embodiments, the remote computer server may determine at 320 whether the cause of the crash is due to a resource constraint or a resource access error. There are several reasons why an application may be interrupted. One may be a hardware resource constraint or some software or input data dependency. If this step detects that the interruption is due to a software or input data dependency, a notification may be presented to the user and no further action may be taken. However, if the crash is due to a hardware limitation, the method may continue.

[0030] The remote computer server can identify 325 the type of resource (or lack thereof) that caused the application execution to be interrupted and that the local device needs to execute the application to its intended result. Further investigation may be performed to understand what is missing to meet the application's requirements. For example, if the problem is a memory limitation, the remote computer server may generate an estimate of the amount of memory needed for the application. Alternatively, if the problem is a specific hardware (e.g., GPU or other accelerator) instruction (or set of instructions), the instruction and the type of hardware that can provide such instruction are identified.

[0031] Each type of resource can have a software component that describes how to identify such requests, and there can be several implementations, including rule-based or machine learning-based components.

[0032] If memory is a type of resource required, it is very common for an application to be suspended due to a limited amount of memory on the local device running the application. One possible embodiment estimates the amount of memory an application will require by checking storage (e.g., the crash data troubleshooting module of FIG. 1 ) for previous runs of the same application with different input parameter values. For example, assume a user is running a multi-agent simulation with 200 agents and the user device has 4 GB of RAM. With 200 agents, the application cannot run on the user terminal. However, the user can run it with 5, 10, 20, 50, or 100 agents. By accessing logs and operating system measurements, an embodiment may estimate a curve (not shown) relating the number of agents to memory consumption, which can be used to estimate the amount of memory required to run a given number of agents, such as 200, on the local user device. The curve may have a different shape, such as linear or exponential.

[0033] In some instances, a crash is caused by a lack of hardware. For example, processor architectures such as ARM (Advanced RISK Machine) provide a CPU that supports a core set of instructions. Processor extensions are provided to hardware designers who wish to include support for optional features. Floating-point and vector instructions are two examples. If application code is compiled with support for such instruction extensions, but the underlying hardware does not include the corresponding processor extension, an "illegal instruction" trap is received by the operating system. By checking registers upon such a trap, embodiments may determine which instruction failed and what hardware resources should be allocated to allow the application to run to completion.

[0034] In some embodiments, the remote computer server may determine whether execution repair is possible at 330. Depending on the type and requirements of the application, a set of validations may be performed. Embodiments of such validations include:

[0035] Verify whether the application depends on any type of resource that is only available locally (e.g., intranet services).

[0036] For native applications, verify whether the application contains symbols that can be used to revert the application's execution to an earlier point. For example, one technique available to do this is debug record and replay, which uses such symbols in conjunction with the program counter so that the application can be rolled back to a previous execution state.

[0037] For managed applications (e.g., high-level runtimes), a reverse debugger engine can be used to revert program execution to the step immediately preceding the resource usage command, preserving the software's execution context.

[0038] In some embodiments, the remote computer server may check the availability of resources in the remote infrastructure of the remote computer server before attempting to repair the application at 335. The remote infrastructure provider may be queried to check whether resources relevant to continuing execution are available. If the resources are unavailable, processing may terminate.

[0039] If the resources are available, the system may fetch updated quotes for the resources at the remote infrastructure. Once these quotes are obtained, the system uses them to estimate the hourly rate for the requested resources at the remote infrastructure. Once the rates are estimated, in one embodiment, the system may estimate the total execution time of the application and ask the user if they wish to continue (e.g., some embodiments may involve authorizing or paying for additional resources). If the user does not agree, processing may terminate.

[0040] In some embodiments, the remote computer server may determine at 340 whether migration of the application is possible. The memory state of the process is checked for handlers on resources that must exist on the destination host. Handlers that depend on local resources (such as network connections to hosts that belong to the same private network) may not be able to be restored on the destination server. The user may be prompted to respond if there are legal or compliance constraints that do not allow the application to run at a remote location. In some embodiments, the availability of resources in the remote infrastructure for running the application may be checked in advance.

[0041] In some embodiments, the remote computer server may determine at 345 whether the crashed application is worth repairing. In some embodiments, the repair may be performed from the point where the application crashed. The determination may include comparing the time to transition execution from a point just before the crash to the time to restart the application from start to the point where it crashed, given a new set of computing resources. Some embodiments may calculate the amount of computing resources and processing time involved compared to threshold cutoff values, for example, to prevent an application from consuming too many remote resources.

[0042] Generally, once the remote computer server identifies the resources involved in remotely executing the application, a remediation process is performed at 350. The remote computer server locates the required resources and provisions them for execution of the application at 355. The application may be migrated from the host local computing device to the remote computer server at 360. Execution of the application may resume at 365 on the remote computer server. In some embodiments, the remote computer server may continue to monitor the execution of the application for execution performance at 370. In some embodiments, the remote computer server may understand resource usage application patterns. The application's resource usage, including, for example, memory, network, CPU, and accelerator usage, may confirm whether the migration was successful in terms of the selected troubleshooting strategy and allocated resources at the remote host. In some embodiments, the remote computer server may collect information about the performed remediation / migration process at 375. The collected information may be used in a learning process to enhance the troubleshooting strategy handler module 112. The executed application and results may be migrated back to the original local computing device at 380. In some embodiments, after the application results are migrated back to the local computing device, at 385 the connection to the remote computer server resource may be terminated.

[0043] (Example of a computer platform) As noted above, the interpretable modeling-related functionality of the subject disclosure may be performed using one or more computing devices connected for data communication via wireless or wired communication, as shown in Figure 1. Figure 5 is a functional block diagram of a specially configured computer hardware platform capable of communicating with various networked components, such as troubleshooting strategy handler module 112, the cloud, etc. In particular, Figure 5 illustrates a network or host computer platform 500, such as may be used to implement a server, such as remote application recovery server 116 of Figure 1.

[0044] The computer platform 500 may include a central processing unit (CPU) 504, a hard disk drive (HDD) 506, random access memory (RAM) and / or read-only memory (ROM) 508, a keyboard 510, a mouse 512, a display 514, and a communication interface 516 connected to a system bus 502.

[0045] In one embodiment, HDD 506 has functionality that includes storing programs capable of executing various processes, such as materials discovery machine learning engine 540, in the manner described herein. Generally, remote application recovery engine 540 may be configured under the above-described embodiments to automatically repair crashed applications and resume application execution remotely from the local device. Remote application recovery engine 540 may have various modules configured to perform different functions.

[0046] For example, the remote application recovery engine 540 may include the troubleshooting strategy handler module 112, the resource restriction identifier module 215, the execution transition handler module 225, and the application state memory handler module 230, whose functions are described above.

[0047] (Example of a cloud platform) As mentioned above, functionality related to processing data using machine learning models to discover new materials for application-specific tasks (e.g., carbon dioxide separation) may include a cloud computing environment 120 (see FIG. 1 ). While the present disclosure includes detailed descriptions related to cloud computing, it will be understood that implementation of the teachings described herein is not limited to a cloud computing environment. Rather, embodiments of the present disclosure may be practiced in conjunction with any other type of computing environment now known or later developed.

[0048] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with the service provider. This cloud model may include at least five characteristics, at least three service models, and at least four implementation models.

[0049] The characteristics are as follows:

[0050] On-Demand Self-Service: Cloud consumers can unilaterally provision computing capacity, such as server time or network storage, automatically as needed, without the need for human interaction with the service provider.

[0051] Broad network access: Computing power is available over the network and can be accessed through standard mechanisms, facilitating use by heterogeneous thin or thick client platforms (e.g., cell phones, laptops, PDAs).

[0052] Resource Pooling: Computing resources from a provider are pooled and offered to multiple consumers using a multi-tenant model. Various physical and virtual resources are dynamically allocated and reallocated based on demand. Consumers generally have no control or knowledge of the exact location of the resources they are provided with, so there is a sense of location independence. However, consumers may be able to identify their location at a higher level of abstraction (e.g., country, state, data center).

[0053] Rapid Elasticity: Computing capacity can be provisioned quickly and elastically, sometimes automatically, to instantly scale out and quickly released to instantly scale in. To the consumer, the computing power available to provision often appears unlimited, and can be purchased at any time and in any quantity.

[0054] Metered Services: Cloud systems leverage measurement capabilities at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, active user count) to automatically control and optimize resource usage. Resource usage can be monitored, controlled, and reported to provide transparency to both providers and consumers of utilized services.

[0055] The service model is as follows:

[0056] Software as a Service (SaaS): The functionality offered to the consumer is the availability of a provider's applications running on a cloud infrastructure. The applications can be accessed from a variety of client devices through a thin client interface such as a web browser (e.g., webmail). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application functions, except for limited user-specific application configuration settings.

[0057] Platform as a Service (PaaS): The capability offered to consumers is to deploy applications they create or acquire onto a cloud infrastructure using programming languages ​​and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but does have control over the deployed applications and, in some cases, the configuration of their hosting environment.

[0058] Infrastructure as a Service (IaaS): The functionality provided to consumers is the provisioning of processors, storage, networking, and other basic computing resources on which the consumer can deploy and run any software, including operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but has control over the operating systems, storage, and deployed applications, and in some cases partial control over some network components (e.g., host firewalls).

[0059] The deployment model is as follows:

[0060] Private Cloud: This cloud infrastructure is dedicated to a specific organization and can be managed by that organization or a third party, and can exist on-premise or off-premise.

[0061] Community Cloud: This cloud infrastructure is shared by multiple organizations to support a specific community with common concerns (e.g., mission, security requirements, policies, and compliance). This cloud infrastructure can be managed by those organizations or a third party and can exist on-premises or off-premises.

[0062] Public cloud: This cloud infrastructure is available to the general public or large industry organizations and is owned by an organization that sells cloud services.

[0063] Hybrid cloud: This cloud infrastructure combines two or more cloud models (private, community, or public), each of which retains its inherent nuances but is bound by standards or specific technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

[0064] A cloud computing environment is a service-oriented environment that emphasizes statelessness, low coupling, modularity, and semantic interoperability. At the core of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0065] FIG. 6 illustrates an exemplary cloud computing environment 600. As illustrated, the cloud computing environment 600 includes one or more cloud computing nodes 610, with which local computing devices used by cloud consumers (e.g., PDAs or cell phones 654A, desktop computers 654B, laptop computers 654C, or automobile computer systems 654N, or combinations thereof) can communicate. The nodes 610 can communicate with each other. The nodes 610 can be physically or virtually grouped (not shown) in one or more networks, such as, for example, the private, community, public, or hybrid clouds described above, or combinations thereof. This enables the cloud computing environment 650 to provide infrastructure, platform, or software as a service, or combinations thereof, for which cloud consumers are not required to maintain resources on their local computing devices. It should be understood that the types of computing devices 654A-N illustrated in FIG. 6 are merely exemplary, and that the computing nodes 610 and the cloud computing environment 650 can communicate with any type of electronic device via any type of network or network-addressable connection (e.g., using a web browser), or both.

[0066] Next, a set of functional abstraction layers provided by cloud computing environment 650 (FIG. 6) is shown in FIG. 7. It should be understood in advance that the components, layers, and functions shown in FIG. 7 are merely exemplary, and embodiments of the present disclosure are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0067] Hardware and software layer 760 includes hardware and software components. Examples of hardware components include mainframe 761, reduced instruction set computer (RISC) architecture-based server 762, server 763, blade server 764, storage device 765, and network and network components 766. In some embodiments, software components include network application server software 767 and database software 768.

[0068] The virtualization layer 770 provides an abstraction layer from which virtual entities such as virtual servers 771, virtual storage 772, virtual networks including virtual private networks 773, virtual applications and operating systems 774, and virtual clients 775 can be provided.

[0069] By way of example, the management layer 780 may provide the following functionality: Resource provisioning 781 enables dynamic procurement of computing and other resources utilized to execute tasks within the cloud computing environment. Metering and pricing 782 enables cost tracking as resources are utilized within the cloud computing environment and billing or invoicing for the consumption of these resources. By way of example, these resources may include application software licenses. Security enables identification and verification of cloud consumers and tasks, as well as protection for data and other resources. User portal 783 provides consumers and system administrators with access to the cloud computing environment. Service level management 784 enables allocation and management of cloud computing resources so that requested service levels are met. Service level agreement (SLA) planning and fulfillment 785 enables advance arrangement and procurement of anticipated future cloud computing resources required according to SLAs.

[0070] The workload layer 790 provides examples of functionality available in a cloud computing environment. Examples of workloads and functionality that can be provided from this layer include mapping and navigation 791, software development and lifecycle management 792, virtual classroom instruction delivery 793, data analytics processing 794, transaction processing 795, and remote crash application recovery and execution 796.

[0071] (Conclusion) The description of various embodiments of the present teachings is presented for purposes of illustration, but is not intended to be exhaustive or limited to the disclosed embodiments. It will be apparent to those skilled in the art that many modifications and variations are possible without departing from the scope and spirit of the described embodiments. The terms used herein have been selected to explain the principles of the embodiments, practical applications or technical improvements to technology found in the market, or to enable those skilled in the art to understand the embodiments disclosed herein.

[0072] While the above describes what is considered to be the best mode and / or alternative embodiments, it is understood that various modifications may be made therein, that the subject matter disclosed herein may be embodied in a variety of forms and embodiments, and that the teachings may be applied in numerous applications, only some of which are described herein. It is intended that the following claims claim all applications, modifications, and variations that fall within the true scope of the present teachings.

[0073] The components, steps, features, objects, values, and advantages described herein are merely exemplary. Neither they nor the discussion thereof is intended to limit the scope of protection. While various advantages have been discussed herein, it will be understood that not all embodiments necessarily include all advantages. Unless otherwise specified, all measurements, values, ratings, positions, dimensions, sizes, and other specifications described herein, including those set forth in the following claims, are approximate and not exact. They are intended to have a reasonable range consistent with the function to which they relate and that which is customary in the technical field to which they pertain.

[0074] Numerous other embodiments are contemplated, including embodiments having fewer, additional, or different, or combinations of, components, steps, features, objects, values, and advantages, including embodiments in which components and / or steps are arranged and / or ordered differently.

[0075] Aspects of the present disclosure are described herein with reference to flowchart and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present disclosure. Each step in the flowchart and / or block diagrams, and combinations of blocks in the call flow diagrams and / or block diagrams, can be implemented by computer-readable program instructions.

[0076] The computer-readable program instructions may be provided to a processor of a computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, when executed by the processor of such computer or other programmable data processing apparatus, create means for performing the functions / acts specified in one or more blocks of the call flow processes and / or block diagrams. The computer-readable program instructions may also be stored on a computer-readable storage medium capable of instructing a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner. The computer-readable storage medium having the instructions stored thereon thereby constitutes an article of manufacture including instructions for performing aspects of the functions / acts specified in one or more blocks of the call flows and / or block diagrams.

[0077] Computer-readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device and a series of operational steps executed on the computer, other programmable apparatus, or other device to create a computer-implemented process, whereby the instructions executing on the computer, other programmable apparatus, or other device perform the functions / operations identified in one or more blocks in the call flow processes and / or block diagrams.

[0078] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a call flow process or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions for performing a particular logical function. In some other implementations, the functions shown in the blocks may be executed in an order different from that shown in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently or in the reverse order, depending on the functionality involved. Note that each block in the block diagrams and / or call flow diagrams, and combinations of blocks in the block diagrams and / or call flow diagrams, may be implemented by a dedicated hardware-based system that performs the specified function or operation, or by a combination of dedicated hardware and computer instructions.

[0079] While the foregoing has been described in connection with exemplary embodiments, it is understood that the term "exemplary" means merely an example, not best or optimal. Except as noted above, nothing described or illustrated is intended to, or should be construed to, induce the public to dedicate any component, step, feature, object, value, advantage, or equivalent, whether or not claimed.

[0080] Terms and expressions used herein are understood to have the ordinary meanings given to such terms and expressions in relation to their respective fields of inquiry and study, unless a specific meaning is otherwise stated herein. Relationship terms such as first and second, etc., may be used merely to distinguish one entity or action from another, without necessarily requiring or implying any actual relationship or order between such entities or actions. The terms "comprises," "comprising," or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements may not include only those elements, but may include other elements not expressly listed or inherent in such process, method, article, or apparatus. An element preceded by the singular form "a" or "an" does not, without further constraints, exclude the presence of additional identical elements in a process, method, article, or apparatus that includes that element.

[0081] The Abstract of the Disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Moreover, in the foregoing Detailed Description, it can be seen that various features are grouped together in various embodiments for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments have more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Accordingly, the following claims are incorporated into the Detailed Description, with each claim standing on its own as separately claimed subject matter.

Claims

1. 1. A computer-implemented method for repairing a crashed application, comprising: Detecting a crash of an application running on a host computing device; Migrating the application to a remote computer server; provisioning, by the remote computer server, computing resources to the application while the application resides on the remote computer server; executing operations of the application at the remote computer server using the provisioned computing resources; generating an execution result from the application at the remote computer server; migrating the generated execution results from the application to the host computing device; 11. A computer-implemented method comprising:

2. determining whether the crash was caused by a resource constraint, wherein the provisioning of computing resources allocates computing resources to satisfy the resource constraint; The computer-implemented method of claim 1 , further comprising:

3. further comprising identifying one or more computing resource types for the execution of the application; a shortage of the identified one or more computing resource types caused the crash; the provisioning of computing resources includes providing, by the remote computer server, the identified one or more computing resource types for the execution of the application. The computer-implemented method of claim 1 .

4. the identified one or more computing resource types include access to a piece of hardware; the provisioning of computing resources includes accessing a portion of the hardware at the remote computer server; The computer-implemented method of claim 3 .

5. identifying a pre-crash state of the application, the pre-crash state including a current state of execution; rolling back the application to the pre-crash state at the remote computer server before provisioning the computing resources; The computer-implemented method of claim 1 , comprising:

6. executing the application on the remote computer server from the current state of the execution results before migrating the generated execution results from the application to the host computing device; The computer-implemented method of claim 5 further comprising:

7. determining a resource cost associated with repairing the application; determining whether to provision the computing resource based on the resource cost; The computer-implemented method of claim 1 , further comprising:

8. 1. A computer program product for repairing a crashed application, the computer program product comprising: one or more computer-readable storage media; and program instructions collectively stored on the one or more computer-readable storage media, the program instructions comprising: Detecting a crash of an application running on a host computing device; Migrating the application to a remote computer server; provisioning, by the remote computer server, computing resources to the application while the application resides on the remote computer server; executing operations of the application at the remote computer server using the provisioned computing resources; generating an execution result from the application at the remote computer server; migrating the generated execution results from the application to the host computing device; a computer program product,

9. The program instructions further include determining whether the crash was caused by a resource constraint; The provisioning of computing resources includes allocating computing resources to satisfy the resource constraints.

9. A computer program product according to claim 8.

10. the program instructions further include identifying one or more computing resource types for the execution of the application; a shortage of the identified one or more computing resource types caused the crash; the provisioning of computing resources includes providing, by the remote computer server, the identified one or more computing resource types for the execution of the application.

9. A computer program product according to claim 8.

11. the identified one or more computing resource types include access to a piece of hardware; the provisioning of computing resources includes accessing a portion of the hardware at the remote computer server; 11. The computer program product of claim 10.

12. The program instructions include: identifying a pre-crash state of the application, the pre-crash state including a current state of execution; rolling back the application to the pre-crash state at the remote computer server before provisioning the computing resources; 9. The computer program product of claim 8, further comprising:

13. The program instructions execute the application on the remote computer server from a current state of the execution results before migrating the generated execution results from the application to the host computing device.

13. The computer program product of claim 12, further comprising:

14. The program instructions include: determining a resource cost associated with repairing the application; determining whether to provision the computing resource based on the resource cost; 9. The computer program product of claim 8, further comprising:

15. 1. A remote computer server for repairing a crashed application on a host computing device, comprising: Network connection and one or more computer-readable storage media; a processor coupled to the network connection and coupled to the one or more computer readable storage media; a computer program product including program instructions collectively stored on said one or more computer-readable storage media, said program instructions comprising: detecting a crash of an application running on a host computing device via the network connection; migrating the application to a remote computer server over the network connection; provisioning, by the remote computer server, computing resources to the application while the application resides on the remote computer server; executing operations of the application at the remote computer server using the provisioned computing resources; generating an execution result from the application at the remote computer server; migrating the generated execution results from the application to the host computing device; a remote computer server, including

16. The program instructions further include determining whether the crash was caused by a resource constraint; The provisioning of computing resources includes allocating computing resources to satisfy the resource constraints.

16. The remote computer server of claim 15.

17. the program instructions further include identifying one or more computing resource types for the execution of the application; a shortage of the identified one or more computing resource types caused the crash; the provisioning of computing resources includes providing, by the remote computer server, the identified one or more computing resource types for the execution of the application.

16. The remote computer server of claim 15.

18. the identified one or more computing resource types include access to a piece of hardware; the provisioning of computing resources includes accessing a portion of the hardware at the remote computer server; 20. The remote computer server of claim 17.

19. The program instructions include: identifying a pre-crash state of the application, the pre-crash state including a current state of execution; rolling back the application to the pre-crash state at the remote computer server before provisioning the computing resources; 16. The remote computer server of claim 15, further comprising:

20. The program instructions execute the application on the remote computer server from a current state of the execution results before migrating the generated execution results from the application to the host computing device.

20. The remote computer server of claim 19, further comprising:

Images