[GitHub] httpcomponents-core issue #67: HTTPCORE-484 use TimeWheel algorithm to deal ...
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. --- - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] httpcomponents-core issue #67: HTTPCORE-484 use TimeWheel algorithm to deal ...
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. --- - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] httpcomponents-core issue #67: HTTPCORE-484 use TimeWheel algorithm to deal ...
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. --- - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] httpcomponents-core issue #67: HTTPCORE-484 use TimeWheel algorithm to deal ...
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? --- - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] httpcomponents-core issue #67: HTTPCORE-484 use TimeWheel algorithm to deal ...
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
---
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] httpcomponents-core issue #67: HTTPCORE-484 use TimeWheel algorithm to deal ...
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. --- - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] httpcomponents-core issue #67: HTTPCORE-484 use TimeWheel algorithm to deal ...
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. --- - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] httpcomponents-core issue #67: HTTPCORE-484 use TimeWheel algorithm to deal ...
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. --- - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
