Open rvansa opened 2 years ago
/cc @FroMage, @geoand, @stuartwdouglas
Reading through ServerRequestFilter
javadocs it looks like I should not do any blocking operation in that filter anyway.
Thanks for reporting.
I'll have a look on Monday
So this is actually the expected behavior - the filter uses the same thread as the resource method.
As you mention, to explicitly control the behavior of the filter, you can use @Blocking
and @NonBlocking
.
Do you mind adding the entire stacktrace to the description? I was not able to reproduce the issue with an example application I have.
@geoand Added stacktrace.
You are probably right that the behaviour is more predictable when a non-blocking method is executed by the I/O thread regardless of the filter. Had you transparently switched to blocking thread when the filter is added there would be a non-obvious performance drop.
The problem (except error reporting) then is that the default value for the filter is blocking while you treat it as non-blocking, and IIUC setting blocking = false
actually means to force running on I/O thread and then switch to pooled thread if needed. So there are in fact 3 possible options how to run it:
a) same thread as target method b) force I/O thread c) force pooled thread
a) as the default makes sense to me. There's no option right now for c) - you could consider using @Blocking
on the filter. You could select b) through a property of @ServerRequestFilter
. However I would drop the blocking
with default true
as this is confusing.
You are probably right that the behaviour is more predictable when a non-blocking method is executed by the I/O thread regardless of the filter. Had you transparently switched to blocking thread when the filter is added there would be a non-obvious performance drop.
Yeah, that's the idea.
However I would drop the blocking with default true as this is confusing.
Completely agreed, it's currently very confusing. We should probably introduce some kind of enum
for handling this (and deprecate the current boolean field).
@Sgitario how do you feel about this one? Would you be interested in it (fair warning: it's probably requires a little more work than one thinks when first looking at it)?
Describe the bug
I have a non-blocking method in my API:
and I use a custom
ServerRequestFilter
that invokes a potentially blocking call toSecurityIdentity.isAnonymous()
. The filter is blocking (default value for the annotation):Since the method is non-blocking RESTEasy decides to invoke the method on I/O thread and I get an exception:
Workaround of marking the method
@Blocking
works.Expected behavior
The operation is invoked on a blocking thread and is successful.
Actual behavior
The operation is executed on I/O thread. Message is a bit confusing since it speaks about the method, but the stack trace shows clearly that the blocking call happens in the filter.
Full stack trace:
How to Reproduce?
No response
Output of
uname -a
orver
No response
Output of
java -version
No response
GraalVM version (if different from Java)
No response
Quarkus version or git rev
2.9.2
Build tool (ie. output of
mvnw --version
orgradlew --version
)No response
Additional information
No response