[
https://issues.apache.org/jira/browse/HBASE-13387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14486132#comment-14486132
]
stack edited comment on HBASE-13387 at 4/9/15 1:18 AM:
-------------------------------------------------------
bq. Also Cells added to Memstore and getting returned in Scan time
These won't be offheap or BB backed, right? So why type conversion needed?
bq. That is not an interface contract but an impl detail.
That the Cell is backed by an offheap BB should really be an implementation
detail too.
Highlevel, a particular Cell implementation wants to change the read path
implementation so read path can deal when a basic presumption no longer holds;
i.e. that Cells are NOT backed by byte array. The difficulty with this patch
and the DBB/Cell effort is that it sprinkles if/else throughout the code base
reimplementing basics -- compares mostly but also retrofitting into basic types
off-heap APIs where there were none before -- so they will work also against
offheap BBs. Ideally, at a high-level (does it have to be at the regionserver
level since read path spans block read to rpc?), a switch would be thrown, and
a factory would emit an appropriate Cell type AND any read path classes needed
such as comparators. Ideally the number of classes and the loci where we need
to be cognizant of difference will be few (two? The Cell type and its
comparators) and narrow. Is such an ideal possible lads?
bq. So what you say is keep the type of cell passing in read path as Cell
itself...
We could have the switch at every compare nexus or would it be possible to do
the switch at a high-level once as suggested above.
bq. Pls note that, the getXXXArray APIs will throw Exception in case of buffer
backed Cells. So writers of Filter/CP has to do the instance of check always.
Yeah, we want that. The filter is using raw APIs and needs to be insulated
better from our internals -- go via utils or get a comparator from a factory.
Or we do as you suggest above and we don't throw exception but do the
performance-killing copy until the filter gets changed.
bq. ...can we have separate getXXXOffset() methods for getting offset in buffer?
Please say more on above.
Thanks
was (Author: stack):
bq. Also Cells added to Memstore and getting returned in Scan time
These won't be offheap or BB backed, right? So why type conversion needed?
bq. That is not an interface contract but an impl detail.
That the Cell is backed by an offheap BB should really be an implementation
detail too.
Highlevel, a particular Cell implementation wants to change the read path
implementation so read path can deal when a basic presumption that no longer
holds; i.e. that Cells are NOT backed by byte array. The difficulty with this
patch and the DBB/Cell effort is that it sprinkles if/else throughout the code
base reimplementing basics -- compares mostly but also retrofitting into basic
types off-heap APIs where there were none before -- so they will work also
against offheap BBs. Ideally, at a high-level (does it have to be at the
regionserver level since read path spans block read to rpc?), a switch would be
thrown, and a factory would emit an appropriate Cell type AND any read path
classes such as comparators. Ideally the number of classes and the loci where
we need to be cognizant of difference will be few (two? The Cell type and its
comparators) and narrow. Is such an ideal possible lads?
bq. So what you say is keep the type of cell passing in read path as Cell
itself...
We could have the switch at every compare nexus or would it be possible to do
the switch at a high-level once as suggested above.
bq. Pls note that, the getXXXArray APIs will throw Exception in case of buffer
backed Cells. So writers of Filter/CP has to do the instance of check always.
Yeah, we want that. The filter is using raw APIs and needs to be insulated
better from our internals -- go via utils or get a comparator from a factory.
Or we do as you suggest above and we don't throw exception but do the
performance-killing copy until the filter gets changed.
bq. ...can we have separate getXXXOffset() methods for getting offset in buffer?
Please say more on above.
Thanks
> 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_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)
