Middleware communication method and device, equipment and storage medium

Abstract

The invention discloses a middleware communication method and device, equipment and a storage medium, and relates to the technical field of communication, and the middleware communication method comprises the steps that a middleware calling signal is acquired, and a target sub-process is determined from multiple sub-processes according to a calling function of the middleware calling signal and a calling interface of each sub-process; when an application layer calls an underlying program through a target sub-process, obtaining sub-process exception information and sub-process exception information; obtaining an exception handling strategy according to the sub-process exception information, and restarting the target sub-process or controlling the target sub-process to roll back to the previous node according to the exception handling strategy; according to the method, the problem of communication abnormality of the sub-thread is found in time by setting the sub-thread to perform self-inspection and throw the abnormality and the main thread to supervise the abnormality of the sub-thread at the same time, the problem of single sub-thread is controlled, the use of other sub-threads is not affected, and the problem that the whole middleware process crashes due to the communication abnormality of a single interface is effectively avoided.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a middleware communication method, apparatus, device and storage medium. Background Art

[0002] With the improvement of enterprise informatization and the development of Internet applications, distributed systems have become mainstream. These systems usually span multiple geographical locations, different hardware platforms and operating system environments. In order to achieve interoperability between different components, a middle layer is provided that can shield the underlying differences and provide a unified interface.

[0003] In the current market, the design of product software system middleware is often based on a simple point-to-point communication model. As business complexity increases, this model is difficult to meet the needs of efficient data exchange. A single communication channel can easily become a performance bottleneck for the system when faced with a large number of concurrent requests. There is a lack of a complete exception capture and recovery mechanism. Once an unforeseen error occurs, it may lead to application termination. Currently, many product software system middleware processes use single-channel communication, which can easily lead to the crash of the entire middleware process due to a single interface communication anomaly.

[0004] The above contents are only used to assist in understanding the technical solution of the present application and do not constitute an admission that the above contents are prior art. Summary of the invention

[0005] The main purpose of the present application is to provide a middleware communication method, device, equipment and storage medium, aiming to solve the technical problem that many product software system middleware processes in the current market are single-channel communications, and single interface communication anomalies are prone to cause the entire middleware process to crash.

[0006] To achieve the above object, the present application proposes a middleware communication method, which is applied to the middleware in the middleware communication system, the middleware communication system includes an application layer, a middleware and an underlying program, and the middleware includes a main process and multiple sub-processes;

[0007] The middleware communication method comprises:

[0008] Obtaining a middleware calling signal, and determining a target subprocess from the plurality of subprocesses according to a calling function of the middleware calling signal and a calling interface of each subprocess;

[0009] When the application layer calls the underlying program through the target sub-process, sub-process exception information is obtained, wherein the sub-process exception information includes reporting exception information obtained by capturing an exception thrown by the target sub-process and / or monitoring exception information obtained by analyzing a running log of the target sub-process;

[0010] An exception handling strategy is obtained according to the child process exception information, and the target child process is restarted or controlled to roll back to a previous node according to the exception handling strategy.

[0011] In one embodiment, when the application layer calls the underlying program through the target sub-process, the sub-process exception information is obtained, and the sub-process exception information includes reporting exception information obtained by capturing the exception thrown by the target sub-process, and / or monitoring exception information obtained by analyzing the running log of the target sub-process, including:

[0012] When the application layer calls the underlying program through the target sub-process, the sub-process exception signal thrown by the sub-process is captured through the sub-process exception handling mechanism, and the sub-process exception signal and the preset exception signal-fault list are used to obtain the reported exception information, wherein the sub-process exception signal is generated and thrown when the sub-process detects a preset exception trigger signal;

[0013] In response to a sub-process detection signal, the heartbeat signal, resource usage and response time of the target sub-process are called. When the heartbeat signal, resource usage and response time are inconsistent with the standard state of the target sub-process, monitoring exception information is obtained based on the heartbeat signal, resource usage and response time. The standard state includes a standard heartbeat signal, a resource usage standard and a standard response time.

[0014] In one embodiment, the sub-process exception handling mechanism is used to capture the sub-process exception signal thrown by the sub-process, and the sub-process exception signal and the preset exception signal-fault list are used to obtain the reported exception information, including:

[0015] Capture the subprocess exception signal thrown by the subprocess through the subprocess exception handling mechanism;

[0016] Match the subprocess exception signal with the exception signal in the preset exception signal-fault list to obtain the exception type, error message, stack trace and context information;

[0017] The exception type, the error message, the stack trace and the context information are used as reported exception information.

[0018] In one embodiment, obtaining an exception handling strategy according to the child process exception information, and restarting the target child process or controlling the target child process to roll back to a previous node according to the exception handling strategy include:

[0019] Determine the abnormality type of the target sub-process according to the sub-process abnormality information, wherein the abnormality type includes process abnormality and operation abnormality;

[0020] When the abnormal state is a process abnormality, restarting the target subprocess is used as an abnormality handling strategy;

[0021] When the abnormal state is an operation abnormality, the target subprocess is controlled to roll back to the previous node as an exception handling strategy.

[0022] In one embodiment, when the abnormal state is a process abnormality, restarting the target subprocess as an abnormality handling strategy includes:

[0023] When the abnormal state is a process abnormality, obtaining the current progress of the target subprocess and using the current progress as a reference state;

[0024] Initializing the target subprocess to obtain an initialized target subprocess;

[0025] The target subprocess is adjusted to the reference state, and the target subprocess is restarted.

[0026] In one embodiment, the obtaining of the middleware calling signal and determining the target sub-process from the plurality of sub-processes according to the calling function of the middleware calling signal and the calling interface of each sub-process include:

[0027] Get the middleware call signal;

[0028] Matching the calling function of the middleware calling signal with the calling functions of each sub-process to obtain a successfully matched sub-process;

[0029] The subprocess of the successfully matched subprocess is taken as the target subprocess.

[0030] In addition, to achieve the above-mentioned purpose, the present application also proposes a middleware communication device, the middleware communication device comprising:

[0031] A signal acquisition module, used to acquire a middleware call signal, and identify a target subprocess among multiple subprocesses according to the middleware call signal;

[0032] The signal acquisition module is further used to obtain the sub-process exception information of the target sub-process when the application layer calls the underlying program through the target sub-process, wherein the sub-process exception information includes reporting exception information and / or monitoring exception information, wherein the reporting exception information is obtained through the self-check of the target sub-process, and the monitoring exception information is obtained through the main process monitoring the target sub-process;

[0033] The sub-process control module is used to obtain an exception handling strategy according to the sub-process exception information, and control the target sub-process according to the exception handling strategy to ensure normal communication of the middleware.

[0034] In addition, to achieve the above objectives, the present application also proposes a middleware communication device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the middleware communication method described above.

[0035] In addition, to achieve the above objectives, the present application also proposes a storage medium, which is a computer-readable storage medium, and stores a computer program on the storage medium. When the computer program is executed by a processor, the steps of the middleware communication method described above are implemented.

[0036] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, wherein the computer program product includes a computer program, and when the computer program is executed by a processor, the steps of the middleware communication method described above are implemented.

[0037] One or more technical solutions proposed in this application have at least the following technical effects:

[0038] By setting up a main thread and multiple sub-threads in the middle layer, the sub-threads directly communicate with the application layer and call the underlying program to ensure that each sub-thread is independent of each other. At the same time, sub-thread self-inspection and main thread supervision are set up for exception supervision to promptly detect communication anomalies in sub-threads and control problems for individual sub-threads without affecting the use of other sub-threads, effectively avoiding the problem of a single interface communication anomaly causing the entire middleware process to crash. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0040] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0041] Figure 1 A flow chart of the middleware communication method embodiment 1 of the present application;

[0042] Figure 2 A system level diagram of a middleware communication system provided for the first embodiment of the middleware communication method of the present application;

[0043] Figure 3 A schematic diagram of a middleware process architecture provided for the first embodiment of the middleware communication method of the present application;

[0044] Figure 4 A schematic diagram of the main process interface and sub-process interface structure provided for the first embodiment of the middleware communication method of the present application;

[0045] Figure 5 A schematic diagram of a system structure based on a main process and a sub-process provided in Embodiment 1 of the middleware communication method of the present application;

[0046] Figure 6 A schematic diagram of a calling architecture for the application layer to call a sub-process interface and sub-process communication provided in the first embodiment of the middleware communication method of the present application;

[0047] Figure 7 A schematic diagram of abnormal observation between a main process and a sub-process provided in Embodiment 1 of the middleware communication method of the present application;

[0048] Figure 8 A flow chart of the second embodiment of the middleware communication method of the present application;

[0049] Fig. 9 A schematic diagram of the protection flow of the main process to the sub-process provided in the second embodiment of the middleware communication method of the present application;

[0050] Fig.10 This is a schematic diagram of the module structure of the middleware communication device in an embodiment of the present application;

[0051] Fig.11 This is a schematic diagram of the device structure of the hardware operating environment involved in the middleware communication method in the embodiment of the present application. DETAILED DESCRIPTION

[0052] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0053] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0054] The main solution of the embodiment of the present application is: obtaining a middleware call signal, and identifying a target sub-process among multiple sub-processes according to the middleware call signal; obtaining sub-process exception information of the target sub-process when the application layer calls the underlying program through the target sub-process, the sub-process exception information includes reporting exception information and / or monitoring exception information, the reporting exception information is obtained through self-checking of the target sub-process, and the monitoring exception information is obtained through monitoring the target sub-process by the main process; obtaining an exception handling strategy according to the sub-process exception information, and controlling the target sub-process according to the exception handling strategy to ensure normal communication of the middleware.

[0055] In this embodiment, for the convenience of description, the following description is made by taking the identification middleware communication device as the execution subject.

[0056] As the current technology improves the level of enterprise informatization and the development of Internet applications, distributed systems have become mainstream. These systems usually span multiple geographical locations, different hardware platforms and operating system environments. In order to achieve interoperability between different components, an intermediate layer is provided that can shield the underlying differences and provide a unified interface.

[0057] In the current market, the design of product software system middleware is often based on a simple point-to-point communication model. As business complexity increases, this model is difficult to meet the needs of efficient data exchange. A single communication channel can easily become a performance bottleneck for the system when faced with a large number of concurrent requests. There is a lack of a complete exception capture and recovery mechanism. Once an unforeseen error occurs, it may lead to application termination. Currently, many product software system middleware processes use single-channel communication, which can easily lead to the crash of the entire middleware process due to a single interface communication anomaly.

[0058] The present application provides a solution, which ensures that each sub-thread is independent of each other by setting a main thread and multiple sub-threads in the middle layer, and calling the underlying program based on the direct communication between the sub-threads and the application layer. At the same time, the sub-thread self-check and main thread supervision are set to monitor abnormal communication, so as to timely discover the abnormal communication problems of the sub-threads, control the problems of a single sub-thread, and do not affect the use of other sub-threads, so as to effectively avoid the problem that a single interface communication abnormality causes the entire middleware process to crash.

[0059] It can be seen from the above embodiments that the present application discloses a middleware communication method, apparatus, device and storage medium, which relates to the field of communication technology, and discloses a middleware communication method, including: obtaining a middleware call signal, and identifying a target sub-process among multiple sub-processes according to the middleware call signal; when the application layer calls the underlying program through the target sub-process, obtaining the reported exception information and / or monitoring exception information of the target sub-process; obtaining an exception handling strategy according to the sub-process exception information, and controlling the target sub-process according to the exception handling strategy; the method sets a main thread and multiple sub-threads in the middle layer, and calls the underlying program based on the direct communication between the sub-threads and the application layer to ensure that each sub-thread is independent of each other, and at the same time sets the sub-thread self-check and main thread supervision exception supervision, so as to promptly discover the communication abnormality of the sub-thread, control the problem of a single sub-thread, and do not affect the use of other sub-threads, so as to effectively avoid the problem that a single interface communication abnormality causes the entire middleware process to crash.

[0060] It should be noted that the execution subject of this embodiment may be a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or an electronic device capable of realizing the above functions, a middleware communication device, etc. The following takes the middleware communication device as an example to illustrate this embodiment and the following embodiments.

[0061] Based on this, the present application embodiment provides a middleware communication method, referring to Figure 1 , Figure 1 This is a flow chart of the first embodiment of the middleware communication method of the present application.

[0062] In this embodiment, the middleware communication method includes steps S10 to S30:

[0063] Step S10, obtaining a middleware calling signal, and determining a target sub-process from the plurality of sub-processes according to a calling function of the middleware calling signal and a calling interface of each sub-process.

[0064] It is understandable that the middleware call signal can be a signal sent to the middleware when the TV application software wants to use a certain function according to the function that needs to be called. The middleware call signal is obtained through the signal call function. The signal call function refers to a function pre-defined in the program design, which is used to receive and process signals (Signals) sent from the operating system or other processes, and is usually called a signal handler.

[0065] It should be understood that the middleware communication method of the present invention is applied to the middleware in the middleware communication system. The system hierarchy diagram of the middleware communication system can be referred to as Figure 2 , Figure 2 The middleware communication system includes an application layer, middleware and an underlying program, and the middleware includes a main process and multiple sub-processes.

[0066] It should be noted that the middleware includes a main process and multiple sub-processes. The middleware process architecture can be referred to Figure 3 , Figure 3 The sub-process can include sub-processes with multiple functions such as AQ, PQ, Media, Log, Setting, and the main process of Main. Among them, modules such as AQ (audio quality), PQ (picture quality), Media (media), Log (log), Setting (settings), etc. are part of the middleware, and they provide specific functional interfaces for the application layer to call.

[0067] The main process is the first process to be initialized after the TV is turned on, usually named init. The main responsibilities of the main process include: initializing the operating environment of the entire system to prepare for the startup of other components or processes; after completing its own initialization, the main process starts and manages all sub-processes by sending intent instructions; through a certain observer mode (Observer), the main process monitors the exceptions that occur in the sub-processes and takes measures when an exception is detected, such as restarting the sub-process with problems.

[0068] Among them, the subprocess is an independent process started by the main process after the main process is successfully initialized. The subprocess can respond to the startup instruction. When receiving the intent instruction sent by the main process, each subprocess starts its own initialization process (init); once the initialization is completed, the subprocess will focus on performing the specific task or service assigned to it; if a problem is encountered during operation, such as an exception caused by the application layer calling the interface, the subprocess can throw an exception signal, which will be captured by the main process. Then, according to the preset strategy, the main process may try to restart the subprocess to resume normal operation.

[0069] It should be noted that the main process is a process that starts other processes (i.e., child processes), which is usually responsible for initializing the main parts of the system or application and can serve as the entry point of the entire application; the child process is an independent process created by the main process.

[0070] In this embodiment, the main process is a running logic program that starts the sub-process and monitors the sub-process exceptions; the sub-process is the underlying program calling program under the main process that matches the calling signal requirement function.

[0071] It should be further explained that the target sub-process can be any one of the multiple sub-processes, and the function of the target sub-process is consistent with the function that the application layer wants to call.

[0072] It should be noted that when the application layer calls the underlying program through the sub-process, before obtaining the reported exception information and monitoring the exception information, it also includes: obtaining a power-on startup signal, initializing the main process based on the power-on startup signal and generating a sub-process initialization signal; initializing each sub-process according to the sub-process initialization signal.

[0073] It is understandable that the power-on start signal may be a signal generated when the TV is started, and the main process and the sub-process are activated based on the signal, so that subsequent users can call various functions based on software applications in the TV.

[0074] It should be noted that the main process interface and sub-process interface structure can refer to Figure 4 In the figure, the main process can include init interface (initialization interface) and intent interface (start sub-process interface); each sub-process has init interface, intent interface and function control interface under each sub-process function. The main process has interfaces init (initialization) and intent (start sub-process); sub-process interfaces include init (initialization), intent (start main process), fun1 (function 1), fun2 (function 2), etc.

[0075] Among them, it should be emphasized that the application layer communicates directly with the sub-process, and if a function needs to be called, it can directly call the sub-process fun interface.

[0076] Among them, it should be emphasized that after the user starts the TV, the main process starts to initialize. After the main process is initialized, all sub-processes are started in sequence. The main process starts the sub-process by sending an intent instruction to the sub-process, and the sub-process starts to initialize after receiving the initialization instruction sent by the main process.

[0077] It should be emphasized that the main process can start a sub-process, but generally the sub-process cannot start the main process. However, when the application layer calls a sub-process and finds that the main process stops running for some reason (shutdown, black screen, card disconnection, etc.), the main process can be started through the intent interface.

[0078] In a feasible implementation, step S10 may include steps A11 to A13:

[0079] Step A11, obtaining a middleware calling signal.

[0080] It is understandable that the middleware call signal can be an action that the user wants to perform, such as turning on music, turning on settings, starting WIFI, etc. The middleware call signal can be obtained from the application layer after the application layer generates the signal based on user needs.

[0081] It should be noted that the calling software, calling function, control amount and other information designed by the middleware calling signal are determined by analyzing the middleware calling signal.

[0082] It should be noted that the target calling function may be a function designed based on the middleware calling signal. For example, if the middleware calling signal is to increase the volume, the corresponding target calling function may include a volume control function and a volume level setting function.

[0083] It should be noted that obtaining the target calling function based on the middleware calling signal may be based on the function that the user wants to use carried in the calling signal, and taking the function as the target calling function.

[0084] Step A12, matching the calling function of the middleware calling signal with the calling functions of each sub-process to obtain a successfully matched sub-process.

[0085] It is understandable that the functions that the application layer needs to use may be different each time. The middleware call signal of the application layer can determine the calling function that the user wants. It is understandable that the sub-process is a calling program, and each sub-process can select a different functional interface. The functional interface selected based on the sub-process meets the user's function calling needs.

[0086] It should be noted that the subprocess includes multiple interfaces, each of which represents a different function. Each interface of the subprocess corresponds to a different control function under the function, for example: 1) AQ (audio quality) interface includes: Initialization interface: initAudio(): Initialize the audio module. Volume control: setVolume(level): Set the volume level. mute(): Mute the audio output. unmute(): Unmute. Sound effect settings: setEqualizer(settings): Set the equalizer parameters. enableSurroundSound(enable): Enable or disable surround sound. Audio output selection: selectOutputDevice(device): Select the audio output device (such as speakers, headphones, etc.).

[0087] 2) PQ (Picture Quality) interface includes: Initialization interface: initPicture(): Initialize the image module. Brightness and contrast: setBrightness(level): Set brightness. setContrast(level): Set contrast. Color adjustment: setSaturation(level): Set saturation. setHue(level): Set hue. Image mode: setPictureMode(mode): Set image mode (such as standard, cinema, dynamic). Resolution and ratio: setResolution(resolution): Set resolution. setAspectRatio(ratio): Set display ratio, etc.

[0088] 3) Media player interface includes: Initialization interface: initPlayer(): Initialize the media player. Playback control: play(): Play media. pause(): Pause playback. stop(): Stop playback. Media navigation: seek(position): Jump to the specified position. next(): Play the next media. previous(): Play the previous media. Playlist management: addToPlaylist(media): Add media to the playlist. removeFromPlaylist(media): Remove media from the playlist. Audio and subtitles: selectAudioTrack(track): Select an audio track. selectSubtitleTrack(track): Select a subtitle track, etc.

[0089] It should be noted that the application layer calls the underlying program through the middle layer. The system structure diagram based on the main process and sub-process can be referred to Figure 5In the figure, the application layer is the top layer, the middle layer including the main process and the sub-process is the middle layer, and the bottom layer (i.e. the bottom layer program) is the bottom layer. The left side of the middle layer is the main process, and the right side is the sub-process, which mainly includes a single main process and multiple sub-processes. For further information, the call architecture diagram of the application layer calling the sub-process interface and the sub-process communication can be referred to. Figure 6 ,In the figure, the application layer connects with the child process through interface communication.

[0090] It should be noted that each sub-process can provide an independent communication interface, and the application layer can directly call the corresponding sub-process function as needed, rather than through a single middleware channel, which can reduce communication bottlenecks and improve response speed.

[0091] It should be emphasized that the application layer calls are made based on the sub-process functional modules. Each functional module has N interfaces. The functional modules have been divided in the architecture. If there are new functional modules, this architecture can also be expanded.

[0092] Step A13: taking the sub-process of the successfully matched sub-process as the target sub-process.

[0093] It is understandable that each sub-process corresponds to a calling program with different functions, and the functions that can be called by each sub-process are matched with the target calling function, and the sub-process that is successfully matched is used as the target sub-process.

[0094] In this implementation, through a software architecture based on a main process and multiple sub-processes, the application layer can directly call the interface of a single control function of the middle-layer sub-process to call the underlying program, thereby meeting the user's control needs, while avoiding the problem of all control functions being unavailable when problems occur in the sub-process, allowing the application layer to more conveniently access underlying resources and services.

[0095] The above are only feasible implementations of step S10 provided in this embodiment, and this embodiment does not specifically limit the specific implementation of step S10.

[0096] Step S20, when the application layer calls the underlying program through the target sub-process, the sub-process exception information is obtained, and the sub-process exception information includes the reported exception information obtained by capturing the exception thrown by the target sub-process, and / or the monitoring exception information obtained by analyzing the operation log of the target sub-process.

[0097] It should be noted that when the application layer calls the underlying program through the target sub-process, the main process, as an observer, checks the running logs of each sub-process when the application layer calls the sub-process and monitors each sub-process. The application layer can call multiple sub-processes at the same time, and the main process can monitor each sub-process at the same time.

[0098] It is understandable that the main process can capture various log entries generated during runtime by monitoring the running logs of each child process, and analyze whether they contain error prompts or other abnormal behaviors. If there are error prompts or other abnormal behaviors, child process exception information can be generated based on the error prompts or other abnormal behaviors caused by the abnormalities.

[0099] It should be noted that when the main process monitors the running logs of each sub-process for abnormalities, the sub-process will also perform self-checks, that is, the sub-process checks whether there is an error when it is running. If there is an error, it will be fed back to the main process based on the error content. Specifically, it can be understood as the process of actively reporting error details to a higher level when the sub-process encounters an error. For example, in Java, this can be achieved by throwing an exception; in C++, you can use an exception handling mechanism such as try-catch. Developers can set specific conditions in the code, and once they are met, exception reporting is triggered.

[0100] It should be understood that when a sub-process self-checks and finds an exception, it will feed the exception information back to the main process, and the main process will handle the exceptions of each sub-process in a unified manner. For the abnormal observation diagram between the main process and the sub-process, please refer to Figure 7 In the figure, the main process acts as an Observer to observe the child process Observed, and the child process promptly feeds back the self-test results to the main process.

[0101] It is understandable that the sub-process abnormal information can be the reported abnormal information discovered by the sub-process self-check, or it can be the monitoring abnormal information about the sub-process observed by the main process, or both abnormal information can exist at the same time.

[0102] It should be noted that through sub-process self-inspection and main process supervision, possible exceptions that may exist when the application layer calls the underlying program through the middleware can be discovered both internally and externally. Based on the exception information, only the sub-process with the exception is processed to ensure that the application layer can call the sub-process normally.

[0103] Step S30, obtaining an exception handling strategy according to the child process exception information, and restarting the target child process or controlling the target child process to roll back to the previous node according to the exception handling strategy.

[0104] It is understandable that the exception handling strategy may be to provide different exception handling strategies for different sub-process exception information, and the exception handling strategy may include restarting the sub-process or re-operating the sub-process, that is, returning to the last operation node.

[0105] It should be understood that controlling the target subprocess according to the exception handling strategy may be restarting the target subprocess or controlling the subprocess to re-execute the operation of calling the underlying program to be called by the application layer.

[0106] In a feasible implementation, step S30 may include steps A31 to A33:

[0107] Step A31, determining the abnormality type of the target sub-process according to the sub-process abnormality information, wherein the abnormality type includes process abnormality and operation abnormality.

[0108] It is understandable that the abnormal state of the target sub-process obtained according to the sub-process abnormal information can be to determine whether the target sub-process has crashed or is unresponsive, and the abnormal state is determined according to the reaction of the target sub-process. Specifically, a signal can be sent to the main process, and if the sub-process feeds back the signal, there is a response; the sub-process running log can be checked to see if it is normal to determine whether the sub-process has crashed.

[0109] It should be noted that the abnormal state can include process abnormality and operation abnormality, wherein the process abnormality can be understood as the crash of the sub-process; the operation abnormality can be understood as the application layer calling the underlying program according to the sub-process, but the sub-process does not respond.

[0110] It should be understood that different abnormal states may correspond to abnormal situations of different degrees, and the processing strategies for abnormal situations of different degrees are different.

[0111] Step A32, when the abnormal state is a process abnormality, restarting the target sub-process is used as an exception handling strategy.

[0112] It should be noted that when the abnormal state is a process abnormality, the target sub-process is controlled according to the process restart strategy to ensure the normal communication of the middleware, including: when the abnormal state is a process abnormality, obtaining the current progress of the target sub-process, and using the current progress as a reference state; initializing the target sub-process to obtain an initialized target sub-process; adjusting the target sub-process to the reference state, and completing the restart of the target sub-process.

[0113] It should be noted that initialization refers to the process of preparing the operating environment for a module, process or system. Initialization usually includes allocating resources, setting the initial state, loading necessary data or configuration, etc. to ensure that the module or process can run normally.

[0114] It is understandable that the current progress of the target subprocess can be obtained by calling a function to view the real-time progress of the target subprocess, that is, it can be understood as the step at which the calling program of the subprocess proceeds.

[0115] Among them, it can be understood that the current progress of the target sub-process can be the progress of the application layer calling the underlying program through the target sub-process, and the reference state can be the state of the target sub-process at the current progress, such as volume value, screen image frame, etc. Based on the current progress, if the target sub-process is restarted, the progress can be directly adjusted to ensure the consistency of the previous and subsequent progress.

[0116] Step A33, when the abnormal state is an operation abnormality, controlling the target child process to roll back to the previous node as an exception handling strategy.

[0117] It is understandable that rolling back to the previous node may be a repeated operation, that is, when the previous node controls the child process connection interface but there is no response, the operation is called repeatedly.

[0118] It should be emphasized that if the previous node is other operations, then the other operations are re-executed.

[0119] It is understandable that re-executing the calling operation of the application layer can avoid abnormal operation of the target sub-process caused by jamming.

[0120] In this implementation, different sub-process exception handling strategies are targeted according to different exception states of the sub-processes, so as to handle the exception of a single sub-process and ensure the normal communication of the middleware.

[0121] The above are only feasible implementations of step S30 provided in this embodiment, and this embodiment does not specifically limit the specific implementation of step S30.

[0122] This embodiment provides a middleware communication method, which ensures that each sub-thread is independent of each other by setting a main thread and multiple sub-threads in the middle layer, and directly communicating with the application layer based on the sub-threads to call the underlying program, and at the same time setting sub-thread self-checking and main thread supervision exception supervision, so as to timely discover communication anomalies of sub-threads, control single sub-thread problems, and do not affect the use of other sub-threads, effectively avoiding the problem that a single interface communication anomaly causes the entire middleware process to crash.

[0123] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can be referred to the above introduction, and will not be repeated in the following. Figure 8 , step S20 includes steps S21-S22:

[0124] Step S21, when the application layer calls the underlying program through the target sub-process, the sub-process exception signal thrown by the sub-process is captured through the sub-process exception handling mechanism, and the sub-process exception signal and the preset exception signal-fault list are combined to obtain the reported exception information. The sub-process exception signal is generated and thrown when the sub-process detects a preset exception trigger signal.

[0125] It is understandable that the abnormal state can be based on the comparison of the standard state of each sub-process and the current state of each sub-process, or it can be understood as a data comparison, or whether the log reports an error. If the sub-process state is different from the data in the normal state, or there is a log error, it can be understood that the sub-process is in an abnormal state.

[0126] It should be noted that the exception handling mechanism of the child process captures the abnormal state of the child process. The child process can perform exception detection on itself to see whether there is an error in the child process running program. When each child process runs internally, it uses the exception handling mechanism (try-catch block) to capture its own exceptions. When the child process detects error data or other fault errors, it will generate an exception event or notification and send it to the main process.

[0127] It should be emphasized that the child process will send the reported exception information to the main process, and this notification can be achieved through the event bus, message queue or directly calling the interface of the main process.

[0128] In a feasible implementation, step S21 may include steps A211 to A213:

[0129] Step A211, capturing the sub-process exception signal thrown by the sub-process through the sub-process exception handling mechanism.

[0130] It should be emphasized that the types of child process exceptions can include: Null Pointer Exception: Attempt to access a member of a null object. Example: Call a method of an uninitialized object, such as object.method(), where object is null. Index Out of Bounds Exception: Index out of range when accessing an array or list. Example: Access the 10th element of the array arr, but the array length is only 5. Input / Output Exception (I / O Exception): File Not FoundException: Attempt to open a file that does not exist. Example: Attempt to read a file with the path / path / to / nonexistent / file.txt. IOException: An error occurred while reading or writing a file. Example: Attempt to read data from a stream when the network connection is interrupted. Network Exception: SocketException: The network connection failed or was interrupted. Example: The client tried to send data after the server closed the connection. TimeoutException: The network request timed out. Example: No server response was received within the specified time. Database Exception: SQLException: Database access error. Example: Attempt to insert a duplicate primary key value resulting in a unique constraint violation. ConnectionException: Unable to connect to the database. Examples: Database server unavailable or network misconfiguration, etc.

[0131] It should be noted that the main process handles exceptions: the main process acts as an observer and listens to exception notifications from the child process. Once an exception notification is received, the main process performs the following operations: Logging: Records detailed information about the exception for subsequent analysis.

[0132] It should be noted that the stack trace shows all function calls from the start of program execution to the time when the exception occurs, so that you can understand how the program reached the state that caused the exception. The stack trace usually includes the location of each function call (file name, line number) and the parameter values ​​​​passed to these functions. Context information may include environment variables, configuration settings, logging, memory dumps, or other related information, which can help you gain a deeper understanding of the conditions when the exception occurred.

[0133] Step A212, matching the subprocess exception signal with the exception signal in the preset exception signal-fault list to obtain the exception type, error message, stack trace and context information.

[0134] It is understandable that the main process determines the abnormal state of the child process based on the exception type and error message fed back by the child process, the stack trace results and the context information. If it is determined that the child process is abnormal based on the exception type, error message, stack trace results and context information, the child process is considered to be in an abnormal state.

[0135] It should be noted that the preset exception signal-fault list may be a list of exception causes represented by different signals and corresponding exception types, error messages, stack traces, and context information that are predetermined.

[0136] Step A213: Use the exception type, the error message, the stack trace and the context information as reported exception information.

[0137] It should be noted that after determining the abnormal state of the sub-process, the main process will update the state of the sub-process on the user interface or in the system display to reflect the abnormal situation.

[0138] Furthermore, the main process decides whether to restart the child process based on the severity and type of the exception.

[0139] In this implementation, logs and process status of sub-processes are generated through abnormal information of sub-processes, which facilitates statistical analysis and feedback of abnormal status of each sub-process, thereby optimizing sub-process abnormalities.

[0140] The above are only feasible implementations of step S20 provided in this embodiment, and this embodiment does not specifically limit the specific implementation of step S20.

[0141] Step S22, in response to the sub-process detection signal, calling the heartbeat signal, resource usage and response time of the target sub-process, when the heartbeat signal, resource usage and response time are inconsistent with the standard state of the target sub-process, obtaining monitoring exception information based on the heartbeat signal, resource usage and response time, the standard state includes a standard heartbeat signal, resource usage standard and a standard response time.

[0142] It should be noted that the main process regularly or continuously monitors the status of the child process and detects anomalies by checking indicators such as heartbeat signals, resource usage, and response time.

[0143] It is understandable that the monitoring exception information is generated based on the heartbeat signal, resource usage and response time. If the main process detects that the child process is not responding, resource usage is abnormal or other abnormal behavior, it can be considered that the child process may have an abnormality, and the monitoring exception information is generated based on the heartbeat signal, resource usage and response time when the abnormality occurs.

[0144] It should be noted that in TV, the initialization of the main process and the initialization of the subprocess are two different stages, each with different responsibilities. The main process is responsible for allocating and initializing system-level resources, such as memory, network connections, file systems, etc. These resources are required for all subprocesses to run. Each subprocess is allocated specific resources based on its functional requirements. For example, the Media subprocess needs to initialize the relevant interfaces for media playback.

[0145] It should be noted that in this embodiment, an observer and an observed mechanism are set according to a single main process and multiple sub-processes. Based on this mechanism, the sub-process self-checks and reports exceptions: used to capture and handle known exceptions within the sub-process. The main process actively discovers: used to detect exceptions or faults that the sub-process may not report. Through this combination, exceptions can be monitored and handled more comprehensively to ensure the stability and reliability of the system.

[0146] It should be noted that the child process uses the exception handling mechanism (try-catch block) to capture its own exceptions during operation. Once an exception is captured, the child process will actively generate an exception event or notification and report it to the main process.

[0147] In the specific implementation, each sub-process runs independently and is responsible for a specific functional module (such as AQ, PQ, Media, etc.). In this way, even if an exception occurs in a sub-process, it will not affect the operation of other sub-processes. The main process monitors the status of the sub-process. Once an exception is detected (such as no response, crash), the sub-process can be restarted. Based on the above mechanism, the protection process of the main process for the sub-process can refer to Fig. 9 In the figure, the application layer calls the child process (Observerd) fun interface. When an exception occurs and causes the child process to crash, the main process (Observerd) intents the child process and controls the child process to restart.

[0148] It should be emphasized that when a child process needs to be reinitialized, it may affect the currently executing application. Here are some handling strategies:

[0149] 1) State preservation and restoration: Save state: Save the current application state (such as playback position, volume setting, etc.) before reinitialization.

[0150] 2) Restore state: After initialization is complete, restore the application's state so that the user can continue the previous operation.

[0151] 3) User Notification: Notify the user: When necessary, notify the user through the user interface that the current operation may be interrupted, and inform the user after it is restored.

[0152] 4) Minimize interruptions: Fast restart: Optimize the initialization process to minimize the restart time and reduce the impact on user experience. Background processing: When possible, the initialization process is performed in the background to reduce interference with foreground applications.

[0153] 5) Redundancy mechanism: Redundant process: In critical tasks, redundant processes are used to take over tasks to ensure that when one sub-process is restarted, another process can continue to provide services.

[0154] This embodiment provides a middleware communication method, which preliminarily determines the abnormal state of the target sub-process through the abnormal information of the target sub-process fed back by the sub-process or the main process, and then applies a response strategy according to the abnormal state, and restarts the target sub-process or repeats the operation according to different abnormal states. It can be based on a structure of a main process and multiple sub-processes. When an exception occurs in a single sub-process, exception handling is performed on the single sub-process, ensuring that the call of the target sub-process does not affect the call of other sub-processes by the application layer, and avoiding the crash of the entire middleware process due to a single interface communication exception.

[0155] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the middleware communication method of the present application. More simple transformations based on this technical concept are all within the scope of protection of the present application.

[0156] This application also provides a middleware communication device, please refer to Fig.10 , the middleware communication device comprises:

[0157] A signal acquisition module 10, used to acquire a middleware calling signal, and identify a target sub-process among multiple sub-processes according to the middleware calling signal;

[0158] The signal acquisition module 10 is further used to obtain the sub-process exception information of the target sub-process when the application layer calls the underlying program through the target sub-process, wherein the sub-process exception information includes reporting exception information and / or monitoring exception information, wherein the reporting exception information is obtained by the self-check of the target sub-process, and the monitoring exception information is obtained by the main process monitoring the target sub-process;

[0159] The sub-process control module 20 is used to obtain an exception handling strategy according to the sub-process exception information, and control the target sub-process according to the exception handling strategy to ensure normal communication of the middleware.

[0160] The middleware communication device provided by the present application adopts the middleware communication method in the above embodiment, which can solve the technical problem that the middleware process of many product software systems in the current market is single-channel communication, and a single interface communication anomaly is prone to cause the entire middleware process to crash. Compared with the prior art, the beneficial effects of the middleware communication device provided by the present application are the same as the beneficial effects of the middleware communication method provided by the above embodiment, and other technical features in the middleware communication device are the same as the features disclosed in the above embodiment method, which will not be repeated here.

[0161] In one embodiment, the signal acquisition module 10 is further used to capture the abnormal state of the sub-process through the exception handling mechanism of the sub-process when the application layer calls the underlying program through the target sub-process, and generate reporting abnormal information according to the abnormal state;

[0162] A detection signal is generated by the main process, a heartbeat signal, resource usage and response time of the sub-process are detected according to the detection signal, and monitoring abnormality information is generated according to the heartbeat signal, resource usage and response time.

[0163] In one embodiment, the signal acquisition module 10 is further used to obtain the exception type, error message, stack trace and context information based on the target child process according to the reported exception information;

[0164] Obtaining an exception state based on the main process according to the exception type, the error message, the stack trace, and the context information, and generating an exception log according to the exception type, the error message, the stack trace, the context information, and the exception state;

[0165] The process state of the target subprocess is updated according to the abnormal state.

[0166] In one embodiment, the sub-process control module 20 is further used to obtain the abnormal state of the target sub-process according to the sub-process abnormal information, and obtain an abnormality handling strategy according to the abnormal state, wherein the abnormality handling strategy includes a repeated operation strategy and a process restart strategy;

[0167] When the abnormal state is a process abnormality, controlling the target subprocess according to the process restart strategy to ensure normal communication of the middleware;

[0168] When the abnormal state is an operation abnormality, the target subprocess is controlled according to the repeated operation strategy to ensure normal communication of the middleware.

[0169] In one embodiment, the sub-process control module 20 is further configured to obtain the current progress of the target sub-process when the abnormal state is a process abnormality, and use the current progress as a reference state;

[0170] Initializing the target subprocess to obtain an initialized target subprocess;

[0171] The initialized target subprocess is adjusted based on the reference state to ensure normal communication of the middleware.

[0172] In one embodiment, the signal acquisition module 10 is further used to acquire a middleware calling signal, and obtain a target calling function based on the middleware calling signal;

[0173] The target calling function is matched with the functions of each sub-process to obtain the target sub-process.

[0174] In one embodiment, the signal acquisition module 10 is further used to acquire a power-on startup signal, initialize the main process based on the power-on startup signal, and generate a sub-process initialization signal;

[0175] Each sub-process is initialized according to the sub-process initialization signal.

[0176] The present application provides a middleware communication device, which includes: at least one processor; and a memory connected to the at least one processor in communication; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the middleware communication method in the above-mentioned embodiment one.

[0177] Reference below Fig.11 , which shows a schematic diagram of the structure of a middleware communication device suitable for implementing the embodiments of the present application. The middleware communication device in the embodiments of the present application may include but is not limited to mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Fig.11 The middleware communication device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0178] like Fig.11As shown, the middleware communication device may include a processing device 1001 (e.g., a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM: Read Only Memory) 1002 or a program loaded from a storage device 1003 to a random access memory (RAM: Random Access Memory) 1004. In RAM1004, various programs and data required for the operation of the xxx device are also stored. The processing device 1001, ROM1002, and RAM1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems can be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touch pad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD: Liquid Crystal Display), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the middleware communication device to communicate with other devices wirelessly or by wire to exchange data. Although the figure shows a middleware communication device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented or provided instead.

[0179] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0180] The middleware communication device provided by the present application adopts the middleware communication method in the above embodiment, which can solve the technical problem that the middleware process of many product software systems in the current market is single-channel communication, and a single interface communication anomaly is prone to cause the entire middleware process to crash. Compared with the prior art, the beneficial effects of the middleware communication device provided by the present application are the same as the beneficial effects of the middleware communication method provided by the above embodiment, and other technical features in the middleware communication device are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

[0181] It should be understood that the various parts disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0182] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0183] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, and the computer-readable program instructions are used to execute the middleware communication method in the above-mentioned embodiment.

[0184] The computer-readable storage medium provided in the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination of the above.

[0185] The computer-readable storage medium may be included in the middleware communication device; or may exist independently without being assembled into the middleware communication device.

[0186] The computer-readable storage medium carries one or more programs. When the one or more programs are executed by the middleware communication device, the middleware communication device: obtains a middleware call signal, and identifies a target sub-process among multiple sub-processes according to the middleware call signal; obtains sub-process exception information of the target sub-process when the application layer calls the underlying program through the target sub-process, the sub-process exception information includes reporting exception information and / or monitoring exception information, the reporting exception information is obtained through self-checking of the target sub-process, and the monitoring exception information is obtained through monitoring the target sub-process by the main process; obtains an exception handling strategy according to the sub-process exception information, and controls the target sub-process according to the exception handling strategy to ensure normal communication of the middleware.

[0187] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0188] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0189] The modules involved in the embodiments described in this application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0190] The readable storage medium provided by the present application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned middleware communication method, and can solve the technical problem that the middleware process of many product software systems in the current market is single-channel communication, and it is easy to have a single interface communication anomaly that causes the entire middleware process to crash. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided by the present application are the same as the beneficial effects of the middleware communication method provided by the above-mentioned embodiment, and will not be repeated here.

[0191] The present application also provides a computer program product, including a computer program, wherein when the computer program is executed by a processor, the steps of the middleware communication method as described above are implemented.

[0192] The computer program product provided by the present application can solve the technical problem that the middleware process of many product software systems in the current market is a single-channel communication, and a single interface communication anomaly is prone to cause the entire middleware process to crash. Compared with the prior art, the beneficial effects of the computer program product provided by the present application are the same as the beneficial effects of the middleware communication method provided by the above embodiment, and will not be repeated here.

[0193] The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect applications in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A middleware communication method, characterized in that: The middleware communication method is applied to the middleware in the middleware communication system, the middleware communication system includes an application layer, middleware and bottom layer program, and the middleware includes multiple sub-processes; The middleware communication method comprises: Obtaining a middleware calling signal, and determining a target subprocess from the plurality of subprocesses according to a calling function of the middleware calling signal and a calling interface of each subprocess; When the application layer calls the underlying program through the target sub-process, sub-process exception information is obtained, wherein the sub-process exception information includes reporting exception information obtained by capturing an exception thrown by the target sub-process and / or monitoring exception information obtained by analyzing a running log of the target sub-process; An exception handling strategy is obtained according to the child process exception information, and the target child process is restarted or controlled to roll back to a previous node according to the exception handling strategy.

2. The middleware communication method according to claim 1, characterized in that: When the application layer calls the underlying program through the target sub-process, sub-process exception information is obtained, where the sub-process exception information includes reported exception information obtained by capturing an exception thrown by the target sub-process, and / or monitoring exception information obtained by analyzing the running log of the target sub-process, including: When the application layer calls the underlying program through the target sub-process, the sub-process exception signal thrown by the sub-process is captured through the sub-process exception handling mechanism, and the sub-process exception signal and the preset exception signal-fault list are used to obtain the reported exception information, wherein the sub-process exception signal is generated and thrown when the sub-process detects a preset exception trigger signal; In response to a sub-process detection signal, the heartbeat signal, resource usage and response time of the target sub-process are called. When the heartbeat signal, resource usage and response time are inconsistent with the standard state of the target sub-process, monitoring exception information is obtained based on the heartbeat signal, resource usage and response time. The standard state includes a standard heartbeat signal, a resource usage standard and a standard response time.

3. The middleware communication method according to claim 2, characterized in that: The sub-process exception signal thrown by the sub-process is captured by the sub-process exception handling mechanism, and the sub-process exception signal and the preset exception signal-fault list are used to obtain the reported exception information, including: Capture the subprocess exception signal thrown by the subprocess through the subprocess exception handling mechanism; Match the subprocess exception signal with the exception signal in the preset exception signal-fault list to obtain the exception type, error message, stack trace and context information; The exception type, the error message, the stack trace and the context information are used as reported exception information.

4. The middleware communication method according to claim 1, characterized in that: The obtaining an exception handling strategy according to the child process exception information, and restarting the target child process or controlling the target child process to roll back to the previous node according to the exception handling strategy, includes: Determine the abnormality type of the target sub-process according to the sub-process abnormality information, wherein the abnormality type includes process abnormality and operation abnormality; When the abnormal state is a process abnormality, restarting the target subprocess is used as an abnormality handling strategy; When the abnormal state is an operation abnormality, the target subprocess is controlled to roll back to the previous node as an exception handling strategy.

5. The middleware communication method according to claim 4, characterized in that: When the abnormal state is a process abnormality, restarting the target subprocess as an abnormality handling strategy includes: When the abnormal state is a process abnormality, obtaining the current progress of the target subprocess and using the current progress as a reference state; Initializing the target subprocess to obtain an initialized target subprocess; The target subprocess is adjusted to the reference state, and the target subprocess is restarted.

6. The middleware communication method according to claim 1, characterized in that: The obtaining of the middleware calling signal and determining the target sub-process from the plurality of sub-processes according to the calling function of the middleware calling signal and the calling interface of each sub-process include: Get the middleware call signal; Matching the calling function of the middleware calling signal with the calling functions of each sub-process to obtain a successfully matched sub-process; The subprocess of the successfully matched subprocess is taken as the target subprocess.

7. The middleware communication method according to claim 1, characterized in that: When the application layer calls the underlying program through the sub-process, before obtaining the reported exception information and monitoring the exception information, it also includes: Obtaining a power-on start signal, initializing the main process based on the power-on start signal and generating a sub-process initialization signal; Each sub-process is initialized according to the sub-process initialization signal.

8. A middleware communication device, characterized in that: The middleware communication device comprises: A signal acquisition module, used to acquire a middleware calling signal, and determine a target subprocess from the multiple subprocesses according to a calling function of the middleware calling signal and a calling interface of each subprocess; The signal acquisition module is further used to obtain sub-process exception information when the application layer calls the underlying program through the target sub-process, wherein the sub-process exception information includes reporting exception information obtained by capturing an exception thrown by the target sub-process, and / or monitoring exception information obtained by analyzing the operation log of the target sub-process; The sub-process control module is used to obtain an exception handling strategy according to the sub-process exception information, and restart the target sub-process according to the exception handling strategy or control the target sub-process to roll back to the previous node.

9. A middleware communication device, characterized in that: The device comprises: a memory, a processor, and a middleware communication program stored in the memory and executable on the processor, wherein the middleware communication program is configured to implement the middleware communication method according to any one of claims 1 to 7.

10. A storage medium, characterized in that: The storage medium stores a middleware communication program, and when the middleware communication program is executed by the processor, the middleware communication method according to any one of claims 1 to 7 is implemented.

Images