[jira] [Commented] (HTTPCORE-484) check timeout could use TimeWheel algorithm
[ https://issues.apache.org/jira/browse/HTTPCORE-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16542705#comment-16542705 ] ASF GitHub Bot commented on HTTPCORE-484: - Github user ok2c commented on the issue: https://github.com/apache/httpcomponents-core/pull/67 1. How come? That basically means that a read or write event can get triggered by an I/O reactor thread concurrently with a timeout event triggered by the time-wheel thread making it necessary to synchronize **_all_** methods of the `IOEventHandler` interface. This breaks current `IOEventHandler` contract and possibly negates all the performance gains from your changes 2. This is theory and it looks promising. But I still would like to see if it actually produces any performance in real life scenarios, especially in situations when _every_ channel sets a socket timeout. I do not think I can accept the change-set in its current state. It can be accepted if we can solve the concurrency issue and get some empirical evidence of performance improvement. Are you at the dev@hc.apache.org list? If not, please subscribe and let us discuss further steps on the dev list. > check timeout could use TimeWheel algorithm > --- > > Key: HTTPCORE-484 > URL: https://issues.apache.org/jira/browse/HTTPCORE-484 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore NIO >Affects Versions: 4.4.6 >Reporter: silver9886 >Assignee: Oleg Kalnichevski >Priority: Major > Fix For: 5.0-beta3 > > > check time out every this.selectTimeout,and had to iterator all the > SelectionKeys. > it is not efficient nor accurate when their is a lot of SelectionKeys. > I suggest use the TimeWheel algorithm when check the channel time out just > as netty do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-484) check timeout could use TimeWheel algorithm
[ https://issues.apache.org/jira/browse/HTTPCORE-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16542637#comment-16542637 ] ASF GitHub Bot commented on HTTPCORE-484: - Github user xiaohu-zhang commented on the issue: https://github.com/apache/httpcomponents-core/pull/67 1. yes,all the time out task is executed by a separate thread. but I dont think IOEventHandler need to synchronization because every channel has difference IOEventHandler instance. 2. suppose there is n channels . every loop interval find time out task, original algorithm time complexity is o(n).using time wheel time complexity is o(n/k),where k is ticks in PerWheel. original algorithm every interval will loop all the task ,the more accurate,the interval need to be reduced.but there is contradiction between reduce interval and loop all the task in the interval.time wheel every click only need to loop n/k task ,so click time interval can be very small ,so trigger the time out task will be more accurate.linux ,kafka,quartz and lots of framework using time wheel deal with timeout task. > check timeout could use TimeWheel algorithm > --- > > Key: HTTPCORE-484 > URL: https://issues.apache.org/jira/browse/HTTPCORE-484 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore NIO >Affects Versions: 4.4.6 >Reporter: silver9886 >Assignee: Oleg Kalnichevski >Priority: Major > Fix For: 5.0-beta3 > > > check time out every this.selectTimeout,and had to iterator all the > SelectionKeys. > it is not efficient nor accurate when their is a lot of SelectionKeys. > I suggest use the TimeWheel algorithm when check the channel time out just > as netty do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-484) check timeout could use TimeWheel algorithm
[ https://issues.apache.org/jira/browse/HTTPCORE-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16541719#comment-16541719 ] ASF GitHub Bot commented on HTTPCORE-484: - Github user garydgregory commented on the issue: https://github.com/apache/httpcomponents-core/pull/67 It would be great to show a small program that demonstrates the performance difference. Maybe something that can be run before and after the patch is applied. > check timeout could use TimeWheel algorithm > --- > > Key: HTTPCORE-484 > URL: https://issues.apache.org/jira/browse/HTTPCORE-484 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore NIO >Affects Versions: 4.4.6 >Reporter: silver9886 >Assignee: Oleg Kalnichevski >Priority: Major > Fix For: 5.0-beta3 > > > check time out every this.selectTimeout,and had to iterator all the > SelectionKeys. > it is not efficient nor accurate when their is a lot of SelectionKeys. > I suggest use the TimeWheel algorithm when check the channel time out just > as netty do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-484) check timeout could use TimeWheel algorithm
[ https://issues.apache.org/jira/browse/HTTPCORE-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16541704#comment-16541704 ] ASF GitHub Bot commented on HTTPCORE-484: - Github user ok2c commented on the issue: https://github.com/apache/httpcomponents-core/pull/67 @xiaohu-zhang I have spent more time looking at the proposed change-set. 1. Do I understand it correctly that with this patch all `IOEventHandler#timeout` events will be executed by a separate thread and will require synchronization for all `IOEventHandler` implementations? 2. Can you quantify performance improvement with the proposed change-set? What kind of performance improvement can we expect? > check timeout could use TimeWheel algorithm > --- > > Key: HTTPCORE-484 > URL: https://issues.apache.org/jira/browse/HTTPCORE-484 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore NIO >Affects Versions: 4.4.6 >Reporter: silver9886 >Assignee: Oleg Kalnichevski >Priority: Major > Fix For: 5.0-beta3 > > > check time out every this.selectTimeout,and had to iterator all the > SelectionKeys. > it is not efficient nor accurate when their is a lot of SelectionKeys. > I suggest use the TimeWheel algorithm when check the channel time out just > as netty do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-484) check timeout could use TimeWheel algorithm
[
https://issues.apache.org/jira/browse/HTTPCORE-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16539958#comment-16539958
]
ASF GitHub Bot commented on HTTPCORE-484:
-
Github user xiaohu-zhang commented on the issue:
https://github.com/apache/httpcomponents-core/pull/67
1. testTimeoutInSSecond method in class TestHashedWheelTimer should rename
to testTimeoutInSecond ,I dont have permission to push to your branch.
2.why delete
if (isWindows()) {
-sleepTimeMs = sleepTimeMs / 10 * 10;
-}
in HashedWheelTimer class. the comment is clearly said why use this code
blocks in netty.
3. I agree with you set package private. I dont like HashedWheelTimer being
static too.Because
HashedWheelTimer class is used only in framework,I think we could change
HashedWheelTimer to be
singleton
> check timeout could use TimeWheel algorithm
> ---
>
> Key: HTTPCORE-484
> URL: https://issues.apache.org/jira/browse/HTTPCORE-484
> Project: HttpComponents HttpCore
> Issue Type: Improvement
> Components: HttpCore NIO
>Affects Versions: 4.4.6
>Reporter: silver9886
>Assignee: Oleg Kalnichevski
>Priority: Major
> Fix For: 5.0-beta3
>
>
> check time out every this.selectTimeout,and had to iterator all the
> SelectionKeys.
> it is not efficient nor accurate when their is a lot of SelectionKeys.
> I suggest use the TimeWheel algorithm when check the channel time out just
> as netty do.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-484) check timeout could use TimeWheel algorithm
[ https://issues.apache.org/jira/browse/HTTPCORE-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16538157#comment-16538157 ] ASF GitHub Bot commented on HTTPCORE-484: - Github user ok2c commented on the issue: https://github.com/apache/httpcomponents-core/pull/67 @xiaohu-zhang This is a much bigger change that I have initially anticipated. It will take me a while to absorb it. First off, I do not think HttpCore should expose any of those classes in its public APIs. I moved the classes to the `org.apache.hc.core5.reactor` package and I intend to make them all package private. Those people who need it as a generic, re-usable time-wheel implementation should be using Netty instead. I am also trying to reduce the amount of code and classes that we would end up maintaining. I also dislike `HashedWheelTimer` instance being static. My code can be found here: https://github.com/ok2c/httpcore/tree/timewheel It is still in very early stages. > check timeout could use TimeWheel algorithm > --- > > Key: HTTPCORE-484 > URL: https://issues.apache.org/jira/browse/HTTPCORE-484 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore NIO >Affects Versions: 4.4.6 >Reporter: silver9886 >Assignee: Oleg Kalnichevski >Priority: Major > Fix For: 5.0-beta3 > > > check time out every this.selectTimeout,and had to iterator all the > SelectionKeys. > it is not efficient nor accurate when their is a lot of SelectionKeys. > I suggest use the TimeWheel algorithm when check the channel time out just > as netty do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-484) check timeout could use TimeWheel algorithm
[ https://issues.apache.org/jira/browse/HTTPCORE-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533694#comment-16533694 ] ASF GitHub Bot commented on HTTPCORE-484: - Github user xiaohu-zhang commented on the issue: https://github.com/apache/httpcomponents-core/pull/67 that is ok.Look forward to your reply.If anything wrong,let me know.If license is not ok,I can write it by my self. > check timeout could use TimeWheel algorithm > --- > > Key: HTTPCORE-484 > URL: https://issues.apache.org/jira/browse/HTTPCORE-484 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore NIO >Affects Versions: 4.4.6 >Reporter: silver9886 >Assignee: Oleg Kalnichevski >Priority: Major > Fix For: 5.0-beta3 > > > check time out every this.selectTimeout,and had to iterator all the > SelectionKeys. > it is not efficient nor accurate when their is a lot of SelectionKeys. > I suggest use the TimeWheel algorithm when check the channel time out just > as netty do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-484) check timeout could use TimeWheel algorithm
[ https://issues.apache.org/jira/browse/HTTPCORE-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533412#comment-16533412 ] ASF GitHub Bot commented on HTTPCORE-484: - Github user ok2c commented on the issue: https://github.com/apache/httpcomponents-core/pull/67 @xiaohu-zhang This is a large chunk of code that comes directly from another project. The code is ASLv2 licensed and based on published academic research. I personally do not see a problem taking this code but I would like to adjust it a bit more to our coding conventions. It may take me a few days or more. Please bear with me. > check timeout could use TimeWheel algorithm > --- > > Key: HTTPCORE-484 > URL: https://issues.apache.org/jira/browse/HTTPCORE-484 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore NIO >Affects Versions: 4.4.6 >Reporter: silver9886 >Priority: Major > Fix For: 5.0 > > > check time out every this.selectTimeout,and had to iterator all the > SelectionKeys. > it is not efficient nor accurate when their is a lot of SelectionKeys. > I suggest use the TimeWheel algorithm when check the channel time out just > as netty do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-484) check timeout could use TimeWheel algorithm
[ https://issues.apache.org/jira/browse/HTTPCORE-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16532786#comment-16532786 ] ASF GitHub Bot commented on HTTPCORE-484: - GitHub user xiaohu-zhang opened a pull request: https://github.com/apache/httpcomponents-core/pull/67 HTTPCORE-484 use TimeWheel algorithm to deal with time out HashedWheelTimer and related util classes are copied from netty framework with tiny changes. You can merge this pull request into a Git repository by running: $ git pull https://github.com/xiaohu-zhang/httpcomponents-core TimeWheelForPR Alternatively you can review and apply these changes as the patch at: https://github.com/apache/httpcomponents-core/pull/67.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #67 > check timeout could use TimeWheel algorithm > --- > > Key: HTTPCORE-484 > URL: https://issues.apache.org/jira/browse/HTTPCORE-484 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore NIO >Affects Versions: 4.4.6 >Reporter: silver9886 >Priority: Major > Fix For: 5.0 > > > check time out every this.selectTimeout,and had to iterator all the > SelectionKeys. > it is not efficient nor accurate when their is a lot of SelectionKeys. > I suggest use the TimeWheel algorithm when check the channel time out just > as netty do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-484) check timeout could use TimeWheel algorithm
[ https://issues.apache.org/jira/browse/HTTPCORE-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16532388#comment-16532388 ] ASF GitHub Bot commented on HTTPCORE-484: - Github user xiaohu-zhang closed the pull request at: https://github.com/apache/httpcomponents-core/pull/66 > check timeout could use TimeWheel algorithm > --- > > Key: HTTPCORE-484 > URL: https://issues.apache.org/jira/browse/HTTPCORE-484 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore NIO >Affects Versions: 4.4.6 >Reporter: silver9886 >Priority: Major > Fix For: 5.0 > > > check time out every this.selectTimeout,and had to iterator all the > SelectionKeys. > it is not efficient nor accurate when their is a lot of SelectionKeys. > I suggest use the TimeWheel algorithm when check the channel time out just > as netty do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-484) check timeout could use TimeWheel algorithm
[ https://issues.apache.org/jira/browse/HTTPCORE-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16531076#comment-16531076 ] ASF GitHub Bot commented on HTTPCORE-484: - GitHub user xiaohu-zhang opened a pull request: https://github.com/apache/httpcomponents-core/pull/66 Use TimeWheel algorithm instead of loop when check timeout HashedWheelTimer and related util classes are copied from netty framework with tiny changes. use TimeWheel algorithm to deal with both connect time out and read time out. related with HTTPCORE-484 You can merge this pull request into a Git repository by running: $ git pull https://github.com/xiaohu-zhang/httpcomponents-core TimeWheel Alternatively you can review and apply these changes as the patch at: https://github.com/apache/httpcomponents-core/pull/66.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #66 commit 4d7a18420cd66dd17387b845b324b241281d7fcc Author: xiaohu-zhang Date: 2017-08-29T14:11:24Z setting time limit on processPending methods setting time limit to avoid the SingleCoreIOReactor's time be exhausted and then block the remaining work to do. commit b6043b3aa94c65b23bb39804342a7826dc236eae Author: xiaohu-zhang Date: 2017-08-30T03:27:04Z Merge branch 'master' of https://github.com/apache/httpcomponents-core/commits/master commit 0f58c65f06f0defd5c03b8e21c76e5ce533796e5 Author: xiaohu-zhang Date: 2017-09-04T11:02:50Z Merge branch 'master' of https://github.com/apache/httpcomponents-core # Conflicts: # httpcore5/src/main/java/org/apache/hc/core5/reactor/SingleCoreIOReactor.java commit 1cd22c701259a61207d538d0881a04484b9ca405 Author: xiaohu-zhang Date: 2017-09-06T13:33:35Z Merge branch 'master' of https://github.com/apache/httpcomponents-core commit 9f28dcfa49979a6f0c0bf6312749f3daca8c8bd3 Author: Oleg Kalnichevski Date: 2017-09-06T14:42:50Z HTTPCORE-489: tweak SSL protocol mismatch test case to work around the problem with intermittent failures on Windows commit 3b0bbac649499e2d1ecb1b089e29af72a93f37ca Author: Oleg Kalnichevski Date: 2017-09-27T15:55:24Z Drop oraclejdk7 from the Travis-CI build commit 3eae2ab92d9aed582f2346fe0de55b1a6080fd41 Author: Oleg Kalnichevski Date: 2017-09-28T20:31:07Z Fixed header logging in non-blocking client and server protocol handlers commit a0c624056b2870c9af791beb5b4faa14cb392058 Author: Oleg Kalnichevski Date: 2017-09-29T14:42:34Z Make basic string, byte array and file entity producers repeatable commit d07a2a78466e3ccf2e4054c4306d55c0e3d896a8 Author: Gary Gregory Date: 2017-10-05T17:48:49Z [HTTPCORE-494] Add image constants to ContentType. commit e81d893f36f4a9231b74d8a6feb620beb316b340 Author: Gary Gregory Date: 2017-10-05T18:06:53Z [HTTPCORE-494] Add image constants to ContentType. commit f6906ed18e56d5163dd2a2dfa0f9669a834aa91d Author: Oleg Kalnichevski Date: 2017-10-16T14:06:13Z Fixed handling of relative request paths in BasicHttpRequest commit ba88cc43d6c1062a611cba3d65b49ff95a87adcd Author: Oleg Kalnichevski Date: 2017-10-20T09:35:57Z Silence doclint warning about missing @param and @throws commit d839711bd93871cb980cc7808dc2a9e899e5f867 Author: Oleg Kalnichevski Date: 2017-10-20T11:36:42Z HTTPCORE-495: add context details to ParseException commit 7cf31a110768f2d8cdac0cfbcdd8cf619cc59598 Author: Oleg Kalnichevski Date: 2017-10-20T12:30:04Z Upgraded httpcomponents-parent to version 9 commit c1c391c4c19cb4601904f25482cb7f0b4e0489b1 Author: Oleg Kalnichevski Date: 2017-10-20T14:39:53Z Compatibility with Java 9 (tested with Oracle JDK 9.0.1) commit d9ac44e9712b251567f4191b853f66f193a2164d Author: Oleg Kalnichevski Date: 2017-10-20T14:45:51Z Added Oracle JDK 9 to Travis CI config commit ced6ad940893a99d90e4002c68de86be89baa3cb Author: Oleg Kalnichevski Date: 2017-10-20T14:51:47Z Revert "Silence doclint warning about missing @param and @throws" This reverts commit e948fb1cb4090264a7bb078945d63fd31c5793b5. commit 0ba626fa834748b8d96712a4c3751bdbfbac20b4 Author: Oleg Kalnichevski Date: 2017-10-22T12:05:48Z Default I/O reactors to allow null IOReactorConfig parameter commit 69b30da7cb7d20d370c68dba1a2983c2f37c9e19 Author: Oleg Kalnichevski Date: 2017-10-22T12:17:41Z Renamed HTTP/2 TLS example (no functional changes) commit 41d7b1ad194dec748644c08713be616049a19f07 Author: Oleg Kalnichevski Date: 2017-10-24T11:31:01Z Added functional Transformation and Resolver interfaces commit f779f007018cf9596cb9e479b5f14a344e774676 Author: Oleg Kalnichevski Date: 2017-10-24T12:01:03Z Moved last read / write even time tracking from the I/O reactor to I/O sessions commit d35a76f4c729cb0dc8ce7b4
[jira] [Commented] (HTTPCORE-484) check timeout could use TimeWheel algorithm
[ https://issues.apache.org/jira/browse/HTTPCORE-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16146460#comment-16146460 ] ASF GitHub Bot commented on HTTPCORE-484: - Github user xiaohu-zhang commented on the issue: https://github.com/apache/httpcomponents-core/pull/50 this change is not related to HTTPCORE-484 > check timeout could use TimeWheel algorithm > --- > > Key: HTTPCORE-484 > URL: https://issues.apache.org/jira/browse/HTTPCORE-484 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore NIO >Affects Versions: 4.4.6 >Reporter: silver9886 > Fix For: 5.0 > > > check time out every this.selectTimeout,and had to iterator all the > SelectionKeys. > it is not efficient nor accurate when their is a lot of SelectionKeys. > I suggest use the TimeWheel algorithm when check the channel time out just > as netty do. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-484) check timeout could use TimeWheel algorithm
[ https://issues.apache.org/jira/browse/HTTPCORE-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16145524#comment-16145524 ] ASF GitHub Bot commented on HTTPCORE-484: - Github user ok2c commented on the issue: https://github.com/apache/httpcomponents-core/pull/50 Is there any particular reason for choosing the limit of 10? Is this change related to HTTPCORE-484 in any way? > check timeout could use TimeWheel algorithm > --- > > Key: HTTPCORE-484 > URL: https://issues.apache.org/jira/browse/HTTPCORE-484 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore NIO >Affects Versions: 4.4.6 >Reporter: silver9886 > Fix For: 5.0 > > > check time out every this.selectTimeout,and had to iterator all the > SelectionKeys. > it is not efficient nor accurate when their is a lot of SelectionKeys. > I suggest use the TimeWheel algorithm when check the channel time out just > as netty do. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-484) check timeout could use TimeWheel algorithm
[ https://issues.apache.org/jira/browse/HTTPCORE-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16143114#comment-16143114 ] Oleg Kalnichevski commented on HTTPCORE-484: https://github.com/apache/httpcomponents-core Please do your development off master. We'll see whether or not the changes could be ported to 4.4.x depending on how extensive they turn out to be. Oleg > check timeout could use TimeWheel algorithm > --- > > Key: HTTPCORE-484 > URL: https://issues.apache.org/jira/browse/HTTPCORE-484 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore NIO >Affects Versions: 4.4.6 >Reporter: silver9886 > Fix For: 5.0 > > > check time out every this.selectTimeout,and had to iterator all the > SelectionKeys. > it is not efficient nor accurate when their is a lot of SelectionKeys. > I suggest use the TimeWheel algorithm when check the channel time out just > as netty do. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-484) check timeout could use TimeWheel algorithm
[ https://issues.apache.org/jira/browse/HTTPCORE-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16143028#comment-16143028 ] silver9886 commented on HTTPCORE-484: - please give the git url I should fork.fork from https://github.com/xiaohu-zhang/httpcomponents-core/tree/4.4.x or from https://github.com/xiaohu-zhang/httpcomponents-core thank you > check timeout could use TimeWheel algorithm > --- > > Key: HTTPCORE-484 > URL: https://issues.apache.org/jira/browse/HTTPCORE-484 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore NIO >Affects Versions: 4.4.6 >Reporter: silver9886 > Fix For: 5.0 > > > check time out every this.selectTimeout,and had to iterator all the > SelectionKeys. > it is not efficient nor accurate when their is a lot of SelectionKeys. > I suggest use the TimeWheel algorithm when check the channel time out just > as netty do. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-484) check timeout could use TimeWheel algorithm
[ https://issues.apache.org/jira/browse/HTTPCORE-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16142507#comment-16142507 ] silver9886 commented on HTTPCORE-484: - thank you very much! I would like to do it very much !!! I will write the code from now on! > check timeout could use TimeWheel algorithm > --- > > Key: HTTPCORE-484 > URL: https://issues.apache.org/jira/browse/HTTPCORE-484 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore NIO >Affects Versions: 4.4.6 >Reporter: silver9886 > Fix For: 5.0 > > > check time out every this.selectTimeout,and had to iterator all the > SelectionKeys. > it is not efficient nor accurate when their is a lot of SelectionKeys. > I suggest use the TimeWheel algorithm when check the channel time out just > as netty do. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
