You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CHANGELOG.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -23,6 +23,7 @@ This release uses the latest InfluxDB OSS API definitions - [oss.yml](https://ra
23
23
1.[#272](https://github.com/influxdata/influxdb-client-java/pull/272): Add `PingService` to check status of OSS and Cloud instance
24
24
1.[#278](https://github.com/influxdata/influxdb-client-java/pull/278): Add query method with all params for BucketsApi, OrganizationApi and TasksApi
25
25
1.[#280](https://github.com/influxdata/influxdb-client-java/pull/280): Use async HTTP calls in the Batching writer
26
+
1.[#251](https://github.com/influxdata/influxdb-client-java/pull/251): Client uses `Reactive Streams` in public API, `WriteReactiveApi` is cold `Publisher`[influxdb-client-reactive]
26
27
27
28
### Bug Fixes
28
29
1.[#279](https://github.com/influxdata/influxdb-client-java/pull/279): Session authentication for InfluxDB `2.1`
The reference Java client that allows query and write for the InfluxDB 2.0 by a reactive way.
5
+
The reference reactive Java client for InfluxDB 2.0. The client provide supports for asynchronous stream processing with backpressure as is defined by the [Reactive Streams specification](http://www.reactive-streams.org/).
6
+
7
+
## Important
8
+
9
+
> :warning: The `Publishers` returned from [Query](src/main/java/com/influxdb/client/reactive/QueryReactiveApi.java) and [Write](src/main/java/com/influxdb/client/reactive/WriteReactiveApi.java) API are cold.
10
+
That means no request to InfluxDB is trigger until register a subscription to `Publisher`.
@@ -177,17 +187,23 @@ public class InfluxDB2ReactiveExamplePojo {
177
187
178
188
## Writes
179
189
180
-
For writing data we use [WriteReactiveApi](https://influxdata.github.io/influxdb-client-java/influxdb-client-reactive/apidocs/com/influxdb/client/reactive/WriteReactiveApi.html) that supports same configuration as [non reactive client](../client#writes):
190
+
For writing data we use [`WriteReactiveApi`](src/main/java/com/influxdb/client/reactive/WriteReactiveApi.java)
191
+
that supports writing data using Line Protocol, Data Point or POJO. The [GZIP compression](#gzip-support) is also supported.
192
+
193
+
The writes are configurable by [`WriteOptionsReactive`](src/main/java/com/influxdb/client/reactive/WriteOptionsReactive.java):
194
+
195
+
| Property | Description | Default Value |
196
+
| --- | --- | --- |
197
+
|**batchSize**| the number of data point to collect in batch. The `0` disable batching - whole upstream is written in one batch. | 1000 |
198
+
|**flushInterval**| the number of milliseconds before the batch is written | 1000 |
199
+
|**jitterInterval**| the number of milliseconds to increase the batch flush interval by a random amount | 0 |
200
+
|**retryInterval**| the number of milliseconds to retry unsuccessful write. The retry interval is used when the InfluxDB server does not specify "Retry-After" header.| 5000 |
201
+
|**maxRetries**| the number of max retries when write fails. The `0` disable retry strategy - the error is immediately propagate to upstream. | 5 |
202
+
|**maxRetryDelay**| the maximum delay between each retry attempt in milliseconds | 125_000 |
203
+
|**maxRetryTime**| maximum total retry timeout in milliseconds | 180_000 |
204
+
| **exponentialBase** | the base for the exponential retry delay, the next delay is computed using random exponential backoff as a random value within the interval ``retryInterval * exponentialBase^(attempts-1)`` and ``retryInterval * exponentialBase^(attempts)``. Example for ``retryInterval=5_000, exponentialBase=2, maxRetryDelay=125_000, total=5`` Retry delays are random distributed values within the ranges of ``[5_000-10_000, 10_000-20_000, 20_000-40_000, 40_000-80_000, 80_000-125_000]``
181
205
182
-
1. writing data using Line Protocol, Data Point, POJO
183
-
2. use batching for writes
184
-
3. use client backpressure strategy
185
-
4. produces events that allow user to be notified and react to this events
186
-
-`WriteSuccessEvent` - published when arrived the success response from Platform server
187
-
-`BackpressureEvent` - published when is **client** backpressure applied
188
-
-`WriteErrorEvent` - published when occurs a unhandled exception
189
-
-`WriteRetriableErrorEvent` - published when occurs a retriable error
190
-
5. use GZIP compression for data
206
+
> Backpressure: is defined by the backpressure behavior of the upstream publisher.
0 commit comments