[jira] Closed: (DIRMINA-527) should be able to set connect timeout in milliseconds
[ https://issues.apache.org/jira/browse/DIRMINA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien Vermillard closed DIRMINA-527. - should be able to set connect timeout in milliseconds - Key: DIRMINA-527 URL: https://issues.apache.org/jira/browse/DIRMINA-527 Project: MINA Issue Type: Improvement Components: Core Affects Versions: 1.0.8, 1.1.5, 2.0.0-M1 Reporter: Sangjin Lee Assignee: Mark Webb Fix For: 2.0.0-M2 Attachments: DIRMINA-527.patch Currently, IoConnector allows setting connect timeouts only in seconds. The minimum value of allowed connect timeout is 1 second. There are cases where one needs to have a shorter connect timeout than 1 second and will finer granularity than seconds. I suggest introducing the ability to set connect timeout in milliseconds and deprecating the getter/setter in seconds in favor of the ms getter/setter. See the discussion thread at http://www.nabble.com/connect-timeout-to15281787s16868.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (DIRMINA-527) should be able to set connect timeout in milliseconds
[ https://issues.apache.org/jira/browse/DIRMINA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trustin Lee reopened DIRMINA-527: - We have a little bit more to do :) http://mina.markmail.org/search/?q=connect%20timeout#query:connect%20timeout+page:1+mid:wp3ewpnfew7msthj+state:results should be able to set connect timeout in milliseconds - Key: DIRMINA-527 URL: https://issues.apache.org/jira/browse/DIRMINA-527 Project: MINA Issue Type: Improvement Components: Core Affects Versions: 1.0.8, 1.1.5, 2.0.0-M1 Reporter: Sangjin Lee Assignee: Mark Webb Fix For: 2.0.0-M2 Attachments: DIRMINA-527.patch Currently, IoConnector allows setting connect timeouts only in seconds. The minimum value of allowed connect timeout is 1 second. There are cases where one needs to have a shorter connect timeout than 1 second and will finer granularity than seconds. I suggest introducing the ability to set connect timeout in milliseconds and deprecating the getter/setter in seconds in favor of the ms getter/setter. See the discussion thread at http://www.nabble.com/connect-timeout-to15281787s16868.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-527) should be able to set connect timeout in milliseconds
[ https://issues.apache.org/jira/browse/DIRMINA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12576998#action_12576998 ] Mark Webb commented on DIRMINA-527: --- What is the purpose of the MINIMUM_CONNECT_TIMEOUT field? If it can be changed via a call to setConnectTimeoutMillis(long), then why have it? Trustin mentions in the TODO: Make this configurable and automatically adjusted if the timeout a user specified is smaller than the current minimum connect timeout. So if the minimum connection timeout and connection timeout can both be configured, why not just have one field? The only way this makes sense to me is that if you try and set the connection timeout to be lower than the minimum we should throw an exception. should be able to set connect timeout in milliseconds - Key: DIRMINA-527 URL: https://issues.apache.org/jira/browse/DIRMINA-527 Project: MINA Issue Type: Improvement Components: Core Affects Versions: 1.0.8, 1.1.5, 2.0.0-M1 Reporter: Sangjin Lee Assignee: Mark Webb Fix For: 2.0.0-M2 Attachments: DIRMINA-527.patch Currently, IoConnector allows setting connect timeouts only in seconds. The minimum value of allowed connect timeout is 1 second. There are cases where one needs to have a shorter connect timeout than 1 second and will finer granularity than seconds. I suggest introducing the ability to set connect timeout in milliseconds and deprecating the getter/setter in seconds in favor of the ms getter/setter. See the discussion thread at http://www.nabble.com/connect-timeout-to15281787s16868.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-527) should be able to set connect timeout in milliseconds
[ https://issues.apache.org/jira/browse/DIRMINA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577025#action_12577025 ] Trustin Lee commented on DIRMINA-527: - For example, we could start from 1000ms selector timeout at the first time. If a user specifies a connect timeout value smaller than 1000ms, we can adjust the 1000ms to the connect timeout value specified (or its half). By doing so, we can minimize unnecessary CPU consumption, because most users will use the timeout value of 60 seconds or something similar to that. If a user wants a millisecond-level timeout (e.g. 9ms), then he will pay for what he or she wants, but it's not the case for most people. should be able to set connect timeout in milliseconds - Key: DIRMINA-527 URL: https://issues.apache.org/jira/browse/DIRMINA-527 Project: MINA Issue Type: Improvement Components: Core Affects Versions: 1.0.8, 1.1.5, 2.0.0-M1 Reporter: Sangjin Lee Assignee: Mark Webb Fix For: 2.0.0-M2 Attachments: DIRMINA-527.patch Currently, IoConnector allows setting connect timeouts only in seconds. The minimum value of allowed connect timeout is 1 second. There are cases where one needs to have a shorter connect timeout than 1 second and will finer granularity than seconds. I suggest introducing the ability to set connect timeout in milliseconds and deprecating the getter/setter in seconds in favor of the ms getter/setter. See the discussion thread at http://www.nabble.com/connect-timeout-to15281787s16868.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-527) should be able to set connect timeout in milliseconds
[ https://issues.apache.org/jira/browse/DIRMINA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577284#action_12577284 ] Mark Webb commented on DIRMINA-527: --- I have checked in an update that makes the minimum timeout field configurable. should be able to set connect timeout in milliseconds - Key: DIRMINA-527 URL: https://issues.apache.org/jira/browse/DIRMINA-527 Project: MINA Issue Type: Improvement Components: Core Affects Versions: 1.0.8, 1.1.5, 2.0.0-M1 Reporter: Sangjin Lee Assignee: Mark Webb Fix For: 2.0.0-M2 Attachments: DIRMINA-527.patch Currently, IoConnector allows setting connect timeouts only in seconds. The minimum value of allowed connect timeout is 1 second. There are cases where one needs to have a shorter connect timeout than 1 second and will finer granularity than seconds. I suggest introducing the ability to set connect timeout in milliseconds and deprecating the getter/setter in seconds in favor of the ms getter/setter. See the discussion thread at http://www.nabble.com/connect-timeout-to15281787s16868.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DIRMINA-527) should be able to set connect timeout in milliseconds
[ https://issues.apache.org/jira/browse/DIRMINA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Webb resolved DIRMINA-527. --- Resolution: Fixed checked in an update that makes the minimum connection timeout field configurable should be able to set connect timeout in milliseconds - Key: DIRMINA-527 URL: https://issues.apache.org/jira/browse/DIRMINA-527 Project: MINA Issue Type: Improvement Components: Core Affects Versions: 1.0.8, 1.1.5, 2.0.0-M1 Reporter: Sangjin Lee Assignee: Mark Webb Fix For: 2.0.0-M2 Attachments: DIRMINA-527.patch Currently, IoConnector allows setting connect timeouts only in seconds. The minimum value of allowed connect timeout is 1 second. There are cases where one needs to have a shorter connect timeout than 1 second and will finer granularity than seconds. I suggest introducing the ability to set connect timeout in milliseconds and deprecating the getter/setter in seconds in favor of the ms getter/setter. See the discussion thread at http://www.nabble.com/connect-timeout-to15281787s16868.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-527) should be able to set connect timeout in milliseconds
[ https://issues.apache.org/jira/browse/DIRMINA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577286#action_12577286 ] Trustin Lee commented on DIRMINA-527: - Looks very good in its implementation! However, I think the property name 'minimumConnectTimeout' doesn't represent what it is actually. What do you think about renaming it to connectTimeoutCheckInterval or something similar? Do you have any idea? should be able to set connect timeout in milliseconds - Key: DIRMINA-527 URL: https://issues.apache.org/jira/browse/DIRMINA-527 Project: MINA Issue Type: Improvement Components: Core Affects Versions: 1.0.8, 1.1.5, 2.0.0-M1 Reporter: Sangjin Lee Assignee: Mark Webb Fix For: 2.0.0-M2 Attachments: DIRMINA-527.patch Currently, IoConnector allows setting connect timeouts only in seconds. The minimum value of allowed connect timeout is 1 second. There are cases where one needs to have a shorter connect timeout than 1 second and will finer granularity than seconds. I suggest introducing the ability to set connect timeout in milliseconds and deprecating the getter/setter in seconds in favor of the ms getter/setter. See the discussion thread at http://www.nabble.com/connect-timeout-to15281787s16868.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-527) should be able to set connect timeout in milliseconds
[ https://issues.apache.org/jira/browse/DIRMINA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577287#action_12577287 ] Mark Webb commented on DIRMINA-527: --- Nothing is really jumping out to me on this one so your idea is fine with me. should be able to set connect timeout in milliseconds - Key: DIRMINA-527 URL: https://issues.apache.org/jira/browse/DIRMINA-527 Project: MINA Issue Type: Improvement Components: Core Affects Versions: 1.0.8, 1.1.5, 2.0.0-M1 Reporter: Sangjin Lee Assignee: Mark Webb Fix For: 2.0.0-M2 Attachments: DIRMINA-527.patch Currently, IoConnector allows setting connect timeouts only in seconds. The minimum value of allowed connect timeout is 1 second. There are cases where one needs to have a shorter connect timeout than 1 second and will finer granularity than seconds. I suggest introducing the ability to set connect timeout in milliseconds and deprecating the getter/setter in seconds in favor of the ms getter/setter. See the discussion thread at http://www.nabble.com/connect-timeout-to15281787s16868.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DIRMINA-527) should be able to set connect timeout in milliseconds
[ https://issues.apache.org/jira/browse/DIRMINA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Webb reassigned DIRMINA-527: - Assignee: Mark Webb should be able to set connect timeout in milliseconds - Key: DIRMINA-527 URL: https://issues.apache.org/jira/browse/DIRMINA-527 Project: MINA Issue Type: Improvement Components: Core Affects Versions: 1.0.8, 1.1.5, 2.0.0-M1 Reporter: Sangjin Lee Assignee: Mark Webb Attachments: DIRMINA-527.patch Currently, IoConnector allows setting connect timeouts only in seconds. The minimum value of allowed connect timeout is 1 second. There are cases where one needs to have a shorter connect timeout than 1 second and will finer granularity than seconds. I suggest introducing the ability to set connect timeout in milliseconds and deprecating the getter/setter in seconds in favor of the ms getter/setter. See the discussion thread at http://www.nabble.com/connect-timeout-to15281787s16868.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-527) should be able to set connect timeout in milliseconds
[ https://issues.apache.org/jira/browse/DIRMINA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12576850#action_12576850 ] Mark Webb commented on DIRMINA-527: --- I have applied the patch associated with this issue. I will go ahead and mark this issue as fixed. should be able to set connect timeout in milliseconds - Key: DIRMINA-527 URL: https://issues.apache.org/jira/browse/DIRMINA-527 Project: MINA Issue Type: Improvement Components: Core Affects Versions: 1.0.8, 1.1.5, 2.0.0-M1 Reporter: Sangjin Lee Assignee: Mark Webb Attachments: DIRMINA-527.patch Currently, IoConnector allows setting connect timeouts only in seconds. The minimum value of allowed connect timeout is 1 second. There are cases where one needs to have a shorter connect timeout than 1 second and will finer granularity than seconds. I suggest introducing the ability to set connect timeout in milliseconds and deprecating the getter/setter in seconds in favor of the ms getter/setter. See the discussion thread at http://www.nabble.com/connect-timeout-to15281787s16868.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DIRMINA-527) should be able to set connect timeout in milliseconds
[ https://issues.apache.org/jira/browse/DIRMINA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Webb resolved DIRMINA-527. --- Resolution: Fixed Fix Version/s: 2.0.0-M2 I applied the associated patch after reviewing the patch. This only adds to the precision of the timeout. The methods that dealt with getting and setting the connection timeout in seconds have been deprecated and a note in the javadoc says that the millisecond-based methods should be used. should be able to set connect timeout in milliseconds - Key: DIRMINA-527 URL: https://issues.apache.org/jira/browse/DIRMINA-527 Project: MINA Issue Type: Improvement Components: Core Affects Versions: 1.0.8, 1.1.5, 2.0.0-M1 Reporter: Sangjin Lee Assignee: Mark Webb Fix For: 2.0.0-M2 Attachments: DIRMINA-527.patch Currently, IoConnector allows setting connect timeouts only in seconds. The minimum value of allowed connect timeout is 1 second. There are cases where one needs to have a shorter connect timeout than 1 second and will finer granularity than seconds. I suggest introducing the ability to set connect timeout in milliseconds and deprecating the getter/setter in seconds in favor of the ms getter/setter. See the discussion thread at http://www.nabble.com/connect-timeout-to15281787s16868.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
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
[jira] Commented: (DIRMINA-527) should be able to set connect timeout in milliseconds
[ https://issues.apache.org/jira/browse/DIRMINA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12566926#action_12566926 ] Sangjin Lee commented on DIRMINA-527: - Hmm... Is there any hope for changes in 1.1.x? It would be adding new methods, not removing existing ones, so backward compatibility is there... should be able to set connect timeout in milliseconds - Key: DIRMINA-527 URL: https://issues.apache.org/jira/browse/DIRMINA-527 Project: MINA Issue Type: Improvement Components: Core Affects Versions: 1.0.8, 1.1.5, 2.0.0-M1 Reporter: Sangjin Lee Attachments: DIRMINA-527.patch Currently, IoConnector allows setting connect timeouts only in seconds. The minimum value of allowed connect timeout is 1 second. There are cases where one needs to have a shorter connect timeout than 1 second and will finer granularity than seconds. I suggest introducing the ability to set connect timeout in milliseconds and deprecating the getter/setter in seconds in favor of the ms getter/setter. See the discussion thread at http://www.nabble.com/connect-timeout-to15281787s16868.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
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
[jira] Commented: (DIRMINA-527) should be able to set connect timeout in milliseconds
[ https://issues.apache.org/jira/browse/DIRMINA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12566465#action_12566465 ] Niklas Therning commented on DIRMINA-527: - The API for 1.0/1.1 has been frozen. Since this patch introduces changes in the API it should only go into trunk. Please, anyone, correct me if I'm wrong. BTW, the patch looks great! One tiny detail, I think the coding conventions we're using in MINA mandates spaces around operators. E.g. 60*1000L = 60 * 1000L. See http://mina.apache.org/developer-guide.html#DeveloperGuide-CodingConvention for more info. should be able to set connect timeout in milliseconds - Key: DIRMINA-527 URL: https://issues.apache.org/jira/browse/DIRMINA-527 Project: MINA Issue Type: Improvement Components: Core Affects Versions: 1.0.8, 1.1.5, 2.0.0-M1 Reporter: Sangjin Lee Attachments: DIRMINA-527.patch Currently, IoConnector allows setting connect timeouts only in seconds. The minimum value of allowed connect timeout is 1 second. There are cases where one needs to have a shorter connect timeout than 1 second and will finer granularity than seconds. I suggest introducing the ability to set connect timeout in milliseconds and deprecating the getter/setter in seconds in favor of the ms getter/setter. See the discussion thread at http://www.nabble.com/connect-timeout-to15281787s16868.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
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
[jira] Updated: (DIRMINA-527) should be able to set connect timeout in milliseconds
[ https://issues.apache.org/jira/browse/DIRMINA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangjin Lee updated DIRMINA-527: Attachment: DIRMINA-527.patch A proposed patch (based on the trunk). - Introduces IoConnector.setConnectTimeoutMillis(), and deprecates getConnectTimeout()/setConnectTimeout(). - Adjust the select timeout to be the smaller of the connectTimeout() or 1 second. Please review the changes, and accept them if you guys are OK with it. I'd also like to see the changes propagated to 1.1.x (and 1.0.x too?). Do we need separate JIRA issues for them? Thanks, Sangjin should be able to set connect timeout in milliseconds - Key: DIRMINA-527 URL: https://issues.apache.org/jira/browse/DIRMINA-527 Project: MINA Issue Type: Improvement Components: Core Affects Versions: 1.0.8, 1.1.5, 2.0.0-M1 Reporter: Sangjin Lee Attachments: DIRMINA-527.patch Currently, IoConnector allows setting connect timeouts only in seconds. The minimum value of allowed connect timeout is 1 second. There are cases where one needs to have a shorter connect timeout than 1 second and will finer granularity than seconds. I suggest introducing the ability to set connect timeout in milliseconds and deprecating the getter/setter in seconds in favor of the ms getter/setter. See the discussion thread at http://www.nabble.com/connect-timeout-to15281787s16868.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-527) should be able to set connect timeout in milliseconds
[ https://issues.apache.org/jira/browse/DIRMINA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangjin Lee updated DIRMINA-527: Attachment: (was: DIRMINA-527.patch) should be able to set connect timeout in milliseconds - Key: DIRMINA-527 URL: https://issues.apache.org/jira/browse/DIRMINA-527 Project: MINA Issue Type: Improvement Components: Core Affects Versions: 1.0.8, 1.1.5, 2.0.0-M1 Reporter: Sangjin Lee Attachments: DIRMINA-527.patch Currently, IoConnector allows setting connect timeouts only in seconds. The minimum value of allowed connect timeout is 1 second. There are cases where one needs to have a shorter connect timeout than 1 second and will finer granularity than seconds. I suggest introducing the ability to set connect timeout in milliseconds and deprecating the getter/setter in seconds in favor of the ms getter/setter. See the discussion thread at http://www.nabble.com/connect-timeout-to15281787s16868.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-527) should be able to set connect timeout in milliseconds
[ https://issues.apache.org/jira/browse/DIRMINA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangjin Lee updated DIRMINA-527: Attachment: DIRMINA-527.patch should be able to set connect timeout in milliseconds - Key: DIRMINA-527 URL: https://issues.apache.org/jira/browse/DIRMINA-527 Project: MINA Issue Type: Improvement Components: Core Affects Versions: 1.0.8, 1.1.5, 2.0.0-M1 Reporter: Sangjin Lee Attachments: DIRMINA-527.patch Currently, IoConnector allows setting connect timeouts only in seconds. The minimum value of allowed connect timeout is 1 second. There are cases where one needs to have a shorter connect timeout than 1 second and will finer granularity than seconds. I suggest introducing the ability to set connect timeout in milliseconds and deprecating the getter/setter in seconds in favor of the ms getter/setter. See the discussion thread at http://www.nabble.com/connect-timeout-to15281787s16868.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DIRMINA-527) should be able to set connect timeout in milliseconds
should be able to set connect timeout in milliseconds - Key: DIRMINA-527 URL: https://issues.apache.org/jira/browse/DIRMINA-527 Project: MINA Issue Type: Improvement Components: Core Affects Versions: 1.1.5, 1.0.8, 2.0.0-M1 Reporter: Sangjin Lee Currently, IoConnector allows setting connect timeouts only in seconds. The minimum value of allowed connect timeout is 1 second. There are cases where one needs to have a shorter connect timeout than 1 second and will finer granularity than seconds. I suggest introducing the ability to set connect timeout in milliseconds and deprecating the getter/setter in seconds in favor of the ms getter/setter. See the discussion thread at http://www.nabble.com/connect-timeout-to15281787s16868.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
connect timeout
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
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
