[jira] [Created] (HBASE-11117) [AccessController] checkAndPut/Delete hook should check only Read permission
Anoop Sam John created HBASE-7: -- Summary: [AccessController] checkAndPut/Delete hook should check only Read permission Key: HBASE-7 URL: https://issues.apache.org/jira/browse/HBASE-7 Project: HBase Issue Type: Bug Components: security Affects Versions: 0.98.0 Reporter: Anoop Sam John Assignee: Anoop Sam John Fix For: 0.99.0, 0.98.3 We check for Read and Write permissions in checkAndPut/Delete hooks. Here we check for the condition part alone and so can check for Read permission alone. Later prePut/Delete hook is getting called with Put/Delete mutation and in that we properly check for the Write permission -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (HBASE-11118) non environment variable solution for IllegalAccessError: class com.google.protobuf.ZeroCopyLiteralByteString cannot access its superclass com.google.protobuf.LiteralBy
André Kelpe created HBASE-8: --- Summary: non environment variable solution for IllegalAccessError: class com.google.protobuf.ZeroCopyLiteralByteString cannot access its superclass com.google.protobuf.LiteralByteString Key: HBASE-8 URL: https://issues.apache.org/jira/browse/HBASE-8 Project: HBase Issue Type: Bug Affects Versions: 0.98.2 Reporter: André Kelpe I am running into the problem described in https://issues.apache.org/jira/browse/HBASE-10304, while trying to use a newer version within cascading.hbase (https://github.com/cascading/cascading.hbase). One of the features of cascading.hbase is that you can use it from lingual (http://www.cascading.org/projects/lingual/), our SQL layer for hadoop. lingual has a notion of providers, which are fat jars that we pull down dynamically at runtime. Those jars give users the ability to talk to any system or format from SQL. They are added to the classpath programmatically before we submit jobs to a hadoop cluster. Since lingual does not know upfront , which providers are going to be used in a given run, the HADOOP_CLASSPATH trick proposed in the JIRA above is really clunky and breaks the ease of use we had before. No other provider requires this right now. It would be great to have a programmatical way to fix this, when using fat jars. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (HBASE-10923) Control where to put meta region
[ https://issues.apache.org/jira/browse/HBASE-10923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jimmy Xiang reopened HBASE-10923: - Re-open it. We need a way for the master to do the old-style deployment. Control where to put meta region Key: HBASE-10923 URL: https://issues.apache.org/jira/browse/HBASE-10923 Project: HBase Issue Type: Improvement Reporter: Jimmy Xiang Assignee: Jimmy Xiang There is a concern on placing meta regions on the master, as in the comments of HBASE-10569. I was thinking we should have a configuration for a load balancer to decide where to put it. Adjusting this configuration we can control whether to put the meta on master, or other region server. -- This message was sent by Atlassian JIRA (v6.2#6252)
custom filter which extends Filter directly
Hi, Filter is an abstract class. If your filter extends Filter directly, I would be curious to know your use case. Thanks
[jira] [Created] (HBASE-11119) Update ExportSnapShot to optionally not use a tmp file on external file system
Ted Malaska created HBASE-9: --- Summary: Update ExportSnapShot to optionally not use a tmp file on external file system Key: HBASE-9 URL: https://issues.apache.org/jira/browse/HBASE-9 Project: HBase Issue Type: New Feature Reporter: Ted Malaska Priority: Minor There are FileSystem like S3 where renaming is extremely expensive. This patch will add a parameter that says something like use.tmp.folder It will be defaulted to true. So default behavior is the same. If false is set them the files will land in the final destination with no need for a rename. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (HBASE-11121) Guidelines on when / how often to do major compaction, as well as default settings and how to change
Misty Stanley-Jones created HBASE-11121: --- Summary: Guidelines on when / how often to do major compaction, as well as default settings and how to change Key: HBASE-11121 URL: https://issues.apache.org/jira/browse/HBASE-11121 Project: HBase Issue Type: Bug Components: Compaction, documentation Affects Versions: 0.98.2 Reporter: Misty Stanley-Jones [14:53:10] jdcryans I'd say 80% of the time you should just let it happen naturally [14:53:26] jdcryans the main thing is deciding how often you want to major compact [14:53:38] jdcryans some people disable it completely because they don't update/delete [14:53:58] jdcryans others may decide to do it weekly because they don't update/delete that often [14:54:18] jdcryans and then there's the aggressive default of doing it every 24h [14:55:39] jdcryans and it looks like the default is now 1 week un trunk [14:56:09] jdcryans same in C5 [14:58:35] jdcryans automatic major* compactions -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (HBASE-11120) Update documentation about major compaction algorithm
Misty Stanley-Jones created HBASE-11120: --- Summary: Update documentation about major compaction algorithm Key: HBASE-11120 URL: https://issues.apache.org/jira/browse/HBASE-11120 Project: HBase Issue Type: Bug Components: Compaction, documentation Affects Versions: 0.98.2 Reporter: Misty Stanley-Jones [14:20:38] jdcryans seems that there's http://hbase.apache.org/book.html#compaction and http://hbase.apache.org/book.html#managed.compactions [14:20:56] jdcryans the latter doesn't say much, except that you should manage them [14:21:44] jdcryans the former gives a good description of the _old_ selection algo [14:45:25] jdcryans this is the new selection algo since C5 / 0.96.0: https://issues.apache.org/jira/browse/HBASE-7842 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (HBASE-11122) Annotate coprocessor APIs
Andrew Purtell created HBASE-11122: -- Summary: Annotate coprocessor APIs Key: HBASE-11122 URL: https://issues.apache.org/jira/browse/HBASE-11122 Project: HBase Issue Type: Task Affects Versions: 0.99.0, 0.98.3 Reporter: Andrew Purtell Add annotations to coprocessor APIs for:\\ - Interface stability - If or if not bypassable - If or if not executed under row lock -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (HBASE-6646) Upgrade to 0.96 section in the book
[ https://issues.apache.org/jira/browse/HBASE-6646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar resolved HBASE-6646. -- Resolution: Duplicate Thanks. Yes, this has been done elsewhere. Having a upgrade from 0.94 to 0.98 would be good though in a separate jira. Upgrade to 0.96 section in the book --- Key: HBASE-6646 URL: https://issues.apache.org/jira/browse/HBASE-6646 Project: HBase Issue Type: Improvement Components: documentation Affects Versions: 0.95.2 Reporter: Enis Soztutar Priority: Blocker We should have an upgrade section in the book for 0.96. Raising this as blocker. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (HBASE-11123) Upgrade instructions from 0.94 to 0.98
Misty Stanley-Jones created HBASE-11123: --- Summary: Upgrade instructions from 0.94 to 0.98 Key: HBASE-11123 URL: https://issues.apache.org/jira/browse/HBASE-11123 Project: HBase Issue Type: Improvement Components: documentation Affects Versions: 0.95.2 Reporter: Misty Stanley-Jones Priority: Blocker We should have an upgrade section in the book for 0.96. Raising this as blocker. -- This message was sent by Atlassian JIRA (v6.2#6252)
