Running applications

You can submit and run your applications in stand-alone or distributed runtime environments. In a stand-alone runtime environment, an application is a binary that you can launch directly, that is, it does not run on the Teracloud® Streams instance. In a distributed runtime environment, an application is run when you submit a application bundle file to a Teracloud® Streams instance.

Running applications in stand-alone mode

You run an application in a stand-alone mode when you execute the binary file with the name standalone in the output/bin directory.

When running applications in a stand-alone runtime environment, there are a few restrictions:

All operators are fused into a single PE.
The logging output goes to the standard output or standard error, depending on the launch options specified.
Imported and exported streams and associated functions do not work, such as subscription expressions and export properties.
Host pool information and host placement constraints are ignored.
The @view annotation is ignored.
There is no support for runtime interaction with Teracloud® Streams tools, such as the Streams Instance Graph view or the Streams Console.

Running applications in distributed runtime environments

When an application is compiled, a application bundle file is created. You run an application in a distributed runtime environment when you submit the application bundle file to a Teracloud® Streams instance. Except for system libraries, the application bundle file includes all toolkit artifacts and libraries that are needed to run the application.

When you submit a application bundle file, the Teracloud® Streams instance automatically transfers the file to the hosts where the application runs. Because your application bundle file contains all of the necessary toolkit artifacts, it can run on a file system different from where it was compiled. Thus, you can place the application bundle file on any Teracloud® Streams instance. Teracloud® Streams defines how your application is fused into processing elements (PEs) at submission time. This is based on the information provided at compile time and the runtime resources available.

Tip: For some application workflows, setting the domain.preloadApplicationBundles domain property or the instance.preloadApplicationBundles instance property to deploy a application bundle file on every application host within the instance can improve performance. The amount of improvement depends on how often the PE placements on the hosts get adjusted. Consider, however, that use of the preload feature might incur an additional storage requirement for the hosts, because the application bundle will be deployed on every host in the instance, whether the application is currently running on that host or not.

The following directories can be defined in the environment where the application runs.

Data directory: If your application reads or writes data from files, you need to define the data directory. It is a path to an existing directory, which is specified at compile or submission time, that operators can use to write files into or read files from. Your application can create or read a file relative to the data directory path. There is no default data directory. Before you run an application that requires a data directory, that data directory needs to be created and, if necessary, populated with the data files that the application processes. In a non-shared file system, the PEs containing operators that access the data directory need to be placed on resources that contain the data directory.
Application directory: When you run your application, the application directory points to a directory hierarchy that is determined by the domain where your application runs. This directory forms the root of the directory hierarchy to reference toolkit artifacts in the application bundle file. The domain.applicationBundlesPath domain property determines the location of the application directory. At compile time, the application directory refers to the directory within which the sc command is run, and where the compile artifacts are produced. At run time, the application directory refers to the location in the file system where the executable artifacts are placed and from which the application is run.
Working directory: When your application is run, the current directory is set to a working directory. The root location of a working directory is determined for each instance of your application with the domain.applicationCurrentWorkingPath domain property.