I wasn't really thinking yesterday the behavior I would expect is rather
} catch (RejectedExecutionException rex) {
if (!allowCurrentThread
|| (policy != null
&& policy.isSetAsyncExecuteTimeoutRejection()
&& policy.isAsyncExecuteTimeoutRejection())) {
throw rex;
}
if (!hasLoggedAsyncWarning) {
LOG.warning("EXECUTOR_FULL_WARNING");
hasLoggedAsyncWarning = true;
}
LOG.fine("EXECUTOR_FULL");
handleResponseInternal();
}
On Thu, Oct 18, 2018 at 9:17 PM Jan Hallonstén <[email protected]> wrote:
> Hi,
>
> When the WorkQueue rejects the execution in
> HttpConduit.handleResponseOnWorkqueue(boolean allowCurrentThread, boolean
> forceWQ) and allowCurrentThread is false the handling of the response is
> always done on the current thread. I would expect it to be the other way
> around. In my scenario the method is called from the AsyncHttpConduit and
> the response will be handled by one of the io core threads which is not
> something I want. I would like to be able to set
> AsyncExecuteTimeoutRejection when using the async cxf client. So is this a
> bug that should be reported or does it work as designed?
>
> } catch (RejectedExecutionException rex) {
> if (allowCurrentThread
> && policy != null
> && policy.isSetAsyncExecuteTimeoutRejection()
> && policy.isAsyncExecuteTimeoutRejection()) {
> throw rex;
> }
> if (!hasLoggedAsyncWarning) {
> LOG.warning("EXECUTOR_FULL_WARNING");
> hasLoggedAsyncWarning = true;
> }
> LOG.fine("EXECUTOR_FULL");
> handleResponseInternal();
> }
>
> I would like to negate allowCurrentThread in the if statement instead
>
> if (!allowCurrentThread
> && policy != null
> && policy.isSetAsyncExecuteTimeoutRejection()
> && policy.isAsyncExecuteTimeoutRejection()) {
> throw rex;
> }
>
> Link to the relevant code at Github
>
> https://github.com/apache/cxf/blob/540bb76f6f3d3d23944c566905f9f395c6f86b79/rt/transports/http/src/main/java/org/apache/cxf/transport/http/HTTPConduit.java#L1245
>
> Regards,
> Jan
>
