[jira] [Commented] (HTTPCORE-536) duplicate connect method could be extract
[ https://issues.apache.org/jira/browse/HTTPCORE-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16570120#comment-16570120 ] silver9886 commented on HTTPCORE-536: - understand > duplicate connect method could be extract > - > > Key: HTTPCORE-536 > URL: https://issues.apache.org/jira/browse/HTTPCORE-536 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore NIO >Reporter: silver9886 >Priority: Major > Fix For: 5.0-beta3 > > > DefaultConnectingIOReactor and DefaultListeningIOReactor connect method are > same. > create abstractDefaultIOReactor class,put the connect code to the abstract > class. > AsyncServer and AsyncRequester connect method are same. > create abstractAsyncServerandRequester class,put the connect code to the > abstract class. -- 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-536) duplicate connect method could be extract
[ https://issues.apache.org/jira/browse/HTTPCORE-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16570097#comment-16570097 ] silver9886 commented on HTTPCORE-536: - why not say write the pr ... I thought you dont want to change the code @ok2 > duplicate connect method could be extract > - > > Key: HTTPCORE-536 > URL: https://issues.apache.org/jira/browse/HTTPCORE-536 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore NIO >Reporter: silver9886 >Priority: Major > Fix For: 5.0-beta3 > > > DefaultConnectingIOReactor and DefaultListeningIOReactor connect method are > same. > create abstractDefaultIOReactor class,put the connect code to the abstract > class. > AsyncServer and AsyncRequester connect method are same. > create abstractAsyncServerandRequester class,put the connect code to the > abstract class. -- 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] [Updated] (HTTPCORE-536) duplicate connect method could be extract
[ https://issues.apache.org/jira/browse/HTTPCORE-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] silver9886 updated HTTPCORE-536: Priority: Major (was: Minor) > duplicate connect method could be extract > - > > Key: HTTPCORE-536 > URL: https://issues.apache.org/jira/browse/HTTPCORE-536 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore NIO >Reporter: silver9886 >Priority: Major > > DefaultConnectingIOReactor and DefaultListeningIOReactor connect method are > same. > create abstractDefaultIOReactor class,put the connect code to the abstract > class. > AsyncServer and AsyncRequester connect method are same. > create abstractAsyncServerandRequester class,put the connect code to the > abstract class. -- 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] (HTTPCLIENT-1928) HttpAsyncClient callback should ignore exception throwed by compelete method
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16541323#comment-16541323
]
silver9886 commented on HTTPCLIENT-1928:
why delete AbstractMinimalHttpAsyncClientBase.java and
InternalAbstractHttpAsyncClient.java modification?
> HttpAsyncClient callback should ignore exception throwed by compelete method
>
>
> Key: HTTPCLIENT-1928
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1928
> Project: HttpComponents HttpClient
> Issue Type: Improvement
>Reporter: silver9886
>Priority: Major
> Fix For: 5.0 Beta2
>
>
> If exception throwed by completed method in FutureCallback argument in
> HttpAsyncClient.execute，the connection will be closed.
> but the exception throwed by customer code,should not affect the connection
> managed by the framework,the connection should be connected also.
> there can be a class called FutureCallbackIgnorecompelteExcepton class.
> public abstract class FutureCallbackIgnorecompelteExcepton {
> private FutureCallback t;
> void completed(T result){
>try{
>t.completed(result);
> }catch(Exception e)
> //ignore
> }
> void failed(Exception ex);
> void cancelled();
> }
> HttpAsyncClient changed as:
> HttpAsyncClient. Future execute(
> AsyncRequestProducer requestProducer,
> AsyncResponseConsumer responseConsumer,
> HttpContext context,
> FutureCallbackIgnorecompelteExcepton callback);
--
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-535) mod workerCount is power of two can be improved as &(workerCount-1)
[ https://issues.apache.org/jira/browse/HTTPCORE-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16541317#comment-16541317 ] silver9886 commented on HTTPCORE-535: - of course & is faster than %. > mod workerCount is power of two can be improved as &(workerCount-1) > > > Key: HTTPCORE-535 > URL: https://issues.apache.org/jira/browse/HTTPCORE-535 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore NIO >Reporter: silver9886 >Priority: Critical > > if workerCount is power of two . improve > final int i = Math.abs(currentWorker.incrementAndGet() % workerCount); > to be > final int i = Math.abs(currentWorker.incrementAndGet() & (workerCount-1) ); -- 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] [Created] (HTTPCORE-536) duplicate connect method could be extract
silver9886 created HTTPCORE-536: --- Summary: duplicate connect method could be extract Key: HTTPCORE-536 URL: https://issues.apache.org/jira/browse/HTTPCORE-536 Project: HttpComponents HttpCore Issue Type: Improvement Components: HttpCore NIO Reporter: silver9886 DefaultConnectingIOReactor and DefaultListeningIOReactor connect method are same. create abstractDefaultIOReactor class,put the connect code to the abstract class. AsyncServer and AsyncRequester connect method are same. create abstractAsyncServerandRequester class,put the connect code to the abstract class. -- 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] [Created] (HTTPCORE-535) mod workerCount is power of two can be improved as &(workerCount-1)
silver9886 created HTTPCORE-535: --- Summary: mod workerCount is power of two can be improved as &(workerCount-1) Key: HTTPCORE-535 URL: https://issues.apache.org/jira/browse/HTTPCORE-535 Project: HttpComponents HttpCore Issue Type: Improvement Components: HttpCore NIO Reporter: silver9886 if workerCount is power of two . improve final int i = Math.abs(currentWorker.incrementAndGet() % workerCount); to be final int i = Math.abs(currentWorker.incrementAndGet() & (workerCount-1) ); -- 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] (HTTPCLIENT-1928) HttpAsyncClient callback should ignore exception throwed by compelete method
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16538663#comment-16538663
]
silver9886 commented on HTTPCLIENT-1928:
you can log the exception in the framework ,the wrong is the complete
method,not the connection.so i think there is no bussiness of the
connection.the connection can be reused.even shut down the conenction,next time
,the connection will be created next time ,and have no difference with the
prior shut down connection.
> HttpAsyncClient callback should ignore exception throwed by compelete method
>
>
> Key: HTTPCLIENT-1928
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1928
> Project: HttpComponents HttpClient
> Issue Type: Improvement
>Reporter: silver9886
>Priority: Major
>
> If exception throwed by completed method in FutureCallback argument in
> HttpAsyncClient.execute，the connection will be closed.
> but the exception throwed by customer code,should not affect the connection
> managed by the framework,the connection should be connected also.
> there can be a class called FutureCallbackIgnorecompelteExcepton class.
> public abstract class FutureCallbackIgnorecompelteExcepton {
> private FutureCallback t;
> void completed(T result){
>try{
>t.completed(result);
> }catch(Exception e)
> //ignore
> }
> void failed(Exception ex);
> void cancelled();
> }
> HttpAsyncClient changed as:
> HttpAsyncClient. Future execute(
> AsyncRequestProducer requestProducer,
> AsyncResponseConsumer responseConsumer,
> HttpContext context,
> FutureCallbackIgnorecompelteExcepton callback);
--
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] [Created] (HTTPCORE-532) IOReactor thread should be lazy started
silver9886 created HTTPCORE-532: --- Summary: IOReactor thread should be lazy started Key: HTTPCORE-532 URL: https://issues.apache.org/jira/browse/HTTPCORE-532 Project: HttpComponents HttpCore Issue Type: Improvement Reporter: silver9886 SingleCoreIOReactor can be lazy started when it used. do not need to start all threads before any http request. resolve method is create new ioreactor thread every time there has new request util thread number limit. -- 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] [Created] (HTTPCLIENT-1928) HttpAsyncClient callback should ignore exception throwed by compelete method
silver9886 created HTTPCLIENT-1928:
--
Summary: HttpAsyncClient callback should ignore exception throwed
by compelete method
Key: HTTPCLIENT-1928
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1928
Project: HttpComponents HttpClient
Issue Type: Improvement
Reporter: silver9886
If exception throwed by completed method in FutureCallback argument in
HttpAsyncClient.execute，the connection will be closed.
but the exception throwed by customer code,should not affect the connection
managed by the framework,the connection should be connected also.
there can be a class called FutureCallbackIgnorecompelteExcepton class.
public abstract class FutureCallbackIgnorecompelteExcepton {
private FutureCallback t;
void completed(T result){
try{
t.completed(result);
}catch(Exception e)
//ignore
}
void failed(Exception ex);
void cancelled();
}
HttpAsyncClient changed as:
HttpAsyncClient. Future execute(
AsyncRequestProducer requestProducer,
AsyncResponseConsumer responseConsumer,
HttpContext context,
FutureCallbackIgnorecompelteExcepton callback);
--
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-518) Improve buffer allocation
[
https://issues.apache.org/jira/browse/HTTPCORE-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533473#comment-16533473
]
silver9886 commented on HTTPCORE-518:
-
perhaps newcapacity = ((this.buffer.capacity() + 1) * 5) >> 2;
> Improve buffer allocation
> -
>
> Key: HTTPCORE-518
> URL: https://issues.apache.org/jira/browse/HTTPCORE-518
> Project: HttpComponents HttpCore
> Issue Type: Improvement
> Components: HttpCore NIO
>Reporter: Ion Moldovan
>Priority: Minor
>
> The doubling of the buffer size every time it exceeds its previous size is a
> good way for small buffers, but quite wasteful for large sizes.
> A more modest growth (e.g. 1.25 x Previous Size) when sizes are > 32MB would
> be a nice improvement.
> Proposed solution:
> {code:java}
> /**
> * Expands buffer's capacity.
> *
> * @throws BufferOverflowException in case we get over the maximum allowed
> value
> */
> protected void expand() throws BufferOverflowException {
> int newcapacity;
> if (this.buffer.capacity() <= (32 << 20) ) {
> newcapacity = (this.buffer.capacity() + 1) << 1;
> } else {
> newcapacity = (this.buffer.capacity() + 1) * 5 / 4;
> }
> ...
> }
> {code}
> What do you think?
--
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-489) sometimes unit test will failed
[ https://issues.apache.org/jira/browse/HTTPCORE-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16156669#comment-16156669 ] silver9886 commented on HTTPCORE-489: - I find these bug when write the code to fix the HTTPCORE-484. i am a little busy about my company work. I will try my best to fix the HTTPCORE-484 soon. > sometimes unit test will failed > --- > > Key: HTTPCORE-489 > URL: https://issues.apache.org/jira/browse/HTTPCORE-489 > Project: HttpComponents HttpCore > Issue Type: Test > Components: HttpCore NIO >Affects Versions: 5.0-alpha4 > Environment: windows 7 > jdk:1.8.0_101 >Reporter: silver9886 >Priority: Trivial > Fix For: 5.0-beta1 > > Attachments: SocketException(success case).txt, > SSLHandshakeException(failed case).txt > > > org.apache.hc.core5.ssl.TestSSLContextBuilder.testSSLHanskshakeProtocolMismatch2() > sometimes will run failed occasionally. > for example, change the branch from master to the other banch,run mvn clean > test command, > change back to the master run the command,and change to the other branch ,run > command > twice change back ,run command(just run more times each branch and change to > other branch run command several times). > Doing steps above for some times, occasionally the unit test failed. > out put is like this: > Failed tests: > TestSSLContextBuilder.testSSLHanskshakeProtocolMismatch2 > Expected: an instance of java.net.SocketException > but: handshake_ > failure> is a javax.net.ssl.SSLHandshakeException > Stacktrace was: javax.net.ssl.SSLHandshakeException: Received fatal alert: > hands > hake_failure > the difference exception stack between failed and success test case are in > attachment. > I don't know if you can Recurrent this bug in your environment.And I am not > sure If it is a bug or just something wrong with my environment. > If make sure it is a bug,maybe we should except thrown IOException.class when > environment is windows and jdk.version > >= 1.8. -- 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-489) sometimes unit test will failed
[ https://issues.apache.org/jira/browse/HTTPCORE-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16156281#comment-16156281 ] silver9886 commented on HTTPCORE-489: - why don't give me a chance to raise a pr :( > sometimes unit test will failed > --- > > Key: HTTPCORE-489 > URL: https://issues.apache.org/jira/browse/HTTPCORE-489 > Project: HttpComponents HttpCore > Issue Type: Test > Components: HttpCore NIO >Affects Versions: 5.0-alpha4 > Environment: windows 7 > jdk:1.8.0_101 >Reporter: silver9886 >Priority: Trivial > Fix For: 5.0-beta1 > > Attachments: SocketException(success case).txt, > SSLHandshakeException(failed case).txt > > > org.apache.hc.core5.ssl.TestSSLContextBuilder.testSSLHanskshakeProtocolMismatch2() > sometimes will run failed occasionally. > for example, change the branch from master to the other banch,run mvn clean > test command, > change back to the master run the command,and change to the other branch ,run > command > twice change back ,run command(just run more times each branch and change to > other branch run command several times). > Doing steps above for some times, occasionally the unit test failed. > out put is like this: > Failed tests: > TestSSLContextBuilder.testSSLHanskshakeProtocolMismatch2 > Expected: an instance of java.net.SocketException > but: handshake_ > failure> is a javax.net.ssl.SSLHandshakeException > Stacktrace was: javax.net.ssl.SSLHandshakeException: Received fatal alert: > hands > hake_failure > the difference exception stack between failed and success test case are in > attachment. > I don't know if you can Recurrent this bug in your environment.And I am not > sure If it is a bug or just something wrong with my environment. > If make sure it is a bug,maybe we should except thrown IOException.class when > environment is windows and jdk.version > >= 1.8. -- 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-488) SingleCoreIOReactor.connect methods timeout parameter do not have effect.
[ https://issues.apache.org/jira/browse/HTTPCORE-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155424#comment-16155424 ] silver9886 commented on HTTPCORE-488: - you are right ! your change is execlent，I ignore the super constructor . The commit is perfect. > SingleCoreIOReactor.connect methods timeout parameter do not have effect. > - > > Key: HTTPCORE-488 > URL: https://issues.apache.org/jira/browse/HTTPCORE-488 > Project: HttpComponents HttpCore > Issue Type: Bug > Components: HttpCore NIO >Affects Versions: 5.0-alpha4 >Reporter: silver9886 >Priority: Minor > Fix For: 5.0-beta1 > > > In my opinion , timeout parameter in connect method means connectTimeout. > In InternalConnectChannel.onIOEvent ,if (readyOps & SelectionKey.OP_CONNECT) > != 0 then the socketChannel will connect to the server.However , at this time, > Perhaps It is connection time out already. > So i suggest check connecttimeout at InternalConnectChannel.onIOEvent methods > When there is SelectionKey.OP_CONNECT event happend -- 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-488) SingleCoreIOReactor.connect methods timeout parameter do not have effect.
[ https://issues.apache.org/jira/browse/HTTPCORE-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155385#comment-16155385 ] silver9886 commented on HTTPCORE-488: - I think we have to discuss about it. In the pr, SingleCoreIOReactor.java channel.setLastEventTime(System.currentTimeMillis()); is very useful. In the truck code,lastEventTime change in handleIOEvent method ,that is the time accept the SelectionKey.OP_CONNECT event.but it should be set right after socketChannel.connect(sessionRequest.remoteAddress);then the checkTimeout(now) in the InternalConnectChannel will calculate the time duration between connect and OP_CONNECT event,and chck if it is connect timeout. > SingleCoreIOReactor.connect methods timeout parameter do not have effect. > - > > Key: HTTPCORE-488 > URL: https://issues.apache.org/jira/browse/HTTPCORE-488 > Project: HttpComponents HttpCore > Issue Type: Bug > Components: HttpCore NIO >Affects Versions: 5.0-alpha4 >Reporter: silver9886 >Priority: Minor > Fix For: 5.0-beta1 > > > In my opinion , timeout parameter in connect method means connectTimeout. > In InternalConnectChannel.onIOEvent ,if (readyOps & SelectionKey.OP_CONNECT) > != 0 then the socketChannel will connect to the server.However , at this time, > Perhaps It is connection time out already. > So i suggest check connecttimeout at InternalConnectChannel.onIOEvent methods > When there is SelectionKey.OP_CONNECT event happend -- 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-489) sometimes unit test will failed
[ https://issues.apache.org/jira/browse/HTTPCORE-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155125#comment-16155125 ] silver9886 commented on HTTPCORE-489: - Is it a bug? > sometimes unit test will failed > --- > > Key: HTTPCORE-489 > URL: https://issues.apache.org/jira/browse/HTTPCORE-489 > Project: HttpComponents HttpCore > Issue Type: Test > Components: HttpCore NIO >Affects Versions: 5.0-alpha4 > Environment: windows 7 > jdk:1.8.0_101 >Reporter: silver9886 >Priority: Trivial > Fix For: 5.0-beta1 > > Attachments: SocketException(success case).txt, > SSLHandshakeException(failed case).txt > > > org.apache.hc.core5.ssl.TestSSLContextBuilder.testSSLHanskshakeProtocolMismatch2() > sometimes will run failed occasionally. > for example, change the branch from master to the other banch,run mvn clean > test command, > change back to the master run the command,and change to the other branch ,run > command > twice change back ,run command(just run more times each branch and change to > other branch run command several times). > Doing steps above for some times, occasionally the unit test failed. > out put is like this: > Failed tests: > TestSSLContextBuilder.testSSLHanskshakeProtocolMismatch2 > Expected: an instance of java.net.SocketException > but: handshake_ > failure> is a javax.net.ssl.SSLHandshakeException > Stacktrace was: javax.net.ssl.SSLHandshakeException: Received fatal alert: > hands > hake_failure > the difference exception stack between failed and success test case are in > attachment. > I don't know if you can Recurrent this bug in your environment.And I am not > sure If it is a bug or just something wrong with my environment. > If make sure it is a bug,maybe we should except thrown IOException.class when > environment is windows and jdk.version > >= 1.8. -- 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] [Created] (HTTPCORE-489) sometimes unit test will failed
silver9886 created HTTPCORE-489: --- Summary: sometimes unit test will failed Key: HTTPCORE-489 URL: https://issues.apache.org/jira/browse/HTTPCORE-489 Project: HttpComponents HttpCore Issue Type: Test Components: HttpCore NIO Affects Versions: 5.0-beta1 Environment: windows 7 jdk:1.8.0_101 Reporter: silver9886 Priority: Critical Attachments: SocketException(success case).txt, SSLHandshakeException(failed case).txt org.apache.hc.core5.ssl.TestSSLContextBuilder.testSSLHanskshakeProtocolMismatch2() sometimes will run failed occasionally. for example, change the branch from master to the other banch,run mvn clean test command, change back to the master run the command,and change to the other branch ,run command twice change back ,run command(just run more times each branch and change to other branch run command several times). Doing steps above for some times, occasionally the unit test failed. out put is like this: Failed tests: TestSSLContextBuilder.testSSLHanskshakeProtocolMismatch2 Expected: an instance of java.net.SocketException but: is a javax.net.ssl.SSLHandshakeException Stacktrace was: javax.net.ssl.SSLHandshakeException: Received fatal alert: hands hake_failure the difference exception stack between failed and success test case are in attachment. I don't know if you can Recurrent this bug in your environment.And I am not sure If it is a bug or just something wrong with my environment. If make sure it is a bug,maybe we should except thrown IOException.class when environment is windows and jdk.version >= 1.8. -- 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] [Created] (HTTPCORE-488) SingleCoreIOReactor.connect methods timeout parameter do not have effect.
silver9886 created HTTPCORE-488: --- Summary: SingleCoreIOReactor.connect methods timeout parameter do not have effect. Key: HTTPCORE-488 URL: https://issues.apache.org/jira/browse/HTTPCORE-488 Project: HttpComponents HttpCore Issue Type: Bug Components: HttpCore NIO Affects Versions: 5.0-beta1 Reporter: silver9886 Priority: Critical In my opinion , timeout parameter in connect method means connectTimeout. In InternalConnectChannel.onIOEvent ,if (readyOps & SelectionKey.OP_CONNECT) != 0 then the socketChannel will connect to the server.However , at this time, Perhaps It is connection time out already. So i suggest check connecttimeout at InternalConnectChannel.onIOEvent methods When there is SelectionKey.OP_CONNECT event happend -- 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-486) SingleCoreIOReactor.processPendingChannels and processPendingConnectionRequests should setting time limit
[
https://issues.apache.org/jira/browse/HTTPCORE-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16145427#comment-16145427
]
silver9886 commented on HTTPCORE-486:
-
please see PR:https://github.com/apache/httpcomponents-core/pull/50
> SingleCoreIOReactor.processPendingChannels and
> processPendingConnectionRequests should setting time limit
> -
>
> Key: HTTPCORE-486
> URL: https://issues.apache.org/jira/browse/HTTPCORE-486
> Project: HttpComponents HttpCore
> Issue Type: Improvement
> Components: HttpCore NIO
>Affects Versions: 5.0-alpha3
>Reporter: silver9886
>
> in processPendingChannels method
> while ((socketChannel = this.channelQueue.poll()) != null) {
> }
> do not have the time limit.If there are too many socketChannel in the
> channelQueue
> or there is channelQueue.add in the loop,the SingleCoreIOReactor time will be
> exhausted
> .That's will block the remaining work to do.
> I suggest using the following code:
> for (int i = 0 ;i < 10 && (socketChannel = this.channelQueue.poll()) !=
> null;++i) {
> }
> the processPendingConnectionRequests method is the same
--
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] [Created] (HTTPCORE-486) SingleCoreIOReactor.processPendingChannels and processPendingConnectionRequests should setting time limit
silver9886 created HTTPCORE-486:
---
Summary: SingleCoreIOReactor.processPendingChannels and
processPendingConnectionRequests should setting time limit
Key: HTTPCORE-486
URL: https://issues.apache.org/jira/browse/HTTPCORE-486
Project: HttpComponents HttpCore
Issue Type: Improvement
Components: HttpCore NIO
Affects Versions: 5.0-alpha3
Reporter: silver9886
in processPendingChannels method
while ((socketChannel = this.channelQueue.poll()) != null) {
}
do not have the time limit.If there are too many socketChannel in the
channelQueue
or there is channelQueue.add in the loop,the SingleCoreIOReactor time will be
exhausted
.That's will block the remaining work to do.
I suggest using the following code:
for (int i = 0 ;i < 10 && (socketChannel = this.channelQueue.poll()) !=
null;++i) {
}
the processPendingConnectionRequests method is the same
--
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] [Comment Edited] (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=16143028#comment-16143028 ] silver9886 edited comment on HTTPCORE-484 at 8/27/17 8:34 AM: -- please give the git url I should fork.fork from https://github.com/apache/httpcomponents-core or from https://github.com/apache/httpcomponents-core/tree/4.4.x thank you was (Author: silver9886): please give the git url I should fork.fork from https://github.com/apache/httpcomponents-core or from https://github.com/apache/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] [Comment Edited] (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=16143028#comment-16143028 ] silver9886 edited comment on HTTPCORE-484 at 8/27/17 8:27 AM: -- please give the git url I should fork.fork from https://github.com/apache/httpcomponents-core or from https://github.com/apache/httpcomponents-core thank you was (Author: silver9886): 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/apache/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] [Comment Edited] (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=16143028#comment-16143028 ] silver9886 edited comment on HTTPCORE-484 at 8/27/17 7:56 AM: -- 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/apache/httpcomponents-core thank you was (Author: silver9886): 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=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=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
[jira] [Created] (HTTPCORE-484) check timeout could use TimeWheel algorithm
silver9886 created HTTPCORE-484: --- Summary: 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: Critical 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-480) improve the code in check timeout
[ https://issues.apache.org/jira/browse/HTTPCORE-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1648#comment-1648 ] silver9886 commented on HTTPCORE-480: - thank you ,I understand how the nio select works. but the idea I said is not right either,thank you very much ! > improve the code in check timeout > - > > Key: HTTPCORE-480 > URL: https://issues.apache.org/jira/browse/HTTPCORE-480 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore NIO >Affects Versions: 4.4.6 >Reporter: silver9886 >Priority: Minor > Fix For: 4.4.7 > > Attachments: AbstractIOReactor-change.png, BaseIOReactor-add > class.png, BaseIOReactor-change.png > > > change the code in org.apache.http.impl.nio.reactor.BaseIOReactor: > if( (currentTime - this.lastTimeoutCheck) >= > this.timeoutCheckInterval) -> >if( (currentTime - this.lastTimeoutCheck) >= this.timeoutCheckInterval + 2) > because :the code will run for a time and network tranport expend the time > too. So currentTime - this.lastTimeoutCheck should be > larger than selectTimeout in order to check timeout. In this case , This will > make the code more efficiency. -- 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-480) improve the code in check timeout
[
https://issues.apache.org/jira/browse/HTTPCORE-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1608#comment-1608
]
silver9886 commented on HTTPCORE-480:
-
you are right.so i change the source code as follows:
protected void timeoutCheck(final SelectionKey key, final long now, final
MinHoldTime minHoldTime) {
final IOSessionImpl session = (IOSessionImpl) key.attachment();
if (session != null) {
final int timeout = session.getSocketTimeout();
{color:red}if (minHoldTime.get() == 0 || minHoldTime.get() >
timeout ) {
minHoldTime.set(timeout);
}{color}
if (timeout > 0) {
if (session.getLastAccessTime() + timeout < now) {
sessionTimedOut(session);
}
}
}
}
the red color is added by me. in this case,the timeoutCheckInterval can be
adjust dynamicly
> improve the code in check timeout
> -
>
> Key: HTTPCORE-480
> URL: https://issues.apache.org/jira/browse/HTTPCORE-480
> Project: HttpComponents HttpCore
> Issue Type: Improvement
> Components: HttpCore NIO
>Affects Versions: 4.4.6
>Reporter: silver9886
>Priority: Minor
> Fix For: 4.4.7
>
> Attachments: AbstractIOReactor-change.png, BaseIOReactor-add
> class.png, BaseIOReactor-change.png
>
>
> change the code in org.apache.http.impl.nio.reactor.BaseIOReactor:
> if( (currentTime - this.lastTimeoutCheck) >=
> this.timeoutCheckInterval) ->
>if( (currentTime - this.lastTimeoutCheck) >= this.timeoutCheckInterval + 2)
> because :the code will run for a time and network tranport expend the time
> too. So currentTime - this.lastTimeoutCheck should be
> larger than selectTimeout in order to check timeout. In this case , This will
> make the code more efficiency.
--
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-480) improve the code in check timeout
[ https://issues.apache.org/jira/browse/HTTPCORE-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1602#comment-1602 ] silver9886 commented on HTTPCORE-480: - set selectTimeout = timeoutCheckInterval in the code is not a good idea I think in the code . because when retrun from the readyCount = this.selector.select(this.selectTimeout) the timeout check is just one of the all operations. the other operations could be checked every selectTimeout. but the timeout check is no needed every selectTimeout. timeout check interval can be dynamicly set by the code . that is set the timeoutCheckInterval = min(all sessions timeout) > improve the code in check timeout > - > > Key: HTTPCORE-480 > URL: https://issues.apache.org/jira/browse/HTTPCORE-480 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore NIO >Affects Versions: 4.4.6 >Reporter: silver9886 >Priority: Minor > Fix For: 4.4.7 > > Attachments: AbstractIOReactor-change.png, BaseIOReactor-add > class.png, BaseIOReactor-change.png > > > change the code in org.apache.http.impl.nio.reactor.BaseIOReactor: > if( (currentTime - this.lastTimeoutCheck) >= > this.timeoutCheckInterval) -> >if( (currentTime - this.lastTimeoutCheck) >= this.timeoutCheckInterval + 2) > because :the code will run for a time and network tranport expend the time > too. So currentTime - this.lastTimeoutCheck should be > larger than selectTimeout in order to check timeout. In this case , This will > make the code more efficiency. -- 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] [Comment Edited] (HTTPCORE-480) improve the code in check timeout
[
https://issues.apache.org/jira/browse/HTTPCORE-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16111089#comment-16111089
]
silver9886 edited comment on HTTPCORE-480 at 8/2/17 3:19 PM:
-
you don't konw what i mean.
I don't want to reduce frequency of the timeout check,I just say there is no
need to check the selectedKeys if there is no needed.
no matter what the value of the timeoutCheckInterval. because the selectTimeout
= timeoutCheckInterval in the code , the code :
if (keys != null) {
for (final SelectionKey key : keys) {
timeoutCheck(key, currentTime,minholdTime);
}
}
will be executed every time the timeout check. that means the key in the keys
will be checked every time the timeout check.
for example , the session timeout set is 10 min.
but the key will be checked every 1s by default value.
but it should not be. .
if change the code as currentTime - this.lastTimeoutCheck) <
this.timeoutCheckInterval + minholdTime.get(), the minholdTime.get() will
return 10min.
then , the key in the keys will no be checked (of course , there is no need to
check).
the user can set the selectTimeout as 10min. but it is not obviously as the
user. the code should be more intelligent and modify the minholdTime.get()
dynamicly。
you know not every user can read the source code and change the selectTimeout .
was (Author: silver9886):
you don't konw what i mean.
I don't want to reduce frequency of the timeout check,I just say there is no
need to check the selectedKeys if there is no needed.
no matter what the value of the timeoutCheckInterval. because the selectTimeout
= timeoutCheckInterval in the code , the code :
if (keys != null) {
for (final SelectionKey key : keys) {
timeoutCheck(key, currentTime,minholdTime);
}
}
will be executed every time the timeout check. that means the key in the keys
will be checked every time the timeout check.
for example , the session timeout set is 10 min.
but the key will be checked every 1s by default value.
but it should not be. .
if change the code as currentTime - this.lastTimeoutCheck) <
this.timeoutCheckInterval + minholdTime.get(), the minholdTime.get() will
return 10min.
then , the key in the keys will no be checked (of course , there is no need the
check).
the user can set the selectTimeout as 10min. but it is not obviously as the
user. the code should be more intelligent and modify the minholdTime.get()
dynamicly。
you know not every user can read the source code and change the selectTimeout .
> improve the code in check timeout
> -
>
> Key: HTTPCORE-480
> URL: https://issues.apache.org/jira/browse/HTTPCORE-480
> Project: HttpComponents HttpCore
> Issue Type: Improvement
> Components: HttpCore NIO
>Affects Versions: 4.4.6
>Reporter: silver9886
>Priority: Minor
> Fix For: 4.4.7
>
> Attachments: AbstractIOReactor-change.png, BaseIOReactor-add
> class.png, BaseIOReactor-change.png
>
>
> change the code in org.apache.http.impl.nio.reactor.BaseIOReactor:
> if( (currentTime - this.lastTimeoutCheck) >=
> this.timeoutCheckInterval) ->
>if( (currentTime - this.lastTimeoutCheck) >= this.timeoutCheckInterval + 2)
> because :the code will run for a time and network tranport expend the time
> too. So currentTime - this.lastTimeoutCheck should be
> larger than selectTimeout in order to check timeout. In this case , This will
> make the code more efficiency.
--
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-480) improve the code in check timeout
[
https://issues.apache.org/jira/browse/HTTPCORE-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16111089#comment-16111089
]
silver9886 commented on HTTPCORE-480:
-
you don't konw what i mean.
I don't want to reduce frequency of the timeout check,I just say there is no
need to check the selectedKeys if there is no needed.
no matter what the value of the timeoutCheckInterval. because the selectTimeout
= timeoutCheckInterval in the code , the code :
if (keys != null) {
for (final SelectionKey key : keys) {
timeoutCheck(key, currentTime,minholdTime);
}
}
will be executed every time the timeout check. that means the key in the keys
will be checked every time the timeout check.
for example , the session timeout set is 10 min.
but the key will be checked every 1s by default value.
but it should not be. .
if change the code as currentTime - this.lastTimeoutCheck) <
this.timeoutCheckInterval + minholdTime.get(), the minholdTime.get() will
return 10min.
then , the key in the keys will no be checked (of course , there is no need the
check).
the user can set the selectTimeout as 10min. but it is not obviously as the
user. the code should be more intelligent and modify the minholdTime.get()
dynamicly。
you know not every user can read the source code and change the selectTimeout .
> improve the code in check timeout
> -
>
> Key: HTTPCORE-480
> URL: https://issues.apache.org/jira/browse/HTTPCORE-480
> Project: HttpComponents HttpCore
> Issue Type: Improvement
> Components: HttpCore NIO
>Affects Versions: 4.4.6
>Reporter: silver9886
>Priority: Minor
> Fix For: 4.4.7
>
> Attachments: AbstractIOReactor-change.png, BaseIOReactor-add
> class.png, BaseIOReactor-change.png
>
>
> change the code in org.apache.http.impl.nio.reactor.BaseIOReactor:
> if( (currentTime - this.lastTimeoutCheck) >=
> this.timeoutCheckInterval) ->
>if( (currentTime - this.lastTimeoutCheck) >= this.timeoutCheckInterval + 2)
> because :the code will run for a time and network tranport expend the time
> too. So currentTime - this.lastTimeoutCheck should be
> larger than selectTimeout in order to check timeout. In this case , This will
> make the code more efficiency.
--
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] [Reopened] (HTTPCORE-480) improve the code in check timeout
[ https://issues.apache.org/jira/browse/HTTPCORE-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] silver9886 reopened HTTPCORE-480: - so if currentTime - this.lastTimeoutCheck) < this.timeoutCheckInterval + min(sessions.sockettimeout) the code wil not iterator the keys,that is more efficiency. am i wrong? > improve the code in check timeout > - > > Key: HTTPCORE-480 > URL: https://issues.apache.org/jira/browse/HTTPCORE-480 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore NIO >Affects Versions: 4.4.6 >Reporter: silver9886 >Priority: Minor > Fix For: 4.4.7 > > Attachments: AbstractIOReactor-change.png, BaseIOReactor-add > class.png, BaseIOReactor-change.png > > > change the code in org.apache.http.impl.nio.reactor.BaseIOReactor: > if( (currentTime - this.lastTimeoutCheck) >= > this.timeoutCheckInterval) -> >if( (currentTime - this.lastTimeoutCheck) >= this.timeoutCheckInterval + 2) > because :the code will run for a time and network tranport expend the time > too. So currentTime - this.lastTimeoutCheck should be > larger than selectTimeout in order to check timeout. In this case , This will > make the code more efficiency. -- 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-480) improve the code in check timeout
[
https://issues.apache.org/jira/browse/HTTPCORE-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16110943#comment-16110943
]
silver9886 commented on HTTPCORE-480:
-
because timeoutCheckInterval = timeoutCheckInterval in the code , (currentTime
- this.lastTimeoutCheck) >= this.timeoutCheckInterval will be true.so the keys
must be iteratored every time .
but if the currentTime - this.lastTimeoutCheck < this.timeoutCheckInterval +
min(session.sockettimeout) ,there i{color:red}s no need to iterator the
keys.{color}
am i clear?
> improve the code in check timeout
> -
>
> Key: HTTPCORE-480
> URL: https://issues.apache.org/jira/browse/HTTPCORE-480
> Project: HttpComponents HttpCore
> Issue Type: Improvement
> Components: HttpCore NIO
>Affects Versions: 4.4.6
>Reporter: silver9886
>Priority: Minor
> Fix For: 4.4.7
>
> Attachments: AbstractIOReactor-change.png, BaseIOReactor-add
> class.png, BaseIOReactor-change.png
>
>
> change the code in org.apache.http.impl.nio.reactor.BaseIOReactor:
> if( (currentTime - this.lastTimeoutCheck) >=
> this.timeoutCheckInterval) ->
>if( (currentTime - this.lastTimeoutCheck) >= this.timeoutCheckInterval + 2)
> because :the code will run for a time and network tranport expend the time
> too. So currentTime - this.lastTimeoutCheck should be
> larger than selectTimeout in order to check timeout. In this case , This will
> make the code more efficiency.
--
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-480) improve the code in check timeout
[ https://issues.apache.org/jira/browse/HTTPCORE-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16110906#comment-16110906 ] silver9886 commented on HTTPCORE-480: - so if currentTime - this.lastTimeoutCheck) < this.timeoutCheckInterval + minholdTime.get() the code wil not iterator the keys,that is more efficiency. > improve the code in check timeout > - > > Key: HTTPCORE-480 > URL: https://issues.apache.org/jira/browse/HTTPCORE-480 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore NIO >Affects Versions: 4.4.6 >Reporter: silver9886 >Priority: Minor > Fix For: 4.4.7 > > Attachments: AbstractIOReactor-change.png, BaseIOReactor-add > class.png, BaseIOReactor-change.png > > > change the code in org.apache.http.impl.nio.reactor.BaseIOReactor: > if( (currentTime - this.lastTimeoutCheck) >= > this.timeoutCheckInterval) -> >if( (currentTime - this.lastTimeoutCheck) >= this.timeoutCheckInterval + 2) > because :the code will run for a time and network tranport expend the time > too. So currentTime - this.lastTimeoutCheck should be > larger than selectTimeout in order to check timeout. In this case , This will > make the code more efficiency. -- 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-480) improve the code in check timeout
[
https://issues.apache.org/jira/browse/HTTPCORE-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16110883#comment-16110883
]
silver9886 commented on HTTPCORE-480:
-
the new idea is this(i upload the diff png) :
add a protected class MinHoldTime default value is 0.
if( (currentTime - this.lastTimeoutCheck) >= this.timeoutCheckInterval +
minholdTime.get()) {
if (keys != null) {
for (final SelectionKey key : keys)
{ timeoutCheck(key, currentTime,minholdTime); }
}
}
in the timeoutCheck,we can get the min sockettimeout is all sessions and change
the minholdTime.get() return value.
protected void timeoutCheck(final SelectionKey key, final long now, final
MinHoldTime minHoldTime) {
final IOSessionImpl session = (IOSessionImpl) key.attachment();
if (session != null) {
final int timeout = session.getSocketTimeout();
if (minHoldTime.get() == 0 || minHoldTime.get() > timeout )
{ minHoldTime.set(timeout); }
if (timeout > 0) {
if (session.getLastAccessTime() + timeout < now)
{ sessionTimedOut(session); }
}
}
}
> improve the code in check timeout
> -
>
> Key: HTTPCORE-480
> URL: https://issues.apache.org/jira/browse/HTTPCORE-480
> Project: HttpComponents HttpCore
> Issue Type: Improvement
> Components: HttpCore NIO
>Affects Versions: 4.4.6
>Reporter: silver9886
>Priority: Minor
> Fix For: 4.4.7
>
> Attachments: AbstractIOReactor-change.png, BaseIOReactor-add
> class.png, BaseIOReactor-change.png
>
>
> change the code in org.apache.http.impl.nio.reactor.BaseIOReactor:
> if( (currentTime - this.lastTimeoutCheck) >=
> this.timeoutCheckInterval) ->
>if( (currentTime - this.lastTimeoutCheck) >= this.timeoutCheckInterval + 2)
> because :the code will run for a time and network tranport expend the time
> too. So currentTime - this.lastTimeoutCheck should be
> larger than selectTimeout in order to check timeout. In this case , This will
> make the code more efficiency.
--
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] [Updated] (HTTPCORE-480) improve the code in check timeout
[ https://issues.apache.org/jira/browse/HTTPCORE-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] silver9886 updated HTTPCORE-480: Attachment: AbstractIOReactor-change.png BaseIOReactor-change.png BaseIOReactor-add class.png > improve the code in check timeout > - > > Key: HTTPCORE-480 > URL: https://issues.apache.org/jira/browse/HTTPCORE-480 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore NIO >Affects Versions: 4.4.6 >Reporter: silver9886 >Priority: Minor > Fix For: 4.4.7 > > Attachments: AbstractIOReactor-change.png, BaseIOReactor-add > class.png, BaseIOReactor-change.png > > > change the code in org.apache.http.impl.nio.reactor.BaseIOReactor: > if( (currentTime - this.lastTimeoutCheck) >= > this.timeoutCheckInterval) -> >if( (currentTime - this.lastTimeoutCheck) >= this.timeoutCheckInterval + 2) > because :the code will run for a time and network tranport expend the time > too. So currentTime - this.lastTimeoutCheck should be > larger than selectTimeout in order to check timeout. In this case , This will > make the code more efficiency. -- 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] [Updated] (HTTPCORE-480) improve the code in check timeout
[ https://issues.apache.org/jira/browse/HTTPCORE-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] silver9886 updated HTTPCORE-480: Attachment: (was: BaseIOReactor.java) > improve the code in check timeout > - > > Key: HTTPCORE-480 > URL: https://issues.apache.org/jira/browse/HTTPCORE-480 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore NIO >Affects Versions: 4.4.6 >Reporter: silver9886 >Priority: Minor > Fix For: 4.4.7 > > > change the code in org.apache.http.impl.nio.reactor.BaseIOReactor: > if( (currentTime - this.lastTimeoutCheck) >= > this.timeoutCheckInterval) -> >if( (currentTime - this.lastTimeoutCheck) >= this.timeoutCheckInterval + 2) > because :the code will run for a time and network tranport expend the time > too. So currentTime - this.lastTimeoutCheck should be > larger than selectTimeout in order to check timeout. In this case , This will > make the code more efficiency. -- 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] [Updated] (HTTPCORE-480) improve the code in check timeout
[ https://issues.apache.org/jira/browse/HTTPCORE-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] silver9886 updated HTTPCORE-480: Attachment: (was: AbstractIOReactor.java) > improve the code in check timeout > - > > Key: HTTPCORE-480 > URL: https://issues.apache.org/jira/browse/HTTPCORE-480 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore NIO >Affects Versions: 4.4.6 >Reporter: silver9886 >Priority: Minor > Fix For: 4.4.7 > > > change the code in org.apache.http.impl.nio.reactor.BaseIOReactor: > if( (currentTime - this.lastTimeoutCheck) >= > this.timeoutCheckInterval) -> >if( (currentTime - this.lastTimeoutCheck) >= this.timeoutCheckInterval + 2) > because :the code will run for a time and network tranport expend the time > too. So currentTime - this.lastTimeoutCheck should be > larger than selectTimeout in order to check timeout. In this case , This will > make the code more efficiency. -- 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] [Comment Edited] (HTTPCORE-480) improve the code in check timeout
[
https://issues.apache.org/jira/browse/HTTPCORE-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16110833#comment-16110833
]
silver9886 edited comment on HTTPCORE-480 at 8/2/17 1:14 PM:
-
the new idea is this(i update the attach .java file) :
add a protected class MinHoldTime default value is 0.
if( (currentTime - this.lastTimeoutCheck) >= this.timeoutCheckInterval
+ minholdTime.get()) {
if (keys != null) {
for (final SelectionKey key : keys) {
timeoutCheck(key, currentTime,minholdTime);
}
}
}
in the timeoutCheck,we can get the min sockettimeout is all sessions and change
the minholdTime.get() return value.
protected void timeoutCheck(final SelectionKey key, final long now, final
MinHoldTime minHoldTime) {
final IOSessionImpl session = (IOSessionImpl) key.attachment();
if (session != null) {
final int timeout = session.getSocketTimeout();
if (minHoldTime.get() == 0 || minHoldTime.get() > timeout ) {
minHoldTime.set(timeout);
}
if (timeout > 0) {
if (session.getLastAccessTime() + timeout < now) {
sessionTimedOut(session);
}
}
}
}
was (Author: silver9886):
when return from readyCount = this.selector.select(this.selectTimeout); the
time has elapsed (this.selectTimeout default is 1s).
when the code execute the code if( (currentTime - this.lastTimeoutCheck) >=
this.timeoutCheckInterval) the time is elapsed larger than (this.selectTimeout
default is 1s).
beacuse the pc need the time to execute the code between readyCount =
this.selector.select(this.selectTimeout); and if( (currentTime -
this.lastTimeoutCheck) >= this.timeoutCheckInterval)
so currentTime - this.lastTimeoutCheck >= this.timeoutCheckInterval will always
return true(because timeoutCheckInterval=selectTimeout ).
I think if there is no post/get request , the currentTime -
this.lastTimeoutCheck should no be true.
suppose the time executed elapsed between
readyCount = this.selector.select(this.selectTimeout); and if( (currentTime -
this.lastTimeoutCheck) >= this.timeoutCheckInterval)
at last need 1 millisecond.
the new idea is this(i update the attach .java file) :
add a protected class MinHoldTime default value is 1 (means at last 1
millisecond).
if( (currentTime - this.lastTimeoutCheck) >= this.timeoutCheckInterval
+ minholdTime.get()) {
if (keys != null) {
for (final SelectionKey key : keys) {
timeoutCheck(key, currentTime,minholdTime);
}
}
}
in the timeoutCheck,we can get the min sockettimeout is all sessions and change
the minholdTime.get() return value.
protected void timeoutCheck(final SelectionKey key, final long now, final
MinHoldTime minHoldTime) {
final IOSessionImpl session = (IOSessionImpl) key.attachment();
if (session != null) {
final int timeout = session.getSocketTimeout();
if (minHoldTime.get() == 1 || minHoldTime.get() > timeout ) {
minHoldTime.set(timeout);
}
if (timeout > 0) {
if (session.getLastAccessTime() + timeout < now) {
sessionTimedOut(session);
}
}
}
}
> improve the code in check timeout
> -
>
> Key: HTTPCORE-480
> URL: https://issues.apache.org/jira/browse/HTTPCORE-480
> Project: HttpComponents HttpCore
> Issue Type: Improvement
> Components: HttpCore NIO
>Affects Versions: 4.4.6
>Reporter: silver9886
>Priority: Minor
> Fix For: 4.4.7
>
> Attachments: AbstractIOReactor.java, BaseIOReactor.java
>
>
> change the code in org.apache.http.impl.nio.reactor.BaseIOReactor:
> if( (currentTime - this.lastTimeoutCheck) >=
> this.timeoutCheckInterval) ->
>if( (currentTime - this.lastTimeoutCheck) >= this.timeoutCheckInterval + 2)
> because :the code will run for a time and network tranport expend the time
> too. So currentTime - this.lastTimeoutCheck should be
> larger than selectTimeout in order to check timeout. In this case , This will
> make the code more efficiency.
--
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] [Updated] (HTTPCORE-480) improve the code in check timeout
[ https://issues.apache.org/jira/browse/HTTPCORE-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] silver9886 updated HTTPCORE-480: Priority: Major (was: Trivial) > improve the code in check timeout > - > > Key: HTTPCORE-480 > URL: https://issues.apache.org/jira/browse/HTTPCORE-480 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore NIO >Affects Versions: 4.4.6 >Reporter: silver9886 > Fix For: 4.4.7 > > Attachments: AbstractIOReactor.java, BaseIOReactor.java > > > change the code in org.apache.http.impl.nio.reactor.BaseIOReactor: > if( (currentTime - this.lastTimeoutCheck) >= > this.timeoutCheckInterval) -> >if( (currentTime - this.lastTimeoutCheck) >= this.timeoutCheckInterval + 2) > because :the code will run for a time and network tranport expend the time > too. So currentTime - this.lastTimeoutCheck should be > larger than selectTimeout in order to check timeout. In this case , This will > make the code more efficiency. -- 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-480) improve the code in check timeout
[
https://issues.apache.org/jira/browse/HTTPCORE-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16110833#comment-16110833
]
silver9886 commented on HTTPCORE-480:
-
when return from readyCount = this.selector.select(this.selectTimeout); the
time has elapsed (this.selectTimeout default is 1s).
when the code execute the code if( (currentTime - this.lastTimeoutCheck) >=
this.timeoutCheckInterval) the time is elapsed larger than (this.selectTimeout
default is 1s).
beacuse the pc need the time to execute the code between readyCount =
this.selector.select(this.selectTimeout); and if( (currentTime -
this.lastTimeoutCheck) >= this.timeoutCheckInterval)
so currentTime - this.lastTimeoutCheck >= this.timeoutCheckInterval will always
return true(because timeoutCheckInterval=selectTimeout ).
I think if there is no post/get request , the currentTime -
this.lastTimeoutCheck should no be true.
suppose the time executed elapsed between
readyCount = this.selector.select(this.selectTimeout); and if( (currentTime -
this.lastTimeoutCheck) >= this.timeoutCheckInterval)
at last need 1 millisecond.
the new idea is this(i update the attach .java file) :
add a protected class MinHoldTime default value is 1 (means at last 1
millisecond).
if( (currentTime - this.lastTimeoutCheck) >= this.timeoutCheckInterval
+ minholdTime.get()) {
if (keys != null) {
for (final SelectionKey key : keys) {
timeoutCheck(key, currentTime,minholdTime);
}
}
}
in the timeoutCheck,we can get the min sockettimeout is all sessions and change
the minholdTime.get() return value.
protected void timeoutCheck(final SelectionKey key, final long now, final
MinHoldTime minHoldTime) {
final IOSessionImpl session = (IOSessionImpl) key.attachment();
if (session != null) {
final int timeout = session.getSocketTimeout();
if (minHoldTime.get() == 1 || minHoldTime.get() > timeout ) {
minHoldTime.set(timeout);
}
if (timeout > 0) {
if (session.getLastAccessTime() + timeout < now) {
sessionTimedOut(session);
}
}
}
}
> improve the code in check timeout
> -
>
> Key: HTTPCORE-480
> URL: https://issues.apache.org/jira/browse/HTTPCORE-480
> Project: HttpComponents HttpCore
> Issue Type: Improvement
> Components: HttpCore NIO
>Affects Versions: 4.4.6
>Reporter: silver9886
>Priority: Trivial
> Fix For: 4.4.7
>
> Attachments: AbstractIOReactor.java, BaseIOReactor.java
>
>
> change the code in org.apache.http.impl.nio.reactor.BaseIOReactor:
> if( (currentTime - this.lastTimeoutCheck) >=
> this.timeoutCheckInterval) ->
>if( (currentTime - this.lastTimeoutCheck) >= this.timeoutCheckInterval + 2)
> because :the code will run for a time and network tranport expend the time
> too. So currentTime - this.lastTimeoutCheck should be
> larger than selectTimeout in order to check timeout. In this case , This will
> make the code more efficiency.
--
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] [Updated] (HTTPCORE-480) improve the code in check timeout
[ https://issues.apache.org/jira/browse/HTTPCORE-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] silver9886 updated HTTPCORE-480: Attachment: AbstractIOReactor.java BaseIOReactor.java > improve the code in check timeout > - > > Key: HTTPCORE-480 > URL: https://issues.apache.org/jira/browse/HTTPCORE-480 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore NIO >Affects Versions: 4.4.6 >Reporter: silver9886 >Priority: Trivial > Fix For: 4.4.7 > > Attachments: AbstractIOReactor.java, BaseIOReactor.java > > > change the code in org.apache.http.impl.nio.reactor.BaseIOReactor: > if( (currentTime - this.lastTimeoutCheck) >= > this.timeoutCheckInterval) -> >if( (currentTime - this.lastTimeoutCheck) >= this.timeoutCheckInterval + 2) > because :the code will run for a time and network tranport expend the time > too. So currentTime - this.lastTimeoutCheck should be > larger than selectTimeout in order to check timeout. In this case , This will > make the code more efficiency. -- 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] [Updated] (HTTPCORE-480) improve the code in check timeout
[ https://issues.apache.org/jira/browse/HTTPCORE-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] silver9886 updated HTTPCORE-480: Attachment: (was: BaseIOReactor.java) > improve the code in check timeout > - > > Key: HTTPCORE-480 > URL: https://issues.apache.org/jira/browse/HTTPCORE-480 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore NIO >Affects Versions: 4.4.6 >Reporter: silver9886 >Priority: Trivial > Fix For: 4.4.7 > > > change the code in org.apache.http.impl.nio.reactor.BaseIOReactor: > if( (currentTime - this.lastTimeoutCheck) >= > this.timeoutCheckInterval) -> >if( (currentTime - this.lastTimeoutCheck) >= this.timeoutCheckInterval + 2) > because :the code will run for a time and network tranport expend the time > too. So currentTime - this.lastTimeoutCheck should be > larger than selectTimeout in order to check timeout. In this case , This will > make the code more efficiency. -- 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] [Created] (HTTPCORE-480) improve the code in check timeout
silver9886 created HTTPCORE-480: --- Summary: improve the code in check timeout Key: HTTPCORE-480 URL: https://issues.apache.org/jira/browse/HTTPCORE-480 Project: HttpComponents HttpCore Issue Type: Improvement Components: HttpCore NIO Affects Versions: 4.4.6 Reporter: silver9886 Priority: Critical Fix For: 4.4.7 Attachments: BaseIOReactor.java change the code in org.apache.http.impl.nio.reactor.BaseIOReactor: if( (currentTime - this.lastTimeoutCheck) >= this.timeoutCheckInterval) -> if( (currentTime - this.lastTimeoutCheck) >= this.timeoutCheckInterval + 2) because :the code will run for a time and network tranport expend the time too. So currentTime - this.lastTimeoutCheck should be larger than selectTimeout in order to check timeout. In this case , This will make the code more efficiency. -- 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
