You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@accumulo.apache.org by "Mike Drob (JIRA)" <ji...@apache.org> on 2014/01/31 20:18:10 UTC

[jira] [Commented] (ACCUMULO-2300) Leaking internal state in core/client code

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