Patent Application
20240394132
Use of cloud native and microservices technologies are becoming more common. Cloud native computing is a software development approach that utilizes cloud computing to create scalable applications within dynamic environments such as cloud or cloud-like computing environments. Common in cloud native computing architectures are microservices. Microservices (or microservices architecture) are a cloud native architectural approach in which a single application is composed of many loosely coupled and independently deployable smaller components, or services. These services typically have their own technology stack, inclusive of the database and data management model. A distributed application is composed of hundreds of microservices which communicate with each other using a synchronous protocol, such as the Hypertext Transfer Protocol (HTTP), or using an asynchronous protocol, such as the Advanced Message Queuing Protocol (AMQP).
This Summary is provided to introduce a selection of concepts in simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key or essential features or combinations of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
The backbone of a microservices architecture is the payload or the message body which forms the information for data exchange. The ability to exchange messages within the microservices architecture is critically important since lost or failed messages can result in both business loss and untraceable application errors. Protocols, such as HTTP, define the use of status codes to assist in the proper delivery and processing of messages. However, HTTP status codes such as 2xx, 3xx, 4xx, and 5xx are only helpful to the extent of determining what happened at the receiving end, such as whether the message was received by the recipient, failed at the server side, or encountered any network errors. Unfortunately, these status codes are of no help in determining whether messages received by the recipient are successfully processed. For example, a message may fail subsequent to the recipient sending back an HTTP status 200 OK indicating successful receipt of the message. In such cases, the sender may not know of the message failure or whether to resend the payload. Embodiments of the present disclosure provide solutions to these and other technical problems described herein.
In accordance with one illustrative embodiment provided to illustrate the broader concepts, systems, and techniques described herein, a method includes, by a computing device, intercepting a request message from a first microservice to a second microservice, saving information about the request message to a first database, and initiating a timer for the request message, wherein the timer specifies a predetermined time for retrying the request message. The method also includes, by the computing device, responsive to a determination that the timer expired, incrementing a current attempt count for the request message, wherein the current attempt count is a count of a number of times the request message is retried, and, responsive to a determination that the current attempt count does not exceed a maximum attempts permitted for the request message, retrieving the information about the request message from the first database, retrying the request message based on the information retrieved from the first database, and initiating the timer for the request message. The method further includes, responsive to a determination that the current attempt exceeds the maximum attempts permitted for the request message, by the computing device, saving information about the request message to a second database.
In some embodiments, the information about the request message includes a recipient of the request message, a payload, and a type of request message. In one aspect, the information about the request message includes a target Uniform Resource Identifier (URI), a payload, and a Hypertext Transfer Protocol (HTTP) method.
In some embodiments, the first database is an in-memory database.
In some embodiments, retrying the request message includes initiating the timer for the request message.
In some embodiments, the method also includes, by the computing device, responsive to the determination that the current attempt exceeds the maximum attempts permitted for the request message, setting a purge flag for the request message to indicate that the information about the request message can be permanently deleted from the first database.
In some embodiments, the method further includes, responsive to a determination that an acknowledgement signal for a request identifier associated with the request message is intercepted, by the computing device, stopping the timer for the request message and stopping the timer for the request message.
In some embodiments, the method also includes, by the computing device, purging information about the request message from the first database based on the purge flag for the request message.
In some embodiments, the computing device is a sidecar proxy deployed adjacent to the first microservice.
According to another illustrative embodiment provided to illustrate the broader concepts described herein, a system includes one or more non-transitory machine-readable mediums configured to store instructions and one or more processors configured to execute the instructions stored on the one or more non-transitory machine-readable mediums. Execution of the instructions causes the one or more processors to carry out a process corresponding to the aforementioned method or any described embodiment thereof.
According to another illustrative embodiment provided to illustrate the broader concepts described herein, a non-transitory machine-readable medium encodes instructions that when executed by one or more processors cause a process to be carried out, the process corresponding to the aforementioned method or any described embodiment thereof.
It should be appreciated that individual elements of different embodiments described herein may be combined to form other embodiments not specifically set forth above. Various elements, which are described in the context of a single embodiment, may also be provided separately or in any suitable sub-combination. It should also be appreciated that other embodiments not specifically described herein are also within the scope of the claims appended hereto.
The foregoing and other objects, features and advantages will be apparent from the following more particular description of the embodiments, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the embodiments.
Referring now to
In some embodiments, client machines 11 can communicate with remote machines 15 via one or more intermediary appliances (not shown). The intermediary appliances may be positioned within network 13 or between networks 13. An intermediary appliance may be referred to as a network interface or gateway. In some implementations, the intermediary appliance may operate as an application delivery controller (ADC) in a datacenter to provide client machines (e.g., client machines 11) with access to business applications and other data deployed in the datacenter. The intermediary appliance may provide client machines with access to applications and other data deployed in a cloud computing environment, or delivered as Software as a Service (SaaS) across a range of client devices, and/or provide other functionality such as load balancing, etc.
Client machines 11 may be generally referred to as computing devices 11, client devices 11, client computers 11, clients 11, client nodes 11, endpoints 11, or endpoint nodes 11. Client machines 11 can include, for example, desktop computing devices, laptop computing devices, tablet computing devices, mobile computing devices, workstations, and/or hand-held computing devices. Server machines 15 may also be generally referred to as a server farm 15. In some embodiments, a client machine 11 may have the capacity to function as both a client seeking access to resources provided by server machine 15 and as a server machine 15 providing access to hosted resources for other client machines 11.
Server machine 15 may be any server type such as, for example, a file server, an application server, a web server, a proxy server, a virtualization server, a deployment server, a Secure Sockets Layer Virtual Private Network (SSL VPN) server; an active directory server; a cloud server; or a server executing an application acceleration program that provides firewall functionality, application functionality, or load balancing functionality. Server machine 15 may execute, operate, or otherwise provide one or more applications. Non-limiting examples of applications that can be provided include software, a program, executable instructions, a virtual machine, a hypervisor, a web browser, a web-based client, a client-server application, a thin-client, a streaming application, a communication application, or any other set of executable instructions.
In some embodiments, server machine 15 may execute a virtual machine providing, to a user of client machine 11, access to a computing environment. In such embodiments, client machine 11 may be a virtual machine. The virtual machine may be managed by, for example, a hypervisor, a virtual machine manager (VMM), or any other hardware virtualization technique implemented within server machine 15.
Networks 13 may be configured in any combination of wired and wireless networks. Network 13 can be one or more of a local-area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a virtual private network (VPN), a primary public network, a primary private network, the Internet, or any other type of data network. In some embodiments, at least a portion of the functionality associated with network 13 can be provided by a cellular data network and/or mobile communication network to facilitate communication among mobile devices. For short range communications within a wireless local-area network (WLAN), the protocols may include 802.11, Bluetooth, and Near Field Communication (NFC).
Non-volatile memory 206 may include: one or more hard disk drives (HDDs) or other magnetic or optical storage media; one or more solid state drives (SSDs), such as a flash drive or other solid-state storage media; one or more hybrid magnetic and solid-state drives; and/or one or more virtual storage volumes, such as a cloud storage, or a combination of such physical storage volumes and virtual storage volumes or arrays thereof.
User interface 208 may include a graphical user interface (GUI) 214 (e.g., a touchscreen, a display, etc.) and one or more input/output (I/O) devices 216 (e.g., a mouse, a keyboard, a microphone, one or more speakers, one or more cameras, one or more biometric scanners, one or more environmental sensors, and one or more accelerometers, etc.).
Non-volatile memory 206 stores an operating system 218, one or more applications 220, and data 222 such that, for example, computer instructions of operating system 218 and/or applications 220 are executed by processor(s) 202 out of volatile memory 204. In one example, computer instructions of operating system 218 and/or applications 220 are executed by processor(s) 202 out of volatile memory 204 to perform all or part of the processes described herein (e.g., processes illustrated and described with reference to
The illustrated computing device 200 is shown merely as an illustrative client device or server and may be implemented by any computing or processing environment with any type of machine or set of machines that may have suitable hardware and/or software capable of operating as described herein.
Processor(s) 202 may be implemented by one or more programmable processors to execute one or more executable instructions, such as a computer program, to perform the functions of the system. As used herein, the term “processor” describes circuitry that performs a function, an operation, or a sequence of operations. The function, operation, or sequence of operations may be hard coded into the circuitry or soft coded by way of instructions held in a memory device and executed by the circuitry. A processor may perform the function, operation, or sequence of operations using digital values and/or using analog signals.
In some embodiments, the processor can be embodied in one or more application specific integrated circuits (ASICs), microprocessors, digital signal processors (DSPs), graphics processing units (GPUs), microcontrollers, field programmable gate arrays (FPGAs), programmable logic arrays (PLAs), multi-core processors, or general-purpose computers with associated memory.
Processor 202 may be analog, digital, or mixed signal. In some embodiments, processor 202 may be one or more physical processors, or one or more virtual (e.g., remotely located or cloud computing environment) processors. A processor including multiple processor cores and/or multiple processors may provide functionality for parallel, simultaneous execution of instructions or for parallel, simultaneous execution of one instruction on more than one piece of data.
Communications interfaces 210 may include one or more interfaces to enable computing device 200 to access a computer network such as a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or the Internet through a variety of wired and/or wireless connections, including cellular connections.
In described embodiments, computing device 200 may execute an application on behalf of a user of a client device. For example, computing device 200 may execute one or more virtual machines managed by a hypervisor. Each virtual machine may provide an execution session within which applications execute on behalf of a user or a client device, such as a hosted desktop session. Computing device 200 may also execute a terminal services session to provide a hosted desktop environment. Computing device 200 may provide access to a remote computing environment including one or more applications, one or more desktop applications, and one or more desktop sessions in which one or more applications may execute.
Referring to
In cloud computing environment 300, one or more client devices 302a-302t (such as client machines 11 and/or computing device 200 described above) may be in communication with a cloud network 304 (sometimes referred to herein more simply as a cloud 304). Cloud 304 may include back-end platforms such as, for example, servers, storage, server farms, or data centers. The users of clients 302a-302t can correspond to a single organization/tenant or multiple organizations/tenants. More particularly, in one implementation, cloud computing environment 300 may provide a private cloud serving a single organization (e.g., enterprise cloud). In other implementations, cloud computing environment 300 may provide a community or public cloud serving one or more organizations/tenants.
In some embodiments, one or more gateway appliances and/or services may be utilized to provide access to cloud computing resources and virtual sessions. For example, a gateway, implemented in hardware and/or software, may be deployed (e.g., reside) on-premises or on public clouds to provide users with secure access and single sign-on to virtual, SaaS, and web applications. As another example, a secure gateway may be deployed to protect users from web threats.
In some embodiments, cloud computing environment 300 may provide a hybrid cloud that is a combination of a public cloud and a private cloud. Public clouds may include public servers that are maintained by third parties to client devices 302a-302t or the enterprise/tenant. The servers may be located off-site in remote geographical locations or otherwise.
Cloud computing environment 300 can provide resource pooling to serve clients devices 302a-302t (e.g., users of client devices 302a-302n) through a multi-tenant environment or multi-tenant model with different physical and virtual resources dynamically assigned and reassigned responsive to different demands within the respective environment. The multi-tenant environment can include a system or architecture that can provide a single instance of software, an application, or a software application to serve multiple users. In some embodiments, cloud computing environment 300 can include or provide monitoring services to monitor, control, and/or generate reports corresponding to the provided shared resources and/or services.
In some embodiments, cloud computing environment 300 may provide cloud-based delivery of various types of cloud computing services, such as Software as a service (SaaS), Platform as a Service (PaaS), Infrastructure as a Service (IaaS), and/or Desktop as a Service (DaaS), for example. IaaS may refer to a user renting the use of infrastructure resources that are needed during a specified period. IaaS providers may offer storage, networking, servers, or virtualization resources from large pools, allowing the users to quickly scale up by accessing more resources as needed. PaaS providers may offer functionality provided by IaaS, including, e.g., storage, networking, servers, or virtualization, as well as additional resources such as, for example, operating systems, middleware, and/or runtime resources. SaaS providers may offer the resources that PaaS provides, including storage, networking, servers, virtualization, operating systems, middleware, or runtime resources. SaaS providers may also offer additional resources such as, for example, data and application resources. DaaS (also known as hosted desktop services) is a form of virtual desktop service in which virtual desktop sessions are typically delivered as a cloud service along with the applications used on the virtual desktop.
Upon returning the success message to API gateway 402, service 404b may asynchronously pass the message to a service 406b. Upon performing some initial validation on the payload and returning a success message to service 404b, service 406b may asynchronously pass the message to a service 408a. Similarly, upon returning the success message to API gateway 402, service 404c may synchronously pass the message to a service 406c and wait to receive a response (other than a message successfully received response) to the sent message from service 406c. Upon receiving the message from service 404c, service 406c may synchronously pass the message to service 408b and wait to receive a response (other than a message successfully received response) to the sent message from service 408b. Service 406c may also asynchronously pass the message to a service 408c. However, as can be seen in
In some embodiments, IMLD engine 502 can be provided as a service (e.g., a microservice) within network environment 500 (e.g., within the microservices environment of services 520, 530). IMLD engine 502 may be, according to some embodiments, configured to deploy sidecar proxies (or “sidecars”) to microservices that register for enabling the IMLD service provided by IMLD engine 502. IMLD engine 502 may also be enabled for a namespace in a cluster, such as a KUBERNETES cluster, in which case IMLD engine 502 is automatically registered for all the microservices running inside that namespace. In the example of
Referring to IMLD engine 502, message interceptor 504 is operable to monitor the network traffic and intercept and capture information about request messages (e.g., outgoing calls) being sent by a microservice to which a sidecar of IMLD engine 502 is attached. Such intercepted request messages can be understood to be potentially lost messages. In one implementation, message interceptor 504 may be configured to run as a request and response interceptor (e.g., HTTP or asynchronous protocol such as AMQP) collecting all the information a sender microservice sends to a receiving microservice endpoint. Message interceptor 504 can save the captured information per request/response to in-memory database 512. In one implementation, for a particular intercepted request message, message interceptor 504 can set a timer 506 (e.g., an instance of timer 506) for the request identifier of the request message to the waiting time for the acknowledgement signal from the receiving microservice (i.e., from the microservice that received the intercepted request message) and initiate the set timer 506. The waiting time for the acknowledgement signal may be specified in a retry policy. In the example of
Timers 506 can correspond to timer instances initiated for each intercepted request message. An instance of timer 506 can be initiated for a request identifier of an intercepted request message. Instances of timer 506 can be set to waiting times for acknowledgement signals as specified in the retry policy.
HTTP server 508 is operable to intercept acknowledgement signals for request messages intercepted by message interceptor 504. For example, HTTP server 508 can listen on a port (e.g., port 9090) for an incoming acknowledgement signal from a receiving microservice. The port that HTTP server 508 is to listen on may be specified as part of an IMLD policy. In one implementation, upon intercepting (e.g., receiving) an acknowledgement signal for a request identifier of an intercepted request message, HTTP server 508 can stop the timer 506 instance initiated for that request identifier. In the example of
Scheduler 510 is operable to attempt retries of intercepted request messages based on the retry policy. According to one implementation, for a particular intercepted request message, scheduler 510 can first determine whether the request message can be retried (e.g., replayed) based on the number of retries already attempted and the maximum number of retries permitted for the request message. To retry the request message, scheduler 510 can retrieve or query in-memory database 512 the information needed to retry the request message, such as the request identifier, the payload of the request message, and the type of request message. Scheduler 510 can then create the request message that is to be retried and trigger a job to make a retry call to the receiving microservice for the particular request message (e.g., trigger a job to retry the created request message). Scheduler 510 can then set a timer 506 for the request identifier of the request message (i.e., the request identifier of the retried message) to the waiting time for the acknowledgement signal from the receiving microservice as specified in the retry policy and initiate the set timer 506.
In-memory database 512 is operable to store the information and details about intercepted request messages. In-memory database 512 may implement or include a purpose-built database that primarily relies on memory (i.e., non-disk) for data storage. As a result, in-memory database 512 is faster and more efficient in execution and requires fewer CPU instructions to retrieve data as compared to legacy databases (e.g., as compared to databases that store data on disk storage or SSDs). In some embodiments, in-memory database 512 may be configured to purge records storing information about intercepted request messages that have completed processing either successfully (e.g., acknowledgement signals were intercepted) or by exhausting their permitted number of retries per the retry policy. Purging records from in-memory database 512 in this way enables in-memory database 512 to maintain a smaller digital footprint (i.e., utilize less memory and, thus, be more efficient). According to one implementation, in-memory database 512 may be configured to perform the purging of records storing information about intercepted request messages that have completed processing on a continuous or periodic basis (e.g., according to a predetermined schedule which may be configured as part of the IMLD policy).
In some embodiments, in-memory database 512 may be configured to store the information from the purged records within an audit log database, where it can be subsequently retrieved and used. Such information stored within the audit log database may indicate whether retries of the intercepted request messages were successful or unsuccessful. In some embodiments, the audit log database may correspond to a database that stores data on disk storage or SSDs instead of memory.
In some embodiments, in-memory database 512 may be implemented as a key-value based document database configured to store the information about intercepted request messages in corresponding records in the database. In-memory database 512 is further described below at least with respect to
IMLD configurator 514 can be used to configure (e.g. setup) IMLD engine 502. To this end, IMLD configurator 514 may provide an interface for configuring various settings to control various aspects of the operation of IMLD engine 502. In some embodiments, IMLD configurator 514 may maintain microservice and namespace registration information including the names of all the microservices and namespaces for which IMLD engine 502 needs to be enabled. The microservice and namespace registration information can be used to automatically register IMLD engine 502 (i.e., the sidecar of IMLD engine 502) for the microservices and/or namespaces in a cluster. The IMLD settings are further described below at least with respect to
Further description of the components of IMLD engine 502 and other processing that can be implemented within IMLD engine 502 is provided below with at least with respect to
Turning to
In the example shown in
The “Max_Attempts” attribute indicates the maximum number of times the request message can be retried (e.g., the maximum number of times the request message can be resent). The “Max_Attempts” attribute may be predetermined for the request message based on a defined policy (e.g., a retry policy). The “Current_Attempt” attribute indicates the number of retries attempted for the request message. For example, the “Current_Attempt” attribute can be incremented each time a retry is attempted for the request messages (e.g., each time the request message is resent). The “Status” attribute indicates the current status of the request message. For example, the “Status” attribute may indicate the type of response the request message is waiting to receive (e.g., “WAITING_ON_ACK”). The “Purge” attribute indicates whether the particular in-memory database record 600 can be purged from in-memory database 512 (e.g., permanently deleted in in-memory database 512 so as to free up memory). For example, the “Purge” attribute may be implemented as a flag which can be set to “TRUE” to indicate that the particular in-memory database record 600 can be purged, or “FALSE” to indicate that the particular in-memory database record 600 is not to be purged. In one implementation, the “Purge” attribute may be set to “FALSE” by default.
In embodiments, IMLD engine 502 and, more particularly, scheduler 510 of IMLD engine 502 can use the information stored within in-memory database records 600 to determine whether request messages (e.g., intercepted request messages) are to be retried. Scheduler 510 can also use the information stored within in-memory database records 600 to create (e.g., recreate) the request messages which are to be retried. The attributes shown in in-memory database record 600 are merely illustrative and is not intended to depict a complete list of attributes of in-memory database record 600. For example, in practice, in-memory database record 600 may include various other attributes and/or not include some of the attributes shown in
Turning to
The “Enable/Disable Pod” setting can be provided for the individual pods and can be used to specify whether IMLD engine 502 (i.e., the IMLD service) is to be enabled or disabled for the particular pod running a microservice. For instance, as discussed previously, a sidecar of IMLD engine 502 can attach to a microservice (e.g., attach to a microservice that registers for the IMLD service). In cases where the microservice is running on multiple pods, the individual pods on which the microservice is running will need its own sidecar. That is, for IMLD engine 502 to be enabled on the multiple pods on which the microservice is running (i.e., the multiple pods running the microservice), a sidecar of IMLD engine 502 needs to be attached to each of the multiple pods. The “Enable/Disable Pod” settings can be used to specify whether IMLD engine 502 is to be enabled or disabled for a particular pod on which a registered microservice (i.e., a microservice that registered for the IMLD service) is running.
The “Enable/Disable Namespace” setting can be provided for the induvial namespaces and can be used to specify whether IMLD engine 502 (i.e., the IMLD service) is to be enabled or disabled for the particular namespace in a cluster, such as a KUBERNETES cluster. If the “Enable/Disable Namespace” setting is enabled for a particular namespace, the IMLD service is automatically registered for all the microservices under that namespace. That is, if the “Enable/Disable Namespace” setting is enabled for a particular namespace, IMLD engine 502 is enabled for all the microservices under that namespace. The “DNS Entry” setting can be used to specify a DNS entry for the HTTP server (e.g., HTTP server 508) that is listening for the incoming acknowledgment signals. The “Listener Port” setting can be used to specify the port that the HTTP server (e.g., HTTP server 508) is to listen on for incoming acknowledgement signals.
The “Retry Policy” setting can be used to specify the retry policy that is to be applied in attempting to retry intercepted request messages. The retry policy may include information such as, for example, the number of retries to attempt for an intercepted request message and the waiting time for the acknowledgement signal (i.e., the timeout wait period) for an intercepted request message before a retry is to be attempted, among other information. In some implementations, a different number of retries may be specified for different types of request messages. In some implementations, increasingly longer waiting times for the acknowledgement signal may be specified (e.g., exponential backoff) based on the number of retries already attempted for an intercepted request message. For example, the retry policy may specify a timeout wait period of 10 minutes for a first retry attempt, a timeout wait period of 30 minutes for a second retry attempt, a time out wait period of 120 minutes for a third retry attempt, and a timeout wait period of 240 minutes for a fourth retry attempt. The “Max Attempts” setting can be used to specify a maximum number of retries that are to be attempted for an intercepted request message. The “Audit Log DB” setting specifies a connection string for the audit log database. That is, the “Audit Log DB” setting specifies the information needed to establish a connection to the audit log database. The settings shown in data structure 700 are merely illustrative and are not intended to depict a complete list of the IMLD settings for IMLD engine 502.
With reference to process 800, at 802, a request message may be intercepted. For example, message interceptor 504 may intercept the request message having request identifier RID123 sent by Microservice A.
At 804, information about the request message may be saved to a first database (e.g., an in-memory database). For example, message interceptor 504 may capture and save information about the request message having request identifier RID123 to in-memory database 512.
At 806, a timer for the request identifier of the request message may be initiated. Upon initiating the timer, process 800 may wait to intercept an acknowledgement signal for the request identifier of the request message or for expiration of the timer initiated for the request message. For example, message interceptor 504 or another component of IMLD engine 502 may set an instance of timer 506 for request identifier RID123 to the waiting time for the acknowledgement signal from Microservice B and initiate the set timer 506. Upon the set timer 506 for request identifier RID123 being initiated, message interceptor 504 may continue monitoring the network traffic for other request messages being sent by Microservice A.
At 808, an acknowledgement signal for the request identifier may be intercepted. For example, HTTP server 508 listening for acknowledgment signals may intercept an acknowledgment signal for request identifier RID123.
At 810, the timer initiated for the request identifier may be stopped. For example, upon intercepting the acknowledgment signal for request identifier RID123, HTTP server 508 may stop the timer 506 instance initiated for request identifier RID123. In some embodiments, IMLD engine 502 or another component of IMLD engine 502 may stop the timer 506 instance initiated for request identifier RID123.
At 812, the information about the request message may be saved to a second database (e.g., a database that stores data on disk storage or SSDs). For example, the information about the request message stored within the first database may be moved to the second database. For example, HTTP server 508 or another component of IMLD engine 502 may move the information about the request message having request identifier RID123 stored within in-memory database 512 to the audit log database.
At 814, the purge flag for the request message may be set to TRUE to indicate that the information about the request message saved in the first database can be purged. For example, upon moving the information to the audit log database, HTTP server 508 or another component of IMLD engine 502 may set the “Purge” attribute of the record in in-memory database 512 which stored the information about the request message having request identifier RID123 to TRUE.
However, prior to an acknowledgment signal for the request identifier being intercepted at 816, the timer initiated for the request identifier may expire. For example, the timer 506 instance initiated for request identifier RID123 may expire (i.e., timeout) prior to HTTP server 508 intercepting an acknowledgment signal for request identifier RID123.
At 818, the count of retry attempts for the request message may be incremented. For example, scheduler 510 may increment the “Current_Attempt” attribute of the record in in-memory database 512 storing the information about the request message having request identifier RID123.
At 820, a check may be performed to determine whether the number of retries attempted for the request message exceeds a maximum number of retries permitted for the request message. For example, scheduler 510 may check the “Current_Attempt” attribute and the “Max_Attempts” attribute of the record in in-memory database 512 storing the information about the request message having request identifier RID123 to determine whether the maximum number of retries permitted for the request message having request identifier RID123 is exceeded.
If, at 820, it is determined that the number of retries attempted for the request message does not exceed the maximum number of retries permitted for the request message, then, at 822, information about the request message may be retrieved from the first database. For example, if scheduler 510 determines that the maximum retries permitted for the request message having request identifier RID123, scheduler 510 may retrieve from in-memory database 512 the information stored about the request message having request identifier RID123. Scheduler 510 may then use the retrieved information to create the request message to retry (e.g., recreate the request message having request identifier TID123).
At 824, the request message may be retried. For example, scheduler 510 may schedule a job to resend the request message having request identifier RID123 created at 822. Scheduler 510 may then set an instance of timer 506 for request identifier RID123 to the waiting time for the acknowledgement signal from Microservice B and initiate the set timer 506.
Otherwise, if, at 820, it is determined that the number of retries attempted for the request message exceeds the maximum number of retries permitted for the request message, then, at 812, the information about the request message may be saved to the second database. For example, if scheduler 510 determines that the maximum retries permitted for the request message having request identifier RID123, scheduler 510 may move the information about the request message having request identifier RID123 stored within in-memory database 512 to the audit log database.
At 814, the purge flag for the request message may be set to TRUE to indicate that the information about the request message saved in the first database can be purged. For example, upon moving the information to the audit log database, scheduler 510 may set the “Purge” attribute of the record in in-memory database 512 which stored the information about the request message having request identifier RID123 to TRUE.
In the foregoing detailed description, various features of embodiments are grouped together for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claims require more features than are expressly recited. Rather, inventive aspects may lie in less than all features of each disclosed embodiment.
As will be further appreciated in light of this disclosure, with respect to the processes and methods disclosed herein, the functions performed in the processes and methods may be implemented in differing order. Additionally or alternatively, two or more operations may be performed at the same time or otherwise in an overlapping contemporaneous fashion. Furthermore, the outlined actions and operations are only provided as examples, and some of the actions and operations may be optional, combined into fewer actions and operations, or expanded into additional actions and operations without detracting from the essence of the disclosed embodiments.
Elements of different embodiments described herein may be combined to form other embodiments not specifically set forth above. Other embodiments not specifically described herein are also within the scope of the following claims.
Reference herein to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the claimed subject matter. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments necessarily mutually exclusive of other embodiments. The same applies to the term “implementation.”
As used in this application, the words “exemplary” and “illustrative” are used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as “exemplary” or “illustrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs. Rather, use of the words “exemplary” and “illustrative” is intended to present concepts in a concrete fashion.
In the description of the various embodiments, reference is made to the accompanying drawings identified above and which form a part hereof, and in which is shown by way of illustration various embodiments in which aspects of the concepts described herein may be practiced. It is to be understood that other embodiments may be utilized, and structural and functional modifications may be made without departing from the scope of the concepts described herein. It should thus be understood that various aspects of the concepts described herein may be implemented in embodiments other than those specifically described herein. It should also be appreciated that the concepts described herein are capable of being practiced or being carried out in ways which are different than those specifically described herein.
Terms used in the present disclosure and in the appended claims (e.g., bodies of the appended claims) are generally intended as “open” terms (e.g., the term “including” should be interpreted as “including, but not limited to,” the term “having” should be interpreted as “having at least,” the term “includes” should be interpreted as “includes, but is not limited to,” etc.).
Additionally, if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, as an aid to understanding, the following appended claims may contain usage of the introductory phrases “at least one” and “one or more” to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim recitation to embodiments containing only one such recitation, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an” (e.g., “a” and/or “an” should be interpreted to mean “at least one” or “one or more”); the same holds true for the use of definite articles used to introduce claim recitations.
In addition, even if a specific number of an introduced claim recitation is explicitly recited, such recitation should be interpreted to mean at least the recited number (e.g., the bare recitation of “two widgets,” without other modifiers, means at least two widgets, or two or more widgets). Furthermore, in those instances where a convention analogous to “at least one of A, B, and C, etc.” or “one or more of A, B, and C, etc.” is used, in general such a construction is intended to include A alone, B alone, C alone, A and B together, A and C together, B and C together, or A, B, and C together, etc.
All examples and conditional language recited in the present disclosure are intended for pedagogical examples to aid the reader in understanding the present disclosure, and are to be construed as being without limitation to such specifically recited examples and conditions. Although illustrative embodiments of the present disclosure have been described in detail, various changes, substitutions, and alterations could be made hereto without departing from the scope of the present disclosure. Accordingly, it is intended that the scope of the present disclosure be limited not by this detailed description, but rather by the claims appended hereto.
