accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hudson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-984) Check potentially unexpected behavior with TimeUnit
Date Fri, 25 Jan 2013 00:09:15 GMT

    [ https://issues.apache.org/jira/browse/ACCUMULO-984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13562171#comment-13562171
] 

Hudson commented on ACCUMULO-984:
---------------------------------

Integrated in Accumulo-Trunk #665 (See [https://builds.apache.org/job/Accumulo-Trunk/665/])
    ACCUMULO-984 Prevent unexpected behavior when using a really small timeout values, that
get truncated to zero on conversion internally.
ACCUMULO-955 Removed the minimum value for maxMemory, and accept any non-negative value. (Revision
1438248)

     Result = SUCCESS
ctubbsii : 
Files : 
* /accumulo/trunk/core/src/main/java/org/apache/accumulo/core/client/BatchWriterConfig.java
* /accumulo/trunk/core/src/test/java/org/apache/accumulo/core/client/BatchWriterConfigTest.java

                
> Check potentially unexpected behavior with TimeUnit
> ---------------------------------------------------
>
>                 Key: ACCUMULO-984
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-984
>             Project: Accumulo
>          Issue Type: Sub-task
>          Components: client
>            Reporter: Christopher Tubbs
>             Fix For: 1.5.0
>
>
> For maxTimeout and maxLatency, there is potentially unexpected behavior if the user sets
a (very) small value. Internally, these values are stored as MILLISECONDS, but TimeUnit supports
MICROSECONDS, and NANOSECONDS, which means that when we convert values to MILLISECONDS, if
the value is small, the conversion could lose precision and change a really small value to
an exact value of 0 MILLISECONDS, which has the special interpretation of INFINITY. Setting
a really small value that internally converts to INFINITY (or Long.MAX_VALUE, at the very
least) is incorrect.
> We just to need to check this and possibly clean up the code to behave in a way more
congruent with the behavior users might expect.
> Options:
> # Treat -1 as +INF instead of 0 (which I think more intuitively means "immediate" instead
of "never" for a span of time).
> # Always round up to 1 millisecond, if the value would normally round down to 0 and wasn't
already 0 to begin with.

--
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

Mime
View raw message