[ https://issues.apache.org/jira/browse/HBASE-8684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jesse Yates updated HBASE-8684: ------------------------------- Resolution: Fixed Status: Resolved (was: Patch Available) Committed to 0.94, 0.95, and trunk. > Table Coprocessor can't access external HTable by default > --------------------------------------------------------- > > Key: HBASE-8684 > URL: https://issues.apache.org/jira/browse/HBASE-8684 > Project: HBase > Issue Type: Bug > Reporter: Jesse Yates > Assignee: Jesse Yates > Fix For: 0.98.0, 0.95.1, 0.94.9 > > Attachments: 8684-trunk.txt, hbase-8684-0.94-addendum.patch, > hbase-8684-0.94-v0.patch, hbase-8684-0.94-v1.patch, hbase-8684-0.94-v2.patch, > hbase-8684-0.94-v3.patch, hbase-8684-0.94-v4.patch, > hbase-8684-trunk-addendum.patch, hbase-8684-trunk-v1.patch > > > With the default configuration passed to a RegionCoprocessor environment, you > cannot reach an HTable on the same cluster (at least in 0.94 - no verified > yet in 0.96/8). The reason is in the usage of CompoundConfiguration > (backported to 0.94 in HBASE-8176) when loading a table coprocessor we just > do (RegionCoprocessorHost, ln 182): > {code} > Configuration newConf = new Configuration(conf); > // set per-table cfspec properties > {code} > but the conf we pass in a CompoundConfiguration, which means the copy > constructor from Configuration doesn't work at all. > So, we really need two things: > 1. A test that we can reach another HTable in the same cluster via a > coprocessor by default > 2. Fixing the configuration creation in RegionCoprocessorHost to support (1) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira