Class loader issues in AvroRpcTest with Quarkus 2.0.0.Alpha3 #2651

[JiriOndrusek]

fixes #2651
supersedes #2845

Adds support of new SPI - apache/camel#5714

This enhancement uses vertx for the http server. Servers are started for required ports ad are managed via quarkus.
Tests are still using jetty http server - but only in scope test.

Unfortunatelly there is no public access to these methods (which have to be used in http server) - HttpTranscier#readBuffers, HttpTransciever#writeBuffers and HttpTransciever#writeLength. For that reason, vertx request handler has to leverage RespondServlet, which requires creation of very simple HttpServletRequest and HttpServletResponse, which basically wraps byte[].
It makes sense to ask whether it is possible to make these methods public (or for example through creations of class called VertxResponder). If yes, VertxHttpServer.java could be simplified - but that would be covered by follow-up issue.

@ppalaga It seems, that we don't need to use any blocking feature of vertx here, camel component waits for the response of the server. But there is a small issue here. Vertx logs warnings if thread is blocked for more than 2000 ms. I'm not sure whether this could affect users. (but it doesn't affect the functionality) WDYT?

[ppalaga]

@JiriOndrusek is there any reason why this PR is against camel-main? Wouldn't main be fine too?

[JiriOndrusek]

@ppalaga yes, you are right. I forgot that the current main already uses camel 3.11. I rebased PR.

[ppalaga]

This looks quite elegant!

Tests are still using jetty http server - but only in scope test.

I cannot find the scope change for the jetty artifact. Is it there?

Unfortunatelly there is no public access to these methods (which have to be used in http server) - HttpTranscier#readBuffers, HttpTransciever#writeBuffers and HttpTransciever#writeLength. For that reason, vertx request handler has to leverage RespondServlet, which requires creation of very simple HttpServletRequest and HttpServletResponse, which basically wraps byte[].
It makes sense to ask whether it is possible to make these methods public (or for example through creations of class called VertxResponder). If yes, VertxHttpServer.java could be simplified - but that would be covered by follow-up issue.

+1 this PR is OK for now, we can ask Avro to change the visibility and improve our code once they do. Actually when asking for some changes there, an avro-ipc artifact without the Servlet API dependency would be nice.

@ppalaga It seems, that we don't need to use any blocking feature of vertx here, camel component waits for the response of the server. But there is a small issue here. Vertx logs warnings if thread is blocked for more than 2000 ms.

My understanding is that ResponderServlet.service() entails the execution of the whole Camel route. We never know whether the code in the route is or is not going to block. Hence we have to handle it as blocking. @davsclaus may want to correct me if I am wrong.

[jamesnetherton]

We never know whether the code in the route is or is not going to block

Yeah - we had to deal with the same problem in the platform-http consumer. So we process the request on a separate thread with vertx.executeBlocking.

[JiriOndrusek]

Follow-up issue #2861
(in case that avro brings a better API for this case - https://issues.apache.org/jira/browse/AVRO-3166)

[ppalaga]

Looks good to me. @jamesnetherton would you like to throw a final look?

I have filed #2862 for the OpenStack failure

[jamesnetherton]

Looks ok to me, so let's merge as-is.

I still think there's potentially some room to optimise things a bit, but I need to dig into the Quarkus Vert.x internals before creating any follow-up issues.