Describe the feature:
JG views writes to mixed indices as a "best effort" and documents that failures in transactions with regards to mixed indices are left to a separate periodic clean up process after enabling JG's WAL.
However this results in clients not getting feedback for more mundane write failures to mixed indices like Elasticsearch like a 429 Too Many Requests that just need to respect the backpressure being conveyed by Elasticsearch and retry again.
To implement this feature would require implementing retry logic around this callsite. Additionally supporting some new config settings for Elasticsearch:
retry-limit: How many times to attempt a retry. Default to 0 to maintain current behavior.
retry-initial-wait: How long (in milliseconds) to wait before applying the initial retry. Defaults to 1ms.
retry-max-wait: How long (in milliseconds) to wait at most for each retry attempt, operates as a ceiling if a high number of retries are configured since exponential backoff will grow exceptionally quickly. Defaults to 1000ms.
retry-error-codes: Which error codes contained in a thrown Elasticsearch ResponseException to apply retries upon.
Describe a specific use case for the feature:
Once this feature is implemented it'll make writes to Elasticsearch better handle write errors like 429 during high write periods instead of silently failing the write and users of JanusGraph needing to be aware of the WAL & separate periodic repair application.
Describe the feature: JG views writes to mixed indices as a "best effort" and documents that failures in transactions with regards to mixed indices are left to a separate periodic clean up process after enabling JG's WAL.
However this results in clients not getting feedback for more mundane write failures to mixed indices like Elasticsearch like a
429 Too Many Requeststhat just need to respect the backpressure being conveyed by Elasticsearch and retry again.Elasticsearch's guidance states that 429 errors in particular are the client's responsibility.
To implement this feature would require implementing retry logic around this callsite. Additionally supporting some new config settings for Elasticsearch:
retry-limit: How many times to attempt a retry. Default to 0 to maintain current behavior.retry-initial-wait: How long (in milliseconds) to wait before applying the initial retry. Defaults to 1ms.retry-max-wait: How long (in milliseconds) to wait at most for each retry attempt, operates as a ceiling if a high number of retries are configured since exponential backoff will grow exceptionally quickly. Defaults to 1000ms.retry-error-codes: Which error codes contained in a thrown ElasticsearchResponseExceptionto apply retries upon.Describe a specific use case for the feature: Once this feature is implemented it'll make writes to Elasticsearch better handle write errors like 429 during high write periods instead of silently failing the write and users of JanusGraph needing to be aware of the WAL & separate periodic repair application.