Enable `platform-http-vertx` route processing to run on IO threads

[jamesnetherton]

Relates to a discussion on Zulip here:

https://camel.zulipchat.com/#narrow/stream/257302-camel-quarkus/topic/Fully.20Non-Blocking.20Reactive

Currently, all of the route processing that comes after from("platform-http") is done on a worker thread:

https://github.com/apache/camel/blob/main/components/camel-platform-http-vertx/src/main/java/org/apache/camel/component/platform/http/vertx/VertxPlatformHttpConsumer.java#L168-L221

I wonder if we should introduce an option that determines whether a worker or IO thread is used. E.g if folks know the downstream route processing will not block, then they can choose to have the work done on an IO thread.

[aldettinger]

That' sounds like a good to experiment and it should be optional indeed.

If we happen to have a temporarily cq version where this is not optional, then, I think it would be possible to run the performance regression prototype to have an idea about the effect on performance.

[jamesnetherton]

https://issues.apache.org/jira/browse/CAMEL-18383

[InfoSec812]

@jamesnetherton Two questions for you with regards to this.

1. How would the Camel Context decide which route(s) are non-blocking and eligible? Seems like the discussion above suggests a parameter on the component.
2. Even if we were able to easily determine the blocking possibility, what does this gain? The blocking threadpool is going to be there anyhow, so it really doesn't save much if anything. Also, it provides a convenient foot-gun for people to shoot themselves with when they later change/amend a route and add a blocking step.

So, thinking this through, we would need to add an optional (and preferably default to off) option to run the route on the event loop thread. It's entirely likely that Vert.x/Quarkus will throw an error if a user later adds a blocking operation to the route, so it shouldn't be difficult to debug if they do.

The other side of this discussion is "are there already idiomatic ways to handle this in Camel today"... Perhaps handing off to a vertx:<address> eventbus or a seda endpoint which would pretty much immediately release the worker thread.

[jamesnetherton]

1. Seems like the discussion above suggests a parameter on the component.

Yes, that is what I was proposing.

2. Even if we were able to easily determine the blocking possibility, what does this gain? The blocking threadpool is going to be there anyhow.

Wouldn't that also be true for Quarkus? Or indeed any application built on Vert.x?

In terms of gain, we'd need to run some performance tests to get a read on it. I'm not proposing we make such a change without researching it a bit first.

It provides a convenient foot-gun for people to shoot themselves with when they later change/amend a route and add a blocking step

True. But you could argue that scenario is a reality in a plain Quarkus or Vert.x application.

We would need to add an optional (and preferably default to off) option to run the route on the event loop thread

That was pretty much my thinking. Preserve the current behavior by default and always run on a worker thread, unless the platform-http endpoint is configured to do otherwise.

The other side of this discussion is "are there already idiomatic ways to handle this in Camel today"... Perhaps handing off to a vertx eventbus or a seda endpoint.

For seda I'm not sure if that is the case. The platform-http consumer waits for the route pipeline to complete so it can return a response back to the client. So you'll not release the thread until that work is completed. Certainly if we had more components backed by Vert.x it'd likely help to improve things.