Contents
TIBCO® Streaming 11.1.3 adds the following updates and new features:
- A new parameter,
rebalanceOnNodeJoin, has been added to the configuration. -
This parameter is
trueby default.Configure this parameter to prevent automatic rebalancing when a node joins or rejoins the cluster. SetrebalanceOnNodeJointofalsewhen you prefer manual administration to choose when to rebalance, instead of permitting an automatic and immediate rebalance upon a new node joining a cluster.Configuration Example:
dataDistributionPolicies = { session-data-distribution-policy = { type = "DYNAMIC" dynamicDataDistributionPolicy = { numberOfPartitions = ${SESSION_STORE_NUMBER_OF_PARTITIONS:-80} rebalanceOnNodeJoin = false primaryDataRedundancy = { numberOfReplicas = ${NUM_SESSION_STORE_PRIMARY_REPLICAS:-2} replicationType = "${SESSION_STORE_PRIMARY_REPLICATION_TYPE:-SYNCHRONOUS}" } backupDataRedundancy = { numberOfReplicas = ${NUM_SESSION_STORE_BACKUP_REPLICAS:-2} replicationType = "${SESSION_STORE_BACKUP_REPLICATION_TYPE:-SYNCHRONOUS}" } } } }
- TIBCO Enterprise Streaming and TIBCO Enterprise Streaming - High-Performance FIX Engine Released
-
TIBCO Enterprise Streaming is a license package available starting in July 2025. TIBCO Enterprise Streaming permits you to use, at a given point in time, TIBCO Streaming, and the included TIBCO Streaming Standard Adapters, Enterprise Streaming Premium Adapters, and Enterprise Streaming - FIX Adapters, TIBCO LiveView™ Web Standard Edition, and TIBCO StreamBase® Add-in for Microsoft Excel, with your licensed version of TIBCO Enterprise Streaming.
TIBCO Enterprise Streaming - High-Performance FIX Engine is a license package available starting in July 2025. It includes TIBCO StreamBase® High-Performance FIX Engine.
For more information, see What is TIBCO Enterprise Streaming?.
- OSIsoft PI Adapter is now Aveva PI Adapter
-
This rebrand has no impact on your licenses, support, or existing functionality. Please reach out to your account representative for more information.
This section describes known limitations as of the current release of Spotfire Streaming. Each item includes a tracking number, description, and workarounds when possible.
Known limitations for using the EventFlow debugger are described separately, in the Limitations, Tips, and Tricks section of the Using the EventFlow Debugger page.
This section describes the known limitations in the current release of Spotfire LiveView™. Each item includes a tracking number, description, and whenever possible, one or more workarounds.
| ClusterAlert | Cluster-wide Alert Group Restriction for Heterogeneous Clusters | |
| Description | Nodes with only EventFlow engines in LiveView clusters must be in their own alert groups. | |
| Workaround | For more information, see Cluster-Wide Alerting guidelines | |
| SB-54280 | Deadlock when nodes start simultaneously. | |
| Description | Starting nodes simultaneously may lead to a race condition and subsequent deadlock during start-up. | |
| Workaround | Stagger the launch of each node in a multi-node cluster. | |
| SB‑46418 | Removing the lvweb.war dependency from a project's POM does not remove the file, and vice versa.
|
|
| Description | New LiveView Fragment projects are created by default with a dependency on the lvweb.war file that implements LiveView Web functionality. There are two cases: (1) If you later edit the project's pom.xml file to remove that <dependency> element, in which doing so does not automatically remove the lvweb.war file from the project's src/main/liveview/lv-user-webapps folder. (2) If you remove the lvweb.war file manually, the pom.xml is not automatically edited to remove the dependency.
|
|
| Workaround | In both cases, you must both remove the lvweb.war file and
edit the pom.xml file to remove a project's support for LiveView
Web.
The correct way to create a new LiveView project
without LiveView Web support is to change the |
|
| SB‑45720 | Failure to independently run or debug EventFlow modules in LiveView projects in 10.4.0 through 10.4.2. | |
| Description | Many LiveView projects have StreamBase EventFlow modules that provide functionality such as publishers or transformers of data. In releases 10.4.0, 10.4.1, and 10.4.2, right-clicking such modules and selecting > (or ) to run or debug the module independent of the enclosing LiveView project resulted in an error. This feature has been restored in release 10.4.3. This limitation did not prevent running the project as a LiveView fragment with all EventFlow modules working. The limitation was only on running the EventFlow modules by themselves. | |
| Workaround | If you are using one of the affected releases, you can:
|
|
| SB‑44494 | Metadata store restriction for clusters containing LiveView and StreamBase fragments. | |
| Description | The transactional memory metadata store type is only supported on homogeneous LiveView clusters. This means the cluster cannot contain a mix of LiveView and StreamBase fragments when using a transactional
memory metadata store.
|
|
| Workaround | Use either the JDBC or H2 metadata store type when your cluster contains both LiveView and StreamBase fragments. | |
| CQS-5503 | Controlling the output for aggregation queries against no rows. | |
| Description | As documented, aggregate queries that execute against no result return
null (to indicate unknown), except for
counting functions (that return 0). If you wish to instead return no row at all, see the
workaround.
|
|
| Workaround | Append GROUP BY 1 to the query. | |
| CQS-4800 | Row level security authentication not performed on results of already-registered queries and query-based alerts. | |
| Description | Row level security (RLS) authentication and authorization is performed at the time when new query-based alerts and queries are registered with the LiveView server. LiveView does not perform authentication on the results of already-registered queries and query-based alerts; to get the expected results based on RLS authentication, you must re-register the queries with the server. | |
| Workaround | None. | |
| CQS-4748 | liveview.project.out system property is
not used for deployed applications.
|
|
| Description | The liveview.project.out system property was recommended in
previous releases as a way to manage the placement of the LiveView server's compilation
working directory. However, if you redirect this working directory in StreamBase 10
applications, the StreamBase application might fail to start correctly.
|
|
| Workaround | None. | |
| CQS-4641 | Issuing queries with literal non-printing characters is not supported in query strings. | |
| Description | Query strings with literal non-printing characters can cause issues. Non-printing characters are those below 0x20, excepting tab, carriage return, and line feed. The tables and query result sets are free to have any characters as values. | |
| Workaround | Instead use StreamBase Unicode escape sequences, which looks like \uXXXX. For example, a bell is \u0007.
|
|
| CQS-3855 | Remote data source tables with sole primary key CQSInternalID cannot be opened.
|
|
| Description | When querying a remote data source's tables, all LiveView clients fail to open any
remote table that uses a single primary key named CQSInternalID.
This issue affects all LiveView clients, including Spotfire LiveView Desktop, Spotfire LiveView Web, the lv-client command line utility, and any custom client written using LiveView Client APIs. The issue occurs when querying any remote data source, including: Spotfire StreamBase Query Tables, other LiveView servers, JDBC databases, Spotfire ActiveSpaces tables, and custom table providers. |
|
| Workaround | To enumerate the remote tables that you must avoid, use one of the following
suggestions:
|
|
This section provides a list of errors corrected in release 11.1.3 of Spotfire® Streaming.
| Fixed in 11.1.3 | |
|---|---|
| Number | Resolution |
| Spotfire Streaming 11.1.3 incorporates all fixes resolved in the release 10.0 series through 11.1.2. | |
| SB-55161 | Asynchronous replication did not correctly handle PktNodeDisabled
responses.
|
| SB-53537 | The slow startup time observed with a large number of containers in applications. Previously, large applications experienced significant delays during startup. This fix optimizes the container initialization process. |

