[ 
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

Reply via email to