Aspect-aware stream computing method, system, and computer program

Abstract

To affect operation of a stream application based on an aspect program code.SOLUTION: A stream of tuples to be processed by processing elements that operate on one or more compute nodes of a stream application is monitored. Each processing element has one or more stream operators. A program request is received. A stream application target of a set of program code instructions is identified. A portion of the stream application is encapsulated with a generic program execution structure during an operation of the stream application. The structure is configured to receive and execute program code instructions outside of a preconfigured operation of the stream application. The set of program code instructions is executed during the operation of the stream application in response to the program request and based on the stream application target.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The present disclosure relates to stream computing, and more particularly to influencing the behavior of stream applications based on aspects of program code. [Background technology]

[0002] Stream computing can be used to provide real-time analytical processing on large amounts of data and can be based on a fixed set of pre-compiled processing elements or stream operators. Summary of the Invention [Problem to be solved by the invention]

[0003] Aspects provide a way to influence the behavior of a stream application based on program code. [Means for solving the problem]

[0004] According to embodiments, a method, a system, and a computer program product are disclosed.

[0005] A stream of tuples can be monitored. The stream of tuples is processed by a plurality of processing elements operating on one or more nodes of a stream application, each processing element having one or more stream operators. A program request to execute a first set of one or more program code instructions is received. A stream application target for the first set of program code instructions is identified based on the program request. A first portion of the set of one or more portions of the stream application is encapsulated in a generic program execution structure. The encapsulation occurs during operation of the stream application. The generic program execution structure is configured to receive and execute program code instructions outside of a preconfigured operation of the stream application. The first set of program code instructions is executed by the generic program execution structure during a first period of execution of the first portion of the stream application. Execution of the first set of program code instructions occurs during operation of the stream application based on the stream application target in response to the program request.

[0006] The above summary is not intended to describe each illustrated embodiment or every implementation of the present disclosure. [Brief explanation of the drawings]

[0007] The drawings included in this disclosure are incorporated into and constitute a part of this specification. These drawings illustrate embodiments of the present disclosure and, together with the description, serve to explain the principles of the disclosure. The drawings are merely illustrative of particular embodiments and are not intended to limit the disclosure.

[0008] [Figure 1] 1 illustrates representative major components of an exemplary computer system that may be used in accordance with some embodiments of the present disclosure. [Figure 2]1 illustrates an exemplary stream computing application configured to operate on a stream of tuples, according to some embodiments of the present disclosure. [Figure 3] 1 is an exemplary stream application configured as aspect-aware stream computing in accordance with some embodiments of the present disclosure. [Figure 4] 1 illustrates a method for aspect-aware stream computing according to some embodiments of the present disclosure.

[0009] While the embodiments described herein are susceptible to various modifications and alternative forms, specific features thereof have been shown by way of example in the drawings and will be described in detail. It is to be understood, however, that the particular embodiments described are not to be construed in a limiting sense. On the contrary, it is intended to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0010] Aspects of the present disclosure relate to stream computing, and more particularly to affecting the behavior of stream applications based on aspects of program code. The present disclosure is not necessarily limited to such applications, but various aspects of the present disclosure will be understood through the discussion of various examples using this context.

[0011] One use of a computing system (or computer system) is to gather available information, manipulate the gathered information, and make decisions based on the manipulated information. Computer systems can manipulate information through databases that allow users to determine what has happened and predict future outcomes based on past events. These computer systems can receive information from a variety of sources and record that information in a permanent database. After the information is recorded in the database, the computing system runs algorithms on the information, sometimes generating new information, and then performs and stores relevant transformations on the new information, makes decisions, and provides context to the user.

[0012] The ability of computer systems to analyze information and provide meaning to users can be inadequate in some situations. The ability of large organizations, such as businesses and governments, to make decisions based on information analysis can be hampered by a limited range of available information. Furthermore, the value of an analysis can be limited due to the analysis' reliance on stored structural databases that may contain outdated information. This can result in decisions of limited value or even inaccurate decisions. For example, a weather forecasting service may be unable to accurately predict the amount of precipitation in a given area, or a brokerage firm may make incorrect decisions about trading stocks.

[0013] The lack of analytics for computer systems may be exacerbated by other factors. First, the world may be becoming more instrumented, as previously unintelligent devices are now becoming intelligent. Intelligent devices may include devices that previously could not provide analytical information but can now do so with the addition of sensors (e.g., automobiles that can now provide diagnostic information to their owners or manufacturers, or thermostats that now communicate information about daily temperature changes in the home to users via a web page). Second, these gaps may be further exacerbated by the interconnection of previously isolated devices and increased communication from sources (e.g., appliances in the home communicating with each other and with the power company to use electricity more efficiently). These new sources may provide a wealth of not only isolated data points but also novel relationships between intelligent devices.

[0014] A third aggravating factor is that users of computing systems may prefer to continuously analyze streams of information, while data acquisition methods may only offer an event-based approach to analyzing pre-recorded information. For example, an analytics package may receive a finite amount of data and later apply analytics to that data. This approach may not work when dealing with continuous streams of data. A fourth aggravating factor is that computer systems may be deficiencies not only in handling the volume of information, but also in handling information of an unstructured nature; for example, sensors, cameras, and other novel data sources may provide only raw information, without context or formatting. The computing system's analytical methods may need to modify and rearrange this data to provide some kind of context to the raw information. Such modification and rearrangement may consume time or resources that many computing systems may be unable to provide.

[0015] Yet another potential drawback is that computing systems may not be able to provide scalable solutions for new users. The advent of smart and connected devices has brought about new use cases for analyzing continuous streams of information. However, modern systems for large-scale data collection require significant user training and may offer unintuitive interfaces. For example, a farm may attach sensors to each animal on the farm to monitor the animal's health and location. Data from these sensors allows the farmer to respond to the ever-changing health status of the animals, but this is only possible if the sensor data is collected and converted into a usable format to provide meaningful information to the farmer in real time. Farmers may not have the resources to provide engineers to build large-scale analysis packages, and the resulting information may remain unused.

[0016] FIG. 1 illustrates representative major components of an exemplary computer system 100 (alternatively, a computer) that can be used in accordance with some embodiments of the present disclosure. It should be understood that the individual components may vary in complexity, number, type, or configuration, or combinations thereof. The specific example disclosed is presented for illustrative purposes only and does not necessarily represent all such variations. Computer system 100 may include a processor 110, memory 120, an input / output interface (herein I / O or I / O interface) 130, and a main bus 140. Main bus 140 may provide a communication path for other components of computer system 100. In some embodiments, main bus 140 may be connected to other components, such as a dedicated digital signal processor (not shown).

[0017] The processor 110 of the computer system 100 may be comprised of one or more cores 112A, 112B, 112C, and 112D (collectively 112). The processor 110 may further include one or more memory buffers or caches (not shown) that provide temporary storage of instructions and data for the cores 112. The cores 112 may execute instructions on input provided from the cache or memory 120 and output results to the cache or memory. The cores 112 may be comprised of one or more circuits configured to perform one or more methods according to embodiments of the present disclosure. In some embodiments, the computer system 100 may include multiple processors 110. In some embodiments, the computer system 100 may be a single processor 110 having a single core 112.

[0018] The memory 120 of the computer system 100 may include a memory controller 122. In some embodiments, the memory 120 may include a random-access semiconductor memory, storage device, or storage medium (either volatile or non-volatile) for storing data and programs. In some embodiments, the memory may be in the form of a module (e.g., a dual in-line memory module). The memory controller 122 may communicate with the processor 110 to facilitate the storage and retrieval of information in the memory 120. The memory controller 122 may communicate with the I / O interface 130 to facilitate the storage and retrieval of input or output in the memory 120.

[0019] The I / O interface 130 may include an I / O bus 150, a terminal interface 152, a storage interface 154, an I / O device interface 156, and a network interface 158. The I / O interface 130 may connect the main bus 140 to the I / O bus 150. The I / O interface 130 may direct instructions and data from the processor 110 and memory 120 to various interfaces of the I / O bus 150. The I / O interface 130 may also direct instructions and data from the various interfaces of the I / O bus 150 to the processor 110 and memory 120. The various interfaces may include the terminal interface 152, the storage interface 154, the I / O device interface 156, and the network interface 158. In some embodiments, the various interfaces may include a subset of the aforementioned interfaces (e.g., an embedded computer system for industrial applications may not include the terminal interface 152 and the storage interface 154).

[0020] Logical modules throughout computer system 100 (including, but not limited to, memory 120, processor 110, and I / O interface 130) can communicate faults and changes to one or more components to a hypervisor or operating system (not shown). The hypervisor or operating system can allocate the various resources available to computer system 100 and track the location of data in memory 120 and the location of processes assigned to the various cores 112. In embodiments that combine or rearrange elements, aspects and capabilities of the logical modules can be combined or rearranged. These variations will be apparent to those skilled in the art.

[0021] I. Stream Computing Stream computing can enable users to process big data and can continuously provide advanced metrics about the big data as it is being generated by various sources. A stream application can provide stream computing by creating a configuration of one or more processing elements, where each processing element includes one or more stream operators. For example, a stream application can be compiled with fixed logic contained in each processing element and / or stream operator. Each processing element and / or stream operator of a stream application can process big data by generating and modifying information in the form of tuples. Each tuple can have one or more attributes (e.g., a tuple can be similar to a row in a table, and an attribute can be similar to a column in a table).

[0022] A stream application can deploy instances of a configuration to a set of hardware compute nodes. The stream application can then manage the instances by coordinating the hardware to run the stream application as configured, such as by load balancing processing elements on the compute nodes, on a subset of given compute nodes, or across multiple compute nodes.

[0023] 2 illustrates an exemplary stream computing application (stream application) 200 configured to operate on a stream of tuples, according to some embodiments of the present disclosure. Stream application 200 may be represented in the form of an operator graph 202. Operator graph 202 may visually represent to a user the flow of data through stream application 200. Operator graph 202 may define how tuples are routed through various components of stream application 200 (e.g., a pre-compiled logical layout of execution paths, processing, and resource allocations, represented by curved arrows in FIG. 2). Stream application 200 may include one or more computing nodes 210-1, 210-2, 210-3, and 210-4 (collectively 210), a development system 220, a management system 230, one or more processing elements 240-1, 240-2, 240-3, 240-4, 240-5, and 240-6 (collectively 240), one or more stream operators 242-1, 242-2, 242-3, 242-4, 242-5, 242-6, 242-7 (collectively 242), and a network 250.

[0024] The stream application 200 can receive information from one or more sources 244. The stream application 200 can output information to one or more sinks 246. Inputs can also be from outside the stream application 200, such as from Internet of Things (IoT) devices. The stream network 250 can be a communication layer that handles connections and sends and receives data between portions of the stream application 200. For example, the stream network 250 can be a transport layer for data packets internal to the stream application 200 and can be configured to communicatively couple the processing elements 240.

[0025] The configuration of stream application 200 depicted by operator graph 202 is merely an example stream application. A stream application may vary the number of compute nodes, processing elements, or stream operators. A stream application may also vary the roles and / or responsibilities performed by any of the components, or may include other components not shown. For example, some or all of the functions of development system 220 may be performed by management system 230. In another example, the functions of development system 220 and management system 230 may be performed by a single management system (not shown). The management system may be configured to perform these tasks without departing from the embodiments disclosed herein. In yet another example, the functions of development system 220 and management system 230 may be performed by multiple services (e.g., 10 or more separate software programs, each configured to perform a specific function).

[0026] Compute nodes 210 may be computer systems, each including the following components: a processor, memory, and an input / output interface (here, I / O). Each compute node 210 may also include an operating system or hypervisor. In some embodiments, compute nodes 210 may perform operations for development system 220, management system 230, processing elements 240, or stream operators 242, or a combination thereof. Compute nodes 210 may be categorized as management hosts, application hosts, or mixed-use hosts. A management host may perform operations for development system 220, management system 230, or both. An application host may perform operations for processing elements 240 and stream operators 242. A mixed-use host may perform operations of both a management host and an application host. FIG. 1 illustrates a computer system 100, which may be a compute node according to some embodiments.

[0027] A network (not shown) may communicatively couple each of the nodes 210 to one another (e.g., a local area network, the Internet). For example, node 210-1 may communicate with nodes 210-2, 210-3, and 210-4 through the network. The computing nodes 210 may communicate with the network via I / O. The network may include various physical communication channels or links. The links may be wired, wireless, optical, or any other suitable medium. The network may include various network hardware and software, such as routers, switches, or bridges, for performing routing, switching, and other functions. The nodes 210 may communicate through various protocols (e.g., Internet Protocol, Transmission Control Protocol, File Transfer Protocol, Hypertext Transfer Protocol, etc.). In some embodiments, the nodes 210 may share the network with other hardware, software, or services (not shown).

[0028] The development system 220 can provide a user with the ability to create stream applications targeted to process specific data sets. The development system 220 can operate on an instance of a computer system (not shown), such as computer system 100. The development system 220 can operate on one or more of the compute nodes 210. The development system 220 can generate one or more configuration files that describe the stream computing application 200 (e.g., processing elements 240, stream operators 242, sources 244, sinks 246, allocation of the aforementioned compute nodes 210, etc.). The development system 220 can receive a request from a user to generate the stream application 200. The development system 220 can receive a request from a user to generate other stream applications (not shown). The development system 220 can communicate with the management system 230 to convey the configuration for any stream applications that the development system 220 can generate.

[0029] Development system 220 can generate a configuration by considering performance characteristics of software components (e.g., processing elements 240, stream operators 242, etc.), hardware (e.g., compute nodes 210, network), and data (e.g., source 244, tuple format, etc.). In a first example, development system 220 can determine that the overhead of running processing elements 240-1, 240-2, and 240-3 together on compute node 210-1 results in better performance than running them on separate compute nodes. The better performance can be due to latency incurred by running processing elements 240-1, 240-2, and 240-3 over network 250 between compute nodes 210-1 and 210-2. In a second example, development system 220 may determine that placing stream operators 242-3, 242-4, 242-5, and 242-6 on a single processing element 240-5 would result in a larger memory footprint than the cache of the first processor of compute node 210-2. To conserve memory space within the cache of the first processor, development system 220 may decide to place only stream operators 242-4, 242-5, and 242-6 on the single processing element 240-5, despite the inter-process communication latency that comes with having two processing elements 240-4 and 240-5.

[0030] In a third example considering performance characteristics, development system 220 may identify a first operation (e.g., an operation executing on processing element 240-6 on compute node 210-3) of stream application 200 that requires a greater amount of resources. Development system 220 may allocate a greater amount of resources to support the execution of the first operation (e.g., running processing element 240-6 on compute node 210-4 in addition to compute node 210-3). Development system 220 may identify a second operation (e.g., an operation executing on processing element 240-1) within stream application 200 that requires a smaller amount of resources. Development system 220 may further determine that stream application 200 can operate more efficiently through increased parallelism (e.g., more instances of processing element 240-1). Development system 220 may create multiple instances of processing element 240-1 (e.g., processing elements 240-2 and 240-3). Next, development system 220 can assign processing elements 240-1, 240-2, and 240-3 to a single resource (e.g., compute node 210-1). Finally, development system 220 can identify a third and a fourth operation (e.g., operations to be performed on processing elements 240-4 and 240-5), each of which requires a lower level of resources. Development system 220 can allocate a smaller amount of resources to these two different operations (e.g., have each operation share the resources of compute node 210-2 rather than executing on its own compute node).

[0031] The development system 220 may include a compiler (not shown) that compiles modules (e.g., processing elements 240, stream operators 242, etc.). The modules may be source code or other program statements. The modules may be in the form of requests from a stream processing language (e.g., a computing language containing declarative statements that allow a user to describe a specific subset of information formatted in a particular way). The compiler may convert the modules into object code (e.g., machine code targeted to a specific instruction set architecture of the compute node 210). The compiler may convert the modules into an intermediate form (e.g., virtual machine code). The compiler may be a just-in-time compiler that runs as part of an interpreter. In some embodiments, the compiler may be an optimizing compiler. In some embodiments, the compiler may perform peephole optimization, local optimization, loop optimization, interprocedural or whole-program optimization, machine code optimization, or any other optimization that reduces the time required to execute the object code, reduces the amount of memory required to execute the object code, or both.

[0032] Management system 230 can monitor and manage stream application 200. Management system 230 can run on an instance of a computer system (not shown), such as computer system 100. Management system 230 can run on one or more of the compute nodes 210. Management system 230 can also provide an operator graph 202 for stream application 200. Management system 230 can host services that make up stream application 200 (e.g., services that monitor the health of compute nodes 210, the performance of processing elements 240 and stream operators 242, etc.). Management system 230 can receive requests from users (e.g., requests to authenticate and authorize users of stream application 210, requests to view information generated by the stream application, requests to view operator graph 202, etc.).

[0033] The management system 230 can provide a user with the ability to create multiple instances of the stream application 200 configured by the development system 220. For example, if a second instance of the stream application 200 is required to perform the same processing, the management system 230 can allocate a second set of compute nodes (not shown) for execution of the second instance of the stream application. The management system 230 can also reallocate compute nodes 210 to eliminate bottlenecks in the system. For example, as shown, processing elements 240-4 and 240-5 are executed by compute node 210-2. Processing element 240-6 is executed by compute nodes 210-3 and 210-4. In some situations, the stream application 200 may experience performance issues because processing elements 240-4 and 240-5 are not providing tuples to processing element 240-6 before processing element 240-6 becomes idle. Management system 230 can detect these performance problems and reallocate resources from compute node 210-4 to execute some or all of processing elements 240-4, thereby reducing the workload on compute node 210-2. Management system 230 can also perform operating system operations for compute node 210, such as load balancing and resource allocation for processing elements 240 and stream operators 242. By performing operating system operations, management system 230 can enable stream application 200 to more efficiently use available hardware resources and improve performance (e.g., by reducing the overhead of the operating system and multiprocessing hardware of compute node 210).

[0034] The processing elements 240 may perform the operations of the stream application 200. Each of the processing elements 240 may operate on one or more of the compute nodes 210. In some embodiments, a given processing element 240 may operate on a subset of a given compute node 210, such as a processor of the compute node 210 or a single core of a processor. In some embodiments, a given processing element 240 may correspond to an operating system process of an operating system hosted by the compute node 210. In some embodiments, a given processing element 240 may operate on multiple compute nodes 210. The processing elements 240 may be generated by the development system 220. Each of the processing elements 240 may be in the form of a binary file and additional library files (e.g., an executable file and associated libraries, a package file containing the executable code and associated resources, etc.).

[0035] Each of processing elements 240 may include configuration information from development system 220 or management system 230 (e.g., resources and protocols required by its assigned associated compute node 210, identities and credentials needed to communicate with sources 244 or sinks 246, and identities and credentials needed to communicate with other processing elements). Each of processing elements 240 may be configured by development system 220 to optimally execute on one of compute nodes 210. For example, processing elements 240-1, 240-2, and 240-3 may be compiled to execute with optimizations recognized by the operating system running on compute node 210-1. Processing elements 240-1, 240-2, and 240-3 may also be optimized for the particular hardware of compute node 210-1 (e.g., instruction set architecture, configured resources such as memory and processors, etc.).

[0036] Each of the processing elements 240 can include one or more stream operators 242 that perform the basic functions of the stream application 200. As the stream of tuples flows through the processing elements 240 as directed by the operator graph 202, the tuples proceed from one stream operator to another (e.g., a first processing element can process a tuple and place the processed tuple in a queue assigned to a second processing element; the first stream operator can process a tuple and write the processed tuple to a region of memory designated for the second stream operator; the processed tuple may not be moved but may be updated with metadata to indicate that it is ready for processing by a new processing element or stream operator, etc.). Multiple stream operators 242 within the same processing element 240 can benefit from architectural efficiencies (e.g., reduced cache misses, sharing of variables and logic, reduced memory swapping, etc.). The processing elements 240 and stream operators 242 can utilize inter-process communication (e.g., network sockets, shared memory, message queues, message passing, semaphores, etc.). Processing elements 240 and stream operators 242 may utilize different inter-process communication techniques depending on the configuration of stream application 200. For example, stream operator 242-1 may use semaphores to communicate with stream operator 242-2, processing element 240-1 may use message queues to communicate with processing element 240-3, and processing element 240-2 may use network sockets to communicate with processing element 240-4.

[0037] Stream operators 242 can perform the basic logic and operations of stream application 200 (e.g., processing tuples and passing processed tuples to other components of the stream application). By separating logic that might occur within a single large program into basic operations performed by stream operators 242, stream application 200 can provide greater scalability. For example, dozens of compute nodes hosting hundreds of stream operators in a given stream application can enable the processing of millions of tuples per second. The logic can be created by development system 220 before run-time of stream application 200. In some embodiments, sources 244 and sinks 246 can also be stream operators 242. In some embodiments, sources 244 and sinks 246 can link multiple stream applications together (e.g., source 244 can be a sink for a second stream application, and sink 246 can be a source for a third stream application). Stream operators 242 can be configured by development system 220 to optimally execute stream application 200 using available compute nodes 210. Stream operators 242 can send tuples to and receive tuples from other stream operators. Stream operators 242 can receive tuples from sources 244 and send tuples to sinks 246.

[0038] Stream operators 242 can perform operations on tuple attributes (e.g., conditional logic, iterative loop structures, type conversions, string formatting, filter statements, etc.). In some embodiments, each stream operator 242 can perform only very simple operations and pass the updated tuple to another stream operator in stream application 200 (simple stream operators may be more scalable and easier to parallelize). For example, stream operator 242-2 can receive a date value with a particular precision, round the date value to a lower precision, and pass the modified date value to stream operator 242-4, which can change the modified date value from a 24-hour format to a 12-hour format. A given stream operator 242 may not modify anything about a tuple. A stream operator 242 can perform operations on a tuple by adding a new attribute or removing an existing attribute.

[0039] Stream operator 242 can operate on a stream of tuples by routing some tuples to a first stream operator and other tuples to a second stream operator (e.g., stream operator 242-2 sends some tuples to stream operator 242-3 and other tuples to stream operator 242-4). Stream operator 242 can operate on a stream of tuples by filtering some tuples (e.g., culling some tuples and passing a subset of the stream to another stream operator). Stream operator 242 can also operate on a stream of tuples by routing part of the stream to itself (e.g., stream operator 242-4 can perform simple arithmetic operations and, as part of its operation, perform a logical loop to direct a subset of tuples to itself). In some embodiments, a particular tuple output by a stream operator 242 or processing element 240 may not be considered to be the same tuple as the corresponding input tuple, even if the input tuple is not modified by the stream operator or processing element.

[0040] In some situations, stream applications may be primarily static big data manipulation mechanisms. Once configured, such stream applications may not be able to change the context they provide to users. For example, after developing operator graph 202, development system 220 may provide the generated form of the operator graph, along with the configuration of stream application 200, to management system 230 for execution by compute nodes 210. Furthermore, in some situations, such stream applications execute specific logic in the way they process tuples. Once configured, this logic may not be updatable or changeable until a new stream application is compiled. Attempting to provide updates to the processing elements or stream operators of such configured stream instances may be impractical due to the real-time, continuous nature of stream applications and the information they process. For example, even microseconds of downtime may cause the stream application to miss one or more tuples during the switchover from the originally configured processing elements to the updated processing elements. The missing data may result in partial or complete failure of the stream application, preventing the stream application from providing context for the big data source to users.

[0041] Another problem can arise when too much or too little data flows through a stream application. For example, the logic of a given stream operator may provide a stream application that processes only a subset, selection, or part of the tuples. If too few tuples are processed based on the stream operator configuration, poor analysis values ​​may occur because the data set is too small to derive meaning from. To compensate for this, a pre-compiled stream application can be configured to ingest and process many tuples. If too many tuples are processed based on the stream operator configuration, a bottleneck may occur in the system (e.g., processor or memory exhaustion). In another example, one or more tuples may be dropped because part of the stream application is overwhelmed (e.g., one or more compute nodes may not process certain tuples when a large number of tuples are received). For example, if too much data (too many tuples) is inundated into a stream application, random tuples may be dropped, or the system may back up and crash.

[0042] Suboptimal configuration of a stream application may not be due to negligence or malice, but rather may be based on practical considerations. In particular, a given stream application may be generated based on the type or volume of test data created during the development phase of the stream application. Because big data analysis is a relatively new phase in computing, it may be difficult to predict or anticipate the type, volume, and optimal route of tuple processing in a stream application. For example, a stream application 200 may be developed by a development system 220 based on test data or based on sources 244 that were under a different set of conditions. As a result, the development system 220 may allocate computing resources and data flows (as represented by the curves in FIG. 2 ) based on an incomplete or outdated understanding of data processing. As analysis of the situation progresses, the configuration of the operator graph 202 may fail to address actual issues in the production data or real-world events or information updates that are changing (thus affecting the type or volume, or both, of data coming from the sources 244).

[0043] Given these shortcomings, developing a real-time analysis application can be practically necessary to address many different factors. The first factor is the need for static analysis of good and bad data formats, values, etc. before developing the application. This need for static analysis may be necessary to properly develop and configure the data analysis system. The second factor may be planning for many failure scenarios, source changes, or incorrect assumptions about the data. For example, data processing can be based on assumptions about the data provided by the source and how to optimally process that data. These assumptions may help design and configure the various stream operators, processing elements, and the flows between them before compiling, instantiating, and executing them. The same assumptions may later lead to problems during the actual operation and runtime of the stream application (e.g., incorrect data tuple formats, data tuple value checks, or other misalignments between configuration and data). The third factor is the need to restart one or more parts of a data analysis or processing system for various reasons to enable specific functionality or to allow for configuration changes in a given system's logic or supporting non-core logic. Examples of scenarios that may lead to a stream application restart include changing logging levels, performing increased transaction processing, or alleviating resource bottlenecks by adjusting the conditions for tuple processing (e.g., tuple forwarding, addition, or deletion).

[0044] One attempt to solve such problems could be to use a microservices architecture. A microservices architecture could attempt to use small applications that subscribe to data streams, perform several functions, and then publish them. A microservices architecture can be an incomplete or partial solution. For example, a streaming application or analytics application needs to know and be aware of all potential subscription plans before deployment and runtime. Stream applications cannot be configured for all situations, and on the downside, they may have to be restarted to reconfigure or deploy the output of certain parts of the stream (e.g., the output of a processing element or stream operator) to correct these imperfections.

[0045] Another attempt to address these shortcomings could be a job overlay architecture. Job overlay architectures focus on determining the potential need to execute specific program logic on a running data analysis application, but this particular architecture may also have shortcomings for stream applications. For example, a job overlay architecture may focus on modifying a portion of the core logic ("job logic") of a portion of a stream application, saving the new logic in the application bundle, and applying those changes to the running portion. However, this solution does not solve the availability problem because updating the job logic requires restarting the running process. For example, portions of a stream application may not be modifiable once they are running.

[0046] II. Aspect-Aware Stream Computing Aspect-Aware Stream Computing ("AASC") can overcome problems associated with other types of data analysis in the context of stream applications. AASC can enable stream applications to operate based on one or more aspect-oriented programming techniques. AASC can include exposing request processing logic ("hooks") for receipt of aspects. The hooks can be in the form of a generic program execution structure. The generic program execution structure can be configured to receive or consume any code, rules, or other logic provided by a requester. AASC can affect the behavior of a stream application through execution by the generic program execution structure. Specifically, a request can be sent that includes a set of one or more program code instructions. The set of program code instructions can operate on a stream of tuples and outside of the logic embedded in the stream application's stream operators and / or processing elements.

[0047] The AASC can be configured to affect core or tertiary functionality of the stream application. In particular, the stream application can have a first configuration that is developed before runtime and that is put into practice and operates during runtime and operation of the stream application. The generic program execution structure may execute during operation of the stream application or may execute outside of operation of the stream application. In a first example, the generic program execution structure may execute a set of program code instructions immediately before or after a portion of the stream application, or both. The rules can change the functionality of the stream application by rerouting, updating, deleting, adding, or otherwise modifying one or more tuples of the stream application.

[0048] In some embodiments, the AASC can operate by encapsulating a portion of a stream application (e.g., a stream operator, a processing element). Encapsulating a portion of a stream application can include executing a generic program execution structure (configured to execute a received set of program code instructions) immediately outside of the logic that constitutes that portion. For example, encapsulation can be configured as the first program step after or the last program step before any code that is part of a given stream operator. Encapsulating a portion of a stream application can include executing the generic program execution structure as an initial step or a final step of that portion of the stream application. For example, encapsulation can be configured as the first program step, the last program step, or both of a given stream operator.

[0049] AASC can operate without affecting the availability and execution of stream applications. Specifically, AASC causes no downtime to running applications, and the core logic of each stream operator and processing element, which executes based on pre-compiled logic, remains unaffected or unchanged. For example, a first stream operator can be configured to operate on tuples based on filter statements or other logic to affect only certain tuples in a stream of tuples and ignore or pass other tuples in the stream of tuples. A generic program execution structure can execute a set of program code instructions immediately before, after, outside, or separate from the stream application's original compiled logic. As a result, only the stream application's effects (e.g., receiving, modifying, creating, deleting, and outputting tuples) change; the core logic remains unchanged.

[0050] AASC can provide advantages over other methods of stream computing. Specifically, AASC can facilitate the rapid or temporary introduction and / or removal of aspects that can perform various functions without bouncing, restarting, or otherwise temporarily taking the stream application offline. AASC can facilitate the continuous delivery of aspects to actively running pre-compiled stream applications. Stream application scalability through AASC may be technically necessary in environments where stream applications perform mission-critical or other infrastructure operations. For example, a power plant may operate based on a stream application by monitoring multiple sensors that observe various energetic particles, chemical mixtures, and the like. AASC can also facilitate stream application developers and administrators to tune or modify the stream application (e.g., to address changing source data and to improve the accuracy of calculations performed by the stream application). Adjustments or modifications can be made while the stream application is running without risking potential data loss or requiring reconfiguration, testing, and restarting the stream application. AASC can utilize dynamic proxy conventions such as Java Dynamic Proxies™.

[0051] AASC's program code instruction injection aids in debugging applications through logging or other telemetry. Program code instruction injection can allow or deny, or both, specific elements or connections for security reasons. Program code instruction injection can promote higher uptime and stream availability by facilitating rerouting data to available services when downstream network or compute nodes, or both, are down or otherwise offline. Program code instruction injection can improve data accuracy by running one or more data integrity routines to validate specific tuples. Program code instruction injection can allow a production environment to demonstrate functionality by inserting demo data (e.g., tuples containing demo data) along with a first set of program code instructions throughout a portion of a stream application. For example, a first portion of a stream application can be placed immediately before a subset of processing elements or stream operators, or both.

[0052] The AASC may utilize a first generic program execution structure immediately preceding the subset to execute a set of program code instructions configured to insert demo tuples into the stream application. A subset of the processing elements or stream operators or both may operate on the demo tuples to generate, modify, or otherwise create tuples based on the demo tuples. A second set of program code instructions may be executed by a second generic program execution structure located immediately after the subset of stream applications. The second set of program code instructions may be configured to extract tuples created based on the demo tuples. Further, the second set of program code instructions may be configured to identify existing tuples that were modified by the subset of stream applications as a result of the demo tuples and undo the modifications.

[0053] 3 illustrates an exemplary stream application 300 configured as an AASC, in accordance with some embodiments of the present disclosure. The stream application 300 may be represented in the form of an operator graph 302. The operator graph 302 may provide a visual representation to a user of the flow of data through the stream application 300. The operator graph 302 may be configured similarly to the operator graph 202 of FIG. 2, except that for clarity, the operator graph 302 does not include lines representing the flow of tuples throughout the stream application 300. The operator graph 302 may define how tuples are routed through the various components of the stream application 300 (e.g., a pre-compiled logical layout of execution paths, processing, and resource allocations). Stream application 300 may include one or more compute nodes 310-1, 310-2, 310-3, and 310-4 (collectively 310), a development system 320, a management system 330, one or more processing elements 340-1, 340-2, 340-3, 340-4, 340-5, and 340-6 (collectively 340), one or more stream operators 342-1, 342-2, 342-3, 342-4, 342-5, 342-6, 342-7 (collectively 342), and a network 350. Stream application 300 may further include multiple general-purpose program execution structures. Specifically, a first plurality of generic program execution structures 362-1, 362-2 (collectively 362), a second plurality of generic program execution structures 364-1, 364-2 (collectively 364), a third plurality of generic program execution structures 366-1, 366-2, 366-3, 366-4 (collectively 366), and a fourth plurality of generic program execution structures 368-1, 368-2. The stream application 300 may also include an aspect data store 370.

[0054] The stream application 300 can receive information from one or more sources 344. The stream application 300 can output information to one or more sinks 346. Inputs can also be from outside the stream application 300, such as from multiple IoT devices. The stream network 350 can be a communication layer that handles connections and sends and receives data between portions of the stream application 300. For example, the stream network 350 can be a transport layer for data packets internal to the stream application 300 and can be configured to communicatively couple the processing elements 340.

[0055] Each generic program execution structure 362, 364, 366, or 368 can be configured to receive, process, and execute requests. For example, generic program execution structure 364-2 can be configured as a request handler or hook that listens for requests to execute a set of program code instructions. In another example, generic program execution structure 362-1 can initiate execution of the received set of program code instructions in response to receiving the set of program code instructions. Each generic program execution structure 362, 364, 366, or 368 can operate through the use of stream network 350. For example, program execution structure 366-3 can operate through web sockets to accept connections from management system 330.

[0056] The generic program execution structures 362, 364, 366, or 368 can be configured by the management system 330. Specifically, the management system 330 can operate by default by not initiating, running, or otherwise providing processing cycles to any particular code outside of the stream application 300 (e.g., processing elements 340, stream operators 342). The management system 330 can operate in a preemptive aspect-aware mode. For example, during operation of the stream application 300, the management system 330 can initiate program code for one or more of the generic program execution structures 362, 364, 366, or 368 even before receiving a request to execute a set of program code instructions. The management system 330 can operate in a reactive aspect-aware mode. For example, during operation of the stream application 300, the management system 330 can not encapsulate any portion of the stream application 300 until receiving a request to execute a set of program code instructions. The stream application 300 can operate in a default aspect-aware mode. For example, at the beginning of data processing, the management system 330 can assign generic program code structures 362, 364, 366, 368 to portions of the stream application 300 in addition to assigning compute nodes 310 to processing elements 340 and stream operators 342.

[0057] Generic program execution structures 362, 364, 366, and 368 can each encapsulate a portion of stream application 300. Specifically, generic program execution structure 362-1 can be configured to occur logically immediately before processing elements 340-1, 340-2, and 340-3. Additionally, generic program execution structure 362-2 can be configured to occur logically immediately after processing elements 340-1, 340-2, and 340-3. As a result, any set of program code instructions dispatched to generic program execution structure 362-1 can be executed immediately before processing elements 340-1, 340-2, and 340-3. Any set of program code instructions dispatched to generic program execution structure 362-2 can be executed immediately after processing elements 340-1, 340-2, and 340-3, respectively. As a result of the encapsulation, a set of program code instructions dispatched to generic program execution structure 362 can operate on a stream of tuples immediately before or after they are processed by processing elements 340-1, 340-2, and 340-3. As a result, stream operators 342-1 and 342-2 can also be affected by generic program execution structure 362.

[0058] A given portion of a stream application to be encapsulated may be multiple processing elements. For example, multiple processing elements 340-1, 340-2, and 340-3 may all be encapsulated by only two generic program execution structures 362-1 and 362-2, respectively. A given portion of a stream application to be encapsulated may be a single processing element. For example, generic program execution structures 364-1 and 364-2 may encapsulate a single processing element 340-4. A given portion of a stream application to be encapsulated may be multiple stream operators. For example, generic program execution structures 366-1 and 366-2 may encapsulate stream operators 342-4 and 342-6. A given portion of a stream application to be encapsulated may be a single stream operator. For example, generic program execution structures 366-3 and 366-4 may encapsulate stream operator 342-5.

[0059] Computing resources may be allocated by the stream application 300 to the generic program execution structures 362, 364, 366, 368. The allocated computing resources may be portions of the computing resources that execute the stream application 300. For example, one or more of the compute nodes 310 may be assigned to process the generic program execution structures 362, 364, 366, 368. The allocation and / or allocation of processing cycles and memory may be based on the operator graph 302 and on the layout of portions of the stream application 300. For example, generic program execution structures 362-1 and 362-2 may be assigned to compute node 310-1 based on the structures 362-1 and 362-2 encapsulating portions of the stream application (e.g., stream operator 342-1, processing element 340-2) that are also assigned to compute node 310-1. In another example, generic program execution structures 366-3 and 366-4 can be assigned to a first execution thread on compute node 310-2 based on the configuration that stream operator 342-5 is also assigned to the first execution thread. Allocating similar threads or other multiprocessing structures as part of encapsulation can provide performance efficiencies (e.g., reducing thread lock contention, eliminating process deadlocks, reducing inter-process communication). Generic program execution structures 362, 364, 366, and 368 can be assigned to computing resources on another computer (not shown) outside of stream application 300. Allocation to another computer can improve performance of stream application 300 by allowing additional computing resources to process the stream of tuples. Each generic program execution structure 362, 364, 366, and 368 can be configured to receive and execute program code instructions outside of the preconfigured operation of stream application 300.For example, a given stream operator 342-1 or processing element 340-2 may be configured and compiled to operate on a first subset of tuples, and a corresponding generic program execution structure 366-3 or 366-4, or both, may be configured to operate on tuples outside the first subset of tuples.

[0060] Management system 330 can be configured to respond to requests to execute program code instructions, such as request 380. Request 380 can be an example of a request provided to AASC stream application 300. Request 380 can be received from a user.

[0061] The request 380 may include a set of program code instructions. The set of program code instructions may be in the form of a package or other suitable software construct, such as in the form of an aspect bundle. The set of program code instructions may include a compiled software library. The compiled software library may be configured in an executable format compatible with a particular portion of a stream application. For example, the stream operator 342-7 may be configured in a first software language, and the set of program code instructions may be required to be in that first software language in order to be executable when directed to the general-purpose program execution structure 368-1 or 368-2. The set of program code instructions may be written only in a particular set of approved interfaces. For example, an implementation of a single function may accept and return a data tuple using a tuple schema defined by the approved interface.

[0062] Request 380 may also include a set of program execution instructions. The set of program execution instructions may include a stream application target. A stream application target may be a particular processing element or stream operator of a given stream application. For example, request 380 may include a stream application target that includes a stream operator identifier that specifically identifies stream operator 342-5. Thus, request 380 may indicate that the included set of program code instructions is to be executed by generic program execution structures 366-3 and 366-4 (e.g., generic program execution structures encapsulating stream operator 342-5).

[0063] The management system 330 can instruct at least one of the general program execution structures 362, 364, 366, or 368 to execute a received set of program code instructions (e.g., program code instructions that are part of the request 380). The specific portion of the set of portions of the stream application 300 can be based on the request 380. Specifically, the specific portion can specify a portion of instructions that the network 350 can receive (e.g., a given stream operator 342 based on an existing job ID, location, or port) and a set of program code instructions to be executed. The management system 330 can identify a specific stream application target based on the request. For example, the request 380 can include a specific type of stream operation, such as all “SET” operations, applicable to an include set of program code instructions. In response, the management system 330 can traverse the operator graph 302 to identify one or more stream operators 342 or a subset of processing elements 340 that perform the “SET” operation. The management system 330 can instruct a given generic program execution structure 362, 364, 366, or 368 to execute a received set of program code instructions under one or more conditions (e.g., a number of times to execute the program code instructions, to execute the program code instructions for a certain amount of time, to execute the program code instructions before or after one or more conditions, or that an input or output occurs on the part of the stream application 300). The condition can be received as part of the program execution instruction, such as as part of the request 380.

[0064] The management system 330 may also store the program code instructions for later use. Specifically, once the management system 330 receives the request 380, the management system 330 may store the set of program code instructions in the aspect data store 370. The aspect data store 370 may be a database, memory, tertiary storage, or other data structure configured to store aspect bundles and other program code instructions. Storing in the aspect data store 370 may enable high availability of the AASC for the stream application 300. Future requests may only need to identify a particular set of program code instructions (e.g., by file name or other unique identifier). In response to receiving a request with an identifier but without a particular set of program code instructions, the management system 330 may be configured to scan the aspect data store 370 to retrieve the stored set of program code instructions. Other requests from different users may identify a particular set of program code instructions by the identifier and be executed at different times.

[0065] Management system 330 can operate in a security mode. Specifically, management system 330 can be configured to handle authentication and authorization of submitted requests. Any submitted request can be authorized by management system 330 before being allowed to pass to a particular general-purpose program execution structure 362, 364, 366, or 368. Management system 330 and any requester can communicate through a secure communication channel (e.g., over an encrypted network, using public / private certificates). Requesters can be prevented from directly executing sets of program code instructions, but can only submit and authenticate them through management system 330.

[0066] The AASC of the stream application 300 can facilitate an extensible set of enhancements that can be invoked during stream computing operations. Specifically, for stream applications that result in specific use cases, various sets of program code instructions can be executed by one or more of the general-purpose program execution structures 362, 364, 366, or 368, or combinations thereof, to perform various operations. For example, a first use case can be tuple creation and injecting, which can serve as a dynamic source of tuples to inject into stream operators for stream replay, operator logic debugging, and on-demand tuple processing. In another example, a second use case can be tuple validation, which checks whether a tuple is valid according to a schema or within a valid range; further, the set of program code instructions can be configured to drop tuples that can be determined to be invalid. In yet another example, a third use case can be tuple transformation, which includes dynamic custom logic that can be added to manipulate specific tuples.

[0067] Other enhancements facilitated by AASC of the stream application 300 include sets of program code for logging, debugging, profiling, notification, caching, rerouting, dropping, and transaction processing. In a first example, logging can be performed through debug or audit logging, which can be configured to include a given user, data, time, and whether the operation was successful. In a second example, profiling can be performed by determining how long it takes the stream operator 342 to process a tuple by comparing timestamps before and after the processing occurs. In a third example, notification can be sent when certain criteria defined in a set of program code instructions are met. In a fourth example, caching can be performed based on program code instructions configured to save a particular tuple for offline processing. In a fifth example, rerouting can be performed based on program code instructions defining rules for routing a particular tuple to another stream operator, such as when a first stream operator is overloaded or experiencing a particular performance issue. In a sixth example, dropping can be performed based on program code instructions defining rules for dropping tuples, for example, to alleviate an overloaded stream operator, or based on updated filtering conditions. In a seventh example, transaction processing can be based on program code instructions that cause a single tuple of data to be split into multiple tuples. The logic of the seventh example can include program code instructions that gate the progress of tuple processing only if all tuples of a transaction have been received by a given stream operator 342. In an eighth example, security can be based on program code instructions configured to block data from particular connections or users that are deemed malicious.

[0068] FIG. 4 illustrates a method 400 for performing aspect-aware stream computing in accordance with some embodiments of the present disclosure. Method 400 may generally be implemented with fixed-function hardware, configurable logic, logic instructions, etc., or any combination thereof. For example, logic instructions may include assembler instructions, ISA instructions, machine instructions, machine-dependent instructions, microcode, state setting data, integrated circuit configuration data, state information for personalizing electronic circuits, or other structural components specific to hardware (e.g., a host processor, a central processing unit / CPU, a microcontroller, etc.), or a combination thereof. Method 400 may be performed by a single computer, such as computer system 100. Method 400 may be performed by a stream application, such as stream application 400.

[0069] From start 405, method 400 may begin by monitoring activity of a stream application. Monitoring the stream application may be performed by determining whether one or more processing elements and / or stream operators of the stream application are operational and configured to actively process a stream of tuples.

[0070] If the stream application is active, i.e., Y, at 420, the method 400 may continue by listening for program requests at 430. Listening for program requests may be performed by parts of the stream application. For example, a management system for the stream application may operate by listening for requests.

[0071] If a program request is received at 440, i.e., Y, then method 400 may continue at 450 by identifying a target of the stream application. Specifically, the request may include a specific stream operator or processing element (e.g., based on an identifier) ​​that is the target of the request. The request may include a specific type, category, or group of portions of the stream application. For example, the request may include a stream application target that specifies "any SET stream operator." The request may not include a stream application target, but may indirectly identify a stream application target. For example, the request may include a specific identifier of a set of program code instructions to be executed. The request may not include a target, but may include only identifiers of the program code instructions. Upon receiving the request, a program repository (e.g., aspect data store 370) may be scanned, searched, or otherwise accessed. Identifying the target of the stream application may be done by retrieving the program code instructions from the program repository and scanning the program code instructions for the portion of the stream application processed by the program code instructions.

[0072] Portions of a stream application may be encapsulated at 460. The stream application may be encapsulated in a generic program execution structure configured to receive and execute program code instructions. The stream application may be encapsulated during execution of the stream application. For example, a given stream operator or processing element may be configured with a first input and a first output. The first input may be configured to receive a plurality of tuples of a stream of tuples, and the first output may be configured to output a second plurality of tuples of the stream of tuples. A given stream operator or processing element may also be configured with a second input, which may be configured to receive an aspect flag, such as a Boolean or numeric value. By default, when execution of a stream application begins, the default configuration of the stream operator or processing element is to operate without any reachable or operational generic program execution structure. Without receiving any aspect flags, the stream application cannot operate with generic program execution structures. Upon receiving the flags, the stream application may begin operation with the encapsulated generic program execution structure.

[0073] At 470, the portion of the stream application may execute the identified program code instructions. The portion of the stream application may be a set of one or more processing cycles outside the portion of the stream application, such as a management system or other portion that is not part of the pre-compiled logic of the stream application, and may send the program code instructions to a generic program execution structure. The generic program code execution structure may execute the program code instructions. After the program code instructions are executed, method 400 may continue by monitoring the stream application at 410. If the stream application is not active at 410, i.e., N, method 400 may end at 495.

[0074] The present invention may be a system, method, or computer program product, or combination thereof, at any possible level of technical detail of the collection. The computer program product may include one or more computer-readable storage media having computer-readable program instructions thereon for causing a processor to perform aspects of the present invention.

[0075] A computer-readable storage medium may be any tangible device capable of holding and storing instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, or semiconductor storage device, or any suitable combination of the above. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disks (DVDs), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge structures in grooves having instructions recorded thereon, and any suitable combination of the above. As used herein, computer-readable storage media is not to be construed as transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses through a fiber optic cable), or electrical signals sent through wires.

[0076] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to each computing / processing device, or may be downloaded to an external computer or storage device over a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may include copper transmission cables, fiber optic transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing / processing device.

[0077] The computer-readable program instructions for carrying out the operations of the present invention may be source or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or object-oriented programming languages ​​such as Smalltalk, C++, and conventional procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer-readable program instructions may run entirely on the user's computer, partially on the user's computer as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) can execute computer-readable program instructions by individualizing the electronic circuitry using state information of the computer-readable program instructions to implement aspects of the present invention.

[0078] Aspects of the present invention are described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0079] These computer-readable program instructions can be provided to a processor of a computer or other programmable data processing apparatus to produce a machine, whereby the instructions executed by the processor of the computer or other programmable data processing apparatus create means for performing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. The computer program instructions can also be stored in a computer-readable medium that can direct a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner, such that the computer-readable medium having instructions stored therein comprises an article of manufacture including instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0080] The computer program instructions may be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to generate a computer-implemented process, such that the instructions running on the computer, other programmable apparatus, or other device implement the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0081] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code, including one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions shown in the blocks may occur in an order different from that shown in the figures. For example, two blocks shown in succession may actually be accomplished as a single step, may be executed simultaneously, may be executed substantially simultaneously, may be executed in a partially or fully overlapping manner, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. It should also be noted that each block in the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a dedicated hardware-based system that performs the specified functions or operations, or may execute a combination of dedicated hardware and computer instructions.

[0082] The descriptions of various embodiments of the present disclosure have been presented for illustrative purposes, but they are not intended to be exhaustive or to be limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terms used herein have been selected to best explain the principles of the embodiments, practical applications, or technical improvements over the art found in the market, or to enable those skilled in the art to understand the embodiments disclosed herein.

Claims

1. 1. A method for processing a stream of tuples, comprising: monitoring a stream of tuples processed by a plurality of processing elements running on one or more compute nodes of a stream application, each processing element having one or more stream operators; receiving a program request to execute a first set of one or more program code instructions; identifying a stream application target for the first set of program code instructions based on the program request; encapsulating, during operation of the stream application, a first portion of the set of one or more portions of the stream application with a generic program execution structure, the generic program execution structure configured to receive and execute program code instructions outside of a pre-configured operation of the stream application; executing, during operation of the stream application, in response to the program request, by the generic program execution structure based on the stream application target, a first set of program code instructions during a first period of execution of the first portion of the stream application, wherein execution of the first set of program code instructions alters processing of the stream of tuples and occurs without taking the stream application offline; A method comprising:

2. 2. The method of claim 1, wherein the program request includes the first set of program code instructions.

3. 2. The method of claim 1, wherein the program request includes a program identifier associated with the first set of program code instructions.

4. The method of claim 3 , wherein the first set of program code instructions is located in a program repository.

5. The method of claim 4 , wherein the program repository is part of the stream application.

6. 2. The method of claim 1, wherein the program request includes a first set of one or more program execution instructions associated with the first set of program code instructions.

7. The method of claim 6 , wherein the first set of program execution instructions includes the stream application target.

8. 8. The method of claim 6 or claim 7, wherein the first set of program execution instructions includes a number of times to execute the first set of program code instructions.

9. 9. The method of claim 6, wherein the first set of program execution instructions includes an exit condition that causes execution of the first set of program code instructions to stop.

10. The method of claim 1 , wherein the first part of the set of parts of the stream application is a processing element of the stream application.

11. The method of claim 1 , wherein the first part of the set of parts of the stream application is a stream operator of the stream application.

12. 12. The method of claim 11, wherein the first period is before the stream application executes the stream operator and after the stream application executes any other portion of the set of portions of the stream application.

13. The method of claim 11 , wherein the first period of time is after the stream application executes the stream operator.

14. 12. The method of claim 11, wherein the first period is after the stream application executes the stream operator and before the stream application executes any other portion of the set of portions of the stream application.

15. encapsulating a second portion of the set of portions of the stream application in a second generic program execution structure during operation of the stream application; executing, during operation of the streaming application, in response to the program request, by the second generic program execution structure based on the streaming application target, the first set of program code instructions during a second period of execution of the second portion of the streaming application; 15. The method of any one of claims 1 to 14, further comprising:

16. The method of claim 1 , wherein the first set of program code instructions includes program code instructions for logging the operation of the streaming application.

17. 17. The method of claim 1, wherein the first set of program code instructions comprises program code instructions that generate one or more additional tuples.

18. encapsulating a second portion of the set of portions of the stream application in a second generic program execution structure during operation of the stream application; receiving a second program request to execute a second set of one or more program code instructions; identifying a second stream application target for the second set of program code instructions based on the second program request; executing, during operation of the stream application, in response to the second program request, by the second generic program execution structure based on the second stream application target, the second set of program code instructions during a second period of execution of the second portion of the stream application; 15. The method of any one of claims 1 to 14, further comprising:

19. a memory containing one or more instructions; a processor communicatively coupled to the memory, the processor responding to reading the one or more instructions to: monitoring a stream of tuples processed by a plurality of processing elements running on one or more compute nodes of a stream application, each processing element having one or more stream operators; receiving a program request to execute a first set of one or more program code instructions; identifying a stream application target for the first set of program code instructions based on the program request; encapsulating, during operation of the stream application, a first portion of the set of one or more portions of the stream application with a generic program execution structure, the generic program execution structure configured to receive and execute program code instructions outside of a pre-configured operation of the stream application; executing, during operation of the stream application and in response to the program request and based on the stream application target and by the generic program execution structure, a first set of program code instructions during a first period of execution of the first portion of the stream application, wherein the execution of the first set of program code instructions alters processing of the stream of tuples and is performed without taking the stream application offline; a processor configured to: Including, the system.

20. A computer program comprising program instructions arranged to cause a computer to perform the method of any one of claims 1 to 18.

21. 21. A computer readable storage medium having stored thereon a computer program according to claim 20.

Images