KR-102964309-B1 - Mapping method for response information in response to requests from web applications in asynchronous data processing environments

KR102964309B1KR 102964309 B1KR102964309 B1KR 102964309B1KR-102964309-B1

Abstract

The present invention relates to a method for mapping response information corresponding to a request of a web application in an asynchronous data processing environment, wherein a unique identifier is generated per user or request regarding the processing of requests and responses of a web application in an asynchronous Java web application environment, and this is propagated throughout the asynchronous data processing environment to link responses such as database queries and execution history with the requests of the web application. The method comprises: a request identifier generation step in which a management server, which communicates via web with a client and a DB server in an asynchronous data processing environment, generates a request identifier for request information received from the web application of the client and assigns it to a context for the request information; a request identifier sharing step in which the management server processes the request identifier so that it is shared during asynchronous data processing; a DB query execution step in which the management server executes a DB query on a corresponding DB server according to the request information, wherein the linking of the request identifier of the request information to the DB query is processed; and a tracking step in which, when the management server receives response information from the DB server, the response information is mapped to the request identifier of the corresponding DB query to track the request information. The above management server includes a log storage step in which request information, DB query, and response information are stored as log data based on a request identifier.

Inventors

박천오
진선태
김영회

Assignees

주식회사 피앤피시큐어

Dates

Publication Date: 20260513
Application Date: 20250515

Claims (4)

A management server that communicates via web in an asynchronous data processing environment with a client and a DB server comprises: a request identifier generation step in which the management server generates a request identifier for request information received from the corresponding web application of the client and assigns it to a context for the request information; a request identifier sharing step in which the management server processes the request identifier so that it is shared during asynchronous data processing; a DB query execution step in which the management server executes a DB query on a corresponding DB server according to the request information, wherein the association of the request identifier of the request information with the DB query is processed; a tracing step in which, when the management server receives response information from the DB server, the response information is mapped to the request identifier of the corresponding DB query to trace the request information; and a log storage step in which the management server stores the request information, DB query, and response information as log data based on the request identifier. The request identifier sharing step includes the step of the management server transmitting the request identifier through a reactive stream context or channel attribute so that, in an asynchronous data processing environment between the client, the management server, and the DB server, the sharing of the request identifier is sustained even if a thread or execution context is switched during the processing of request information by the management server; A method for mapping response information in response to a request of a web application in an asynchronous data processing environment characterized by
delete
In Article 1, The above request identifier sharing step includes the step of storing and transmitting a request identifier in a context object of a Reactor so that the management server can transmit the request identifier through a reactive stream context, and the step of transferring the request identifier to a Mapped Diagnostic Context (MDC) using Hooks when a thread switches during the processing of request information by the management server so that the request identifier is retrieved when log data is output; A method for mapping response information in response to a request of a web application in an asynchronous data processing environment characterized by
In Article 1, The request identifier sharing step comprises the step of sharing the request identifier among events on the same connection by storing the request identifier in the AttributeMap of a channel in a Netty-based asynchronous data processing environment so that the management server can transmit the request identifier through channel attributes, and transmitting the corresponding request identifier to the processing logic of the event; A method for mapping response information in response to a request of a web application in an asynchronous data processing environment characterized by

Description

Mapping method for response information in response to requests from web applications in asynchronous data processing environments The present invention relates to a method for mapping response information corresponding to a request of a web application in an asynchronous data processing environment, wherein a unique identifier is generated per user or request regarding the processing of requests and responses of a web application in an asynchronous Java web application environment, and this identifier is propagated throughout the asynchronous data processing environment to link responses, such as database queries and execution history, with the requests of the web application. In existing synchronous web applications such as Servlet-based Spring MVC, a dedicated thread is allocated to process each client's web application request. In such environments, a widely used method involved utilizing ThreadLocal or MDC (Mapped Diagnostic Context) to store request contexts, such as the web application's request ID (identifier) or user identifier, within the thread scope and automatically including this information in logs. Ultimately, conventionally, the database query (hereinafter 'DB query') for each request of a web application and the response generation process, such as execution history, could be tracked within a single thread. For example, if the web application's request identifier was stored in ThreadLocal, it was possible to identify which request operation was being performed by referencing the corresponding request identifier or user identifier in all logs and DB accesses executed within that thread. However, in asynchronous or non-blocking web application environments, such as Spring WebFlux's Reactor-based implementations and Netty-based servers, it was difficult to apply the method described above for tracking the response generation process, including DB queries and execution history for each request of the web application. This is because, in asynchronous data processing environments, a single request is processed asynchronously across multiple threads, or a single thread handles multiple requests alternately. Meanwhile, since ThreadLocal-based context propagation techniques cannot transmit data across thread boundaries, problems arose in asynchronous data processing environments where context information used to identify web application requests was lost or incorrectly linked. For instance, in WebFlux, since the processing of web application requests is fragmented between the event loop thread and separate worker threads, request identifiers stored in a simple ThreadLocal could not be referenced in subsequent asynchronous steps. Consequently, confusion arose in logs and tracing information, making it impossible to identify which request corresponded to which DB query. Furthermore, as logs from multiple requests became mixed up, it became difficult to track the response generation process, including DB queries and execution history for each web application request. Furthermore, event-based non-blocking servers like Netty manage connections regarding web application requests, DB queries, and responses such as execution history at the Channel level; however, since multiple requests and responses (HTTP pipelining or HTTP/2 multiplexing) can occur over the same connection, simply storing a unique context for each request in the Channel was not sufficient. In other words, if an error occurred, multiple web application requests could overwrite a single context, potentially causing confusion in response matching. In short, because asynchronous Java web application environments do not utilize the traditional thread-locked model found in synchronous environments, there were technical difficulties in maintaining and tracking the relationships between web application requests, DB queries, and responses such as execution history. Therefore, to solve the aforementioned conventional problems, a thread-independent context propagation method and a request-specific identifier management technique were required. FIG. 1 is a block diagram illustrating an embodiment of a mapping system for tracking a DB query in response to a response from a DB server in the present invention, and FIG. 2 is a flowchart sequentially showing a mapping method based on the mapping system according to the present invention. The terms used in the embodiments have been selected to be as widely used as possible, taking into account their functions in the present invention; however, these terms may vary depending on the intent of those skilled in the art, case law, the emergence of new technologies, etc. Additionally, in specific cases, terms have been arbitrarily selected by the applicant, and in such cases, their meanings will be described in detail in the corresponding description of the invention. Therefore, the terms used in the present invention should be defined not merely by their names, but based on their meanings and the overall conte