Method for managing connection loss for distributed system

Abstract

To provide a method for managing a connection loss for a distributed system.SOLUTION: In a distributed system 1, a method includes deploying a support module on two sender runtimes 2, on one receiver runtime 3, and on one orchestrator 4. of the distributed system, the support module being configured to provide transmission of a signal on an additional communication channel, the orchestrator being configured to manage regular communication between the sender runtimes and the receiver runtime. The method includes the steps of: analyzing the additional communication channel between the sender runtimes and the orchestrator to detect a connection loss of the sender runtimes on the basis of detection of the transmitted signal on the additional communication channel; and initiating a countermeasure when the connection loss is detected. The countermeasure comprises stopping the regular communication between the sender runtimes with the detected connection loss and the receiver runtime by means of the support module.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to a method for managing connection losses for a distributed system, and further to a computer program, a device and a storage medium for this purpose. [Background technology]

[0002] Over the last decade, the availability and capacity of cloud and edge resources has increased dramatically. This trend can be primarily driven by several benefits of monolithic applications across many (dynamically changing) heterogeneous resource nodes, such as improved resource utilization, fault tolerance, and application availability.

[0003] Although cloud servers can provide enormous computing power and nearly infinite elasticity, the transmission of data between devices and the cloud can require relatively long and highly variable transmission times. That is, the transmission times to and from the cloud servers can have large delays and significant jitter. As a result, application distribution efforts have initially focused primarily on non-timing-critical applications, e.g., from fields such as enterprise, scientific computing, or machine learning.

[0004] Meanwhile, real-time and safety-critical CPS (Cyber-Physical Systems) were used especially as monoliths, where the processing part (responsible for control / decision making) and the sensor and actuator parts of the application are all deployed on the same device in the field. But now, due to a larger decentralization of edge resources and high bandwidth communication, it may be possible to achieve high speed communication (especially with runtimes in the millisecond range) between field devices and high-performance edge nodes, so that the processing part of the CPS application can be offloaded to the higher performance computing nodes (thereby effectively utilizing the advantages of the decentralization mentioned above), while the field devices can manage only the sensor and actuator functions.

[0005] Use cases in which timing-critical CPS applications are distributed across a network of edge resources have been used successfully in the laboratory to demonstrate the benefits of distribution, but the inherent unreliability of communication networks in the field, where individual network nodes may be susceptible to intermittent disruptions, may still pose a significant challenge for real-world distributed deployments of real-time critical CPS systems, which may be particularly sensitive to packet loss caused by disconnections.

[0006] Cloud orchestration frameworks, such as Kubernetes, can use more traditional approaches to fault tolerance, since they can use popular protocols with very strong properties, such as Paxos or Raft. However, this design decision can introduce a large overhead in terms of messages and the number of replicas required. For example, etcd, the highly durable distributed key-value store in Kubernetes used, among other things, to maintain the cluster state, can have large network requirements, e.g. 1GbE in a typical deployment. While this may not be surprising, since cloud orchestration is designed for data centers with large network and computational power, such requirements may not be well suited for resource-poor distributed embedded systems. These protocols can be overkill for highly synchronized systems, such as industrial automation systems or automotive controls.

[0007] Existing middleware solutions lack, among other things, the ability to detect resource disconnections fast enough to achieve failover within milliseconds and to manage new connections for resources in a manner that is transparent to applications. Existing approaches may target primarily data center connectivity failures and may have significant network and data processing requirements. Some of the existing efforts to enable faster failover times may rely on additional mechanisms provided by (software-defined) networks. Summary of the Invention [Means for solving the problem]

[0008] According to aspects of the present invention there is provided a method comprising the features of claim 1, a computer program comprising the features of claim 8, a data processing device comprising the features of claim 9 and a computer-readable storage medium comprising the features of claim 10. Further features and details of the invention are disclosed in the respective dependent claims, the description and the drawings. Features and details mentioned in the context of the method according to the invention also correspond to the computer program according to the invention, the data processing device according to the invention and the computer-readable storage medium according to the invention and vice versa.

[0009] According to one aspect of the present invention, there is provided a method for managing connection loss for a distribution system, the method comprising: - deploying at least one support module on at least two sender runtimes, at least one receiver runtime, and at least one orchestrator of the distributed system, where the at least one support module is designed to provide for the transmission of signals on an additional communication channel, and the orchestrator is designed to manage periodic communication between the at least two sender runtimes and the at least one receiver runtime; - analyzing additional communication channels between the at least two sender runtimes and the orchestrator and detecting a connection loss of at least one of the at least two sender runtimes based on detecting a transmitted signal on the additional communication channel, respectively; - initiating at least one measure when a connection loss is detected, the at least one measure including stopping, by at least one support module, regular communication between at least one of the at least two sender runtimes where the connection loss was detected and at least one receiver runtime in order to manage the connection loss in the distributed system; Includes.

[0010] The distributed system may be a distributed information technology system, such as a cloud system. The sender runtime may be a runtime that includes or hosts the sender module. The receiver runtime may be a runtime that includes or hosts the receiver module. In one example, an application may be executed on the receiver runtime, which requires data from the sender runtime, for which periodic communication between the sender runtime and the receiver runtime is provided. The orchestrator may be a decision-making entity that may have a global view of the distributed system and may be able to deploy and stop modules on the runtime again and control the communication behavior of the modules. The analysis of the additional communication channel may include periodic verification by detection to verify whether a transmitted signal is present or has been present within a defined period of time. The transmitted signal may be a digital signal, such as a string or a bit sequence. When a connection loss is detected, the stop of the periodic communication may be initiated by at least one of the at least two sender runtimes. Briefly, in one example, the support module of the sender runtime may detect that no signal has been transmitted by the support module of the orchestrator for a predetermined period of time, which may cause the sender runtime to stop the periodic communication. The additional communication channel by the at least one support module may be advantageous insofar as it can be dedicated to detecting a connection loss and insofar as at least one of the at least two sender runtimes can detect the connection loss and thereby stop the regular communication, which advantageously prevents the receiver runtime from being overflowed with data from the sender runtime when the connection was lost after reconnection.

[0011] This method, - initiating, at intervals, the transmission of signals on the additional communication channel by at least one support module; - analyzing the presence of a transmitted signal to detect a connection loss, the presence of the transmitted signal being analyzed by at least two sender runtimes and / or an orchestrator; It is possible for the method to further include:

[0012] A signal can be transmitted and detected by at least one support module. In one example, a support module is provided in a sender runtime and can transmit a signal to another support module provided in an orchestrator, which can then analyze the presence of the transmitted signal and thereby detect a connection loss, or vice versa. The term "presence" can refer to the presence of a transmitted signal at a given time, or the presence or detection of a transmitted signal during a given period of time.

[0013] Furthermore, this method - defining intervals in which the signals are transmitted, the intervals being defined manually or automatically, preferably according to at least one requirement; - defining a period of time for a transmitted signal before a connection loss is detected; It is also possible to further include at least one of the following:

[0014] Being able to define the intervals can be advantageous insofar as it guarantees greater flexibility. For example, for critical applications that must detect connection loss quickly, the interval can be defined very short, for example 10 milliseconds. For less critical applications and to save data processing or network capacity, the interval can be defined longer, for example 1 second. It is also possible to define different intervals for different signal transmission directions. In one example, the signal transmitted from the orchestrator to one of the at least two sender runtimes is different from the interval from one of the at least two sender runtimes to the orchestrator. Different intervals can advantageously make it possible to achieve a compromise between response time and communication overhead of the signal. This definition can also be done automatically and dynamically, for example allowing slowing down in scenarios where the available network bandwidth is reduced due to connection or node failure. Thus, at least one requirement can be, for example, how time-critical the application is or how much bandwidth or data processing capacity is provided. In one alternative, the period for the transmitted signal before a connection loss is detected can be a multiple of the interval in which the signal is transmitted. For example, if the interval at which the signal is transmitted is 10 ms, the period may be 30 ms. Thus, when there is no signal after 30 ms, a connection loss may be detected in this case. It is also possible to analyze the pattern of the transmitted signal to detect a connection loss. In one example, a connection loss is detected when two signals are not detected consecutively, or when m out of k signals are not detected.

[0015] In another example, three types of support modules, namely: an emitter for transmitting a signal; a detector for detecting a signal transmitted by the emitter; - a mute switch that stops regular communication between at least one of the at least two sender runtimes and at least one receiver runtime; At least one of them is deployed.

[0016] A mute switch can be deployed on at least two sender runtimes to stop the regular communication. This can be advantageous because the at least two sender runtimes can then stop the regular communication without the need for intervention by the orchestrator. In one example, emitters and detectors can be deployed on at least two sender runtimes, at least one receiver runtime, and at least one orchestrator, respectively, so that additional communication channels can be analyzed, for example, with respect to a respective emitter on one of the at least two sender runtimes and a respective detector on, for example, the at least one orchestrator.

[0017] In another example, the at least one measure further includes enabling temporary regular communication between at least one of the at least two sender runtimes where a connection loss is not detected and at least one receiver runtime. In other words, the regular communication with at least one of the at least two sender runtimes where a connection loss is not detected can be temporarily replaced by temporary regular communication with another of the at least two sender runtimes where a connection loss is not detected, preferably after which at least one of the at least two sender runtimes where a connection loss is detected is reconnected to the at least one receiver runtime. Thus, as soon as the connection is reestablished, the regular communication can be re-enabled and the temporary regular communication can be disabled.

[0018] Furthermore, it is also possible for the orchestrator to perform the enabling of temporary periodic communication between at least one of the at least two sender runtimes where no connection loss is detected and at least one receiver runtime, which may be advantageous since a global view of all sender and receiver runtimes that may be present in the distributed system is available to the orchestrator, in particular further regarding the possibility of connection loss for each runtime.

[0019] This method is - analyzing an additional communication channel between the at least two sender runtimes and detecting a connection loss of at least one of the at least two sender runtimes based on a transmission of a signal between the at least two sender runtimes; It may further include:

[0020] This can be advantageous because the sender runtimes in this case each detect a possible connection loss independently and without an orchestrator. When a connection loss is detected in one of the sender runtimes, at least one other sender runtime can contemplate starting to provide periodic communication with at least one receiver runtime.

[0021] In another aspect of the invention, a computer program, in particular a computer program product, can be provided which comprises instructions which cause a computer to carry out the steps of the method according to the invention when the computer program is executed by a computer. The computer program according to the invention can therefore have the same advantages as those detailed with reference to the method according to the invention.

[0022] In another aspect of the invention, a data processing device designed to implement the method according to the invention can be provided. As a device, for example, a computer can be provided that executes the computer program according to the invention. The computer can include at least one processor that can be used to execute the computer program. It is also possible to provide a non-volatile data memory in which the computer program can be stored and from which the processor can read and execute the computer program.

[0023] According to another aspect of the invention, a computer-readable storage medium may be provided that includes a computer program according to the invention and / or instructions that, when executed by a computer, cause a computer to perform the steps of a method according to the invention. The storage medium may be formed as a data storage device, such as, for example, a hard disk, and / or a non-volatile memory, and / or a memory card, and / or a solid-state drive. The storage medium may, for example, be integrated into the computer.

[0024] Furthermore, the methods according to the present invention may be implemented as computer-implemented methods. Further advantages, features and details of the invention will become apparent from the following description, in which an embodiment of the invention is described in detail with reference to the drawings. In this context, the features mentioned in the claims and in this specification may, each individually or in any combination, be an essential part of the invention. [Brief description of the drawings]

[0025] [Figure 1] 1 illustrates a method, a computer program, a storage medium, and a device according to an embodiment of the present invention. [Diagram 2] FIG. 1 illustrates a distributed system according to the prior art. [Diagram 3] FIG. 1 illustrates a distributed system according to the prior art. [Figure 4]FIG. 1 illustrates a distributed system according to the prior art. [Diagram 5] FIG. 1 illustrates a distributed system according to an embodiment of the present invention. [Figure 6] FIG. 1 illustrates a distributed system according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0026] FIG. 1 shows a computer program 20, a storage medium 15 and a device 10 according to an embodiment of the invention. Fig. 1 further illustrates a method 100 for managing a connection loss for a distributed system 1 according to an embodiment of the present invention. In a first step 101, at least one support module 5 can be deployed on at least two sender runtimes 2, at least one receiver runtime 3 and at least one orchestrator 4 of the distributed system 1. The at least one support module 5 is preferably designed to provide for the transmission of signals on an additional communication channel. The orchestrator 4 is designed, among other things, to manage regular communication between the at least two sender runtimes 2 and the at least one receiver runtime 3. In a second step 102, the additional communication channel between the at least two sender runtimes 2 and the orchestrator 4, respectively, can be analyzed to detect a connection loss of at least one of the at least two sender runtimes 2 based on the detection of a transmitted signal on the additional communication channel. In a third step 103, at least one measure can be initiated in case of a connection loss being detected. At least one countermeasure may include stopping, by at least one support module 5, regular communication between at least one of the at least two sending runtimes 2 where a connection loss is detected and at least one receiving runtime 3 in order to manage a connection loss in the distributed system 1.

[0027] The invention focuses on failover mechanisms, especially with regard to intermittent connection failures in a distributed system 1. It can be assumed that the system comprises several distributed (computational) nodes that can be connected via a communication network, on each of which a so-called runtime can be deployed. The runtime can be a program that can access the resources of the node on which it is deployed and launch executable files, called modules. In addition to launching modules and monitoring their execution, the runtime can also manage the communication between modules. To transmit a message generated by a sending module, the runtime hosting that module can intercept the message and then inject it into the communication network to be transmitted to the runtime hosting the receiving module. The runtime hosting the receiving module can receive the message and provide it to the receiving module.

[0028] An application provided as multiple deployable modules can be deployed by an orchestrator 4. The orchestrator 4 may be a decision-making entity having access to a global view of the system and may be able to deploy and undeploy modules at runtime and control the communication behavior of modules. In particular, the orchestrator 4 may "mute" a module by configuring its runtime host to no longer transmit messages it generates. The orchestrator 4 may determine the mapping of modules at the runtime of the deployed application, monitor its execution, and activate failover mechanisms to protect the deployed application against dynamic failures (e.g. connection or node failures).

[0029] Figure 2 illustrates failure scenarios addressed by an embodiment of the invention. In a distributed system 1, which may include several runtimes 2, 3 and which may be managed by an orchestrator 4, an application may be deployed by distributing its modules to the available runtimes 2, 3. For the sake of clarity, this example uses a minimal application that includes, among other things, a sender module T, which may also be called speaker, that generates data, and a listener-receiver module L, which may also be called listener, that consumes that data. These modules may represent, for example, control tasks (speakers) that compute control signals, which are then sent to actuator tasks (listeners). The right part of this figure highlights, among other things, the disconnection vulnerability of this deployment: i.e. as soon as RT1 is disconnected, the listener may not be able to receive incoming data, which may lead to the application failing.

[0030] FIG. 3 illustrates how hot-standby deployment of task replicas can harden an application against run-time disconnections. As described above, the orchestrator 4 can selectively disable the communication capabilities of individual modules. This functionality can be used to deploy a “muted” replica of sender module T on RT3 as a “backup” for the “primary” sender module T on RT1 with which it is communicating. Since the orchestrator 4 can detect the disconnection (which can be difficult, as outlined below), it can respond by enabling the communication capabilities of the backup sender module T, which can then generate the necessary data for the receiver module L, so that the application may be unaffected by the disconnection and can continue its execution.

[0031] However, this scheme may not be sufficient to deal with the intermittent disconnection scenario, where RT1 reconnects to the network after being disconnected for a time interval, as shown in FIG. 4, which may be a very common failure in large networks. As soon as RT1 reconnects to the network, the receiving module L may start receiving duplicate messages, which may cause application failures when the application is not specifically written to be allowed to handle message duplication. Handling such duplication is a functionality that is usually missing in most applications. Note that the orchestrator 4's ability to mute and unmute the module again may not be sufficient to deal with this scenario. Until it is disconnected, the sender module T of RT1 acts as a failover primary device and can generate messages. During the time that RT1 is disconnected, the orchestrator 4 may not be able to mute the module, since it cannot communicate with RT1. Although the orchestrator 4 may be implemented to mute one of the sending modules T as soon as it detects a reconnection, it may not be possible to prevent the receiving module L from receiving duplicate messages over a certain time interval, which may have catastrophic consequences for the application.

[0032] In particular, the above description assumes that the orchestrator 4 can detect run-time disconnections fast enough to perform a failover, i.e., activation of a backup, before the application fails. For real-time-critical CPS applications, which may be particularly sensitive to packet loss, the complete middleware response chain, i.e. (a) detection of a disconnection, (b) decision-making to determine the response, and (c) implementation of the response, must be completed in a particularly short time interval (in the range of a few milliseconds), which requires, for example, a detection mechanism that can detect disconnections in even shorter times. Most mechanisms for detecting disconnections in a distributed system 1 can be based on some kind of periodic heartbeat, i.e., a scheme in which messages are periodically sent between a trusted and certain node (e.g., the node on which the orchestrator 4 is deployed) and the monitored node. As long as heartbeats are received regularly, the monitored node can be considered connected, while the absence of a heartbeat message can represent a disconnection. While most existing middleware and communication protocols come with built-in heartbeat functionality, it may typically not be possible to set a heartbeat period short enough to allow detection of disconnections fast enough to provide failover for CPS applications. The minimum configurable period may typically be around 1 second. One possible reason for this is that shortening the heartbeat period may increase the volume of messages sent over the network, to the point where interference / network load of these messages may affect deployed applications.

[0033] The present invention can provide such a failover mechanism. The present invention can be used to harden real-time critical applications against run-time disconnections due to intermittent network connection failures. The present invention may not require adaptation or special assumptions on the application, nor any failure detection or recovery mechanisms provided by the underlying communication protocol. The application may be treated as a black box and may be completely independent of its distributed deployment.

[0034] Compared to existing solutions, the present invention may provide at least the following advantages: Detection of disconnection and reconnection situations within milliseconds of their occurrence without having to rely on mechanisms provided by the underlying communication protocol. A mechanism for triggering low latency failover using hot standby operation. A mechanism for managing modules on a disconnected runtime during the time that the runtime is disconnected from the network. A mechanism for managing a previously disconnected runtime when it reconnects to the network. All of the above listed advantages may be provided in a manner that is completely transparent to the running application and may not require any adaptation of application code or behavior.

[0035] An object of the proposed invention may be to harden distributed real-time applications against intermittent disconnections. This mechanism may be based on the idea that in addition to application modules, the orchestrator 4 may also deploy so-called "sidecar" modules. A "sidecar" may be a special orchestration module that may be deployed on a runtime together with the modules of the application. Among other things, it may implement an error handling policy and (a) detect runtime disconnections, (b) manage and / or monitor the communication behavior of the application modules, (c) observe and / or manage the runtime even if it is disconnected from the network and thus from the orchestrator 4, (d) detect when the runtime reconnects to the network, and / or (e) cooperate with the orchestrator 4 to integrate the reconnected runtime back into the system. In the context of the present invention, the sidecar module may also be synonymously referred to as a support module 5. For this deployment, the orchestrator 4 may ensure that the selected deployment meets the resource requirements and real-time constraints of the application, taking into account the computational and network requirements of the application and the sidecar modules. This "sidecar" mechanism can enable very fast failover and does not need to rely on failure detection or response mechanisms provided by the underlying communication protocol.

[0036] Moreover, this mechanism may not require any adaptation of application code and may instead be used to "retrofit" error handling capabilities onto existing applications. Thus, by bringing orchestration closer to the processor, the proposed sidecar mechanism can extend the temporal and spatial locality of recovery logic in a distributed system 1.

[0037] In addition to the general mechanism of using sidecars, i.e., support modules 5, a scheme for managing disconnection-reconnection scenarios according to an embodiment of the present invention for orchestration tasks is described below. Among other things, the scheme is based on dynamically deployed support modules 5 for generating runtime heartbeats and managing communication behavior of application modules, whereby applications are transparently protected from (a) runtime disconnections due to (transient) connection failures and (b) potential failures caused by runtime reconnections of previously disconnected instances.

[0038] Figure 5 visually illustrates some possible components of the inventive approach to address intermittent disconnection scenarios. As explained in the previous section, this approach can be based on the use of sidecars, i.e. support modules 5. The scheme illustrated in Figure 5 uses, among others, three different kinds of support modules 5: (a) Emitters E, which, after deployment in the runtime, can emit or transmit signals or, more specifically, heartbeat messages, with a periodicity that can be set, preferably dynamically, by the orchestrator 4; (b) Detectors D, which can be responsible for listening to a specific heartbeat and detecting its absence, i.e. a disconnection, and triggering a disconnection response in the orchestrator 4 and / or other support modules 5; and (c) Mute Switches S, which, upon receiving a trigger signal from the Detector D, can be configured to disable the communication of other modules hosted by that runtime, where the mute switch is hosted. To ensure robustness against false positive results, it can be flexibly configured as to what specifically is meant as an absence of a heartbeat. An absence of a heartbeat may be, for example, missing two consecutive heartbeats or receiving fewer than m out of k heartbeats. As shown in FIG. 5, the orchestrator 4 may use an emitter E and detector D pair to (a) monitor the connection state of the runtime and (b) enable the runtime to detect when it is disconnected.

[0039] The implementation of the heartbeat mechanism by the sidecar or support module 5 may allow fine-grained control of the heartbeat period. That is, different heartbeat periods may be configured for different runtimes. Runtimes performing more important or more sensitive tasks may be designed to send heartbeats more frequently. Furthermore, different heartbeat directions may be configured. The period may be different for (a) heartbeats sent from the orchestrator 4 to the runtime and (b) heartbeats sent from the runtime to the orchestrator 4. This may allow a compromise between heartbeat response time and communication overhead to be achieved. The reconfiguration of the heartbeat period may even be dynamic, allowing for a gradual slowdown in scenarios where the available network bandwidth is reduced due to connection or node failure, for example.

[0040] The support modules 5 are preferably deployed by an orchestrator 4 that can utilize a global view of the system and can collectively consider the computational and network requirements of the application and the support modules 5. As shown on the right side of FIG. 5, the utilization of the support modules 5 not only allows a very fast detection of the disconnection, but also allows the orchestrator 4 to manage the runtime while it is disconnected. In the illustrated example, the detector D used in RT1 detects the disconnection among other things and (a) informs the emitter E to stop sending heartbeats and (b) informs the mute switch S to disable the communication capabilities of the application task T. As already mentioned, this response, which cannot be directly triggered by the orchestrator 4, which is now disconnected from RT1, can ensure that no messages (neither heartbeat messages nor application messages) are sent by RT1. The runtime can now therefore safely reconnect to the network without overflowing messages. Meanwhile, the detector D used in the node of orchestrator 4 can detect the disconnection of RT1 and trigger a response in orchestrator 4, in which (a) the communication function of the backup task on RT3 is enabled and it is set as primary, and (b) if RT3 is disconnected, the mute switch S for the sender module T on RT3 is used.

[0041] Finally, Fig. 6 illustrates a safe reconnection made possible, among other things, by the use of the support module 5. The sequence of events can be implemented as follows: (1) as soon as RT1 is reconnected to the network, its detector D can start receiving the heartbeats sent by emitter E on the node of orchestrator 4; (2) detector D can inform emitter E of the reconnection, which can resume sending heartbeats; (3) detector D on the node of orchestrator 4 responsible for RT1 can receive that heartbeat and inform orchestrator 4, which from this point on preferably reassumes control and management of RT1.

[0042] The overall process according to one embodiment is described below. In a normal operating mode, the orchestrator 4 and the runtime can exchange periodic heartbeats. After a disconnection, a detector D on the runtime can detect the absence of the orchestrator 4 heartbeat and can disable the runtime heartbeat and mute the application modules hosted there. When the detector D on the orchestrator 4 detects the absence of the runtime heartbeat, it preferably enables a failover by unmuting the backup sender module T. The orchestrator 4 can still send its heartbeat so that the detector D on the runtime can detect it after reconnection and can re-enable the emitter E on the runtime. The orchestrator 4 can be notified when its detector D receives the runtime heartbeat again and can reassume control over the runtime.

[0043] Since the use of sidecars can generally provide great flexibility for these and other failure / management scenarios, possible alternatives to the above scheme are described below. A possible alternative limitation would be, for example, to configure detector D to listen to application messages instead of generating additional heartbeats. For communication schemes where this is easily possible, such as PubSub, it is possible to reduce the network bandwidth overhead introduced by this mechanism. For example, when a motion control application is enhanced that includes a sensor and actuator module, detector D can be used on the runtime hosting the actuator module, where it can listen for periodic sensor signals, allowing fast disconnection failover when the runtime hosting the sensor module is disconnected, without any overhead in terms of network load.

[0044] In another alternative, a maximum absent time interval can be defined for an application module. In case of disconnection, for example a watchdog support module 5 on the middleware and the disconnected resource can monitor the time the resource has been disconnected. As soon as the absence time of the module is exceeded, the module can be (a) detached from the disconnected resource by the resource watchdog and (b) deployed again on the connected resource by the middleware watchdog.

[0045] Instead of muting the application module, in a further alternative, the recorder support module 5 can also record the messages of the application module during the disconnection time. Different schemes can be used for this, for example recording all messages and recording the last n messages. After reconnection, messages can be injected back into the network in a systematic manner coordinated with the middleware. This can be a further example regarding the functionality implemented on the disconnected runtime that can be made possible by the sidecar concept.

[0046] In another example, the presented scheme can also be extended for use with other failover mechanisms, such as cold standby, or redeploying modules whose runtime is disconnected on other (connected) runtimes.

[0047] Furthermore, the mute switch S can additionally monitor messages sent by the application module while it is connected, detect "babbling idiot" failure behavior, mute the module, and trigger a failover to a backup before the module can affect the application due to network overflow. "Bubbling idiot" failure behavior can be sending messages at random times that are not synchronized with the network, or incorrect message content.

[0048] Furthermore, the ability to manage disconnected runtimes can also be used to ensure a higher level of autonomy with respect to the orchestrator 4. This is done, for example, by the deployment of support modules 5 that can take over management of the runtime in case the orchestrator 4 disconnects / crashes, or autonomously migrate modules between runtimes to balance computational / network load.

[0049] The above description of the embodiments sets forth the present invention by way of example, and of course, the individual features of the embodiments can be freely combined with each other as long as it is technically reasonable, without departing from the scope of protection of the present invention. [Explanation of symbols]

[0050] 1 Distributed Systems 2 Sender Runtime 3 Receiver Runtime 4 Orchestrator 5 Support Modules 10. Computers 20 Computer Programs D Detector E emitter S Mute Switch

Claims

1. A method (100) for managing connection losses for a distribution system (1), comprising: - deploying (101) at least one support module (5) on at least two sender runtimes (2), at least one receiver runtime (3) and at least one orchestrator (4) of said distributed system (1), said at least one support module (5) being designed to provide for the transmission of signals on an additional communication channel and said orchestrator (4) being designed to manage regular communication between said at least two sender runtimes (2) and said at least one receiver runtime (3); - analyzing (102) an additional communication channel between the at least two sender runtimes (2) and the orchestrator (4) and detecting a connection loss of at least one of the at least two sender runtimes (2) based on the detection of a transmitted signal on the additional communication channel; - initiating (103) at least one measure in case of detection of said connection loss, said at least one measure comprising stopping, by said at least one support module (5), a regular communication between at least one of the at least two sending runtimes (2) where said connection loss was detected and at least one receiving runtime (3) in order to manage a connection loss in said distributed system (1); A method (100).

2. - initiating, at intervals, the transmission of a signal on said additional communication channel by said at least one support module (5); - analyzing the presence of a transmitted signal to detect said connection loss, the presence of a transmitted signal being analyzed by said at least two sender runtimes (2) and / or an orchestrator (4); 2. The method (100) of claim 1, further comprising:

3. - defining intervals during which said signals are transmitted, said intervals being defined manually or automatically, preferably according to at least one requirement; - defining a period of time for the transmitted signal before said connection loss is detected; 3. The method (100) of claim 2, further comprising:

4. On the at least two sender runtimes (2), the at least one receiver runtime (3) and / or the at least one orchestrator (4), three types of support modules (5) are provided: an emitter (E) for transmitting said signal; a detector (D) for detecting the signal transmitted by said emitter (E); a mute switch (S) for stopping the regular communication between at least one of said at least two sender runtimes (2) and at least one receiver runtime (3); The method (100) according to any one of claims 1 to 3, characterized in that at least one of the following is deployed.

5. The method (100) according to any one of claims 1 to 4, characterized in that the at least one measure further comprises enabling temporary periodic communication between at least one of the at least two sender runtimes (2) and at least one receiver runtime (3) where no connection loss is detected.

6. 6. The method (100) according to claim 5, characterized in that the enabling of temporary periodic communication between at least one of at least two sending runtimes (2) and at least one receiving runtime (3) where no connection loss is detected is performed by the orchestrator (4).

7. The method (100) according to any one of claims 1 to 6, characterized in that it further comprises a step of analyzing an additional communication channel between the at least two sending runtimes (2) and detecting a connection loss of at least one of the at least two sending runtimes (2) based on the transmission of a signal between the at least two sending runtimes (2).

8. A computer program (20) comprising instructions that, when the computer program (20) is executed by a computer (10), cause the computer (10) to carry out a method (100) according to any one of claims 1 to 7.

9. A data processing device (10) comprising means for performing the method (100) according to any one of the preceding claims.

10. A computer readable storage medium (15) comprising instructions which, when executed by a computer (10), cause the computer (10) to perform the steps of the method (100) of any one of claims 1 to 7.

Images