Patent classifications
G06F11/0715
SELECTIVE PRIVILEGED CONTAINER AUGMENTATION
Selective privileged container augmentation is provided. A target group of edge devices is selected from a plurality of edge devices to run a plurality of child tasks comprising a pending task by mapping edge device tag attributes of the plurality of edge devices to child task tag attributes of the plurality of child tasks. A privileged container corresponding to the pending task is installed in each edge device of the target group to monitor execution of a child task by a given edge device of the target group. A privileged container installation tag that corresponds to the privileged container is added to an edge device tag attribute of each edge device of the target group having the privileged container installed. A child task of the plurality of child tasks comprising the pending task is sent to a selected edge device in the target group to run the child task.
SYSTEM MANAGEMENT DEVICE AND SYSTEM MANAGEMENT METHOD
A system management device manages a monitored system. When a performance failure occurs in the monitored system, the system management device creates a plurality of countermeasures for the performance failure. The system management device evaluates, for each of the plurality of countermeasures, the influence of the countermeasure on the execution of a job having an execution deadline associated with the countermeasure. The system management device selects the countermeasure to be executed on the monitored system from out of the plurality of countermeasures based on the evaluation results.
SYSTEM AND METHOD FOR DETECTING AND FIXING ROBOTIC PROCESS AUTOMATION FAILURES
A system and method for detecting and fixing robotic process automation failures, including collecting tasks from at least one client computerized device, processing the tasks via robotic process automation, collecting tasks that failed to complete per task type, recording successful execution steps per each of the failed tasks, evaluating the recorded successful execution steps with respect to the failed task types, and providing selected execution steps that best fix the failed tasks, thereby fixing the robotic process automation failures.
PREEMPTIBLE-BASED SCAFFOLD HOPPING
In a method of molecular scaffold hopping an interface of a scheduler computer sends instructions, prepared by the scheduler computer, to a job runner computer to perform a plurality of separate computational tasks. Each of the separate computational tasks includes calculating one or more chemical properties for a query molecule or molecules in a library of molecules. One or more of the plurality of separate computational tasks performed on the job runner computer are preemptible computing instances. Status indicators sent from the job runner computer are received by the interface for each of the plurality of separate computational tasks. The indicators are one of: incomplete, completed, or failed computing instances. The interface resends the instructions to the job runner computer that correspond to the separate computational tasks having the failed computing instance indicator to increase fault-tolerance against the separate computational tasks not attaining the completed computing instance indicator.
Granular tracking of replication consistency using subsets of asynchronous replication tasks
Sets of asynchronous replication operations may be tracked to ensure consistency. A tracking service may receive notifications of pending asynchronous replication tasks, and responsive to receiving a manifest indicating a request to be notified upon completion of a set of pending replication asynchronous tasks, matches individual ones of the tasks within the set to tasks indicated as pending. The tracking service may then select a routing table based on a most recent sequence number associated with the set of tasks, determine one of more tracking nodes assigned to track the set of tasks, and send the manifest to each of the tracking nodes. As individual ones of the tasks complete, notifications of completion may be sent to the tracking nodes and an aggregator node aggregates the completion notifications for the set. Once all completion notifications are received, a response to the request indicating completion may be sent.
APPLICATION LOGGING MECHANISM
A system to facilitate application logging is described. The system includes a processor and a machine readable medium storing instructions that, when executed, cause the processor to record a system state, perform application logging at a first logging rate, record an occurrence of task failures during the logging, determine a predicted queue size threshold value based on the recorded occurrence of task failures, determine whether that the predicted queue size threshold value is less than an actual queue size and perform the application logging at a second logging rate upon a determination that the predicted queue size threshold value is less than an actual queue size, wherein the second logging rate is greater than the first logging rate.
Restart tolerance in system monitoring
When a restart event is detected within a technology landscape, restart-impacted performance metrics and non-restart-impacted performance metrics may be identified. The non-restart-impacted performance metrics may continue to be included within a performance characterization of the technology landscape. The restart-impacted performance metrics may be monitored, while being excluded from the performance characterization. The restart-impacted performance metric of the restart-impacted performance metrics may be transitioned to a non-restart-impacted performance metric, based on a monitored value of the restart-impacted performance metric following the restart event.
AUTOMATED CRASH RECOVERY
Methods for improving operation of a user device executing an application. The methods include collecting a first set of data corresponding to a run time environment of the application, collecting a second set of data corresponding to a crash of the application, identifying a cause of the crash based on the first set of data and a second set of data and determining the cause of the crash is associated with an application feature corresponding to a feature flag.
System and methods for hardware-software cooperative pipeline error detection
An error reporting system utilizes a parity checker to receive data results from execution of an original instruction and a parity bit for the data. A decoder receives an error correcting code (ECC) for data resulting from execution of a shadow instruction of the original instruction, and data error correction is initiated on the original instruction result on condition of a mismatch between the parity bit and the original instruction result, and the decoder asserting a correctable error in the original instruction result.
TROUBLESHOOTING SOFTWARE SERVICES BASED ON SYSTEM CALLS
System calls can be used to troubleshoot problems with software services. For example, a system can receive tracing data indicating system calls executed by a group of software services. The system can analyze parameters of the system calls described in the tracing data to identify relationships between the system calls. The system can determine a sequence of system calls between a predefined starting event and a predefined ending event based on the relationships between the system calls. The system can then generate an output to a user indicating the sequence of system calls. The output can be used by the user to troubleshoot a problem associated with executing the plurality of software services.