[ https://issues.apache.org/jira/browse/HTTPCORE-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17902002#comment-17902002 ]
Anithamahalakshmi commented on HTTPCORE-773: -------------------------------------------- > 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: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org