2. Cassandra PV Archiver 3.1
The Cassandra PV Archiver 3.1 adds a few new features and updates its
dependencies to their respective newest versions.
It is compatible with the Cassandra PV Archiver 3.0.x, meaning that it
can operate on data stored by the Cassandra PV Archiver 3.0.x and the
APIs supported by the Cassandra PV Archiver 3.0.x are fully supported.
The following features have been added in this release:
-
A web-service API for managing the server has been added.
This API is described in detail in
Appendix C, Administrative API.
-
The administrative user-interface now uses AJAX to load the list of
channels asynchronously.
This improves the performance when displaying a list containing a
large number of channels.
There also are some bugfixes and minor improvements:
-
For each module containing Java code, a source JAR is generated in
addition to the binary JAR.
-
A
NullPointerException that could occur when
updating a channel while concurrently moving or deleting it has been
fixed.
-
The launcher script on Windows now works correctly when the path
where the Cassandra PV Archiver is installed contains spaces.
-
All library dependencies have been updated to their newest versions.
2.1. Cassandra PV Archiver 3.1.1
Version 3.1.1 is a bugfix release that fixes an issue with displaying
the channel state in the channel list.
Unfortunately, a regression was introduced shortly before the release
of version 3.0.0.
This regression caused the state of a channel not to be visible in the
list view (but it would show on the details page for a channel).
This problem is fixed in version 3.0.1 so that the state now is also
visible in the list view (like it was in older versions).
2.2. Cassandra PV Archiver 3.1.2
Version 3.1.2 is a bugfix release that includes an updated version of
the EPICS Jackie library and brings a few minor improvements:
-
EPICS Jackie has been updated to version 1.0.2.
This version includes a fix for a bug that could cause
connectivity issues for channels that are hosted by servers based
on older EPICS versions.
-
When an archive configuration command fails, the corresponding
exception is now logged in the logfile.
Expected exceptions (e.g. trying to add a channel that already
exists) are logged with the level INFO, while unexpected
exceptions (e.g. database errors) are logged with level ERROR.
Such errors were already reported to the user through the user
interface, but the logged exception (including the stack trace)
might give additional insights into the actual cause of the error.
-
Write timeouts when creating, updating, or deleting a “pending
channel operation” are now handled more gracefully.
These timeouts caused configuration commands to fail with a
message like “Cassandra timeout during write query at consistency
SERIAL…”.
While the
throttling options
should still be used to avoid overloading the server, the new
logic can help in handling short spikes by retrying an operation
that timed out after a short delay.
Configuring the throttling at a reasonable value is still needed
because this mechanism will not work in a situation where the
database is overloaded for a longer period of time (the operation
will simply fail after reaching the maximum number of retries).
-
The timeout for inter-node communication has been increased.
When running a large number (typically thousands) of configuration
commands that affected a remote server, the commands would fail
with a timeout error due to the HTTP communication timing out.
While this timeout would be reported to the user, the commands
would still continue running in the background.
The timeout for the HTTP communication has now been increased to
15 minutes, so that the HTTP connection should not time out, even
when a large number of commands is processed.