Actually, I now have another question because of the way our work load is
structured. We use a wide schema and each time we write, we delete the
entire row and write a fresh set of columns - we want to make sure no old
columns survive. So, I just want to see if my picture of the memstore at
this po
Varun,
There is no need to open new JIRA - there are two already:
https://issues.apache.org/jira/browse/HBASE-9769
https://issues.apache.org/jira/browse/HBASE-9778
Both with patches, you can grab and test them.
-Vladimir
On Mon, Jan 27, 2014 at 9:36 PM, Varun Sharma wrote:
> Hi lars,
>
> Tha
Hi lars,
Thanks for the background. It seems that for our case, we will have to
consider some solution like the Facebook one, since the next column is
always the next one - this can be a simple flag. I am going to raise a JIRA
and we can discuss there.
Thanks
Varun
On Sun, Jan 26, 2014 at 3:43
/**
* A janitor for the catalog tables. Scans the .META. catalog
* table on a period looking for unused regions to garbage collect.
*/
class CatalogJanitor extends Chore {
private static final Log LOG =
LogFactory.getLog(CatalogJanitor.class.getName());
private final Server server;
privat
ramkrishna.s.vasudevan created HBASE-10429:
--
Summary: Make Visibility Controller to throw a better msg if it is
of type RegionServerCoprocessor
Key: HBASE-10429
URL: https://issues.apache.org/jira/browse/
But continue to see reads on META - no idea why ?
On Mon, Jan 27, 2014 at 8:52 PM, Varun Sharma wrote:
> We are not seeing any balancer related logs btw anymore...
>
>
> On Mon, Jan 27, 2014 at 8:23 PM, Ted Yu wrote:
>
>> Looking at the changes since release 0.94.7, I found:
>>
>> HBASE-8655 B
We are not seeing any balancer related logs btw anymore...
On Mon, Jan 27, 2014 at 8:23 PM, Ted Yu wrote:
> Looking at the changes since release 0.94.7, I found:
>
> HBASE-8655 Backport to 94 - HBASE-8346(Prefetching .META. rows in case only
> when useCache is set to true)
> HBASE-8698 potentia
Looking at the changes since release 0.94.7, I found:
HBASE-8655 Backport to 94 - HBASE-8346(Prefetching .META. rows in case only
when useCache is set to true)
HBASE-8698 potential thread creation in MetaScanner.metaScan
If possible, can you upgrade your cluster ?
Cheers
On Mon, Jan 27, 2014 a
Do you see the following (from HConnectionManager$HConnectionImplementation#
locateRegionInMeta) ?
if (LOG.isDebugEnabled()) {
LOG.debug("locateRegionInMeta parentTable=" +
Bytes.toString(parentTable) + ", metaLocation=" +
((metaLocation ==
Actually not sometimes but we are always seeing a large # of .META. reads
every 5 minutes.
On Mon, Jan 27, 2014 at 7:47 PM, Varun Sharma wrote:
> The default one with 0.94.7... - I dont see any of those logs. Also we
> turned off the balancer switch - but looks like sometimes we still see a
> l
The default one with 0.94.7... - I dont see any of those logs. Also we
turned off the balancer switch - but looks like sometimes we still see a
large number of requests to .META. table every 5 minutes.
Varun
On Mon, Jan 27, 2014 at 7:37 PM, Ted Yu wrote:
> In HMaster#balance(), we have (same f
In HMaster#balance(), we have (same for 0.94 and 0.96):
for (RegionPlan plan: plans) {
LOG.info("balance " + plan);
Do you see such log in master log ?
On Mon, Jan 27, 2014 at 7:26 PM, Varun Sharma wrote:
> We are seeing one other issue with high read latency (p99 etc.) on o
We are seeing one other issue with high read latency (p99 etc.) on one of
our read heavy hbase clusters which is correlated with the balancer runs -
every 5 minutes.
If there is no balancing to do, does the balancer only scan the table every
5 minutes - does it do anything on top of that if the re
On Mon, Jan 27, 2014 at 10:16 AM, Andrew Purtell wrote:
> Let me vote -1 on 0.98.0RC0 on account of HBASE-10422.
Sorry I didn't mean to sink the RC just for this. Just thought that
I'd mention it because generally somebody else will come with a
real / good reason why to sink the first RC of any
On Mon, Jan 27, 2014 at 5:05 PM, Andrew Purtell wrote:
> On Mon, Jan 27, 2014 at 4:16 PM, Stack wrote:
>
> > I brought a up 0.98 regionserver on a 0.96.1.1. cluster that was under
> > load. It just slotted in and cluster kept going.
> >
> > I then brought up a 0.98.0 master instead of the 0.96.
On Mon, Jan 27, 2014 at 5:05 PM, Andrew Purtell wrote:
> On Mon, Jan 27, 2014 at 4:16 PM, Stack wrote:
>
> > Logging could do w/ an edit -- too profuse. We need to make INFO level
> > work before 1.0.0.
> >
>
> Anything specific stand out? We can get in a INFO -> DEBUG reduction in
> before RC1
On Mon, Jan 27, 2014 at 4:16 PM, Stack wrote:
> I brought a up 0.98 regionserver on a 0.96.1.1. cluster that was under
> load. It just slotted in and cluster kept going.
>
> I then brought up a 0.98.0 master instead of the 0.96.1.1. master and that
> was fine to.
>
That is f*cking awesome.
-
On Mon, Jan 27, 2014 at 4:16 PM, Stack wrote:
> Logging could do w/ an edit -- too profuse. We need to make INFO level
> work before 1.0.0.
>
Anything specific stand out? We can get in a INFO -> DEBUG reduction in
before RC1 cuts.
--
Best regards,
- Andy
Problems worthy of attack prove
I am done Andrew.
Doc and layout looks good.
Should make it so javadoc and xref docs are 0.98.0 rather than
0.98.0-hadoop1 and 0.98.0-hadoop2 (but that is not you).
Logging could do w/ an edit -- too profuse. We need to make INFO level
work before 1.0.0.
I brought a up 0.98 regionserver on a 0
Jimmy Xiang created HBASE-10428:
---
Summary: Test jars should have scope test
Key: HBASE-10428
URL: https://issues.apache.org/jira/browse/HBASE-10428
Project: HBase
Issue Type: Bug
Comp
Sergey Shelukhin created HBASE-10427:
Summary: clean up HRegionLocation/ServerName usage
Key: HBASE-10427
URL: https://issues.apache.org/jira/browse/HBASE-10427
Project: HBase
Issue Type
Ted Yu created HBASE-10426:
--
Summary: user_permission in security.rb calls non-existent
UserPermission#getTable method
Key: HBASE-10426
URL: https://issues.apache.org/jira/browse/HBASE-10426
Project: HBase
[
https://issues.apache.org/jira/browse/HBASE-10371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl resolved HBASE-10371.
---
Resolution: Fixed
Committed to 0.94 and 0.96.
> Compaction creates empty hfile, then select
[
https://issues.apache.org/jira/browse/HBASE-10402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hsieh resolved HBASE-10402.
Resolution: Fixed
Hadoop Flags: Reviewed
> [docs] Add docs on how to create and tag
Adela Maznikar created HBASE-10425:
--
Summary: [0.89-fb] Isolate assignment plan on subset of machines
Key: HBASE-10425
URL: https://issues.apache.org/jira/browse/HBASE-10425
Project: HBase
I
Maybe spin it tomorrow. I was going to take a look at 0.98 today. Let me
see if I can turn up something else?
St.Ack
On Mon, Jan 27, 2014 at 10:16 AM, Andrew Purtell wrote:
> Let me vote -1 on 0.98.0RC0 on account of HBASE-10422.
>
> I will spin a new RC today.
>
>
> On Sat, Jan 25, 2014 at 11
Ok, I will tag RC1 tomorrow.
On Mon, Jan 27, 2014 at 10:21 AM, Stack wrote:
> Maybe spin it tomorrow. I was going to take a look at 0.98 today. Let me
> see if I can turn up something else?
> St.Ack
>
>
> On Mon, Jan 27, 2014 at 10:16 AM, Andrew Purtell >wrote:
>
> > Let me vote -1 on 0.98.0
This will be fixed (at least) in the 0.98.0 release.
On Sun, Jan 26, 2014 at 6:36 PM, tsuna wrote:
> Yes, I just ran into the same issue. Sigh. I guess one workaround is
> to try to make AsyncHBase's jar show up first on the class path,
> although that's not always as easy to do as it might s
Let me vote -1 on 0.98.0RC0 on account of HBASE-10422.
I will spin a new RC today.
On Sat, Jan 25, 2014 at 11:32 AM, Andrew Purtell wrote:
> The 1st HBase 0.98.0 release candidate (RC0) is available for download at
> http://people.apache.org/~apurtell/0.98.0RC0/ and Maven artifacts are
> also a
On Mon, Jan 27, 2014 at 9:48 AM, Jonathan Hsieh wrote:
> So is the suggestion to just add the other signature to hbase's version?
The existing signature is useless as it cannot be used from outside
Google's protobuf package.
--
Benoit "tsuna" Sigoure
This was obnoxious, sorry about that Benoit. I will sink this RC and spin
another one today.
On Sun, Jan 26, 2014 at 6:37 PM, tsuna wrote:
> If this RC sinks, can you please include this one in 0.98.0:
> https://issues.apache.org/jira/browse/HBASE-10422
>
> --
> Benoit "tsuna" Sigoure
>
--
On Mon, Jan 27, 2014 at 9:48 AM, Jonathan Hsieh wrote:
> So is the suggestion to just add the other signature to hbase's version?
>
>
Can't do that since the change is changing the param to be its superclass
instead.
> We recently ran into another problem due to this ZeroCopy class --
> shouldn
[
https://issues.apache.org/jira/browse/HBASE-8153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell resolved HBASE-8153.
---
Resolution: Cannot Reproduce
> TestJoinedScanners fails occasionally
> --
[
https://issues.apache.org/jira/browse/HBASE-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-4643.
--
Resolution: Unresolved
Resolving no longer pertinent issue
> Consider reverting HBASE-451 (change HRI to remov
[
https://issues.apache.org/jira/browse/HBASE-4490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-4490.
--
Resolution: Later
Resolving old issue, abandoned with no progress
> Improve TestRollingRestart to cover comple
So is the suggestion to just add the other signature to hbase's version?
We recently ran into another problem due to this ZeroCopy class --
shouldn't it really be pushed into protobuf, or pulled out as a separate
jar of some sort. We ran into into class path/class loader problems with
it because
[
https://issues.apache.org/jira/browse/HBASE-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-4507.
--
Resolution: Won't Fix
Resolving a -1'd issue as won't fix (HBASE-4527 takes over)
> Create checkAndPut variant
[
https://issues.apache.org/jira/browse/HBASE-4464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-4464.
--
Resolution: Not A Problem
Resolving. For old balancer, not for new stochastic.
> Make region balancing parall
[
https://issues.apache.org/jira/browse/HBASE-4136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-4136.
--
Resolution: Invalid
Resolving as invalid. The behavior is by design.
> Load balancer may not have a chance to
[
https://issues.apache.org/jira/browse/HBASE-4370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-4370.
--
Resolution: Incomplete
Unassigned incomplete issue w/ no work done. Resolving.
> Support progress reporting a
[
https://issues.apache.org/jira/browse/HBASE-4389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-4389.
--
Resolution: Later
Old issue, no longer pertinent. Abandoned.
> Address lots of issues with migration from 90
[
https://issues.apache.org/jira/browse/HBASE-4385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-4385.
--
Resolution: Later
Abandoned issue
> Use CacheBuilder in place of MapMaker
> --
I committed your patch on all branches Benoit. It'll make the next RC and
any releases from here on out.
St.Ack
On Sun, Jan 26, 2014 at 6:37 PM, tsuna wrote:
> If this RC sinks, can you please include this one in 0.98.0:
> https://issues.apache.org/jira/browse/HBASE-10422
>
> --
> Benoit "tsun
On Mon, Jan 27, 2014 at 1:02 AM, Nicolas Liochon wrote:
> Should we not rename ZeroCopyLiteralByteString to something like
> HBasePrivateZeroCopyLiteralByteString to be sure that we won't have name
> conflicts in the future?
I don't mind keeping the same name as long as we agree on the API.
I don
Harsh J created HBASE-10424:
---
Summary: HMaster could capture stacks of RSes it deems
unresponsive during assignments
Key: HBASE-10424
URL: https://issues.apache.org/jira/browse/HBASE-10424
Project: HBase
Harsh J created HBASE-10423:
---
Summary: Report back the message of split or rollback failure to
the master
Key: HBASE-10423
URL: https://issues.apache.org/jira/browse/HBASE-10423
Project: HBase
Iss
Should we not rename ZeroCopyLiteralByteString to something like
HBasePrivateZeroCopyLiteralByteString to be sure that we won't have name
conflicts in the future?
On Mon, Jan 27, 2014 at 3:36 AM, tsuna wrote:
> Yes, I just ran into the same issue. Sigh. I guess one workaround is
> to try to
47 matches
Mail list logo
