4.7.1

[4.7.1] - 2019-08-19

Fixed:

• Fixed a race condition that could cause a NumberFormatException to be logged when delivering event data to LaunchDarkly (although the exception did not prevent the events from being delivered).

4.7.0

[4.7.0] - 2019-08-02

Added:

• In RedisFeatureStoreBuilder, the new methods database, password, and tls allow you to specify the database number, an optional password, and whether to make a secure connection to Redis. This is an alternative to specifying them as part of the Redis URI, e.g. rediss://:PASSWORD@host:port/NUMBER, which is also supported (previously, the database and password were supported in the URI, but the secure rediss: scheme was not).
• LDConfig.Builder.sslSocketFactory allows you to specify a custom socket factory and truststore for all HTTPS connections made by the SDK. This is for unusual cases where your Java environment does not have the proper root CA certificates to validate LaunchDarkly's certificate, or you are connecting through a secure proxy that has a self-signed certificate, and you do not want to modify Java's global truststore.

Deprecated:

• LDConfig.Builder.samplingInterval is now deprecated. The intended use case for the samplingInterval feature was to reduce analytics event network usage in high-traffic applications. This feature is being deprecated in favor of summary counters, which are meant to track all events.

4.6.6

[4.6.6] - 2019-07-10

Fixed:

• Under conditions where analytics events are being generated at an extremely high rate (for instance, if an application is evaluating a flag repeatedly in a tight loop on many threads), a thread could be blocked indefinitely within the Variation methods while waiting for the internal event processing logic to catch up with the backlog. The logic has been changed to drop events if necessary so threads will not be blocked (similar to how the SDK already drops events if the size of the event buffer is exceeded). If that happens, this warning message will be logged once: "Events are being produced faster than they can be processed; some events will be dropped". Under normal conditions this should never happen; this change is meant to avoid a concurrency bottleneck in applications that are already so busy that thread starvation is likely.

4.6.5

[4.6.5] - 2019-05-21

Fixed

• The LDConfig.Builder method userKeysFlushInterval was mistakenly setting the value of flushInterval instead. (Thanks, kutsal!)

Added

• CI tests now run against Java 8, 9, 10, and 11.

4.6.4

[4.6.4] - 2019-05-01

Changed

• Changed the artifact name from com.launchdarkly:launchdarkly-client to com.launchdarkly:launchdarkly-java-server-sdk
• Changed repository references to use the new URL

There are no other changes in this release. Substituting launchdarkly-client version 4.6.3 with launchdarkly-java-server-sdk version 4.6.4 will not affect functionality.

4.6.3

[4.6.3] - 2019-03-21

Fixed

• The SDK uberjars contained some JSR305 annotation classes such as javax.annotation.Nullable. These have been removed. They were not being used in the public API anyway. (#156)
• If track or identify is called without a user, the SDK now logs a warning, and does not send an analytics event to LaunchDarkly (since it would not be processed without a user).

4.6.2

[4.6.2] - 2019-02-21

Fixed

• If an unrecoverable java.lang.Error is thrown within the analytics event dispatching thread, the SDK will now log the error stacktrace to the configured logger and then disable event sending, so that all further events are simply discarded. Previously, the SDK could be left in a state where application threads would continue trying to push events onto a queue that was no longer being consumed, which could block those threads. The SDK will not attempt to restart the event thread after such a failure, because an Error typically indicates a serious problem with the application environment.
• Summary event counters now use 64-bit integers instead of 32-bit, so they will not overflow if there is an extremely large volume of events.
• The SDK's CI test suite now includes running the tests in Windows.

4.6.1

[4.6.1] - 2019-01-14

Fixed

• Fixed a potential race condition that could happen when using a DynamoDB or Consul feature store. The Redis feature store was not affected.

4.6.0

[4.6.0] - 2018-12-12

Added:

• The SDK jars now contain OSGi manifests which should make it possible to use them as bundles. The default jar requires Gson and SLF4J to be provided by other bundles, while the jar with the "all" classifier contains versions of Gson and SLF4J which it both exports and imports (i.e. it self-wires them, so it will use a higher version if you provide one). The "thin" jar is not recommended in an OSGi environment because it requires many dependencies which may not be available as bundles.
• There are now helper classes that make it much simpler to write a custom FeatureStore implementation. See the com.launchdarkly.client.utils package. The Redis feature store has been revised to use this code, although its functionality is unchanged except for the fix mentioned below.
• FeatureStore caching parameters (for Redis or other databases) are now encapsulated in the FeatureStoreCacheConfig class.

Changed:

• The exponential backoff behavior when a stream connection fails has changed as follows. Previously, the backoff delay would increase for each attempt if the connection could not be made at all, or if a read timeout happened; but if a connection was made and then an error (other than a timeout) occurred, the delay would be reset to the minimum value. Now, the delay is only reset if a stream connection is made and remains open for at least a minute.

Fixed:

• The Redis feature store would incorrectly report that it had not been initialized, if there happened to be no feature flags in your environment at the time that it was initialized.

Deprecated:

• The RedisFeatureStoreBuilder methods cacheTime, refreshStaleValues, and asyncRefresh are deprecated in favor of the new caching method which sets these all at once.

4.5.1

[4.5.1] - 2018-11-21

Fixed:

• Fixed a build error that caused the com.launchdarkly.client.files package (the test file data source component added in v4.5.0) to be inaccessible unless you were using the "thin" jar.
• Stream connection errors are now logged at WARN level, rather than ERROR.