Systems, methods, and computer-readable media for performing web app scans of an application are provided. Telemetry events derived from the web app scan are intercepted by a runtime that has been instrumented in conjunction with the application. The telemetry events are collected and transmitted to a platform that analyzes the collected events and presents information based on the analysis.

A technique is introduced for intercepting memory calls from a user-space application and applying an allocation policy to determine whether such calls are handled using volatile memory such as dynamic random-access memory (DRAM) or persistent memory (PMEM). In an example embodiment, memory calls from an application are intercepted by a memory allocation capture library. Such calls may be to a memory function such as malloc( ) and may be configured to cause a portion of DRAM to be allocated to the application to process a task. The memory allocation capture library then determines whether the intercepted call satisfies capture criteria associated with an allocation policy. If the intercepted call does satisfy the capture criteria, the call is processed to cause a portion of PMEM to be allocated to the application instead of DRAM.

Systems and methods for providing a development application having a tiered application pattern. One system includes an electronic processor configured to, with a gateway layer, receive and route a request to an application layer. In response to receiving the request from the gateway layer, the electronic processor is also configured to, with the application layer, perform application functionality corresponding to a function associated with the request. The application functionality includes generating an application event. The electronic processor is configured to receive, with an event stream layer, the application event from the application layer. The electronic processor is configured to, with the data processing layer, access the application event and process the application event. The electronic processor is configured to transmit, with the data processing layer, the processed application event to a data storage layer.

A system, method, and computer readable medium for asynchronous live migration of applications between two or more servers. The computer readable medium includes computer-executable instructions for execution by a processing system. Primary applications runs on primary hosts and one or more replicated instances of each primary application run on one or more backup hosts. Asynchronous live migration is provided through a combination of process replication, logging, barrier synchronization, checkpointing, reliable messaging and message playback. The live migration is transparent to the application and requires no modification to the application, operating system, networking stack or libraries.

A service proxy is described herein. The service proxy is configured to act as an intermediary between a client and a service. The service proxy may observe communications, modify communications, log communications, or the like, particularly so as to enhance the security and reliability of the host device. In some implementations, the service proxy may cooperate with an operating system to take over a named port object. In some implementations, the service proxy may receive messages as an intermediary between the client and the server. In some implementations, the service proxy may attach to a shared memory to intercept communications. In some implementations, the service proxy may be injected into a client process to appear to be the client itself.

Examples of devices and methods for detecting malicious network activity are described. Fake user credentials are saved into memory of a monitored device. The fake user credentials may include a username and a password hash for a nonexistent account. Reconnaissance on the fake user credentials is monitored. A compromised account is detected based on the fake user credential reconnaissance monitoring.

Techniques are provided for synchronous replication for synchronous mirror copy guarantee. A file system dependent technique for synchronous mirror copy guarantee is provided by overriding default behavior of a persistent fence so that the persistent fence is activated to block operations targeting a storage object having a synchronous replication relationship based upon the synchronous replication relationship being out of sync. The default behavior of the persistent fence is overridden to allow operations to be executed upon the storage object based upon the synchronous replication relationship being in sync. A file system independent technique for synchronous mirror copy guarantee is provided by intercepting operations before the operations are received by a file system. The operations are selectively forwarded to the file system or not based upon a state of a synchronous replication relationship.

A hypervisor virtual server system, including a plurality of virtual servers, a plurality of virtual disks that are read from and written to by the plurality of virtual servers, a physical disk, an I/O backend coupled with the physical disk and in communication with the plurality of virtual disks, which reads from and writes to the physical disk, a tapping driver in communication with the plurality of virtual servers, which intercepts I/O requests made by any one of said plurality of virtual servers to any one of said plurality of virtual disks, and a virtual data services appliance, in communication with the tapping driver, which receives the intercepted I/O write requests from the tapping driver, and that provides data services based thereon.

Execution of multiple execution streams is scheduled on at least one coprocessor. A software layer located logically between applications and the at least one coprocessor intercepts a first API call from an application and determines that a first execution stream is to be executed. Before scheduling the first execution stream, the software layer transmits a response to the application indicating that the at least one coprocessor is ready to execute another execution stream. The software layer intercepts a second API call from the application and determines that a second execution stream including one or more kernels is to be executed. The software layer determines that the one or more kernels does not have a dependency on the first execution stream. The software layer schedules the one or more kernels for execution prior to when the at least one coprocessor has completed execution of the first execution stream.

An Application Programming Interface (API) call that is directed from a first application to a second application is intercepted. A first version number is identified for the first application and a second version number is identified for the second application. One or more transformations are processed on the API call to produce a compatible API call that is compatible with the second application. The compatible API call is provided to the second application for processing on behalf of the first application.