Signed-off-by: zenios [email protected]

Notes:

1. Hardcoded netty version (4.1.48.Final) for netty-codec-haproxy in order to avoid creating a pull request for vertx-dependencies

2. Tests were copied from #1271. That PR can be closed if this one gets merged

As discussed here previously, starting with vert.x 3.5.0 I was noticing failing integration tests when uploading large (at least a few MB) files. The issue so far only appeared when running against mongo in a docker container or with travis ci. Downgrading to vert.x 3.4.0 seems to fix the issue. This issue does not appear on every build. I once examined the differences between the uploaded and the persisted file and it showed that about the first 1054400 bytes were correctly persisted, but subsequent bytes were corrupt. I could not find any issues with file download. Just the upload seems to encouter this issue.

I have put a branch together which explicitly compares the md5 checksums of the uploaded file in addition to the actual bytes with vertx 3.5.1-SNAPSHOT travis available here - source

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running com.github.sth.vertx.mongo.streams.GridFSInOutStreamIT
Cluster created with settings {hosts=[localhost:27017], mode=SINGLE, requiredClusterType=UNKNOWN, serverSelectionTimeout='30000 ms', maxWaitQueueSize=500} 
Opened connection [connectionId{localValue:1, serverValue:1}] to localhost:27017 
Monitor thread successfully connected to server with description ServerDescription{address=localhost:27017, type=STANDALONE, state=CONNECTED, ok=true, version=ServerVersion{versionList=[3, 4, 10]}, minWireVersion=0, maxWireVersion=5, maxDocumentSize=16777216, roundTripTimeNanos=4467832} 
Opened connection [connectionId{localValue:2, serverValue:2}] to localhost:27017 
uploaded file md5: e875acd2c89e7db444f04c54c5b01460
java.lang.AssertionError: uploaded file md5 does not match md5 calculated on server. Not equals : 31C48A5A246C9352E0EB846FEFD0A498 != E875ACD2C89E7DB444F04C54C5B01460 
Cluster created with settings {hosts=[localhost:27017], mode=SINGLE, requiredClusterType=UNKNOWN, serverSelectionTimeout='30000 ms', maxWaitQueueSize=500} 
Opened connection [connectionId{localValue:3, serverValue:3}] to localhost:27017 
Monitor thread successfully connected to server with description ServerDescription{address=localhost:27017, type=STANDALONE, state=CONNECTED, ok=true, version=ServerVersion{versionList=[3, 4, 10]}, minWireVersion=0, maxWireVersion=5, maxDocumentSize=16777216, roundTripTimeNanos=895998} 
Opened connection [connectionId{localValue:4, serverValue:4}] to localhost:27017 
Closed connection [connectionId{localValue:2, serverValue:2}] to localhost:27017 because the pool has been closed. 
Cluster created with settings {hosts=[localhost:27017], mode=SINGLE, requiredClusterType=UNKNOWN, serverSelectionTimeout='30000 ms', maxWaitQueueSize=500} 
Opened connection [connectionId{localValue:5, serverValue:5}] to localhost:27017 
Monitor thread successfully connected to server with description ServerDescription{address=localhost:27017, type=STANDALONE, state=CONNECTED, ok=true, version=ServerVersion{versionList=[3, 4, 10]}, minWireVersion=0, maxWireVersion=5, maxDocumentSize=16777216, roundTripTimeNanos=2004399} 
Opened connection [connectionId{localValue:6, serverValue:6}] to localhost:27017 
uploaded file md5: b563f831734cf630117017f006470f8a
Cluster created with settings {hosts=[localhost:27017], mode=SINGLE, requiredClusterType=UNKNOWN, serverSelectionTimeout='30000 ms', maxWaitQueueSize=500} 
No server chosen by WritableServerSelector from cluster description ClusterDescription{type=UNKNOWN, connectionMode=SINGLE, serverDescriptions=[ServerDescription{address=localhost:27017, type=UNKNOWN, state=CONNECTING}]}. Waiting for 30000 ms before timing out 
Closed connection [connectionId{localValue:6, serverValue:6}] to localhost:27017 because the pool has been closed. 
Opened connection [connectionId{localValue:7, serverValue:7}] to localhost:27017 
Monitor thread successfully connected to server with description ServerDescription{address=localhost:27017, type=STANDALONE, state=CONNECTED, ok=true, version=ServerVersion{versionList=[3, 4, 10]}, minWireVersion=0, maxWireVersion=5, maxDocumentSize=16777216, roundTripTimeNanos=651115} 
Opened connection [connectionId{localValue:8, serverValue:8}] to localhost:27017 
Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 6.561 sec <<< FAILURE! - in com.github.sth.vertx.mongo.streams.GridFSInOutStreamIT
testUploadAndDownloadLarge(com.github.sth.vertx.mongo.streams.GridFSInOutStreamIT)  Time elapsed: 4.324 sec  <<< FAILURE!
java.lang.AssertionError: uploaded file md5 does not match md5 calculated on server. Not equals : 31C48A5A246C9352E0EB846FEFD0A498 != E875ACD2C89E7DB444F04C54C5B01460

this is a build using vertx 3.4.0 which never failed so far

Signed-off-by: Srijan Gupta [email protected]

Motivation:

If you are making http request to a remote-service with keep-alive: true the connection will never recycle if the request rate is high. In this scenario if a deployment took place for the remote service with blue-green configuration. Our client will still hit requests to old stack. To solve this keeping a global TTL for active connections makes sense. Similar to node's: https://www.npmjs.com/package/agentkeepalive#new-agentoptions

Hi all,

First of all, Thank you for the amazing work with vertx.

I am testing the Version 3.5.0 with an nginx reverse proxy.

If I turn off the keep-alive functionality, the HttpServerResponseImpl is not answering anything.

You can test using the following HTTP requests:

Not working

GET / HTTP/1.0.
Host: my-server.com
X-Real-IP: 127.0.0.1.
X-Forwarded-For: 127.0.0.1.
Connection: close.
Cache-Control: max-age=0.
Upgrade-Insecure-Requests: 1.
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.79 Safari/537.36.
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8.
Accept-Encoding: gzip, deflate.
Accept-Language: pt-BR,pt;q=0.8,en-US;q=0.6,en;q=0.4.
.

Working

GET / HTTP/1.1.
Host: my-server.com
X-Real-IP: 127.0.0.1.
X-Forwarded-For: 127.0.0.1.
Cache-Control: max-age=0.
Upgrade-Insecure-Requests: 1.
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.79 Safari/537.36.
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8.
Accept-Encoding: gzip, deflate.
Accept-Language: pt-BR,pt;q=0.8,en-US;q=0.6,en;q=0.4.
.

This is because of the Connection: close

After a debug, I found that if HttpServerResponseImpl line 442 keepAlive is false, it is working as expected

    if (!keepAlive) {
      closeConnAfterWrite();
      closed = true;
    }

So I suspect that the closeConnAfterWrite is not working as expected.

I would appreciate if you can take a look on it.

motivation : SNI is an important features for virtual hosting

changes: provides SNI support for HttpClient/HttpServer/NetClient/NetServer. On the server certificates are matched using the certificate CN or SAN DNS, the PemKeyCertOptions has been extended to support multiple entries for this matter. For HttpClient, the host header value is sent as SNI server name, for NetClient the connect method is overloaded to provide the server name in addition of the connect host.

please review @pmlopes @alexlehm @cescoffier

Hi all,

We are big fans of VertX! We are working on setuping a cluster of at least 20 Vertx JVM in a single cluster. When starting playing killing nodes, more than one node in few seconds, we found that the vertx event bus cluster becomes unstable. After drilling down into the code, we found that the clusterMap of HAManager, and subs multimap of the ClusteredEventBus are often corrupted:

• sometimes, references on nodes killed are still present in clusterMap and subs multimap
• sometimes, references on nodes still running are missing in clusterMap and subs multimap

So we suggest to make sure to clean the maps from each node and not only from an elligible node. And we also suggest that each node is sending every 10 seconds their key/value into the clusterMap and subs multimap.

The main benefits are that when the nodes are killed, after few seconds, the map are correctly cleaned-up, and running nodes are populating again the maps. Even under load (we tested it), the cluster becomes available again and 100% operational. We tested up to 20 running nodes and 80% of nodes loss, while the system were under load. The main drawback is that each node is responsible for sending (every 10s) their key/value constantly in the clusterMap and the subs multimap.

So we propose to enable this behavior when the HFT is enabled from VertxOptions (High Fault Tolerance), since it will add additional traffic on the cluster which is not always necessary depending the deployment. (by default set to false). We have also the capability to change the delay of sending data to maps (HFTInterval) which is 10s by default.

Please comment, accept, deny or anything else about this pull request. We are strongly considering Vertx at the heart of our new infra for deploying micro-services, and the fault tolerance is only thing that we see as a showstopper.

Same issue already raised by other users:

• https://github.com/eclipse/vert.x/pull/1593
• https://github.com/vert-x3/vertx-hazelcast/issues/13

Vert.x version : 2.0.0-CR3-SNAPSHOT

When some opaque uri was created by "new URI(url.toExternalForm())", Paths.get throws IllegalAurgumentException(). ( see ) A opaque uri　for example, "file:src/main/resources/index.html". There may be any other solutions for that.

stacktrace:

org.vertx.java.core.VertxException: java.lang.IllegalArgumentException: URI is not hierarchical
        at org.vertx.java.core.file.impl.ClasspathPathResolver.resolve(ClasspathPathResolver.java:61)
        at org.vertx.java.core.file.impl.PathAdjuster.adjust(PathAdjuster.java:35)
        at org.vertx.java.core.file.impl.PathAdjuster.adjust(PathAdjuster.java:42)
        at com.wingnest.mathcloud.MathCloud.start(MathCloud.java:27)
        at org.vertx.java.platform.Verticle.start(Verticle.java:82)
        at org.vertx.java.platform.impl.DefaultPlatformManager$18.run(DefaultPlatformManager.java:1270)
        at org.vertx.java.core.impl.DefaultContext$3.run(DefaultContext.java:171)
        at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:353)
        at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:366)
        at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:101)
        at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.IllegalArgumentException: URI is not hierarchical
        at sun.nio.fs.WindowsUriSupport.fromUri(WindowsUriSupport.java:122)
        at sun.nio.fs.WindowsFileSystemProvider.getPath(WindowsFileSystemProvider.java:91)
        at java.nio.file.Paths.get(Paths.java:138)
        at org.vertx.java.core.file.impl.ClasspathPathResolver.resolve(ClasspathPathResolver.java:59)
        ... 10 more

Version

Which version did you encounter this bug? 4.0.2

Context

I'm using Vert.x Verticles to process messages sequentially per given address, up to 3.9.5 a consumer would only process messages in a sequential order but now they seem to be doing that concurrently.

Do you have a reproducer?

Yes, here is a simple unit test, it passes with 3.9.5 and fails with 4.0.2: https://gist.github.com/guidomedina/ff20d1531bf59e046dd5fd5599918052

I'm trying to create websocket client, but DNS resolution fails. It doesn't fails consistently, sometimes it succeeds. Example

package test;

import io.vertx.core.AbstractVerticle;
import io.vertx.core.http.HttpClientOptions;

public class Test extends AbstractVerticle {
  @Override
  public void start() {
    var httpOpts = new HttpClientOptions().setSsl(true);
    var client = vertx.createHttpClient(httpOpts);

    client.webSocket(443, "echo.websocket.org", "/", res -> {
      if (res.failed()) {
        res.cause().printStackTrace();
        return;
      }
      System.out.println("SUCCESS");
      res.result().handler(System.out::println);
    });
  }
}

Exception

io.netty.resolver.dns.DnsResolveContext$SearchDomainUnknownHostException: Search domain query failed. Original hostname: 'echo.websocket.org' failed to resolve 'echo.websocket.org.Home' after 3 queries 
	at io.netty.resolver.dns.DnsResolveContext.finishResolve(DnsResolveContext.java:925)
	at io.netty.resolver.dns.DnsResolveContext.tryToFinishResolve(DnsResolveContext.java:884)
	at io.netty.resolver.dns.DnsResolveContext.query(DnsResolveContext.java:356)
	at io.netty.resolver.dns.DnsResolveContext.onResponse(DnsResolveContext.java:543)
	at io.netty.resolver.dns.DnsResolveContext.access$400(DnsResolveContext.java:64)
	at io.netty.resolver.dns.DnsResolveContext$2.operationComplete(DnsResolveContext.java:400)
	at io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:500)
	at io.netty.util.concurrent.DefaultPromise.notifyListeners0(DefaultPromise.java:493)
	at io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:472)
	at io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:413)
	at io.netty.util.concurrent.DefaultPromise.setValue0(DefaultPromise.java:538)
	at io.netty.util.concurrent.DefaultPromise.setSuccess0(DefaultPromise.java:527)
	at io.netty.util.concurrent.DefaultPromise.trySuccess(DefaultPromise.java:98)
	at io.netty.resolver.dns.DnsQueryContext.setSuccess(DnsQueryContext.java:204)
	at io.netty.resolver.dns.DnsQueryContext.finish(DnsQueryContext.java:196)
	at io.netty.resolver.dns.DnsNameResolver$DnsResponseHandler.channelRead(DnsNameResolver.java:1296)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:352)
	at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:352)
	at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1421)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360)
	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:930)
	at io.netty.channel.nio.AbstractNioMessageChannel$NioMessageUnsafe.read(AbstractNioMessageChannel.java:93)
	at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:697)
	at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:632)
	at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:549)
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:511)
	at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:918)
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.base/java.lang.Thread.run(Thread.java:834)

Dig output

; <<>> DiG 9.14.7 <<>> echo.websocket.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26605
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;echo.websocket.org.		IN	A

;; ANSWER SECTION:
echo.websocket.org.	60	IN	A	174.129.224.73

;; Query time: 45 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Oct 17 12:26:26 CEST 2019
;; MSG SIZE  rcvd: 52

I'm using vertx 3.8.2 on OpenJDK 11 on Arch Linux.

groovy code, simple and standard: upload from browser like chrome, everything is ok! but if upload from a phonegap app, nothing happened! so I think the reason is that uploadHandler can not recognize upload file data from phonegap( data encode a little differently ).

req.uploadHandler { upload -> upload.exceptionHandler { cause -> req.response.end(">>>>>>>>>>Upload failed"); }

      upload.endHandler {
        println ">>>>>>>>>upload ok!"
        req.response.end("Upload successful!");
      }

      upload.streamToFileSystem(upload.filename);   
}

I'm writing non-blocking HTTP proxy server and faced with the issue: after several benchmark iterations my server stop handling requests. As I see pooled connections are in CLOSE_WAIT state (according to netstat) which means that remote server has closed them, but vert.x http client still keeps them for sending data. I suppose when new request arrives vert.x acquires one of them to pass the request and then hangs.

My environment: Vert.x 3.1.0 JDK 1.8 OS X 10.9.5

Code sample (Kotlin):

val clientOptions =
                HttpClientOptions()
                        .setDefaultHost("$BUCKET.s3.amazonaws.com")
                        .setMaxPoolSize(1000)

        val client = vertx.createHttpClient(clientOptions)

        val serverOptions =
                HttpServerOptions()
                .setAcceptBacklog(1000)

        vertx.createHttpServer(serverOptions)
                .requestHandler { request ->
                    val path = request.path()

                    when (request.method()) {                        
                        HttpMethod.GET -> {
                            client.get(path) { s3Response ->
                                if (s3Response.statusCode() != 200)
                                    request.response().setStatusCode(s3Response.statusCode()).end()
                                else {
                                    val response =
                                            request.response()
                                                    .putHeader(LENGTH_HEADER, s3Response.getHeader(LENGTH_HEADER))

                                    val pump = Pump.pump(s3Response, response)

                                    s3Response.endHandler { response.end() }

                                    pump.start()
                                }
                            }
                            .putHeader("Date", "...") // put required headers
                            .end()
                        }
                        else ->
                            request.response().setStatusCode(400).end("Unsupported HTTP verb")
                    }
                }
                .listen(8080) { result ->
                    if (result.succeeded())
                        future.complete()
                    else
                        future.fail(result.cause())
                }

...

@JvmStatic fun main(args: Array<String>) {
            Launcher.main(arrayOf("run", MyVerticle::class.java.name))
}

The issue looks similar to https://github.com/eclipse/vert.x/issues/1218 but differs in closing connection trigger - my case is a remote server closes connection explicitly. I suppose that http client should close it in order and remove from pool.

Describe the feature

Promise.completeWith(future); Promise.tryCompleteWith(future);

Use cases

This Api would be useful when inside a handler.

Contribution

Yes

…taskQueue anymore.

Motivation:

The current DuplicatedContext is not maintaining a seperated TaskQueue anymore.

Conformance:

You should have signed the Eclipse Contributor Agreement as explained in https://github.com/eclipse/vert.x/blob/master/CONTRIBUTING.md Please also make sure you adhere to the code style guidelines: https://github.com/vert-x3/wiki/wiki/Vert.x-code-style-guidelines

Version

4.3.7

Context

Test wheather a code is running on the same context of an vertical context.

Do you have a reproducer?

Yes

Steps to reproduce

The current

  default boolean isRunningOnContext() {
    return current() == this && inThread();
  }

in DuplicatedContext is not override by DuplicatedContext.

And the current DuplicatedContext has removed its own TaskQueue, and the javadoc seems need an update too.

Version

Which version(s) did you encounter this bug ? 4.3.2

Context

nonProxyHostList value overrides to null by creating new WebClientOptions from existing WebClientOptions

WebClientOptions options = new WebClientOptions();
options.setNonProxyHosts(Arrays.asList("10.*","localhost"));
options.setTrustAll(true);
ProxyOptions proxyOptions = new ProxyOptions();
    proxyOptions.setHost("proxy-server");
    proxyOptions.setPort(3128);
options.setProxyOptions(proxyOptions);

//check log level and set log activity
WebClientOptions  finalOptions = new WebClientOptions(options).setLogActivity(false);
finalOptions .getNonProxyHosts() //returns null

https://github.com/eclipse-vertx/vert.x/blob/master/src/main/java/io/vertx/core/net/ClientOptionsBase.java#L51-L73

Issue

"Invalid header name [X-B3-TraceId]" exception thrown when the WebClient request a same URL for second time. The WebClient is configured with HTTP2 and OpenTelemetry with B3Propagator.

Version

4.3.7

Context

I am getting the "Invalid header name [X-B3-TraceId]" exception when the WebClient request a same URL for second time. The WebClient is configured with HTTP2 and OpenTelemetry with B3Propagator.

The HTTP2 protocol requires all the headers to be in lower case. First WebClient request able to convert the tracing propagator headers to lower case, however the WebClient failed to do so on second request onward.

Exceptions:

io.netty.handler.codec.http2.Http2Exception: invalid header name [X-B3-TraceId] at io.netty.handler.codec.http2.Http2Exception.connectionError(Http2Exception.java:109) at io.netty.handler.codec.http2.DefaultHttp2Headers$2.validateName(DefaultHttp2Headers.java:71) at io.netty.handler.codec.http2.DefaultHttp2Headers$2.validateName(DefaultHttp2Headers.java:42) at io.netty.handler.codec.DefaultHeaders.validateName(DefaultHeaders.java:1012) at io.netty.handler.codec.http2.DefaultHttp2Headers.validateName(DefaultHttp2Headers.java:166) at io.netty.handler.codec.http2.DefaultHttp2Headers.validateName(DefaultHttp2Headers.java:33) at io.netty.handler.codec.DefaultHeaders.add(DefaultHeaders.java:329) at io.vertx.tracing.opentelemetry.HeadersPropagatorSetter.set(HeadersPropagatorSetter.java:24) at io.vertx.tracing.opentelemetry.HeadersPropagatorSetter.set(HeadersPropagatorSetter.java:17) at io.opentelemetry.extension.trace.propagation.B3PropagatorInjectorMultipleHeaders.inject(B3PropagatorInjectorMultipleHeaders.java:52) at io.opentelemetry.extension.trace.propagation.B3Propagator.inject(B3Propagator.java:111) at io.vertx.tracing.opentelemetry.OpenTelemetryTracer.sendRequest(OpenTelemetryTracer.java:130) at io.vertx.tracing.opentelemetry.OpenTelemetryTracer.sendRequest(OpenTelemetryTracer.java:31) at io.vertx.core.http.impl.Http2ClientConnection$StreamImpl.createStream(Http2ClientConnection.java:570) at io.vertx.core.http.impl.Http2ClientConnection$StreamImpl.writeHeaders(Http2ClientConnection.java:533) at io.vertx.core.http.impl.Http2ClientConnection$StreamImpl.lambda$writeHead$0(Http2ClientConnection.java:501) at io.vertx.core.impl.EventLoopContext.emit(EventLoopContext.java:55) at io.vertx.core.impl.ContextBase.emit(ContextBase.java:239) at io.vertx.core.http.impl.Http2ClientConnection$StreamImpl.writeHead(Http2ClientConnection.java:500) at io.vertx.core.http.impl.Http2UpgradeClientConnection$DelegatingStream.writeHead(Http2UpgradeClientConnection.java:138) at io.vertx.core.http.impl.HttpClientRequestImpl.doWrite(HttpClientRequestImpl.java:476) at io.vertx.core.http.impl.HttpClientRequestImpl.write(HttpClientRequestImpl.java:449) at io.vertx.core.http.impl.HttpClientRequestImpl.end(HttpClientRequestImpl.java:395) at io.vertx.core.http.impl.HttpClientRequestImpl.end(HttpClientRequestImpl.java:389) ...

Jan 04, 2023 10:53:13 AM io.vertx.core.http.impl.HttpClientRequestImpl SEVERE: invalid header name [X-B3-TraceId]

Do you have a reproducer?

Reproducer codes (Maven project): https://github.com/hsrky/vertx-otel-http2-b3-propagator/

Full exceptions and steps to reproduce: https://github.com/hsrky/vertx-otel-http2-b3-propagator/blob/main/README.md

Steps to reproduce

1. Run the main method on https://github.com/hsrky/vertx-otel-http2-b3-propagator/blob/main/src/main/java/com/example/starter/Main.java
2. The main method will serve a vertx HTTP server at port 8080, with /test endpoint.
3. Send HTTP GET request to http://localhost:8080/test and observe first request is success without error
4. Send same HTTP GET request to http://localhost:8080/test and observe second request failed with invalid header exception.