hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-13387) Add ServerCell an extension to Cell
Date Thu, 09 Apr 2015 19:05:12 GMT

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

stack commented on HBASE-13387:
-------------------------------

bq. Adding one more cell and allowing the user to to manipulate the cell using instance of
check - so it becomes mandatory that he uses this instance of check or use the CellUtil. Another
thing is it becomes user's prudency to use the correct Offset API like use getXXXOffset for
getXXXArray and use the getBBPosition() for the getXXXBuffer. 

I cannot parse the above. Please rephrase.

bq. This problem was already there in terms of using hasArray without which he would get an
UnSupportedException but did not have the problem of the API confusion. 

Not sure what above is referring to. Yes, we have an issue where a cell implementation wants
to change the read path implementation to suit.  Yes, if a cell implementation takes the wrong
path, it should blowup and throw an exception.  Which API confusion? (What Cell methods do
when BB-backed or the change of all APIs to take a ServerCell?)

bq. 'instanceOf' and 'typecast' would become mandatory because in our previous patches we
had this way and later reverted this as things look ugly particularly because the number of
times we call different comparators is huge. 

To be clear, what is being advocated now is corralling locations where have to do instanceof
into a few areas only rather than all over the readpath with a follow-on project to see if
we could avoid instanceof by using factories' to load type-appropriate 'read-paths': e.g.
a DBB aware comparator in place of current one if RS is running offheap read path.

bq. One more thing, I think in these implementations it is very much mandatory that we cache
these new offsets and lengths ? Am i right? 

The constant reparse and recalc of lengths and offsets costs. Caching this stuff is secondary
I'd say, an implementation detail as [~anoop.hbase] called it earlier.

 









> Add ServerCell an extension to Cell
> -----------------------------------
>
>                 Key: HBASE-13387
>                 URL: https://issues.apache.org/jira/browse/HBASE-13387
>             Project: HBase
>          Issue Type: Sub-task
>          Components: regionserver, Scanners
>            Reporter: Anoop Sam John
>            Assignee: Anoop Sam John
>         Attachments: WIP_HBASE-13387_V2.patch, WIP_ServerCell.patch
>
>
> This came in btw the discussion abt the parent Jira and recently Stack added as a comment
on the E2E patch on the parent Jira.
> The idea is to add a new Interface 'ServerCell'  in which we can add new buffer based
getter APIs, hasArray API etc.  We will keep this interface @InterfaceAudience.Private
> Also we have to change the timestamp and seqId on Cells in server side. We have added
new interfaces SettableSequenceId, SettableTimestamp for this. Now if we can add a ServerCell
we can add the setter APIs there.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message