Asynchronous cancellation of processing engine requests

Abstract

The disclosure relates to efficient and flexible asynchronous cancellation of uncompleted service requests in a computing system with a processing engine system. For example, the processing engine system facilitates asynchronous cancellation of a request by verifying the request at different stages of a request processing stream using a sequence number. In particular, after efficient execution of a local cancellation operation, the processing engine system ensures that resources associated with cancelled requests are deallocated and other requests are freely processed. Indeed, the processing engine system can provide such a guarantee of no processing resources without contacting or waiting for a remote resource to return an uncompleted processing request.

Description

Background Art

[0001] In recent years, significant hardware and software advances have been seen in computing devices. For example, many entities increasingly use resources and services provided by cloud computing systems. In order to perform many of these services, computing devices within a computing system, such as a cloud computing system, receive and process numerous user requests from requesting devices or systems. In one or more instances, the cloud computing system utilizes local resources to process user requests. In some instances, the cloud computing system relies on remote systems to process user requests.

[0002] Despite these and other advances, existing computing systems for processing user requests face several technical shortcomings that result in inefficient and inflexible computing operations, particularly in the area of ​​canceling outstanding user requests (e.g., user requests that have been made but not yet completed). Specifically, existing computer systems typically employ complex cancellation processes when receiving a cancellation to cancel an outstanding user request. For example, some computer systems need to first look up whether the pending user request is being processed locally or remotely. In many instances, the lookup process requires the existing computer system to store additional tracking information for each user request.

[0003] If local resources are being used to process user requests, many existing computer systems wait for the user request to complete processing first. In some instances, some existing computer systems attempt to locate and track canceled user requests that are being processed locally, which consumes additional computing resources. In other cases, some existing computer systems prevent all newly submitted requests from being processed until all outstanding requests are completed first, rather than attempting to track canceled user requests, which creates a backlog of incoming user requests.

[0004] For the user request that has been forwarded to the remote computing device for processing, the existing computer system can chase the user request or wait for the remote device to return the request result.In one case, the remote computing device may have forwarded the user request to other equipment, in which case, the existing computer system cannot identify the current position of the user request to indicate cancellation, or the existing computer system must navigate through complicated maze equipment to identify the remote computing device that is processing the user request.In other cases, the remote computing device may be delayed, time out or even go offline.In these cases, the existing computer system is usually inefficient and inflexibly keeps the result that needs to be returned to complete the local resources of the processing of the user request, and the existing computer system is not given the indication of the remote device about when to return the result, which causes the local resources to be locked, unavailable and wasteful.In some instances, the results of these returns may not arrive or do not arrive at all in a reasonable time frame.

[0005] These problems are compounded by inefficiencies and inflexibility as the number of canceled requests increases. For example, in some cases, the requesting device is a virtual machine that is shut down. In doing so, the virtual machine may cancel thousands to millions of user requests, each of which is at a different stage in the request processing flow (and chasing each of these requests is mind-boggling and inefficient).

[0006] Some existing computer systems use software solutions to make user-requested cancellation possible. However, this requires the software to synchronize itself at multiple checkpoints and maintain multiple locking mechanisms. As with the example above, these systems are inefficient, inflexible, and often require the system to wait for remote results that may not arrive.

[0007] These and other problems result in significant inefficiencies, inaccuracies, and inflexibility in existing systems for canceling currently pending user requests in the request processing flow. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The detailed description provides one or more implementations with additional specificity and detail through the use of the accompanying drawings, as briefly described below.

[0009] Figure 1A to Figure 1B A diagram of a computing system environment is shown for implementing a processing engine system in accordance with one or more implementations.

[0010] Figure 2 An exemplary overview of a processing engine system for implementing asynchronous cancellation of service requests is shown in accordance with one or more implementations.

[0011] FIG. 3A to FIG. 3B A block diagram of a processing engine system that utilizes local processing resources and remote processing resources to process service requests according to one or more implementations is shown.

[0012] Figure 4 A sequence diagram illustrating an asynchronous cancellation of a service request according to one or more implementations is shown.

[0013] Figure 5 A block diagram is shown for performing request validation checks on processing requests according to one or more implementations.

[0014] Figure 6 A block diagram is shown for clearing local processing resources in response to a cancel request according to one or more implementations.

[0015] Figure 7 An exemplary series of actions for persisting monitored and processed event data to persistent storage is illustrated in accordance with one or more implementations.

[0016] Figure 8Example components included within a computer system are shown. DETAILED DESCRIPTION

[0017] Implementations of the present disclosure utilize a processing engine system to efficiently and flexibly asynchronously cancel unfinished service requests in a computing system such as a cloud computing system, a non-transitory computer-readable medium, a method, and / or a device to provide benefits and / or solve one or more of the aforementioned or other problems in the art. For example, in various implementations, the processing engine system facilitates the asynchronous cancellation of requests by utilizing sequence numbers to verify requests at different stages of the request processing flow. In particular, after effectively performing a local cancellation operation, the processing engine system ensures that resources associated with the canceled request are deallocated and free to process other requests. In fact, the processing engine system is able to provide this guarantee of no processing resources, and there is no need to contact or wait for remote resources to return unfinished processing requests.

[0018] Specifically, in one or more implementations, the processing engine system processes a service request from a requesting device (or system), which may include converting the service request into one or more processing requests. As part of generating the processing request, the processing engine system creates a context entry in a request context table, which includes a sequence number of the processing request and other information.

[0019] After receiving the service request, in various implementations, the processing engine system identifies a cancellation indication to cancel the service request. In response, the processing engine system asynchronously cancels the service request by modifying a sequence number in a context entry to indicate that the context entry is now invalid. Additionally, the processing engine system performs request validation checks at various stages of the request processing flow to discard the canceled request and prevent it from accessing local processing resources.

[0020] In addition, in some implementations, the processing engine system provides a processing request completion indicator (and / or clears the monitor) to the local processing resource to verify that any processing requests associated with the service request that arrived at the local processing resource before the processing request completion indicator was completed are complete. Thereafter, in various implementations, the processing engine system confirms the cancellation of the service request to the requestor by indicating that the processing request associated with the cancelled service request can no longer access any local processing resources.

[0021] As described herein, the processing engine system provides several technical advantages in terms of computational efficiency, accuracy, and flexibility compared to existing computing systems. In fact, the processing engine system provides several practical applications that provide advantages and / or solve problems associated with real-time edge device metric monitoring and reporting.

[0022] In detail, in various implementations, the processing engine system improves efficiency by quickly and asynchronously canceling pending or unfinished service requests, regardless of where the request is currently being processed in the request processing flow, even for processing requests that reside on one or more remote processing resources. In fact, the processing engine system efficiently and flexibly cancels requests without having to track the current location of the processing request. Instead, the processing engine system performs a local cancel operation that prevents the processing engine system from processing the canceled request while allowing uncancelled requests to be processed without delay.

[0023] Furthermore, in various implementations, unlike a computer system that occupies the presence of local resources waiting for a remote request to be returned (which may be an infinite amount of time), the processing engine system asynchronously cancels the request by updating a request context table to mark the request as invalid and clearing the local processing job that the processing engine system quickly executes. In particular, the processing engine system effectively and flexibly facilitates the immediate release of local resources when processing a cancellation request, rather than having to lock local resources for an indefinite period of time. In fact, the processing engine system ensures that after the processing engine system confirms the cancellation operation, the resources associated with the canceled request are deallocated and can no longer be accessed by the canceled request. In this way, the processing engine system ensures that local processing resources can be immediately used for other pending requests.

[0024] In addition, the processing engine system does not waste local processing resources to process requests that are later ignored or discarded. For example, in various implementations, the processing engine system utilizes a validation check before processing the request locally to ensure that the canceled request is not processed. In multiple implementations, the processing engine system utilizes a validation check to discard the canceled request before the canceled request advances to the next processing stage of the request processing flow. For example, the validation check includes utilizing a sequence number in a request context table to effectively determine whether the request is valid (e.g., a current sequence number) or invalid (e.g., an outdated sequence number). Additionally, because the request is quickly canceled at the local level, the processing engine system releases entries in the request context table more quickly, which alleviates the problem of overwriting active entries (because the request context table is typically a fixed size with a limited number of request context entries).

[0025] In addition, the processing engine system can flexibly expand to any number of cancellation requests. In fact, unlike existing computer systems that increasingly struggle with the increase in the number of cancellation requests, the processing engine system effectively handles any number of cancellation requests because cancellation is completed locally and asynchronously.

[0026] In addition, the processing engine system can be operated as a hardware or software solution. For example, the processing engine system is implemented on a processing engine that performs one or more implementations described herein. In some implementations, the processing engine system is a software-based action set. In various implementations, the processing engine system utilizes hardware and software components to perform various implementations disclosed herein.

[0027] As explained in the above discussion, the present disclosure utilizes a variety of terms to describe the features and advantages of one or more implementations described herein. For example, as used herein, the operation of a processing engine system utilizes one or more processing engines. Therefore, the term "processing engine" refers to a device, hardware, and / or system that receives and processes incoming requests (e.g., services or user requests). For example, a processing engine is responsible for processing data that is typically retrieved from a storage device based on predefined logic in order to produce a result. In multiple implementations, a processing engine system includes one or more processing engines. Therefore, as used herein, the terms processing engine and processing engine system are generally interchangeable.

[0028] In various implementations, the processing engine is implemented in hardware, such as a hardware pipeline, a hardware accelerator, a finite state machine (FSM), or a processor. In various implementations, the processing engine includes a memory having a request context table and local processing resources. In some implementations, the processing engine is implemented in software or a combination of hardware and software. In many implementations, a computing device such as a server device, a host device, or other types of computing devices within a cloud computing system includes one or more processing engines.

[0029] As used herein, the term "service request" or "user request" refers to a request by a requesting device or system ("requester") for a processing engine and / or a processing engine system to process a request. For example, a requester sends a disk IO request to a processing engine. In one or more implementations, the service request is sent from the same computing device as the processing engine (e.g., a virtual machine on a host device sends a service request to a processing engine on the host device). In some implementations, the requester is on a computing device separate from the processing engine (e.g., the requester is on a client device).

[0030] As used herein, the term "processing request" refers to a request generated and tracked by a processing engine and / or a processing engine system. For example, upon receiving a service request, the processing engine converts the service request into one or more processing requests required to satisfy the service request. Then, the processing engine tracks the pending or unfinished processing request in the request context table. For some implementations, the processing request is bound, aliased, linked and / or otherwise associated with the service request. In some implementations, the processing request is processed locally by the processing engine. In various implementations, the processing engine system sends a processing request to other computing devices such as remote processing resources or remote services (e.g., remote backend storage servers) and receives a response therefrom.

[0031] As used herein, the term "uncompleted processing request" refers to a processing request that has been started but has not yet completed processing at a processing resource; the term "pending processing request" refers to a generated processing request that is waiting to be processed; and the term "active request" refers to pending and uncompleted requests. For illustration, pending requests include processing requests that have been generated from a service request but have not yet begun processing or processing requests that are waiting for additional processing (e.g., advancing to the next stage of the request processing flow). For example, a processing request is processed at a remote processing resource. When a processing result is returned to the processing request, the processing engine system needs to further process the result at the local processing resource (e.g., for bookkeeping purposes).

[0032] As used herein, the term "request context table" refers to a requested data structure that tracks processing requests that are currently being processed and / or processing requests that are waiting to be processed. In many implementations, the request context table resides in a processing engine. In some implementations, the request context table is located elsewhere, such as on a device that is the same or different from the corresponding processing engine. In various implementations, the request context table includes context entries indicating the request context of the processing request. Additionally, in several implementations, each context entry includes a context identifier, a sequence number, and service information.

[0033] As used herein, the term "context identifier" refers to an identifier of a processing request in a request context table. In various implementations, a context identifier (i.e., a request context identifier) ​​is used as a table index (or keyword) to identify a processing request in a request context table. For example, a context identifier ("CID") indicates a physical location on a request context table. Typically, a request context table includes a fixed number of context identifiers that are reused over time.

[0034] As used herein, the term "sequence number" refers to a unique or mostly unique identifier assigned to a processing request. In various implementations, the sequence number identifies the processing request of the current processing request. In one or more implementations, the processing engine system generates a sequence number for the processing request. In many implementations, the sequence number is unique for a reasonable time period so that the processing request does not repeat with the current or processed request generated in the foreseeable future (e.g., the sequence number can repeat after a predetermined amount of time). Additionally, in many implementations, the processing engine system utilizes the sequence number to verify or invalidate the processing request.

[0035] As used herein, the term "service information" or "request service information" refers to information and / or instructions in a request context table used to service a processing request. In various implementations, the service information is based on the request type. For example, for a disk read service request, the service information corresponding to the processing request includes which disk to read, the logical block address to access, and / or the number of blocks to read. In various implementations, the service information for the processing request is updated as part of the normal processing flow of the request. For example, the service information for the processing request includes information about completed and still uncompleted sub-portions of sub-portions of the processing request (e.g., and / or for determining when the associated service request is completed).

[0036] As described above, the processing engine system can process processing requests locally or send them to remote processing. In various implementations, the processing engine system attaches a token to the processing request being processed by the processing resource. As used herein, the term "token" or "request token" refers to identification information attached to the processing request being processed. In various implementations, the token includes a context identifier and a sequence number of the processing request. For example, in order to process a request sent to a remote computing device by the processing engine system, the token is attached to the processing request and / or travels with the processing request when being processed, and is also returned with the processing result. In this way, the processing engine system can match the incoming processing result with the outgoing processing request. In one or more implementations, the processing engine system also utilizes the token of the processing request on the local processing resource.

[0037] As used herein, the terms "request cancellation indication," "cancellation request," "service request cancellation," and "processing request cancellation" refer to an indication for canceling or terminating a previous or pending service request. In various implementations, the processing engine system handles the cancellation request by pausing or stopping the processing and handling of the service request (or associated processing request). In some implementations, the processing engine system responds to the cancellation request by deallocating resources being used to service the request and / or indicating that the request no longer accesses resources previously used to process the request. In some implementations, the processing engine system provides a list of outstanding service requests that were canceled (e.g., to the requestor). Additional information about the cancellation request is provided below. In an example implementation, the addition of the term "asynchronously" indicates that the processing engine system cancels the request locally at the processing engine and does not need to wait for confirmation or a response from another device.

[0038] As used herein, a "cloud computing system" refers to a network of connected computing devices that provide various services to computing devices (e.g., client devices, server devices, provider devices, customer devices, etc.). For example, as described above, a distributed computing system may include a collection of physical server devices (e.g., server nodes) organized in a hierarchical structure including clusters, computing regions, virtual local area networks (VLANs), racks, fault domains, etc. In various implementations, the network is a virtual network or a network with a combination of virtual and real components. Typically, cloud computing systems utilize computing devices including parity-based SSD solutions to facilitate cloud storage, virtual machines, and / or other services.

[0039] Additional details will now be provided regarding the components and elements of the processing engine system (i.e., the processing engine system). For example, Figure 1A to Figure 1B 1 shows a schematic diagram of an environment 100 for implementing a processing engine system 104. Specifically, Figure 1A Including environment 100, Figure 1B Additional details regarding components and elements of the processing engine system 104 are provided.

[0040] like Figure 1A As shown, environment 100 includes server device 102, server device 102 includes processing engine system 104, cloud computing system 110 with cloud processing resources 112, and client device 114 with client application 116 each connected via network 118. As shown, processing engine system 104 includes request context table 106 and local processing resources 108. Figure 8 Additional details about these and other computing devices are provided. Figure 8 Additional details regarding networks, such as network 118 as shown, are also provided.

[0041] As described above, environment 100 includes server device 102. Server device 102 may include one computing device, or may be distributed across multiple computing devices. In some implementations, server device 102 is part of cloud computing system 110, as shown by the dashed line.

[0042] As shown, the server device 102 includes a processing engine system 104, which in some cases represents a processing engine. In one or more implementations, the processing engine system 104 facilitates receiving, processing, and returning service requests to requesters. In some implementations, the requesters are located on the server device 102 and / or within the cloud computing system 110. In an example implementation, the server device 102 includes multiple processing engines.

[0043] As described above, the processing engine system 104 includes a request context table 106 and a local processing resource 108. In various implementations, the processing engine system 104 utilizes the request context table 106 to track and monitor outstanding requests. In some implementations, the processing engine system 104 utilizes the local processing resource 108 to process service requests (i.e., process requests associated with the service requests). As used herein, the term "local processing resource" includes a hardware or software component for locally processing one or more processing requests. In various implementations, the local processing resource 108 includes a hardware processing pipeline. Additional details about the processing engine system 104 are provided in the following figures. For example, the following in conjunction with Figure 1B Details and components of the processing engine system 104 are also provided.

[0044] As shown, the environment 100 includes a cloud computing system 110 having a cloud processing resource 112. In one or more implementations, the processing engine system 104 sends a processing request to the cloud processing resource 112 on the cloud computing system 110 to remotely process one or more processing requests associated with a service request. In multiple implementations, the cloud processing resource 112 represents a remote processing resource. As used herein, a "remote processing resource" refers to a processing resource that is located separately from a processing engine on the processing engine system 104. For example, the processing engine system 104 sends a processing request to a remote machine to be processed by a remote processing resource.

[0045] In various implementations, the cloud computing system 110 includes additional computing devices not shown. In some implementations, the cloud processing resources 112 utilize one or more computing devices including storage devices to process requests sent by the processing engine system 104. For example, cloud processing employs computing devices, systems, and / or functional chains to generate request results for received processing requests.

[0046] As shown, the environment 100 includes a client device 114 having a client application 116. In various implementations, the client device 114 is a user client device or an administrator client device that provides service requests to the processing engine system 104. In some implementations, the processing engine system 104 provides an interactive graphical user interface for making requests and / or implementing policies for making service requests to the processing engine system 104 (e.g., the client device 114 is the requestor). In various implementations, the client application 116 is provided by and / or communicates with the processing engine system 104 to facilitate device and user interaction with the processing engine system 104.

[0047] As mentioned above, Figure 1B Additional details are provided regarding the capabilities and components of the processing engine system 104. As shown, the computing device 101 includes the processing engine system 104. As shown, the processing engine system 104 includes various components and elements implemented in hardware and / or software. For illustration, Figure 1B Processing engine system 104 is shown with request manager 120, authentication manager 122, cleanup manager 124, request context table 106, and local processing resources 108. Request context table 106 includes content identifier 126, sequence number 128, and service information 130, also as shown.

[0048] As shown, the processing engine system 104 includes a request manager 120. In one or more implementations, the request manager 120 receives, accesses, collects, identifies, transforms, modifies, provides, groups, tags, or otherwise manages service requests from requestors (e.g., requesting devices or systems). For example, the request manager 120 receives an incoming service request, generates one or more associated processing requests using logic-based heuristics, and adds the one or more processing requests to the request context table 106. In some implementations, the request manager 120 ensures that the processing requests added to the request context table 106 are given a content identifier 126, a sequence number 128, and service information 130. The request manager 120 can then track the processing requests based on their context in the request context table 106.

[0049] In various implementations, the request manager 120 also facilitates receiving a cancellation indication from a provider or otherwise identifying a cancellation indication. For example, the request manager 120 receives a cancellation request for a pending or uncompleted service request. In another example, the request manager 120 determines that a requestor device, such as a virtual machine, has gone offline and all outstanding service requests from the requestor device should be canceled. In response to detecting one or more cancellation indications, in one or more implementations, the request manager 120 modifies the sequence number 128 of one or more processing requests associated with the one or more service requests in the request context table 106.

[0050] Additionally, in one or more implementations, the processing engine system 104 includes a verification manager 122. In various implementations, the verification manager 122 facilitates verification of processing requests. For example, the verification manager 122 utilizes a verification check to determine whether pending processing requests can be processed, whether unfinished processing requests can continue to be processed, or whether they should be discarded and thrown away. In some cases, the verification manager 122 performs a verification check before processing a request processed by the local processing resource 108. For example, in one or more implementations, the verification manager 122 verifies that pending or unfinished processing requests have a valid sequence number that matches the corresponding sequence number in the request context table 106 of the same request context. As a result, any local or remote processing results that need to be further processed will need to pass the verification check before proceeding. Otherwise, if canceled, the verification manager 122 discards invalid, canceled requests without further wasted processing.

[0051] As shown, the processing engine system 104 includes a purge manager 124. In various implementations, the purge manager 124 ensures that the local processing resources 108 have no outstanding processing requests. For example, in one or more implementations, the purge manager 124 sends a purge monitor (i.e., a processing request completion indicator) to the local processing resources 108 to flush, drain, or otherwise purge the local processing resources 108 (and / or additional local processing resources) to ensure that all outstanding processing requests have been cleared of the local processing resources. In this manner, the processing engine system 104 ensures that any canceled outstanding service requests no longer access local resources.

[0052] In addition, as shown, the processing engine system 104 includes a request context table 106. As described above, in multiple implementations, the request context table is a table or other data structure of fixed size that stores the request context for processing requests. Because the request context table 106 is usually fixed in size, the content identifier 126 is usually recycled. Therefore, it may not be enough to cancel the processing request by removing the processing request from the request context table 106, because the same content identifier can be quickly added back to the table and used by another processing request. Therefore, when determining the validity of the request based on the existence of a specific content identifier in the request context table 106, a false positive result will be triggered occasionally. However, if the requested context table 106 is too large and it cannot be ruled out that the content identifier is reused too frequently, the processing engine system 104 wastes valuable storage space due to unnecessary hosting of a large number of sparse tables.

[0053] As shown, the processing engine system 104 includes local processing resources 108. In various implementations, the local processing resources 108 are on-chip processing pipelines and / or finite state machines. In an example implementation, the local processing resources 108 are virtualized processing pipeline resources. In one or more implementations, the local processing resources 108 provide a request processing flow for processing one or more processing requests. Some implementations include processing requests that are sent to remote processing resources for return, and their results are run through the local processing resources 108 (e.g., processing pipeline resources) before signaling to the requesting device that the service request has been completed.

[0054] Combination Figure 2 Additional details regarding an example implementation of the processing engine system 104 are discussed. For example, Figure 2 An exemplary overview of a processing engine system for implementing asynchronous cancellation of service requests according to one or more implementations is shown. As shown, Figure 2 A series of actions 200 performed by the processing engine system 104 is shown.

[0055] Specifically, Figure 2 The series of actions 200 in the example include an action 202 of tracking received service requests using a request context table. For example, in various implementations, the processing engine system 104 receives a service request from a requestor. In response, the processing engine system 104 generates one or more processing requests and provides the processing requests to local processing resources and / or remote processing resources. Additionally, in various implementations, the processing engine system 104 adds the processing requests to a request context table to track the general status and / or location of pending and unfinished processing requests. For example, the processing engine system 104 adds a request context for processing the request to the request context table along with a context identifier, a sequence number, service information, and / or other information. Figure 3A , Figure 3B and Figure 4 Provides additional details about monitoring the processing request associated with the service request.

[0056] also, Figure 2 The series of actions 200 is shown to include an action 204 of modifying the sequence number of the processing request in the request context table in response to receiving a request to cancel the service request. For example, the processing engine system 104 identifies a cancellation indication regarding the active service request. In response, the processing engine system 104 identifies one or more processing requests associated with the service request in the request context table. In addition, the processing engine system 104 asynchronously cancels the request by locally modifying the sequence number of each identified processing request in the request context table. Figure 4 Provides additional details about receiving and responding to cancellation instructions.

[0057] As shown, the series of actions 200 includes an action 206 of adding a local validation check that validates the request returned from the remote resource and the outstanding local request. For example, in one or more implementations, the processing engine system 104 generates a validation check attached to the local processing resources, such as a master validation check or a validation check before each local processing resource, to validate all pending processing requests. Once in place, the pending processing request needs to satisfy the validation check before advancing to the local processing resource for processing and completion. As described above, in many implementations, the processing engine system 104 utilizes a sequence number comparison and match to verify that the pending processing request is valid. Figure 4 and Figure 5 Provide additional details about the validation check.

[0058] also, Figure 2 The series of actions 200 is shown to include an action 208 of clearing currently processed local outstanding processing requests. For example, in various implementations, the processing engine system 104 generates a clear monitor (i.e., a processing request completion indicator) and provides it to one or more local processing resources to ensure that any processing requests that were not completed when the cancellation indication was received are completed. In this way, the processing engine system 104 ensures that all outstanding processing requests are completed without having to determine whether one or more outstanding requests correspond to the cancellation indication, and thus frees any resources used by the canceled processing request. Additionally, the processing engine system 104 ensures that pending processing requests can utilize local processing resources as long as they are followed by a clear monitor. In conjunction with Figure 4 and Figure 6 Provides additional details on using the purge monitor.

[0059] Also as shown, the series of actions 200 includes an action 210 of providing an indication of confirming the cancellation of the service request. For example, in various implementations, the processing engine system 104 receives a confirmation that the verification check is in place and that the clear monitor has completed flushing or draining the local processing resources. In response, in various implementations, the processing engine system 104 provides an indication to the requesting device that ensures that the resources associated with the canceled request are deallocated and can be used to process other requests. Additionally, the processing engine system 104 provides this resource-free guarantee or assurance without waiting for the remote resources to return, because any canceled processing request returned from the remote device will be discarded after quickly identifying that it has been canceled.

[0060] As mentioned above, FIG. 3A to FIG. 3B Provides more details for monitoring the processing request associated with the service request. For example, FIG. 3A to FIG. 3B A block diagram is shown in combination with an action set for a processing engine system to utilize local and remote processing resources to process a service request according to one or more implementations. Specifically, Figure 3A shows the use of local processing resources to complete processing requests, while Figure 3B The use of both remote processing resources and local processing resources to complete a processing request is shown. FIG. 3A to FIG. 3B The background provided in Figures 4 to 6 Provides additional details about canceling an activity request.

[0061] As shown, Figure 3A and 3B Both include the cloud computing system 110 described above. Specifically, the cloud computing system 110 includes a host device 302, which can represent the server device 102 described above. In addition, as shown, the host device 302 includes a processing engine system 104 and a virtual machine 314. Although not shown for simplicity, the host device 302 may include multiple virtual machines. In addition, each virtual machine may include components, such as processors, instructions, memory, etc. In addition, the host device 302 may include other components, such as hypervisors, processors, memories, storage devices, peripheral devices, etc.

[0062] Additionally, Figure 3A and Figure 3B The processing engine system 104 in both includes a request processing logic engine 304, a request context table 106, and a local processing resource 108. In some implementations, the request processing logic engine 304 represents the above combined Figure 1B1. The request context table 106 and the local processing resources 108 may correspond to similar components previously described. For example, the request context table 106 includes a request context for each processing request, including, among other possible items, a context identifier 308, a sequence number 310, and service information 312.

[0063] Steering Figure 3A As shown, the figure illustrates local request processing 300 of a service request. For illustration, a virtual machine 314 running on the cloud computing system 110 performs various services for a user (e.g., the virtual machine 314 provides web or data analytics for an entity). As part of its functionality, the virtual machine 314 (i.e., the requestor) issues a service request to the processing engine system 104, as shown in action 1A 320. For example, the virtual machine 314 sends a disk I / O (input / output) request to the processing engine. For example, the virtual machine 314 has a local storage device, wherein the disk I / O of the virtual machine is serviced by the host device 302 using a block storage abstraction.

[0064] As shown, the processing engine system 104 receives the service request and begins processing the service request using the request processing logic engine 304. For example, the request processing logic engine 304 generates one or more processing requests from the service request. In conjunction with generating the processing request associated with the service request, the request processing logic engine 304 can generate a request context within the request context table 106, as shown in action 1B 322. As shown, the generated request context for the processing request includes a context identifier 308, a sequence number 310, and service information 312.

[0065] In various implementations, the request processing logic engine 304 selects an available context identifier 308. In one or more implementations, the request context table 106 includes context identifiers that are fixed and correspond to entry numbers, keys, or indexes in the request context table 106.

[0066] Additionally, the request processing logic engine 304 can generate a unique sequence number for the processing request. As described above, the sequence number uniquely identifies the processing request. In some implementations, the processing engine system 104 generates a sequence number that remains unique for a time frame corresponding to the processing or reference processing request (e.g., for a reasonable processing time window). In practice, a processing request should not be assigned to a sequence number that is used or becomes available within a threshold time period (e.g., one day, several days, or a week after becoming available).

[0067] In various implementations, the time frame includes abnormal situations, such as when a processing request takes an extended time to complete processing. For example, the processing engine system 104 utilizes 48-bit or 64-bit values ​​to store sequence numbers, which provides a time frame of several months before a sequence number is repeated. However, given the above factors, in an example implementation, the processing engine system 104 keeps the sequence number size as small as possible to maximize storage efficiency. Specifically, the size of the sequence number is increased or decreased based on the type of application or request processing flow used.

[0068] As shown, upon generating the request context, the processing engine system 104 performs action 1C 324 of the local processing request. Additionally, the local processing resource 108 completes the processing request, as shown in action 1D 326. For example, the processing engine system 104 sends the processing request to the local processing resource 108 to perform disk I / O reads and / or writes at the local storage disk. In various implementations, the local processing resource 108 processing the processing request is referred to as a short latency operation because the time to complete the request is short.

[0069] In some but not all implementations, the processing engine system 104 pairs a request token with the processing request sent to the local processing resource 108. For example, the request token includes a context identifier and a sequence number assigned to the processing request. In this way, the processing engine system 104 monitors active processing requests (e.g., outstanding and pending requests) and correctly identifies them when they return. In an alternative implementation, the processing engine system 104 does not send a token when utilizing the local processing resource 108 to process a request.

[0070] As shown, the processing engine system 104 performs an action 1E 328 of returning a processed request (e.g., a processed result). For example, upon receiving a processing request from a local processing resource 108, the processing engine system 104 uses the context identifier and sequence number in the request token to match the processing result with the processing request and / or the service request (e.g., via the request context table 106). When multiple processing requests are generated for a service request, the processing engine system 104 waits for some or all of the processing requests to be returned. In addition, the processing engine system 104 returns the result of the service request (e.g., (multiple) processed requests) to the virtual machine 314 (i.e., the requestor). In an alternative implementation, the processing engine system 104 indicates to the virtual machine 314 that the service request has been completed (e.g., the data has been successfully written to the storage disk).

[0071] Although Figure 3A Corresponds to local processing requests, but Figure 3B The concept is extended to exploit remote processing resources. To illustrate, Figure 3B The remote request processing 330 of the service request is shown. Figure 3AIn addition to the components in Figure 3B The cloud computing system 110 in FIG. 1 adds cloud processing resources 112 , which are also introduced above.

[0072] As shown, the processing engine system 104 performs an action 2A 332 of receiving a service request from the virtual machine 314. As previously described, the service request may be a disk I / O request. However, in this case, the virtual machine 314 has an attached virtual disk (i.e., storage device), where the I / O operations to the virtual disk are serviced by the host device 302. In this case, to process the service request, the processing engine system 104 sends one or more processing requests to a remote storage device on a backend server (e.g., on the cloud processing resource 112).

[0073] To illustrate, the processing engine system 104 performs action 2B 334 of the processing engine system 104 to generate a request context for one or more processing requests. As previously described, the request processing logic engine 304 of the processing engine system 104 utilizes logic-based heuristics to generate one or more processing requests that directly correspond to the service request. Then, as part of generating the processing request, the request processing logic engine 304 generates a request context in the request context table 106 for the generated processing request.

[0074] As shown in action 2C 336, the processing engine system 104 sends one or more remote processing requests to the cloud processing resource 112 (e.g., a remote processing resource). For example, the processing engine system 104 sends the processing request with the accompanying token 316 to the cloud processing resource 112 to be processed remotely. In some implementations, the processing engine system 104 sends the processing request to different or multiple remote processing resources. In the example implementation, the remote processing resource that processes the processing request is referred to as a long latency operation because the time to complete the request is longer than a short latency operation, is generally unknown, and is sometimes uncertain.

[0075] In various implementations, the cloud processing resource 112 completes the processing request and provides the remote processing results back to the processing engine system 104, as shown in action 2D 338. As shown, the processing engine system 104 receives the processed request and a corresponding token including a content identifier and a sequence number associated with the processing request. In fact, the token 316 propagates with the process request from its creation to its completion. In this way, the processing engine system 104 can accurately track the processing request as it is sent and received back from the remote processing resource.

[0076] About remote processing resources, in some implementations, cloud processing resources 112 utilize multiple components, devices or functions to complete processing requests. As mentioned above, in many cases, when sending processing requests to cloud processing resources 112 for processing, processing engine system 104 does not know and / or cannot track the remote progress of processing requests. In addition, processing requests can be divided into multiple instances unknown to processing engine system 104. Therefore, it is infeasible to attempt to track the processing requests sent to remote processing resources in most cases. On the contrary, processing engine system 104 must wait for the remote processing resource to return the completed request.

[0077] Once the processing result is received, the processing engine system 104 performs local processing of the processing request after receiving the processing result, as shown in action 2E 340. For example, the processing engine system 104 sends the processing result through the processing pipeline to locally record and / or complete the processing of the processing request. For example, in some examples, the processing pipeline removes the request context of the processing request from the request context table 106 to signal the completion of the processing request.

[0078] Additionally, the processing engine system 104 performs action 2F 342 of returning the processed request to the virtual machine 314 (ie, the requestor). For example, the processing engine system 104 provides information in response to the service request and / or an indication that the service request has been completed.

[0079] Although Figure 3A and Figure 3B The processing engine system 104 is described and shown as processing service requests, but in many implementations, Figures 4 to 6 Additional details are provided about asynchronously canceling an active request. To elaborate, an active service request may be canceled for several reasons. For example, reasons for request cancellation include a timeout of the service request or processing request, a disconnection of the network connection over which the request was sent (and over which the response result is expected to be received), a hardware or software update (e.g., an operating system, a software driver, or firmware running on a processing engine needs to be serviced / upgraded), the requestor device providing the request being terminated (e.g., a session terminated), a necessary disk being unloaded, or being shut down (e.g., a virtual machine sending the service request is shut down).

[0080] Regardless of the reason for cancellation, when the processing engine system 104 identifies a cancellation indication for a service request, the processing engine system 104 can quickly and efficiently stop the request from the extended processing and released local processing resources used by the canceled request, even for outstanding processing requests issued to remote processing resources whose completion status and timing are unknown. In fact, the processing engine system 104 facilitates asynchronous (e.g., local) cancellation of any number of outstanding requests, and regardless of where they are currently being processed or what processing stage they are in the request processing flow.

[0081] To further illustrate, Figure 4 A sequence diagram of an asynchronous cancellation service request according to one or more implementations is shown. As shown, Figure 4 Includes virtual machine 314, processing engine system 104 and cloud processing resources 112, each of which is introduced above. Specifically, Figure 4 A series of actions 400 are included regarding the processing engine system 104 processing a request and interacting with the virtual machine 314 (eg, the requestor) and the cloud processing resources 112 (eg, the remote processing resources).

[0082] As shown, series of acts 400 includes act 402 of issuing a processing request by processing engine system 104. For example, processing engine system 104 receives a service request from virtual machine 314, generates a processing request associated with the service request, and sends the processing request to cloud processing resource 112 for remote processing, as described above.

[0083] As shown, the series of acts 400 includes an act 404 of receiving a request cancellation from the virtual machine 314. For example, the requestor device sends a cancellation request for a currently active service request to the processing engine system 104. In various implementations, the processing engine system 104 automatically detects a cancellation indication, such as from a network disconnect or when the requestor device stops responding.

[0084] In various implementations, the processing engine system 104 receives criteria for canceling the request. For example, the requester provides an indication to cancel all requests made on behalf of a particular virtual machine. In another example, the requester indicates to cancel all requests sent before a particular timestamp. In some instances, the cancel request indicates to cancel all service requests of a given type (e.g., disk I / O reads). Based on the criteria indicated in the cancel request, the processing engine system 104 finds each service request to be canceled and the corresponding processing request.

[0085] Upon receiving the cancel request, the processing engine system 104 begins a process of asynchronously canceling the service request. In one or more implementations, the processing engine system 104 identifies each processing request associated with the service request. Specifically, in various implementations, the processing engine system 104 locates the request context corresponding to the processing request in the request context table. Additionally, in various implementations, for each processing request, the processing engine system 104 updates the sequence number of the request (i.e., the request context) in the request context table, as shown in action 406 in the series of actions 400.

[0086] The processing engine system 104 can update the sequence number of the processing request in various ways. In one or more implementations, the processing engine system 104 increments the sequence number to a new unique number. In some implementations, the processing engine system 104 changes the most significant bit of the sequence number. In an example implementation, the processing engine system 104 changes the sequence number to a number or range of numbers corresponding to the canceled request (e.g., sequence number 0 or range 1 to 10 for canceled requests).

[0087] In various implementations, changing the sequence number of the processing request in the request context table initiates the process of canceling the processing request. For example, in one or more implementations, by changing the sequence number, the processing engine system 104 invalidates the context; that is, the processing engine system 104 invalidates and / or deallocates the request context of the processing request. In some implementations, modifying the sequence number of the processing request allows the context entry in the request context table to be overwritten by the incoming processing request. In various implementations, the processing engine system 104 utilizes additionally or alternatively methods to provide a request context (e.g., context entry) in the request context table that is invalid for the canceled request.

[0088] As part of canceling the request, the processing engine system 104 can ensure that only processing requests with valid sequence numbers can continue to be processed at each stage of the request processing flow. Specifically, because the processing engine system 104 has control over the processing that occurs at the cloud processing resources 112, in various implementations, the processing engine system 104 verifies the sequence number of each request before performing local processing, as shown in action 408 in the series of actions 400. In this way, pending processing requests that need to be processed locally must first be verified or they will be discarded. Figure 5 Provides additional details about the sequence number of the authentication processing request.

[0089] As shown, the series of actions 400 includes an action 410 in which the processing engine system 104 clears the local processing resources for processing requests. For example, once a cancellation request is received, the outstanding requests processed locally must be completed to ensure that there are no canceled requests in the request processing flow. In various implementations, the processing engine system 104 uses a clear monitor to drain or clear the outstanding processing requests. Figure 6 Provides additional details about clearing outstanding processing requests.

[0090] Additionally, the series of actions 400 includes an action 412 in which the processing engine system 104 indicates to the virtual machine 314 (e.g., the requestor) a guarantee of local resource availability. Specifically, once a sequence number verification check has been established to prevent the canceled request from using local processing resources coupled to local processes in the resources of the canceled request, the processing engine system 104 can guarantee to the requestor that any resources associated with the canceled request are now available for use by other processing requests. In fact, the processing engine system 104 can guarantee that it will no longer access any resources associated with the canceled request, and that all resources used to cancel the request have been deallocated. In multiple instances, once the local resource becomes available, the processing engine system 104 will effectively use it, which may occur before providing a guarantee indication to the requestor.

[0091] In contrast to existing computer systems that typically require the processing engine to wait for all pending and uncompleted processing requests to be returned from remote sources to complete the cancellation of a service request, the processing engine system 104 described herein can asynchronously execute processing requests in an instant. More specifically, in multiple implementations, the processing engine system 104 only needs to perform local actions to cancel the request, and the time to complete the cancellation operation is approximately the sum of the time required to update the corresponding sequence number in the request context table plus the time to clean up the local processing resources utilized by the processing engine system 104 (or less if performed in parallel). As described above, although the time taken to clean up the local processing resources depends on the number of outstanding processing requests, these requests are cleaned up in a short time frame.

[0092] In addition, the processing engine system 104 described herein does not need to wait for the remote source to return the request result to ensure the availability of local processing resources. For illustration, Figure 4 A dashed line 414 is included that represents the passage of time that a remote processing request is processed at a cloud processing resource 112. This passage of time may be short, long, or in some cases infinite.

[0093] As shown, the series of actions 400 includes an action 416 in which the processing engine system 104 receives a processed request from the cloud processing resource 112. For example, the processing engine system 104 receives a processed request from the cloud processing resource 112 at the time elapsed in response to issuing a remote processing request (e.g., action 402). As described above, the processed request includes a request token having a content identifier and a sequence number assigned to the processing request. It is important to note that the sequence number in the token being returned will be the unmodified sequence number originally generated for the processing request. In fact, because the processing request was sent to the cloud processing resource 112 before the processing engine system 104 received the cancellation request, the return token does not have the modified sequence number in the request context table.

[0094] As also shown, the series of actions 400 includes an action 418 in which the processing engine system 104 discards the request based on the invalid sequence number. As further provided below, the processing engine system 104 will use the context identifier in the token to find the request context of the processing request in the request context table, and then identify the sequence number corresponding thereto. Because the context identifier is fixed in the request context table, the processing engine system 104 will identify the request context of the processing request based on the context identifier. However, the request context may correspond to a canceled request context, or to a new processing request that has been rewritten to the request context table using the same context identifier. Therefore, the processing engine system 104 utilizes the sequence number to verify whether the processing request is valid. Because in this case, the processing request has been canceled, the sequence number will not match, and the processing engine system 104 will discard the processing request, as further described below.

[0095] As mentioned above, Figure 5 Additional details are provided regarding validating the serial number of a processing request to identify valid and invalid processing requests. Specifically, Figure 5 A block diagram of performing a request validation check for a processing request according to one or more implementations is shown. As shown, Figure 5 Included is a series of actions 500 performed by the processing engine system 104 .

[0096] As shown, the series of actions 500 includes an action 502 of adding a request validation check to each local processing resource. As described above, the request validation check determines whether the processing request is valid and authorized to continue processing at the local processing resource. In various implementations, if the local processing resource includes multiple processing pipelines, the processing engine system 104 provides a request validation check before each pipeline. In an alternative implementation, the processing engine system 104 utilizes one request validation check for multiple processing pipelines. In some implementations, the processing engine system 104 provides a request validation check to each local processing resource in conjunction with implementing or programming the local processing resource. In other implementations, the processing engine system 104 provides a resource validation check after creating, programming, or encoding the local processing resource.

[0097] As also shown, the series of actions 500 includes an action 504 of receiving an incoming processing request. For example, the processing engine system 104 identifies a pending processing request that needs to be processed at a local processing resource. In some cases, the pending processing request arrives from a remote processing resource and needs to complete local processing. Otherwise in various cases, the pending processing request is waiting for local processing. For example, the pending processing request has just completed the first stage of processing by a local processing resource and is waiting for additional local processing to be completed. As described above, in multiple implementations, the incoming processing request includes a request token with a context identifier and a sequence number of the processing request.

[0098] Additionally, as shown, the series of actions 500 includes an action 506 of identifying a context identifier and a sequence number of a processing request token. For example, the processing engine system 104 parses the processing request to identify the request token. Furthermore, in various implementations, the processing engine system 104 identifies the context identifier and sequence number of the process and the request from the request token. As described above, the request token includes the original, unmodified sequence number of the processing request.

[0099] Figure 5 Also shown is a series of actions 500, including an action 508 of looking up a sequence number in a request context table using the context identifier. In various implementations, the processing engine system 104 uses the context identifier of the processing request identified from the request token to look up a request context for the processing request on the request context table. Once the request context for the processing request is identified, the processing engine system 104 identifies the current sequence number stored in the request context table.

[0100] As shown, the series of actions 500 includes an action 510 of comparing the sequence numbers between the token and the request context table. For example, the processing engine system 104 compares the original sequence number from the token with the current sequence number in the request context table to determine whether they match. If the processing request is not canceled, these sequence numbers will match because the processing engine system 104 will keep the sequence number unchanged as long as the processing request is active (e.g., not canceled or completed). Otherwise, if the processing request is canceled, the processing engine system 104 will replace the sequence number with the modified sequence number. In some cases, the processing engine system 104 will further replace the sequence number by overwriting the request context with a new processing request that shares the same context identifier but has a new unique sequence number.

[0101] To further illustrate, when the sequence numbers match, the series of actions 500 includes an action of locally processing the request 512. For example, the processing engine system 104 determines that the processing request is valid based on its status in the request context table and allows the local processing resource to proceed and complete.

[0102] Otherwise, if the sequence numbers do not match, the series of actions 500 includes discarding the processing request in action 514. In these implementations, the processing engine system 104 cannot validate the incoming processing request. In fact, the processing engine system 104 determines that the processing request has been canceled and is no longer valid. As a result, the processing engine system 104 discards the incoming process and request / result. In addition, the processing engine system 104 does not allow the processing request to access local processing resources, including any resources previously associated with the canceled request, because they are deallocated when the request is asynchronously canceled. In addition, in multiple implementations, the processing engine system 104 prevents access to any additional fields of the processing request before first confirming the validity of the processing request, thereby ensuring that computing resources are not wasted when processing portions of the canceled processing request.

[0103] As mentioned above, Figure 6 Provides additional details about clearing outstanding processing requests. Specifically, Figure 6 A block diagram of clearing local processing resources in response to a cancel request according to one or more implementations is shown. As shown, Figure 6 Included is a series of actions 600 performed by the processing engine system 104 .

[0104] As shown, the series of acts 600 includes an act of receiving a cancellation request 602. As described above, the processing engine system 104 may directly or indirectly detect a cancellation indication for one or more service requests.

[0105] In addition, the series of actions 600 includes an action 604 of generating a purge monitor. For example, in various implementations, the processing engine system 104 generates, selects, accesses, or indicates one or more purge monitors for use. Such as, the processing engine system 104 obtains a purge monitor for each local processing resource that performs a function on the processor engine. In addition, the action 604 can include sending a purge monitor to each local processing resource. In some implementations, the purge monitor is a type of processing request that the local processing resource handles, similar to other processing requests.

[0106] In some cases, the purge monitor includes a processing request completion indicator. In various implementations, the processing engine system 104 provides the processing request completion indicator to each local processing resource when the cancel request is received. In one or more implementations, as part of generating the purge monitor, the processing engine system 104 sets the processing request completion indicator to false or null.

[0107] As shown, the series of actions 600 includes an action 606 of sending a purge monitor by each local processing resource. For example, the processing engine system 104 sends a purge monitor and / or a processing request completion indicator by each local processing resource. In various implementations, the purge monitor follows all unfinished processing requests in the local processing resource and exits when all previous processing requests have completed processing. In some implementations, the processing engine system 104 sets the processing request completion indicator to positive or true when clearing the local processing resource.

[0108] In some cases, the clearing monitor clears, drains and / or pushes unfinished processing requests through local processing resources and / or from local processing resources. For example, if the clearing monitor encounters a canceled processing request while traversing local processing resources, the processing engine system 104 causes the clearing monitor to push the processing request out of the local processing resource, regardless of whether the processing resource has completed processing. In these implementations, the processing engine system 104 ensures that the canceled processing request does not occupy or further access local resources. In some implementations, the processing engine system 104 causes the clearing monitor to follow and wait for all unfinished processing requests to complete processing at the local processing resource.

[0109] In one or more implementations, the processing engine system 104 allows pending processing requests to enter the local processing resource after the clear monitor enters the local processing resource, but before the clear monitor has exited the local processing resource. Specifically, in various implementations, the clear monitor is sent to the local processing resource in association with receiving a target cancellation request, which triggers a modification of the sequence number of the canceled processing request. Therefore, after the clear monitor enters the local processing resource, the processing engine system 104 only allows valid processing requests to enter the local processing resource. Therefore, the processing engine system 104 improves efficiency by allowing the local processing resource to process valid pending processing requests without waiting for the local processing resource to completely clear the unfinished processing requests. In an alternative implementation, the processing engine system 104 prevents the sending resource from entering the local processing resource until it has been cleared, as indicated by the clear monitor exiting the local processing resource.

[0110] By utilizing the clear monitor and / or processing request completion indicator, the processing engine system 104 does not need to track or trace after a particular processing request that has been canceled and can be processed locally. In fact, by clearing all currently processed and uncompleted processing requests on local processing resources, the processing engine system 104 ensures that any processing request that may be included in the most recently identified cancellation request can no longer access local processing resources. In this way, the processing engine system 104 provides a flexible and elegant solution that does not require tracking and / or tracing of canceled processing requests that are located somewhere locally in the request processing flow.

[0111] As shown, the series of actions 600 includes an action 608 of returning a purge monitor to indicate that all pending processing requests are complete. For example, the processing engine system 104 identifies that the purge monitor and / or the processed / active processing request completion indicator has been processed, indicating that the local processing resource does not have any canceled processing requests (relative to the target cancel request). In fact, by returning the purge monitor, the processing engine system 104 can ensure that the target cancel request can no longer access the resources they previously accessed because these resources have been deallocated and may be allocated to satisfy new processing requests.

[0112] Now go to Figure 7 , which illustrates an example flow chart including a series of actions 700 for utilizing the processing engine system 104 according to one or more implementations. Specifically, Figure 7 An exemplary series of actions 700 for persisting monitored and processed event data to persistent storage is shown according to one or more implementations. Figure 7 The actions of may be performed as part of a method. Alternatively, the non-transitory computer readable medium may include a program that, when executed by one or more processors, causes a computing device to perform Figure 7 In the implementation, the system may execute the instruction of action 700. Figure 7 In some implementations, the processing engine performs one or more actions in the series of actions 700.

[0113] As shown, series of actions 700 includes an act of identifying a cancellation request 710. For example, in an example implementation, act 710 involves identifying a cancellation indication to cancel a service request currently being processed.

[0114] In various implementations, the processing request is a remote processing request sent to a remote computing device for processing, the remote processing request is sent to the remote computing device along with a token including a context identifier and a sequence number for the processing request, and / or a cancellation indication is identified and / or received when the remote processing request is at the remote computing device.

[0115] As further shown, the series of actions 700 includes an action 720 of modifying a sequence number of a canceled request in a context table. For example, in an example implementation, the action 720 involves modifying the sequence number to generate a modified sequence number at a target context entry of the request context table to indicate that the target context entry is invalid, the target context entry including a request context for a processing request associated with the service request in response to the cancellation indication. In some implementations, the action 720 includes generating a modified sequence number at the target context entry of the request context table by changing the most significant bit of the sequence number or adding a digit to the sequence number.

[0116] As further shown, the series of actions 700 includes an action 730 of providing a request validation check that prevents invalid processing requests from accessing processing resources. For example, in an example implementation, action 730 involves providing a request validation check that prevents invalid processing requests from accessing local processing resources before the local processing resources. In some implementations, action 730 includes identifying a target context entry for the processing request in a request context table by identifying the target context entry using a context identifier within a token of the processing request.

[0117] In an example implementation, action 730 includes providing a request validation check at a local processing resource before the processing request reaches the local processing resource to be processed. In various implementations, providing the request validation check before the local processing resource includes determining that a sequence number associated with the processing request is invalid based on a sequence number within a token associated with the processing request not matching a sequence number in a target context entry for the processing request in a request context table. In additional implementations, action 730 includes blocking the processing request from accessing the local processing resource and / or discarding the processing request based on determining that the processing request is invalid.

[0118] As further shown, the series of actions 700 includes an action 740 of clearing pending requests in the processing resource. For example, in an example implementation, the action 740 involves providing a processing request completion indicator to the local processing resource to verify that any processing request associated with a service request that arrived at the local processing resource before the processing request completion indicator arrived has completed processing. In some implementations, the action 740 includes pushing out the unfinished or waiting processing requests in the local processing resource using the processing request completion indicator.

[0119] As further shown, the series of actions 700 includes an action of confirming the cancellation request 750. For example, in an example implementation, the action 750 involves confirming the cancellation of the service request by indicating that the local processing resource will not be accessed to further process the processing request associated with the service request. In some implementations, the action 750 includes clearing any processing request currently in the local processing resource using the processing request completion indicator upon arrival of the processing request completion indicator and / or returning the processing request completion indicator to indicate that the local processing resource has been cleared.

[0120] In some implementations, the series of actions 700 includes additional actions. For example, in some implementations, the series of actions 700 includes an action of receiving a service request for a request return result at a processing engine, and an action of generating a processing request by adding a request context for the processing request to a context entry in a request context table in response to receiving the service request. In various implementations, the request context for the processing request includes a context identifier, a sequence number, and request service information. In various implementations, the series of actions 700 includes an action of identifying a processing request generated in a request context table in response to receiving the service request.

[0121] In some implementations, the series of actions 700 includes an action of rewriting data in the target context entry after the target context entry is marked as invalid. In various implementations, rewriting the data in the target context entry includes generating a new sequence number while maintaining a context identifier of the target context entry.

[0122] In an example implementation, the series of actions 700 includes receiving a processing result of a remote processing request from a remote computing device, wherein the processing result includes a token; providing the processing result and the token to a local processing resource; and / or utilizing a request validation check to determine that the processing request has been invalidated based on a mismatch between a serial number in the token and a modified serial number.

[0123] In some implementations, the series of actions 700 includes determining that the additional sequence number associated with the additional processing request is valid based on matching the additional sequence number within the additional token associated with the additional processing request with the additional context entry of the additional processing request in the request context table, and based on the additional processing request being valid, allowing the additional processing request to access the local processing resource. In various implementations, the additional processing request enters the local processing resource after the processing request completion indicator and before the processing request completion indicator clears the local processing resource of uncompleted processing requests (e.g., processing requests before the processing request completion indicator arrives).

[0124] In some implementations, the series of actions 700 includes receiving a processing result of a remote processing request from a remote processing service, wherein the remote processing request is sent to the remote processing service based on the service request, and wherein the processing result includes a token having a context identifier and a serial number for a target context entry; and / or discarding the processing result based on determining that the serial number in the token does not match a modified serial number in the target context entry.

[0125] In one or more implementations, the series of actions 700 includes receiving a processing result of the remote processing request from the remote computing device after modifying a sequence number at a target context entry (i.e., a request context), wherein the processing result includes a token; providing the processing result and the token to a local processing pipeline resource; and / or determining that the processing request has been invalidated using a request validation check before allowing access to the local processing pipeline resource based on a mismatch between the sequence number in the token and the modified sequence number. For multiple implementations, the processing engine includes a hardware accelerator and / or a local processing pipeline resource including an on-chip pipeline.

[0126] A "computer network" (hereinafter referred to as a "network") is defined as one or more data links capable of transmitting electronic data between computer systems and / or modules and / or other electronic devices. When information is transmitted or provided to a computer via a network or another communication connection (hardwired, wireless, or a combination of hardwired or wireless), the computer appropriately regards the connection as a transmission medium. The transmission medium may include a network and / or data links, which may be used to carry the required program code components in the form of computer executable instructions or data structures and may be accessed by a general or special purpose computer. Combinations of the above should also be included within the scope of computer readable media.

[0127] In addition, the network (i.e., computer network) described herein may represent a network or a collection of networks (such as the Internet, an intranet, a virtual private network (VPN), a local area network (LAN), a wireless local area network (WLAN), a cellular network, a wide area network (WAN), a metropolitan area network (MAN), or a combination of two or more such networks) through which one or more computing devices can access the processing engine system 104. In fact, the network described herein may include one or more networks that use one or more communication platforms or technologies to transmit data. For example, the network may include the Internet or other data links that enable electronic data to be transmitted between various client devices and components (e.g., server devices and / or virtual machines thereon) of a cloud computing system.

[0128] In addition, upon reaching various computer system components, program code methods in the form of computer executable instructions or data structures can be automatically transferred from the transmission medium to the non-transient computer readable storage medium (device) (or vice versa). For example, computer executable instructions or data structures received through a network (i.e., a computer network) or a data link can be cached in RAM within a network interface module (NIC) and then ultimately transferred to the computer system RAM and / or a less volatile computer storage medium (device) at the computer system. Therefore, it should be understood that the non-transient computer readable storage medium (device) can be included in a computer system component that also (or even primarily) utilizes a transmission medium.

[0129] Computer executable instructions include, for example, instructions and data that cause a general-purpose computer, a special-purpose computer, or a special-purpose processing device to perform a specific function or group of functions when executed by a processor. In some implementations, computer executable instructions are executed by a general-purpose computer to convert a general-purpose computer into a special-purpose computer that implements the elements of the present disclosure. Computer executable instructions may include, for example, binary code, intermediate format instructions such as assembly language, or even source code. Although the subject matter has been described in a language dedicated to structural features and / or method actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the above-mentioned features or actions. On the contrary, the described features and actions are disclosed as an example form of implementing the claims.

[0130] Figure 8 Illustrated are certain components that may be included within computer system 800. Computer system 800 may be used to implement the various computing devices, components, and systems described herein.

[0131] In various implementations, the computer system 800 may represent one or more of a client device, a server device, or other computing devices described above. For example, the computer system 800 may refer to various types of network devices capable of accessing data on a network (i.e., a computer network), a cloud computing system, or another system. For example, a client device may refer to a mobile device, such as a mobile phone, a smart phone, a personal digital assistant (PDA), a tablet computer, a laptop computer, or a wearable computing device (e.g., a headset or a smart watch). A client device may also refer to a non-mobile device, such as a desktop computer, a server node (e.g., from another cloud computing system), or another non-portable device.

[0132] Computer system 800 includes processor 801. Processor 801 may be a general-purpose single-chip or multi-chip microprocessor (e.g., Advanced RISC (Reduced Instruction Set Computer) Machine (ARM)), a special-purpose microprocessor (e.g., a digital signal processor (DSP)), a microcontroller, a programmable gate array, etc. Processor 801 may be referred to as a central processing unit (CPU). Although processor 801 is shown as Figure 8 A single processor is used in the computer system 800, but in an alternative configuration, a combination of processors (e.g., an ARM and DSP) could be used.

[0133] The computer system 800 also includes a memory 803 in electronic communication with the processor 801. The memory 803 can be any electronic component capable of storing electronic information. For example, the memory 803 can be implemented as a random access memory (RAM), a read-only memory (ROM), a disk storage medium, an optical storage medium, a flash memory device in a RAM, an on-board memory included in the processor, an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a register, etc., including combinations thereof.

[0134] Instructions 805 and data 807 may be stored in memory 803. Instructions 805 may be executed by processor 801 to implement some or all of the functionality disclosed herein. Executing instructions 805 may include using data 807 stored in memory 803. Any of the various examples of modules and components described herein may be implemented in part or in whole as instructions 805 stored in memory 803 and executed by processor 801. Any of the various examples of data described herein may be data 807 stored in memory 803 and used during execution of instructions 805 by processor 801.

[0135] The computer system 800 may also include one or more communication interfaces 809 for communicating with other electronic devices. The one or more communication interfaces 809 may be based on wired communication technology, wireless communication technology, or both. Some examples of the one or more communication interfaces 809 include a universal serial bus (USB), an Internet adapter, a wireless adapter operating according to the Institute of Electrical and Electronics Engineers (IEEE) 802.11 wireless communication protocol, Wireless communication adapter and infrared (IR) communication port.

[0136] The computer system 800 may also include one or more input devices 811 and one or more output devices 813. Some examples of the one or more input devices 811 include a keyboard, a mouse, a microphone, a remote control device, a button, a joystick, a trackball, a touchpad, and a light pen. Some examples of the one or more output devices 813 include speakers and printers. A specific type of output device that is typically included in the computer system 800 is a display device 815. The display device 815 used with the implementations disclosed herein may utilize any suitable image projection technology, such as a liquid crystal display (LCD), a light emitting diode (LED), a gas plasma, electroluminescence, etc. A display controller 817 may also be provided for converting the data 807 stored in the memory 803 into text, graphics, and / or moving images (when appropriate) displayed on the display device 815.

[0137] The various components of the computer system 800 may be coupled together via one or more buses, which may include a power bus, a control signal bus, a status signal bus, a data bus, etc. For clarity, Figure 8 The individual buses are shown as bus system 819.

[0138] Those skilled in the art will appreciate that the present invention can be practiced in a network computing environment with many types of computer system configurations, including personal computers, desktop computers, laptop computers, message processors, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile phones, PDAs, tablets, pagers, routers, switches, etc. The present disclosure can also be practiced in a distributed system environment, where local and remote computer systems that are linked (by hardwired data links, wireless data links, or a combination of hardwired and wireless data links) through a network (i.e., a computer network) both perform tasks. In a distributed system environment, program modules can be located in local and remote memory storage devices.

[0139] The techniques described herein may be implemented in hardware, software, firmware, or any combination thereof, unless explicitly described as being implemented in a particular manner. Any features described as modules, components, etc. may also be implemented together in an integrated logic device, or separately as discrete but interoperable logic devices. If implemented in software, the techniques may be implemented in part by a non-transitory processor-readable storage medium containing instructions, which, when executed by at least one processor, perform one or more of the methods described herein. Instructions may be organized into routines, programs, objects, components, data structures, etc., which may perform specific tasks and / or implement specific data types, and which may be combined or distributed as needed in various implementations.

[0140] Computer-readable media can be any available media that can be accessed by a general or special purpose computer system. Computer-readable media that store computer-executable instructions are non-transitory computer-readable storage media (devices). Computer-readable media that carry computer-executable instructions are transmission media. Therefore, by way of example and not limitation, implementations of the present disclosure may include at least two distinct types of computer-readable media: non-transitory computer-readable storage media (devices) and transmission media.

[0141] As used herein, non-transitory computer-readable storage media (devices) may include RAM, ROM, EEPROM, CD-ROM, solid-state drives (“SSD”) (e.g., RAM-based), flash memory, phase change memory (“PCM”), other types of memory, other optical disk storage, disk storage or other magnetic storage devices, or any other medium that can be used to store desired program code components in the form of computer-executable instructions or data structures and that can be accessed by a general or special purpose computer.

[0142] The steps and / or actions of the methods described herein may be interchanged with each other without departing from the scope of the claims. In other words, unless the proper operation of the described method requires a specific order of steps or actions, the order and / or use of specific steps and / or actions may be modified without departing from the scope of the claims.

[0143] The term "determining" encompasses a variety of actions, and thus, "determining" may include calculating, computing, processing, deriving, investigating, looking up (e.g., looking up in a table, a database, or another data structure), ascertaining, etc. Furthermore, "determining" may include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory), etc. Furthermore, "determining" may include resolving, selecting, choosing, establishing, etc.

[0144] The terms "comprising," "including," and "having" are intended to be inclusive, and mean that there may be additional elements in addition to the listed elements. Furthermore, it should be understood that reference to "an implementation" or "multiple implementations" of the present disclosure is not intended to be interpreted as excluding the existence of additional implementations that also incorporate the described features. For example, any element or feature described with respect to an implementation herein may be combined with any element or feature of any other implementation described herein where compatible.

[0145] The present disclosure may be embodied in other specific forms without departing from its spirit or features. The described implementation is considered to be illustrative rather than restrictive. Therefore, the scope of the present disclosure is indicated by the appended claims rather than by the preceding description. Changes within the meaning and scope of the equivalents of the claims will be included within their scope.

Claims

1. A computer-implemented method comprising: Identify a cancellation instruction to cancel the service request currently being processed; In response to the cancellation indication, modifying a sequence number to generate a modified sequence number at a target context entry of a request context table to indicate the target context entry as invalid, the target context entry including a request context for a processing request associated with the service request; providing a request validation check before a local processing resource, the request validation check preventing invalid processing requests from accessing the local processing resource; providing a processing request completion indicator to the local processing resource to verify that any processing request associated with the service request that arrived at the local processing resource prior to the arrival of the processing request completion indicator has completed processing; as well as Cancellation of the service request is confirmed by indicating that the local processing resources are not to be accessed to further process the processing request associated with the service request.

2. The computer-implemented method of claim 1 , further comprising: Receiving, at a processing engine, the service request for requesting a return result; as well as In response to receiving the service request, the processing request is generated by adding a request context for the processing request to a context entry in the request context table, wherein the request context for the processing request includes a context identifier, a sequence number, and request service information.

3. The computer-implemented method of claim 2, wherein identifying the cancellation indication to cancel the service request comprises: The processing request generated in the request context table in response to receiving the service request is identified.

4. The computer-implemented method of claim 3, wherein: said request validation check exists at said local processing resource before said processing request reaches said local processing resource to be processed; as well as Providing the request validation check before the local processing resource includes determining that the sequence number associated with the processing request is invalid based on the sequence number within the token associated with the processing request not matching the sequence number in the target context entry for the processing request in the request context table.

5. The computer-implemented method of claim 4, further comprising: Based on the determination that the processing request is invalid: preventing the processing request from accessing the local processing resource; as well as The processing request is discarded.

6. The computer-implemented method of claim 4, further comprising: The target context entry for the processing request is identified in the request context table by identifying the target context entry using a context identifier within the token of the processing request.

7. The computer-implemented method of any one of claims 2 to 6, further comprising: Rewriting data in the target context entry after the target context entry is marked as invalid, wherein rewriting the data in the target context entry comprises: generating a new sequence number while maintaining the context identifier for the target context entry.

8. The computer-implemented method of any one of claims 2 to 7, wherein providing the processing request completion indicator to the local processing resource comprises: When the processing request completion indicator arrives, using the processing request completion indicator to clear any processing request currently in the local processing resource; as well as The processing request completion indicator is returned to indicate that the local processing resources have been cleared.

9. A computer-implemented method according to any one of claims 2 to 8, wherein: The processing request is a remote processing request sent to a remote computing device for processing; The remote processing request is sent to the remote computing device along with a token, the token including the context identifier for the processing request and the sequence number; as well as The cancellation indication is identified while the remote processing request is at the remote computing device.

10. The computer-implemented method of claim 9, further comprising: receiving a result for the remote processing request from the remote computing device, the result including the token; providing the result and the token to the local processing resource; as well as Using the request validation check, it is determined that the processing request has been invalidated based on the serial number in the token not matching the modified serial number.

11. A processing engine comprising: a memory including a request context table having context entries, the context entries each including a context identifier, a unique sequence number, and request service information; local processing resources for processing one or more processing requests; and The processing engine is programmed to perform the method of any one of claims 1 to 10.

12. The processing engine of claim 11, wherein providing the request validation check prior to the local processing resource comprises: determining that the additional sequence number associated with the additional processing request is valid based on an additional sequence number within an additional token associated with the additional processing request matching the additional sequence number in an additional context entry for the additional processing request in the request context table; as well as Based on the additional processing request being valid, allowing the additional processing request to access the local processing resource, wherein the additional processing request enters the local processing resource after the processing request completion indicator and before the processing request completion indicator clears the local processing resource of processing requests prior to the arrival of the processing request completion indicator.

13. A computer-implemented method comprising: A cancel indication is identified by the processing engine to cancel the service request currently being processed; In response to the cancellation indication, modifying a sequence number to generate a modified sequence number at a target context entry of a request context table to indicate the target context entry as invalid, the target context entry including a request context for a processing request associated with the service request; At the processing engine, providing a request validation check before local processing pipeline resources, the request validation check prevents invalid processing requests from accessing local processing pipeline resources; providing, at the processing engine, a processing request completion indicator to a local processing pipeline resource to verify any local processing request triggered in response to the service request having completed processing at the local processing pipeline resource if the service request was initiated prior to receipt of the processing request completion indicator; receiving a processing result of a remote processing request from a remote processing service, wherein the remote processing request is sent to the remote processing service based on the service request, and wherein the processing result includes a token having a context identifier for the target context entry and the sequence number; as well as The processing result is discarded based on a determination that the sequence number in the token does not match the modified sequence number in the target context entry.

14. The computer-implemented method of claim 13, further comprising: Cancellation of the service request is confirmed by the processing engine by indicating that the local processing pipeline resources will not be accessed to further process the service request.

15. The computer-implemented method of claim 13, wherein the processing engine comprises a hardware accelerator, and wherein the local processing pipeline resources comprise an on-chip pipeline.

Images