[
https://issues.apache.org/jira/browse/CXF-3627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058189#comment-13058189
]
Freeman Fang commented on CXF-3627:
-----------------------------------
Hi,
This code
{code}
} catch (RejectedExecutionException e) {
//the executor queue is full, so run the task in the caller thread
chain.resume();
{code}
ensure that we won't lose oneway invocation if the executor queue is full.
Anyway you can alawys configure a larger executor queue for high load. And I
agree that add a log to indicate the "the executor queue is full, so run the
task in the caller thread" should be good.
Freeman
> high load may cause deadlocks
> -----------------------------
>
> Key: CXF-3627
> URL: https://issues.apache.org/jira/browse/CXF-3627
> Project: CXF
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.4.1
> Reporter: Peter Repp
>
> we tried to implement bi directional ws communication (both sides are client
> and servers)
> methods were annotated with @oneway to make sure that on the other side
> request is processed in separate thread and to make sure requesting thread do
> not wait for the server processing (because server can issue another request
> back).
> Unfortunately there is confusing part of the code in
> org/apache/cxf/interceptor/OneWayProcessorInterceptor.java
> } catch (RejectedExecutionException e) {
> //the executor queue is full, so run the task in the caller thread
> chain.resume();
> that ignores @oneway and continues with the current thread, which means
> requesting thread (acting as client) will wait... in some cases forever (or
> till some network timeout)
> What is even worse, there is no single log line indicating that (and
> suggesting to increase thread pool size), so it was really hard to debug it
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
