Executing continuous event processing (CEP) queries in parallel

Abstract

A continuous event processing (CEP) query processor determines how and when a CEP query can be processed in a concurrent manner, such that multiple threads of execution can concurrently perform at least some of the CEP query's operations concurrently with each other. According to one technique, a user can instruct a CEP query processor to attempt to execute a CEP query in a concurrent manner. The CEP query processor responsively determines whether the CEP query's execution, or parts thereof, can be made concurrent based on certain constraints that can depend on inheritance and operation type. Based on this determination, the CEP query processor can execute at least certain parts of a CEP query in parallel relative to the same event within an event stream.

Description

BACKGROUND OF THE INVENTION

The present application relates to the processing of continuous event processing (CEP) queries.

Databases have traditionally been used in applications that require storage of data and querying capability on the stored data. Existing databases are thus best equipped to run queries over finite stored data sets. However, the traditional database model is not well suited for a growing number of modern applications in which data is received as a stream of data events instead of a bounded data set. A data stream, also referred to as an event stream, is characterized by a real-time, potentially continuous, sequence of events. A data or event stream thus represents unbounded sets of data. Examples of sources that generate data streams include sensors and probes (e.g., RFID sensors, temperature sensors, etc.) configured to send a sequence of sensor readings, financial tickers, network monitoring and traffic management applications sending network status updates, click stream analysis tools, and others.

CEP is a technology useful for processing data in an event stream. CEP is highly stateful. CEP involves receiving events continuously, and finding some pattern among those events. A significant amount of state maintenance is therefore involved in CEP. Because CEP involves the maintenance of so much state, processes which apply CEP queries to data within an event stream have always been single-threaded. In computer programming, single-threading is the processing of one command at a time.

CEP query processing generally involves the continuous execution of a query relative to events that are specified within an event stream. For example, CEP query processing might be used in order to continuously observe the average price of a stock over the most recent hour. Under such circumstances, CEP query processing can be performed relative to an event stream that contained events that each indicated the current price of the stock at various times. The query can aggregate the stock prices over the last hour and then calculate the average of those stock prices. The query can output each calculated average. As the hour-long window of prices moves, the query can be executed continuously, and the query can output various different average stock prices.

Because such CEP query processing has always been performed within a single thread, the scaling of CEP query processing can become problematic. When a computing machine has multiple processors that are capable of performing operations concurrently, or when a computing system has many nodes that are capable of performing operations concurrently, the concurrent processing power of such machine and systems may be wasted when CEP query processing is performed.

Additionally, during the execution of a CEP query, sometimes errors can occur. Traditionally, when an error has occurred during the execution of a CEP query, the error has simply caused the CEP query to stop executing. The continuous query language (CQL) developed out of the structured query language (SQL). In SQL, queries typically are executed once against a set of data, rather than continuously against events in continuous event stream. Because SQL queries typically were executed just once, the failure of a SQL query was usually remedied by having a database administrator investigate the problem manually, and then having the database administrator manually make whatever changes to the database or to the query were necessary in order to solved the problem, and then having the database administrator re-executed the query. In contrast, CQL queries can be executed continuously against events in an event stream. An error that caused a CQL query to halt execution might have been due simply to a single invalid event within the event stream. Unfortunately, even if the remaining events in the event stream are valid, those events will not be processed by the CQL query as long as the CQL query remains halted. Instead, those events may simply be lost as the event stream continues to flow with time. The CQL query will not be restarted unless an administrator restarts the CQL query manually. Often, an administrator will simply restart a CQL query without changing the CQL query at all, recognizing that the error was due to an invalid event. Under such circumstances, the halting of the CQL query, with its attendant resulting loss in event data, was unfortunate and unnecessary.

BRIEF SUMMARY OF THE INVENTION

Certain embodiments of the invention involve techniques for determining how and when a CEP query can be processed in a concurrent manner, such that multiple threads of execution can concurrently perform at least some of the CEP query's operations concurrently with each other. According to one technique, a user can instruct a CEP query processor to attempt to execute a CEP query in a concurrent manner. The CEP query processor responsively determines whether the CEP query's execution, or parts thereof, can be made concurrent based on certain constraints that can depend on inheritance and operation type. Based on this determination, the CEP query processor can execute at least certain parts of a CEP query in parallel relative to the same event within an event stream.

Certain embodiments of the invention involve techniques for adding the concept of faults and fault handling to the execution of CEP queries. By introducing fault handling techniques to the processing of CEP queries (CQL queries being a kind of CEP query), users are enabled to instruct a CEP query processor to respond to faults in a customized manner that does not necessarily involve the halting of the CEP query relative to which the faults occurred. For example, a fault might be due to a temporary problem. Under such circumstances, the CEP query processor can be instructed or programmed to ignore the fault and allow the execution of the CEP query to continue relative to the remainder of the event stream. Alternatively, if the fault is due to a problem with the CEP query itself, then the CEP query processor can be instructed or programmed to propagate the fault through the query processing system until the fault ultimately causes the problematic CEP query to be halted.

The foregoing, together with other features and embodiments will become more apparent when referring to the following specification, claims, and accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a flow diagram that illustrates an example technique for determining whether a CEP query can be executed in a concurrent manner based on the operators of that CEP query, according to an embodiment of the present invention.

FIG. 2 is a flow diagram that illustrates an example technique for determining a concurrency constraint for a particular operator in a directed graph of operators, according to an embodiment of the present invention.

FIG. 3 is a flow diagram that illustrates an example technique for adding operators to the beginning of a CEP query in order to allow or enforce maximum permissible concurrency in the execution of that CEP query, according to an embodiment of the present invention.

FIG. 4 is a flow diagram that illustrates an example technique whereby user-registered fault handlers of a CEP query processor can handle faults thrown by operators of CEP queries, according to an embodiment of the present invention.

FIG. 5 is a simplified block diagram illustrating components of a system environment that may be used in accordance with an embodiment of the present invention; and

FIG. 6 is a simplified block diagram of a computer system that may be used in accordance with embodiments of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

In the following description, for the purposes of explanation, specific details are set forth in order to provide a thorough understanding of embodiments of the invention. However, it will be apparent that the invention may be practiced without these specific details.

In one embodiment of the invention, a CEP query processor can evaluate the various components of a CEP query. Based on this evaluation, the CEP query processor can break the CEP query into separate pieces. The CEP query processor can then evaluate each such piece of the CEP query in order to determine whether that piece can be processed in a concurrent manner. Based on the results of this evaluation, certain pieces of the CEP query can be processed in a concurrent manner—such that those pieces of the CEP query can be applied to multiple events from the event stream at the same time—while other pieces of the CEP query can be processed in a non-concurrent, sequential manner.

Events in an event stream can be ordered by time, such that a query processor can receive the oldest events in the event stream before receiving the newest events in that event stream. According to an embodiment of the invention, the CEP query processor can receive, from a user, a directive indicating that none, all, or at least part of a specified CEP query can be processed in a concurrent manner, or in other words, in parallel. For example, the user can inform the CEP query processor that the specified CEP query is completely ordered. Under such circumstances, the CEP query processor can determine that no part of the specified CEP query can be processed in a concurrent manner, because concurrent processing of a completely ordered CEP query could cause the processed events to lose their order. For another example, the user can inform the CEP query processor that the specified CEP query is unordered. A CEP query is unordered if the order in which the CEP query processes and outputs the events from an event stream does not matter to the user. For yet another example, the user can inform the CEP query processor that the specified CEP query is partition-ordered. A CEP query is partition-ordered if, for each of the CEP query's partitions, the events within that partition must be processed in order relative to each other, but not necessarily in order relative to the events within other partitions. Based on the user's directive, the CEP query processor can determine which, if any, pieces of the CEP query can be processed in a concurrent manner. Each partition involved in partition-based processing might contain events from a different category. For example, partition-based processing might involve computing a separate average stock price for each separate company having stock price events represented within the same event stream. Under such circumstances, the CEP query is conceptually partitioned by stock symbol. A CEP query may indicate that it involves partition-based processing by its inclusion of a “group by” clause.

In an embodiment, concurrent processing of a CEP query does not cause multiple events in an event stream to be processed concurrently. Instead, concurrent processing of a CEP query can cause multiple portions, or operations, of that CEP query to be performed concurrently relative to a particular event within an event stream. For each such particular event in the event stream, those multiple portions of the CEP query can be performed concurrently relative to that particular event. In an embodiment of the invention, a CEP processor can process a portion of a CEP query relative to an event in a concurrent manner by executing multiple threads, each of which can perform an operation of the CEP query relative to the event concurrently. When this happens, there is no guarantee concerning which of the multiple threads will finish performing its operations first. A single thread can be devoted to extracting events from the event stream in order to prevent the events from inadvertently becoming out-of-order.

In an embodiment, the CEP query processor can receive input from a user indicating certain constraints that are possessed by an application of that user. For example, a user might have an application that displays a stock price on a dashboard. The stock price might be read from an event stream. It might be the case that the user does not care whether the stock prices from the event stream are displayed strictly in time order. Under such circumstances, the user's application can cope with unordered events. In other cases, a user's application might require that events remain ordered. For example, an application might involve the automatic sale of a stock in response to a determination that the stock's price has declined beneath a specified threshold. Under such circumstances, it would be important for the order of the stock price events to be processed in order. The user to whom the application belongs can inform the CEP query processor about the ordering constraints, if any, that the application possesses in this regard.

In an embodiment, after receiving such constraint information from a user, the CEP query processor can determine which pieces, or operations, of a CEP query can be performed in a concurrent manner while still upholding those constraints. In an embodiment, the CEP processor can apply a particular “calculus” to make this determination. In making this determination, the CEP processor can determine a manner in which the central processing units of a machine, and/or the nodes of a system, can be used maximally to execute the CEP query while still honoring the constraints.

Potentially, multiple different CEP queries can execute relative to the same event stream. In a CEP system, multiple different CEP queries can be registered with the CEP system and then continuously executed relative to an event stream. Each such CEP query can be conceived of conceptually as a tree of operators, each having an operation type. In an embodiment of the invention, the CEP query processor can mesh together all of the CEP queries that are to be executed relative to the same event stream, conceptually by meshing together the operator trees for those CEP queries. The CEP query processor can perform this meshing by first breaking down each CEP query into the low-level operators that make up that CEP query. Breaking down the CEP queries in this manner does not necessarily incur any extra cost in the CEP query processing system, because such CEP queries often are broken down in this manner for other reasons anyway. In an embodiment of the invention, the kinds of operations into which a CEP query processor can break down a CEP query include (1) filtering operations, (2) selection operations, (3) projection operations, and (4) join operations, among potentially other kinds of operations. These are the same kinds of operations that are typically found in a query that can be performed relative to a database system. The CEP query processor can then determine, based on the operation types of these low-level operators, which of these low-level operators, potentially from separate CEP queries, can be shared.

For example, multiple CEP queries might perform a filtering operation. A filtering operation can selectively output fewer than all events received from an event stream; a filtering operation can filter out other events, which do not satisfy operation-specified filtering criteria, from the event stream so that the filtering operation does not pass those events on to other query operations. In an embodiment, if multiple CEP queries in a set of CEP queries performs filtering operations relative to an event stream, then the CEP query processor can determine that all of the filtering operations in these CEP queries can share the same filtering operator, even if the filtering criteria for these filtering operations differ. In an embodiment, certain other types of operations, such as group-by operations and aggregation operations, are not allowed to share operators, even if multiple CEP queries executing relative to an event stream perform those types of operations. Thus, according to an embodiment of the invention, only certain specified types of operations, such as filtering operations, can share operators. In an embodiment of the invention, the CEP query processor can mesh together all operators that can be shared by multiple CEP queries executing relative to the same event stream, and leave unmeshed all other operators. Thus, multiple filtering operations from multiple CEP queries can be meshed together by causing those filtering operations to share a single filtering operator, while group-by operations, aggregation operations, and other kinds of un-shareable operations can retain separate operators. In an embodiment of the invention, the CEP query processor can attempt to make as many operations as possible share the same operator, limited by the operation type considerations discussed above.

In an embodiment of the invention, the CEP query processor can link together the set of operators determined and created in this manner, potentially with some sharing, into a directed graph of operators. In the graph, the operators can be linked together based on their inputs and outputs. Operators that output events to other operators can have outgoing links to those other operators in the graph. Operators that receive events from other operators can have incoming links from those other operators in the graph. A particular operator can have multiple incoming and/or outgoing links to and from other operators in the graph. This is especially likely to occur if the particular operator is an operator that is shared by multiple separate CEP queries executing relative to the event stream. Thus, an operator from a first CEP query and an operator from a second CEP query can both output events to a particular filtering operator that is shared by the first and second CEP queries. The particular filtering operator that is so shared can output events to another operator from the first CEP query and another operator from the second CEP query.

Overall, then, the directed graph of operators can have multiple root operators (one for each CEP query), multiple intermediary operators, and multiple leaf operators. Each root operator can receive events as input directly from the event stream and output those events to other operators. The leaf operators can receive events from other operators, perform operations relative to those events, and then output those events to an application's event consumers, such as application components that display output based on those events. The CEP query processor can organize these operators within the directed graph relative to each other based on their operation types. Thus, for example, the CEP query processor can ensure that an operator that extracts events from an event stream comes before, or passes output to, a filtering operator that filters those events. Likewise, for example, the CEP query processor can ensure that such a filtering operator comes before, or passes output to, an aggregation operator that aggregates data specified by those events (e.g., calculating an average). This organization can be based on the fact that filtering should be performed prior to aggregation in order for the aggregation to be performed properly, although this may potentially vary depending upon the particular syntax of the CEP query.

In an embodiment of the invention, the CEP query processor can perform a recursive technique relative to the operators in the directed graph of operators to determine which of the operators in graph can perform its operations in parallel with other operators in that graph. More specifically, the CEP processor can perform this technique to determine the extent to which each operator in the graph can perform its operations in parallel with other operators in that graph. As is discussed above, some of the operators in the directed graph of operators are leaf operators that are the furthest away in the graph from the event stream itself (the root operators being the closest to the event stream). According to one embodiment, the CEP query processor can begin by performing the recursive technique relative to each leaf operator in the directed graph of operators. The recursive technique can involve determining the extent to which the particular operator upon which the technique is being performed can be executed concurrently with other operators. This determination, in turn, can involve first performing the same technique, recursively, on all of the other operators from which the particular operator has an incoming link in the direct graph of operators. If the operator upon which the recursive technique is being performed is a root operator, which receives events directly from the event stream, then the technique can be recursively performed relative to the event stream itself. The event stream has certain properties. These properties indicate whether the event stream is completely ordered, unordered, or partition-ordered based on some specified partitioning. In an embodiment, these properties can be specified by the user of the application that receives events from the event stream, as discussed above.

According to an embodiment of the invention, during the performance of the recursive technique relative to a particular operator in the directed graph of operators, a constraint, which indicates the extent to which that particular operator can be executed concurrently with other operators, can be determined for the particular operator in the following manner. First, an “inherited” constraint for the particular operator can be determined based on the constraints of its “parents” (the operators from which it has incoming links, or from which it receives input) in the directed graph. Then, another, type-based constraint, which is based on the particular operator's own operation type, can be determined for the particular operator. The particular operator's final constraint can be based on its inherited constraint and its type-based constraint. For example, the particular operator's final constraint can be the most constrained of its inherited and type-based constraints.

To determine the particular operator's inherited constraint, first, according to the recursive technique, the final constraints of each of the other operators from which the particular operator has incoming links in the graph can be determined. The particular operator's inherited constraint then can become the most constrained final constraint of those other operators. In an embodiment, completely ordered is the most constrained constraint. In an embodiment, partition-ordered is a constraint that is less constrained that completely ordered, but more constrained than unordered. In an embodiment, unordered is the least constrained constraint.

Thus, for example, if a particular operator has incoming links from three other operators in the directed graph of operators, and if the final constraints of these other operators are completely ordered, partition-ordered, and unordered, then the inherited constraint of the particular operator can become completely ordered (the most constrained of the constraints of the other operators from which the particular operator has incoming links), meaning that the particular operator cannot be executed concurrently with other operators at all. For another example, if a particular operator has incoming links from two other operators in the directed graph of operators, and if the final constraints of these other operators are both unordered, then the inherited constraint of the particular operator similarly can become unordered. The constraint of the event stream itself can be determined based on its properties.

After the inherited constraint for the particular operator has been determined based on the constraints of the other operators from which the particular operator has incoming links, the final constraint for the particular operator can become its inherited constraint unless the particular operator's type-based constraint is more constrained than its inherited constraint. Each operator can have an operation type, and each operation type can have a constraint that is completely ordered, partition-ordered, or unordered. For example, a filtering operation type can have an unordered constraint; the order in which filtering is performed does not matter. However, for another example, a standard deviation operation type can have a completely ordered constraint. Thus, even if the standard deviation operator's inherited constraint is unordered or partition-ordered, the standard deviation operator's final constraint can become completely ordered, because the operator's type-based constraint is more constrained than the operator's inherited constraint. Thus, in one embodiment of the invention, a particular operator's final constraint can become the most constrained of: (a) the constraints of the operators from which the particular operator has incoming links in the directed graph of operators and (b) the particular operator's own type-based constraint. If the particular operator has outgoing links to other operators in the directed graph of operators, it can be this final constraint of the particular operator that is used to determine, at least partially, the inherited constraints of those other operators.

In this recursive manner, each of the operators in the directed graph of operators can obtain a property indicating an extent to which that operator can be executed concurrently with other operators in the directed graph of operators, that property being a final constraint that can be one of: completely ordered, partition-ordered, or unordered. Ultimately, each of the root operators in the directed graph of operators can obtain such a property. Inasmuch as each such root operator can correspond to a separate CEP query, the property for that root operator can become the property for the entire corresponding CEP query.

According to an embodiment of the invention, after each of the CEP queries has obtained a constraint property in the manner discussed above, the CEP query processor can spawn multiple separate threads of execution for each such CEP query that has an unordered constraint. In creating the query execution plan for a particular CEP query, the CEP query processor can ensure that each of these threads receives, in parallel, the same event from the event stream. These threads can then process those events in parallel and output their processed events to their consumer. In one embodiment, in order to cause these threads of execution to be spawned, prior to the execution of the particular CEP query, the CEP query processor can place thread-spawning operators at the beginning of the particular CEP query to be executed at the beginning of the execution of that CEP query.

Similarly, in one embodiment of the invention, the CEP query processor can spawn multiple separate threads of execution for each CEP query that has a partition-ordered constraint. These operations performed by these threads are specially segregated based on the specified partitions, such that each thread handles the operators of a different partition corresponding only to that thread, and such that within a thread, events are processed in a sequential manner. In creating the query execution plan for a particular CEP query, the CEP query processor can ensure that each of these threads only receives events that pertain to its partition (e.g., filtering stock prices for a specified company), but that these threads can operate on different events (for different partitions) from the event stream in parallel. In one embodiment, in order to cause these threads of execution to be spawned, prior to the execution of the particular CEP query, the CEP query processor can place thread-spawning operators at the beginning of the particular CEP query to be executed at the beginning of the execution of that CEP query.

In one embodiment of the invention, for each CEP query that has a completely ordered constraint, prior to the execution of that CEP query, the CEP query processor can place locking operators at the beginning of that CEP query to be executed at the beginning of the execution of that CEP query in order to ensure that the operations of each operator involved in that CEP query are performed sequentially, within a single thread, rather than in parallel.

FIG. 1 is a flow diagram that illustrates an example technique 100 for determining whether a CEP query can be executed in a concurrent manner based on the operators of that CEP query, according to an embodiment of the present invention. Although certain blocks are illustrated by way of example in FIG. 1, alternative embodiments of the invention may involve more, fewer, or different blocks, and/or blocks occurring in a different order. In block 102, a CEP query processor can receive, from a user, input indicating concurrency constraints that are to be imposed on an application that involves a group of CEP queries. In block 104, the CEP query processor can break each CEP query in the group into a separate tree of operators. In block 106, the CEP query processor can mesh together the trees of operators by sharing some operators between trees, thereby forming a directed graph of operators. In block 108, the CEP query processor can determine a concurrency constraint for each operator in the directed graph. In block 110, the CEP query processor can determine a concurrency constraint for each CEP query in the group based on the concurrency constraints for the operators of that CEP query. In block 112, the CEP query processor can add operators to the beginnings of the CEP queries to allow or prevent concurrent execution of those CEP queries based on the concurrency constraints for those CEP queries.

FIG. 2 is a flow diagram that illustrates an example technique 200 for determining a concurrency constraint for a particular operator in a directed graph of operators, according to an embodiment of the present invention. Technique 200 can be performed relative to each of the operators in a directed graph of operators after the meshing of block 106 of FIG. 1 has been performed, for example. Although certain blocks are illustrated by way of example in FIG. 2, alternative embodiments of the invention may involve more, fewer, or different blocks, and/or blocks occurring in a different order. In block 202, the CEP query processor can determine final concurrency constraints of each other operator from which the particular operator receives events. For example, the CEP query processor can use technique 200 recursively to determine the final concurrency constraints for each such other operator. In block 204, the CEP query processor can set the particular operator's inherited concurrency constraint to be the most constrained of the final concurrency constraints of the other operators from which the particular operator receives events. In block 206, the CEP query processor can set the particular operator's type-based concurrency constraint based on a type of operation performed by the operator. In block 208, the CEP query processor can set the particular operator's final concurrency constraint to be the most constrained of (a) the particular operator's inherited concurrency constraint and (b) the particular operator's type-based concurrency constraint.

FIG. 3 is a flow diagram that illustrates an example technique 300 for adding operators to the beginning of a CEP query in order to allow or enforce maximum permissible concurrency in the execution of that CEP query, according to an embodiment of the present invention. Technique 300 can be performed relative to each of the CEP queries in a group of CEP queries involved in an application after the application of technique 200 of FIG. 2 has been performed relative to all of the operators in the directed graph of operators, for example. Although certain blocks are illustrated by way of example in FIG. 3, alternative embodiments of the invention may involve more, fewer, or different blocks, and/or blocks occurring in a different order. In block 302, the CEP query processor can determine whether the final concurrency constraint of the CEP query's root operator in the directed graph of operators is unordered, partition-ordered, or completely ordered. If the final concurrency constraint is unordered, then control passes to block 306. If the final concurrency constraint is partition-ordered, then control passes to block 308. If the final concurrency constraint is completely ordered, then control passes to block 310.

In block 306, the CEP query processor can add, to the beginning of the CEP query, operators that cause multiple threads of execution to be spawned to permit execution of the CEP query in a concurrent manner. Alternatively, in block 308, the CEP query processor can add, to the beginning of the CEP query, operators that cause a separate thread of execution to be spawned for each of the event partitions that the CEP query processes. Alternatively, in block 310, the CEP query processor can add, to the beginning of the CEP query, locking operators that ensure that the operation of the CEP query will be performed sequentially rather than in parallel.

According to an embodiment of the invention, the CEP query processor can be modified to introduce fault-handling mechanisms into the CEP query processor. In one embodiment, these mechanisms involve an analysis of the directed graph of operators discussed above. The analysis can involve a determination of whether a particular operator in the directed graph is shared by multiple executing CEP queries or not.

In an embodiment of the invention, during the execution of multiple CEP queries relative to an event stream, the CEP query processor can detect the occurrence of a fault. This fault can be raised by one of the operators within the directed graph of operators discussed above. For example, a particular operator can raise a fault in response to determining that the event upon which that particular operator is attempting to perform its operation specifies invalid data. In response to detecting the occurrence of a fault, the CEP query processor can determine which one of the operators in the directed graph of operators raised the fault. The operator that raised the fault might be a filtering operator that performs filtering operations relative to events in the event stream, or the operator that raised the fault might be some other more complex type of operator, such as a join operator that performs join operations.

In an embodiment of the invention, the CEP query processor can include a registration facility through which a user of the CEP query processor can register a customized fault handler of the user's own specification. This fault handler can pertain in scope to all of the CEP queries that the CEP query processor executes, such that faults raised by the operator of any CEP query being executed by the CEP query processor can be handled by that fault handler. Multiple separate and different fault handlers can be registered with the same CEP query processor, in which case all of them can handle faults raised by any of the CEP query processor's executing CEP queries.

According to an embodiment of the invention, in response to any operator of any executing CEP query raising a fault, the fault handlers registered to the CEP query processors can be responsively invoked in the order of the registration of those fault handlers. The CEP query processor can provide some contextual information pertaining to the fault to each such fault handler. This contextual information can include an identity of the fault itself as well as an identity of the operator (from the directed graph of operators) that raised the fault. As each fault handler is invoked, that fault handler can determine, based on its internal instructions, whether to catch the fault or re-throw the fault. Some registered fault handlers can be customized to catch types of faults that other registered fault handlers have not been customized to catch. For example, a particular fault handler might be customized to catch faults raised by filtering operators but not faults raised by join operators. For another example, a particular fault handler might be customized to catch faults resulting from timestamp errors in event data but not faults resulting from other kinds of errors in event data.

In an embodiment of the invention, if a fault handler decides to catch the fault, then the fault handler can handle the fault in a manner that is based on its internal instructions pertaining to faults of the fault's type. These internal instructions can be customized by the fault handler's creator. Under such circumstances, the fault thereafter can be treated as though the fault had not occurred; the fault's existence can be removed from the system. The CEP query processor can continue to execute the CEP queries, permitting the CEP queries to process additional events from the event stream, without halting any CEP query. In an embodiment of the invention, any other registered fault handlers subsequently invoked responsive to the same fault detect no fault that they can catch.

Alternatively, in an embodiment of the invention, if a particular fault handler decides to re-throw the fault, meaning that the particular fault handler has decided not to handle the fault (potentially because the particular fault handler contains no instructions for handling faults of the fault's specific type), then the CEP query processor can invoke the next registered fault handler, if any, in order of registration. That next fault handler can then similarly decide whether to catch the fault or re-throw the fault, again based on its own internal instructions. This approach can continue repetitively, with the CEP query processor invoking subsequent registered fault handlers in the order of their registration, either until one of the registered fault handlers catches and handles the fault, thereby removing the fault's existence from the system, or until there are no further user-registered fault handlers for the CEP query processor to invoke.

According to an embodiment of the invention, the CEP query processor can include a default fault handler in addition to any user-registered, user-customized fault handlers. If a fault is not caught by any of the user-registered fault handlers, then the default fault handler can catch the fault. In an embodiment of the invention, the default fault handler does not re-throw any fault, but instead catches every fault that has been re-thrown by all of the user-registered fault handlers. In response to catching a fault, the default fault handler can halt execution of each CEP query that included the operator that raised the fault. Inasmuch as some operators can be shared by multiple CEP queries, the default fault handler can, under some circumstances, halt execution of multiple CEP queries in response to catching a single fault that was raised by an operator shared by all of those CEP queries.

As is discussed above, in one embodiment of the invention, the CEP query processor's default fault handler can halt execution of a CEP query in response to catching a fault. However, in an alternative embodiment of the invention, instead of halting execution of the CEP query in response to catching a fault, the default fault handler can throw the fault as a JAVA exception which can be caught by a fault handler of a JAVA adapter that is feeding the event stream's events to the CEP query processor. Thus, under such circumstances, the JAVA adapter that is the event stream source or producer can receive the fault as a JAVA exception from the CEP query processor's default fault handler. The manner in which the JAVA adapter handles the exception can vary based on the JAVA adapter's internal instructions and programming. For example, if the JAVA adapter is a JAVA messaging system (JMS) adapter, then the JAVA adapter can determine whether the event is invalid, and, in response to determining that the event is invalid, the JAVA adapter can ask the messaging system from whence the JAVA adapter obtained the event to re-send a valid version of the event to the JAVA adapter. Alternatively, the JAVA adapter can roll-back the event, and/or ignore the event and allow other events in the event stream to proceed to the CEP query processor.

Potentially, a single event can cause multiple separate operators in the directed graph of operators to raise faults in response to that event. For example, a filtering operator that outputs events to a join operator, and the join operator itself, both might raise a fault in response to a particular event. This occurrence may be especially likely under circumstances in which the CEP query processor is processing events in a concurrent manner. In one embodiment of the invention, when multiple faults are raised in response to the same event, the CEP query processor can group the faults together for handling in a unified manner. The CEP query processor can accomplish this grouping by creating a “parent” fault called “event processing fault.” This parent fault can specifies, as context within the parent fault, both an identity of the event that caused the faults to be raised, as well as an identity of each operator that raised a fault in response to the event. In an embodiment, the fact that multiple faults have been raised in response to the same event can be detected by a “parent” operator that receives events as input from the fault-raising operators, and the grouping can be performed at this parent operator. The parent fault can then caught or re-thrown by fault handlers in the manner discussed above, while the other faults that were grouped together within the parent fault can be removed from the system so as not to be separately caught by any fault handler. As a consequence of the grouping, the fault handlers can avoid unnecessary repetitious fault handling for faults arising from the same event. In one embodiment of the invention, fault handlers can be customized to handle these “compound” grouped faults in a manner that is different from the manner in which those faults handler handle “simple” faults.

FIG. 4 is a flow diagram that illustrates an example technique 400 whereby user-registered fault handlers of a CEP query processor can handle faults thrown by operators of CEP queries, according to an embodiment of the present invention. Although certain blocks are illustrated by way of example in FIG. 4, alternative embodiments of the invention may involve more, fewer, or different blocks, and/or blocks occurring in a different order. In block 402, an operator within a directed graph of operators representing concurrently executing CEP queries can raise a fault relative to an event being processed by that operator. In block 403, in response to detecting that the fault was raised, the CEP query processor can determine whether any user fault handlers are registered by users to handle the fault. If so, then control passes to block 404. If not, control passes to block 412. In block 404, the CEP query processor determines whether any of the user-registered faults handlers have not yet been invoked relative to the fault. If at least one user-registered fault handler has not yet been invoked relative to the fault, then control passes to block 406. Otherwise, technique 400 ends.

In block 406, the CEP query processor can invoke the next user-registered fault handler, in registration order, to handle the fault. In block 408, the most recently invoked user-registered fault handler can either catch and handle the fault or re-throw the fault. In block 410, a determination can be made as to whether the most recently invoked user-registered fault handler caught or re-threw the fault. If the fault was caught, then technique 400 is finished. Alternatively, if the fault was re-thrown, then control passes back to block 404.

Alternatively, in block 412, the CEP query processor can invoke a default fault handler (not user-registered) to handle the fault. In block 414, the default fault handler can catch the fault and responsively raise a JAVA exception. In block 416, an exception handler of a JAVA adapter, which is the source of the event stream that contained the event that caused the fault to be raised in block 402, catches the JAVA exception and causes a corrected version of the event to be re-issued to the CEP query processor. Control then passes back to block 402, in which another fault potentially pertaining to another event can be raised potentially by another operator.

FIG. 5 is a simplified block diagram illustrating components of a system environment 500 that may be used in accordance with an embodiment of the present invention. As shown, system environment 500 includes one or more client computing devices 502, 504, 506, 508, which are configured to operate a client application such as a web browser, proprietary client (e.g., Oracle Forms), or the like. In various embodiments, client computing devices 502, 504, 506, and 508 may interact with a server 512.

Client computing devices 502, 504, 506, 508 may be general purpose personal computers (including, by way of example, personal computers and/or laptop computers running various versions of Microsoft Windows and/or Apple Macintosh operating systems), cell phones or PDAs (running software such as Microsoft Windows Mobile and being Internet, e-mail, SMS, Blackberry, or other communication protocol enabled), and/or workstation computers running any of a variety of commercially-available UNIX or UNIX-like operating systems (including without limitation the variety of GNU/Linux operating systems). Alternatively, client computing devices 502, 504, 506, and 508 may be any other electronic device, such as a thin-client computer, Internet-enabled gaming system, and/or personal messaging device, capable of communicating over a network (e.g., network 510 described below). Although exemplary system environment 500 is shown with four client computing devices, any number of client computing devices may be supported. Other devices such as devices with sensors, etc. may interact with server 512.

System environment 500 may include a network 510. Network 510 may be any type of network familiar to those skilled in the art that can support data communications using any of a variety of commercially-available protocols, including without limitation TCP/IP, SNA, IPX, AppleTalk, and the like. Merely by way of example, network 510 can be a local area network (LAN), such as an Ethernet network, a Token-Ring network and/or the like; a wide-area network; a virtual network, including without limitation a virtual private network (VPN); the Internet; an intranet; an extranet; a public switched telephone network (PSTN); an infra-red network; a wireless network (e.g., a network operating under any of the IEEE 802.11 suite of protocols, the Bluetooth protocol known in the art, and/or any other wireless protocol); and/or any combination of these and/or other networks.

System environment 500 also includes one or more server computers 512 which may be general purpose computers, specialized server computers (including, by way of example, PC servers, UNIX servers, mid-range servers, mainframe computers, rack-mounted servers, etc.), server farms, server clusters, or any other appropriate arrangement and/or combination. In various embodiments, server 512 may be adapted to run one or more services or software applications described in the foregoing disclosure. For example, server 512 may correspond to a continuous event processing server.

Server 512 may run an operating system including any of those discussed above, as well as any commercially available server operating system. Server 512 may also run any of a variety of additional server applications and/or mid-tier applications, including HTTP servers, FTP servers, CGI servers, Java servers, database servers, and the like. Exemplary database servers include without limitation those commercially available from Oracle, Microsoft, Sybase, IBM and the like.

System environment 500 may also include one or more databases 514, 516. Databases 514, 516 may reside in a variety of locations. By way of example, one or more of databases 514, 516 may reside on a storage medium local to (and/or resident in) server 512. Alternatively, databases 514, 516 may be remote from server 512, and in communication with server 512 via a network-based or dedicated connection. In one set of embodiments, databases 514, 516 may reside in a storage-area network (SAN) familiar to those skilled in the art. Similarly, any necessary files for performing the functions attributed to server 512 may be stored locally on server 512 and/or remotely, as appropriate. In one set of embodiments, databases 514, 516 may include relational databases, such as Oracle 10g, that are adapted to store, update, and retrieve data in response to SQL-formatted commands.

FIG. 6 is a simplified block diagram of a computer system 600 that may be used in accordance with embodiments of the present invention. For example, a continuous even processing server may be implemented using a system such as system 600. Computer system 600 is shown comprising hardware elements that may be electrically coupled via a bus 624. The hardware elements may include one or more central processing units (CPUs) 602, one or more input devices 604 (e.g., a mouse, a keyboard, etc.), and one or more output devices 606 (e.g., a display device, a printer, etc.). Computer system 600 may also include one or more storage devices 608. By way of example, the storage device(s) 608 may include devices such as disk drives, optical storage devices, and solid-state storage devices such as a random access memory (RAM) and/or a read-only memory (ROM), which can be programmable, flash-updateable and/or the like.

Computer system 600 may additionally include a computer-readable storage media reader 612, a communications subsystem 614 (e.g., a modem, a network card (wireless or wired), an infra-red communication device, etc.), and working memory 618, which may include RAM and ROM devices as described above. In some embodiments, computer system 600 may also include a processing acceleration unit 616, which can include a digital signal processor (DSP), a special-purpose processor, and/or the like.

Computer-readable storage media reader 612 can further be connected to a computer-readable storage medium 610, together (and, optionally, in combination with storage device(s) 608) comprehensively representing remote, local, fixed, and/or removable storage devices plus storage media for temporarily and/or more permanently containing computer-readable information. Communications system 614 may permit data to be exchanged with network 1610 and/or any other computer described above with respect to system environment 1600.

Computer system 600 may also comprise software elements, shown as being currently located within working memory 618, including an operating system 620 and/or other code 622, such as an application program (which may be a client application, Web browser, mid-tier application, RDBMS, etc.). In an exemplary embodiment, working memory 618 may include executable code and associated data structures (such as caches) used for the techniques described above. It should be appreciated that alternative embodiments of computer system 600 may have numerous variations from that described above. For example, customized hardware might also be used and/or particular elements might be implemented in hardware, software (including portable software, such as applets), or both. Further, connection to other computing devices such as network input/output devices may be employed.

Storage media and computer readable media for containing code, or portions of code, can include any appropriate media known or used in the art, including storage media and communication media, such as but not limited to volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage and/or transmission of information such as computer readable instructions, data structures, program modules, or other data, including RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, data signals, data transmissions, or any other medium which can be used to store or transmit the desired information and which can be accessed by a computer.

Although specific embodiments of the invention have been described, various modifications, alterations, alternative constructions, and equivalents are also encompassed within the scope of the invention. Embodiments of the present invention are not restricted to operation within certain specific data processing environments, but are free to operate within a plurality of data processing environments. Additionally, although embodiments of the present invention have been described using a particular series of transactions and steps, it should be apparent to those skilled in the art that the scope of the present invention is not limited to the described series of transactions and steps.

Further, while embodiments of the present invention have been described using a particular combination of hardware and software, it should be recognized that other combinations of hardware and software are also within the scope of the present invention. Embodiments of the present invention may be implemented only in hardware, or only in software, or using combinations thereof.

The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that additions, subtractions, deletions, and other modifications and changes may be made thereunto without departing from the broader spirit and scope as set forth in the claims. U.S. patent applications having the following serial numbers are incorporated by reference herein: Ser. Nos. 12/548,187; 12/396,008; 12/396,464; 12/395,871; 12/506,891; 12/548,209; 12/506,905; 12/534,384; 12/548,222; 12/534,398; 12/548,281; and 12/548,290.

Claims

1. A computer-readable memory storing a plurality of instructions for causing a processor to perform operations, the plurality of instructions comprising: instructions that cause the processor to determine that multiple portions of a continuous event processing (CEP) query can be executed concurrently relative to an event in an event stream, the instructions comprising: instructions that cause the processor to split the CEP query into a plurality of separate operators;instructions that cause the processor to determine a separate constraint for each operator within the plurality of separate operators; andinstructions that cause the processor to determine, based at least in part on the separate constraint for each operator within the plurality of separate operators, whether at least a part of the CEP query can be executed in a concurrent manner;instructions that cause the processor to execute the multiple portions of the CEP query concurrently against a first event received via the event stream in response to determining that at least part of the CEP query can be executed in a concurrent manner; andinstructions that cause the processor to merge, into a single shared operator, (a) a first operator that is used by a first CEP query that processes at least the first event in the event stream, and (b) a second operator that is used by a second CEP query that also processes at least the first event in the event stream, in response to determining that the first operator and the second operator both perform a particular type of operation.

2. The computer-readable memory of claim 1, wherein the plurality of instructions that cause the processor to execute the multiple portions of the CEP query concurrently against the first event received via the event stream further comprise instructions that cause the processor to spawn multiple threads of execution that concurrently process the multiple portions of the CEP query against the first event received via the event stream.

3. The computer-readable memory of claim 1, wherein the plurality of instructions further comprise instructions that cause the processor to determine a constraint for the CEP query based at least in part on the separate constraint determined for each operator within the plurality of separate operators.

4. The computer-readable memory of claim 1, wherein the plurality of instructions that cause the processor to determine the separate constraint for each operator within the plurality of separate operators comprise instructions that cause the processor to determine the separate constraint for the operator based at least in part on one or more constraints of one or more other operators from which the operator receives input.

5. The computer-readable memory of claim 4, wherein the plurality of instructions that cause the processor to determine the separate constraint for each operator within the plurality of separate operators further comprise instructions that cause the processor to determine the separate constraint for the operator based at least in part on determining that an operation type of the operator is at least one of a filtering operation type, a selection operation type, a projection operation type, or a join operation type.

6. The computer-readable memory of claim 1, wherein the plurality of instructions that cause the processor to determine the separate constraint for each operator within the plurality of separate operators comprise instructions that cause the processor to: determine a first constraint for the operator based on constraints of one or more operators from which the operator receives input;determine a second constraint for the operator based on an operation type of the operator; anddetermine a final constraint for the operator based at least in part on the first constraint and the second constraint.

7. The computer-readable memory of claim 6, wherein the first constraint comprises an inherited constraint for the operator and the second constraint comprises a type-based constraint associated with the operator and wherein the final constraint for the operator is determined based at least in part on the inherited constraint for the operator and the type-based constraint associated with the operator.

8. The computer-readable memory of claim 7, wherein the final constraint for the operator comprises at least one of a completely ordered constraint, a partition-ordered constrained, or an unordered constraint.

9. The computer-readable memory of claim 1, wherein the instructions that cause the processor to determine the separate constraint for each operator within the plurality of separate operators comprise instructions that cause the processor to determine a constraint for a third operator, which receives input from the single shared operator, based at least in part on a constraint of the single shared operator; wherein the instructions that cause the processor to determine the constraint for each operator within the plurality of separate operators comprise instructions that cause the processor to determine a constraint for a fourth operator, which receives input from the single shared operator, based at least in part on the constraint of the single shared operator;wherein the third operator is used by the first CEP query and is not used by the second CEP query; andwherein the fourth operator is used by the second CEP query and is not used by the first CEP query.

10. A system for processing a data stream of events, the system comprising: a memory storing a plurality of instructions; anda processor coupled to the memory, the processor configured to execute the plurality of instructions to: determine that multiple portions of a continuous event processing (CEP) query can be executed concurrently relative to an event in an event stream, the instructions to determine that multiple portions of the CEP query can be executed concurrently relative to an event in an event stream comprising instructions to: split the CEP query into a plurality of separate operators;determine a separate constraint for each operator within the plurality of separate operators; anddetermine, based at least in part on the separate constraint for each operator within the plurality of separate operators, whether at least a part of the CEP query can be executed in a concurrent manner;execute the multiple portions of the CEP query concurrently against a first event received via the event stream in response to determining that at least part of the CEP query can be executed in a concurrent manner; andmerge, into a single shared operator, (a) a first operator that is used by a first CEP query that processes at least the first event in the event stream, and (b) a second operator that is used by a second CEP query that also processes at least the first event in the event stream, in response to determining that the first operator and the second operator both perform a particular type of operation.

11. The system of claim 10, wherein the processor is configured to execute the multiple portions of the CEP query concurrently against the first event received via the event stream by spawning multiple threads of execution that concurrently process the multiple portions of the CEP query against the first event received via the event stream.

12. The system of claim 10, wherein the processor is configured to determine the separate constraint for each operator within the plurality of separate operators at least in part by determining the separate constraint for the operator based at least in part on one or more constraints of one or more other operators from which the operator receives input.

13. The system of claim 12, wherein the processor is configured to determine the separate constraint for each operator within the plurality of separate operators at least in part by determining the separate constraint for the operator based at least in part on whether an operation type of the operator is a filtering operation type, a selection operation type, a projection operation type, or a join operation type.

14. The system of claim 10, wherein the processor is configured to determine the separate constraint for each operator within the plurality of separate operators by: determining a first constraint for the operator based on constraints of one or more operators from which the operator receives input;determining a second constraint for the operator based on an operation type of the operator; anddetermining a final constraint for the operator based at least in part on the first constraint and the second constraint.

15. The system of claim 14, wherein the first constraint comprises an inherited constraint for the operator and the second constraint comprises a type-based constraint associated with the operator.

16. A method for processing a data stream of events, the method comprising: determining that multiple portions of a continuous event processing (CEP) query can be executed concurrently relative to an event in an event stream, the determining comprising: splitting the CEP query into a plurality of separate operators;determining a separate constraint for each operator within the plurality of separate operators; anddetermining, based on the separate constraint for each operator within the plurality of separate operators, whether at least a part of the CEP query can be executed in a concurrent manner;executing the multiple portions of the CEP query concurrently against a first event received via the event stream in response to determining that at least part of the CEP query can be executed in a concurrent manner; andmerging, into a single shared operator, (a) a first operator that is used by a first CEP query that processes at least the first event in the event stream, and (b) a second operator that is used by a second CEP query that also processes at least the first event in the event stream, in response to determining that the first operator and the second operator both perform a particular type of operation.

17. The method of claim 16, further comprising executing the multiple portions of the CEP query concurrently against the first event received via the event stream by spawning multiple threads of execution that concurrently process the multiple portions of the CEP query against the first event received via the event stream.

18. The method of claim 16, wherein determining the separate constraint for each operator within the plurality of separate operators comprises determining the separate constraint for the operator based at least in part on one or more constraints of one or more other operators from which the particular operator receives input.

19. The method of claim 16, wherein determining the separate constraint for each operator within the plurality of separate operators comprises determining the separate constraint for the operator based at least in part on determining that an operation type of the operator is at least one of a filtering operation type, a selection operation type, a projection operation type, or a join operation type.