-
Notifications
You must be signed in to change notification settings - Fork 476
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The client act in a synchronous manner when BatchProcessorr#queue is full. #688
Comments
Correct, but what should be the desired behavior instead ? |
It should be configurable to allow choice of opting for |
But what to do if the user configured not to block ? |
IMO, those events should be not be added to the queue and thus will be dropped. Also, let me see if I am able to raise a PR. |
I have to ask the influxdb employees, because they own the maven repo |
I went through the
BatchProcessor
implementation and noticed that when the batch processor is lagging behind and is not able to clear thequeue
,InfluxDB.write(Point p)
becomes a blocking call even when one has configured it to write in an asynchronous manner.This is happening because the queue instance is of type LinkedBlockingQueue and
put(E e)
is used for enqueueing which blocks the thread trying to enqueue.IMO, this behaviour is very misleading, can block all the application threads who are trying to write whenever the write latencies on the influx-db server increases.
I am using the
influxdb-java:2.15
Below is the sample
Junit
test to simulate this.The default batch size is 1000, so the 2000th write call will be blocked for ~10000ms.
The text was updated successfully, but these errors were encountered: