Re: connect timeout
Could someone take a look at this (DIRMINA-527) and address it? Thanks! Regards, Sangjin On Feb 12, 2008 9:21 PM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote: We could let the connector automatically adjust the select timeout value if the current select timeout is greater than the specified connect timeout. 2008-02-12 (화), 21:16 -0800, Sangjin Lee 쓰시길: Yes, it would be great if users can configure the select timeout. One small issue that I have, however, is if the select timeout is longer than the connect timeout. Then it is possible that the connect timeout will not always be honored because select will not wake up until select timeout pops. It is understood that it would happen only if there are no other connect events happening, but a select timeout that is longer than the connect timeout will effectively interfere with the proper connect timeout. How shall we address that situation? Thanks, Sangjin On Feb 12, 2008 8:43 PM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote: Thanks Sanjin for the patch. It looks pretty good. One tiny thing I'd like to point out is that it would be much nicer if a user can configure the selector timeout parameter. For example, we could leave the default '1000', and let people reconfigure that by calling the following statement: connector.setMaxConnectTimeoutCheckInterval(50); // ms I'm not sure if this property name is good, but it's my idea that we need to make it configurable rather than hard-coding it. In the same context, we could make the idle time check interval also configurable. WDYT? 2008-02-06 (수), 10:09 -0800, Sangjin Lee 쓰시길: I have filed a JIRA issue ( https://issues.apache.org/jira/browse/DIRMINA-527), and submitted a patch for this. In the patch I added IoConnector.setConnectTimeoutMillis(), and deprecated getConnectTimeout()/setConnectTimeout() in favor of the new ones. Perhaps one could go as far as removing them? I wasn't sure... Also, the select timeout is now tied to the connect timeout, but still is no longer than 1 second. I also imposed a somewhat arbitrary minimum legal connect timeout value of 50 ms, but again we could discuss what the right value should be if we need one. What do you think? Thanks, Sangjin On Feb 5, 2008 7:46 AM, Sangjin Lee [EMAIL PROTECTED] wrote: Right, that's why I said the connect timeout limitation seems tied to the select timeout... Hard-coded 1 second select timeout will interfere with sub-second connect timeout value. One obvious suggestion is to set the select timeout to be the same as the connect timeout. That way, we're pretty sure that the connect timeout will be honored. One small drawback is that we'd end up with a busy select loop if the connect timeout is too small. This could be prevented by having a minimum connect/select timeout value... Also, note that the 1-second timeout is pervasive elsewhere (like processor, etc.). Not sure if we need to change them also. Maybe not right now... If you guys don't mind, I'll file a bug (both for 1.1.x and 2.x) and submit a patch also... How's that sound? BTW, what is up with the 1 second sleep in the try-catch clause in the same code area? We can leave it as is? } catch (Throwable e) { ExceptionMonitor.getInstance ().exceptionCaught(e); try { Thread.sleep(1000); } catch (InterruptedException e1) { ExceptionMonitor.getInstance ().exceptionCaught(e1); } } Thanks, Sangjin On Feb 5, 2008 7:29 AM, Julien Vermillard [EMAIL PROTECTED] wrote: On Tue, 05 Feb 2008 13:55:15 +0100 Niklas Therning [EMAIL PROTECTED] wrote: You would also need to make sure that the current IoConnector implementations can support millisecond timeouts. I think that would mean that AbstractPollingIoConnector.Worker needs to be changed. Specifically the line boolean selected = select(1000); To support milliseconds we could simply change this into boolean selected = select(1); but that would be very bad for performance. Instead, one could use an adaptive timeout in the call to select() which depends on the current ConnectRequests' timeouts. Or totally redesign things to use a ScheduledExecutorService or similar instead. Yes Niklas is right, I forgot the impact on worker loop. At first look an adaptive select timeout or a redesign using
Re: connect timeout
We could let the connector automatically adjust the select timeout value if the current select timeout is greater than the specified connect timeout. 2008-02-12 (화), 21:16 -0800, Sangjin Lee 쓰시길: Yes, it would be great if users can configure the select timeout. One small issue that I have, however, is if the select timeout is longer than the connect timeout. Then it is possible that the connect timeout will not always be honored because select will not wake up until select timeout pops. It is understood that it would happen only if there are no other connect events happening, but a select timeout that is longer than the connect timeout will effectively interfere with the proper connect timeout. How shall we address that situation? Thanks, Sangjin On Feb 12, 2008 8:43 PM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote: Thanks Sanjin for the patch. It looks pretty good. One tiny thing I'd like to point out is that it would be much nicer if a user can configure the selector timeout parameter. For example, we could leave the default '1000', and let people reconfigure that by calling the following statement: connector.setMaxConnectTimeoutCheckInterval(50); // ms I'm not sure if this property name is good, but it's my idea that we need to make it configurable rather than hard-coding it. In the same context, we could make the idle time check interval also configurable. WDYT? 2008-02-06 (수), 10:09 -0800, Sangjin Lee 쓰시길: I have filed a JIRA issue ( https://issues.apache.org/jira/browse/DIRMINA-527), and submitted a patch for this. In the patch I added IoConnector.setConnectTimeoutMillis(), and deprecated getConnectTimeout()/setConnectTimeout() in favor of the new ones. Perhaps one could go as far as removing them? I wasn't sure... Also, the select timeout is now tied to the connect timeout, but still is no longer than 1 second. I also imposed a somewhat arbitrary minimum legal connect timeout value of 50 ms, but again we could discuss what the right value should be if we need one. What do you think? Thanks, Sangjin On Feb 5, 2008 7:46 AM, Sangjin Lee [EMAIL PROTECTED] wrote: Right, that's why I said the connect timeout limitation seems tied to the select timeout... Hard-coded 1 second select timeout will interfere with sub-second connect timeout value. One obvious suggestion is to set the select timeout to be the same as the connect timeout. That way, we're pretty sure that the connect timeout will be honored. One small drawback is that we'd end up with a busy select loop if the connect timeout is too small. This could be prevented by having a minimum connect/select timeout value... Also, note that the 1-second timeout is pervasive elsewhere (like processor, etc.). Not sure if we need to change them also. Maybe not right now... If you guys don't mind, I'll file a bug (both for 1.1.x and 2.x) and submit a patch also... How's that sound? BTW, what is up with the 1 second sleep in the try-catch clause in the same code area? We can leave it as is? } catch (Throwable e) { ExceptionMonitor.getInstance().exceptionCaught(e); try { Thread.sleep(1000); } catch (InterruptedException e1) { ExceptionMonitor.getInstance ().exceptionCaught(e1); } } Thanks, Sangjin On Feb 5, 2008 7:29 AM, Julien Vermillard [EMAIL PROTECTED] wrote: On Tue, 05 Feb 2008 13:55:15 +0100 Niklas Therning [EMAIL PROTECTED] wrote: You would also need to make sure that the current IoConnector implementations can support millisecond timeouts. I think that would mean that AbstractPollingIoConnector.Worker needs to be changed. Specifically the line boolean selected = select(1000); To support milliseconds we could simply change this into boolean selected = select(1); but that would be very bad for performance. Instead, one could use an adaptive timeout in the call to select() which depends on the current ConnectRequests' timeouts. Or totally redesign things to use a ScheduledExecutorService or similar instead. Yes Niklas is right, I forgot the impact on worker loop. At first look an adaptive select timeout or a redesign using some kind of ExecutorService doesn't look like a trivial move.. Whats the lowest connect timeout needed if it's under 1 seconds ? Julien -- what we call human nature is actually human habit -- http://gleamynode.net/ -- what we call human nature is actually human
Re: connect timeout
Thanks Sanjin for the patch. It looks pretty good. One tiny thing I'd like to point out is that it would be much nicer if a user can configure the selector timeout parameter. For example, we could leave the default '1000', and let people reconfigure that by calling the following statement: connector.setMaxConnectTimeoutCheckInterval(50); // ms I'm not sure if this property name is good, but it's my idea that we need to make it configurable rather than hard-coding it. In the same context, we could make the idle time check interval also configurable. WDYT? 2008-02-06 (수), 10:09 -0800, Sangjin Lee 쓰시길: I have filed a JIRA issue (https://issues.apache.org/jira/browse/DIRMINA-527), and submitted a patch for this. In the patch I added IoConnector.setConnectTimeoutMillis(), and deprecated getConnectTimeout()/setConnectTimeout() in favor of the new ones. Perhaps one could go as far as removing them? I wasn't sure... Also, the select timeout is now tied to the connect timeout, but still is no longer than 1 second. I also imposed a somewhat arbitrary minimum legal connect timeout value of 50 ms, but again we could discuss what the right value should be if we need one. What do you think? Thanks, Sangjin On Feb 5, 2008 7:46 AM, Sangjin Lee [EMAIL PROTECTED] wrote: Right, that's why I said the connect timeout limitation seems tied to the select timeout... Hard-coded 1 second select timeout will interfere with sub-second connect timeout value. One obvious suggestion is to set the select timeout to be the same as the connect timeout. That way, we're pretty sure that the connect timeout will be honored. One small drawback is that we'd end up with a busy select loop if the connect timeout is too small. This could be prevented by having a minimum connect/select timeout value... Also, note that the 1-second timeout is pervasive elsewhere (like processor, etc.). Not sure if we need to change them also. Maybe not right now... If you guys don't mind, I'll file a bug (both for 1.1.x and 2.x) and submit a patch also... How's that sound? BTW, what is up with the 1 second sleep in the try-catch clause in the same code area? We can leave it as is? } catch (Throwable e) { ExceptionMonitor.getInstance().exceptionCaught(e); try { Thread.sleep(1000); } catch (InterruptedException e1) { ExceptionMonitor.getInstance ().exceptionCaught(e1); } } Thanks, Sangjin On Feb 5, 2008 7:29 AM, Julien Vermillard [EMAIL PROTECTED] wrote: On Tue, 05 Feb 2008 13:55:15 +0100 Niklas Therning [EMAIL PROTECTED] wrote: You would also need to make sure that the current IoConnector implementations can support millisecond timeouts. I think that would mean that AbstractPollingIoConnector.Worker needs to be changed. Specifically the line boolean selected = select(1000); To support milliseconds we could simply change this into boolean selected = select(1); but that would be very bad for performance. Instead, one could use an adaptive timeout in the call to select() which depends on the current ConnectRequests' timeouts. Or totally redesign things to use a ScheduledExecutorService or similar instead. Yes Niklas is right, I forgot the impact on worker loop. At first look an adaptive select timeout or a redesign using some kind of ExecutorService doesn't look like a trivial move.. Whats the lowest connect timeout needed if it's under 1 seconds ? Julien -- what we call human nature is actually human habit -- http://gleamynode.net/ signature.asc Description: This is a digitally signed message part
Re: connect timeout
Sounds good. :) Thanks, Sangjin On Feb 12, 2008 9:21 PM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote: We could let the connector automatically adjust the select timeout value if the current select timeout is greater than the specified connect timeout. 2008-02-12 (화), 21:16 -0800, Sangjin Lee 쓰시길: Yes, it would be great if users can configure the select timeout. One small issue that I have, however, is if the select timeout is longer than the connect timeout. Then it is possible that the connect timeout will not always be honored because select will not wake up until select timeout pops. It is understood that it would happen only if there are no other connect events happening, but a select timeout that is longer than the connect timeout will effectively interfere with the proper connect timeout. How shall we address that situation? Thanks, Sangjin On Feb 12, 2008 8:43 PM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote: Thanks Sanjin for the patch. It looks pretty good. One tiny thing I'd like to point out is that it would be much nicer if a user can configure the selector timeout parameter. For example, we could leave the default '1000', and let people reconfigure that by calling the following statement: connector.setMaxConnectTimeoutCheckInterval(50); // ms I'm not sure if this property name is good, but it's my idea that we need to make it configurable rather than hard-coding it. In the same context, we could make the idle time check interval also configurable. WDYT? 2008-02-06 (수), 10:09 -0800, Sangjin Lee 쓰시길: I have filed a JIRA issue ( https://issues.apache.org/jira/browse/DIRMINA-527), and submitted a patch for this. In the patch I added IoConnector.setConnectTimeoutMillis(), and deprecated getConnectTimeout()/setConnectTimeout() in favor of the new ones. Perhaps one could go as far as removing them? I wasn't sure... Also, the select timeout is now tied to the connect timeout, but still is no longer than 1 second. I also imposed a somewhat arbitrary minimum legal connect timeout value of 50 ms, but again we could discuss what the right value should be if we need one. What do you think? Thanks, Sangjin On Feb 5, 2008 7:46 AM, Sangjin Lee [EMAIL PROTECTED] wrote: Right, that's why I said the connect timeout limitation seems tied to the select timeout... Hard-coded 1 second select timeout will interfere with sub-second connect timeout value. One obvious suggestion is to set the select timeout to be the same as the connect timeout. That way, we're pretty sure that the connect timeout will be honored. One small drawback is that we'd end up with a busy select loop if the connect timeout is too small. This could be prevented by having a minimum connect/select timeout value... Also, note that the 1-second timeout is pervasive elsewhere (like processor, etc.). Not sure if we need to change them also. Maybe not right now... If you guys don't mind, I'll file a bug (both for 1.1.x and 2.x) and submit a patch also... How's that sound? BTW, what is up with the 1 second sleep in the try-catch clause in the same code area? We can leave it as is? } catch (Throwable e) { ExceptionMonitor.getInstance ().exceptionCaught(e); try { Thread.sleep(1000); } catch (InterruptedException e1) { ExceptionMonitor.getInstance ().exceptionCaught(e1); } } Thanks, Sangjin On Feb 5, 2008 7:29 AM, Julien Vermillard [EMAIL PROTECTED] wrote: On Tue, 05 Feb 2008 13:55:15 +0100 Niklas Therning [EMAIL PROTECTED] wrote: You would also need to make sure that the current IoConnector implementations can support millisecond timeouts. I think that would mean that AbstractPollingIoConnector.Worker needs to be changed. Specifically the line boolean selected = select(1000); To support milliseconds we could simply change this into boolean selected = select(1); but that would be very bad for performance. Instead, one could use an adaptive timeout in the call to select() which depends on the current ConnectRequests' timeouts. Or totally redesign things to use a ScheduledExecutorService or similar instead. Yes Niklas is right, I forgot the impact on worker loop. At first look an adaptive select timeout or a redesign using some kind of ExecutorService doesn't look like
Re: connect timeout
I can see cases where one might need a very short connect timeout. If your use case requires a very low fault tolerance and if you would rather fail calls than waiting for any longer than is necessary, then 1 second might not be an adequate minimum value. The characteristic would be a high-load situation where low latency (i.e. high bandwidth) is normally expected and required. For example, if one set of services is making calls to another set of services within a single network (i.e. intranet) in high volumes, then the expectation on the latency is usually very low. Normally calls should succeed within a very short amount of time. Suppose the remote services start having problems and suddenly connects and reads are taking longer. Having a short connect timeout and a short read timeout is a good way to *contain* that risk. If connect timeout can only be 1 second or longer, then there would be many situations where the problems from that remote service will quickly spread over to any calling services and have a cascading effect... Thanks, Sangjin On Feb 9, 2008 12:39 AM, Alan D. Cabrera [EMAIL PROTECTED] wrote: On Feb 4, 2008, at 5:29 PM, Sangjin Lee wrote: I had a quick question on the connect timeout... The connect timeout supplied to connectors is in the unit of seconds, and it appears the minimum value you can use is 1 second ( AbstractIoConnector.setConnectTimeout() in the case of the trunk). Is this by design? I can see cases where one needs to have a shorter connect timeout, but it seems it is not possible today. One solution might be to use ConnectFuture.join() with a timeout, but that works only if you want to block until it times out... It also seems that this minimum timeout value is somewhat tied to the timeout value used in the select() loop in the connector, which is hard coded to be 1 second. Would it be a good idea to support connect timeout values in milliseconds, and make it shorter than 1 second? It doesn't matter to me but I'm just curious. Why would one want a timeout less than a second? Regards, Alan
Re: connect timeout
+1 This was well put Sangjin. After reading this I realized that may deployments of AHC will have similar needs: sub-second timeouts are critical. Alex On Feb 10, 2008 7:10 PM, Sangjin Lee [EMAIL PROTECTED] wrote: I can see cases where one might need a very short connect timeout. If your use case requires a very low fault tolerance and if you would rather fail calls than waiting for any longer than is necessary, then 1 second might not be an adequate minimum value. The characteristic would be a high-load situation where low latency (i.e. high bandwidth) is normally expected and required. For example, if one set of services is making calls to another set of services within a single network (i.e. intranet) in high volumes, then the expectation on the latency is usually very low. Normally calls should succeed within a very short amount of time. Suppose the remote services start having problems and suddenly connects and reads are taking longer. Having a short connect timeout and a short read timeout is a good way to *contain* that risk. If connect timeout can only be 1 second or longer, then there would be many situations where the problems from that remote service will quickly spread over to any calling services and have a cascading effect... Thanks, Sangjin On Feb 9, 2008 12:39 AM, Alan D. Cabrera [EMAIL PROTECTED] wrote: On Feb 4, 2008, at 5:29 PM, Sangjin Lee wrote: I had a quick question on the connect timeout... The connect timeout supplied to connectors is in the unit of seconds, and it appears the minimum value you can use is 1 second ( AbstractIoConnector.setConnectTimeout() in the case of the trunk). Is this by design? I can see cases where one needs to have a shorter connect timeout, but it seems it is not possible today. One solution might be to use ConnectFuture.join() with a timeout, but that works only if you want to block until it times out... It also seems that this minimum timeout value is somewhat tied to the timeout value used in the select() loop in the connector, which is hard coded to be 1 second. Would it be a good idea to support connect timeout values in milliseconds, and make it shorter than 1 second? It doesn't matter to me but I'm just curious. Why would one want a timeout less than a second? Regards, Alan
Re: connect timeout
I would have to give Sangjin's arguments a +0. I think he makes some good points but I don't think I would say that support sub-second timeouts is _critical_ until people start asking for it. Load balancing is a case where connect timeouts would be important and all of the load balancers I've configured (both hardware and software loadbalancers) default to a connect timeout of 1 second. -Mike Alex Karasulu wrote: +1 This was well put Sangjin. After reading this I realized that may deployments of AHC will have similar needs: sub-second timeouts are critical. Alex On Feb 10, 2008 7:10 PM, Sangjin Lee [EMAIL PROTECTED] wrote: I can see cases where one might need a very short connect timeout. If your use case requires a very low fault tolerance and if you would rather fail calls than waiting for any longer than is necessary, then 1 second might not be an adequate minimum value. The characteristic would be a high-load situation where low latency (i.e. high bandwidth) is normally expected and required. For example, if one set of services is making calls to another set of services within a single network (i.e. intranet) in high volumes, then the expectation on the latency is usually very low. Normally calls should succeed within a very short amount of time. Suppose the remote services start having problems and suddenly connects and reads are taking longer. Having a short connect timeout and a short read timeout is a good way to *contain* that risk. If connect timeout can only be 1 second or longer, then there would be many situations where the problems from that remote service will quickly spread over to any calling services and have a cascading effect... Thanks, Sangjin On Feb 9, 2008 12:39 AM, Alan D. Cabrera [EMAIL PROTECTED] wrote: On Feb 4, 2008, at 5:29 PM, Sangjin Lee wrote: I had a quick question on the connect timeout... The connect timeout supplied to connectors is in the unit of seconds, and it appears the minimum value you can use is 1 second ( AbstractIoConnector.setConnectTimeout() in the case of the trunk). Is this by design? I can see cases where one needs to have a shorter connect timeout, but it seems it is not possible today. One solution might be to use ConnectFuture.join() with a timeout, but that works only if you want to block until it times out... It also seems that this minimum timeout value is somewhat tied to the timeout value used in the select() loop in the connector, which is hard coded to be 1 second. Would it be a good idea to support connect timeout values in milliseconds, and make it shorter than 1 second? It doesn't matter to me but I'm just curious. Why would one want a timeout less than a second? Regards, Alan
Re: connect timeout
On Feb 4, 2008, at 5:29 PM, Sangjin Lee wrote: I had a quick question on the connect timeout... The connect timeout supplied to connectors is in the unit of seconds, and it appears the minimum value you can use is 1 second ( AbstractIoConnector.setConnectTimeout() in the case of the trunk). Is this by design? I can see cases where one needs to have a shorter connect timeout, but it seems it is not possible today. One solution might be to use ConnectFuture.join() with a timeout, but that works only if you want to block until it times out... It also seems that this minimum timeout value is somewhat tied to the timeout value used in the select() loop in the connector, which is hard coded to be 1 second. Would it be a good idea to support connect timeout values in milliseconds, and make it shorter than 1 second? It doesn't matter to me but I'm just curious. Why would one want a timeout less than a second? Regards, Alan
Re: connect timeout
I have filed a JIRA issue (https://issues.apache.org/jira/browse/DIRMINA-527), and submitted a patch for this. In the patch I added IoConnector.setConnectTimeoutMillis(), and deprecated getConnectTimeout()/setConnectTimeout() in favor of the new ones. Perhaps one could go as far as removing them? I wasn't sure... Also, the select timeout is now tied to the connect timeout, but still is no longer than 1 second. I also imposed a somewhat arbitrary minimum legal connect timeout value of 50 ms, but again we could discuss what the right value should be if we need one. What do you think? Thanks, Sangjin On Feb 5, 2008 7:46 AM, Sangjin Lee [EMAIL PROTECTED] wrote: Right, that's why I said the connect timeout limitation seems tied to the select timeout... Hard-coded 1 second select timeout will interfere with sub-second connect timeout value. One obvious suggestion is to set the select timeout to be the same as the connect timeout. That way, we're pretty sure that the connect timeout will be honored. One small drawback is that we'd end up with a busy select loop if the connect timeout is too small. This could be prevented by having a minimum connect/select timeout value... Also, note that the 1-second timeout is pervasive elsewhere (like processor, etc.). Not sure if we need to change them also. Maybe not right now... If you guys don't mind, I'll file a bug (both for 1.1.x and 2.x) and submit a patch also... How's that sound? BTW, what is up with the 1 second sleep in the try-catch clause in the same code area? We can leave it as is? } catch (Throwable e) { ExceptionMonitor.getInstance().exceptionCaught(e); try { Thread.sleep(1000); } catch (InterruptedException e1) { ExceptionMonitor.getInstance ().exceptionCaught(e1); } } Thanks, Sangjin On Feb 5, 2008 7:29 AM, Julien Vermillard [EMAIL PROTECTED] wrote: On Tue, 05 Feb 2008 13:55:15 +0100 Niklas Therning [EMAIL PROTECTED] wrote: You would also need to make sure that the current IoConnector implementations can support millisecond timeouts. I think that would mean that AbstractPollingIoConnector.Worker needs to be changed. Specifically the line boolean selected = select(1000); To support milliseconds we could simply change this into boolean selected = select(1); but that would be very bad for performance. Instead, one could use an adaptive timeout in the call to select() which depends on the current ConnectRequests' timeouts. Or totally redesign things to use a ScheduledExecutorService or similar instead. Yes Niklas is right, I forgot the impact on worker loop. At first look an adaptive select timeout or a redesign using some kind of ExecutorService doesn't look like a trivial move.. Whats the lowest connect timeout needed if it's under 1 seconds ? Julien
Re: connect timeout
On Mon, 04 Feb 2008 18:52:37 -0700 Jeff Genender [EMAIL PROTECTED] wrote: great question..Im interested in this as well. Jeff Sangjin Lee wrote: I had a quick question on the connect timeout... The connect timeout supplied to connectors is in the unit of seconds, and it appears the minimum value you can use is 1 second ( AbstractIoConnector.setConnectTimeout() in the case of the trunk). Is this by design? I can see cases where one needs to have a shorter connect timeout, but it seems it is not possible today. One solution might be to use ConnectFuture.join() with a timeout, but that works only if you want to block until it times out... It also seems that this minimum timeout value is somewhat tied to the timeout value used in the select() loop in the connector, which is hard coded to be 1 second. Would it be a good idea to support connect timeout values in milliseconds, and make it shorter than 1 second? Thanks, Sangjin Hi, Apparently it's doable, the timeout value is multiplicated by 1000 before being placed in the ConnectionRequest deadline. As far I understand it, it's not a big deal but an API change. Julien
Re: connect timeout
On Feb 5, 2008 9:17 AM, Julien Vermillard [EMAIL PROTECTED] wrote: On Mon, 04 Feb 2008 18:52:37 -0700 Jeff Genender [EMAIL PROTECTED] wrote: great question..Im interested in this as well. Jeff Sangjin Lee wrote: I had a quick question on the connect timeout... The connect timeout supplied to connectors is in the unit of seconds, and it appears the minimum value you can use is 1 second ( AbstractIoConnector.setConnectTimeout() in the case of the trunk). Is this by design? I can see cases where one needs to have a shorter connect timeout, but it seems it is not possible today. One solution might be to use ConnectFuture.join() with a timeout, but that works only if you want to block until it times out... It also seems that this minimum timeout value is somewhat tied to the timeout value used in the select() loop in the connector, which is hard coded to be 1 second. Would it be a good idea to support connect timeout values in milliseconds, and make it shorter than 1 second? Thanks, Sangjin Hi, Apparently it's doable, the timeout value is multiplicated by 1000 before being placed in the ConnectionRequest deadline. As far I understand it, it's not a big deal but an API change. +1 for sub-second timeout values And I think it's best to change the API now, before cutting 2.0-M1 How about adding a java.util.concurrent.TimeUnit parameter to setConnectTimeout() ? Maarten Julien
Re: connect timeout
+1 - not enough granularity with seconds. Alex On Feb 5, 2008 3:53 AM, Maarten Bosteels [EMAIL PROTECTED] wrote: On Feb 5, 2008 9:17 AM, Julien Vermillard [EMAIL PROTECTED] wrote: On Mon, 04 Feb 2008 18:52:37 -0700 Jeff Genender [EMAIL PROTECTED] wrote: great question..Im interested in this as well. Jeff Sangjin Lee wrote: I had a quick question on the connect timeout... The connect timeout supplied to connectors is in the unit of seconds, and it appears the minimum value you can use is 1 second ( AbstractIoConnector.setConnectTimeout() in the case of the trunk). Is this by design? I can see cases where one needs to have a shorter connect timeout, but it seems it is not possible today. One solution might be to use ConnectFuture.join() with a timeout, but that works only if you want to block until it times out... It also seems that this minimum timeout value is somewhat tied to the timeout value used in the select() loop in the connector, which is hard coded to be 1 second. Would it be a good idea to support connect timeout values in milliseconds, and make it shorter than 1 second? Thanks, Sangjin Hi, Apparently it's doable, the timeout value is multiplicated by 1000 before being placed in the ConnectionRequest deadline. As far I understand it, it's not a big deal but an API change. +1 for sub-second timeout values And I think it's best to change the API now, before cutting 2.0-M1 How about adding a java.util.concurrent.TimeUnit parameter to setConnectTimeout() ? Maarten Julien
Re: connect timeout
On Tue, 5 Feb 2008 09:53:27 +0100 Maarten Bosteels [EMAIL PROTECTED] wrote: On Feb 5, 2008 9:17 AM, Julien Vermillard [EMAIL PROTECTED] wrote: On Mon, 04 Feb 2008 18:52:37 -0700 Jeff Genender [EMAIL PROTECTED] wrote: great question..Im interested in this as well. Jeff Sangjin Lee wrote: I had a quick question on the connect timeout... The connect timeout supplied to connectors is in the unit of seconds, and it appears the minimum value you can use is 1 second ( AbstractIoConnector.setConnectTimeout() in the case of the trunk). Is this by design? I can see cases where one needs to have a shorter connect timeout, but it seems it is not possible today. One solution might be to use ConnectFuture.join() with a timeout, but that works only if you want to block until it times out... It also seems that this minimum timeout value is somewhat tied to the timeout value used in the select() loop in the connector, which is hard coded to be 1 second. Would it be a good idea to support connect timeout values in milliseconds, and make it shorter than 1 second? Thanks, Sangjin Hi, Apparently it's doable, the timeout value is multiplicated by 1000 before being placed in the ConnectionRequest deadline. As far I understand it, it's not a big deal but an API change. +1 for sub-second timeout values And I think it's best to change the API now, before cutting 2.0-M1 How about adding a java.util.concurrent.TimeUnit parameter to setConnectTimeout() ? Maarten Julien I think specifying a millisecond param is enough, nobody will pass hour/day/month/picosecond based timeout values. It'll complexify the API for no much gain. Julien
Re: connect timeout
On Feb 5, 2008 10:04 AM, Julien Vermillard [EMAIL PROTECTED] wrote: On Tue, 5 Feb 2008 09:53:27 +0100 Maarten Bosteels [EMAIL PROTECTED] wrote: On Feb 5, 2008 9:17 AM, Julien Vermillard [EMAIL PROTECTED] wrote: On Mon, 04 Feb 2008 18:52:37 -0700 Jeff Genender [EMAIL PROTECTED] wrote: great question..Im interested in this as well. Jeff Sangjin Lee wrote: I had a quick question on the connect timeout... The connect timeout supplied to connectors is in the unit of seconds, and it appears the minimum value you can use is 1 second ( AbstractIoConnector.setConnectTimeout() in the case of the trunk). Is this by design? I can see cases where one needs to have a shorter connect timeout, but it seems it is not possible today. One solution might be to use ConnectFuture.join() with a timeout, but that works only if you want to block until it times out... It also seems that this minimum timeout value is somewhat tied to the timeout value used in the select() loop in the connector, which is hard coded to be 1 second. Would it be a good idea to support connect timeout values in milliseconds, and make it shorter than 1 second? Thanks, Sangjin Hi, Apparently it's doable, the timeout value is multiplicated by 1000 before being placed in the ConnectionRequest deadline. As far I understand it, it's not a big deal but an API change. +1 for sub-second timeout values And I think it's best to change the API now, before cutting 2.0-M1 How about adding a java.util.concurrent.TimeUnit parameter to setConnectTimeout() ? Maarten Julien I think specifying a millisecond param is enough, nobody will pass hour/day/month/picosecond based timeout values. It'll complexify the API for no much gain. I agree that nobody will pass in hours or days, but IMHO it improves readability a lot: connector.setConnectTimeout(250, TimeUnit.MILLISECONDS); or connector.setConnectTimeout(250); Especially when one is changing the API from seconds to millis, we should try to make it unambiguous and it's inline with a lot of the java.util.concurrent API. Maarten Julien
Re : connect timeout
connector.setConnectTimeoutInMillis(250); This satisfies both of you :) My 2 cents ^^ Cordialement, Regards, -Edouard De Oliveira- http://tedorg.free.fr/en/main.php - Message d'origine De : Maarten Bosteels [EMAIL PROTECTED] À : dev@mina.apache.org Envoyé le : Mardi, 5 Février 2008, 10h25mn 01s Objet : Re: connect timeout On Feb 5, 2008 10:04 AM, Julien Vermillard [EMAIL PROTECTED] wrote: On Tue, 5 Feb 2008 09:53:27 +0100 Maarten Bosteels [EMAIL PROTECTED] wrote: On Feb 5, 2008 9:17 AM, Julien Vermillard [EMAIL PROTECTED] wrote: On Mon, 04 Feb 2008 18:52:37 -0700 Jeff Genender [EMAIL PROTECTED] wrote: great question..Im interested in this as well. Jeff Sangjin Lee wrote: I had a quick question on the connect timeout... The connect timeout supplied to connectors is in the unit of seconds, and it appears the minimum value you can use is 1 second ( AbstractIoConnector.setConnectTimeout() in the case of the trunk). Is this by design? I can see cases where one needs to have a shorter connect timeout, but it seems it is not possible today. One solution might be to use ConnectFuture.join() with a timeout, but that works only if you want to block until it times out... It also seems that this minimum timeout value is somewhat tied to the timeout value used in the select() loop in the connector, which is hard coded to be 1 second. Would it be a good idea to support connect timeout values in milliseconds, and make it shorter than 1 second? Thanks, Sangjin Hi, Apparently it's doable, the timeout value is multiplicated by 1000 before being placed in the ConnectionRequest deadline. As far I understand it, it's not a big deal but an API change. +1 for sub-second timeout values And I think it's best to change the API now, before cutting 2.0-M1 How about adding a java.util.concurrent.TimeUnit parameter to setConnectTimeout() ? Maarten Julien I think specifying a millisecond param is enough, nobody will pass hour/day/month/picosecond based timeout values. It'll complexify the API for no much gain. I agree that nobody will pass in hours or days, but IMHO it improves readability a lot: connector.setConnectTimeout(250, TimeUnit.MILLISECONDS); or connector.setConnectTimeout(250); Especially when one is changing the API from seconds to millis, we should try to make it unambiguous and it's inline with a lot of the java.util.concurrent API. Maarten Julien _ Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail http://mail.yahoo.fr
Re: connect timeout
On Feb 5, 2008 11:07 AM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Maarten Bosteels wrote: I agree that nobody will pass in hours or days, but IMHO it improves readability a lot: connector.setConnectTimeout(250, TimeUnit.MILLISECONDS); or connector.setConnectTimeout(250); Especially when one is changing the API from seconds to millis, we should try to make it unambiguous and it's inline with a lot of the java.util.concurrentAPI. The problem with changing the method parameters semantic is that it does not align anymore with the underlying semantic of the select( timeout ) method : select public abstract int *select*(long timeout) throws IOException http://java.sun.com/j2se/1.4.2/docs/api/java/io/IOException.html ... *Parameters:* |timeout| - If positive, block for up to timeout milliseconds, more or less... The method should use milliseconds, no need to be explicit with that, IMHO. I agree with Julien on that. ok, I can live with that. But you wouldn't even change the metod name ? So users who are porting there code from mina 1.x to 2.x will have to be very careful, or their timeouts will shrink with a factor of 1000. Maarten
Re: connect timeout
Maarten Bosteels wrote: On Feb 5, 2008 11:07 AM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Maarten Bosteels wrote: I agree that nobody will pass in hours or days, but IMHO it improves readability a lot: connector.setConnectTimeout(250, TimeUnit.MILLISECONDS); or connector.setConnectTimeout(250); Especially when one is changing the API from seconds to millis, we should try to make it unambiguous and it's inline with a lot of the java.util.concurrentAPI. The problem with changing the method parameters semantic is that it does not align anymore with the underlying semantic of the select( timeout ) method : select public abstract int *select*(long timeout) throws IOException http://java.sun.com/j2se/1.4.2/docs/api/java/io/IOException.html ... *Parameters:* |timeout| - If positive, block for up to timeout milliseconds, more or less... The method should use milliseconds, no need to be explicit with that, IMHO. I agree with Julien on that. ok, I can live with that. But you wouldn't even change the metod name ? So users who are porting there code from mina 1.x to 2.x will have to be very careful, or their timeouts will shrink with a factor of 1000. Maarten You would also need to make sure that the current IoConnector implementations can support millisecond timeouts. I think that would mean that AbstractPollingIoConnector.Worker needs to be changed. Specifically the line boolean selected = select(1000); To support milliseconds we could simply change this into boolean selected = select(1); but that would be very bad for performance. Instead, one could use an adaptive timeout in the call to select() which depends on the current ConnectRequests' timeouts. Or totally redesign things to use a ScheduledExecutorService or similar instead. -- Niklas Therning www.spamdrain.net
Re: connect timeout
On Tue, 05 Feb 2008 13:55:15 +0100 Niklas Therning [EMAIL PROTECTED] wrote: You would also need to make sure that the current IoConnector implementations can support millisecond timeouts. I think that would mean that AbstractPollingIoConnector.Worker needs to be changed. Specifically the line boolean selected = select(1000); To support milliseconds we could simply change this into boolean selected = select(1); but that would be very bad for performance. Instead, one could use an adaptive timeout in the call to select() which depends on the current ConnectRequests' timeouts. Or totally redesign things to use a ScheduledExecutorService or similar instead. Yes Niklas is right, I forgot the impact on worker loop. At first look an adaptive select timeout or a redesign using some kind of ExecutorService doesn't look like a trivial move.. Whats the lowest connect timeout needed if it's under 1 seconds ? Julien
Re: connect timeout
Right, that's why I said the connect timeout limitation seems tied to the select timeout... Hard-coded 1 second select timeout will interfere with sub-second connect timeout value. One obvious suggestion is to set the select timeout to be the same as the connect timeout. That way, we're pretty sure that the connect timeout will be honored. One small drawback is that we'd end up with a busy select loop if the connect timeout is too small. This could be prevented by having a minimum connect/select timeout value... Also, note that the 1-second timeout is pervasive elsewhere (like processor, etc.). Not sure if we need to change them also. Maybe not right now... If you guys don't mind, I'll file a bug (both for 1.1.x and 2.x) and submit a patch also... How's that sound? BTW, what is up with the 1 second sleep in the try-catch clause in the same code area? We can leave it as is? } catch (Throwable e) { ExceptionMonitor.getInstance().exceptionCaught(e); try { Thread.sleep(1000); } catch (InterruptedException e1) { ExceptionMonitor.getInstance().exceptionCaught(e1); } } Thanks, Sangjin On Feb 5, 2008 7:29 AM, Julien Vermillard [EMAIL PROTECTED] wrote: On Tue, 05 Feb 2008 13:55:15 +0100 Niklas Therning [EMAIL PROTECTED] wrote: You would also need to make sure that the current IoConnector implementations can support millisecond timeouts. I think that would mean that AbstractPollingIoConnector.Worker needs to be changed. Specifically the line boolean selected = select(1000); To support milliseconds we could simply change this into boolean selected = select(1); but that would be very bad for performance. Instead, one could use an adaptive timeout in the call to select() which depends on the current ConnectRequests' timeouts. Or totally redesign things to use a ScheduledExecutorService or similar instead. Yes Niklas is right, I forgot the impact on worker loop. At first look an adaptive select timeout or a redesign using some kind of ExecutorService doesn't look like a trivial move.. Whats the lowest connect timeout needed if it's under 1 seconds ? Julien
Re: connect timeout
great question..Im interested in this as well. Jeff Sangjin Lee wrote: I had a quick question on the connect timeout... The connect timeout supplied to connectors is in the unit of seconds, and it appears the minimum value you can use is 1 second ( AbstractIoConnector.setConnectTimeout() in the case of the trunk). Is this by design? I can see cases where one needs to have a shorter connect timeout, but it seems it is not possible today. One solution might be to use ConnectFuture.join() with a timeout, but that works only if you want to block until it times out... It also seems that this minimum timeout value is somewhat tied to the timeout value used in the select() loop in the connector, which is hard coded to be 1 second. Would it be a good idea to support connect timeout values in milliseconds, and make it shorter than 1 second? Thanks, Sangjin