Event Stream Processing with Multiple Threads

Hallé, Stéphane; Khoury, Raphaël; Gaboury, Sébastien

doi:10.1007/978-3-319-67531-2_22

Cited by 11 publications

(2 citation statements)

References 31 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…However, their languages are often based on SQL extensions without a clear semantics. An exception is BeepBeep [33,34]: a multi-threaded stream processor that supports LTL-FO + , a first-order variant of LTL. The parallelism in BeepBeep must, however, be arranged manually by the user.…”

Section: Related Workmentioning

confidence: 99%

Scalable Online First-Order Monitoring

Schneider

Basin

Brix

et al. 2018

Runtime Verification

View full text Add to dashboard Cite

Online monitoring is the task of identifying complex temporal patterns while incrementally processing streams of data-carrying events. Existing state-of-the-art monitors for first-order patterns, which may refer to and quantify over data values, can process streams of modest velocity in real-time. We show how to scale up first-order monitoring to substantially higher velocities by slicing the stream, based on the events' data values, into substreams that can be monitored independently. Because monitoring is not embarrassingly parallel in general, slicing can lead to data duplication. To reduce this overhead, we adapt hash-based partitioning techniques from databases to the monitoring setting. We implement these techniques in an automatic data slicer based on Apache Flink and empirically evaluate its performance using two tools-MonPoly and DejaVu-to monitor the substreams. Our evaluation attests to substantial scalability improvements for both tools.

show abstract

Section: Related Workmentioning

confidence: 99%

Scalable Online First-Order Monitoring

Schneider

Basin

Brix

et al. 2018

Runtime Verification

View full text Add to dashboard Cite

show abstract

“…As such, there is no explicit assignment of monitors to components and parts of the system, nor consideration of architecture. Furthermore, there is no algorithmic consideration addressing monitoring in a decentralized fashion, even-though some works such as [29] do provide multi-threaded implementations.…”

Section: Related Workmentioning

confidence: 99%

On the Monitoring of Decentralized Specifications Semantics, Properties, Analysis, and Simulation

El-Hokayem¹,

Falcone²

2018

Preprint

View full text Add to dashboard Cite

We define two complementary approaches to monitor decentralized systems. The first relies on those with a centralized specification, i.e, when the specification is written for the behavior of the entire system. To do so, our approach introduces a data-structure that i) keeps track of the execution of an automaton, ii) has predictable parameters and size, and iii) guarantees strong eventual consistency. The second approach defines decentralized specifications wherein multiple specifications are provided for separate parts of the system. We study two properties of decentralized specifications pertaining to monitorability and compatibility between specification and architecture. We also present a general algorithm for monitoring decentralized specifications. We map three existing algorithms to our approaches and provide a framework for analyzing their behavior. Furthermore, we introduce THEMIS, a framework for designing such decentralized algorithms and simulating their behavior. We show the usage of THEMIS to compare multiple algorithms and verify the trends predicted by the analysis by studying two scenarios: a synthetic benchmark and a real example. IntroductionRuntime Verification (RV) [32,27,5] is a lightweight formal method which consists in verifying that a run of a system is correct wrt a specification. The specification formalizes the behavior of the system typically in logics (such as variants of Linear-Time Temporal Logic, LTL) or finite-state machines. Typically the system is considered as a black box that feeds events to a monitor. An event usually consists of a set of atomic propositions that describe some abstract operations or states in the system. The sequence of events transmitted to the monitor is referred to as the trace. Based on the received events, the monitor emits verdicts in a truth domain that indicate whether the run complies or not with the specification. A typical truth domain is a set { , ⊥, ?} where verdicts and ⊥ indicate respectively that a program complies or violates the specification, and verdict ? indicates that no final verdict could be reached yet. Truth domains can also include additional verdicts such as currently true and currently false, to indicate a finer grained truth value. RV techniques have been used for instance in the context of decentralized automotive [13] and medical [33] systems. In both cases, RV is used to verify correct communication patterns between the various components and their adherence to the architecture and their formal specifications. While RV comprehensively deals with monolithic systems, multiple challenges are presented when scaling existing approaches to decentralized systems, that is, systems with multiple components with no central observation point. These challenges are inherent to the nature of decentralization; the monitors have a partial view of the system and need to account for communication and consensus. Our assumptions on the system are as follows: No monitors are malicious, i.e., messages do not contain wrong information; No message...

show abstract

Writing Domain-Specific Languages for BeepBeep

Hallé

Khoury

2018

Runtime Verification

View full text Add to dashboard Cite

Event Stream Processing with Multiple Threads

Cited by 11 publications

References 31 publications

Scalable Online First-Order Monitoring

Scalable Online First-Order Monitoring

On the Monitoring of Decentralized Specifications Semantics, Properties, Analysis, and Simulation

Writing Domain-Specific Languages for BeepBeep

Contact Info

Product

Resources

About