[jira] [Commented] (HBASE-15240) Go Big BucketCache Fixes
[ https://issues.apache.org/jira/browse/HBASE-15240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160286#comment-15160286 ] ramkrishna.s.vasudevan commented on HBASE-15240: My intention was just to see if this parent JIRA is appropriate since we are talking about bigger sized bucket caches. Ya tiered cache needs policy for placement of blocks and considering the hotness, etc. Hence thought can be part of this parent JIRA. If you want that to be a seperate one, am fine with it too. > Go Big BucketCache Fixes > > > Key: HBASE-15240 > URL: https://issues.apache.org/jira/browse/HBASE-15240 > Project: HBase > Issue Type: Umbrella > Components: BucketCache >Reporter: stack >Assignee: stack > Attachments: Screen Shot 2016-02-10 at 6.27.26 AM.png > > > Umbrella issue to which we will attach issues that prevent bucketcache going > big; there's a few. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15180) Reduce garbage created while reading Cells from Codec Decoder
[ https://issues.apache.org/jira/browse/HBASE-15180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160284#comment-15160284 ] stack commented on HBASE-15180: --- Looks better to me. All the messing is kept internal to Codec. Hopefully we get to remove the tag-particular codecs and KeyValue ones one day (let the codec figure whether tags are present or not rather than upper layers -- make Tags first class). > Reduce garbage created while reading Cells from Codec Decoder > - > > Key: HBASE-15180 > URL: https://issues.apache.org/jira/browse/HBASE-15180 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Affects Versions: 0.98.0 >Reporter: Anoop Sam John >Assignee: Anoop Sam John > Fix For: 2.0.0 > > Attachments: HBASE-15180.patch, HBASE-15180_V2.patch, > HBASE-15180_V4.patch, HBASE-15180_V6.patch > > > In KeyValueDecoder#parseCell (Default Codec decoder) we use > KeyValueUtil#iscreate to read cells from the InputStream. Here we 1st create > a byte[] of length 4 and read the cell length and then an array of Cell's > length and read in cell bytes into it and create a KV. > Actually in server we read the reqs into a byte[] and CellScanner is created > on top of a ByteArrayInputStream on top of this. By default in write path, we > have MSLAB usage ON. So while adding Cells to memstore, we will copy the Cell > bytes to MSLAB memory chunks (default 2 MB size) and recreate Cells over that > bytes. So there is no issue if we create Cells over the RPC read byte[] > directly here in Decoder. No need for 2 byte[] creation and copy for every > Cell in request. > My plan is to make a Cell aware ByteArrayInputStream which can read Cells > directly from it. > Same Codec path is used in client side also. There better we can avoid this > direct Cell create and continue to do the copy to smaller byte[]s path. Plan > to introduce some thing like a CodecContext associated with every Codec > instance which can say the server/client context. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15277) TestRegionMergeTransactionOnCluster.testWholesomeMerge fails with no connection to master
[
https://issues.apache.org/jira/browse/HBASE-15277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160285#comment-15160285
]
stack commented on HBASE-15277:
---
Pushed the debugging patch
> TestRegionMergeTransactionOnCluster.testWholesomeMerge fails with no
> connection to master
> -
>
> Key: HBASE-15277
> URL: https://issues.apache.org/jira/browse/HBASE-15277
> Project: HBase
> Issue Type: Sub-task
> Components: test
>Reporter: stack
> Fix For: 2.0.0
>
> Attachments: 15277.patch, debugging.patch
>
>
> {code}
> java.io.IOException: connection is closed
> at
> org.apache.hadoop.hbase.MetaTableAccessor.getMetaHTable(MetaTableAccessor.java:254)
> at
> org.apache.hadoop.hbase.MetaTableAccessor.scanMeta(MetaTableAccessor.java:773)
> at
> org.apache.hadoop.hbase.MetaTableAccessor.scanMeta(MetaTableAccessor.java:702)
> at
> org.apache.hadoop.hbase.MetaTableAccessor.getTableRegionsAndLocations(MetaTableAccessor.java:624)
> at
> org.apache.hadoop.hbase.MetaTableAccessor.getTableRegionsAndLocations(MetaTableAccessor.java:575)
> at
> org.apache.hadoop.hbase.regionserver.TestRegionMergeTransactionOnCluster.waitAndVerifyRegionNum(TestRegionMergeTransactionOnCluster.java:426)
> at
> org.apache.hadoop.hbase.regionserver.TestRegionMergeTransactionOnCluster.mergeRegionsAndVerifyRegionNum(TestRegionMergeTransactionOnCluster.java:402)
> at
> org.apache.hadoop.hbase.regionserver.TestRegionMergeTransactionOnCluster.testWholesomeMerge(TestRegionMergeTransactionOnCluster.java:139)
> {code|
> Everywhere we rely on master connection being up. Instead try using the test
> Connection ... see how that does. Add timeouts on this flakey test too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-14703) not collect stats when call HTable.mutateRow
[ https://issues.apache.org/jira/browse/HBASE-14703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Heng Chen updated HBASE-14703: -- Attachment: HBASE-14703_v12.patch v12 address all [~jesse_yates] comments on review board. > not collect stats when call HTable.mutateRow > - > > Key: HBASE-14703 > URL: https://issues.apache.org/jira/browse/HBASE-14703 > Project: HBase > Issue Type: Bug >Reporter: Heng Chen >Assignee: Heng Chen > Fix For: 2.0.0 > > Attachments: HBASE-14702_v5.2_addendum-addendum.patch, > HBASE-14703-5.2-addendum.patch, HBASE-14703-async.patch, > HBASE-14703-start.patch, HBASE-14703-v4.1.patch, HBASE-14703-v4.patch, > HBASE-14703-v6_with-check-and-mutate.patch, HBASE-14703.patch, > HBASE-14703_v1.patch, HBASE-14703_v10.patch, HBASE-14703_v10.patch, > HBASE-14703_v11.patch, HBASE-14703_v12.patch, HBASE-14703_v2.patch, > HBASE-14703_v3.patch, HBASE-14703_v5.1.patch, HBASE-14703_v5.2.patch, > HBASE-14703_v5.patch, HBASE-14703_v6-addendum.patch, HBASE-14703_v6.patch, > HBASE-14703_v7.patch, HBASE-14703_v8.patch, HBASE-14703_v9.patch > > > We are trying to fix the stats implementation, by moving it out of the Result > object and into an Rpc payload (but not the 'cell payload', just as part of > the values returned from the request). This change will also us use easily > switch to AsyncProcess as the executor, and support stats, for nearly all the > rpc calls. However, that means when you upgrade the client or server, you > will lose stats visibility until the other side is upgraded. We could keep > around the Result based stats storage to accommodate the old api and send > both stats back from the server (in each result and in the rpc payload). > Note that we will still be wire compatible - protobufs mean we can just ride > over the lack of information. > The other tricky part of this is that Result has a > non-InterfaceAudience.Private getStatistics() method (along with two > InterfaceAudience.Private addResults and setStatistics methods), so we might > need a release to deprecate the getStats() method before throwing it out? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15277) TestRegionMergeTransactionOnCluster.testWholesomeMerge fails with no connection to master
[
https://issues.apache.org/jira/browse/HBASE-15277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160273#comment-15160273
]
stack commented on HBASE-15277:
---
Yeah, this test is failing with regularity still.
> TestRegionMergeTransactionOnCluster.testWholesomeMerge fails with no
> connection to master
> -
>
> Key: HBASE-15277
> URL: https://issues.apache.org/jira/browse/HBASE-15277
> Project: HBase
> Issue Type: Sub-task
> Components: test
>Reporter: stack
> Fix For: 2.0.0
>
> Attachments: 15277.patch, debugging.patch
>
>
> {code}
> java.io.IOException: connection is closed
> at
> org.apache.hadoop.hbase.MetaTableAccessor.getMetaHTable(MetaTableAccessor.java:254)
> at
> org.apache.hadoop.hbase.MetaTableAccessor.scanMeta(MetaTableAccessor.java:773)
> at
> org.apache.hadoop.hbase.MetaTableAccessor.scanMeta(MetaTableAccessor.java:702)
> at
> org.apache.hadoop.hbase.MetaTableAccessor.getTableRegionsAndLocations(MetaTableAccessor.java:624)
> at
> org.apache.hadoop.hbase.MetaTableAccessor.getTableRegionsAndLocations(MetaTableAccessor.java:575)
> at
> org.apache.hadoop.hbase.regionserver.TestRegionMergeTransactionOnCluster.waitAndVerifyRegionNum(TestRegionMergeTransactionOnCluster.java:426)
> at
> org.apache.hadoop.hbase.regionserver.TestRegionMergeTransactionOnCluster.mergeRegionsAndVerifyRegionNum(TestRegionMergeTransactionOnCluster.java:402)
> at
> org.apache.hadoop.hbase.regionserver.TestRegionMergeTransactionOnCluster.testWholesomeMerge(TestRegionMergeTransactionOnCluster.java:139)
> {code|
> Everywhere we rely on master connection being up. Instead try using the test
> Connection ... see how that does. Add timeouts on this flakey test too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15277) TestRegionMergeTransactionOnCluster.testWholesomeMerge fails with no connection to master
[
https://issues.apache.org/jira/browse/HBASE-15277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-15277:
--
Attachment: debugging.patch
Adding in debugging. When this suite fails, comparing against a good run, we
see this in logs:
2016-02-24 03:25:23,630 ERROR
[asf909.gq1.ygridcore.net,55601,1456284313298-GeneralBulkAssigner-0]
master.TableStateManager(134): Unable to get table testMergeAndRestartingMaster
state, probably table not exists
... which is a little odd because above I see us writing out the descriptor.
Let me add in printing of why we can't get the descriptor and then logging in
test so can see how far it progresses.
> TestRegionMergeTransactionOnCluster.testWholesomeMerge fails with no
> connection to master
> -
>
> Key: HBASE-15277
> URL: https://issues.apache.org/jira/browse/HBASE-15277
> Project: HBase
> Issue Type: Sub-task
> Components: test
>Reporter: stack
> Fix For: 2.0.0
>
> Attachments: 15277.patch, debugging.patch
>
>
> {code}
> java.io.IOException: connection is closed
> at
> org.apache.hadoop.hbase.MetaTableAccessor.getMetaHTable(MetaTableAccessor.java:254)
> at
> org.apache.hadoop.hbase.MetaTableAccessor.scanMeta(MetaTableAccessor.java:773)
> at
> org.apache.hadoop.hbase.MetaTableAccessor.scanMeta(MetaTableAccessor.java:702)
> at
> org.apache.hadoop.hbase.MetaTableAccessor.getTableRegionsAndLocations(MetaTableAccessor.java:624)
> at
> org.apache.hadoop.hbase.MetaTableAccessor.getTableRegionsAndLocations(MetaTableAccessor.java:575)
> at
> org.apache.hadoop.hbase.regionserver.TestRegionMergeTransactionOnCluster.waitAndVerifyRegionNum(TestRegionMergeTransactionOnCluster.java:426)
> at
> org.apache.hadoop.hbase.regionserver.TestRegionMergeTransactionOnCluster.mergeRegionsAndVerifyRegionNum(TestRegionMergeTransactionOnCluster.java:402)
> at
> org.apache.hadoop.hbase.regionserver.TestRegionMergeTransactionOnCluster.testWholesomeMerge(TestRegionMergeTransactionOnCluster.java:139)
> {code|
> Everywhere we rely on master connection being up. Instead try using the test
> Connection ... see how that does. Add timeouts on this flakey test too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15277) TestRegionMergeTransactionOnCluster.testWholesomeMerge fails with no connection to master
[
https://issues.apache.org/jira/browse/HBASE-15277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160269#comment-15160269
]
stack commented on HBASE-15277:
---
All attempts at fixing this test
> TestRegionMergeTransactionOnCluster.testWholesomeMerge fails with no
> connection to master
> -
>
> Key: HBASE-15277
> URL: https://issues.apache.org/jira/browse/HBASE-15277
> Project: HBase
> Issue Type: Sub-task
> Components: test
>Reporter: stack
> Fix For: 2.0.0
>
> Attachments: 15277.patch
>
>
> {code}
> java.io.IOException: connection is closed
> at
> org.apache.hadoop.hbase.MetaTableAccessor.getMetaHTable(MetaTableAccessor.java:254)
> at
> org.apache.hadoop.hbase.MetaTableAccessor.scanMeta(MetaTableAccessor.java:773)
> at
> org.apache.hadoop.hbase.MetaTableAccessor.scanMeta(MetaTableAccessor.java:702)
> at
> org.apache.hadoop.hbase.MetaTableAccessor.getTableRegionsAndLocations(MetaTableAccessor.java:624)
> at
> org.apache.hadoop.hbase.MetaTableAccessor.getTableRegionsAndLocations(MetaTableAccessor.java:575)
> at
> org.apache.hadoop.hbase.regionserver.TestRegionMergeTransactionOnCluster.waitAndVerifyRegionNum(TestRegionMergeTransactionOnCluster.java:426)
> at
> org.apache.hadoop.hbase.regionserver.TestRegionMergeTransactionOnCluster.mergeRegionsAndVerifyRegionNum(TestRegionMergeTransactionOnCluster.java:402)
> at
> org.apache.hadoop.hbase.regionserver.TestRegionMergeTransactionOnCluster.testWholesomeMerge(TestRegionMergeTransactionOnCluster.java:139)
> {code|
> Everywhere we rely on master connection being up. Instead try using the test
> Connection ... see how that does. Add timeouts on this flakey test too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15240) Go Big BucketCache Fixes
[ https://issues.apache.org/jira/browse/HBASE-15240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160265#comment-15160265 ] stack commented on HBASE-15240: --- bq. Where Bucket cache will operate both on offheap and file mode? What you thinking [~ram_krish] We'd have to copy between tiers dependent on hotness. Thats hard. I think point of this issue is being able to go big; fast cache warming, being able to use all installed SSDs for cache, etc. Tiering would be orthogonal, another effort? > Go Big BucketCache Fixes > > > Key: HBASE-15240 > URL: https://issues.apache.org/jira/browse/HBASE-15240 > Project: HBase > Issue Type: Umbrella > Components: BucketCache >Reporter: stack >Assignee: stack > Attachments: Screen Shot 2016-02-10 at 6.27.26 AM.png > > > Umbrella issue to which we will attach issues that prevent bucketcache going > big; there's a few. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15180) Reduce garbage created while reading Cells from Codec Decoder
[ https://issues.apache.org/jira/browse/HBASE-15180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160261#comment-15160261 ] Anoop Sam John commented on HBASE-15180: wdyt of the latest patch [~saint@gmail.com], [~enis] > Reduce garbage created while reading Cells from Codec Decoder > - > > Key: HBASE-15180 > URL: https://issues.apache.org/jira/browse/HBASE-15180 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Affects Versions: 0.98.0 >Reporter: Anoop Sam John >Assignee: Anoop Sam John > Fix For: 2.0.0 > > Attachments: HBASE-15180.patch, HBASE-15180_V2.patch, > HBASE-15180_V4.patch, HBASE-15180_V6.patch > > > In KeyValueDecoder#parseCell (Default Codec decoder) we use > KeyValueUtil#iscreate to read cells from the InputStream. Here we 1st create > a byte[] of length 4 and read the cell length and then an array of Cell's > length and read in cell bytes into it and create a KV. > Actually in server we read the reqs into a byte[] and CellScanner is created > on top of a ByteArrayInputStream on top of this. By default in write path, we > have MSLAB usage ON. So while adding Cells to memstore, we will copy the Cell > bytes to MSLAB memory chunks (default 2 MB size) and recreate Cells over that > bytes. So there is no issue if we create Cells over the RPC read byte[] > directly here in Decoder. No need for 2 byte[] creation and copy for every > Cell in request. > My plan is to make a Cell aware ByteArrayInputStream which can read Cells > directly from it. > Same Codec path is used in client side also. There better we can avoid this > direct Cell create and continue to do the copy to smaller byte[]s path. Plan > to introduce some thing like a CodecContext associated with every Codec > instance which can say the server/client context. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15181) A simple implementation of date based tiered compaction
[
https://issues.apache.org/jira/browse/HBASE-15181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160244#comment-15160244
]
Anoop Sam John commented on HBASE-15181:
Exclusion of large files wont exclude in btw files. We see a large file we
break there.
{code}
private ArrayList skipLargeFiles(ArrayList candidates,
boolean mayUseOffpeak) {
int pos = 0;
while (pos < candidates.size() && !candidates.get(pos).isReference()
&& (candidates.get(pos).getReader().length() >
comConf.getMaxCompactSize(mayUseOffpeak))) {
++pos;
}
if (pos > 0) {
LOG.debug("Some files are too large. Excluding " + pos
+ " files from compaction candidates");
candidates.subList(0, pos).clear();
}
return candidates;
}
{code}
Bulk load exclude excludes in btw bulk loaded files.
> A simple implementation of date based tiered compaction
> ---
>
> Key: HBASE-15181
> URL: https://issues.apache.org/jira/browse/HBASE-15181
> Project: HBase
> Issue Type: New Feature
> Components: Compaction
>Reporter: Clara Xiong
>Assignee: Clara Xiong
> Fix For: 2.0.0, 1.3.0, 0.98.19
>
> Attachments: HBASE-15181-v1.patch, HBASE-15181-v2.patch
>
>
> This is a simple implementation of date-based tiered compaction similar to
> Cassandra's for the following benefits:
> 1. Improve date-range-based scan by structuring store files in date-based
> tiered layout.
> 2. Reduce compaction overhead.
> 3. Improve TTL efficiency.
> Perfect fit for the use cases that:
> 1. has mostly date-based date write and scan and a focus on the most recent
> data.
> 2. never or rarely deletes data.
> Out-of-order writes are handled gracefully so the data will still get to the
> right store file for time-range-scan and re-compacton with existing store
> file in the same time window is handled by ExploringCompactionPolicy.
> Time range overlapping among store files is tolerated and the performance
> impact is minimized.
> Configuration can be set at hbase-site or overriden at per-table or
> per-column-famly level by hbase shell.
> Design spec is at
> https://docs.google.com/document/d/1_AmlNb2N8Us1xICsTeGDLKIqL6T-oHoRLZ323MG_uy8/edit?usp=sharing
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15181) A simple implementation of date based tiered compaction
[ https://issues.apache.org/jira/browse/HBASE-15181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160223#comment-15160223 ] Clara Xiong commented on HBASE-15181: - [~enis] Thank you for clarification. But my question was: right now, the default compaction policy may exclude bulkload file and large files by configuration. If a user turns either one on, some files will be excluded from compaction selection. That may result in compaction of non-contiguous files sorted by seqId. Will that not cause any MVCC issue? > A simple implementation of date based tiered compaction > --- > > Key: HBASE-15181 > URL: https://issues.apache.org/jira/browse/HBASE-15181 > Project: HBase > Issue Type: New Feature > Components: Compaction >Reporter: Clara Xiong >Assignee: Clara Xiong > Fix For: 2.0.0, 1.3.0, 0.98.19 > > Attachments: HBASE-15181-v1.patch, HBASE-15181-v2.patch > > > This is a simple implementation of date-based tiered compaction similar to > Cassandra's for the following benefits: > 1. Improve date-range-based scan by structuring store files in date-based > tiered layout. > 2. Reduce compaction overhead. > 3. Improve TTL efficiency. > Perfect fit for the use cases that: > 1. has mostly date-based date write and scan and a focus on the most recent > data. > 2. never or rarely deletes data. > Out-of-order writes are handled gracefully so the data will still get to the > right store file for time-range-scan and re-compacton with existing store > file in the same time window is handled by ExploringCompactionPolicy. > Time range overlapping among store files is tolerated and the performance > impact is minimized. > Configuration can be set at hbase-site or overriden at per-table or > per-column-famly level by hbase shell. > Design spec is at > https://docs.google.com/document/d/1_AmlNb2N8Us1xICsTeGDLKIqL6T-oHoRLZ323MG_uy8/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15243) Utilize the lowest seek value when all Filters in MUST_PASS_ONE FilterList return SEEK_NEXT_USING_HINT
[ https://issues.apache.org/jira/browse/HBASE-15243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160220#comment-15160220 ] Anoop Sam John commented on HBASE-15243: +1 for tests skipping WAL write. > Utilize the lowest seek value when all Filters in MUST_PASS_ONE FilterList > return SEEK_NEXT_USING_HINT > -- > > Key: HBASE-15243 > URL: https://issues.apache.org/jira/browse/HBASE-15243 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15243-v1.txt, HBASE-15243-v2.txt, > HBASE-15243-v3.txt, HBASE-15243-v4.txt, HBASE-15243-v5.txt, HBASE-15243-v6.txt > > > As Preston Koprivica pointed out at the tail of HBASE-4394, when all filters > in a MUST_PASS_ONE FilterList return a SEEK_USING_NEXT_HINT code, we should > return SEEK_NEXT_USING_HINT from the FilterList to utilize the lowest seek > value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15240) Go Big BucketCache Fixes
[ https://issues.apache.org/jira/browse/HBASE-15240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160217#comment-15160217 ] ramkrishna.s.vasudevan commented on HBASE-15240: Does it makes sense to add MultiTiered caching also into this as a subtask? Where Bucket cache will operate both on offheap and file mode? > Go Big BucketCache Fixes > > > Key: HBASE-15240 > URL: https://issues.apache.org/jira/browse/HBASE-15240 > Project: HBase > Issue Type: Umbrella > Components: BucketCache >Reporter: stack >Assignee: stack > Attachments: Screen Shot 2016-02-10 at 6.27.26 AM.png > > > Umbrella issue to which we will attach issues that prevent bucketcache going > big; there's a few. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15314) Allow more than one backing file in bucketcache
[ https://issues.apache.org/jira/browse/HBASE-15314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160211#comment-15160211 ] Anoop Sam John commented on HBASE-15314: Implement as another IOEngine (?) MultiFile > Allow more than one backing file in bucketcache > --- > > Key: HBASE-15314 > URL: https://issues.apache.org/jira/browse/HBASE-15314 > Project: HBase > Issue Type: Sub-task > Components: BucketCache >Reporter: stack > > Allow bucketcache use more than just one backing file: e.g. chassis has more > than one SSD in it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15016) StoreServices facility in Region
[
https://issues.apache.org/jira/browse/HBASE-15016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160210#comment-15160210
]
Anoop Sam John commented on HBASE-15016:
bq. method for debugging tests
bq.7873 public void throwException(String title, String regionName) {
Can we keep the scope as package level only? Such a public method looks bad.
+1
> StoreServices facility in Region
>
>
> Key: HBASE-15016
> URL: https://issues.apache.org/jira/browse/HBASE-15016
> Project: HBase
> Issue Type: Sub-task
>Reporter: Eshcar Hillel
>Assignee: Eshcar Hillel
> Attachments: HBASE-15016-V01.patch, HBASE-15016-V02.patch,
> HBASE-15016-V03 (1).patch, HBASE-15016-V03.patch, HBASE-15016-V04.patch,
> HBASE-15016-V05.patch, HBASE-15016-V05.patch, Regioncounters.pdf,
> suggestion.patch
>
>
> The default implementation of a memstore ensures that between two flushes the
> memstore size increases monotonically. Supporting new memstores that store
> data in different formats (specifically, compressed), or that allows to
> eliminate data redundancies in memory (e.g., via compaction), means that the
> size of the data stored in memory can decrease even between two flushes. This
> requires memstores to have access to facilities that manipulate region
> counters and synchronization.
> This subtasks introduces a new region interface -- StoreServices, through
> which store components can access these facilities.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15318) Zk-less region server state management
[ https://issues.apache.org/jira/browse/HBASE-15318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160206#comment-15160206 ] stack commented on HBASE-15318: --- Thanks for filing the issue [~java8964] There is an on going project to purge zk from assignment. See such as HBASE-14350. Thanks. > Zk-less region server state management > -- > > Key: HBASE-15318 > URL: https://issues.apache.org/jira/browse/HBASE-15318 > Project: HBase > Issue Type: Improvement >Reporter: Yong Zhang >Assignee: Yong Zhang > > Current region server state is managed via znode created by region server, > master just listen these nodes. but we find many user network issue is not > network disconnected but package lost, which is hard to capture because > connection between region server and zk is fine. > This jira goal is region server state is managed by master without shared > info in zk, via enhancement heartbeat from region server to master. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-9393) Hbase does not closing a closed socket resulting in many CLOSE_WAIT
[ https://issues.apache.org/jira/browse/HBASE-9393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160204#comment-15160204 ] Sean Busbey commented on HBASE-9393: Ah. next time I'll try to read more of the background. :) That part makes sense now. > Hbase does not closing a closed socket resulting in many CLOSE_WAIT > > > Key: HBASE-9393 > URL: https://issues.apache.org/jira/browse/HBASE-9393 > Project: HBase > Issue Type: Bug >Affects Versions: 0.94.2, 0.98.0 > Environment: Centos 6.4 - 7 regionservers/datanodes, 8 TB per node, > 7279 regions >Reporter: Avi Zrachya >Assignee: Ashish Singhi >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-9393.patch, HBASE-9393.v1.patch, > HBASE-9393.v10.patch, HBASE-9393.v11.patch, HBASE-9393.v12.patch, > HBASE-9393.v2.patch, HBASE-9393.v3.patch, HBASE-9393.v4.patch, > HBASE-9393.v5.patch, HBASE-9393.v5.patch, HBASE-9393.v5.patch, > HBASE-9393.v6.patch, HBASE-9393.v6.patch, HBASE-9393.v6.patch, > HBASE-9393.v7.patch, HBASE-9393.v8.patch, HBASE-9393.v9.patch > > > HBase dose not close a dead connection with the datanode. > This resulting in over 60K CLOSE_WAIT and at some point HBase can not connect > to the datanode because too many mapped sockets from one host to another on > the same port. > The example below is with low CLOSE_WAIT count because we had to restart > hbase to solve the porblem, later in time it will incease to 60-100K sockets > on CLOSE_WAIT > [root@hd2-region3 ~]# netstat -nap |grep CLOSE_WAIT |grep 21592 |wc -l > 13156 > [root@hd2-region3 ~]# ps -ef |grep 21592 > root 17255 17219 0 12:26 pts/000:00:00 grep 21592 > hbase21592 1 17 Aug29 ?03:29:06 > /usr/java/jdk1.6.0_26/bin/java -XX:OnOutOfMemoryError=kill -9 %p -Xmx8000m > -ea -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode > -Dhbase.log.dir=/var/log/hbase > -Dhbase.log.file=hbase-hbase-regionserver-hd2-region3.swnet.corp.log ... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15317) document release announcement template
[ https://issues.apache.org/jira/browse/HBASE-15317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160201#comment-15160201 ] Sean Busbey commented on HBASE-15317: - I personally like the idea of identifying ourselves in terms of the capabilities we provide rather than the systems that inspired our design or that we rely on for implementation details. > document release announcement template > -- > > Key: HBASE-15317 > URL: https://issues.apache.org/jira/browse/HBASE-15317 > Project: HBase > Issue Type: Improvement > Components: documentation >Reporter: Sean Busbey > > Our release docs should include a release announcement template for folks to > use (and suggested email lists to send to) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15243) Utilize the lowest seek value when all Filters in MUST_PASS_ONE FilterList return SEEK_NEXT_USING_HINT
[ https://issues.apache.org/jira/browse/HBASE-15243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-15243: --- Attachment: HBASE-15243-v6.txt > Utilize the lowest seek value when all Filters in MUST_PASS_ONE FilterList > return SEEK_NEXT_USING_HINT > -- > > Key: HBASE-15243 > URL: https://issues.apache.org/jira/browse/HBASE-15243 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15243-v1.txt, HBASE-15243-v2.txt, > HBASE-15243-v3.txt, HBASE-15243-v4.txt, HBASE-15243-v5.txt, HBASE-15243-v6.txt > > > As Preston Koprivica pointed out at the tail of HBASE-4394, when all filters > in a MUST_PASS_ONE FilterList return a SEEK_USING_NEXT_HINT code, we should > return SEEK_NEXT_USING_HINT from the FilterList to utilize the lowest seek > value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15243) Utilize the lowest seek value when all Filters in MUST_PASS_ONE FilterList return SEEK_NEXT_USING_HINT
[ https://issues.apache.org/jira/browse/HBASE-15243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160183#comment-15160183 ] Ted Yu commented on HBASE-15243: bq. No commentary on what the likes of this is about? Added comment in patch v6. Basically not all cases for Operator.MUST_PASS_ALL would return before exiting the for loop. So a guard is needed. bq. Can't piggy-back on an already running cluster? As you can see in the setup, block size is adjusted so that the specified number of rows would result in multiple blocks (8 for this test). I don't think the other Filter tests need this setup. bq. How long does the test run take? This was from QA run for patch v4: Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 79.131 sec - in org.apache.hadoop.hbase.filter.TestFilterListOrOperatorWithBlkCnt This was from QA run for patch v5: Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 15.82 sec - in org.apache.hadoop.hbase.filter.TestFilterListOrOperatorWithBlkCnt > Utilize the lowest seek value when all Filters in MUST_PASS_ONE FilterList > return SEEK_NEXT_USING_HINT > -- > > Key: HBASE-15243 > URL: https://issues.apache.org/jira/browse/HBASE-15243 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15243-v1.txt, HBASE-15243-v2.txt, > HBASE-15243-v3.txt, HBASE-15243-v4.txt, HBASE-15243-v5.txt > > > As Preston Koprivica pointed out at the tail of HBASE-4394, when all filters > in a MUST_PASS_ONE FilterList return a SEEK_USING_NEXT_HINT code, we should > return SEEK_NEXT_USING_HINT from the FilterList to utilize the lowest seek > value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15136) Explore different queuing behaviors while busy
[
https://issues.apache.org/jira/browse/HBASE-15136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160184#comment-15160184
]
Hadoop QA commented on HBASE-15136:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
51s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 3s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 11s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 5m
58s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
45s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
16s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 55s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 13s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m 11s
{color} | {color:red} hbase-hadoop2-compat in the patch failed. {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 2s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 2s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 11s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 11s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 3m 59s
{color} | {color:red} Patch generated 1 new checkstyle issues in hbase-server
(total was 15, now 16). {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
46s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
23m 49s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 2m 2s
{color} | {color:red} hbase-server introduced 1 new FindBugs issues. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 59s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 14s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 33s
{color} | {color:green} hbase-common in the patch passed with JDK v1.8.0_72.
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 17s
{color} | {color:green} hbase-hadoop2-compat in the patch passed with JDK
v1.8.0_72. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 14s
{color} | {color:green} hbase-hadoop-compat in the patch passed with JDK
v1.8.0_72. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 81m 8s
{color} | {color:green} hbase-server in the patch passed with JDK v1.8.0_72.
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 49s
{color} | {color:green} hbase-common in the patch passed with JDK v1.7.0_95.
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 26s
{color} | {color:green} hbase-hadoop2-compat in the patch passed with JDK
v1.7.0_95. {color} |
| {color:green}+1{color} | {color:green} unit {color}
[jira] [Commented] (HBASE-15016) StoreServices facility in Region
[ https://issues.apache.org/jira/browse/HBASE-15016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160179#comment-15160179 ] stack commented on HBASE-15016: --- +1 on patch. Waiting on hadoopqa to come back. > StoreServices facility in Region > > > Key: HBASE-15016 > URL: https://issues.apache.org/jira/browse/HBASE-15016 > Project: HBase > Issue Type: Sub-task >Reporter: Eshcar Hillel >Assignee: Eshcar Hillel > Attachments: HBASE-15016-V01.patch, HBASE-15016-V02.patch, > HBASE-15016-V03 (1).patch, HBASE-15016-V03.patch, HBASE-15016-V04.patch, > HBASE-15016-V05.patch, HBASE-15016-V05.patch, Regioncounters.pdf, > suggestion.patch > > > The default implementation of a memstore ensures that between two flushes the > memstore size increases monotonically. Supporting new memstores that store > data in different formats (specifically, compressed), or that allows to > eliminate data redundancies in memory (e.g., via compaction), means that the > size of the data stored in memory can decrease even between two flushes. This > requires memstores to have access to facilities that manipulate region > counters and synchronization. > This subtasks introduces a new region interface -- StoreServices, through > which store components can access these facilities. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15016) StoreServices facility in Region
[ https://issues.apache.org/jira/browse/HBASE-15016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-15016: -- Attachment: HBASE-15016-V05.patch Uploaded wrong version .Here is v5. > StoreServices facility in Region > > > Key: HBASE-15016 > URL: https://issues.apache.org/jira/browse/HBASE-15016 > Project: HBase > Issue Type: Sub-task >Reporter: Eshcar Hillel >Assignee: Eshcar Hillel > Attachments: HBASE-15016-V01.patch, HBASE-15016-V02.patch, > HBASE-15016-V03 (1).patch, HBASE-15016-V03.patch, HBASE-15016-V04.patch, > HBASE-15016-V05.patch, HBASE-15016-V05.patch, Regioncounters.pdf, > suggestion.patch > > > The default implementation of a memstore ensures that between two flushes the > memstore size increases monotonically. Supporting new memstores that store > data in different formats (specifically, compressed), or that allows to > eliminate data redundancies in memory (e.g., via compaction), means that the > size of the data stored in memory can decrease even between two flushes. This > requires memstores to have access to facilities that manipulate region > counters and synchronization. > This subtasks introduces a new region interface -- StoreServices, through > which store components can access these facilities. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15317) document release announcement template
[ https://issues.apache.org/jira/browse/HBASE-15317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160175#comment-15160175 ] stack commented on HBASE-15317: --- Nice [~busbey] You've modified our lead off sentences on hbase.org. We should update there too? > document release announcement template > -- > > Key: HBASE-15317 > URL: https://issues.apache.org/jira/browse/HBASE-15317 > Project: HBase > Issue Type: Improvement > Components: documentation >Reporter: Sean Busbey > > Our release docs should include a release announcement template for folks to > use (and suggested email lists to send to) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15016) StoreServices facility in Region
[ https://issues.apache.org/jira/browse/HBASE-15016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-15016: -- Attachment: HBASE-15016-V03 (1).patch Retry to see if failures related. > StoreServices facility in Region > > > Key: HBASE-15016 > URL: https://issues.apache.org/jira/browse/HBASE-15016 > Project: HBase > Issue Type: Sub-task >Reporter: Eshcar Hillel >Assignee: Eshcar Hillel > Attachments: HBASE-15016-V01.patch, HBASE-15016-V02.patch, > HBASE-15016-V03 (1).patch, HBASE-15016-V03.patch, HBASE-15016-V04.patch, > HBASE-15016-V05.patch, Regioncounters.pdf, suggestion.patch > > > The default implementation of a memstore ensures that between two flushes the > memstore size increases monotonically. Supporting new memstores that store > data in different formats (specifically, compressed), or that allows to > eliminate data redundancies in memory (e.g., via compaction), means that the > size of the data stored in memory can decrease even between two flushes. This > requires memstores to have access to facilities that manipulate region > counters and synchronization. > This subtasks introduces a new region interface -- StoreServices, through > which store components can access these facilities. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15290) Hbase Rest CheckAndAPI should save other cells along with compared cell
[ https://issues.apache.org/jira/browse/HBASE-15290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160174#comment-15160174 ] Enis Soztutar commented on HBASE-15290: --- Yes, the Java API contract (as in Table.checkAndDelete) receives a Delete object, where the Delete() instance can be only for a row, cf or column. Just checked the code. I think there are at least two problems here: - RemoteHTable.checkAndDelete() does not send all the cells that is in the Delete to the REST API call. We can fix this here or some follow up jira since this is existing behavior. - RowResource.checkAndDelete() also does not honor the cells in the RowModel. Actually, it will only check and delete a single cell. > Hbase Rest CheckAndAPI should save other cells along with compared cell > --- > > Key: HBASE-15290 > URL: https://issues.apache.org/jira/browse/HBASE-15290 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 1.1.1 > Environment: Linux and windows >Reporter: Ajith > Labels: easyfix > Attachments: HBASE-15290-checkAndPut.patch, > HBASE-15290-checkAndPut_Comments.patch, checkputfix2.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > Java CheckAndPut API allows users to save Cells (C1..C5) while comparing a > Cell C1. > But in Rest API, even though caller sent multiple cells, hbase rest code is > ignoring all the cells except for compare cell. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15243) Utilize the lowest seek value when all Filters in MUST_PASS_ONE FilterList return SEEK_NEXT_USING_HINT
[
https://issues.apache.org/jira/browse/HBASE-15243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160172#comment-15160172
]
stack commented on HBASE-15243:
---
No commentary on what the likes of this is about?
if (operator == Operator.MUST_PASS_ONE && !seenNonHintReturnCode) {
We have to spin up a cluster just to do this test? Can't piggy-back on an
already running cluster? We've tried to avoid being HDFS where you spin up a
cluster per test.
bq. Patch v5 uses Durability.SKIP_WAL to speed up the test.
Why. How long does the test run take?
> Utilize the lowest seek value when all Filters in MUST_PASS_ONE FilterList
> return SEEK_NEXT_USING_HINT
> --
>
> Key: HBASE-15243
> URL: https://issues.apache.org/jira/browse/HBASE-15243
> Project: HBase
> Issue Type: Improvement
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-15243-v1.txt, HBASE-15243-v2.txt,
> HBASE-15243-v3.txt, HBASE-15243-v4.txt, HBASE-15243-v5.txt
>
>
> As Preston Koprivica pointed out at the tail of HBASE-4394, when all filters
> in a MUST_PASS_ONE FilterList return a SEEK_USING_NEXT_HINT code, we should
> return SEEK_NEXT_USING_HINT from the FilterList to utilize the lowest seek
> value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15312) Update the dependences of pom for mini cluster in HBase Book
[ https://issues.apache.org/jira/browse/HBASE-15312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160168#comment-15160168 ] Appy commented on HBASE-15312: -- Yup. If it works for [~liushaohui], all good. Ideally, we would like be fix our hbase-server's pom to make it easy such that if someone wants to use HBTU, they simply need to include hbase-server's test-jar instead of having to figure out this magic. [~liushaohui], if you are a master of dependencies and if above task is possible, would you like to fix it in a followup jira? > Update the dependences of pom for mini cluster in HBase Book > > > Key: HBASE-15312 > URL: https://issues.apache.org/jira/browse/HBASE-15312 > Project: HBase > Issue Type: Improvement > Components: documentation >Reporter: Liu Shaohui >Assignee: Liu Shaohui >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-15312-trunk-v1.diff > > > In HBase book, the dependences of pom for mini cluster is outdated after > version 0.96. > See: > http://hbase.apache.org/book.html#_integration_testing_with_an_hbase_mini_cluster -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15187) Integrate CSRF prevention filter to REST gateway
[
https://issues.apache.org/jira/browse/HBASE-15187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160167#comment-15160167
]
stack commented on HBASE-15187:
---
Thanks [~jerryhe] for keeping eye on Ted antics ("It takes a village...").
Why are we bringing in this filter [~ted_yu]? [~ashish singhi] just added a
whole frame work over in HBASE-15122 for taking care of this sort of intrusion.
Why does the REST gateway get the treatment and other servlets do not?
> Integrate CSRF prevention filter to REST gateway
>
>
> Key: HBASE-15187
> URL: https://issues.apache.org/jira/browse/HBASE-15187
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: HBASE-15187.v1.patch, HBASE-15187.v2.patch,
> HBASE-15187.v3.patch, HBASE-15187.v4.patch, HBASE-15187.v5.patch,
> HBASE-15187.v6.patch, HBASE-15187.v7.patch, HBASE-15187.v8.patch
>
>
> HADOOP-12691 introduced a filter in Hadoop Common to help REST APIs guard
> against cross-site request forgery attacks.
> This issue tracks the integration of that filter into HBase REST gateway.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15264) Implement a fan out HDFS OutputStream
[ https://issues.apache.org/jira/browse/HBASE-15264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160164#comment-15160164 ] stack commented on HBASE-15264: --- Ugh. Forget what i said about checkstyle. I forgot what the errors were. Ignore. > Implement a fan out HDFS OutputStream > - > > Key: HBASE-15264 > URL: https://issues.apache.org/jira/browse/HBASE-15264 > Project: HBase > Issue Type: Sub-task > Components: util, wal >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0 > > Attachments: HBASE-15264-v1.patch, HBASE-15264-v2.patch, > HBASE-15264-v3.patch, HBASE-15264-v4.patch, HBASE-15264-v5.patch, > HBASE-15264-v6.patch, HBASE-15264-v7.patch, HBASE-15264-v8.patch, > HBASE-15264.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15184) SparkSQL Scan operation doesn't work on kerberos cluster
[ https://issues.apache.org/jira/browse/HBASE-15184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160163#comment-15160163 ] Hudson commented on HBASE-15184: FAILURE: Integrated in HBase-Trunk_matrix #732 (See [https://builds.apache.org/job/HBase-Trunk_matrix/732/]) HBASE-15184 SparkSQL Scan operation doesn't work on kerberos cluster (tedyu: rev 00248656ee9c60009ff1697e90ba9d0f86264103) * hbase-spark/src/main/scala/org/apache/hadoop/hbase/spark/DefaultSource.scala * hbase-spark/src/main/scala/org/apache/hadoop/hbase/spark/NewHBaseRDD.scala * hbase-spark/src/main/scala/org/apache/hadoop/hbase/spark/HBaseContext.scala * hbase-spark/src/main/scala/org/apache/hadoop/hbase/spark/datasources/HBaseTableScanRDD.scala > SparkSQL Scan operation doesn't work on kerberos cluster > > > Key: HBASE-15184 > URL: https://issues.apache.org/jira/browse/HBASE-15184 > Project: HBase > Issue Type: Bug > Components: spark >Reporter: Ted Malaska >Assignee: Ted Malaska >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-15184.1.patch, HBaseSparkModule.zip > > > I was using the HBase Spark Module at a client with Kerberos and I ran into > an issue with the Scan. > I made a fix for the client but we need to put it back into HBase. I will > attach my solution, but it has a major problem. I had to over ride a > protected class in spark. I will need help to decover a better approach -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15306) Make RPC call queue length dynamically configurable
[ https://issues.apache.org/jira/browse/HBASE-15306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160162#comment-15160162 ] Hudson commented on HBASE-15306: FAILURE: Integrated in HBase-Trunk_matrix #732 (See [https://builds.apache.org/job/HBase-Trunk_matrix/732/]) HBASE-15306 Make RPC call queue length dynamically configurable (antonov: rev f47dba74d498d5d39f124ad8ea5723c437acbc85) * hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/RpcServer.java * hbase-server/src/test/java/org/apache/hadoop/hbase/ipc/TestSimpleRpcScheduler.java * hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/RWQueueRpcExecutor.java * hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/RpcExecutor.java * hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/SimpleRpcScheduler.java * hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/BalancedQueueRpcExecutor.java > Make RPC call queue length dynamically configurable > --- > > Key: HBASE-15306 > URL: https://issues.apache.org/jira/browse/HBASE-15306 > Project: HBase > Issue Type: Improvement > Components: IPC/RPC >Affects Versions: 1.2.0 >Reporter: Mikhail Antonov >Assignee: Mikhail Antonov > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15306-v1.patch, HBASE-15306-v2.patch, > HBASE-15306-v3.patch > > > Sometimes it's useful to be able to modify call queue size on prod cluster > without having to do a rolling restart. > Here setting fixed hard limit on call queue size and soft limit which is > dynamically-updatable. > https://reviews.facebook.net/D54579 for review, will test more. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15312) Update the dependences of pom for mini cluster in HBase Book
[ https://issues.apache.org/jira/browse/HBASE-15312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160161#comment-15160161 ] stack commented on HBASE-15312: --- Thank you for working on this [~liushaohui] Patch LGTM. Good by you [~appy]? > Update the dependences of pom for mini cluster in HBase Book > > > Key: HBASE-15312 > URL: https://issues.apache.org/jira/browse/HBASE-15312 > Project: HBase > Issue Type: Improvement > Components: documentation >Reporter: Liu Shaohui >Assignee: Liu Shaohui >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-15312-trunk-v1.diff > > > In HBase book, the dependences of pom for mini cluster is outdated after > version 0.96. > See: > http://hbase.apache.org/book.html#_integration_testing_with_an_hbase_mini_cluster -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-9393) Hbase does not closing a closed socket resulting in many CLOSE_WAIT
[ https://issues.apache.org/jira/browse/HBASE-9393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160159#comment-15160159 ] stack commented on HBASE-9393: -- [~busbey] The method rename was done at my suggestion. If you read what the method does, previous name made no sense. > Hbase does not closing a closed socket resulting in many CLOSE_WAIT > > > Key: HBASE-9393 > URL: https://issues.apache.org/jira/browse/HBASE-9393 > Project: HBase > Issue Type: Bug >Affects Versions: 0.94.2, 0.98.0 > Environment: Centos 6.4 - 7 regionservers/datanodes, 8 TB per node, > 7279 regions >Reporter: Avi Zrachya >Assignee: Ashish Singhi >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-9393.patch, HBASE-9393.v1.patch, > HBASE-9393.v10.patch, HBASE-9393.v11.patch, HBASE-9393.v12.patch, > HBASE-9393.v2.patch, HBASE-9393.v3.patch, HBASE-9393.v4.patch, > HBASE-9393.v5.patch, HBASE-9393.v5.patch, HBASE-9393.v5.patch, > HBASE-9393.v6.patch, HBASE-9393.v6.patch, HBASE-9393.v6.patch, > HBASE-9393.v7.patch, HBASE-9393.v8.patch, HBASE-9393.v9.patch > > > HBase dose not close a dead connection with the datanode. > This resulting in over 60K CLOSE_WAIT and at some point HBase can not connect > to the datanode because too many mapped sockets from one host to another on > the same port. > The example below is with low CLOSE_WAIT count because we had to restart > hbase to solve the porblem, later in time it will incease to 60-100K sockets > on CLOSE_WAIT > [root@hd2-region3 ~]# netstat -nap |grep CLOSE_WAIT |grep 21592 |wc -l > 13156 > [root@hd2-region3 ~]# ps -ef |grep 21592 > root 17255 17219 0 12:26 pts/000:00:00 grep 21592 > hbase21592 1 17 Aug29 ?03:29:06 > /usr/java/jdk1.6.0_26/bin/java -XX:OnOutOfMemoryError=kill -9 %p -Xmx8000m > -ea -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode > -Dhbase.log.dir=/var/log/hbase > -Dhbase.log.file=hbase-hbase-regionserver-hd2-region3.swnet.corp.log ... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15306) Make RPC call queue length dynamically configurable
[ https://issues.apache.org/jira/browse/HBASE-15306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160142#comment-15160142 ] Hudson commented on HBASE-15306: SUCCESS: Integrated in HBase-1.3 #568 (See [https://builds.apache.org/job/HBase-1.3/568/]) HBASE-15306 Make RPC call queue length dynamically configurable (antonov: rev bcbe174a277998f1c7ea4035b2f2d91e7757bc66) * hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/BalancedQueueRpcExecutor.java * hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/RpcServer.java * hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/SimpleRpcScheduler.java * hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/RpcExecutor.java * hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/RWQueueRpcExecutor.java * hbase-server/src/test/java/org/apache/hadoop/hbase/ipc/TestSimpleRpcScheduler.java > Make RPC call queue length dynamically configurable > --- > > Key: HBASE-15306 > URL: https://issues.apache.org/jira/browse/HBASE-15306 > Project: HBase > Issue Type: Improvement > Components: IPC/RPC >Affects Versions: 1.2.0 >Reporter: Mikhail Antonov >Assignee: Mikhail Antonov > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15306-v1.patch, HBASE-15306-v2.patch, > HBASE-15306-v3.patch > > > Sometimes it's useful to be able to modify call queue size on prod cluster > without having to do a rolling restart. > Here setting fixed hard limit on call queue size and soft limit which is > dynamically-updatable. > https://reviews.facebook.net/D54579 for review, will test more. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15290) Hbase Rest CheckAndAPI should save other cells along with compared cell
[
https://issues.apache.org/jira/browse/HBASE-15290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ajith updated HBASE-15290:
--
Attachment: HBASE-15290-checkAndPut_Comments.patch
Addressed the { coding style comments
> Hbase Rest CheckAndAPI should save other cells along with compared cell
> ---
>
> Key: HBASE-15290
> URL: https://issues.apache.org/jira/browse/HBASE-15290
> Project: HBase
> Issue Type: Bug
> Components: hbase
>Affects Versions: 1.1.1
> Environment: Linux and windows
>Reporter: Ajith
> Labels: easyfix
> Attachments: HBASE-15290-checkAndPut.patch,
> HBASE-15290-checkAndPut_Comments.patch, checkputfix2.patch
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> Java CheckAndPut API allows users to save Cells (C1..C5) while comparing a
> Cell C1.
> But in Rest API, even though caller sent multiple cells, hbase rest code is
> ignoring all the cells except for compare cell.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15181) A simple implementation of date based tiered compaction
[ https://issues.apache.org/jira/browse/HBASE-15181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160139#comment-15160139 ] Enis Soztutar commented on HBASE-15181: --- bq. But I want to add a tweak to this proposal on how to handle late-arriving data. I want to compact the out-of-order data with newer files other than older ones. We are using the maxTs to select the tier, rather than minTs, so this is already true? bq. We have observed drastic IO reduction for the scans. Great. This will be a nice addition to HBase. Let me look at the patch. bq. I am wondering how we have maintained mvcc with Ratio-basedCompactionPolicy and its derived class ExploringCompactonPolicy when we allow filtering bulk-load and skip large files? We are assigning (bulk load) a seqId to the bulk loaded files at the time of the bulk load. We execute a flush beforehand to make sure that the sequenceId that is assigned is not overlapping with the in-memory data's sequenceIds. We have a store-level read/write lock that coordinates bulk load files and file selection for compaction. Is this what you were asking for? > A simple implementation of date based tiered compaction > --- > > Key: HBASE-15181 > URL: https://issues.apache.org/jira/browse/HBASE-15181 > Project: HBase > Issue Type: New Feature > Components: Compaction >Reporter: Clara Xiong >Assignee: Clara Xiong > Fix For: 2.0.0, 1.3.0, 0.98.19 > > Attachments: HBASE-15181-v1.patch, HBASE-15181-v2.patch > > > This is a simple implementation of date-based tiered compaction similar to > Cassandra's for the following benefits: > 1. Improve date-range-based scan by structuring store files in date-based > tiered layout. > 2. Reduce compaction overhead. > 3. Improve TTL efficiency. > Perfect fit for the use cases that: > 1. has mostly date-based date write and scan and a focus on the most recent > data. > 2. never or rarely deletes data. > Out-of-order writes are handled gracefully so the data will still get to the > right store file for time-range-scan and re-compacton with existing store > file in the same time window is handled by ExploringCompactionPolicy. > Time range overlapping among store files is tolerated and the performance > impact is minimized. > Configuration can be set at hbase-site or overriden at per-table or > per-column-famly level by hbase shell. > Design spec is at > https://docs.google.com/document/d/1_AmlNb2N8Us1xICsTeGDLKIqL6T-oHoRLZ323MG_uy8/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-9393) Hbase does not closing a closed socket resulting in many CLOSE_WAIT
[
https://issues.apache.org/jira/browse/HBASE-9393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160137#comment-15160137
]
Sean Busbey commented on HBASE-9393:
{code}
- private static Reader pickReaderVersion(Path path, FSDataInputStreamWrapper
fsdis,
- long size, CacheConfig cacheConf, HFileSystem hfs, Configuration conf)
throws IOException {
+ private static Reader openReader(Path path, FSDataInputStreamWrapper fsdis,
long size,
+ CacheConfig cacheConf, HFileSystem hfs, Configuration conf) throws
IOException {
{code}
Why the method rename?
> Hbase does not closing a closed socket resulting in many CLOSE_WAIT
>
>
> Key: HBASE-9393
> URL: https://issues.apache.org/jira/browse/HBASE-9393
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.2, 0.98.0
> Environment: Centos 6.4 - 7 regionservers/datanodes, 8 TB per node,
> 7279 regions
>Reporter: Avi Zrachya
>Assignee: Ashish Singhi
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-9393.patch, HBASE-9393.v1.patch,
> HBASE-9393.v10.patch, HBASE-9393.v11.patch, HBASE-9393.v12.patch,
> HBASE-9393.v2.patch, HBASE-9393.v3.patch, HBASE-9393.v4.patch,
> HBASE-9393.v5.patch, HBASE-9393.v5.patch, HBASE-9393.v5.patch,
> HBASE-9393.v6.patch, HBASE-9393.v6.patch, HBASE-9393.v6.patch,
> HBASE-9393.v7.patch, HBASE-9393.v8.patch, HBASE-9393.v9.patch
>
>
> HBase dose not close a dead connection with the datanode.
> This resulting in over 60K CLOSE_WAIT and at some point HBase can not connect
> to the datanode because too many mapped sockets from one host to another on
> the same port.
> The example below is with low CLOSE_WAIT count because we had to restart
> hbase to solve the porblem, later in time it will incease to 60-100K sockets
> on CLOSE_WAIT
> [root@hd2-region3 ~]# netstat -nap |grep CLOSE_WAIT |grep 21592 |wc -l
> 13156
> [root@hd2-region3 ~]# ps -ef |grep 21592
> root 17255 17219 0 12:26 pts/000:00:00 grep 21592
> hbase21592 1 17 Aug29 ?03:29:06
> /usr/java/jdk1.6.0_26/bin/java -XX:OnOutOfMemoryError=kill -9 %p -Xmx8000m
> -ea -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode
> -Dhbase.log.dir=/var/log/hbase
> -Dhbase.log.file=hbase-hbase-regionserver-hd2-region3.swnet.corp.log ...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-9393) Hbase does not closing a closed socket resulting in many CLOSE_WAIT
[
https://issues.apache.org/jira/browse/HBASE-9393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160133#comment-15160133
]
Sean Busbey commented on HBASE-9393:
Several of your log messages are at ERROR but they don't give an operator any
idea about what to do next. No info on finding a root cause, something to
correct, or get more information. Could we add some of that kind of information
or change them to be INFO or WARN?
{code}
+ private static void setInstanceOfCanUnbuffer(boolean instanceOfCanUnbuffer) {
+FSDataInputStreamWrapper.instanceOfCanUnbuffer = instanceOfCanUnbuffer;
+ }
+
+ private static void setUnbufferMethod(Method unbuffer) {
+FSDataInputStreamWrapper.unbuffer = unbuffer;
+ }
{code}
Why are we making these assignments indirectly via methods?
{code}
+ if (FSDataInputStreamWrapper.instanceOfCanUnbuffer == null) {
+// To ensure we compute whether the stream is instance of CanUnbuffer
only once.
+FSDataInputStreamWrapper.setInstanceOfCanUnbuffer(false);
+Class[] streamInterfaces = streamClass.getInterfaces();
+for (Class c : streamInterfaces) {
+ if
(c.getCanonicalName().toString().equals("org.apache.hadoop.fs.CanUnbuffer")) {
+try {
+
FSDataInputStreamWrapper.setUnbufferMethod(streamClass.getDeclaredMethod("unbuffer"));
+} catch (Exception e) {
+ LOG.error("Failed to find 'unbuffer' method in class " +
streamClass, e);
+ return;
+}
+FSDataInputStreamWrapper.setInstanceOfCanUnbuffer(true);
+break;
+ }
+}
+ }
{code}
This doesn't look like it will behave correctly in presence of concurrency. Can
we do the reflection set up during a static initializer?
{code}
+ if (FSDataInputStreamWrapper.instanceOfCanUnbuffer) {
+try {
+ FSDataInputStreamWrapper.unbuffer.invoke(wrappedStream);
+} catch (Exception e) {
+ LOG.error("Failed to unbuffer the stream so possibly there may be a
TCP socket "
+ + "connection left open in CLOSE_WAIT state for this
RegionServer.", e);
+}
+ }
{code}
This should probably have an else clause that similarly gives the warning. In
that case, it should probably give a pointer to this issue.
> Hbase does not closing a closed socket resulting in many CLOSE_WAIT
>
>
> Key: HBASE-9393
> URL: https://issues.apache.org/jira/browse/HBASE-9393
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.2, 0.98.0
> Environment: Centos 6.4 - 7 regionservers/datanodes, 8 TB per node,
> 7279 regions
>Reporter: Avi Zrachya
>Assignee: Ashish Singhi
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-9393.patch, HBASE-9393.v1.patch,
> HBASE-9393.v10.patch, HBASE-9393.v11.patch, HBASE-9393.v12.patch,
> HBASE-9393.v2.patch, HBASE-9393.v3.patch, HBASE-9393.v4.patch,
> HBASE-9393.v5.patch, HBASE-9393.v5.patch, HBASE-9393.v5.patch,
> HBASE-9393.v6.patch, HBASE-9393.v6.patch, HBASE-9393.v6.patch,
> HBASE-9393.v7.patch, HBASE-9393.v8.patch, HBASE-9393.v9.patch
>
>
> HBase dose not close a dead connection with the datanode.
> This resulting in over 60K CLOSE_WAIT and at some point HBase can not connect
> to the datanode because too many mapped sockets from one host to another on
> the same port.
> The example below is with low CLOSE_WAIT count because we had to restart
> hbase to solve the porblem, later in time it will incease to 60-100K sockets
> on CLOSE_WAIT
> [root@hd2-region3 ~]# netstat -nap |grep CLOSE_WAIT |grep 21592 |wc -l
> 13156
> [root@hd2-region3 ~]# ps -ef |grep 21592
> root 17255 17219 0 12:26 pts/000:00:00 grep 21592
> hbase21592 1 17 Aug29 ?03:29:06
> /usr/java/jdk1.6.0_26/bin/java -XX:OnOutOfMemoryError=kill -9 %p -Xmx8000m
> -ea -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode
> -Dhbase.log.dir=/var/log/hbase
> -Dhbase.log.file=hbase-hbase-regionserver-hd2-region3.swnet.corp.log ...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15290) Hbase Rest CheckAndAPI should save other cells along with compared cell
[ https://issues.apache.org/jira/browse/HBASE-15290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160131#comment-15160131 ] Ajith commented on HBASE-15290: --- In Java API one can specify the Delete object which can contain (Delete a Cell / ColumnFamily / Row with a version etc). But when it comes to rest, were you suggesting the Body to contain the Cell's information that need to be deleted based on the last cell check? If none is present then delete the complete row > Hbase Rest CheckAndAPI should save other cells along with compared cell > --- > > Key: HBASE-15290 > URL: https://issues.apache.org/jira/browse/HBASE-15290 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 1.1.1 > Environment: Linux and windows >Reporter: Ajith > Labels: easyfix > Attachments: HBASE-15290-checkAndPut.patch, checkputfix2.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > Java CheckAndPut API allows users to save Cells (C1..C5) while comparing a > Cell C1. > But in Rest API, even though caller sent multiple cells, hbase rest code is > ignoring all the cells except for compare cell. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15319) clearJmxCache does not take effect actually
Hao Lin created HBASE-15319:
---
Summary: clearJmxCache does not take effect actually
Key: HBASE-15319
URL: https://issues.apache.org/jira/browse/HBASE-15319
Project: HBase
Issue Type: Bug
Components: metrics
Affects Versions: 1.1.0.1
Reporter: Hao Lin
When trying to backport HBASE-14166 to 0.98.6, I find
JmxCacheBuster::clearJmxCache() does no take effect actually. The related code
are listed below:
{code:title=org.apache.hadoop.metrics2.impl.JmxCacheBuster.java|borderStyle=solid}
// fut is initialized to null
private static AtomicReference fut = new
AtomicReference<>(null);
public static void clearJmxCache() {
// clearJmxCache return directly when fut is null, which is always true.
// the actual intent is 'if (future != null && !future.isDone ...)' ?
ScheduledFuture future = fut.get();
if ((future == null || (!future.isDone() &&
future.getDelay(TimeUnit.MILLISECONDS) > 100))) {
return;
}
..
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15290) Hbase Rest CheckAndAPI should save other cells along with compared cell
[ https://issues.apache.org/jira/browse/HBASE-15290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160123#comment-15160123 ] Ajith commented on HBASE-15290: --- Enis, For CheckAndDelete, one can only delete the row right. Wondering why we need to consider all the put columns for check And Delete. > Hbase Rest CheckAndAPI should save other cells along with compared cell > --- > > Key: HBASE-15290 > URL: https://issues.apache.org/jira/browse/HBASE-15290 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 1.1.1 > Environment: Linux and windows >Reporter: Ajith > Labels: easyfix > Attachments: HBASE-15290-checkAndPut.patch, checkputfix2.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > Java CheckAndPut API allows users to save Cells (C1..C5) while comparing a > Cell C1. > But in Rest API, even though caller sent multiple cells, hbase rest code is > ignoring all the cells except for compare cell. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15290) Hbase Rest CheckAndAPI should save other cells along with compared cell
[ https://issues.apache.org/jira/browse/HBASE-15290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160122#comment-15160122 ] Enis Soztutar commented on HBASE-15290: --- Patch looks good, except that we have to do this for checkAndDelete as well. Also, please follow the hbase style in the code (spaces in between arguments, left curly bracket, etc). > Hbase Rest CheckAndAPI should save other cells along with compared cell > --- > > Key: HBASE-15290 > URL: https://issues.apache.org/jira/browse/HBASE-15290 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 1.1.1 > Environment: Linux and windows >Reporter: Ajith > Labels: easyfix > Attachments: HBASE-15290-checkAndPut.patch, checkputfix2.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > Java CheckAndPut API allows users to save Cells (C1..C5) while comparing a > Cell C1. > But in Rest API, even though caller sent multiple cells, hbase rest code is > ignoring all the cells except for compare cell. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15312) Update the dependences of pom for mini cluster in HBase Book
[
https://issues.apache.org/jira/browse/HBASE-15312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160082#comment-15160082
]
Liu Shaohui commented on HBASE-15312:
-
[~appy]
Thanks for your review~
{quote}
1. hbase-hadoop-compat is also a dependency in hbase-server/pom.xml. If it'll
always be included transitively, maybe remove it from here?
{quote}
Yes, hbase-hadoop-compat is also a dependency in hbase-server/pom.xml. But the
scope for test-jar of hbase-hadoop-compat is test, which will no be included
transitively.
{quote}
2. You are removing hadoop-hdfs' (non test-jar) from dependency, is it really
not needed?
{quote}
hadoop-hdfs is also a dependency in hbase-server/pom.xml and it be included
transitively.
> Update the dependences of pom for mini cluster in HBase Book
>
>
> Key: HBASE-15312
> URL: https://issues.apache.org/jira/browse/HBASE-15312
> Project: HBase
> Issue Type: Improvement
> Components: documentation
>Reporter: Liu Shaohui
>Assignee: Liu Shaohui
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-15312-trunk-v1.diff
>
>
> In HBase book, the dependences of pom for mini cluster is outdated after
> version 0.96.
> See:
> http://hbase.apache.org/book.html#_integration_testing_with_an_hbase_mini_cluster
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15264) Implement a fan out HDFS OutputStream
[ https://issues.apache.org/jira/browse/HBASE-15264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-15264: -- Attachment: HBASE-15264-v8.patch Fix the javadoc issue, but it will introduce a checkstyle issue(line too long)... > Implement a fan out HDFS OutputStream > - > > Key: HBASE-15264 > URL: https://issues.apache.org/jira/browse/HBASE-15264 > Project: HBase > Issue Type: Sub-task > Components: util, wal >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0 > > Attachments: HBASE-15264-v1.patch, HBASE-15264-v2.patch, > HBASE-15264-v3.patch, HBASE-15264-v4.patch, HBASE-15264-v5.patch, > HBASE-15264-v6.patch, HBASE-15264-v7.patch, HBASE-15264-v8.patch, > HBASE-15264.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15264) Implement a fan out HDFS OutputStream
[ https://issues.apache.org/jira/browse/HBASE-15264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160060#comment-15160060 ] Duo Zhang commented on HBASE-15264: --- Sure, I will fix the javadoc issue. For checkstyle, I could fix some. And for the wrong import order error, what is the suggested import order for HBase project? I just follow the eclipse rule... The UT failures are unrelated since I do not change the existing code... > Implement a fan out HDFS OutputStream > - > > Key: HBASE-15264 > URL: https://issues.apache.org/jira/browse/HBASE-15264 > Project: HBase > Issue Type: Sub-task > Components: util, wal >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0 > > Attachments: HBASE-15264-v1.patch, HBASE-15264-v2.patch, > HBASE-15264-v3.patch, HBASE-15264-v4.patch, HBASE-15264-v5.patch, > HBASE-15264-v6.patch, HBASE-15264-v7.patch, HBASE-15264.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15181) A simple implementation of date based tiered compaction
[ https://issues.apache.org/jira/browse/HBASE-15181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160057#comment-15160057 ] Ted Yu commented on HBASE-15181: Clara: Mind attaching your patch here for QA run ? > A simple implementation of date based tiered compaction > --- > > Key: HBASE-15181 > URL: https://issues.apache.org/jira/browse/HBASE-15181 > Project: HBase > Issue Type: New Feature > Components: Compaction >Reporter: Clara Xiong >Assignee: Clara Xiong > Fix For: 2.0.0, 1.3.0, 0.98.19 > > Attachments: HBASE-15181-v1.patch, HBASE-15181-v2.patch > > > This is a simple implementation of date-based tiered compaction similar to > Cassandra's for the following benefits: > 1. Improve date-range-based scan by structuring store files in date-based > tiered layout. > 2. Reduce compaction overhead. > 3. Improve TTL efficiency. > Perfect fit for the use cases that: > 1. has mostly date-based date write and scan and a focus on the most recent > data. > 2. never or rarely deletes data. > Out-of-order writes are handled gracefully so the data will still get to the > right store file for time-range-scan and re-compacton with existing store > file in the same time window is handled by ExploringCompactionPolicy. > Time range overlapping among store files is tolerated and the performance > impact is minimized. > Configuration can be set at hbase-site or overriden at per-table or > per-column-famly level by hbase shell. > Design spec is at > https://docs.google.com/document/d/1_AmlNb2N8Us1xICsTeGDLKIqL6T-oHoRLZ323MG_uy8/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15184) SparkSQL Scan operation doesn't work on kerberos cluster
[ https://issues.apache.org/jira/browse/HBASE-15184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160042#comment-15160042 ] Ted Yu commented on HBASE-15184: Sure. Thought you already addressed his comment :-) Anyway, if Ari's concern turns out not to be addressed, we can certainly apply addendum or revert. > SparkSQL Scan operation doesn't work on kerberos cluster > > > Key: HBASE-15184 > URL: https://issues.apache.org/jira/browse/HBASE-15184 > Project: HBase > Issue Type: Bug > Components: spark >Reporter: Ted Malaska >Assignee: Ted Malaska >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-15184.1.patch, HBaseSparkModule.zip > > > I was using the HBase Spark Module at a client with Kerberos and I ran into > an issue with the Scan. > I made a fix for the client but we need to put it back into HBase. I will > attach my solution, but it has a major problem. I had to over ride a > protected class in spark. I will need help to decover a better approach -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15181) A simple implementation of date based tiered compaction
[ https://issues.apache.org/jira/browse/HBASE-15181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160026#comment-15160026 ] Clara Xiong commented on HBASE-15181: - I updated the design spec and uploaded the new patch at https://reviews.apache.org/r/43114/. Major changes: 1. sort by seq id. A new test was added. 2. handling future data. A new test was added. 3. other CR feedbacks > A simple implementation of date based tiered compaction > --- > > Key: HBASE-15181 > URL: https://issues.apache.org/jira/browse/HBASE-15181 > Project: HBase > Issue Type: New Feature > Components: Compaction >Reporter: Clara Xiong >Assignee: Clara Xiong > Fix For: 2.0.0, 1.3.0, 0.98.19 > > Attachments: HBASE-15181-v1.patch, HBASE-15181-v2.patch > > > This is a simple implementation of date-based tiered compaction similar to > Cassandra's for the following benefits: > 1. Improve date-range-based scan by structuring store files in date-based > tiered layout. > 2. Reduce compaction overhead. > 3. Improve TTL efficiency. > Perfect fit for the use cases that: > 1. has mostly date-based date write and scan and a focus on the most recent > data. > 2. never or rarely deletes data. > Out-of-order writes are handled gracefully so the data will still get to the > right store file for time-range-scan and re-compacton with existing store > file in the same time window is handled by ExploringCompactionPolicy. > Time range overlapping among store files is tolerated and the performance > impact is minimized. > Configuration can be set at hbase-site or overriden at per-table or > per-column-famly level by hbase shell. > Design spec is at > https://docs.google.com/document/d/1_AmlNb2N8Us1xICsTeGDLKIqL6T-oHoRLZ323MG_uy8/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15318) Zk-less region server state management
Yong Zhang created HBASE-15318: -- Summary: Zk-less region server state management Key: HBASE-15318 URL: https://issues.apache.org/jira/browse/HBASE-15318 Project: HBase Issue Type: Improvement Reporter: Yong Zhang Assignee: Yong Zhang Current region server state is managed via znode created by region server, master just listen these nodes. but we find many user network issue is not network disconnected but package lost, which is hard to capture because connection between region server and zk is fine. This jira goal is region server state is managed by master without shared info in zk, via enhancement heartbeat from region server to master. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15136) Explore different queuing behaviors while busy
[ https://issues.apache.org/jira/browse/HBASE-15136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160016#comment-15160016 ] Mikhail Antonov commented on HBASE-15136: - The command '/bin/sh -c add-apt-repository -y ppa:webupd8team/java' returned a non-zero code: 1 > Explore different queuing behaviors while busy > -- > > Key: HBASE-15136 > URL: https://issues.apache.org/jira/browse/HBASE-15136 > Project: HBase > Issue Type: New Feature > Components: IPC/RPC >Reporter: Elliott Clark >Assignee: Mikhail Antonov > Attachments: HBASE-15136-1.2.v1.patch, HBASE-15136-v2.patch, > deadline_scheduler_v_0_2.patch > > > http://queue.acm.org/detail.cfm?id=2839461 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15136) Explore different queuing behaviors while busy
[
https://issues.apache.org/jira/browse/HBASE-15136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160015#comment-15160015
]
Hadoop QA commented on HBASE-15136:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:red}-1{color} | {color:red} docker {color} | {color:red} 0m 2s {color}
| {color:red} Docker failed to build yetus/hbase:date2016-02-24. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12789351/HBASE-15136-v2.patch |
| JIRA Issue | HBASE-15136 |
| Powered by | Apache Yetus 0.2.0-SNAPSHOT http://yetus.apache.org |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/661/console |
This message was automatically generated.
> Explore different queuing behaviors while busy
> --
>
> Key: HBASE-15136
> URL: https://issues.apache.org/jira/browse/HBASE-15136
> Project: HBase
> Issue Type: New Feature
> Components: IPC/RPC
>Reporter: Elliott Clark
>Assignee: Mikhail Antonov
> Attachments: HBASE-15136-1.2.v1.patch, HBASE-15136-v2.patch,
> deadline_scheduler_v_0_2.patch
>
>
> http://queue.acm.org/detail.cfm?id=2839461
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15136) Explore different queuing behaviors while busy
[
https://issues.apache.org/jira/browse/HBASE-15136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160010#comment-15160010
]
Hadoop QA commented on HBASE-15136:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:red}-1{color} | {color:red} docker {color} | {color:red} 1m 47s
{color} | {color:red} Docker failed to build yetus/hbase:date2016-02-24.
{color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12789351/HBASE-15136-v2.patch |
| JIRA Issue | HBASE-15136 |
| Powered by | Apache Yetus 0.2.0-SNAPSHOT http://yetus.apache.org |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/660/console |
This message was automatically generated.
> Explore different queuing behaviors while busy
> --
>
> Key: HBASE-15136
> URL: https://issues.apache.org/jira/browse/HBASE-15136
> Project: HBase
> Issue Type: New Feature
> Components: IPC/RPC
>Reporter: Elliott Clark
>Assignee: Mikhail Antonov
> Attachments: HBASE-15136-1.2.v1.patch, HBASE-15136-v2.patch,
> deadline_scheduler_v_0_2.patch
>
>
> http://queue.acm.org/detail.cfm?id=2839461
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15136) Explore different queuing behaviors while busy
[ https://issues.apache.org/jira/browse/HBASE-15136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Antonov updated HBASE-15136: Status: Open (was: Patch Available) > Explore different queuing behaviors while busy > -- > > Key: HBASE-15136 > URL: https://issues.apache.org/jira/browse/HBASE-15136 > Project: HBase > Issue Type: New Feature > Components: IPC/RPC >Reporter: Elliott Clark >Assignee: Mikhail Antonov > Attachments: HBASE-15136-1.2.v1.patch, HBASE-15136-v2.patch, > deadline_scheduler_v_0_2.patch > > > http://queue.acm.org/detail.cfm?id=2839461 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15136) Explore different queuing behaviors while busy
[ https://issues.apache.org/jira/browse/HBASE-15136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Antonov updated HBASE-15136: Status: Patch Available (was: Open) > Explore different queuing behaviors while busy > -- > > Key: HBASE-15136 > URL: https://issues.apache.org/jira/browse/HBASE-15136 > Project: HBase > Issue Type: New Feature > Components: IPC/RPC >Reporter: Elliott Clark >Assignee: Mikhail Antonov > Attachments: HBASE-15136-1.2.v1.patch, HBASE-15136-v2.patch, > deadline_scheduler_v_0_2.patch > > > http://queue.acm.org/detail.cfm?id=2839461 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-15184) SparkSQL Scan operation doesn't work on kerberos cluster
[ https://issues.apache.org/jira/browse/HBASE-15184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159992#comment-15159992 ] Jonathan Hsieh edited comment on HBASE-15184 at 2/24/16 1:01 AM: - Hey [~tedyu], before we committed we should have waited to make sure [~asrabkin]'s concern was addressed. was (Author: jmhsieh): Hey [~tedyu], before we committed we should have waited to make sure [asrabkin]'s concern was addressed. > SparkSQL Scan operation doesn't work on kerberos cluster > > > Key: HBASE-15184 > URL: https://issues.apache.org/jira/browse/HBASE-15184 > Project: HBase > Issue Type: Bug > Components: spark >Reporter: Ted Malaska >Assignee: Ted Malaska >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-15184.1.patch, HBaseSparkModule.zip > > > I was using the HBase Spark Module at a client with Kerberos and I ran into > an issue with the Scan. > I made a fix for the client but we need to put it back into HBase. I will > attach my solution, but it has a major problem. I had to over ride a > protected class in spark. I will need help to decover a better approach -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15184) SparkSQL Scan operation doesn't work on kerberos cluster
[ https://issues.apache.org/jira/browse/HBASE-15184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159992#comment-15159992 ] Jonathan Hsieh commented on HBASE-15184: Hey [~tedyu], before we committed we should have waited to make sure [asrabkin]'s concern was addressed. > SparkSQL Scan operation doesn't work on kerberos cluster > > > Key: HBASE-15184 > URL: https://issues.apache.org/jira/browse/HBASE-15184 > Project: HBase > Issue Type: Bug > Components: spark >Reporter: Ted Malaska >Assignee: Ted Malaska >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-15184.1.patch, HBaseSparkModule.zip > > > I was using the HBase Spark Module at a client with Kerberos and I ran into > an issue with the Scan. > I made a fix for the client but we need to put it back into HBase. I will > attach my solution, but it has a major problem. I had to over ride a > protected class in spark. I will need help to decover a better approach -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15184) SparkSQL Scan operation doesn't work on kerberos cluster
[ https://issues.apache.org/jira/browse/HBASE-15184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159987#comment-15159987 ] Ted Malaska commented on HBASE-15184: - Thank u Ted yu -- Sent from Gmail Mobile > SparkSQL Scan operation doesn't work on kerberos cluster > > > Key: HBASE-15184 > URL: https://issues.apache.org/jira/browse/HBASE-15184 > Project: HBase > Issue Type: Bug > Components: spark >Reporter: Ted Malaska >Assignee: Ted Malaska >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-15184.1.patch, HBaseSparkModule.zip > > > I was using the HBase Spark Module at a client with Kerberos and I ran into > an issue with the Scan. > I made a fix for the client but we need to put it back into HBase. I will > attach my solution, but it has a major problem. I had to over ride a > protected class in spark. I will need help to decover a better approach -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15136) Explore different queuing behaviors while busy
[ https://issues.apache.org/jira/browse/HBASE-15136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Antonov updated HBASE-15136: Status: Patch Available (was: Open) > Explore different queuing behaviors while busy > -- > > Key: HBASE-15136 > URL: https://issues.apache.org/jira/browse/HBASE-15136 > Project: HBase > Issue Type: New Feature > Components: IPC/RPC >Reporter: Elliott Clark >Assignee: Mikhail Antonov > Attachments: HBASE-15136-1.2.v1.patch, HBASE-15136-v2.patch, > deadline_scheduler_v_0_2.patch > > > http://queue.acm.org/detail.cfm?id=2839461 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15184) SparkSQL Scan operation doesn't work on kerberos cluster
[ https://issues.apache.org/jira/browse/HBASE-15184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-15184: --- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) > SparkSQL Scan operation doesn't work on kerberos cluster > > > Key: HBASE-15184 > URL: https://issues.apache.org/jira/browse/HBASE-15184 > Project: HBase > Issue Type: Bug > Components: spark >Reporter: Ted Malaska >Assignee: Ted Malaska >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-15184.1.patch, HBaseSparkModule.zip > > > I was using the HBase Spark Module at a client with Kerberos and I ran into > an issue with the Scan. > I made a fix for the client but we need to put it back into HBase. I will > attach my solution, but it has a major problem. I had to over ride a > protected class in spark. I will need help to decover a better approach -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15136) Explore different queuing behaviors while busy
[ https://issues.apache.org/jira/browse/HBASE-15136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Antonov updated HBASE-15136: Status: Open (was: Patch Available) > Explore different queuing behaviors while busy > -- > > Key: HBASE-15136 > URL: https://issues.apache.org/jira/browse/HBASE-15136 > Project: HBase > Issue Type: New Feature > Components: IPC/RPC >Reporter: Elliott Clark >Assignee: Mikhail Antonov > Attachments: HBASE-15136-1.2.v1.patch, HBASE-15136-v2.patch, > deadline_scheduler_v_0_2.patch > > > http://queue.acm.org/detail.cfm?id=2839461 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15136) Explore different queuing behaviors while busy
[ https://issues.apache.org/jira/browse/HBASE-15136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Antonov updated HBASE-15136: Attachment: HBASE-15136-v2.patch Some more improvements, dynamically configurable CoDel properties, added test, made sure deadline is still the default. > Explore different queuing behaviors while busy > -- > > Key: HBASE-15136 > URL: https://issues.apache.org/jira/browse/HBASE-15136 > Project: HBase > Issue Type: New Feature > Components: IPC/RPC >Reporter: Elliott Clark >Assignee: Mikhail Antonov > Attachments: HBASE-15136-1.2.v1.patch, HBASE-15136-v2.patch, > deadline_scheduler_v_0_2.patch > > > http://queue.acm.org/detail.cfm?id=2839461 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15184) SparkSQL Scan operation doesn't work on kerberos cluster
[
https://issues.apache.org/jira/browse/HBASE-15184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159982#comment-15159982
]
Jonathan Hsieh commented on HBASE-15184:
I tested the patch on a live kerborized cluster and it works for me.Here's
how I did it for folks who'd like to duplicate:
Prereqs:
# must have a kerb enabled cluster (hbase/hdfs/yarn, etc).
# spark must be run in yarn continainers (kerb doesn't work with spark
standalone mode).
Procedure:
# Loaded a table with 100k rows. 'hbase ltt -write 5:1000:160 -num_keys 10
-tn ltt'
# Granted 'R' access to 'randomuser' user (yarn need to have a user with id
>1000). "grant 'randomuser', 'R', 'ltt'" in the hbase shell.
# Started spark-shell with hbase classpath: 'sudo -u randomuser
SPARK_CLASSPATH=`hbase classpath` spark-shell
# ran these lines in the spark shell
{code}
import org.apache.hadoop.hbase.spark.HBaseContext
import org.apache.hadoop.hbase.{TableName, HBaseConfiguration}
import org.apache.hadoop.hbase.util.Bytes
import org.apache.hadoop.hbase.client.Scan
import org.apache.spark.sql.SQLContext
val tableName="ltt"
val hbaseConf = HBaseConfiguration.create()
val hbaseContext = new HBaseContext(sc, hbaseConf)
val scan = new Scan()
scan.setCaching(100)
val getRdd = hbaseContext.hbaseRDD(TableName.valueOf(tableName), scan)
getRdd.foreach(v => println(Bytes.toString(v._1.get(
println("Length: " + getRdd.map(r => r._1.copyBytes()).collect().length);
{code}
# got 100k count, declare victory
> SparkSQL Scan operation doesn't work on kerberos cluster
>
>
> Key: HBASE-15184
> URL: https://issues.apache.org/jira/browse/HBASE-15184
> Project: HBase
> Issue Type: Bug
> Components: spark
>Reporter: Ted Malaska
>Assignee: Ted Malaska
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-15184.1.patch, HBaseSparkModule.zip
>
>
> I was using the HBase Spark Module at a client with Kerberos and I ran into
> an issue with the Scan.
> I made a fix for the client but we need to put it back into HBase. I will
> attach my solution, but it has a major problem. I had to over ride a
> protected class in spark. I will need help to decover a better approach
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15184) SparkSQL Scan operation doesn't work on kerberos cluster
[ https://issues.apache.org/jira/browse/HBASE-15184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159979#comment-15159979 ] Jonathan Hsieh commented on HBASE-15184: Hey [~asrabkin], I don't quite understand the map trick you mentioned but I think the HBaseContext introduced in this module may hide the need for the code snippet you provided. > SparkSQL Scan operation doesn't work on kerberos cluster > > > Key: HBASE-15184 > URL: https://issues.apache.org/jira/browse/HBASE-15184 > Project: HBase > Issue Type: Bug > Components: spark >Reporter: Ted Malaska >Assignee: Ted Malaska >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-15184.1.patch, HBaseSparkModule.zip > > > I was using the HBase Spark Module at a client with Kerberos and I ran into > an issue with the Scan. > I made a fix for the client but we need to put it back into HBase. I will > attach my solution, but it has a major problem. I had to over ride a > protected class in spark. I will need help to decover a better approach -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15130) Backport 0.98 Scan different TimeRange for each column family
[
https://issues.apache.org/jira/browse/HBASE-15130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159962#comment-15159962
]
Hadoop QA commented on HBASE-15130:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 4 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
23s {color} | {color:green} 0.98 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 28s
{color} | {color:green} 0.98 passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 17s
{color} | {color:green} 0.98 passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
52s {color} | {color:green} 0.98 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
41s {color} | {color:green} 0.98 passed {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m
52s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m 58s
{color} | {color:red} hbase-client in 0.98 has 19 extant Findbugs warnings.
{color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m 43s
{color} | {color:red} hbase-common in 0.98 has 6 extant Findbugs warnings.
{color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 1m 45s
{color} | {color:red} hbase-server in 0.98 has 83 extant Findbugs warnings.
{color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m 23s
{color} | {color:red} hbase-client in 0.98 failed with JDK v1.8.0_72. {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m 17s
{color} | {color:red} hbase-common in 0.98 failed with JDK v1.8.0_72. {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m 30s
{color} | {color:red} hbase-server in 0.98 failed with JDK v1.8.0_72. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 11s
{color} | {color:green} 0.98 passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m 15s
{color} | {color:red} hbase-client in the patch failed. {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m 23s
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m 23s
{color} | {color:red} hbase-server in the patch failed with JDK v1.8.0_72.
{color} |
| {color:red}-1{color} | {color:red} cc {color} | {color:red} 0m 23s {color} |
{color:red} hbase-server in the patch failed with JDK v1.8.0_72. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 23s {color}
| {color:red} hbase-server in the patch failed with JDK v1.8.0_72. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m 23s
{color} | {color:red} hbase-server in the patch failed with JDK v1.7.0_95.
{color} |
| {color:red}-1{color} | {color:red} cc {color} | {color:red} 0m 23s {color} |
{color:red} hbase-server in the patch failed with JDK v1.7.0_95. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 23s {color}
| {color:red} hbase-server in the patch failed with JDK v1.7.0_95. {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m 10s
{color} | {color:red} Patch generated 1 new checkstyle issues in hbase-client
(total was 12, now 13). {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
39s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 0s
{color} | {color:red} The patch has 123 line(s) that end in whitespace. Use git
apply --whitespace=fix. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 3m
37s {color} | {color:green} Patch does not cause any errors with Hadoop 2.4.1
2.5.2 2.6.0. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m
52s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} |
[jira] [Commented] (HBASE-15264) Implement a fan out HDFS OutputStream
[ https://issues.apache.org/jira/browse/HBASE-15264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159960#comment-15159960 ] stack commented on HBASE-15264: --- Patch looks good to me. Can fix the checkstyle and javadoc on commit (if you can). The unit test failures are unrelated? If so, go for it [~Apache9] > Implement a fan out HDFS OutputStream > - > > Key: HBASE-15264 > URL: https://issues.apache.org/jira/browse/HBASE-15264 > Project: HBase > Issue Type: Sub-task > Components: util, wal >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0 > > Attachments: HBASE-15264-v1.patch, HBASE-15264-v2.patch, > HBASE-15264-v3.patch, HBASE-15264-v4.patch, HBASE-15264-v5.patch, > HBASE-15264-v6.patch, HBASE-15264-v7.patch, HBASE-15264.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15187) Integrate CSRF prevention filter to REST gateway
[ https://issues.apache.org/jira/browse/HBASE-15187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-15187: --- Attachment: HBASE-15187.v8.patch Patch v8 uses reflection to load CSRF filter. > Integrate CSRF prevention filter to REST gateway > > > Key: HBASE-15187 > URL: https://issues.apache.org/jira/browse/HBASE-15187 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu > Attachments: HBASE-15187.v1.patch, HBASE-15187.v2.patch, > HBASE-15187.v3.patch, HBASE-15187.v4.patch, HBASE-15187.v5.patch, > HBASE-15187.v6.patch, HBASE-15187.v7.patch, HBASE-15187.v8.patch > > > HADOOP-12691 introduced a filter in Hadoop Common to help REST APIs guard > against cross-site request forgery attacks. > This issue tracks the integration of that filter into HBase REST gateway. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15264) Implement a fan out HDFS OutputStream
[ https://issues.apache.org/jira/browse/HBASE-15264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159955#comment-15159955 ] stack commented on HBASE-15264: --- Ok. Just go for master. Makes sense. > Implement a fan out HDFS OutputStream > - > > Key: HBASE-15264 > URL: https://issues.apache.org/jira/browse/HBASE-15264 > Project: HBase > Issue Type: Sub-task > Components: util, wal >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0 > > Attachments: HBASE-15264-v1.patch, HBASE-15264-v2.patch, > HBASE-15264-v3.patch, HBASE-15264-v4.patch, HBASE-15264-v5.patch, > HBASE-15264-v6.patch, HBASE-15264-v7.patch, HBASE-15264.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15300) Upgrade to zookeeper 3.4.8
[
https://issues.apache.org/jira/browse/HBASE-15300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159950#comment-15159950
]
Hadoop QA commented on HBASE-15300:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
52s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m 30s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 38s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
43s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 4m 25s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 48s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
3s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 35s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m 35s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 22s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m 22s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
31s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m 1s
{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
38m 6s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 4m 20s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 52s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 157m 6s {color}
| {color:red} root in the patch failed with JDK v1.8.0_72. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 161m 47s
{color} | {color:red} root in the patch failed with JDK v1.7.0_95. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
30s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 402m 21s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| JDK v1.8.0_72 Timed out junit tests |
org.apache.hadoop.hbase.snapshot.TestFlushSnapshotFromClient |
| JDK v1.7.0_95 Timed out junit tests |
org.apache.hadoop.hbase.snapshot.TestMobSecureExportSnapshot |
| | org.apache.hadoop.hbase.snapshot.TestSecureExportSnapshot |
| | org.apache.hadoop.hbase.snapshot.TestMobExportSnapshot |
| | org.apache.hadoop.hbase.snapshot.TestExportSnapshot |
| | org.apache.hadoop.hbase.snapshot.TestFlushSnapshotFromClient |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.9.1 Server=1.9.1 Image:yetus/hbase:date2016-02-23 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12789218/HBASE-1533.v1.patch |
| JIRA Issue | HBASE-15300 |
| Optional Tests | asflicense javac javadoc unit xml compile |
| uname | Linux 4cd9b3f5f568 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed
Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
[jira] [Commented] (HBASE-15184) SparkSQL Scan operation doesn't work on kerberos cluster
[
https://issues.apache.org/jira/browse/HBASE-15184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159949#comment-15159949
]
Hadoop QA commented on HBASE-15184:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 46s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 0s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} scaladoc {color} | {color:green} 0m
28s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} scaladoc {color} | {color:green} 0m
28s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 43s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} scalac {color} | {color:green} 0m 43s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 0s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} scalac {color} | {color:green} 1m 0s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
24m 14s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} scaladoc {color} | {color:green} 0m
28s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} scaladoc {color} | {color:green} 0m
29s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 52s
{color} | {color:green} hbase-spark in the patch passed with JDK v1.8.0_72.
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 1s
{color} | {color:green} hbase-spark in the patch passed with JDK v1.7.0_95.
{color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
9s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 31m 54s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.9.1 Server=1.9.1 Image:yetus/hbase:date2016-02-23 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12789108/HBASE-15184.1.patch |
| JIRA Issue | HBASE-15184 |
| Optional Tests | asflicense scalac scaladoc unit compile |
| uname | Linux b39a061cd578 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed
Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / f47dba7 |
| JDK v1.7.0_95 Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/657/testReport/ |
| modules | C: hbase-spark U: hbase-spark |
| Max memory used | 186MB |
| Powered by | Apache Yetus 0.1.0 http://yetus.apache.org |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/657/console |
This message was automatically generated.
> SparkSQL Scan operation doesn't work on kerberos cluster
>
>
> Key: HBASE-15184
> URL: https://issues.apache.org/jira/browse/HBASE-15184
> Project: HBase
> Issue Type: Bug
> Components: spark
>Reporter: Ted Malaska
>Assignee: Ted Malaska
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-15184.1.patch, HBaseSparkModule.zip
>
>
> I was using the HBase Spark Module at a client with Kerberos and I ran into
> an issue with the Scan.
> I made a fix for the client but we need to put it back into HBase. I will
> attach my solution, but it has a
[jira] [Commented] (HBASE-15243) Utilize the lowest seek value when all Filters in MUST_PASS_ONE FilterList return SEEK_NEXT_USING_HINT
[ https://issues.apache.org/jira/browse/HBASE-15243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159940#comment-15159940 ] Ted Yu commented on HBASE-15243: [~stack]: As requested, I added unit test showing the correctness and performance gain from this change. I think patch v5 can be committed. If you don't have other review comment, I plan to integrate the patch. > Utilize the lowest seek value when all Filters in MUST_PASS_ONE FilterList > return SEEK_NEXT_USING_HINT > -- > > Key: HBASE-15243 > URL: https://issues.apache.org/jira/browse/HBASE-15243 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15243-v1.txt, HBASE-15243-v2.txt, > HBASE-15243-v3.txt, HBASE-15243-v4.txt, HBASE-15243-v5.txt > > > As Preston Koprivica pointed out at the tail of HBASE-4394, when all filters > in a MUST_PASS_ONE FilterList return a SEEK_USING_NEXT_HINT code, we should > return SEEK_NEXT_USING_HINT from the FilterList to utilize the lowest seek > value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15264) Implement a fan out HDFS OutputStream
[
https://issues.apache.org/jira/browse/HBASE-15264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159930#comment-15159930
]
Hadoop QA commented on HBASE-15264:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
8s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 53s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 49s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 5m
3s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
23s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
37s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 44s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 46s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
1s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 53s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 52s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 49s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 49s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 4m 59s
{color} | {color:red} Patch generated 11 new checkstyle issues in hbase-server
(total was 0, now 11). {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
23s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
1s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
33m 42s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
55s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 3m 40s
{color} | {color:red} hbase-server-jdk1.8.0_72 with JDK v1.8.0_72 generated 1
new issues (was 1, now 2). {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 44s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 4m 28s
{color} | {color:red} hbase-server-jdk1.7.0_95 with JDK v1.7.0_95 generated 1
new issues (was 1, now 2). {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 48s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 150m 13s
{color} | {color:red} hbase-server in the patch failed with JDK v1.8.0_72.
{color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 148m 49s
{color} | {color:red} hbase-server in the patch failed with JDK v1.7.0_95.
{color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
26s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 384m 9s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| JDK v1.8.0_72 Timed out junit tests |
org.apache.hadoop.hbase.client.TestHTableMultiplexer |
| JDK
[jira] [Assigned] (HBASE-15230) ReplicationSource is replicating existing WAL data in a newly added peer
[ https://issues.apache.org/jira/browse/HBASE-15230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales reassigned HBASE-15230: -- Assignee: churro morales > ReplicationSource is replicating existing WAL data in a newly added peer > > > Key: HBASE-15230 > URL: https://issues.apache.org/jira/browse/HBASE-15230 > Project: HBase > Issue Type: Bug >Reporter: Ashish Singhi >Assignee: churro morales > > Scenario: > 1. Add a peer 'p1' and enable table replication for a table 't1' > 2. Put some data in the table 't1' and its gets replicated to peer 'p1' as > expected. > 3. Remove peer 'p1' and truncate the table 't1' in both source and peer > cluster. > 4. Now add peer 'p2' , there is no data in source cluster in table 't1' but > in peer cluster 'p2' where table 't1' already exists, existing WAL data of > table 't1' is getting replicated in 'p2'. > Expectation: Table 't1' in peer cluster 'p2' should only have data which is > inserted in source cluster table 't1' after adding peer 'p2' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13788) Shell commands do not support column qualifiers containing colon (:)
[
https://issues.apache.org/jira/browse/HBASE-13788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Latham updated HBASE-13788:
Summary: Shell commands do not support column qualifiers containing colon
(:) (was: Shell comands do not support column qualifiers containing colon (:))
> Shell commands do not support column qualifiers containing colon (:)
>
>
> Key: HBASE-13788
> URL: https://issues.apache.org/jira/browse/HBASE-13788
> Project: HBase
> Issue Type: Bug
> Components: shell
>Affects Versions: 0.98.0, 0.96.0, 1.0.0, 1.1.0
>Reporter: Dave Latham
>Assignee: Pankaj Kumar
>
> The shell interprets the colon within the qualifier as a delimiter to a
> FORMATTER instead of part of the qualifier itself.
> Example from the mailing list:
> Hmph, I may have spoken too soon. I know I tested this at one point and
> it worked, but now I'm getting different results:
> On the new cluster, I created a duplicate test table:
> hbase(main):043:0> create 'content3', {NAME => 'x', BLOOMFILTER =>
> 'NONE', REPLICATION_SCOPE => '0', VERSIONS => '3', COMPRESSION =>
> 'NONE', MIN_VERSIONS => '0', TTL => '2147483647', BLOCKSIZE => '65536',
> IN_MEMORY => 'false', BLOCKCACHE => 'true'}
> Then I pull some data from the imported table:
> hbase(main):045:0> scan 'content', {LIMIT=>1,
> STARTROW=>'A:9223370612089311807:twtr:57013379'}
> ROW COLUMN+CELL
>
> A:9223370612089311807:twtr:570133798827921408
> column=x:twitter:username, timestamp=1424775595345, value=BERITA &
> INFORMASI!
> Then put it:
> hbase(main):046:0> put
> 'content3','A:9223370612089311807:twtr:570133798827921408',
> 'x:twitter:username', 'BERITA & INFORMASI!'
> But then when I query it, I see that I've lost the column qualifier
> ":username":
> hbase(main):046:0> scan 'content3'
> ROW COLUMN+CELL
> A:9223370612089311807:twtr:570133798827921408 column=x:twitter,
> timestamp=1432745301788, value=BERITA & INFORMASI!
> Even though I'm missing one of the qualifiers, I can at least filter on
> columns in this sample table.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15306) Make RPC call queue length dynamically configurable
[ https://issues.apache.org/jira/browse/HBASE-15306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159824#comment-15159824 ] Hudson commented on HBASE-15306: FAILURE: Integrated in HBase-1.3-IT #513 (See [https://builds.apache.org/job/HBase-1.3-IT/513/]) HBASE-15306 Make RPC call queue length dynamically configurable (antonov: rev bcbe174a277998f1c7ea4035b2f2d91e7757bc66) * hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/BalancedQueueRpcExecutor.java * hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/RpcServer.java * hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/RpcExecutor.java * hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/RWQueueRpcExecutor.java * hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/SimpleRpcScheduler.java * hbase-server/src/test/java/org/apache/hadoop/hbase/ipc/TestSimpleRpcScheduler.java > Make RPC call queue length dynamically configurable > --- > > Key: HBASE-15306 > URL: https://issues.apache.org/jira/browse/HBASE-15306 > Project: HBase > Issue Type: Improvement > Components: IPC/RPC >Affects Versions: 1.2.0 >Reporter: Mikhail Antonov >Assignee: Mikhail Antonov > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15306-v1.patch, HBASE-15306-v2.patch, > HBASE-15306-v3.patch > > > Sometimes it's useful to be able to modify call queue size on prod cluster > without having to do a rolling restart. > Here setting fixed hard limit on call queue size and soft limit which is > dynamically-updatable. > https://reviews.facebook.net/D54579 for review, will test more. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15290) Hbase Rest CheckAndAPI should save other cells along with compared cell
[
https://issues.apache.org/jira/browse/HBASE-15290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159827#comment-15159827
]
Ted Yu commented on HBASE-15290:
{code}
239 if(otherCells != null)
240 {
{code}
The left curly should follow ')' on the same line as 'if' statement.
> Hbase Rest CheckAndAPI should save other cells along with compared cell
> ---
>
> Key: HBASE-15290
> URL: https://issues.apache.org/jira/browse/HBASE-15290
> Project: HBase
> Issue Type: Bug
> Components: hbase
>Affects Versions: 1.1.1
> Environment: Linux and windows
>Reporter: Ajith
> Labels: easyfix
> Attachments: HBASE-15290-checkAndPut.patch, checkputfix2.patch
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> Java CheckAndPut API allows users to save Cells (C1..C5) while comparing a
> Cell C1.
> But in Rest API, even though caller sent multiple cells, hbase rest code is
> ignoring all the cells except for compare cell.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15290) Hbase Rest CheckAndAPI should save other cells along with compared cell
[ https://issues.apache.org/jira/browse/HBASE-15290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-15290: --- Status: Patch Available (was: Open) > Hbase Rest CheckAndAPI should save other cells along with compared cell > --- > > Key: HBASE-15290 > URL: https://issues.apache.org/jira/browse/HBASE-15290 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 1.1.1 > Environment: Linux and windows >Reporter: Ajith > Labels: easyfix > Attachments: HBASE-15290-checkAndPut.patch, checkputfix2.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > Java CheckAndPut API allows users to save Cells (C1..C5) while comparing a > Cell C1. > But in Rest API, even though caller sent multiple cells, hbase rest code is > ignoring all the cells except for compare cell. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15222) Use less contended classes for metrics
[ https://issues.apache.org/jira/browse/HBASE-15222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159823#comment-15159823 ] Sean Busbey commented on HBASE-15222: - Alternatively, we could waste a bunch of energy on getting a manual ordering of our modules in place, as was required prior to YETUS-280. that would allow us to get the correct behavior with the current release. Personally, I don't think it's worth it given how un-often we run into this problem. I'll start a Yetus release vote on Friday and on Monday we'll switch to new release that contains the fix. > Use less contended classes for metrics > -- > > Key: HBASE-15222 > URL: https://issues.apache.org/jira/browse/HBASE-15222 > Project: HBase > Issue Type: Bug > Components: metrics >Affects Versions: 2.0.0, 1.2.0, 1.3.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Critical > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15222-v1.patch, HBASE-15222-v10.patch, > HBASE-15222-v11.patch, HBASE-15222-v12.patch, HBASE-15222-v13.patch, > HBASE-15222-v2.patch, HBASE-15222-v3.patch, HBASE-15222-v5.patch, > HBASE-15222-v6.patch, HBASE-15222-v8.patch, HBASE-15222-v9.patch, > HBASE-15222.patch > > > Running the benchmarks now, but it looks like the results are pretty extreme. > The locking in our histograms is pretty extreme. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15222) Use less contended classes for metrics
[ https://issues.apache.org/jira/browse/HBASE-15222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159819#comment-15159819 ] Sean Busbey commented on HBASE-15222: - The problem is the burden that puts on the Yetus community. As an ASF community their pre-release work is only supposed to be used by their community (which gets defined by their dev@ list). Their PMC is charged with taking proactive steps to avoid folks from outside that list using pre-release work. Right now I'm relying on a rather liberal reading of that rule to justify myself and other HBase folks who work on our precommit builds having a "check if the fix for X works." This is a big rabbit hole of ASF internals stuff I'd rather not waste energy on. The number of cases where this impacts us should be minimal in the long term. YETUS-280 is a temporary growing pain exacerbated by the Yetus project still getting its feet on release cadence. It has a known work around that literally any committer on the project can exercise. > Use less contended classes for metrics > -- > > Key: HBASE-15222 > URL: https://issues.apache.org/jira/browse/HBASE-15222 > Project: HBase > Issue Type: Bug > Components: metrics >Affects Versions: 2.0.0, 1.2.0, 1.3.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Critical > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15222-v1.patch, HBASE-15222-v10.patch, > HBASE-15222-v11.patch, HBASE-15222-v12.patch, HBASE-15222-v13.patch, > HBASE-15222-v2.patch, HBASE-15222-v3.patch, HBASE-15222-v5.patch, > HBASE-15222-v6.patch, HBASE-15222-v8.patch, HBASE-15222-v9.patch, > HBASE-15222.patch > > > Running the benchmarks now, but it looks like the results are pretty extreme. > The locking in our histograms is pretty extreme. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15317) document release announcement template
[ https://issues.apache.org/jira/browse/HBASE-15317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159816#comment-15159816 ] Andrew Purtell commented on HBASE-15317: lgtm > document release announcement template > -- > > Key: HBASE-15317 > URL: https://issues.apache.org/jira/browse/HBASE-15317 > Project: HBase > Issue Type: Improvement > Components: documentation >Reporter: Sean Busbey > > Our release docs should include a release announcement template for folks to > use (and suggested email lists to send to) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15290) Hbase Rest CheckAndAPI should save other cells along with compared cell
[ https://issues.apache.org/jira/browse/HBASE-15290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159811#comment-15159811 ] Nitin Verma commented on HBASE-15290: - Hi [~enis] [~onpduo] [~gouravk] Could you guys please review the patch? Thanks, Nitin. > Hbase Rest CheckAndAPI should save other cells along with compared cell > --- > > Key: HBASE-15290 > URL: https://issues.apache.org/jira/browse/HBASE-15290 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 1.1.1 > Environment: Linux and windows >Reporter: Ajith > Labels: easyfix > Attachments: HBASE-15290-checkAndPut.patch, checkputfix2.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > Java CheckAndPut API allows users to save Cells (C1..C5) while comparing a > Cell C1. > But in Rest API, even though caller sent multiple cells, hbase rest code is > ignoring all the cells except for compare cell. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15184) SparkSQL Scan operation doesn't work on kerberos cluster
[ https://issues.apache.org/jira/browse/HBASE-15184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-15184: --- Status: Patch Available (was: Open) > SparkSQL Scan operation doesn't work on kerberos cluster > > > Key: HBASE-15184 > URL: https://issues.apache.org/jira/browse/HBASE-15184 > Project: HBase > Issue Type: Bug > Components: spark >Reporter: Ted Malaska >Assignee: Ted Malaska >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-15184.1.patch, HBaseSparkModule.zip > > > I was using the HBase Spark Module at a client with Kerberos and I ran into > an issue with the Scan. > I made a fix for the client but we need to put it back into HBase. I will > attach my solution, but it has a major problem. I had to over ride a > protected class in spark. I will need help to decover a better approach -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14801) Enhance the Spark-HBase connector catalog with json format
[ https://issues.apache.org/jira/browse/HBASE-14801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159806#comment-15159806 ] Zhan Zhang commented on HBASE-14801: Will update the scoreboard after the sanity test by server. > Enhance the Spark-HBase connector catalog with json format > -- > > Key: HBASE-14801 > URL: https://issues.apache.org/jira/browse/HBASE-14801 > Project: HBase > Issue Type: Improvement >Reporter: Zhan Zhang >Assignee: Zhan Zhang > Attachments: HBASE-14801-1.patch, HBASE-14801-2.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14801) Enhance the Spark-HBase connector catalog with json format
[ https://issues.apache.org/jira/browse/HBASE-14801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhan Zhang updated HBASE-14801: --- Attachment: HBASE-14801-2.patch > Enhance the Spark-HBase connector catalog with json format > -- > > Key: HBASE-14801 > URL: https://issues.apache.org/jira/browse/HBASE-14801 > Project: HBase > Issue Type: Improvement >Reporter: Zhan Zhang >Assignee: Zhan Zhang > Attachments: HBASE-14801-1.patch, HBASE-14801-2.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15222) Use less contended classes for metrics
[ https://issues.apache.org/jira/browse/HBASE-15222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159798#comment-15159798 ] Elliott Clark commented on HBASE-15222: --- I see no problem with using a non-release build script. This isn't something that's being shipped to end users. This is a dev tool. Basically every jenkins run we had before yetus was a non-released version. We as a community were fine with that. > Use less contended classes for metrics > -- > > Key: HBASE-15222 > URL: https://issues.apache.org/jira/browse/HBASE-15222 > Project: HBase > Issue Type: Bug > Components: metrics >Affects Versions: 2.0.0, 1.2.0, 1.3.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Critical > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15222-v1.patch, HBASE-15222-v10.patch, > HBASE-15222-v11.patch, HBASE-15222-v12.patch, HBASE-15222-v13.patch, > HBASE-15222-v2.patch, HBASE-15222-v3.patch, HBASE-15222-v5.patch, > HBASE-15222-v6.patch, HBASE-15222-v8.patch, HBASE-15222-v9.patch, > HBASE-15222.patch > > > Running the benchmarks now, but it looks like the results are pretty extreme. > The locking in our histograms is pretty extreme. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15222) Use less contended classes for metrics
[
https://issues.apache.org/jira/browse/HBASE-15222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159790#comment-15159790
]
Hadoop QA commented on HBASE-15222:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
27s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 19s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 23s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 6m
33s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
53s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
55s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 14s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 23s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m 12s
{color} | {color:red} hbase-hadoop2-compat in the patch failed. {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 19s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 19s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 20s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 20s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 6m
8s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
52s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m 1s
{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
28m 53s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
34s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 15s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 23s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 51s
{color} | {color:green} hbase-common in the patch passed with JDK v1.8.0_72.
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 21s
{color} | {color:green} hbase-hadoop2-compat in the patch passed with JDK
v1.8.0_72. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 17s
{color} | {color:green} hbase-hadoop-compat in the patch passed with JDK
v1.8.0_72. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 112m 56s
{color} | {color:red} hbase-server in the patch failed with JDK v1.8.0_72.
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 4s
{color} | {color:green} hbase-common in the patch passed with JDK v1.7.0_95.
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 29s
{color} | {color:green} hbase-hadoop2-compat in the patch passed with JDK
[jira] [Updated] (HBASE-14878) maven archetype: client application with shaded jars
[ https://issues.apache.org/jira/browse/HBASE-14878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Vimont updated HBASE-14878: -- Status: Open (was: Patch Available) > maven archetype: client application with shaded jars > > > Key: HBASE-14878 > URL: https://issues.apache.org/jira/browse/HBASE-14878 > Project: HBase > Issue Type: Sub-task > Components: build, Usability >Affects Versions: 2.0.0 >Reporter: Nick Dimiduk >Assignee: Daniel Vimont > Labels: beginner > Attachments: HBASE-14878-v1.patch > > > Add new archetype for generation of hbase-shaded-client dependent project. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14878) maven archetype: client application with shaded jars
[ https://issues.apache.org/jira/browse/HBASE-14878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Vimont updated HBASE-14878: -- Status: Patch Available (was: Open) > maven archetype: client application with shaded jars > > > Key: HBASE-14878 > URL: https://issues.apache.org/jira/browse/HBASE-14878 > Project: HBase > Issue Type: Sub-task > Components: build, Usability >Affects Versions: 2.0.0 >Reporter: Nick Dimiduk >Assignee: Daniel Vimont > Labels: beginner > Attachments: HBASE-14878-v1.patch > > > Add new archetype for generation of hbase-shaded-client dependent project. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15306) Make RPC call queue length dynamically configurable
[ https://issues.apache.org/jira/browse/HBASE-15306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159780#comment-15159780 ] Mikhail Antonov commented on HBASE-15306: - Committed v3 to master and branch-1. > Make RPC call queue length dynamically configurable > --- > > Key: HBASE-15306 > URL: https://issues.apache.org/jira/browse/HBASE-15306 > Project: HBase > Issue Type: Improvement > Components: IPC/RPC >Affects Versions: 1.2.0 >Reporter: Mikhail Antonov >Assignee: Mikhail Antonov > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15306-v1.patch, HBASE-15306-v2.patch, > HBASE-15306-v3.patch > > > Sometimes it's useful to be able to modify call queue size on prod cluster > without having to do a rolling restart. > Here setting fixed hard limit on call queue size and soft limit which is > dynamically-updatable. > https://reviews.facebook.net/D54579 for review, will test more. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15306) Make RPC call queue length dynamically configurable
[ https://issues.apache.org/jira/browse/HBASE-15306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Antonov updated HBASE-15306: Resolution: Fixed Status: Resolved (was: Patch Available) > Make RPC call queue length dynamically configurable > --- > > Key: HBASE-15306 > URL: https://issues.apache.org/jira/browse/HBASE-15306 > Project: HBase > Issue Type: Improvement > Components: IPC/RPC >Affects Versions: 1.2.0 >Reporter: Mikhail Antonov >Assignee: Mikhail Antonov > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15306-v1.patch, HBASE-15306-v2.patch, > HBASE-15306-v3.patch > > > Sometimes it's useful to be able to modify call queue size on prod cluster > without having to do a rolling restart. > Here setting fixed hard limit on call queue size and soft limit which is > dynamically-updatable. > https://reviews.facebook.net/D54579 for review, will test more. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15232) Exceptions returned over multi RPC don't automatically trigger region location reloads
[
https://issues.apache.org/jira/browse/HBASE-15232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159777#comment-15159777
]
Hudson commented on HBASE-15232:
FAILURE: Integrated in HBase-1.3 #567 (See
[https://builds.apache.org/job/HBase-1.3/567/])
HBASE-15232 Handle region location cache mgmt in AsyncProcess for (stack: rev
d747188f2cb7d198393a35f4dde543a798fed3c8)
*
hbase-client/src/main/java/org/apache/hadoop/hbase/exceptions/ClientExceptionsUtil.java
*
hbase-client/src/test/java/org/apache/hadoop/hbase/client/TestHTableMultiplexerViaMocks.java
*
hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestHTableMultiplexerFlushCache.java
*
hbase-client/src/main/java/org/apache/hadoop/hbase/client/HTableMultiplexer.java
* hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncProcess.java
> Exceptions returned over multi RPC don't automatically trigger region
> location reloads
> --
>
> Key: HBASE-15232
> URL: https://issues.apache.org/jira/browse/HBASE-15232
> Project: HBase
> Issue Type: Sub-task
> Components: Client
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: 2.0.0, 1.3.0, 1.2.1
>
> Attachments: HBASE-15232-branch-1.002.patch, HBASE-15232.001.patch,
> HBASE-15232.002.patch, HBASE-15232.002.patch
>
>
> Follow-on for HBASE-15221:
> A work-around was added in HTableMultiplexer to work around an issue that
> AsyncProcess wasn't clearing the region location cache on Exception. This was
> stemming from the issue that the {{tableName}} is {{null}} because
> HTableMultiplexer is using the {{multi}} RPC. This causes an error that looks
> like:
> {noformat}
> [WARN] Coding error, see method javadoc. row=[B@1673eff, tableName=null
> {noformat}
> HBASE-15221 should fix HTableMultiplexer, but it would be good to push the
> fix down into AsyncProcess instead of using higher-level workarounds.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15130) Backport 0.98 Scan different TimeRange for each column family
[
https://issues.apache.org/jira/browse/HBASE-15130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159754#comment-15159754
]
Hadoop QA commented on HBASE-15130:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 4 new or modified test
files. {color} |
| {color:red}-1{color} | {color:red} mvndep {color} | {color:red} 1m 43s
{color} | {color:red} branch's hbase-client dependency:list failed {color} |
| {color:red}-1{color} | {color:red} mvndep {color} | {color:red} 2m 11s
{color} | {color:red} branch's hbase-common dependency:list failed {color} |
| {color:red}-1{color} | {color:red} mvndep {color} | {color:red} 2m 16s
{color} | {color:red} branch's hbase-protocol dependency:list failed {color} |
| {color:red}-1{color} | {color:red} mvndep {color} | {color:red} 2m 39s
{color} | {color:red} branch's hbase-server dependency:list failed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 2m 39s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
23s {color} | {color:green} 0.98 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 6s
{color} | {color:green} 0.98 passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 17s
{color} | {color:green} 0.98 passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
52s {color} | {color:green} 0.98 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
46s {color} | {color:green} 0.98 passed {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m
54s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m 54s
{color} | {color:red} hbase-client in 0.98 has 19 extant Findbugs warnings.
{color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m 38s
{color} | {color:red} hbase-common in 0.98 has 6 extant Findbugs warnings.
{color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 1m 39s
{color} | {color:red} hbase-server in 0.98 has 83 extant Findbugs warnings.
{color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m 16s
{color} | {color:red} hbase-client in 0.98 failed with JDK v1.8.0_72. {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m 13s
{color} | {color:red} hbase-common in 0.98 failed with JDK v1.8.0_72. {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m 27s
{color} | {color:red} hbase-server in 0.98 failed with JDK v1.8.0_72. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 9s
{color} | {color:green} 0.98 passed with JDK v1.7.0_95 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 28s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
27s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 9s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 1m 9s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 9s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 17s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 1m 17s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 17s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m 10s
{color} | {color:red} hbase-client: patch generated 1 new + 12 unchanged - 0
fixed = 13 total (was 12) {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
41s {color} |
[jira] [Commented] (HBASE-15317) document release announcement template
[
https://issues.apache.org/jira/browse/HBASE-15317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159751#comment-15159751
]
Sean Busbey commented on HBASE-15317:
-
replace \_version\_ with the version number for minor release within the
\_major\_ line:
{code}
The HBase team is happy to announce the immediate availability of HBase
_version_.
Apache HBase is an open-source, distributed, versioned, non-relational database.
Apache HBase gives you low latency random access to billions of rows with
millions of columns atop non-specialized hardware. To learn more about HBase,
see https://hbase.apache.org/.
HBase _version_ is the second minor release in the HBase _major_.x line, which
aims to
improve the stability and reliability of HBase. This release includes roughly
XXX resolved issues not covered by previous _major_.x releases.
Notable new features include:
- List text descriptions of features that fit on one line
- Including if JDK or Hadoop support versions changes
- For those with obvious JIRA IDs, include them (HBASE-Y)
The full list of issues can be found at:
https://s.apache.org/hbase-_version_-jira
Download through an ASF mirror near you:
http://www.apache.org/dyn/closer.lua/hbase/_version_/
The relevant checksums files are available at:
https://www.apache.org/dist/hbase/_version_/hbase-_version_-src.tar.gz.mds
https://www.apache.org/dist/hbase/_version_/hbase-_version_-bin.tar.gz.mds
Project member signature keys can be found at
https://www.apache.org/dist/hbase/KEYS
PGP signatures are available at:
https://www.apache.org/dist/hbase/_version_/hbase-_version_-src.tar.gz.asc
https://www.apache.org/dist/hbase/_version_/hbase-_version_-bin.tar.gz.asc
For instructions on verifying ASF release downloads, please see
https://www.apache.org/dyn/closer.cgi#verify
Question, comments, and problems are always welcome at: d...@hbase.apache.org.
Cheers,
The HBase Dev Team
{code}
lists:
* dev@hbase
* user@hbase
* announce@apache
> document release announcement template
> --
>
> Key: HBASE-15317
> URL: https://issues.apache.org/jira/browse/HBASE-15317
> Project: HBase
> Issue Type: Improvement
> Components: documentation
>Reporter: Sean Busbey
>
> Our release docs should include a release announcement template for folks to
> use (and suggested email lists to send to)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15016) StoreServices facility in Region
[
https://issues.apache.org/jira/browse/HBASE-15016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159728#comment-15159728
]
Hadoop QA commented on HBASE-15016:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
38s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 54s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 56s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 5m
46s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
30s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
52s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 47s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 56s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
11s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 54s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 54s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 57s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 57s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 4m 17s
{color} | {color:red} Patch generated 2 new checkstyle issues in hbase-server
(total was 356, now 354). {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
29s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
27m 13s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m 9s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 45s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 57s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 43s
{color} | {color:green} hbase-common in the patch passed with JDK v1.8.0_72.
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 95m 54s
{color} | {color:green} hbase-server in the patch passed with JDK v1.8.0_72.
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 16s
{color} | {color:green} hbase-common in the patch passed with JDK v1.7.0_95.
{color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 82m 22s {color}
| {color:red} hbase-server in the patch failed with JDK v1.7.0_95. {color} |
| {color:red}-1{color} | {color:red} asflicense {color} | {color:red} 0m 35s
{color} | {color:red} Patch generated 1 ASF License warnings. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 254m 21s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| JDK v1.7.0_95 Failed junit tests |
hadoop.hbase.replication.TestReplicationSmallTests |
| JDK v1.7.0_95 Timed out junit tests |
[jira] [Updated] (HBASE-15306) Make RPC call queue length dynamically configurable
[ https://issues.apache.org/jira/browse/HBASE-15306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Antonov updated HBASE-15306: Status: Open (was: Patch Available) > Make RPC call queue length dynamically configurable > --- > > Key: HBASE-15306 > URL: https://issues.apache.org/jira/browse/HBASE-15306 > Project: HBase > Issue Type: Improvement > Components: IPC/RPC >Affects Versions: 1.2.0 >Reporter: Mikhail Antonov >Assignee: Mikhail Antonov > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15306-v1.patch, HBASE-15306-v2.patch, > HBASE-15306-v3.patch > > > Sometimes it's useful to be able to modify call queue size on prod cluster > without having to do a rolling restart. > Here setting fixed hard limit on call queue size and soft limit which is > dynamically-updatable. > https://reviews.facebook.net/D54579 for review, will test more. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15317) document release announcement template
Sean Busbey created HBASE-15317: --- Summary: document release announcement template Key: HBASE-15317 URL: https://issues.apache.org/jira/browse/HBASE-15317 Project: HBase Issue Type: Improvement Components: documentation Reporter: Sean Busbey Our release docs should include a release announcement template for folks to use (and suggested email lists to send to) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15306) Make RPC call queue length dynamically configurable
[ https://issues.apache.org/jira/browse/HBASE-15306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Antonov updated HBASE-15306: Status: Patch Available (was: Open) > Make RPC call queue length dynamically configurable > --- > > Key: HBASE-15306 > URL: https://issues.apache.org/jira/browse/HBASE-15306 > Project: HBase > Issue Type: Improvement > Components: IPC/RPC >Affects Versions: 1.2.0 >Reporter: Mikhail Antonov >Assignee: Mikhail Antonov > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15306-v1.patch, HBASE-15306-v2.patch, > HBASE-15306-v3.patch > > > Sometimes it's useful to be able to modify call queue size on prod cluster > without having to do a rolling restart. > Here setting fixed hard limit on call queue size and soft limit which is > dynamically-updatable. > https://reviews.facebook.net/D54579 for review, will test more. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15232) Exceptions returned over multi RPC don't automatically trigger region location reloads
[
https://issues.apache.org/jira/browse/HBASE-15232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159724#comment-15159724
]
Hudson commented on HBASE-15232:
SUCCESS: Integrated in HBase-1.2 #561 (See
[https://builds.apache.org/job/HBase-1.2/561/])
HBASE-15232 Handle region location cache mgmt in AsyncProcess for (stack: rev
f502f4ac9b171b8f260b5f4b66caa404227052cd)
*
hbase-client/src/main/java/org/apache/hadoop/hbase/client/HTableMultiplexer.java
*
hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestHTableMultiplexerFlushCache.java
*
hbase-client/src/main/java/org/apache/hadoop/hbase/exceptions/ClientExceptionsUtil.java
*
hbase-client/src/test/java/org/apache/hadoop/hbase/client/TestHTableMultiplexerViaMocks.java
* hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncProcess.java
> Exceptions returned over multi RPC don't automatically trigger region
> location reloads
> --
>
> Key: HBASE-15232
> URL: https://issues.apache.org/jira/browse/HBASE-15232
> Project: HBase
> Issue Type: Sub-task
> Components: Client
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: 2.0.0, 1.3.0, 1.2.1
>
> Attachments: HBASE-15232-branch-1.002.patch, HBASE-15232.001.patch,
> HBASE-15232.002.patch, HBASE-15232.002.patch
>
>
> Follow-on for HBASE-15221:
> A work-around was added in HTableMultiplexer to work around an issue that
> AsyncProcess wasn't clearing the region location cache on Exception. This was
> stemming from the issue that the {{tableName}} is {{null}} because
> HTableMultiplexer is using the {{multi}} RPC. This causes an error that looks
> like:
> {noformat}
> [WARN] Coding error, see method javadoc. row=[B@1673eff, tableName=null
> {noformat}
> HBASE-15221 should fix HTableMultiplexer, but it would be good to push the
> fix down into AsyncProcess instead of using higher-level workarounds.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-15316) Add the ability to cache ROOT_INDEX on reads only
Elliott Clark created HBASE-15316: - Summary: Add the ability to cache ROOT_INDEX on reads only Key: HBASE-15316 URL: https://issues.apache.org/jira/browse/HBASE-15316 Project: HBase Issue Type: Bug Reporter: Elliott Clark For larger data sets it's sometimes not needed to fit the entire index in memory ( there can be cold spots in the data, too much data in index, etc). However it's almost always needed to cache the root index. It's always the hottest blocks of the entire region. We should allow the root index block to be cached in memory on write. We should also do that by default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15130) Backport 0.98 Scan different TimeRange for each column family
[ https://issues.apache.org/jira/browse/HBASE-15130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159650#comment-15159650 ] Andrew Purtell commented on HBASE-15130: Looks good testing locally here, I will commit this tonight unless a build comes back first and indicates something amiss. > Backport 0.98 Scan different TimeRange for each column family > -- > > Key: HBASE-15130 > URL: https://issues.apache.org/jira/browse/HBASE-15130 > Project: HBase > Issue Type: Bug > Components: Client, regionserver, Scanners >Affects Versions: 0.98.17 >Reporter: churro morales >Assignee: churro morales > Fix For: 0.98.18 > > Attachments: HBASE-15130-0.98.patch, HBASE-15130-0.98.v1.patch, > HBASE-15130-0.98.v1.patch, HBASE-15130-0.98.v2.patch, > HBASE-15130-0.98.v3.patch > > > branch 98 version backport for HBASE-14355 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
