[
https://issues.apache.org/jira/browse/ACCUMULO-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Vines updated ACCUMULO-1410:
---------------------------------
Attachment: ACCUMULO-1410.patch
A little more attention is paid to times to try to adhere more closely to the
requested timeout values. Not sure if this is kosher to push because
technically it will change behavior for some users...
> ZooSession.connect barely adheres to timeout
> --------------------------------------------
>
> Key: ACCUMULO-1410
> URL: https://issues.apache.org/jira/browse/ACCUMULO-1410
> Project: Accumulo
> Issue Type: Bug
> Components: client, fate
> Reporter: John Vines
> Assignee: John Vines
> Fix For: 1.6.0
>
> Attachments: ACCUMULO-1410.patch
>
>
> ZooSession.connect, which is used by ZooKeeperInstance, takes an argument for
> a timeout, and utilizes it to an extent-
> {quote}
> if (System.currentTimeMillis() - startTime > 2 * timeout)
> {quote}
> However, this is only used after a check which uses hardcoded values.
> Currently, this is set to 10*1000ms. More specifically, it uses this value
> and checks every 100ms to see if it's connected. So if you have a tiny
> timeout, there are 2 issues:
> # Your timeout is only useful in 10 second increments, rounded up
> # You get a nice helpful error message that hides that real lengths of attempt
> I think the block of code should be changed to just try to connect for the
> user specified timeout length, working in the same 100ms increments. This
> allows more granularity in the handling of the user specified values (and I
> think it also simplifies the code). This will also make the timeout message
> more accurate.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
