[
https://issues.apache.org/jira/browse/HTTPCORE-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17901877#comment-17901877
]
Oleg Kalnichevski commented on HTTPCORE-773:
--------------------------------------------
[~anithai1209]
# Please note HttpCore 4.4 is end-of-life. However HttpCore 5.x employs the
same fundamental principle of i/o event processing, so I will keep the ticket
open for now.
# i/o dispatch threads are _NOT_ meant for execution of long running or
blocking operations. This is the whole point of the i/o reactor pattern. If a
long running task needs to be executed, it must be off-loaded from the i/o
dispatch thread to a worker thread
# How do you propose we detect blocked i/o dispatch threads at runtime?
Overall, I am not entirely sure what you expect us to do.
Oleg
> Safeguard against blocked IOWorker thread
> -----------------------------------------
>
> Key: HTTPCORE-773
> URL: https://issues.apache.org/jira/browse/HTTPCORE-773
> Project: HttpComponents HttpCore
> Issue Type: Improvement
> Components: HttpCore NIO
> Reporter: Anithamahalakshmi
> Priority: Minor
>
> # During the initialisation of ApacheAsyncClient, a single main thread is
> created -
> [https://github.com/xSke/CoreServer/blob/master/src/org/apache/http/impl/nio/client/CloseableHttpAsyncClientBase.java#L40.]
> # This IO reactor thread does two key jobs: 1) It internally instantiate IO
> dispatcher threads once They never stop either. They keep polling for new IO
> event) and 2) It then works as a daemon (which never stops) to process new
> events. It worth to notice that all events IO reactor thread is connection
> related event per
> https://github.com/wso2/wso2-httpcore-nio/blob/master/modules/httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/DefaultConnectingIOReactor.java#L164
> # For http request which needs a new IO connection, IO reactor thread is
> invoked to create such IO connection asynchronously -
> [https://github.com/wso2/wso2-httpcore-nio/blob/master/modules/httpcore-nio/src/main/java/org/apache/http/nio/pool/AbstractNIOConnPool.java#L427]
> Connection pending to be created in such asynchronous process is reported as
> {{pending}} connection in Apache connection status.
> # In such asynchronous process, connection to be created is added into
> {{requestQueue}} -
> [https://github.com/wso2/wso2-httpcore-nio/blob/master/modules/httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/DefaultConnectingIOReactor.java#L251].
> {{requestQueue}} is later on polled by IO reactor thread as a daemon, and
> established channel should be handed off to IO dispatcher thread via
> following logic
> -[https://github.com/wso2/wso2-httpcore-nio/blob/master/modules/httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/DefaultConnectingIOReactor.java#L276].
> It is interesting to notice that which IO dispatcher thread such new channel
> should be handed off to is based on round-robin per
> [https://github.com/wso2/wso2-httpcore-nio/blob/master/modules/httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/AbstractMultiworkerIOReactor.java#L475.]
>
> # The IO dispatcher thread is expected to pull and process new IO event
> assigned to it by selector, and then process assigned new channel as well per
> [https://github.com/wso2/wso2-httpcore-nio/blob/master/modules/httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/AbstractIOReactor.java#L222]
> However if a certain IO dispatcher thread is blocked while some previous
> processing, it goes undetected and new requests+connection pair keep getting
> assigned to the blocked thread which is unable to process the request and
> release the connection back to the pool, eventually we exhaust the max
> connection possible from the pool and cause availability drop.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
