Skip to content
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

Ability to add additional options into a writeRequest #50

Open
bcorbett6 opened this issue Jul 1, 2023 · 5 comments
Open

Ability to add additional options into a writeRequest #50

bcorbett6 opened this issue Jul 1, 2023 · 5 comments
Labels
enhancement New feature or request

Comments

@bcorbett6
Copy link

Use Case

For customers who need to tailor their write client based on the below config:

  • batchSize
  • flushInterval
  • bufferLimit
  • jitterInterval
  • retryInterval

This is useful for developing a productionised and durable write-client

Expected behavior

The ability to use the specified config options to tailor how data is sent to InfluxDB

Actual behavior

I don't believe these write options are yet included

Additional info

No response

@bednar
Copy link
Member

bednar commented Jul 1, 2023

@bcorbett6, thank you for your proposal. We are currently prioritizing adding support for the web environment. Once that is accomplished, we can then focus on implementing support for batching writes.

@bednar bednar added the enhancement New feature or request label Jul 1, 2023
@guoxiangke
Copy link

batching writes needed, thanks.

@bednar
Copy link
Member

bednar commented Sep 19, 2023

Hi @guoxiangke,

Thank you for your interest in our client.

Regarding batching writes, what is your preferred approach? Would you like a background service that writes data asynchronously on a separate thread? Or would you prefer a straightforward writer that divides data into batches, writes asynchronously, and then returns the result?

Regards

@anfreita
Copy link

@bednar

For lack of response to your earlier questions, I think some simple retry logic in the existing node implementation would be fantastic. Something to mitigate for potential 413s and 429s when loading larger data sets.

You maybe have more insight into this than I, but I think that ideally it might be nice to maintain parity with the telegraf influx plugin here: https://github.com/influxdata/telegraf/blob/master/plugins/outputs/influxdb_v2/http.go

@bednar
Copy link
Member

bednar commented Apr 17, 2024

Hi @anfreita,

Thank you for your feedback and suggestions.

I wanted to update you that we have added the following enhancements to our development backlog for the v3 clients:

  1. Proper handling of the HTTP 429 status (Too Many Requests) - We will implement a retry mechanism that intelligently manages rate limiting issues by retrying requests after an appropriate delay.

  2. Proper handling of the HTTP 413 status (Payload Too Large) - We plan to enhance the client to automatically split requests that exceed the server's size limits, ensuring that large payloads are handled more efficiently.

These enhancements are aimed at improving the robustness and usability of our clients. We'll be looking into these as part of our next set of enhancements.

Your input is invaluable, and we appreciate your contribution to making our tools better. We will keep you updated on our progress and when you can expect these features to be implemented.

Best regards.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants