You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by GitBox <gi...@apache.org> on 2022/06/30 06:44:30 UTC
[GitHub] [camel-quarkus] jamesnetherton opened a new issue, #3888: Enable `platform-http-vertx` route processing to run on IO threads
jamesnetherton opened a new issue, #3888:
URL: https://github.com/apache/camel-quarkus/issues/3888
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.
--
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: commits-unsubscribe@camel.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-quarkus] jamesnetherton commented on issue #3888: Enable `platform-http-vertx` route processing to run on IO threads
Posted by GitBox <gi...@apache.org>.
jamesnetherton commented on issue #3888:
URL: https://github.com/apache/camel-quarkus/issues/3888#issuecomment-1216723216
https://issues.apache.org/jira/browse/CAMEL-18383
--
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: commits-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-quarkus] jamesnetherton commented on issue #3888: Enable `platform-http-vertx` route processing to run on IO threads
Posted by "jamesnetherton (via GitHub)" <gi...@apache.org>.
jamesnetherton commented on issue #3888:
URL: https://github.com/apache/camel-quarkus/issues/3888#issuecomment-1418715953
> 1. Seems like the discussion above suggests a parameter on the component.
Yes, that 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.
--
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: commits-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-quarkus] aldettinger commented on issue #3888: Enable `platform-http-vertx` route processing to run on IO threads
Posted by GitBox <gi...@apache.org>.
aldettinger commented on issue #3888:
URL: https://github.com/apache/camel-quarkus/issues/3888#issuecomment-1175882851
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.
--
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: commits-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-quarkus] InfoSec812 commented on issue #3888: Enable `platform-http-vertx` route processing to run on IO threads
Posted by "InfoSec812 (via GitHub)" <gi...@apache.org>.
InfoSec812 commented on issue #3888:
URL: https://github.com/apache/camel-quarkus/issues/3888#issuecomment-1416827782
@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.
--
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: commits-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org