date:20140204

[jira] [Commented] (HBASE-10454) Tags presence file info can be wrong in HFiles when PrefixTree encoding is used

2014-02-04 Thread ramkrishna.s.vasudevan (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-10454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13890479#comment-13890479
 ] 

ramkrishna.s.vasudevan commented on HBASE-10454:


+1 on patch.

 Tags presence file info can be wrong in HFiles when PrefixTree encoding is 
 used
 ---

 Key: HBASE-10454
 URL: https://issues.apache.org/jira/browse/HBASE-10454
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.98.0
Reporter: Anoop Sam John
Assignee: Anoop Sam John
Priority: Minor
 Fix For: 0.98.0

 Attachments: HBASE-10454.patch, HBASE-10454_V2.patch


 We always encode tags in case of Prefix tree now and so the code path, while 
 decoding, not checking what is there in FileInfo. So functionally no issues 
 now.
 If we do HBASE-10453 this change will be very important to make sure BC for 
 old files.
 We use the file info MAX_TAGS_LEN to know the presence of tags in a file. In 
 case of prefix tree we always have tags in files even if all kvs have 0 tags. 
  So better we can add this file info into prefix tree encoded HFiles.  Now it 
 get missed.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (HBASE-10463) Filter on columns containing numerics yield wrong results

2014-02-04 Thread Deepa Vasanthkumar (JIRA)

Deepa Vasanthkumar created HBASE-10463:
--

 Summary: Filter on columns containing numerics yield wrong results
 Key: HBASE-10463
 URL: https://issues.apache.org/jira/browse/HBASE-10463
 Project: HBase
  Issue Type: Improvement
  Components: Filters
Affects Versions: 0.94.8
Reporter: Deepa Vasanthkumar


Used SingleColumnValueFilter with CompareFilter.CompareOp.GREATER_OR_EQUAL for 
filtering the scan result. 
However the columns which have numeric value, scan result is not correct, 
because of lexicographic comparison.

Does HBase support numeric value filters (for equal, greater or equal..) for 
columns ? If not, can we add it?




--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (HBASE-10447) Memstore flusher scans storefiles also when the scanner heap gets reset

2014-02-04 Thread ramkrishna.s.vasudevan (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-10447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

ramkrishna.s.vasudevan updated HBASE-10447:
---

Attachment: HBASE-10447_trunk_1.patch

This should be the simplest patches. The constructor that is changed in this
patch is the one that is called over in Compaction and flush. In 0.96 case it
does not add the observers. So should be the case in 0.98 and trunk. Do we
need the reset to happen in compaction? I don't think so.
@apurtell,[~lhofhansl], [~anoop.hbase]
Pls review this patch and if we are ok we could commit this.

Memstore flusher scans storefiles also when the scanner heap gets reset
---

Key: HBASE-10447
URL: https://issues.apache.org/jira/browse/HBASE-10447
Project: HBase
Issue Type: Bug
Affects Versions: 0.98.0, 0.99.0
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan
Priority: Blocker
Fix For: 0.98.0, 0.99.0

Attachments: HBASE-10447_0.98.patch, HBASE-10447_trunk.patch,
HBASE-10447_trunk_1.patch

See the mail thread
http://osdir.com/ml/general/2014-01/msg61294.html
In case of flush we create a memstore flusher which in turn creates a
StoreScanner backed by a Single ton MemstoreScanner.
But this scanner also registers for any updates in the reader in the HStore.
Is this needed?
If this happens then any update on the reader may nullify the current heap
and the entire Scanner Stack is reset, but this time with the other scanners
for all the files that satisfies the last top key. So the flush that happens
on the memstore holds the storefile scanners also in the heap that was
recreated but originally the intention was to create a scanner on the
memstore alone.

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (HBASE-10447) Memstore flusher scans storefiles also when the scanner heap gets reset

2014-02-04 Thread ramkrishna.s.vasudevan (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-10447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ramkrishna.s.vasudevan updated HBASE-10447:
---

Status: Patch Available  (was: Open)

 Memstore flusher scans storefiles also when the scanner heap gets reset
 ---

 Key: HBASE-10447
 URL: https://issues.apache.org/jira/browse/HBASE-10447
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.98.0, 0.99.0
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan
Priority: Blocker
 Fix For: 0.98.0, 0.99.0

 Attachments: HBASE-10447_0.98.patch, HBASE-10447_trunk.patch, 
 HBASE-10447_trunk_1.patch


 See the mail thread
 http://osdir.com/ml/general/2014-01/msg61294.html
 In case of flush we create a memstore flusher which in turn creates a  
 StoreScanner backed by a Single ton MemstoreScanner.  
 But this scanner also registers for any updates in the reader in the HStore.  
 Is this needed?  
 If this happens then any update on the reader may nullify the current heap 
 and the entire Scanner Stack is reset, but this time with the other scanners 
 for all the files that satisfies the last top key.  So the flush that happens 
 on the memstore holds the storefile scanners also in the heap that was 
 recreated but originally the intention was to create a scanner on the 
 memstore alone.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (HBASE-10447) Memstore flusher scans storefiles also when the scanner heap gets reset

2014-02-04 Thread ramkrishna.s.vasudevan (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-10447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ramkrishna.s.vasudevan updated HBASE-10447:
---

Fix Version/s: (was: 0.96.2)
Affects Version/s: (was: 0.96.1.1)
   Status: Open  (was: Patch Available)

removing 0.96 from the fix and affected version.

 Memstore flusher scans storefiles also when the scanner heap gets reset
 ---

 Key: HBASE-10447
 URL: https://issues.apache.org/jira/browse/HBASE-10447
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.98.0, 0.99.0
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan
Priority: Blocker
 Fix For: 0.98.0, 0.99.0

 Attachments: HBASE-10447_0.98.patch, HBASE-10447_trunk.patch, 
 HBASE-10447_trunk_1.patch


 See the mail thread
 http://osdir.com/ml/general/2014-01/msg61294.html
 In case of flush we create a memstore flusher which in turn creates a  
 StoreScanner backed by a Single ton MemstoreScanner.  
 But this scanner also registers for any updates in the reader in the HStore.  
 Is this needed?  
 If this happens then any update on the reader may nullify the current heap 
 and the entire Scanner Stack is reset, but this time with the other scanners 
 for all the files that satisfies the last top key.  So the flush that happens 
 on the memstore holds the storefile scanners also in the heap that was 
 recreated but originally the intention was to create a scanner on the 
 memstore alone.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (HBASE-10463) Filter on columns containing numerics yield wrong results

2014-02-04 Thread Anoop Sam John (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-10463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13890515#comment-13890515
 ] 

Anoop Sam John commented on HBASE-10463:


You can use the below constructor in SCVF?
{code}
public SingleColumnValueFilter(final byte [] family, final byte [] qualifier,
  final CompareOp compareOp, final WritableByteArrayComparable comparator) {
{code}
Instead of the BinaryComparator  you can make a comparator for the numeric 
values and use.

 Filter on columns containing numerics yield wrong results
 -

 Key: HBASE-10463
 URL: https://issues.apache.org/jira/browse/HBASE-10463
 Project: HBase
  Issue Type: Improvement
  Components: Filters
Affects Versions: 0.94.8
Reporter: Deepa Vasanthkumar
   Original Estimate: 168h
  Remaining Estimate: 168h

 Used SingleColumnValueFilter with CompareFilter.CompareOp.GREATER_OR_EQUAL 
 for filtering the scan result. 
 However the columns which have numeric value, scan result is not correct, 
 because of lexicographic comparison.
 Does HBase support numeric value filters (for equal, greater or equal..) for 
 columns ? If not, can we add it?



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (HBASE-10449) Wrong execution pool configuration in HConnectionManager

2014-02-04 Thread Nicolas Liochon (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-10449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13890522#comment-13890522
 ] 

Nicolas Liochon commented on HBASE-10449:
-

Note that we're not exactly changing a default. 
The code wanted to do:
 {panel}Create up to 'max' (default: 256) threads. Expires them if they are not 
used for 10 seconds, excepted for 'core' (default 0) of them. If there is more 
than 'max' tasks, queue them.{panel} 

Actually it was doing:
{panel}Create a single thread, queue all the tasks for this thread.{panel}

So the patch actually implements that was supposed to be implemented (or tries 
to implement it at least :-) ). I

Moreover, it's a regression from HBASE-9917, so actually 96.0 really uses 256 
threads. It's a *96.1* issue only. But yes, it does have an impact on 
performances, and this impact can be good or bad. That's why I would like it to 
be in the .98 RC, and also why I think it's simpler to have the same defaults 
on all versions.

Lastly, and unrelated, we didn't have a limit of the number of threads before 
the .96. I'm wondering if we don't have an impact if a server hangs. The client 
may ends up with all its connections stuck to this server, until it timeouts.

 Wrong execution pool configuration in HConnectionManager
 

 Key: HBASE-10449
 URL: https://issues.apache.org/jira/browse/HBASE-10449
 Project: HBase
  Issue Type: Bug
  Components: Client
Affects Versions: 0.98.0, 0.99.0, 0.96.1.1
Reporter: Nicolas Liochon
Assignee: Nicolas Liochon
Priority: Critical
 Fix For: 0.98.0, 0.96.2, 0.99.0

 Attachments: HBASE-10449.v1.patch


 There is a confusion in the configuration of the pool. The attached patch 
 fixes this. This may change the client performances, as we were using a 
 single thread.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (HBASE-10455) cleanup InterruptedException management

2014-02-04 Thread Nicolas Liochon (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-10455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13890528#comment-13890528
]

Nicolas Liochon commented on HBASE-10455:
-

bq. TestZKSecretWatcher may need fixing after this, if the precommit failure is
not spurious
I've ran the test 30 times locally, it works.

bq. Is this the kind of thing we can catch with FindBugs?
I don't know how to configure FindBugs for this. It could be a specific rule
today. A long time ago, I've added some rules to PMD it was not difficult but
not trivial either (a few hours of work).

cleanup InterruptedException management
---

Key: HBASE-10455
URL: https://issues.apache.org/jira/browse/HBASE-10455
Project: HBase
Issue Type: Bug
Components: Client, master, regionserver
Affects Versions: 0.98.0, 0.99.0
Reporter: Nicolas Liochon
Assignee: Nicolas Liochon
Fix For: 0.98.0, 0.99.0

Attachments: 10455.v1.patch

4 changes in this code:
1) When caught and rethrowed as a IOException we always rethrow
InterruptedIOException
2) When we were both throwing an exception AND resetting the interrupt status
we only throw an exception now.
3) When we were trying to reset the status by Thread.interrupted() (which
does not do that), we now do it for real with a
Thread.currentThread.interrupt().
4) Sometimes, we were rethrowing something else then InterruptedIOException,
while the contract would have allowed it. I've changed this as well.
This patch does not make means that we're fine when we're interrupted, but
we're globally cleaner at least. I will then create other patches specific to
some parts.

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (HBASE-10454) Tags presence file info can be wrong in HFiles when PrefixTree encoding is used

2014-02-04 Thread Anoop Sam John (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-10454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13890538#comment-13890538
 ] 

Anoop Sam John commented on HBASE-10454:


bq.Well, it wouldn't hurt to indicate in the FileInfo that tags are present. 
That part is fine.
[~apurtell]  Said above, I think you are fine with V2 patch. Will commit later 
today.

 Tags presence file info can be wrong in HFiles when PrefixTree encoding is 
 used
 ---

 Key: HBASE-10454
 URL: https://issues.apache.org/jira/browse/HBASE-10454
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.98.0
Reporter: Anoop Sam John
Assignee: Anoop Sam John
Priority: Minor
 Fix For: 0.98.0

 Attachments: HBASE-10454.patch, HBASE-10454_V2.patch


 We always encode tags in case of Prefix tree now and so the code path, while 
 decoding, not checking what is there in FileInfo. So functionally no issues 
 now.
 If we do HBASE-10453 this change will be very important to make sure BC for 
 old files.
 We use the file info MAX_TAGS_LEN to know the presence of tags in a file. In 
 case of prefix tree we always have tags in files even if all kvs have 0 tags. 
  So better we can add this file info into prefix tree encoded HFiles.  Now it 
 get missed.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (HBASE-10413) Tablesplit.getLength returns 0

2014-02-04 Thread Lukas Nalezenec (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-10413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13890550#comment-13890550
 ] 

Lukas Nalezenec commented on HBASE-10413:
-

Hi,
I know it is hacky. It is my first hbase commit, i was not sure how to do it so 
I asked 3 people and then published first draft as soon as possible. Everybody 
was fine with the solution :( .

The hacky solution is good enough for us - I have already deployed it 
yesterday.  I cant spent much more time on this. I need to close it by tomorrow.

How about this solution? I am not sure if it is the best way - it does not work 
with Scan ranges.

ToDos:
We need to filter regions by table
It would be nice to if we could filter size by column families.


https://github.com/apache/hbase/pull/8/files#diff-46ff60f1e27e3d77131acb7873050990R68


   HBaseAdmin admin = new HBaseAdmin(configuration);

ClusterStatus clusterStatus = admin.getClusterStatus();
CollectionServerName servers = clusterStatus.getServers();

for (ServerName serverName: servers) {
  ServerLoad serverLoad = clusterStatus.getLoad(serverName);

  for (Map.Entrybyte[], RegionLoad regionEntry: 
serverLoad.getRegionsLoad().entrySet()) {
byte[] regionId = regionEntry.getKey();
RegionLoad regionLoad = regionEntry.getValue();

long regionSize = 1024 * 1024 * (regionLoad.getMemStoreSizeMB() + 
regionLoad.getStorefileSizeMB());

sizeMap.put(regionId, regionSize);
  }
}

 Tablesplit.getLength returns 0
 --

 Key: HBASE-10413
 URL: https://issues.apache.org/jira/browse/HBASE-10413
 Project: HBase
  Issue Type: Bug
  Components: Client, mapreduce
Affects Versions: 0.96.1.1
Reporter: Lukas Nalezenec
Assignee: Lukas Nalezenec

 InputSplits should be sorted by length but TableSplit does not contain real 
 getLength implementation:
   @Override
   public long getLength() {
 // Not clear how to obtain this... seems to be used only for sorting 
 splits
 return 0;
   }
 This is causing us problem with scheduling - we have got jobs that are 
 supposed to finish in limited time but they get often stuck in last mapper 
 working on large region.
 Can we implement this method ? 
 What is the best way ?
 We were thinking about estimating size by size of files on HDFS.
 We would like to get Scanner from TableSplit, use startRow, stopRow and 
 column families to get corresponding region than computing size of HDFS for 
 given region and column family. 
 Update:
 This ticket was about production issue - I talked with guy who worked on this 
 and he said our production issue was probably not directly caused by 
 getLength() returning 0. 



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (HBASE-10319) HLog should roll periodically to allow DN decommission to eventually complete.

2014-02-04 Thread Matteo Bertozzi (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-10319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matteo Bertozzi updated HBASE-10319:


   Resolution: Fixed
Fix Version/s: 0.94.18
   0.96.2
   0.98.0
   Status: Resolved  (was: Patch Available)

committed to 0.94, 0.96, 0.98 and trunk

 HLog should roll periodically to allow DN decommission to eventually complete.
 --

 Key: HBASE-10319
 URL: https://issues.apache.org/jira/browse/HBASE-10319
 Project: HBase
  Issue Type: Bug
Reporter: Jonathan Hsieh
Assignee: Matteo Bertozzi
 Fix For: 0.98.0, 0.96.2, 0.94.18

 Attachments: HBASE-10319-v0.patch, HBASE-10319-v1.patch


 We encountered a situation where we had an esseitially read only table and 
 attempted to do a clean HDFS DN decommission.  DN's cannot decomission if 
 there are open blocks being written to currently on it.  Because the hbase 
 Hlog file was open, had some data (hlog header), the DN could not 
 decommission itself.  Since no new data is ever written, the existing 
 periodic check is not activated.
 After discussing with [~atm], it seems that although an hdfs semantics change 
 would be ideal (e.g. hbase doesn't have to be aware of hdfs decommission and 
 the client would roll over) this would take much more effort than having 
 hbase periodically force a log roll.  This would enable the hdfs dn con 
 complete.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (HBASE-10461) table.close() in TableEventHandler#reOpenAllRegions() should be enclosed in finally block

2014-02-04 Thread ramkrishna.s.vasudevan (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-10461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13890552#comment-13890552
 ] 

ramkrishna.s.vasudevan commented on HBASE-10461:


+1.. Belated.

 table.close() in TableEventHandler#reOpenAllRegions() should be enclosed in 
 finally block
 -

 Key: HBASE-10461
 URL: https://issues.apache.org/jira/browse/HBASE-10461
 Project: HBase
  Issue Type: Bug
Reporter: Ted Yu
Priority: Minor
 Fix For: 0.98.0, 0.99.0

 Attachments: 10461-v1.txt


 If table.getRegionLocations() throws exception, table.close() would be 
 skipped, leaking the underlying resource



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (HBASE-10413) Tablesplit.getLength returns 0

2014-02-04 Thread Lukas Nalezenec (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-10413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13890559#comment-13890559
 ] 

Lukas Nalezenec commented on HBASE-10413:
-

New version with per table region filtering:
https://github.com/apache/hbase/pull/8/files#diff-46ff60f1e27e3d77131acb7873050990R76

 Tablesplit.getLength returns 0
 --

 Key: HBASE-10413
 URL: https://issues.apache.org/jira/browse/HBASE-10413
 Project: HBase
  Issue Type: Bug
  Components: Client, mapreduce
Affects Versions: 0.96.1.1
Reporter: Lukas Nalezenec
Assignee: Lukas Nalezenec

 InputSplits should be sorted by length but TableSplit does not contain real 
 getLength implementation:
   @Override
   public long getLength() {
 // Not clear how to obtain this... seems to be used only for sorting 
 splits
 return 0;
   }
 This is causing us problem with scheduling - we have got jobs that are 
 supposed to finish in limited time but they get often stuck in last mapper 
 working on large region.
 Can we implement this method ? 
 What is the best way ?
 We were thinking about estimating size by size of files on HDFS.
 We would like to get Scanner from TableSplit, use startRow, stopRow and 
 column families to get corresponding region than computing size of HDFS for 
 given region and column family. 
 Update:
 This ticket was about production issue - I talked with guy who worked on this 
 and he said our production issue was probably not directly caused by 
 getLength() returning 0. 



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (HBASE-10447) Memstore flusher scans storefiles also when the scanner heap gets reset

2014-02-04 Thread Hadoop QA (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-10447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13890563#comment-13890563
]

Hadoop QA commented on HBASE-10447:
---

{color:red}-1 overall{color}. Here are the results of testing the latest
attachment

http://issues.apache.org/jira/secure/attachment/12626849/HBASE-10447_trunk_1.patch
against trunk revision .
ATTACHMENT ID: 12626849

{color:green}+1 @author{color}. The patch does not contain any @author
tags.

{color:red}-1 tests included{color}. 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:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.

{color:green}+1 hadoop1.1{color}. The patch compiles against the hadoop
1.1 profile.

{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.

{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.

{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.

{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.

{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100

{color:green}+1 site{color}. The mvn site goal succeeds with this patch.

{color:green}+1 core tests{color}. The patch passed unit tests in .

Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/8589//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8589//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8589//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8589//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8589//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8589//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8589//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8589//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8589//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8589//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8589//console

This message is automatically generated.

Memstore flusher scans storefiles also when the scanner heap gets reset
---

Attachments: HBASE-10447_0.98.patch, HBASE-10447_trunk.patch,
HBASE-10447_trunk_1.patch

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

1 2 >

1 - 100 of 173 matches

Mail list logo