accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Drob (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-2300) Leaking internal state in core/client code
Date Fri, 31 Jan 2014 19:18:10 GMT

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

Mike Drob commented on ACCUMULO-2300:
-------------------------------------

In some of the cases, I think we _want_ to be leaking the internal state, for the sake of
efficiency. Especially as {{Value}}s get large, it becomes less attractive to make array copies.

> Leaking internal state in core/client code
> ------------------------------------------
>
>                 Key: ACCUMULO-2300
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-2300
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: client
>    Affects Versions: 1.5.0
>            Reporter: Josh Elser
>            Priority: Minor
>
> In perusing over the findbugs reports, I noticed that there was a fair amount of classes
in the core module that were subject to leaking internal state (most commonly, returning the
actual array it holds internally instead of a copy or a wrapper).
> ArrayByteSequence, Column, ColumnUpdate, ComparableBytes, KeyValue, Mutation, Value,
ColumnVisibility are the classes that caught my eye.
> I would imagine that this is something we ultimately want to fix, but I'm not sure of
what the timeline should be. A decent short-term would be to just return copies of those {{byte[]}}
instead of the internal member. A longer-term solution might be to rework some of those classes
to use an object instead (e.g. ByteBuffer) that might have constructs to provide r/o views
instead of having to make a defensive copy.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Mime
View raw message