[
https://issues.apache.org/jira/browse/ACCUMULO-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Vines updated ACCUMULO-482:
--------------------------------
Priority: Major (was: Minor)
We've (the team) discussed this quite a bit offline. While one can simply write
a translation API, there is something else we would like to accomplish with a
proxy. With the column visibilities, we contend that any part of the Key/Value
pair could be the piece that is worth restricting. And we attempt to uphold
this to teh highest degree. The one place where this falters is in the
!METADATA table. Whenever we split, we base the split point off of an existing
row ID in the table. And if the reason a column/value pair is put in a
particular visiblity is because of the row part of the key, then we're
potentially leaking it. All clients must be able to read the !METADATA table in
order to determine what tablet (and tserver) they need to hit to get their next
piece of information.
That said, we would actually like to make server side proxies. We've never
really concluded on tserver thread vs. independent process, I think that's
still up in the air. But regardless, what we should do is have all clients come
in through this proxy service, and it will handle all of the !METADATA table
lookups and funnel all of the data through itself back to the client. This can
prevent a possible attack to guesstimate where the tablets split (Adam can talk
more about this). We should have it utilize the current client API, as we still
want to use it for some operations (MR InputForamat off the top of my head).
However, aside from this, it should work as a proxy for all other purposes as
this is intended. We can simplify the API for the client user, letting all of
the !METADATA lookups occur on the proxy, we can do all of the error
translation, etc. This means we could have a much, MUCH lighter client api that
does easily trascend languages.
As for the language, I don't really care. We use thrift, so it would allow for
some object reuse (but then we will have to reimplement some objects, like Key,
Value, and Mutation, in the various languages I think). But I wouldn't object
to seeing something else used like Avro or any of those other similar projects.
However, I don't really see the need for the flexibility for Avro, but I think
it offers more than just that. Just my two cents.
I'll get off my soap box now.
> Add a thrift proxy server
> -------------------------
>
> Key: ACCUMULO-482
> URL: https://issues.apache.org/jira/browse/ACCUMULO-482
> Project: Accumulo
> Issue Type: New Feature
> Reporter: Sapan Shah
> Assignee: Sapan Shah
>
> Add a thrift proxy server to make integration with other languages besides
> Java a bit easier. This should work like
> http://wiki.apache.org/hadoop/Hbase/ThriftApi.
--
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
