hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gregory Chanan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-5447) Support for custom filters with PB-based RPC
Date Thu, 19 Jul 2012 04:29:35 GMT

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

Gregory Chanan commented on HBASE-5447:
---------------------------------------

Some thoughts on this issue...

First off: I'm not sure if this JIRA is referring to the built-in existing filters, or filters
that end-users would write (or some combination of both).  So, what does "custom" mean here?
 I'm going to refer to both built-in and new filters below -- I think we need to make a decision
for each.

Today, we are using the Writable methods for each filter type in order to create the Filter
on the other end of the rpc (together with the filter class name, this is enough to construct
the filter).  This work but means the filters are not extensible in a forward-compatible way.
 Options:

1) Require a protobuf definition for each filter class
This would allow us to make each filter forward-compatible in the manner that all other rpcs
are done.  I found 16 built-in filter classes where this would need to be done, so I don't
think it's a huge undertaking.  I'm even offering to do it :).  I think this is the best option
for the built-in filters: most users probably don't write their own filters and we might as
well make them extensible.
The downside is that for new filters that end-users would write, we would require them to
install pb, write pb definitions, and write java conversions (convert pb filter to Filter
and visa-versa) which makes writing filters for users more difficult -- they may not even
care about forward compatibility.

2) Keep the existing Writable interface (or use something similar)
This would require no work, but doesn't give us forward compatibility.

We could do also a hybrid scheme, where users have the option to either create PB-compatible
filters or Writable filters (e.g. we could have something like FilterBaseWritable and FilterBasePB),
where all our builit-in filters derive from FilterBasePB and end-users who don't want to mess
with PB can just derive from FilterBasePB (where they are required to implement the readFields
and write methods, as today).  The downside here, of course, is more code to maintain and
test for both of the filter base classes.

So, to recap, the questions I think we need to answer are:
A) What should be done about the built-in filters (I suggest converting fully to PB)
B) What should be done about new filters that end-users write
                
> Support for custom filters with PB-based RPC
> --------------------------------------------
>
>                 Key: HBASE-5447
>                 URL: https://issues.apache.org/jira/browse/HBASE-5447
>             Project: HBase
>          Issue Type: Sub-task
>          Components: ipc, master, migration, regionserver
>            Reporter: Todd Lipcon
>            Assignee: Todd Lipcon
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message