launchdarkly/java-server-sdk 5.0.0-rc2

on GitHub

[5.0.0-rc2] - 2020-05-13

The primary purpose of this second beta release is to introduce the new DataSourceStatusProvider API, which is the server-side equivalent to the "connection status" API that exists in LaunchDarkly's mobile SDKs. Other additions and changes since the previous beta release (5.0.0-rc1) are described below. See the 5.0.0-rc1 release notes for other changes since 4.13.0. Also, see the end of this release note for changes between 5.0.0-rc2 and the final 5.0.0.

Added:

• LDClient.getDataSourceStatusProvider() is a status monitoring mechanism similar to getDataStoreStatusProvider(), but for the data source (streaming, polling, or file data). You can not only check the current connection status, but also choose to receive notifications when the status changes.
• LDConfig.Builder.logging() is a new configuration category for options related to logging. Currently the only such option is escalateDataSourceOutageLoggingAfter, which controls the new connection failure logging behavior described below.
• LDConfig.Builder.threadPriority() allows you to set the priority for worker threads created by the SDK.

Changed:

• Network failures and server errors for streaming or polling requests were previously logged at ERROR level in most cases but sometimes at WARN level. They are now all at WARN level, but with a new behavior: if connection failures continue without a successful retry for a certain amount of time, the SDK will log a special ERROR-level message to warn you that this is not just a brief outage. The amount of time is one minute by default, but can be changed with the new logDataSourceOutageAsErrorAfter option in LoggingConfigurationBuilder.
• The number of worker threads maintained by the SDK has been reduced so that most intermittent background tasks, such as listener notifications, event flush timers, and polling requests, are now dispatched on a single thread. The delivery of analytics events to LaunchDarkly still has its own thread pool because it is a heavier-weight task with greater need for concurrency.
• In polling mode, the poll requests previously ran on a dedicated worker thread that inherited its priority from the application thread that created the SDK. They are now on the SDK's main worker thread, which has Thread.MIN_PRIORITY by default (as all the other SDK threads already did) but the priority can be changed as described above.
• Only relevant for implementing custom components: The DataStore and DataSource interfaces, and their factories, have been changed to provide a more general mechanism for status reporting. This does not affect the part of a persistent data store implementation that is database-specific, so new beta releases of the Consul/DynamoDB/Redis libraries were not necessary.

Changes made after this beta release, in the final 5.0.0 release:

This section is an update in preparation for the full 5.0.0 release, for anyone who has beta-tested 5.0.0-rc2. The following things changed after 5.0.0-rc2:

• The flag listener methods were moved out of LDClient, into the FlagTracker object that is available through client.getFlagTracker().
• DataSourceStatusProvider now has a waitFor method allowing the caller to block until the connection is established.
• LDClientInterface has been moved into the interfaces subpackage.
• The initialized() method in LDClient and LDClientInterface was renamed to isInitialized().
• LDClient.intVariation() and doubleVariation() now return int and double, not the nullable Integer and Double.
• LDClient.version() previously could not be used if the SDK classes were not packaged in their original jar. It now works correctly regardless of deployment details.
• SLF4J logging now uses a simpler, more stable set of logger names instead of using the names of specific implementation classes that are subject to change. General messages are logged under com.launchdarkly.sdk.server.LDClient, while messages about specific areas of functionality are logged under that name plus .DataSource (streaming, polling, file data, etc.), .DataStore (database integrations), .Evaluation (unexpected errors during flag evaluations), or .Events (analytics event processing).
• The FileData tool now supports reading flag data from a classpath resource as if it were a data file. See FileDataSourceBuilder.classpathResources().
• Code coverage reports and JMH benchmarks are now generated in every build. Unit test coverage of the entire SDK codebase has been greatly improved.