Camel REST DSL misses control about reactive/virtual thread type usage #6856
Comments
|
Can you share some example code of what you're trying to do? If you're using the REST DSL in conjunction with the |
|
In the comments you can see my two tries to enforce a worker thread: To keep it simple, I omittet some complexitiy of my use case like POST and HEAD and other variants of the API. I will test to add camel-quarkus-platform-http - instead of the camel-quarkus-vertx-http extension, right? |
Looks like you don't need to change anything. You get What do the |
Yes, in the case of the PUT method, data is fetched via REST from another microservice and processed with a long running JNI call for a result - so I might need to keep that. But just adding the |
|
If possible, try swapping out If the issue stops happening, then we know the problem is likely isolated to the |
I removed the additional So |
Thanks for confirming 👍. I'll try to take a look at reproducing & fixing the problem next week. |
Thanks a lot so far for beeing so responsive, @jamesnetherton - have a nice weekend! |
|
Hi @jamesnetherton, Adding Replacing the Setting the Content-Lenght header manually failed for other methods like POST, GET and HEAD in the past and setting that manually did not succeed - so I deactivated this check on these methods already and calclate the value from the response body only for now. However, for PUT it works with I have more concerns about the internal server errors (HTTP Status Code 500) - this forces me to stay with So it looks like the log messages came from the use of |
|
I tried briefly to reproduce the issue with Can you explain a bit more about your usage of
|
|
Yes, i.e.in the PUT calls I do process large source images, fetched form another service, to a result image and they can have multiple 100 MB (at the moment up to ca 500 MB, may be 2 GB in the future of remote sensing data). So loading and processing them can take time, even when they run on the same node and cached locally. I am using an local object store - MinIO via I do not make use of a custom |
|
It'd help a lot if you could capture the stack trace for where the event loop is being blocked. This should enable more detail to be output from the void onComponentAdd(@Observes ComponentAddEvent event) {
if (event.getComponent() instanceof VertxHttpComponent component) {
VertxOptions vertxOptions = new VertxOptions();
vertxOptions.setWarningExceptionTime(TimeUnit.SECONDS.toNanos(1L));
component.setVertxOptions(vertxOptions);
}
} |
|
Actually, ignore the previous comment, I think it just needs a config option: |
|
@jamesnetherton, When doing REST client calls via When doing REST client calls via Here is the result - GDAL is the processing library getting called via JNI and there the warning exceptions starts: It also looks like the configuration is ignored - it says 2000ms instead of 1s configured... |
|
Ok - so it's blocked from the error handler. Need to think how the component should handle that... |
|
This will be fixed in Camel 4.8.3 / Camel 4.10.0. |
|
Great & many thanks! @jamesnetherton should I open a separate isssue for the Content-Length header adding problem - then I will do that soon and describe it in more detail there... |
Yes, please. Either here or over in the Camel core project (I assume it's a pure Camel issue unrelated to Quarkus): |
Bug description
I am using Camel Quarkus (latest/3.16.0) with REST DSL defined REST API in combination with some long running, blocking routes (usind JNI) when using HTTP PUT and in some configurations on HTTP POST too, but not on GET and HEAD. With (Camel) Quarkus REST switching to the reacive version of RestEasy by default, this generates warning exceptions about blocking thread(s).
I tried to use the @Blocking annotation for the REST DSL configuration/definition method or using .outType(String.class) in the fluent API to enforce the usage of a worker thread - without success.
I also could not find any documentation how to control the tread type in REST DSL, i.e. to use a worker tread or a virtual thread instead of the default I/O tread.
Is there a way to control the thread type?
If not, this should be fixed in my opinion, as potential workarounds like declaring a Jakarta EE REST API to set the return type or add the annotation and start Camel routes from there would be worse and switching back to RestEasy Classic seams to be difficult too (and would turn all my entry points to not make benefit of reactive behaviour or virtual threads).
I think, a REST DSL way to control the entry method thread type is missing and/or the documentation about how to do it or at least how to work around it in the context of Camel Quarkus.
The text was updated successfully, but these errors were encountered: