[
https://issues.apache.org/jira/browse/HTTPCORE-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17902002#comment-17902002
]
Anithamahalakshmi edited comment on HTTPCORE-773 at 11/30/24 1:34 AM:
----------------------------------------------------------------------
> once a channel has been assigned to the i/o selector associated with an i/o
> dispatch thread, i/o events on that channel cannot be reassigned to another
> selector (at least not easily).
Ack'd. But do we even need to reassign if we let the i/o dispatcher threads
poll for requests?The only channel that might be reassigned is the last one
that was assigned to the blocked i/o dispatcher threads, which should be safer
to be failed without having to reassign.
was (Author: JIRAUSER307901):
> once a channel has been assigned to the i/o selector associated with an i/o
> dispatch thread, i/o events on that channel cannot be reassigned to another
> selector (at least not easily).
Ack'd. But do we even need to reassign if we let the i/o dispatcher threads
poll for requests. The only channel that might be reassigned is the last one
that was assigned to the blocked i/o dispatcher threads, which should be safer
to be failed without having to reassign.
> 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: Major
> Fix For: 5.4-alpha1
>
>
> # 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: [email protected]
For additional commands, e-mail: [email protected]
