-
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
Batching Enhancements #289
Comments
My apologies, I was wrong about 2 above. No duplicate records are written during |
Introduction of a new Interface is not necessary in my opinion, to achieve async write some methods must be implemented with an async signature. Do you mind implementing 1 and 3 ? |
Sure, I'll send a PR for 1 and 3. Unfortunately I won't be able to use the built in batch support until it's at least possible to be alerted when records are not delivered. Not sure how I missed #148 but that's a good list of enhancements. Hopefully a combination of those will improve the batch implementation enough that I can use it. If not I'll see what the gap is and propose additional work. Regarding the additional interface I can see the desire to stick with a single interface with additional asynchronous method signatures for writes. |
I reviewed the issues and PRs bundled in #148. The last comment by @andrewdodd on #108 makes a lot of sense to me (separating concerns for this "auto batch" mode and the |
I already have a forked implementation for #3 I am already using in my own code, I'll submit a PR: |
Current promising is: #318 |
I'm building an InfluxDB producer that I'd like to guarantee at-least-once delivery for. My throughput requirements are high enough that batching is required. I was happy when I found BatchProcessor but then realized a couple of shortcomings that are preventing me from using it. I'd rather improve this library than create my own batch producer. Here's where the current batch implementation is falling short. Are any of these being worked on currently?
InfluxDB.disableBatch
followed byInfluxDB.enableBatch
to force a flush but that creates a new executor every time.BatchProcessor.write()
is not thread safe and may be called concurrently fromBatchProcessor.flush()
on the current thread and the scheduled timer on the thread from the pool. This results in duplicate records being sent duringflush()
.ConsistencyLevel.ONE
. Direct control over the consistently level would be nice but ONE is a show stopper.Some of the above are fairly substantial deviations in behavior from the current version. Would it be worthwhile for this to be a separate batch implementation rather than migrating the current version? Perhaps create a new asynchronous interface named
InfluxDBAsync
?The text was updated successfully, but these errors were encountered: