3. Cassandra PV Archiver 3.2

3. Cassandra PV Archiver 3.2
Prev	Chapter II. What’s new in Cassandra PV Archiver 3.x	Next

The Cassandra PV Archiver 3.2 adds a few new configuration options and updates its dependencies to their respective newest versions. It is compatible with the Cassandra PV Archiver 3.1.x, meaning that it can operate on data stored by the Cassandra PV Archiver 3.1.x and the APIs supported by the Cassandra PV Archiver 3.1.x are fully supported.

Due to newly introduced configuration options, configuration files for version 3.2.x are not compatible with version 3.1.x. However, configuration files for version 3.1.x remain compatible with version 3.2.x.

The following improvements have been made in this release:

The memory consumption when generating decimated samples based on pre-existing source samples has been reduced significantly. This is important when adding new decimation levels to a large number of channels. In earlier versions, the sample decimation process could allocate so much memory that the heap space would be exhausted, resulting in an OutOfMemoryError. Two new configuration options have been introduced for controlling the memory consumption of the sample decimation process: throttling.sampleDecimation.maxFetchedSamplesInMemory and throttling.sampleDecimation.maxRunningFetchOperations.
The implementation of AbstractObjectResultSet has been improved in order to avoid unnecessary copy operations. This change should improve the performance when reading samples from the database. In order to profit from this change, control-system supports using AbstractObjectResultSet for implementing their sample result sets should change the result set’s fetchNextPage() method to return a SizedIterator instead of a regular Iterator. This change has already been implemented for the ResultSetBasedObjectResultSet, so control-system supports using this class (like the Channel Access control-system support) will automatically profit from this improvement.
The cassandra.fetchSize option has been introduced in order to control the default fetch size used for queries. Usually, the default fetch size of the Cassandra driver should be fine, but users wanting to fine-tune the fetch size can now do so.
The server.interNodeCommunicationRequestTimeout option has been introduced in order to control the timeout for requests sent from one archiving server to another one. This timeout has been significantly increased in version 3.1.2, but now it is possible to increase it even further if necessary or to choose a shorter timeout if sufficient.
The way how the throttling of statements executed on the Cassandra cluster is handled has been improved. In older versions, the limit for read statements would only apply for the initial execution of a statement. If a statement later fetched more results (because there were more rows than the configured fetch size), this fetch operation would not count towards the limit. Now, a fetch operation is treated like a read statement and fully counts towards the limit. This means that in certain situations it might be possible to slightly raise the limit for read statements.
The naming scheme for the MBeans exposed via JMX has been changed so that all MBeans of the archiving server are in a single domain. This means that clients using JMX to monitor the archiving server have to be changed to use the new object names. The JMX interface is not considered a public API and thus might again change in future versions.

There also was one bug that has been fixed in this release:

The way how write operations to the generic_data_store table were handled was unsafe because light-weight transactions (LWTs) were mixed with regular updates. This could theoretically lead to invalid data if writes were happening very rapidly or server clocks had an extremely large clock skew. As data is only rarely written to this table (once when the archiving cluster is initialized and every time the administrator’s password is changed), this bug was very unlikely to cause any actual problems.

The Cassandra driver has been updated to version 3.2.0 in this release. That version includes a change to how user-defined types (UDTs) are handled when using the schema builder to create a table. Control-system supports using the schema builder to create a table with UDT columns might have to be changed to use the schema builder’s addUDTColumn(…) method with a parameter constructed using SchemaBuilder.frozen(…) instead of using addColumn(…) with an instance of UserType.

Prev	Up	Next
2. Cassandra PV Archiver 3.1	Home	Chapter III. Cassandra PV Archiver server