[jira] [Commented] (HBASE-20618) Skip large rows instead of throwing an exception to client

2018-05-31 Thread Elliott Clark (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-20618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16497357#comment-16497357
 ] 

Elliott Clark commented on HBASE-20618:
---

This seems like the wrong way to go about this. HBase has always been about 
strong consistency. We fail things rather than return the fastest easiest 
answer. That seems like the pattern we should take.

If a row is too big then we already provide the ability to allow partial 
results that can facilitate reading rows too large to send in one rpc.

> Skip large rows instead of throwing an exception to client
> --
>
> Key: HBASE-20618
> URL: https://issues.apache.org/jira/browse/HBASE-20618
> Project: HBase
>  Issue Type: New Feature
>Reporter: Swapna
>Priority: Minor
> Fix For: 3.0.0, 2.0.1, 1.4.5
>
> Attachments: HBASE-20618.hbasemaster.v01.patch, 
> HBASE-20618.hbasemaster.v02.patch, HBASE-20618.v1.branch-1.patch, 
> HBASE-20618.v1.branch-1.patch
>
>
> Currently HBase supports throwing RowTooBigException incase there is a row 
> with one of the column family data exceeds the configured maximum
> https://issues.apache.org/jira/browse/HBASE-10925?attachmentOrder=desc
> We have some bad rows growing very large. We need a way to skip these rows 
> for most of our jobs.
> Some of the options we considered:
> Option 1:
> Hbase client handle the exception and restart the scanner past bad row by 
> capturing the row key where it failed. Can be by adding the rowkey to the 
> exception stack trace, which seems brittle. Client would ignore the setting 
> if its upgraded before server.
> Option 2:
> Skip through big rows on Server.Go with server level config similar to 
> "hbase.table.max.rowsize" or request based by changing the scan request api. 
> If allowed to do per request, based on the scan request config, Client will 
> have to ignore the setting if its upgraded before server.
> {code}
> try {
>  populateResult(results, this.storeHeap, scannerContext, current);
>  } catch(RowTooBigException e) {
>  LOG.info("Row exceeded the limit in storeheap. Skipping row with 
> key:"+Bytes.toString(current.getRowArray()));
>  this.storeHeap.reseek(PrivateCellUtil.createLastOnRow(current));
>  results.clear();
>  scannerContext.clearProgress();
>  continue;
>  }
> {code}
> Prefer the option 2 with server level config. Please share your inputs



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-19646) Add CRON To Major Compaction

2017-12-28 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-19646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16305695#comment-16305695
 ] 

Elliott Clark commented on HBASE-19646:
---

{quote}This is not great if perhaps a SA wants to monitor the system during a 
major compaction{quote}
So that's the thing. There is no way for users to monitor the system during a 
major compaction because major compaction can (and does) happen for lots of 
different reasons other than just time based. Also major compactions even when 
triggered time based are queued and can be delayed for large amounts of time.

{quote} the docs recommend doing a manually triggered major compaction 
anyway.{quote}
The documentation is (in my opinion) incorrect, and we should fix that. The 
majority of users should not have to trigger a major compaction manually. It 
used to be the case that was true. We've put a good amount of effort into 
making the compaction rate limited, and non-disruptive enough that they can, 
and should be done automatically.

{quote}(Hey Elliott Clark!){quote}

/me waves

> Add CRON To Major Compaction
> 
>
> Key: HBASE-19646
> URL: https://issues.apache.org/jira/browse/HBASE-19646
> Project: HBase
>  Issue Type: Bug
>  Components: Compaction
>Reporter: BELUGA BEHR
>Priority: Minor
>
> HBase provides _hbase.hregion.majorcompaction_ 
> {quote}
> Time between major compactions, expressed in milliseconds. Set to 0 to 
> disable time-based automatic major compactions. User-requested and size-based 
> major compactions will still run. This value is multiplied by 
> hbase.hregion.majorcompaction.jitter to cause compaction to start at a 
> somewhat-random time during a given window of time. The default value is 7 
> days, expressed in milliseconds. If major compactions are causing disruption 
> in your environment, you can configure them to run at off-peak times for your 
> deployment, or disable time-based major compactions by setting this parameter 
> to 0, and run major compactions in a cron job or by another external 
> mechanism.
> {quote}
> Instead of this existing mechanism, that adds randomness into a production 
> system (ugh), let's simply allow users to specify a cron string and replace 
> this simple periodic (+jitter) scheduling mechanism.  CRON is useful for 
> systems that have known windows of time (i.e. weekend, nights) that are known 
> to be good times for compaction.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (HBASE-19646) Add CRON To Major Compaction

2017-12-27 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-19646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16304785#comment-16304785
 ] 

Elliott Clark commented on HBASE-19646:
---

Jitter in a production system is one of the most crucial design components to 
ensure even response times, and reduce spiky resource usage for distributed 
systems. We should not suggest configurations that remove this functionality. 
From experience having no jitter is the cause a significant issues in many many 
different HBase user's deployments.

Compactions (including major compactions) should always be an optimization that 
most users should never know about. The default configuration of the system 
should endeavor to make sure that compactions happen in the background at a 
reasonable frequency. To that end we have chosen 1 week (seven days) as a 
amount of time between forced compactions. It's a pretty reasonable thing to 
spread compactions out over a large period of days, for most workloads.

If someone has more customized knowledge and business needs then we should give 
them the ability to script what they want. There's no reason to rebuild cron in 
HBase. Almost all the systems that HBase can be run on already have crond 
installed.

> Add CRON To Major Compaction
> 
>
> Key: HBASE-19646
> URL: https://issues.apache.org/jira/browse/HBASE-19646
> Project: HBase
>  Issue Type: Bug
>  Components: Compaction
>Reporter: BELUGA BEHR
>Priority: Minor
>
> HBase provides _hbase.hregion.majorcompaction_ 
> {quote}
> Time between major compactions, expressed in milliseconds. Set to 0 to 
> disable time-based automatic major compactions. User-requested and size-based 
> major compactions will still run. This value is multiplied by 
> hbase.hregion.majorcompaction.jitter to cause compaction to start at a 
> somewhat-random time during a given window of time. The default value is 7 
> days, expressed in milliseconds. If major compactions are causing disruption 
> in your environment, you can configure them to run at off-peak times for your 
> deployment, or disable time-based major compactions by setting this parameter 
> to 0, and run major compactions in a cron job or by another external 
> mechanism.
> {quote}
> Instead of this existing mechanism, that adds randomness into a production 
> system (ugh), let's simply allow users to specify a cron string and replace 
> this simple periodic (+jitter) scheduling mechanism.  CRON is useful for 
> systems that have known windows of time (i.e. weekend, nights) that are known 
> to be good times for compaction.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (HBASE-16138) Cannot open regions after non-graceful shutdown due to deadlock with Replication Table

2017-05-01 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-16138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15991708#comment-15991708
 ] 

Elliott Clark commented on HBASE-16138:
---

I don't think that anyone is currently working on this. Feel free to pick up 
where they left off if you have free cycles.

> Cannot open regions after non-graceful shutdown due to deadlock with 
> Replication Table
> --
>
> Key: HBASE-16138
> URL: https://issues.apache.org/jira/browse/HBASE-16138
> Project: HBase
>  Issue Type: Sub-task
>  Components: Replication
>Reporter: Joseph
>Assignee: Ashu Pachauri
>Priority: Critical
> Attachments: HBASE-16138.patch, HBASE-16138-v1.patch
>
>
> If we shutdown an entire HBase cluster and attempt to start it back up, we 
> have to run the WAL pre-log roll that occurs before opening up a region. Yet 
> this pre-log roll must record the new WAL inside of ReplicationQueues. This 
> method call ends up blocking on 
> TableBasedReplicationQueues.getOrBlockOnReplicationTable(), because the 
> Replication Table is not up yet. And we cannot assign the Replication Table 
> because we cannot open any regions. This ends up deadlocking the entire 
> cluster whenever we lose Replication Table availability. 
> There are a few options that we can do, but none of them seem very good:
> 1. Depend on Zookeeper-based Replication until the Replication Table becomes 
> available
> 2. Have a separate WAL for System Tables that does not perform any 
> replication (see discussion  at HBASE-14623)
>   Or just have a seperate WAL for non-replicated vs replicated 
> regions
> 3. Record the WAL log in the ReplicationQueue asynchronously (don't block 
> opening a region on this event), which could lead to inconsistent Replication 
> state
> The stacktrace:
> 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.recordLog(ReplicationSourceManager.java:376)
> 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.preLogRoll(ReplicationSourceManager.java:348)
> 
> org.apache.hadoop.hbase.replication.regionserver.Replication.preLogRoll(Replication.java:370)
> 
> org.apache.hadoop.hbase.regionserver.wal.FSHLog.tellListenersAboutPreLogRoll(FSHLog.java:637)
> 
> org.apache.hadoop.hbase.regionserver.wal.FSHLog.rollWriter(FSHLog.java:701)
> 
> org.apache.hadoop.hbase.regionserver.wal.FSHLog.rollWriter(FSHLog.java:600)
> 
> org.apache.hadoop.hbase.regionserver.wal.FSHLog.(FSHLog.java:533)
> 
> org.apache.hadoop.hbase.wal.DefaultWALProvider.getWAL(DefaultWALProvider.java:132)
> 
> org.apache.hadoop.hbase.wal.RegionGroupingProvider.getWAL(RegionGroupingProvider.java:186)
> 
> org.apache.hadoop.hbase.wal.RegionGroupingProvider.getWAL(RegionGroupingProvider.java:197)
> org.apache.hadoop.hbase.wal.WALFactory.getWAL(WALFactory.java:240)
> 
> org.apache.hadoop.hbase.regionserver.HRegionServer.getWAL(HRegionServer.java:1883)
> 
> org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.openRegion(OpenRegionHandler.java:363)
> 
> org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.process(OpenRegionHandler.java:129)
> 
> org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:129)
> 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
> Does anyone have any suggestions/ideas/feedback?
> Attached a review board at: https://reviews.apache.org/r/50546/
> It is still pretty rough, would just like some feedback on it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-16698) Performance issue: handlers stuck waiting for CountDownLatch inside WALKey#getWriteEntry under high writing workload

2016-09-23 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-16698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15517679#comment-15517679
 ] 

Elliott Clark commented on HBASE-16698:
---

If mvcc isn't the same order as the wal log order then there's a chance of acid 
violations.

> Performance issue: handlers stuck waiting for CountDownLatch inside 
> WALKey#getWriteEntry under high writing workload
> 
>
> Key: HBASE-16698
> URL: https://issues.apache.org/jira/browse/HBASE-16698
> Project: HBase
>  Issue Type: Improvement
>  Components: Performance
>Affects Versions: 1.1.6, 1.2.3
>Reporter: Yu Li
>Assignee: Yu Li
> Attachments: HBASE-16698.patch, hadoop0495.et2.jstack
>
>
> As titled, on our production environment we observed 98 out of 128 handlers 
> get stuck waiting for the CountDownLatch {{seqNumAssignedLatch}} inside 
> {{WALKey#getWriteEntry}} under a high writing workload.
> After digging into the problem, we found that the problem is mainly caused by 
> advancing mvcc in the append logic. Below is some detailed analysis:
> Under current branch-1 code logic, all batch puts will call 
> {{WALKey#getWriteEntry}} after appending edit to WAL, and 
> {{seqNumAssignedLatch}} is only released when the relative append call is 
> handled by RingBufferEventHandler (see {{FSWALEntry#stampRegionSequenceId}}). 
> Because currently we're using a single event handler for the ringbuffer, the 
> append calls are handled one by one (actually lot's of our current logic 
> depending on this sequential dealing logic), and this becomes a bottleneck 
> under high writing workload.
> The worst part is that by default we only use one WAL per RS, so appends on 
> all regions are dealt with in sequential, which causes contention among 
> different regions...
> To fix this, we could also take use of the "sequential appends" mechanism, 
> that we could grab the WriteEntry before publishing append onto ringbuffer 
> and use it as sequence id, only that we need to add a lock to make "grab 
> WriteEntry" and "append edit" a transaction. This will still cause contention 
> inside a region but could avoid contention between different regions. This 
> solution is already verified in our online environment and proved to be 
> effective.
> Notice that for master (2.0) branch since we already change the write 
> pipeline to sync before writing memstore (HBASE-15158), this issue only 
> exists for the ASYNC_WAL writes scenario.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16393) Improve computeHDFSBlocksDistribution

2016-08-11 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-16393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15417630#comment-15417630
 ] 

Elliott Clark commented on HBASE-16393:
---

So that one computes the calls after the first one in parallel. There is still 
a lot of work needed to make the first invocation happen in parallel.

> Improve computeHDFSBlocksDistribution
> -
>
> Key: HBASE-16393
> URL: https://issues.apache.org/jira/browse/HBASE-16393
> Project: HBase
>  Issue Type: Improvement
>Reporter: binlijin
>Assignee: binlijin
> Attachments: HBASE-16393.patch
>
>
> With our cluster is big, i can see the balancer is slow from time to time. 
> And the balancer will be called on master startup, so we can see the startup 
> is slow also. 
> The first thing i think whether if we can parallel compute different region's 
> HDFSBlocksDistribution. 
> The second i think we can improve compute single region's 
> HDFSBlocksDistribution.
> When to compute a storefile's HDFSBlocksDistribution first we call 
> FileSystem#getFileStatus(path) and then 
> FileSystem#getFileBlockLocations(status, start, length), so two namenode rpc 
> call for every storefile. Instead we can use FileSystem#listLocatedStatus to 
> get a LocatedFileStatus for the information we need, so reduce the namenode 
> rpc call to one. This can speed the computeHDFSBlocksDistribution, but also 
> send out less rpc call to namenode.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (HBASE-13559) Region stuck in PENDING_OPEN on repeated master failure

2016-08-10 Thread Elliott Clark (JIRA)

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

Elliott Clark resolved HBASE-13559.
---
Resolution: Cannot Reproduce

> Region stuck in PENDING_OPEN on repeated master failure
> ---
>
> Key: HBASE-13559
> URL: https://issues.apache.org/jira/browse/HBASE-13559
> Project: HBase
>  Issue Type: Bug
>Reporter: Elliott Clark
>
> We had some regions stay un-assigned. They were in pending open on a server 
> that was dead. The cluster was restarted as a whole a few times and then the 
> regions were stuck until a manual assign was performed on them.
> I know timing things out has been a pain. Could we have a timeout on servers 
> that are not alive?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-15945) Patch for Cell

2016-08-05 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-15945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15410360#comment-15410360
 ] 

Elliott Clark commented on HBASE-15945:
---

https://github.com/apache/hbase/commit/fa3ab420d19bba853d96576176257b5c12f1a48f

Isn't that it ? It appears to be there on my git checkout ?

> Patch for Cell
> --
>
> Key: HBASE-15945
> URL: https://issues.apache.org/jira/browse/HBASE-15945
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Sudeep Sunthankar
>Assignee: Sudeep Sunthankar
> Attachments: HBASE-15945-HBASE-14850.v2.patch, 
> HBASE-15945-HBASE-14850.v3.patch, HBASE-15945-HBASE-14850.v4.patch, 
> HBASE-15945.HBASE-14850.v1.patch, HBASE-15945.HBASE-14850.v5.patch, 
> HBASE-15945.HBASE-14850.v6.patch
>
>
> This patch contains an implementation of Key Value, Bytes and Cell modeled on 
> the lines of Java implementation.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (HBASE-16365) Hook up Put work flow

2016-08-05 Thread Elliott Clark (JIRA)
Elliott Clark created HBASE-16365:
-

 Summary: Hook up Put work flow
 Key: HBASE-16365
 URL: https://issues.apache.org/jira/browse/HBASE-16365
 Project: HBase
  Issue Type: Sub-task
Reporter: Elliott Clark
Assignee: Elliott Clark






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-15893) Get object

2016-08-05 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-15893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15409785#comment-15409785
 ] 

Elliott Clark commented on HBASE-15893:
---

* None of this is hooked up to the client.
* No Get before getters. Eg GetMaxVersions becomes MaxVersions
* No comments on most of the classes or methods.
* Don't make Get's destructor virtual until we need to. We shouldn't be 
planning to have Get be extendable until we need it.
* GET_FAMILY_MAP is pretty badly named.
* Should we be using shared pointers for ownership of strings in get?
* hbase-native-client/core/get-test.cc no need to include glog. You're not 
using it.
* prefer constexpr over const static in a class. Better yet just don't expose 
that constant at all.
* Don't use unique pointer in time range tests. Tests should be examples of how 
we expect people to create objects and nothing uses unique pointers.
* Max versions should be a uint32_t
* default for SetMaxVersions should be in line with the type and should be the 
same default as our other clients. ( 1 )
* We already have a Consistency enum don't duplicate that.
* Please please don't copy paste.
{code} @throws IllegalArgumentException{code}



> Get object
> --
>
> Key: HBASE-15893
> URL: https://issues.apache.org/jira/browse/HBASE-15893
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Sudeep Sunthankar
>Assignee: Sudeep Sunthankar
> Attachments: HBASE-15893.HBASE-14850.v1.patch, 
> HBASE-15893.HBASE-14850.v2.patch, HBASE-15893.HBASE-14850.v3.patch
>
>
> Patch for creating Get objects.  Get objects can be passed to the Table 
> implementation to fetch results for a given row. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16138) Cannot open regions after non-graceful shutdown due to deadlock with Replication Table

2016-08-03 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-16138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406693#comment-15406693
 ] 

Elliott Clark commented on HBASE-16138:
---

Yeah there's still more work to do (need to have a system table wal so that we 
can make the optimizations for assigning meta more general). 

Though there should be no dead lock issue because of the short circuit 
connections.

> Cannot open regions after non-graceful shutdown due to deadlock with 
> Replication Table
> --
>
> Key: HBASE-16138
> URL: https://issues.apache.org/jira/browse/HBASE-16138
> Project: HBase
>  Issue Type: Sub-task
>  Components: Replication
>Reporter: Joseph
>Assignee: Joseph
>Priority: Critical
> Attachments: HBASE-16138.patch
>
>
> If we shutdown an entire HBase cluster and attempt to start it back up, we 
> have to run the WAL pre-log roll that occurs before opening up a region. Yet 
> this pre-log roll must record the new WAL inside of ReplicationQueues. This 
> method call ends up blocking on 
> TableBasedReplicationQueues.getOrBlockOnReplicationTable(), because the 
> Replication Table is not up yet. And we cannot assign the Replication Table 
> because we cannot open any regions. This ends up deadlocking the entire 
> cluster whenever we lose Replication Table availability. 
> There are a few options that we can do, but none of them seem very good:
> 1. Depend on Zookeeper-based Replication until the Replication Table becomes 
> available
> 2. Have a separate WAL for System Tables that does not perform any 
> replication (see discussion  at HBASE-14623)
>   Or just have a seperate WAL for non-replicated vs replicated 
> regions
> 3. Record the WAL log in the ReplicationQueue asynchronously (don't block 
> opening a region on this event), which could lead to inconsistent Replication 
> state
> The stacktrace:
> 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.recordLog(ReplicationSourceManager.java:376)
> 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.preLogRoll(ReplicationSourceManager.java:348)
> 
> org.apache.hadoop.hbase.replication.regionserver.Replication.preLogRoll(Replication.java:370)
> 
> org.apache.hadoop.hbase.regionserver.wal.FSHLog.tellListenersAboutPreLogRoll(FSHLog.java:637)
> 
> org.apache.hadoop.hbase.regionserver.wal.FSHLog.rollWriter(FSHLog.java:701)
> 
> org.apache.hadoop.hbase.regionserver.wal.FSHLog.rollWriter(FSHLog.java:600)
> 
> org.apache.hadoop.hbase.regionserver.wal.FSHLog.(FSHLog.java:533)
> 
> org.apache.hadoop.hbase.wal.DefaultWALProvider.getWAL(DefaultWALProvider.java:132)
> 
> org.apache.hadoop.hbase.wal.RegionGroupingProvider.getWAL(RegionGroupingProvider.java:186)
> 
> org.apache.hadoop.hbase.wal.RegionGroupingProvider.getWAL(RegionGroupingProvider.java:197)
> org.apache.hadoop.hbase.wal.WALFactory.getWAL(WALFactory.java:240)
> 
> org.apache.hadoop.hbase.regionserver.HRegionServer.getWAL(HRegionServer.java:1883)
> 
> org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.openRegion(OpenRegionHandler.java:363)
> 
> org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.process(OpenRegionHandler.java:129)
> 
> org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:129)
> 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
> Does anyone have any suggestions/ideas/feedback?
> Attached a review board at: https://reviews.apache.org/r/50546/
> It is still pretty rough, would just like some feedback on it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (HBASE-16305) Multi threaded scan performance bottlenecked on Connection

2016-07-29 Thread Elliott Clark (JIRA)
Elliott Clark created HBASE-16305:
-

 Summary: Multi threaded scan performance bottlenecked on Connection
 Key: HBASE-16305
 URL: https://issues.apache.org/jira/browse/HBASE-16305
 Project: HBase
  Issue Type: Bug
Reporter: Elliott Clark


Pretty simple repro. On a single region server host ~10 or more regions. Then 
for each region spawn a thread that starts a scan. Try an pull the scan as fast 
as possible.

If all the scans are created through the same connection then it's slow. If all 
the scans are created through different connections then the scan speed is 
doubled.

Since we recommend a single connection per application this is pretty 
surprising behavior.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16209) Provide an ExponentialBackOffPolicy sleep between failed region open requests

2016-07-29 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16209:
--
   Resolution: Fixed
Fix Version/s: 1.4.0
   2.0.0
   Status: Resolved  (was: Patch Available)

> Provide an ExponentialBackOffPolicy sleep between failed region open requests
> -
>
> Key: HBASE-16209
> URL: https://issues.apache.org/jira/browse/HBASE-16209
> Project: HBase
>  Issue Type: Bug
>Reporter: Joseph
>Assignee: Joseph
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-16209-branch-1.patch, HBASE-16209-v2.patch, 
> HBASE-16209.patch
>
>
> Related to HBASE-16138. As of now we currently have no pause between retrying 
> failed region open requests. And with a low maximumAttempt default, we can 
> quickly use up all our regionOpen retries if the server is in a bad state. I 
> added in a ExponentialBackOffPolicy so that we spread out the timing of our 
> open region retries in AssignmentManager. Review board at 
> https://reviews.apache.org/r/50011/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16096) Replication keeps accumulating znodes

2016-07-28 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16096:
--
   Resolution: Fixed
 Hadoop Flags: Reviewed
Fix Version/s: 1.3.0
   Status: Resolved  (was: Patch Available)

> Replication keeps accumulating znodes
> -
>
> Key: HBASE-16096
> URL: https://issues.apache.org/jira/browse/HBASE-16096
> Project: HBase
>  Issue Type: Bug
>  Components: Replication
>Affects Versions: 2.0.0, 1.2.0, 1.3.0
>Reporter: Ashu Pachauri
>Assignee: Joseph
> Fix For: 2.0.0, 1.3.0, 1.4.0
>
> Attachments: HBASE-16096-branch-1.patch, HBASE-16096.patch
>
>
> If there is an error while creating the replication source on adding the 
> peer, the source if not added to the in memory list of sources but the 
> replication peer is. 
> However, in such a scenario, when you remove the peer, it is deleted from 
> zookeeper successfully but for removing the in memory list of peers, we wait 
> for the corresponding sources to get deleted (which as we said don't exist 
> because of error creating the source). 
> The problem here is the ordering of operations for adding/removing source and 
> peer. 
> Modifying the code to always remove queues from the underlying storage, even 
> if there exists no sources also requires a small refactoring of 
> TableBasedReplicationQueuesImpl to not abort on removeQueues() of an empty 
> queue



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-15937) Figure out retry limit and timing for replication queue table operations

2016-07-27 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-15937:
--
Resolution: Won't Fix
Status: Resolved  (was: Patch Available)

> Figure out retry limit and timing for replication queue table operations
> 
>
> Key: HBASE-15937
> URL: https://issues.apache.org/jira/browse/HBASE-15937
> Project: HBase
>  Issue Type: Sub-task
>  Components: Replication
>Reporter: Joseph
>Assignee: Joseph
> Attachments: HBASE-15937.patch
>
>
> ReplicationQueuesHBaseImpl will abort the server if any of its HBase Table 
> writes/reads fails. We should figure out a reasonable retry limit and pause 
> duration for these operations.
> As of now the timeouts look like: 
> Table initialization:
> 240 retries
> 1 minute pause (because the Master may not be initialized yet, createTable 
> retries are immediately rejected by PleaseHoldException, so we should sleep 
> in between RPC requests)
> 1 minute RPC timeouts
> Total: At minimum 2 hours of retries
> Normal Replication Table operations:
> 240 retries
> 100 millis pause (because we assume the cluster is in a more stable state, we 
> assume most exceptions will be RPC timeouts, so I am using the standard RPC 
> pause)
> 1 minute RPC timeouts
> Total: Assuming operations fail because of RPC timeouts, a minimum of 2 hours 
> of retries. With just pauses we only have 24 seconds. 
> All of these timeouts are configurable too though.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-15937) Figure out retry limit and timing for replication queue table operations

2016-07-22 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-15937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15390451#comment-15390451
 ] 

Elliott Clark commented on HBASE-15937:
---

+1

> Figure out retry limit and timing for replication queue table operations
> 
>
> Key: HBASE-15937
> URL: https://issues.apache.org/jira/browse/HBASE-15937
> Project: HBase
>  Issue Type: Sub-task
>  Components: Replication
>Reporter: Joseph
>Assignee: Joseph
> Attachments: HBASE-15937.patch
>
>
> ReplicationQueuesHBaseImpl will abort the server if any of its HBase Table 
> writes/reads fails. We should figure out a reasonable retry limit and pause 
> duration for these operations.
> As of now the timeouts look like: 
> Table initialization:
> 240 retries
> 1 minute pause (because the Master may not be initialized yet, createTable 
> retries are immediately rejected by PleaseHoldException, so we should sleep 
> in between RPC requests)
> 1 minute RPC timeouts
> Total: At minimum 2 hours of retries
> Normal Replication Table operations:
> 240 retries
> 100 millis pause (because we assume the cluster is in a more stable state, we 
> assume most exceptions will be RPC timeouts, so I am using the standard RPC 
> pause)
> 1 minute RPC timeouts
> Total: Assuming operations fail because of RPC timeouts, a minimum of 2 hours 
> of retries. With just pauses we only have 24 seconds. 
> All of these timeouts are configurable too though.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16096) Replication keeps accumulating znodes

2016-07-22 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-16096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15390446#comment-15390446
 ] 

Elliott Clark commented on HBASE-16096:
---

+1

> Replication keeps accumulating znodes
> -
>
> Key: HBASE-16096
> URL: https://issues.apache.org/jira/browse/HBASE-16096
> Project: HBase
>  Issue Type: Bug
>  Components: Replication
>Affects Versions: 2.0.0, 1.2.0, 1.3.0
>Reporter: Ashu Pachauri
>Assignee: Joseph
> Attachments: HBASE-16096.patch
>
>
> If there is an error while creating the replication source on adding the 
> peer, the source if not added to the in memory list of sources but the 
> replication peer is. 
> However, in such a scenario, when you remove the peer, it is deleted from 
> zookeeper successfully but for removing the in memory list of peers, we wait 
> for the corresponding sources to get deleted (which as we said don't exist 
> because of error creating the source). 
> The problem here is the ordering of operations for adding/removing source and 
> peer. 
> Modifying the code to always remove queues from the underlying storage, even 
> if there exists no sources also requires a small refactoring of 
> TableBasedReplicationQueuesImpl to not abort on removeQueues() of an empty 
> queue



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16262) Update RegionsInTransition UI for branch-1

2016-07-22 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16262:
--
Affects Version/s: 1.4.0
Fix Version/s: (was: 1.3.0)

Pushed to branch-1

> Update RegionsInTransition UI for branch-1
> --
>
> Key: HBASE-16262
> URL: https://issues.apache.org/jira/browse/HBASE-16262
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 1.4.0
>Reporter: Joseph
>Assignee: Joseph
>Priority: Minor
> Fix For: 1.4.0
>
> Attachments: HBASE-16262-branch-1.patch
>
>
> Backport HBASE-13839 to Branch 1. Also make a few style changes in the code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16262) Update RegionsInTransition UI for branch-1

2016-07-22 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16262:
--
   Resolution: Fixed
Fix Version/s: 1.4.0
   1.3.0
   Status: Resolved  (was: Patch Available)

> Update RegionsInTransition UI for branch-1
> --
>
> Key: HBASE-16262
> URL: https://issues.apache.org/jira/browse/HBASE-16262
> Project: HBase
>  Issue Type: Improvement
>Reporter: Joseph
>Assignee: Joseph
>Priority: Minor
> Fix For: 1.3.0, 1.4.0
>
> Attachments: HBASE-16262-branch-1.patch
>
>
> Backport HBASE-13839 to Branch 1. Also make a few style changes in the code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16262) Update RegionsInTransition UI for branch-1

2016-07-22 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-16262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15390438#comment-15390438
 ] 

Elliott Clark commented on HBASE-16262:
---

+1

> Update RegionsInTransition UI for branch-1
> --
>
> Key: HBASE-16262
> URL: https://issues.apache.org/jira/browse/HBASE-16262
> Project: HBase
>  Issue Type: Improvement
>Reporter: Joseph
>Assignee: Joseph
>Priority: Minor
> Attachments: HBASE-16262-branch-1.patch
>
>
> Backport HBASE-13839 to Branch 1. Also make a few style changes in the code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16209) Provide an ExponentialBackOffPolicy sleep between failed region open requests

2016-07-22 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-16209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15390436#comment-15390436
 ] 

Elliott Clark commented on HBASE-16209:
---

TestMasterStatusServlet seems to be consistently broken with this patch. 
Thoughts [~Vegetable26]


> Provide an ExponentialBackOffPolicy sleep between failed region open requests
> -
>
> Key: HBASE-16209
> URL: https://issues.apache.org/jira/browse/HBASE-16209
> Project: HBase
>  Issue Type: Bug
>Reporter: Joseph
>Assignee: Joseph
> Attachments: HBASE-16209.patch
>
>
> Related to HBASE-16138. As of now we currently have no pause between retrying 
> failed region open requests. And with a low maximumAttempt default, we can 
> quickly use up all our regionOpen retries if the server is in a bad state. I 
> added in a ExponentialBackOffPolicy so that we spread out the timing of our 
> open region retries in AssignmentManager. Review board at 
> https://reviews.apache.org/r/50011/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16221) Thrift server drops connection on long scans

2016-07-22 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16221:
--
   Resolution: Fixed
Fix Version/s: 1.4.0
   1.3.0
   2.0.0
   Status: Resolved  (was: Patch Available)

Pushed to branch-1.3+

> Thrift server drops connection on long scans
> 
>
> Key: HBASE-16221
> URL: https://issues.apache.org/jira/browse/HBASE-16221
> Project: HBase
>  Issue Type: Bug
>  Components: Thrift
>Affects Versions: 2.0.0, 1.2.0, 1.3.0
>Reporter: Ashu Pachauri
>Assignee: Joseph
> Fix For: 2.0.0, 1.3.0, 1.4.0
>
> Attachments: HBASE-16221.patch
>
>
> Thrift servers use connection cache and we drop connections after 
> hbase.thrift.connection.max-idletime milliseconds from the last time a 
> connection object was accessed. However, we never update this last accessed 
> time on scan path. 
> By default, this will cause scanners to fail after 10 minutes, if the 
> underlying connection object is not being used along other operation paths 
> (like put).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16221) Thrift server drops connection on long scans

2016-07-22 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-16221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15390433#comment-15390433
 ] 

Elliott Clark commented on HBASE-16221:
---

+1

> Thrift server drops connection on long scans
> 
>
> Key: HBASE-16221
> URL: https://issues.apache.org/jira/browse/HBASE-16221
> Project: HBase
>  Issue Type: Bug
>  Components: Thrift
>Affects Versions: 2.0.0, 1.2.0, 1.3.0
>Reporter: Ashu Pachauri
>Assignee: Joseph
> Attachments: HBASE-16221.patch
>
>
> Thrift servers use connection cache and we drop connections after 
> hbase.thrift.connection.max-idletime milliseconds from the last time a 
> connection object was accessed. However, we never update this last accessed 
> time on scan path. 
> By default, this will cause scanners to fail after 10 minutes, if the 
> underlying connection object is not being used along other operation paths 
> (like put).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16263) Move all to do w/ protobuf -- *.proto files and generated classes -- under hbase-protocol

2016-07-21 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-16263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15387936#comment-15387936
 ] 

Elliott Clark commented on HBASE-16263:
---

Yeah that doesn't sound worth it for such a small clean up.

+1 on the current patch.

> Move all to do w/ protobuf -- *.proto files and generated classes -- under 
> hbase-protocol
> -
>
> Key: HBASE-16263
> URL: https://issues.apache.org/jira/browse/HBASE-16263
> Project: HBase
>  Issue Type: Sub-task
>  Components: Protobufs
>Reporter: stack
>Assignee: stack
> Attachments: HBASE-16263.master.001.patch
>
>
> To better contain our protobuf exposure, keep all to do w/ protobuffing 
> inside the hbase-protocol module.
> This task moves rest, examples, and server proto files that do testing and CP 
> endpoints etc., under hbase-protocol. The patch is big but it is all just 
> moving files.
> interesting to see the copy-paste being done everywhere of proto generation. 
> For this reason alone, it is better to have all the protos in the one place 
> beside doc on how-to, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16263) Move all to do w/ protobuf -- *.proto files and generated classes -- under hbase-protocol

2016-07-20 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-16263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15386803#comment-15386803
 ] 

Elliott Clark commented on HBASE-16263:
---

Should the protobuf files for test be moved into src/test/protobuf ?

> Move all to do w/ protobuf -- *.proto files and generated classes -- under 
> hbase-protocol
> -
>
> Key: HBASE-16263
> URL: https://issues.apache.org/jira/browse/HBASE-16263
> Project: HBase
>  Issue Type: Sub-task
>  Components: Protobufs
>Reporter: stack
>Assignee: stack
> Attachments: HBASE-16263.master.001.patch
>
>
> To better contain our protobuf exposure, keep all to do w/ protobuffing 
> inside the hbase-protocol module.
> This task moves rest, examples, and server proto files that do testing and CP 
> endpoints etc., under hbase-protocol. The patch is big but it is all just 
> moving files.
> interesting to see the copy-paste being done everywhere of proto generation. 
> For this reason alone, it is better to have all the protos in the one place 
> beside doc on how-to, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16208) Make TableBasedReplicationQueuesImpl check that queue exists before attempting to remove it

2016-07-12 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16208:
--
   Resolution: Fixed
 Hadoop Flags: Reviewed
Fix Version/s: 2.0.0
   Status: Resolved  (was: Patch Available)

> Make TableBasedReplicationQueuesImpl check that queue exists before 
> attempting to remove it
> ---
>
> Key: HBASE-16208
> URL: https://issues.apache.org/jira/browse/HBASE-16208
> Project: HBase
>  Issue Type: Sub-task
>  Components: Replication
>Reporter: Joseph
>Assignee: Joseph
> Fix For: 2.0.0
>
> Attachments: HBASE-16208-v1.patch, HBASE-16208-v2.patch, 
> HBASE-16208.patch
>
>
> Currently calling TableBasedReplicationQueuesImpl.removeQueue(String queueId) 
> will cause it to delete the row with the given queue id. Yet this row is not 
> created until the first log is registered for the queue. This causes the 
> server to abort if we every try to remove a queue that has not had a log 
> registered to it yet. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16208) Make TableBasedReplicationQueuesImpl check that queue exists before attempting to remove it

2016-07-12 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-16208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373765#comment-15373765
 ] 

Elliott Clark commented on HBASE-16208:
---

+1

> Make TableBasedReplicationQueuesImpl check that queue exists before 
> attempting to remove it
> ---
>
> Key: HBASE-16208
> URL: https://issues.apache.org/jira/browse/HBASE-16208
> Project: HBase
>  Issue Type: Sub-task
>  Components: Replication
>Reporter: Joseph
>Assignee: Joseph
> Attachments: HBASE-16208-v1.patch, HBASE-16208-v2.patch, 
> HBASE-16208.patch
>
>
> Currently calling TableBasedReplicationQueuesImpl.removeQueue(String queueId) 
> will cause it to delete the row with the given queue id. Yet this row is not 
> created until the first log is registered for the queue. This causes the 
> server to abort if we every try to remove a queue that has not had a log 
> registered to it yet. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (HBASE-16216) Clean up Cell source code.

2016-07-12 Thread Elliott Clark (JIRA)

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

Elliott Clark resolved HBASE-16216.
---
Resolution: Fixed

> Clean up Cell source code.
> --
>
> Key: HBASE-16216
> URL: https://issues.apache.org/jira/browse/HBASE-16216
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Attachments: HBASE-16216.patch
>
>
> formatting.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16214) Add in UI description of Replication Table

2016-07-12 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16214:
--
   Resolution: Fixed
 Hadoop Flags: Reviewed
Fix Version/s: 2.0.0
   Status: Resolved  (was: Patch Available)

Pushed to master.

> Add in UI description of Replication Table
> --
>
> Key: HBASE-16214
> URL: https://issues.apache.org/jira/browse/HBASE-16214
> Project: HBase
>  Issue Type: Sub-task
>  Components: Replication
>Reporter: Joseph
>Assignee: Joseph
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-16214.patch
>
>
> Add a description for the Replication Table in the HBase UI



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16216) Clean up Cell source code.

2016-07-12 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16216:
--
Attachment: HBASE-16216.patch

> Clean up Cell source code.
> --
>
> Key: HBASE-16216
> URL: https://issues.apache.org/jira/browse/HBASE-16216
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Attachments: HBASE-16216.patch
>
>
> formatting.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (HBASE-16216) Clean up Cell source code.

2016-07-12 Thread Elliott Clark (JIRA)
Elliott Clark created HBASE-16216:
-

 Summary: Clean up Cell source code.
 Key: HBASE-16216
 URL: https://issues.apache.org/jira/browse/HBASE-16216
 Project: HBase
  Issue Type: Sub-task
Reporter: Elliott Clark
Assignee: Elliott Clark


formatting.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16214) Add in UI description of Replication Table

2016-07-12 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-16214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373510#comment-15373510
 ] 

Elliott Clark commented on HBASE-16214:
---

+1

> Add in UI description of Replication Table
> --
>
> Key: HBASE-16214
> URL: https://issues.apache.org/jira/browse/HBASE-16214
> Project: HBase
>  Issue Type: Sub-task
>  Components: Replication
>Reporter: Joseph
>Assignee: Joseph
>Priority: Minor
> Attachments: HBASE-16214.patch
>
>
> Add a description for the Replication Table in the HBase UI



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-15643) Need metrics of cache hit ratio, etc for one table

2016-07-12 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-15643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373133#comment-15373133
 ] 

Elliott Clark commented on HBASE-15643:
---

incrementHitForTable does 
{code}
MetricsTableCacheValues val = tableCacheMetricsMap.get(tableName);
{code}

incrementHitForTable/incrementMissForTable is called on every block read.

> Need metrics of cache hit ratio, etc for one table
> --
>
> Key: HBASE-15643
> URL: https://issues.apache.org/jira/browse/HBASE-15643
> Project: HBase
>  Issue Type: Improvement
>Reporter: Heng Chen
>Assignee: Alicia Ying Shu
> Attachments: HBASE-15643.patch
>
>
> There are many tables on our cluster,  only some of them need to be read 
> online.  
> We could improve the performance of read by cache,  but we need some metrics 
> for it at table level. There are a few we can collect: BlockCacheCount, 
> BlockCacheSize, BlockCacheHitCount, BlockCacheMissCount, BlockCacheHitPercent



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-15643) Need metrics of cache hit ratio, etc for one table

2016-07-11 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-15643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371858#comment-15371858
 ] 

Elliott Clark commented on HBASE-15643:
---

-1 No map lookups in the hot code paths.

> Need metrics of cache hit ratio, etc for one table
> --
>
> Key: HBASE-15643
> URL: https://issues.apache.org/jira/browse/HBASE-15643
> Project: HBase
>  Issue Type: Improvement
>Reporter: Heng Chen
>Assignee: Alicia Ying Shu
> Attachments: HBASE-15643.patch
>
>
> There are many tables on our cluster,  only some of them need to be read 
> online.  
> We could improve the performance of read by cache,  but we need some metrics 
> for it at table level. There are a few we can collect: BlockCacheCount, 
> BlockCacheSize, BlockCacheHitCount, BlockCacheMissCount, BlockCacheHitPercent



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16081) Replication remove_peer gets stuck and blocks WAL rolling

2016-07-11 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16081:
--
Affects Version/s: 1.3.0

> Replication remove_peer gets stuck and blocks WAL rolling
> -
>
> Key: HBASE-16081
> URL: https://issues.apache.org/jira/browse/HBASE-16081
> Project: HBase
>  Issue Type: Bug
>  Components: regionserver, Replication
>Affects Versions: 1.3.0
>Reporter: Ashu Pachauri
>Assignee: Joseph
>Priority: Blocker
> Attachments: HBASE-16081.patch
>
>
> We use a blocking take from CompletionService in 
> HBaseInterClusterReplicationEndpoint. When we remove a peer, we try to shut 
> down all threads gracefully. But, under certain race condition, the 
> underlying executor gets shutdown and the CompletionService#take will block 
> forever, which means the remove_peer call will never gracefully finish.
> Since ReplicationSourceManager#removePeer and 
> ReplicationSourceManager#recordLog lock on the same object, we are not able 
> to roll WALs in such a situation and will end up with gigantic WALs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16081) Replication remove_peer gets stuck and blocks WAL rolling

2016-07-11 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16081:
--
Priority: Blocker  (was: Critical)

> Replication remove_peer gets stuck and blocks WAL rolling
> -
>
> Key: HBASE-16081
> URL: https://issues.apache.org/jira/browse/HBASE-16081
> Project: HBase
>  Issue Type: Bug
>  Components: regionserver, Replication
>Affects Versions: 1.3.0
>Reporter: Ashu Pachauri
>Assignee: Joseph
>Priority: Blocker
> Attachments: HBASE-16081.patch
>
>
> We use a blocking take from CompletionService in 
> HBaseInterClusterReplicationEndpoint. When we remove a peer, we try to shut 
> down all threads gracefully. But, under certain race condition, the 
> underlying executor gets shutdown and the CompletionService#take will block 
> forever, which means the remove_peer call will never gracefully finish.
> Since ReplicationSourceManager#removePeer and 
> ReplicationSourceManager#recordLog lock on the same object, we are not able 
> to roll WALs in such a situation and will end up with gigantic WALs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16081) Replication remove_peer gets stuck and blocks WAL rolling

2016-07-11 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16081:
--
Status: Patch Available  (was: Open)

> Replication remove_peer gets stuck and blocks WAL rolling
> -
>
> Key: HBASE-16081
> URL: https://issues.apache.org/jira/browse/HBASE-16081
> Project: HBase
>  Issue Type: Bug
>  Components: regionserver, Replication
>Reporter: Ashu Pachauri
>Assignee: Joseph
>Priority: Critical
> Attachments: HBASE-16081.patch
>
>
> We use a blocking take from CompletionService in 
> HBaseInterClusterReplicationEndpoint. When we remove a peer, we try to shut 
> down all threads gracefully. But, under certain race condition, the 
> underlying executor gets shutdown and the CompletionService#take will block 
> forever, which means the remove_peer call will never gracefully finish.
> Since ReplicationSourceManager#removePeer and 
> ReplicationSourceManager#recordLog lock on the same object, we are not able 
> to roll WALs in such a situation and will end up with gigantic WALs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-15414) Bound the size of multi request returns and/or allow return of partial result up to client

2016-07-11 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-15414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371495#comment-15371495
 ] 

Elliott Clark commented on HBASE-15414:
---

Multi-gets are already chunked ( HBASE-14978 HBASE-14946 ). So the server won't 
respond with too much data. However there is currently no way to get those 
chunks on the client side as they come in.

> Bound the size of multi request returns and/or allow return of partial result 
> up to client
> --
>
> Key: HBASE-15414
> URL: https://issues.apache.org/jira/browse/HBASE-15414
> Project: HBase
>  Issue Type: Improvement
>  Components: Client, rpc
>Reporter: stack
>
> Some knowledgeable hbase users note that while Scanning now allows you return 
> results in 'chunks' for assembly client-side as a whole result (or the 
> application can see the partials as they come out of the cluster), this 
> ability is absent if you do a multi-get; you might get back more than you 
> bargained for and just as chunking when Scanning makes sense because it makes 
> hbase 'regular', we need the same for multiget.
> Parking an issue here for discussion.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16087) Replication shouldn't start on a master if if only hosts system tables

2016-07-11 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16087:
--
   Resolution: Fixed
Fix Version/s: 1.4.0
   1.3.0
   2.0.0
 Release Note: 
Masters will no longer start any replication threads if they are hosting only 
system tables. 

In order to change this add something to the config for tables on master that 
doesn't start with "hbase:" ( Replicating system tables is something that's 
currently unsupported and can open up security holes, so do this at your own 
peril)
   Status: Resolved  (was: Patch Available)

> Replication shouldn't start on a master if if only hosts system tables
> --
>
> Key: HBASE-16087
> URL: https://issues.apache.org/jira/browse/HBASE-16087
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 2.0.0, 1.3.0
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Fix For: 2.0.0, 1.3.0, 1.4.0
>
> Attachments: HBASE-16087.patch, HBASE-16087.v1.patch
>
>
> System tables aren't replicated so we shouldn't start up a replication master 
> if there are no user tables on the master.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16208) Make TableBasedReplicationQueuesImpl check that queue exists before attempting to remove it

2016-07-11 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-16208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371472#comment-15371472
 ] 

Elliott Clark commented on HBASE-16208:
---

Is there a race here? Could someone be trying to add that exact queue while you 
are trying to delete it?

> Make TableBasedReplicationQueuesImpl check that queue exists before 
> attempting to remove it
> ---
>
> Key: HBASE-16208
> URL: https://issues.apache.org/jira/browse/HBASE-16208
> Project: HBase
>  Issue Type: Sub-task
>  Components: Replication
>Reporter: Joseph
>Assignee: Joseph
> Attachments: HBASE-16208.patch
>
>
> Currently calling TableBasedReplicationQueuesImpl.removeQueue(String queueId) 
> will cause it to delete the row with the given queue id. Yet this row is not 
> created until the first log is registered for the queue. This causes the 
> server to abort if we every try to remove a queue that has not had a log 
> registered to it yet. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16196) Update jruby to a newer version.

2016-07-08 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-16196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15368012#comment-15368012
 ] 

Elliott Clark commented on HBASE-16196:
---

bq.It seems worth a user@ message to gauge impact.
Yeah let me do it.

> Update jruby to a newer version.
> 
>
> Key: HBASE-16196
> URL: https://issues.apache.org/jira/browse/HBASE-16196
> Project: HBase
>  Issue Type: Bug
>  Components: dependencies, shell
>Reporter: Elliott Clark
>Assignee: Matt Mullins
> Attachments: 0001-Update-to-JRuby-9.1.2.0-and-JLine-2.12.patch, 
> hbase-16196.branch-1.patch
>
>
> Ruby 1.8.7 is no longer maintained.
> The TTY library in the old jruby is bad. The newer one is less bad.
> Since this is only a dependency on the hbase-shell module and not on 
> hbase-client or hbase-server this should be a pretty simple thing that 
> doesn't have any backwards compat issues.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16196) Update jruby to a newer version.

2016-07-08 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-16196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15367940#comment-15367940
 ] 

Elliott Clark commented on HBASE-16196:
---

I would think it's different because the shell isn't pulled in when people 
develop on top of the hbase-server and hbase-client modules. We've said for 
quite a while that the shell is there for convenience and that it's really bad. 
We've had times where output on the shell is changed, arguments accepted are 
changed, all in minor releases. This treatment of shell has always lead me to 
believe it's in the operational compatibility. 

Said another way, the shell should only be used for operational stuff, and 
testing. It's not good enough for us to encourage any production use cases 
built on it.

> Update jruby to a newer version.
> 
>
> Key: HBASE-16196
> URL: https://issues.apache.org/jira/browse/HBASE-16196
> Project: HBase
>  Issue Type: Bug
>  Components: dependencies, shell
>Reporter: Elliott Clark
>Assignee: Matt Mullins
> Attachments: 0001-Update-to-JRuby-9.1.2.0-and-JLine-2.12.patch, 
> hbase-16196.branch-1.patch
>
>
> Ruby 1.8.7 is no longer maintained.
> The TTY library in the old jruby is bad. The newer one is less bad.
> Since this is only a dependency on the hbase-shell module and not on 
> hbase-client or hbase-server this should be a pretty simple thing that 
> doesn't have any backwards compat issues.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16196) Update jruby to a newer version.

2016-07-08 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-16196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15367919#comment-15367919
 ] 

Elliott Clark commented on HBASE-16196:
---

bq.we run in "Ruby 1.8" mode by default.

We've made no promises around the shell, that I know of. This would be an 
operational compatibility change which is explicitly called out as only be on 
patch releases.

> Update jruby to a newer version.
> 
>
> Key: HBASE-16196
> URL: https://issues.apache.org/jira/browse/HBASE-16196
> Project: HBase
>  Issue Type: Bug
>  Components: dependencies, shell
>Reporter: Elliott Clark
>Assignee: Matt Mullins
> Attachments: 0001-Update-to-JRuby-9.1.2.0-and-JLine-2.12.patch, 
> hbase-16196.branch-1.patch
>
>
> Ruby 1.8.7 is no longer maintained.
> The TTY library in the old jruby is bad. The newer one is less bad.
> Since this is only a dependency on the hbase-shell module and not on 
> hbase-client or hbase-server this should be a pretty simple thing that 
> doesn't have any backwards compat issues.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-15935) Have a separate Walker task running concurrently with Generator

2016-07-08 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-15935:
--
   Resolution: Fixed
 Hadoop Flags: Reviewed
Fix Version/s: 1.4.0
   1.3.0
   2.0.0
   Status: Resolved  (was: Patch Available)

Thanks for the patch.

> Have a separate Walker task running concurrently with Generator   
> --
>
> Key: HBASE-15935
> URL: https://issues.apache.org/jira/browse/HBASE-15935
> Project: HBase
>  Issue Type: Sub-task
>  Components: integration tests
>Reporter: Joseph
>Assignee: Joseph
>Priority: Minor
> Fix For: 2.0.0, 1.3.0, 1.4.0
>
> Attachments: HBASE-15935.patch
>
>
> Keep track of which linked lists have been flushed in an HBase table, so that 
> we can concurrently Walk these lists during the Generation phase. This will 
> allow us to test:
> 1. HBase under concurrent read/writes
> 2. Availability of data immediately after flushes (as opposed to waiting till 
> the Verification phase)
> The review diff can be found at:
> https://reviews.apache.org/r/48294/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-15935) Have a separate Walker task running concurrently with Generator

2016-07-07 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-15935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15366715#comment-15366715
 ] 

Elliott Clark commented on HBASE-15935:
---

[~stack] You ok with a commit after the comment above ?

> Have a separate Walker task running concurrently with Generator   
> --
>
> Key: HBASE-15935
> URL: https://issues.apache.org/jira/browse/HBASE-15935
> Project: HBase
>  Issue Type: Sub-task
>  Components: integration tests
>Reporter: Joseph
>Assignee: Joseph
>Priority: Minor
> Attachments: HBASE-15935.patch
>
>
> Keep track of which linked lists have been flushed in an HBase table, so that 
> we can concurrently Walk these lists during the Generation phase. This will 
> allow us to test:
> 1. HBase under concurrent read/writes
> 2. Availability of data immediately after flushes (as opposed to waiting till 
> the Verification phase)
> The review diff can be found at:
> https://reviews.apache.org/r/48294/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16174) Hook cell test up, and fix broken cell test.

2016-07-07 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16174:
--
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Hook cell test up, and fix broken cell test.
> 
>
> Key: HBASE-16174
> URL: https://issues.apache.org/jira/browse/HBASE-16174
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Attachments: HBASE-16174.HBASE-14850.patch
>
>
> Make sure that cell test is working properly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16196) Update jruby to a newer version.

2016-07-07 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16196:
--
Status: Patch Available  (was: Open)

> Update jruby to a newer version.
> 
>
> Key: HBASE-16196
> URL: https://issues.apache.org/jira/browse/HBASE-16196
> Project: HBase
>  Issue Type: Bug
>Reporter: Elliott Clark
>Assignee: Matt Mullins
> Attachments: 0001-Update-to-JRuby-9.1.2.0-and-JLine-2.12.patch
>
>
> Ruby 1.8.7 is no longer maintained.
> The TTY library in the old jruby is bad. The newer one is less bad.
> Since this is only a dependency on the hbase-shell module and not on 
> hbase-client or hbase-server this should be a pretty simple thing that 
> doesn't have any backwards compat issues.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16196) Update jruby to a newer version.

2016-07-07 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16196:
--
Assignee: Matt Mullins

> Update jruby to a newer version.
> 
>
> Key: HBASE-16196
> URL: https://issues.apache.org/jira/browse/HBASE-16196
> Project: HBase
>  Issue Type: Bug
>Reporter: Elliott Clark
>Assignee: Matt Mullins
>
> Ruby 1.8.7 is no longer maintained.
> The TTY library in the old jruby is bad. The newer one is less bad.
> Since this is only a dependency on the hbase-shell module and not on 
> hbase-client or hbase-server this should be a pretty simple thing that 
> doesn't have any backwards compat issues.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (HBASE-16196) Update jruby to a newer version.

2016-07-07 Thread Elliott Clark (JIRA)
Elliott Clark created HBASE-16196:
-

 Summary: Update jruby to a newer version.
 Key: HBASE-16196
 URL: https://issues.apache.org/jira/browse/HBASE-16196
 Project: HBase
  Issue Type: Bug
Reporter: Elliott Clark


Ruby 1.8.7 is no longer maintained.
The TTY library in the old jruby is bad. The newer one is less bad.

Since this is only a dependency on the hbase-shell module and not on 
hbase-client or hbase-server this should be a pretty simple thing that doesn't 
have any backwards compat issues.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16169) RegionSizeCalculator should not depend on master

2016-07-06 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-16169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15365226#comment-15365226
 ] 

Elliott Clark commented on HBASE-16169:
---

Can you explain a little more about why going to the master is an issue ?

> RegionSizeCalculator should not depend on master
> 
>
> Key: HBASE-16169
> URL: https://issues.apache.org/jira/browse/HBASE-16169
> Project: HBase
>  Issue Type: Sub-task
>  Components: mapreduce, scaling
>Reporter: Thiruvel Thirumoolan
>Assignee: Thiruvel Thirumoolan
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-16169.master.000.patch
>
>
> RegionSizeCalculator is needed for better split generation of MR jobs. This 
> requires RegionLoad which can be obtained via ClusterStatus, i.e. accessing 
> Master. We don't want master to be in this path.
> The proposal is to add an API to the RegionServer that gets RegionLoad of all 
> regions hosted on it or those of a table if specified. RegionSizeCalculator 
> can use the latter.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16074) ITBLL fails, reports lost big or tiny families

2016-07-06 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-16074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15365223#comment-15365223
 ] 

Elliott Clark commented on HBASE-16074:
---

bq.I'm still not clear, based on the discussion, if this is a new issue 
impacting branch-1.2

At this point we're not sure. We're pretty sure that TRT isn't the only issue. 
Either there were two bugs, TRT and something as of yet un-found, or TRT just 
made seeing the issues easier. Either way, since without TRT changes the issue 
shows up less, we don't have a lot of confidence on when the issues started.

> ITBLL fails, reports lost big or tiny families
> --
>
> Key: HBASE-16074
> URL: https://issues.apache.org/jira/browse/HBASE-16074
> Project: HBase
>  Issue Type: Bug
>  Components: integration tests
>Affects Versions: 1.3.0, 0.98.20
>Reporter: Mikhail Antonov
>Assignee: Mikhail Antonov
>Priority: Blocker
> Fix For: 2.0.0, 1.3.0, 1.4.0, 0.98.21
>
> Attachments: 16074.test.branch-1.3.patch, 16074.test.patch, 
> HBASE-16074.branch-1.3.001.patch, HBASE-16074.branch-1.3.002.patch, 
> HBASE-16074.branch-1.3.003.patch, HBASE-16074.branch-1.3.003.patch, 
> changes_to_stress_ITBLL.patch, changes_to_stress_ITBLL__a_bit_relaxed_.patch, 
> itbll log with failure, itbll log with success
>
>
> Underlying MR jobs succeed but I'm seeing the following in the logs (mid-size 
> distributed test cluster):
> ERROR test.IntegrationTestBigLinkedList$Verify: Found nodes which lost big or 
> tiny families, count=164
> I do not know exactly yet whether it's a bug, a test issue or env setup 
> issue, but need figure it out. Opening this to raise awareness and see if 
> someone saw that recently.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-15935) Have a separate Walker task running concurrently with Generator

2016-07-06 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-15935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15365100#comment-15365100
 ] 

Elliott Clark commented on HBASE-15935:
---

+1

> Have a separate Walker task running concurrently with Generator   
> --
>
> Key: HBASE-15935
> URL: https://issues.apache.org/jira/browse/HBASE-15935
> Project: HBase
>  Issue Type: Sub-task
>  Components: integration tests
>Reporter: Joseph
>Assignee: Joseph
>Priority: Minor
> Attachments: HBASE-15935.patch
>
>
> Keep track of which linked lists have been flushed in an HBase table, so that 
> we can concurrently Walk these lists during the Generation phase. This will 
> allow us to test:
> 1. HBase under concurrent read/writes
> 2. Availability of data immediately after flushes (as opposed to waiting till 
> the Verification phase)
> The review diff can be found at:
> https://reviews.apache.org/r/48294/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16187) Fix typo in blog post for metrics2

2016-07-06 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-16187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15364944#comment-15364944
 ] 

Elliott Clark commented on HBASE-16187:
---

s/Clarke/Clark/g

> Fix typo in blog post for metrics2
> --
>
> Key: HBASE-16187
> URL: https://issues.apache.org/jira/browse/HBASE-16187
> Project: HBase
>  Issue Type: Bug
>  Components: website
>Reporter: Lars George
>Assignee: Sean Busbey
> Fix For: 2.0.0
>
>
> See https://blogs.apache.org/hbase/entry/migration_to_the_new_metrics
> s/sudo/pseudo



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16087) Replication shouldn't start on a master if if only hosts system tables

2016-07-06 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-16087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15364869#comment-15364869
 ] 

Elliott Clark commented on HBASE-16087:
---

You don't have to create the table, just list it in the config.

> Replication shouldn't start on a master if if only hosts system tables
> --
>
> Key: HBASE-16087
> URL: https://issues.apache.org/jira/browse/HBASE-16087
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 2.0.0, 1.3.0
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Attachments: HBASE-16087.patch, HBASE-16087.v1.patch
>
>
> System tables aren't replicated so we shouldn't start up a replication master 
> if there are no user tables on the master.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16081) Replication remove_peer gets stuck and blocks WAL rolling

2016-07-05 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-16081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15363145#comment-15363145
 ] 

Elliott Clark commented on HBASE-16081:
---

Please describe the whole deadlock in the code. Forcing people to read from two 
places means that the info won't be read by many.

> Replication remove_peer gets stuck and blocks WAL rolling
> -
>
> Key: HBASE-16081
> URL: https://issues.apache.org/jira/browse/HBASE-16081
> Project: HBase
>  Issue Type: Bug
>  Components: regionserver, Replication
>Reporter: Ashu Pachauri
>Assignee: Joseph
>Priority: Critical
> Attachments: HBASE-16081.patch
>
>
> We use a blocking take from CompletionService in 
> HBaseInterClusterReplicationEndpoint. When we remove a peer, we try to shut 
> down all threads gracefully. But, under certain race condition, the 
> underlying executor gets shutdown and the CompletionService#take will block 
> forever, which means the remove_peer call will never gracefully finish.
> Since ReplicationSourceManager#removePeer and 
> ReplicationSourceManager#recordLog lock on the same object, we are not able 
> to roll WALs in such a situation and will end up with gigantic WALs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16081) Replication remove_peer gets stuck and blocks WAL rolling

2016-07-05 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16081:
--
Priority: Critical  (was: Major)

> Replication remove_peer gets stuck and blocks WAL rolling
> -
>
> Key: HBASE-16081
> URL: https://issues.apache.org/jira/browse/HBASE-16081
> Project: HBase
>  Issue Type: Bug
>  Components: regionserver, Replication
>Reporter: Ashu Pachauri
>Assignee: Joseph
>Priority: Critical
> Attachments: HBASE-16081.patch
>
>
> We use a blocking take from CompletionService in 
> HBaseInterClusterReplicationEndpoint. When we remove a peer, we try to shut 
> down all threads gracefully. But, under certain race condition, the 
> underlying executor gets shutdown and the CompletionService#take will block 
> forever, which means the remove_peer call will never gracefully finish.
> Since ReplicationSourceManager#removePeer and 
> ReplicationSourceManager#recordLog lock on the same object, we are not able 
> to roll WALs in such a situation and will end up with gigantic WALs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16177) In dev mode thrift server can't be run

2016-07-05 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-16177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15363049#comment-15363049
 ] 

Elliott Clark commented on HBASE-16177:
---

Pushed, thanks.

> In dev mode thrift server can't be run
> --
>
> Key: HBASE-16177
> URL: https://issues.apache.org/jira/browse/HBASE-16177
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 1.3.0, 1.2.1
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Fix For: 2.0.0, 1.3.0, 1.4.0
>
> Attachments: HBASE-16177.patch
>
>
> {code}
> Error: Could not find or load main class 
> org.apache.hadoop.hbase.thrift2.ThriftServer
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16177) In dev mode thrift server can't be run

2016-07-05 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16177:
--
   Resolution: Fixed
Fix Version/s: 1.4.0
   1.3.0
   2.0.0
   Status: Resolved  (was: Patch Available)

> In dev mode thrift server can't be run
> --
>
> Key: HBASE-16177
> URL: https://issues.apache.org/jira/browse/HBASE-16177
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 1.3.0, 1.2.1
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Fix For: 2.0.0, 1.3.0, 1.4.0
>
> Attachments: HBASE-16177.patch
>
>
> {code}
> Error: Could not find or load main class 
> org.apache.hadoop.hbase.thrift2.ThriftServer
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16177) In dev mode thrift server can't be run

2016-07-05 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16177:
--
Affects Version/s: 1.3.0
   1.2.1
   Status: Patch Available  (was: Open)

> In dev mode thrift server can't be run
> --
>
> Key: HBASE-16177
> URL: https://issues.apache.org/jira/browse/HBASE-16177
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 1.2.1, 1.3.0
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Attachments: HBASE-16177.patch
>
>
> {code}
> Error: Could not find or load main class 
> org.apache.hadoop.hbase.thrift2.ThriftServer
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16177) In dev mode thrift server can't be run

2016-07-05 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16177:
--
Attachment: HBASE-16177.patch

> In dev mode thrift server can't be run
> --
>
> Key: HBASE-16177
> URL: https://issues.apache.org/jira/browse/HBASE-16177
> Project: HBase
>  Issue Type: Bug
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Attachments: HBASE-16177.patch
>
>
> {code}
> Error: Could not find or load main class 
> org.apache.hadoop.hbase.thrift2.ThriftServer
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (HBASE-16177) In dev mode thrift server can't be run

2016-07-05 Thread Elliott Clark (JIRA)
Elliott Clark created HBASE-16177:
-

 Summary: In dev mode thrift server can't be run
 Key: HBASE-16177
 URL: https://issues.apache.org/jira/browse/HBASE-16177
 Project: HBase
  Issue Type: Bug
Reporter: Elliott Clark
Assignee: Elliott Clark


{code}
Error: Could not find or load main class 
org.apache.hadoop.hbase.thrift2.ThriftServer
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16174) Hook cell test up, and fix broken cell test.

2016-07-05 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16174:
--
Attachment: HBASE-16174.HBASE-14850.patch

> Hook cell test up, and fix broken cell test.
> 
>
> Key: HBASE-16174
> URL: https://issues.apache.org/jira/browse/HBASE-16174
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Attachments: HBASE-16174.HBASE-14850.patch
>
>
> Make sure that cell test is working properly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16174) Hook cell test up, and fix broken cell tests.

2016-07-05 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16174:
--
Summary: Hook cell test up, and fix broken cell tests.  (was: Hook cell 
test up)

> Hook cell test up, and fix broken cell tests.
> -
>
> Key: HBASE-16174
> URL: https://issues.apache.org/jira/browse/HBASE-16174
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Elliott Clark
>Assignee: Elliott Clark
>
> Make sure that cell test is working properly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16174) Hook cell test up, and fix broken cell test.

2016-07-05 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16174:
--
Summary: Hook cell test up, and fix broken cell test.  (was: Hook cell test 
up, and fix broken cell tests.)

> Hook cell test up, and fix broken cell test.
> 
>
> Key: HBASE-16174
> URL: https://issues.apache.org/jira/browse/HBASE-16174
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Elliott Clark
>Assignee: Elliott Clark
>
> Make sure that cell test is working properly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (HBASE-16174) Hook cell test up

2016-07-05 Thread Elliott Clark (JIRA)
Elliott Clark created HBASE-16174:
-

 Summary: Hook cell test up
 Key: HBASE-16174
 URL: https://issues.apache.org/jira/browse/HBASE-16174
 Project: HBase
  Issue Type: Sub-task
Reporter: Elliott Clark
Assignee: Elliott Clark


Make sure that cell test is working properly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (HBASE-15945) Patch for Cell

2016-07-05 Thread Elliott Clark (JIRA)

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

Elliott Clark resolved HBASE-15945.
---
Resolution: Fixed

> Patch for Cell
> --
>
> Key: HBASE-15945
> URL: https://issues.apache.org/jira/browse/HBASE-15945
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Sudeep Sunthankar
>Assignee: Sudeep Sunthankar
> Attachments: HBASE-15945-HBASE-14850.v2.patch, 
> HBASE-15945-HBASE-14850.v3.patch, HBASE-15945-HBASE-14850.v4.patch, 
> HBASE-15945.HBASE-14850.v1.patch, HBASE-15945.HBASE-14850.v5.patch, 
> HBASE-15945.HBASE-14850.v6.patch
>
>
> This patch contains an implementation of Key Value, Bytes and Cell modeled on 
> the lines of Java implementation.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-15945) Patch for Cell

2016-07-05 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-15945:
--
Summary: Patch for Cell  (was: Patch for Cell and CellImpl)

> Patch for Cell
> --
>
> Key: HBASE-15945
> URL: https://issues.apache.org/jira/browse/HBASE-15945
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Sudeep Sunthankar
>Assignee: Sudeep Sunthankar
> Attachments: HBASE-15945-HBASE-14850.v2.patch, 
> HBASE-15945-HBASE-14850.v3.patch, HBASE-15945-HBASE-14850.v4.patch, 
> HBASE-15945.HBASE-14850.v1.patch, HBASE-15945.HBASE-14850.v5.patch, 
> HBASE-15945.HBASE-14850.v6.patch
>
>
> This patch contains an implementation of Key Value, Bytes and Cell modeled on 
> the lines of Java implementation.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-15945) Patch for Cell and CellImpl

2016-07-05 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-15945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15362779#comment-15362779
 ] 

Elliott Clark commented on HBASE-15945:
---

+1 lgtm

> Patch for Cell and CellImpl
> ---
>
> Key: HBASE-15945
> URL: https://issues.apache.org/jira/browse/HBASE-15945
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Sudeep Sunthankar
>Assignee: Sudeep Sunthankar
> Attachments: HBASE-15945-HBASE-14850.v2.patch, 
> HBASE-15945-HBASE-14850.v3.patch, HBASE-15945-HBASE-14850.v4.patch, 
> HBASE-15945.HBASE-14850.v1.patch, HBASE-15945.HBASE-14850.v5.patch, 
> HBASE-15945.HBASE-14850.v6.patch
>
>
> This patch contains an implementation of Key Value, Bytes and Cell modeled on 
> the lines of Java implementation.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-15945) Patch for Cell and CellImpl

2016-07-02 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-15945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15360397#comment-15360397
 ] 

Elliott Clark commented on HBASE-15945:
---

No need for the interface and the implementation because of how hard getting 
c++ abi compatibility is.
I'd prefer a patch that hooks everything up, rather than just adding orphaned 
classes.

> Patch for Cell and CellImpl
> ---
>
> Key: HBASE-15945
> URL: https://issues.apache.org/jira/browse/HBASE-15945
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Sudeep Sunthankar
>Assignee: Sudeep Sunthankar
> Attachments: HBASE-15945-HBASE-14850.v2.patch, 
> HBASE-15945-HBASE-14850.v3.patch, HBASE-15945-HBASE-14850.v4.patch, 
> HBASE-15945.HBASE-14850.v1.patch, HBASE-15945.HBASE-14850.v5.patch
>
>
> This patch contains an implementation of Key Value, Bytes and Cell modeled on 
> the lines of Java implementation.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16089) Add on FastPath for CoDel

2016-06-25 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16089:
--
   Resolution: Fixed
 Hadoop Flags: Reviewed
Fix Version/s: 1.4.0
   1.3.0
   2.0.0
   Status: Resolved  (was: Patch Available)

Pushed to master, branch-1, and branch-1.3

> Add on FastPath for CoDel
> -
>
> Key: HBASE-16089
> URL: https://issues.apache.org/jira/browse/HBASE-16089
> Project: HBase
>  Issue Type: Improvement
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Fix For: 2.0.0, 1.3.0, 1.4.0
>
> Attachments: HBASE-16089.patch, HBASE-16089.v1.patch, 
> HBASE-16089.v2.patch, HBASE-16089.v3.patch, 
> baselineFifo_codel_codelPlusPatch.png, v3.png
>
>
> If this is all that awesome, so we should have it on CoDel too.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16089) Add on FastPath for CoDel

2016-06-25 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-16089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15349756#comment-15349756
 ] 

Elliott Clark commented on HBASE-16089:
---

Thanks [~saint@gmail.com] that's awesome. Still a little lower than fifo ( 
but I think that's to be expected ).

> Add on FastPath for CoDel
> -
>
> Key: HBASE-16089
> URL: https://issues.apache.org/jira/browse/HBASE-16089
> Project: HBase
>  Issue Type: Improvement
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Attachments: HBASE-16089.patch, HBASE-16089.v1.patch, 
> HBASE-16089.v2.patch, HBASE-16089.v3.patch, 
> baselineFifo_codel_codelPlusPatch.png, v3.png
>
>
> If this is all that awesome, so we should have it on CoDel too.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (HBASE-16111) Truncate preserve shell command is broken

2016-06-24 Thread Elliott Clark (JIRA)
Elliott Clark created HBASE-16111:
-

 Summary: Truncate preserve shell command is broken
 Key: HBASE-16111
 URL: https://issues.apache.org/jira/browse/HBASE-16111
 Project: HBase
  Issue Type: Bug
Reporter: Elliott Clark


On a recent version of master I get this:

{code}
hbase(main):001:0> truncate_preserve 'TestTable'

ERROR: undefined local variable or method `table' for #

Here is some help for this command:
  Disables, drops and recreates the specified table while still maintaing the 
previous region boundaries.

Took 0.0290 seconds
hbase(main):002:0> truncate 'TestTable'
Truncating 'TestTable' table (it may take a while):
Disabling table...
Truncating table...
Took 10.0040 seconds
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16089) Add on FastPath for CoDel

2016-06-24 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16089:
--
Attachment: HBASE-16089.v3.patch

Changed the names of threads so it would be more noticible that the FastPath is 
being used.

> Add on FastPath for CoDel
> -
>
> Key: HBASE-16089
> URL: https://issues.apache.org/jira/browse/HBASE-16089
> Project: HBase
>  Issue Type: Improvement
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Attachments: HBASE-16089.patch, HBASE-16089.v1.patch, 
> HBASE-16089.v2.patch, HBASE-16089.v3.patch, 
> baselineFifo_codel_codelPlusPatch.png
>
>
> If this is all that awesome, so we should have it on CoDel too.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16089) Add on FastPath for CoDel

2016-06-24 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-16089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15348885#comment-15348885
 ] 

Elliott Clark commented on HBASE-16089:
---

Hmmm that seems strange. Let me check here.

> Add on FastPath for CoDel
> -
>
> Key: HBASE-16089
> URL: https://issues.apache.org/jira/browse/HBASE-16089
> Project: HBase
>  Issue Type: Improvement
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Attachments: HBASE-16089.patch, HBASE-16089.v1.patch, 
> HBASE-16089.v2.patch, baselineFifo_codel_codelPlusPatch.png
>
>
> If this is all that awesome, so we should have it on CoDel too.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16089) Add on FastPath for CoDel

2016-06-24 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-16089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15348876#comment-15348876
 ] 

Elliott Clark commented on HBASE-16089:
---

The stack you posted seems to be using BalancedQueueRpcExecutor rather than 
FastPathBalancedQueueRpcExecutor.  FifoWith became 
FastPathBalancedQueueRpcExecutor.

> Add on FastPath for CoDel
> -
>
> Key: HBASE-16089
> URL: https://issues.apache.org/jira/browse/HBASE-16089
> Project: HBase
>  Issue Type: Improvement
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Attachments: HBASE-16089.patch, HBASE-16089.v1.patch, 
> HBASE-16089.v2.patch, baselineFifo_codel_codelPlusPatch.png
>
>
> If this is all that awesome, so we should have it on CoDel too.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16087) Replication shouldn't start on a master if if only hosts system tables

2016-06-23 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-16087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15347590#comment-15347590
 ] 

Elliott Clark commented on HBASE-16087:
---

bq.When active goes down, the standby automatically becomes active and it start 
serving the client requests which were going to active, so to handle all the 
security settings done on active we need to do the same on standby also so only 
we replicate these tables.
That's still a security hole, big time.

> Replication shouldn't start on a master if if only hosts system tables
> --
>
> Key: HBASE-16087
> URL: https://issues.apache.org/jira/browse/HBASE-16087
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 2.0.0, 1.3.0
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Attachments: HBASE-16087.patch, HBASE-16087.v1.patch
>
>
> System tables aren't replicated so we shouldn't start up a replication master 
> if there are no user tables on the master.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16087) Replication shouldn't start on a master if if only hosts system tables

2016-06-23 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-16087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15347561#comment-15347561
 ] 

Elliott Clark commented on HBASE-16087:
---

Replicating acl tables is a security risk since the coprocessors are caching. 
We shouldn't allow that hole.
Namespace and meta should never be replicated.

If you really really want that just put a dummy user table in the list of 
things that master can host. 

> Replication shouldn't start on a master if if only hosts system tables
> --
>
> Key: HBASE-16087
> URL: https://issues.apache.org/jira/browse/HBASE-16087
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 2.0.0, 1.3.0
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Attachments: HBASE-16087.patch, HBASE-16087.v1.patch
>
>
> System tables aren't replicated so we shouldn't start up a replication master 
> if there are no user tables on the master.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16089) Add on FastPath for CoDel

2016-06-23 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-16089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15347557#comment-15347557
 ] 

Elliott Clark commented on HBASE-16089:
---

Thank you kind sir.

> Add on FastPath for CoDel
> -
>
> Key: HBASE-16089
> URL: https://issues.apache.org/jira/browse/HBASE-16089
> Project: HBase
>  Issue Type: Improvement
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Attachments: HBASE-16089.patch, HBASE-16089.v1.patch, 
> HBASE-16089.v2.patch
>
>
> If this is all that awesome, so we should have it on CoDel too.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16089) Add on FastPath for CoDel

2016-06-23 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16089:
--
Attachment: HBASE-16089.v2.patch

> Add on FastPath for CoDel
> -
>
> Key: HBASE-16089
> URL: https://issues.apache.org/jira/browse/HBASE-16089
> Project: HBase
>  Issue Type: Improvement
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Attachments: HBASE-16089.patch, HBASE-16089.v1.patch, 
> HBASE-16089.v2.patch
>
>
> If this is all that awesome, so we should have it on CoDel too.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16089) Add on FastPath for CoDel

2016-06-23 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16089:
--
Attachment: HBASE-16089.v1.patch

> Add on FastPath for CoDel
> -
>
> Key: HBASE-16089
> URL: https://issues.apache.org/jira/browse/HBASE-16089
> Project: HBase
>  Issue Type: Improvement
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Attachments: HBASE-16089.patch, HBASE-16089.v1.patch
>
>
> If this is all that awesome, so we should have it on CoDel too.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-15945) Patch for Key Value, Bytes and Cell

2016-06-23 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-15945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15347110#comment-15347110
 ] 

Elliott Clark commented on HBASE-15945:
---

I strongly disagree with that statement. This is not java. You can not plug in 
different versions of cpp libraries and expect them to work. Adding that 
constraint is pretty much a performance killer.

> Patch for Key Value, Bytes and Cell
> ---
>
> Key: HBASE-15945
> URL: https://issues.apache.org/jira/browse/HBASE-15945
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Sudeep Sunthankar
>Assignee: Sudeep Sunthankar
> Attachments: HBASE-15945-HBASE-14850.v2.patch, 
> HBASE-15945-HBASE-14850.v3.patch, HBASE-15945.HBASE-14850.v1.patch
>
>
> This patch contains an implementation of Key Value, Bytes and Cell modeled on 
> the lines of Java implementation.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16085) Add on metric for failed compactions

2016-06-23 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-16085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15347052#comment-15347052
 ] 

Elliott Clark commented on HBASE-16085:
---

+1

> Add on metric for failed compactions
> 
>
> Key: HBASE-16085
> URL: https://issues.apache.org/jira/browse/HBASE-16085
> Project: HBase
>  Issue Type: Improvement
>Reporter: Elliott Clark
>Assignee: Gary Helmling
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-16085.001.patch, HBASE-16085.002.patch
>
>
> Failing compactions doesn't stop the server so things can go un-noticed for 
> quite a while if there are no metrics.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16093) Splits failed before creating daughter regions leave meta inconsistent

2016-06-23 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16093:
--
   Resolution: Fixed
 Hadoop Flags: Reviewed
Fix Version/s: 1.4.0
   Status: Resolved  (was: Patch Available)

Pushed to branch-1 and branch-1.2

> Splits failed before creating daughter regions leave meta inconsistent
> --
>
> Key: HBASE-16093
> URL: https://issues.apache.org/jira/browse/HBASE-16093
> Project: HBase
>  Issue Type: Bug
>  Components: master, Region Assignment
>Affects Versions: 1.3.0, 1.2.1
>Reporter: Elliott Clark
>Assignee: Elliott Clark
>Priority: Critical
> Fix For: 1.3.0, 1.4.0
>
> Attachments: HBASE-16093.branch-1.patch
>
>
> This is on branch-1 based code only.
> Here's the sequence of events.
> # A regionserver opens a new region. That regions looks like it should split.
> # So the regionserver starts a split transaction.
> # Split transaction starts execute
> # Split transaction encounters an error in stepsBeforePONR
> # Split transaction starts rollback
> # Split transaction notifies master that it's rolling back using 
> HMasterRpcServices#reportRegionStateTransition
> # AssignmentManager#onRegionTransition is called with SPLIT_REVERTED
> # AssignmentManager#onRegionSplitReverted is called.
> # That onlines the parent region and offlines the daughter regions.
> However the daughter regions were never created in meta so all that gets done 
> is that state for those rows gets OFFLINE. Now all clients trying to get the 
> parent instead get the offline daughter.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16093) Splits failed before creating daughter regions leave meta inconsistent

2016-06-23 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-16093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15346974#comment-15346974
 ] 

Elliott Clark commented on HBASE-16093:
---

[~mantonov] For 1.3 review

> Splits failed before creating daughter regions leave meta inconsistent
> --
>
> Key: HBASE-16093
> URL: https://issues.apache.org/jira/browse/HBASE-16093
> Project: HBase
>  Issue Type: Bug
>  Components: master, Region Assignment
>Affects Versions: 1.3.0, 1.2.1
>Reporter: Elliott Clark
>Assignee: Elliott Clark
>Priority: Critical
> Fix For: 1.3.0
>
> Attachments: HBASE-16093.branch-1.patch
>
>
> This is on branch-1 based code only.
> Here's the sequence of events.
> # A regionserver opens a new region. That regions looks like it should split.
> # So the regionserver starts a split transaction.
> # Split transaction starts execute
> # Split transaction encounters an error in stepsBeforePONR
> # Split transaction starts rollback
> # Split transaction notifies master that it's rolling back using 
> HMasterRpcServices#reportRegionStateTransition
> # AssignmentManager#onRegionTransition is called with SPLIT_REVERTED
> # AssignmentManager#onRegionSplitReverted is called.
> # That onlines the parent region and offlines the daughter regions.
> However the daughter regions were never created in meta so all that gets done 
> is that state for those rows gets OFFLINE. Now all clients trying to get the 
> parent instead get the offline daughter.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16093) Splits failed before creating daughter regions leave meta inconsistent

2016-06-23 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16093:
--
Assignee: Elliott Clark
  Status: Patch Available  (was: Open)

> Splits failed before creating daughter regions leave meta inconsistent
> --
>
> Key: HBASE-16093
> URL: https://issues.apache.org/jira/browse/HBASE-16093
> Project: HBase
>  Issue Type: Bug
>  Components: master, Region Assignment
>Affects Versions: 1.2.1, 1.3.0
>Reporter: Elliott Clark
>Assignee: Elliott Clark
>Priority: Critical
> Fix For: 1.3.0
>
> Attachments: HBASE-16093.branch-1.patch
>
>
> This is on branch-1 based code only.
> Here's the sequence of events.
> # A regionserver opens a new region. That regions looks like it should split.
> # So the regionserver starts a split transaction.
> # Split transaction starts execute
> # Split transaction encounters an error in stepsBeforePONR
> # Split transaction starts rollback
> # Split transaction notifies master that it's rolling back using 
> HMasterRpcServices#reportRegionStateTransition
> # AssignmentManager#onRegionTransition is called with SPLIT_REVERTED
> # AssignmentManager#onRegionSplitReverted is called.
> # That onlines the parent region and offlines the daughter regions.
> However the daughter regions were never created in meta so all that gets done 
> is that state for those rows gets OFFLINE. Now all clients trying to get the 
> parent instead get the offline daughter.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16093) Splits failed before creating daughter regions leave meta inconsistent

2016-06-23 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16093:
--
Attachment: HBASE-16093.branch-1.patch

> Splits failed before creating daughter regions leave meta inconsistent
> --
>
> Key: HBASE-16093
> URL: https://issues.apache.org/jira/browse/HBASE-16093
> Project: HBase
>  Issue Type: Bug
>  Components: master, Region Assignment
>Affects Versions: 1.3.0, 1.2.1
>Reporter: Elliott Clark
>Priority: Critical
> Fix For: 1.3.0
>
> Attachments: HBASE-16093.branch-1.patch
>
>
> This is on branch-1 based code only.
> Here's the sequence of events.
> # A regionserver opens a new region. That regions looks like it should split.
> # So the regionserver starts a split transaction.
> # Split transaction starts execute
> # Split transaction encounters an error in stepsBeforePONR
> # Split transaction starts rollback
> # Split transaction notifies master that it's rolling back using 
> HMasterRpcServices#reportRegionStateTransition
> # AssignmentManager#onRegionTransition is called with SPLIT_REVERTED
> # AssignmentManager#onRegionSplitReverted is called.
> # That onlines the parent region and offlines the daughter regions.
> However the daughter regions were never created in meta so all that gets done 
> is that state for those rows gets OFFLINE. Now all clients trying to get the 
> parent instead get the offline daughter.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16093) Splits failed before creating daughter regions leave meta inconsistent

2016-06-23 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16093:
--
Fix Version/s: 1.3.0

> Splits failed before creating daughter regions leave meta inconsistent
> --
>
> Key: HBASE-16093
> URL: https://issues.apache.org/jira/browse/HBASE-16093
> Project: HBase
>  Issue Type: Bug
>  Components: master, Region Assignment
>Affects Versions: 1.3.0, 1.2.1
>Reporter: Elliott Clark
>Priority: Critical
> Fix For: 1.3.0
>
>
> This is on branch-1 based code only.
> Here's the sequence of events.
> # A regionserver opens a new region. That regions looks like it should split.
> # So the regionserver starts a split transaction.
> # Split transaction starts execute
> # Split transaction encounters an error in stepsBeforePONR
> # Split transaction starts rollback
> # Split transaction notifies master that it's rolling back using 
> HMasterRpcServices#reportRegionStateTransition
> # AssignmentManager#onRegionTransition is called with SPLIT_REVERTED
> # AssignmentManager#onRegionSplitReverted is called.
> # That onlines the parent region and offlines the daughter regions.
> However the daughter regions were never created in meta so all that gets done 
> is that state for those rows gets OFFLINE. Now all clients trying to get the 
> parent instead get the offline daughter.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16093) Splits failed before creating daughter regions leave meta inconsistent

2016-06-23 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16093:
--
Component/s: Region Assignment
 master

> Splits failed before creating daughter regions leave meta inconsistent
> --
>
> Key: HBASE-16093
> URL: https://issues.apache.org/jira/browse/HBASE-16093
> Project: HBase
>  Issue Type: Bug
>  Components: master, Region Assignment
>Affects Versions: 1.3.0, 1.2.1
>Reporter: Elliott Clark
>Priority: Critical
> Fix For: 1.3.0
>
>
> This is on branch-1 based code only.
> Here's the sequence of events.
> # A regionserver opens a new region. That regions looks like it should split.
> # So the regionserver starts a split transaction.
> # Split transaction starts execute
> # Split transaction encounters an error in stepsBeforePONR
> # Split transaction starts rollback
> # Split transaction notifies master that it's rolling back using 
> HMasterRpcServices#reportRegionStateTransition
> # AssignmentManager#onRegionTransition is called with SPLIT_REVERTED
> # AssignmentManager#onRegionSplitReverted is called.
> # That onlines the parent region and offlines the daughter regions.
> However the daughter regions were never created in meta so all that gets done 
> is that state for those rows gets OFFLINE. Now all clients trying to get the 
> parent instead get the offline daughter.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16093) Splits failed before creating daughter regions leave meta inconsistent

2016-06-23 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16093:
--
Affects Version/s: 1.3.0
   1.2.1

> Splits failed before creating daughter regions leave meta inconsistent
> --
>
> Key: HBASE-16093
> URL: https://issues.apache.org/jira/browse/HBASE-16093
> Project: HBase
>  Issue Type: Bug
>  Components: master, Region Assignment
>Affects Versions: 1.3.0, 1.2.1
>Reporter: Elliott Clark
>Priority: Critical
> Fix For: 1.3.0
>
>
> This is on branch-1 based code only.
> Here's the sequence of events.
> # A regionserver opens a new region. That regions looks like it should split.
> # So the regionserver starts a split transaction.
> # Split transaction starts execute
> # Split transaction encounters an error in stepsBeforePONR
> # Split transaction starts rollback
> # Split transaction notifies master that it's rolling back using 
> HMasterRpcServices#reportRegionStateTransition
> # AssignmentManager#onRegionTransition is called with SPLIT_REVERTED
> # AssignmentManager#onRegionSplitReverted is called.
> # That onlines the parent region and offlines the daughter regions.
> However the daughter regions were never created in meta so all that gets done 
> is that state for those rows gets OFFLINE. Now all clients trying to get the 
> parent instead get the offline daughter.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (HBASE-16093) Splits failed before creating daughter regions leave meta inconsistent

2016-06-23 Thread Elliott Clark (JIRA)
Elliott Clark created HBASE-16093:
-

 Summary: Splits failed before creating daughter regions leave meta 
inconsistent
 Key: HBASE-16093
 URL: https://issues.apache.org/jira/browse/HBASE-16093
 Project: HBase
  Issue Type: Bug
Reporter: Elliott Clark
Priority: Critical


This is on branch-1 based code only.


Here's the sequence of events.

# A regionserver opens a new region. That regions looks like it should split.
# So the regionserver starts a split transaction.
# Split transaction starts execute
# Split transaction encounters an error in stepsBeforePONR
# Split transaction starts rollback
# Split transaction notifies master that it's rolling back using 
HMasterRpcServices#reportRegionStateTransition
# AssignmentManager#onRegionTransition is called with SPLIT_REVERTED
# AssignmentManager#onRegionSplitReverted is called.
# That onlines the parent region and offlines the daughter regions.

However the daughter regions were never created in meta so all that gets done 
is that state for those rows gets OFFLINE. Now all clients trying to get the 
parent instead get the offline daughter.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16083) Fix table based replication related configs

2016-06-22 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-16083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15345435#comment-15345435
 ] 

Elliott Clark commented on HBASE-16083:
---

[~tedyu] that's pretty rude. [~Vegetable26] was in the process of working on 
the addendum. He re-opened the jira and explained what the issue was. There's 
no reason to try and jump in on issues that are 90% solved and involve new 
contributors. You should be setting a better example where you try and guide 
contributors. You didn't even put up the addendum up on jira.

> Fix table based replication related configs
> ---
>
> Key: HBASE-16083
> URL: https://issues.apache.org/jira/browse/HBASE-16083
> Project: HBase
>  Issue Type: Sub-task
>  Components: Replication
>Reporter: Joseph
>Assignee: Joseph
>Priority: Trivial
> Fix For: 2.0.0
>
> Attachments: HBASE-16083.patch
>
>
> Small style changes to make the new Table Based Replication configs match the 
> other HBase configs



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16089) Add on FastPath for CoDel

2016-06-22 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16089:
--
Status: Patch Available  (was: Open)

> Add on FastPath for CoDel
> -
>
> Key: HBASE-16089
> URL: https://issues.apache.org/jira/browse/HBASE-16089
> Project: HBase
>  Issue Type: Improvement
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Attachments: HBASE-16089.patch
>
>
> If this is all that awesome, so we should have it on CoDel too.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16089) Add on FastPath for CoDel

2016-06-22 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16089:
--
Attachment: HBASE-16089.patch

> Add on FastPath for CoDel
> -
>
> Key: HBASE-16089
> URL: https://issues.apache.org/jira/browse/HBASE-16089
> Project: HBase
>  Issue Type: Improvement
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Attachments: HBASE-16089.patch
>
>
> If this is all that awesome, so we should have it on CoDel too.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (HBASE-16089) Add on FastPath for CoDel

2016-06-22 Thread Elliott Clark (JIRA)
Elliott Clark created HBASE-16089:
-

 Summary: Add on FastPath for CoDel
 Key: HBASE-16089
 URL: https://issues.apache.org/jira/browse/HBASE-16089
 Project: HBase
  Issue Type: Improvement
Reporter: Elliott Clark
Assignee: Elliott Clark


If this is all that awesome, so we should have it on CoDel too.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16087) Replication shouldn't start on a master if if only hosts system tables

2016-06-22 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16087:
--
Attachment: HBASE-16087.v1.patch

> Replication shouldn't start on a master if if only hosts system tables
> --
>
> Key: HBASE-16087
> URL: https://issues.apache.org/jira/browse/HBASE-16087
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 2.0.0, 1.3.0
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Attachments: HBASE-16087.patch, HBASE-16087.v1.patch
>
>
> System tables aren't replicated so we shouldn't start up a replication master 
> if there are no user tables on the master.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16087) Replication shouldn't start on a master if if only hosts system tables

2016-06-22 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16087:
--
Affects Version/s: 1.3.0
   2.0.0
   Status: Patch Available  (was: Open)

> Replication shouldn't start on a master if if only hosts system tables
> --
>
> Key: HBASE-16087
> URL: https://issues.apache.org/jira/browse/HBASE-16087
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 2.0.0, 1.3.0
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Attachments: HBASE-16087.patch
>
>
> System tables aren't replicated so we shouldn't start up a replication master 
> if there are no user tables on the master.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16087) Replication shouldn't start on a master if if only hosts system tables

2016-06-22 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16087:
--
Attachment: HBASE-16087.patch

> Replication shouldn't start on a master if if only hosts system tables
> --
>
> Key: HBASE-16087
> URL: https://issues.apache.org/jira/browse/HBASE-16087
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 2.0.0, 1.3.0
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Attachments: HBASE-16087.patch
>
>
> System tables aren't replicated so we shouldn't start up a replication master 
> if there are no user tables on the master.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (HBASE-16087) Replication shouldn't start on a master if if only hosts system tables

2016-06-22 Thread Elliott Clark (JIRA)

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

Elliott Clark reassigned HBASE-16087:
-

Assignee: Elliott Clark

> Replication shouldn't start on a master if if only hosts system tables
> --
>
> Key: HBASE-16087
> URL: https://issues.apache.org/jira/browse/HBASE-16087
> Project: HBase
>  Issue Type: Improvement
>Reporter: Elliott Clark
>Assignee: Elliott Clark
>
> System tables aren't replicated so we shouldn't start up a replication master 
> if there are no user tables on the master.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16087) Replication shouldn't start on a master if if only hosts system tables

2016-06-22 Thread Elliott Clark (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-16087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15345285#comment-15345285
 ] 

Elliott Clark commented on HBASE-16087:
---

Picking this one up.

> Replication shouldn't start on a master if if only hosts system tables
> --
>
> Key: HBASE-16087
> URL: https://issues.apache.org/jira/browse/HBASE-16087
> Project: HBase
>  Issue Type: Improvement
>Reporter: Elliott Clark
>Assignee: Elliott Clark
>
> System tables aren't replicated so we shouldn't start up a replication master 
> if there are no user tables on the master.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16083) Fix table based replication related configs

2016-06-22 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-16083:
--
   Resolution: Fixed
 Hadoop Flags: Reviewed
Fix Version/s: 2.0.0
   Status: Resolved  (was: Patch Available)

Thanks for the patch.

> Fix table based replication related configs
> ---
>
> Key: HBASE-16083
> URL: https://issues.apache.org/jira/browse/HBASE-16083
> Project: HBase
>  Issue Type: Sub-task
>  Components: Replication
>Reporter: Joseph
>Assignee: Joseph
>Priority: Trivial
> Fix For: 2.0.0
>
> Attachments: HBASE-16083.patch
>
>
> Small style changes to make the new Table Based Replication configs match the 
> other HBase configs



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


  1   2   3   4   5   6   7   8   9   10   >