Release Notes for StreamBase 6.0.x

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.