mkapalka commented on code in PR #3120:
URL: https://github.com/apache/jackrabbit-oak/pull/3120#discussion_r4024919576
##########
oak-search-elastic/src/main/java/org/apache/jackrabbit/oak/plugins/index/elastic/ElasticConnection.java:
##########
@@ -76,6 +85,19 @@ public class ElasticConnection implements Closeable {
public static final String FT_OAK_12234 = "FT_OAK-12234";
public static final AtomicBoolean FT_OAK_12234_DISABLE = new
AtomicBoolean(false);
+ /**
+ * Feature toggle for OAK-12366: force HTTP/1.1 on the Elasticsearch REST
client connection. As of the ES 9.x
+ * client upgrade, the underlying transport negotiates HTTP/2 over TLS by
default. Because HTTP/2 multiplexes
+ * all requests over a single TCP connection, large bulk ingestion
payloads (up to 8MB) have been observed to
+ * trigger H2 stream resets ({@code RST_STREAM}) from the server or
intermediary proxies, while small read
+ * requests sharing the same connection succeed -- making the failures
intermittent, hard to diagnose, and
+ * unrecoverable within an enrichment cycle. Enabled by default (bug fix).
When the toggle is flipped the
Review Comment:
Detail: not sure if "enrichment" means much in the Oak context
##########
oak-search-elastic/src/main/java/org/apache/jackrabbit/oak/plugins/index/elastic/ElasticConnection.java:
##########
@@ -76,6 +85,19 @@ public class ElasticConnection implements Closeable {
public static final String FT_OAK_12234 = "FT_OAK-12234";
public static final AtomicBoolean FT_OAK_12234_DISABLE = new
AtomicBoolean(false);
+ /**
+ * Feature toggle for OAK-12366: force HTTP/1.1 on the Elasticsearch REST
client connection. As of the ES 9.x
+ * client upgrade, the underlying transport negotiates HTTP/2 over TLS by
default. Because HTTP/2 multiplexes
+ * all requests over a single TCP connection, large bulk ingestion
payloads (up to 8MB) have been observed to
+ * trigger H2 stream resets ({@code RST_STREAM}) from the server or
intermediary proxies, while small read
+ * requests sharing the same connection succeed -- making the failures
intermittent, hard to diagnose, and
+ * unrecoverable within an enrichment cycle. Enabled by default (bug fix).
When the toggle is flipped the
+ * shared {@link #FT_OAK_12366_DISABLE} flag is set to {@code true} and
the client falls back to negotiating
+ * HTTP/2, restoring the previous behaviour.
Review Comment:
```suggestion
* HTTP/2, restoring the default library behaviour.
```
##########
oak-search-elastic/src/main/java/org/apache/jackrabbit/oak/plugins/index/elastic/ElasticConnection.java:
##########
@@ -76,6 +85,19 @@ public class ElasticConnection implements Closeable {
public static final String FT_OAK_12234 = "FT_OAK-12234";
public static final AtomicBoolean FT_OAK_12234_DISABLE = new
AtomicBoolean(false);
+ /**
+ * Feature toggle for OAK-12366: force HTTP/1.1 on the Elasticsearch REST
client connection. As of the ES 9.x
+ * client upgrade, the underlying transport negotiates HTTP/2 over TLS by
default. Because HTTP/2 multiplexes
+ * all requests over a single TCP connection, large bulk ingestion
payloads (up to 8MB) have been observed to
+ * trigger H2 stream resets ({@code RST_STREAM}) from the server or
intermediary proxies, while small read
+ * requests sharing the same connection succeed -- making the failures
intermittent, hard to diagnose, and
+ * unrecoverable within an enrichment cycle. Enabled by default (bug fix).
When the toggle is flipped the
+ * shared {@link #FT_OAK_12366_DISABLE} flag is set to {@code true} and
the client falls back to negotiating
+ * HTTP/2, restoring the previous behaviour.
+ */
+ public static final String FT_OAK_12366 = "FT_OAK-12366";
+ public static final AtomicBoolean FT_OAK_12366_DISABLE = new
AtomicBoolean(false);
Review Comment:
Since this class is exported, removing this FT will be a breaking change
(and flagged as such during build). Should we move this FT toggle to a
non-exported class?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
