accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-984) Check potentially unexpected behavior with TimeUnit
Date Thu, 24 Jan 2013 22:47:12 GMT


Christopher Tubbs commented on ACCUMULO-984:

I personally find 0 more confusing, because of precedents set by things like read() methods
that return the number of bytes read, or -1 if EOF, long before Hadoop and Accumulo configs
came along. Just like -1 is used in those situations, because 0 has the explicit semantics
of "read 0 bytes", 0 in terms of time, has the explicit meaning of "take action immediately,
with no delay" (we even support this meaning in the maxMemory option in the same BatchWriterConfig
class). Granted, these semantics may not be useful in the timeout or maxLatency contexts used
in the BatchWriterConfig (it may or may not be useful to timeout immediately), and the comparison
with the semantics of maxMemory are imprecise (because there's no need to support a Long.MAX_VALUE
equivalent for memory), but I do think it is more intuitive than re-mapping 0 to an effective
infinity. I think it is more intuitive to remap -1, which has no alternate or ambiguous semantic
meaning in the timeout context, to infinity instead.

Despite my personal preference and the reasons for it, I do understand the need for consistency,
and will implement option 2 (it's easier anyway, even if only slightly).
> Check potentially unexpected behavior with TimeUnit
> ---------------------------------------------------
>                 Key: ACCUMULO-984
>                 URL:
>             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:

View raw message