Release Note Archives

In releases 7.0.0 through 7.0.3, a version mismatch with a bundle's precompiled files did not automatically fall back to compiling the source files in the bundle, and instead stopped and reported the mismatch. As of release 7.0.4, this was corrected, and the 6.6 behavior was restored.

The expected usage is for the StreamBase application to always issue a REFRESH action in response to a subscribe request before issuing any updates. Accordingly, the adapter was updated to distinguish the true no-subscriber case from the case immediately after receiving a subscribe request. The WARN message for the latter case now reads "There are 0 pending snapshots and 1 pending subscriptions but no active subscriptions for item RICname. Consider publishing a REFRESH instead."

In a rare configuration where the output port of one Query write operator was shared by two arcs, one leading to a second Query write operator updating the same Query Table, "old" table rows emitted to the third operator (such as the Map operator shown here) could contain incorrect values. The data in the Query Table itself was not corrupted. The condition was not triggered when the first Query operator was followed by any single operator, such as a Split connected to the second Query and third operators. The cause of the problem was identified and corrected.

The JDBC external adapter was incurring a NullPointerException in response to an attempt to insert a null value into a table. This was fixed.

In previous releases, the adapter would shut down in response to SQL exceptions, such as a primary key violation. The adapter was updated to log SQL exceptions and continue processing.

In previous releases, a StreamBase client built with the .NET API could not be loaded by an ASP-based web page. This problem was corrected.

If you encounter this situation, open the EventFlow .sbapp file associated with the .sblayout file you want to check in. Make a simple change and save the EventFlow file. This clears the incorrect bit on the associated layout file and it is now flagged as ready to check in.

When using the Reuters RMDS Subscribing adapter and the data from Reuters contains partial updates to string fields (which is a rarely encountered mechanism), update tuples were incorrectly handled and could be lost. There were two cases: when using the adapter's Send Thin Tuples property, partial string updates resulted in lost tuples. When using standard tuples and the Send Unchanged Fields as Null check box is selected, string fields in tuples were null. These conditions were corrected.

In previous releases, in some circumstances StreamBase Studio would generate a typecheck error with a message to remove a row that you could not remove because the row was not displayed in the Properties view. This could occur when you edited a data construct associated with an operator and then attempted to save the changes.

Starting in release 6.1.1, the Properties view is more proactive in determining whether changes in associated components in the EventFlow application require re-typechecking the current component. This behavior change fixes the problem described above, but may cause your EventFlow applications to be flagged more often as unsaved.

In the 6.0.0 and 6.0.1 releases, StreamBase Studio did not examine the application module parameters when resolving parameters in Java operators or adapters. The application module parameters are defined in the Parameters tab of the EventFlow Editor. This problem was fixed.

In the 6.0.0 release, if your dynamic variables do not appear to be updating correctly, it could be because StreamBase introduced a change in the way dynamic variable update expressions are specified. In version 6 and later, update expressions can reference the old value of the dynamic variable, in addition to fields on the stream. Due to new support for the tuple data type, the entire tuple on the stream can also be referenced by using the stream's name.

As a result of this new functionality, a field reference in an update expression can be ambiguous if any two of the variable name, field name on the stream, or stream name itself are the same, and that name is used in the update expression. In 6.0.0, StreamBase did not generate an error about this ambiguity, and in fact changed the default behavior. The most common result of this change in behavior is that dynamic variables would appear to not be updating.

To address this problem, release 6.0.1 and later supports two new behaviors. In the first place, if there is such a naming conflict, Studio generates a typecheck error to notify you to change the names that cause the conflict.

Secondly, you can add a prefix to the names that are in conflict to disambiguate between the fields you are trying to access:

The best practice to keep your programs readable is to never use the same name for a variable and the stream that updates it.

For example, suppose you defined a dynamic variable named Threshold to update from a field named Threshold, with an updating expression Threshold, and the output stream is StreamName. To resolve the error and match old behavior, change the updating expression to StreamName.Threshold. To take advantage of new behavior, and access the old value of the variable, use an update expression such as old.Threshold + StreamName.Threshold, which increments the threshold whenever a new event arrives on StreamName.

Users of the JDBC and EMS/JMS adapters, please note that there is a change in the way that you extend the classpath when running the sb-jdbc, sb-ems-enqueue, sb-ems-dequeue, sb-ems-publish, and sb-ems-subscribe commands.

In previous releases, on Linux and Solaris, you could use a command line option (–c classpath) to extend the classpath. This option is no longer available.

In previous releases, on Windows, you were required to edit the ini file for the script. This is no longer required.

On Windows, Linux, and Solaris platforms, these programs now prepend the value of the CLASSPATH environment variable to their internal classpath entries. Editing CLASSPATH is the recommended way for users to extend the adapter's classpath.

This release adds a way to control the size of the internal queue used between a Java StreamBaseClient's main thread and the dequeuing thread. Previously, you could control the number of batches of tuples in the queue using the Java property streambase.max-queue-size, which has a default size of 500 batches. However, if a client gets behind in dequeuing, the server starts sending larger batches, which requires more memory usage by the client.

To remedy this situation, there is a new Java property in the StreamBaseClient API:

streambase.client.max-tuples-in-queue

The default value is 10000 tuples. This property limits the absolute number of tuples in the queue, promoting better client behavior. This new Java property also affects the StreamBase to StreamBase input adapter.

There is also a new Java property for the server:

streambase.sbd.max-tuples-in-dequeue-packet

This property limits the number of packets the server includes in any one dequeue packet. The default value is 10000, which matches the default of the new client property described above. Administrators can set both server and client with matching values to make sure client dequeues are not overwhelmed.

In releases 5.0 through 6.0.0, on the Windows platform, StreamBase Studio did not take into account the possibility that you had moved your My Documents folder when creating your workspace as a subdirectory of My Documents. This was fixed.

Note: after you install release 6.0.x, Studio can continue to use any workspace it has already created. There is no need to move the folder containing your workspace.

In general, properties for Java operators specified in the server's sbd.sbconf file are evaluated at compile time rather than at runtime. In release 5.1, this was causing confusion with precompiled applications (described in Precompiled Application Archives), because operator properties specified in the runtime sbd.sbconf were silently ignored when a precompiled application file was generated.

This was fixed. Starting with release 6.0, properties for Java operators specified in sbd.sbconf are correctly passed to StreamBase Server when it loads a precompiled application file.

A problem with dequeuing tuples was caused by the following limitation in the Java Virtual Machine (JVM):

6724218: Incorrect code is generated for AbstractLinkedList::removeNode

This release of StreamBase includes a workaround for this Java problem.

In releases prior to 5.1.8, StreamBase Studio did not examine the application module parameters when resolving parameters in Java adapters or Java operators. The application module parameters are defined in the Parameters tab of the EventFlow Editor. This problem was fixed.

This release adds a way to control the size of the internal queue used between a Java StreamBaseClient's main thread and the dequeuing thread. Previously, you could control the number of batches of tuples in the queue using the Java property streambase.max-queue-size, which has a default size of 500 batches. However, if a client gets behind in dequeuing, the server starts sending larger batches, which requires more memory usage by the client.

To remedy this situation, there is a new Java property in the StreamBaseClient API:

streambase.client.max-tuples-in-queue

The default value is 10000 tuples. This property limits the absolute number of tuples in the queue, promoting better client behavior. This same Java property also affects the StreamBase to StreamBase input adapter.

There is also a new Java property for the server:

streambase.sbd.max-tuples-in-dequeue-packet

This property limits the number of packets the server includes in any one dequeue packet. The default value is 10000, which matches the default of the new client property described above. Administrators can set both server and client with matching values to make sure client dequeues are not overwhelmed.

This release added a way to control the size of the internal queue used between a Java StreamBaseClient's main thread and the dequeuing thread. Previously, you could control the number of batches of tuples in the queue using the Java property streambase.max-queue-size, which has a default size of 500 batches. However, if a client gets behind in dequeuing, the server starts sending larger batches, which requires more memory usage by the client. To remedy this situation, there is a new Java property in the StreamBaseClient API: streambase.client.max-tuples-in-queue. The default value is 10000 tuples. This property limits the absolute number of tuples in the queue, which promotes better client behavior. This same Java property also affects the StreamBase to StreamBase input adapter.

There is also a new Java property for the server, streambase.sbd.max-tuples-in-dequeue-packet. This property limits the number of packets the server includes in any one dequeue packet. The default value is 10000, which matches the default of the new client property described above. Administrators can set both server and client with matching values to make sure client dequeues are not overwhelmed.

The problems have been fixed: Now, a referencing module is marked as changed only when there is a significant change to the referenced module (for example, to schemas, inputs or outputs, or tables). And, referencing modules are marked as changed when their referenced modules change.

This release adds an additional way to control the size of the internal queue used between a Java StreamBaseClient's main thread and the dequeuing thread. Previously, you could control the number of batches of tuples in the queue using the Java property streambase.max-queue-size, which has a default size of 500 batches. However, if a client gets behind in dequeuing, the server starts sending larger batches, which requires more memory usage by the client. To remedy this situation, there is a new Java property in the StreamBaseClient API: streambase.client.max-tuples-in-queue. The default value is 10000 tuples. This property limits the absolute number of tuples in the queue, which promotes better client behavior. This same Java property also affects the StreamBase to StreamBase input adapter.

There is also a new Java property for the server, streambase.sbd.max-tuples-in-dequeue-packet. This property limits the number of packets the server includes in any one dequeue packet. The default value is 10000, which matches the default of the new client property described above. Administrators can set both server and client with matching values to make sure client dequeues are not overwhelmed.

In prior releases, under certain unusual circumstances, an update operator could corrupt the primary index of a table, leading to the appearance of duplicate key values, and potential data loss. This error was identified and fixed.

The rare circumstances that triggered the condition were: an update operator was modifying rows in a query table with a primary key of type string, which was downstream from, but in the same parallel region as, a read operator connected to the same table, which returned three or more rows.

Errors in a third party Java library were causing a Null Pointer Exception for users of the StreamBase Reuters Subscribing Adapter accessing certain classes of market data. This release of StreamBase incorporates a fixed version of that library, which resolves the errors.

<param name="jvm-args" value="-Xms64m -Xmx256m -Dstreambase.codegen.intermediate-stream-dequeue = true"/>

In the previous release, setting the switch shown did not work properly, and you could only see intermediate streams in debug mode. The problem was fixed.

=RTD("StreamBase.RTD", , "STREAM:myContainer.All_Transactions", ...)

Note that is usually better NOT to specify container names in Excel cells. That is,

=RTD("StreamBase.RTD", , "STREAM:All_Transactions" , ...)

is generally more maintainable than:

=RTD("StreamBase.RTD",,"STREAM:myContainer.All_Transactions", ...)

In previous releases, copying the operators in the loop would cause the schema of the looping stream to be shared by the operators. As a result, a change to either looping stream would take effect in both. In this release, such a copy now creates a separate schema for the looping stream. The schemas are initially identical, but you can edit each independently of the other.

Instead, the adapter monitors the failed StreamBase server, and when it becomes available, reconnects in the background. The current state of each StreamBase server is available through the new META:SERVER_STATUS tag. The new meta.xls sample spreadsheet shows how this works.

<param name="uri" value="sb://foo:10000"/>

and a spreadsheet cell contains:

=RTD("StreamBase.RTD",,"URIREF:", ...)

then this cell will reference the StreamBase server running at URI sb://foo:10000.

Note that if you want to use an expression that intentionally sets the result to null, you must use one of the data-type-specific null literals, as shown in the following list:

For more information, see Using Nulls in StreamBase Applications in the Authoring Guide.

streambase.codegen.javac-Xmx

Use this flag the same way as the java -Xmx command-line option:

Specify the maximum size, in bytes, of the memory allocation pool. This value must a multiple of 1024. Append the letter k or K to indicate kilobytes, or m or M to indicate megabytes. Examples:

-Xmx83886080
-Xmx81920k
-Xmx80m

If the input field in question were of string type, the StreamBase server could experience a Null Pointer Exception. If the input field were another data type, then the output value could be 0 instead of the expected null data type.

package com.streambase.sb.expr.test; 
  import com.streambase.sb.operator.AggregateWindow;
  /** 
  * Class that implements a custom aggregate function that 
  concatenates strings together. 
  */ 
  public class StringConcatAggregate extends AggregateWindow {
  StringBuffer buf = new StringBuffer();
  public static int getResultLength() {
    return 100;
  } 
  public void init() {
    buf.setLength(0); 
  } 
  public void accumulate(String s) {
    buf.append(s);
  } 
  public String calculate() {
    return buf.toString(); 
  }
  } 

{"strptime('2006-Feb-10 11:01:03', '%Y-%b-%d %H:%M:%S')", SOME_TIMESTAMP}
{"strptime('2006-fEB-10 11:01:03', '%Y-%B-%d %H:%M:%S')", SOME_TIMESTAMP}

Note that month letter codes are limited to three characters: long month names like February are not supported.