IBM Streams 4.2

Overriding application-wide settings

When you submit a job, you can optionally override several application-wide settings. For example, you might want to ignore all of the constraints that are specified in the bundle and define the appropriate constraints for your environment by specifying a job configuration overlay file or by configuring submission-time configuration parameters.

About this task

You can override application-wide settings from the IBM® Streams Console, IBM Streams Studio, or the streamtool submitjob command. However, if you use the streamtool submitjob command, you must use a job configuration overlay file to specify these settings. A job configuration overlay file is optional if you use IBM Streams Console or IBM Streams Studio.

Important: If you decide to override application-wide settings, you can alter the performance and behavior of the application. You should preview the job before you submit it to see how overriding these settings impacts how the application is deployed in your environment.

If you specify an of the following settings, the application might not behave the way the application developer intended.

You can modify the following application-level settings:

Relational placements
If you specify the ignoreBundleRelationalPlacements parameter, you can ignore relational placements that are specified in the application bundle file. For example, you might want to ignore relational placements from the application bundle file if the groups that are specified in the bundle are not relevant for the environment where you plan to run the application.

The following values are valid:
PARTITION

This option removes all the partition (or PE) constraints that are specified in the application bundle file (partitionIsolation, partitionColocationGroups, and partitionExlocationGroups). For example, you might want to ignore PE constraints if the operators would run more efficiently if they were grouped in different PEs.

HOST

This option removes all the host constraints that are specified in the application bundle file (hostIsolation, hostColocationGroups, hostExlocationGroups). For example, you might want to ignore the host placement constraints if the host constraints that are specified in the application bundle file do not apply to the instance where you are deploying the application.

ALL

This option removes all partition and host constraints.

NONE

This option leaves all of the relational placement constraints unchanged. This is the default value.
Host pool placement constraints
If you specify the ignoreBundleHostPlacements parameter and set the value to true, all of the operators are placed in the default host pool. For example, you might want to ignore host pool placement constraints that are specified in the application bundle file if the host pools that are specified in the application bundle file do not apply to the instance where you are deploying the application.
Threaded port queue size
If the specified threaded port queue size that is specified in the application bundle file creates a bottleneck or too much slack on the host where you plan to deploy the application, you can override the queue size by specifying the changeThreadedPortSettings parameter.

When you specify this parameter, you must specify a value for the queueSize parameter. The queue size must be an integer greater than or equal to 1. The default queue size for threaded ports is 1000 tuples.

If you adjust the size of the threaded port queue, ensure that you consider the processing requirements of the upstream operator compared to the downstream operators and the amount of memory on the host. A larger queue gives you more flexibility, especially if the downstream operators require a variable amount of processing power, but it also uses more memory. If the queue is too small and it fills up, the upstream operator must wait before it can add the current tuple to the queue.
Tag sets
You can override the host pool tags that are specified in the application bundle file by specifying the convertTagSet parameter. For example, if the tags are not available on the hosts in the instance where you plan to deploy the application, you can specify new tags for this deployment to use.
You can achieve the following types of tag conversions:
- One existing tag to one target tag
  If you want to achieve this type of conversion, create a tag set that contains only the specific existing tag and the specific target tag. If you specify multiple tags in either context, they are used interchangeably.
- One existing tag to multiple target tags
- Many existing tags to one target tag
- Many existing tags to many target tags
These tags are used only if a host pool contains all of the tags that you specified in the existing tag set.

If you want to add tags to the default host pool, add a tag set that does not specify any existing tags.

You can specify multiple TagConversion entries within the convertTagSet parameter. Each entry must include the following information:
originalTagSet

Specify the tags from the application bundle file that you want to convert.
The tags are converted only if a host pool contains all of the tags that you specify. If you specify a combination of tags that is not in any of the host pools, the tags are not converted. If you don't specify any tags, the target tags are added to the default host pool.

targetTagSet

Specify the tags from the hosts in this instance that you want to use as replacements.