Steve Loughran created HBASE-10444:
--
Summary: NPE seen in logs at tail of fatal shutdown
Key: HBASE-10444
URL: https://issues.apache.org/jira/browse/HBASE-10444
Project: HBase
Issue Type:
Sounds good, I'll watch for your patch!
On Thursday, January 30, 2014, Lukas Nalezenec
lukas.naleze...@firma.seznam.cz wrote:
I talked with guy who worked on this and he said our production issue was
probably not directly caused by getLength() returning 0.
Anyway, we are interested in fixing
Ted Yu created HBASE-10445:
--
Summary: TestRegionObserverInterface occasionally times out
Key: HBASE-10445
URL: https://issues.apache.org/jira/browse/HBASE-10445
Project: HBase
Issue Type: Test
Jimmy Xiang created HBASE-10446:
---
Summary: Backup master gives Error 500 for debug dump
Key: HBASE-10446
URL: https://issues.apache.org/jira/browse/HBASE-10446
Project: HBase
Issue Type: Bug
Hi All
In case of flush we create a memstore flusher which in turn creates a
StoreScanner backed by a Single ton MemstoreScanner.
But this scanner also registers for any updates in the reader in the
HStore. Is this needed?
If this happens then any update on the reader may nullify the current
[
https://issues.apache.org/jira/browse/HBASE-10445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu reopened HBASE-10445:
TestRegionObserverInterface occasionally times out
--
[
https://issues.apache.org/jira/browse/HBASE-10445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell resolved HBASE-10445.
Resolution: Invalid
bq. I reproduced the test failure just now - with distributed log
[
https://issues.apache.org/jira/browse/HBASE-10445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell reopened HBASE-10445:
TestRegionObserverInterface occasionally times out
It seems you are right. I think only if a concurrent compaction finishes
the memstore scanner would be affected right?
How big is the affect for resetting the KVHeap ?
Enis
On Thu, Jan 30, 2014 at 11:48 AM, ramkrishna vasudevan
ramkrishna.s.vasude...@gmail.com wrote:
Hi All
In case of
Thanks Enis for your reply. The effect of resetting the heap is that we
would start reading those files under the StoreScanner and start doing the
comparison with the KVs in the memstore scanner.
Ideally this comparison is not needed and this can be avoided by not
allowing the storescanners
From what I found is that the main performance detriment comes from the fact
that we need to take a lock for each next/peek call of the StoreScanner. Even
when those are uncontended (which they are in 99.9% of the cases) the memory
read/writes barriers are expensive.
I doubt you'll see much
The scanner stack is only reset if the set of HFiles for this store
changes, i.e. a compaction or a concurrent flush (when using multithreaded
flushing). It seems that would relatively rare.
In our test scenario this happens. While trying to find out the root cause
for HBASE-10443, hit this
Interesting. Did you see the cause for the scanner reset? Was it a concurrent
compaction?
- Original Message -
From: ramkrishna vasudevan ramkrishna.s.vasude...@gmail.com
To: dev@hbase.apache.org dev@hbase.apache.org; lars hofhansl
la...@apache.org
Cc:
Sent: Thursday, January 30,
Yes there was concurrent compaction happening. This was the cause for the
scanner reset and so finally ended up in seeking/next in the encoded block
of those files under the storefilescanner.
Adding the trace to show how a memstore flusher was trying to read a hfile.
Hi all,
I'm writing simple java program to connect to HBase.
Versions of software used
Hbase 0.96.0-hadoop2
Hadoop:hadoop-2.2.0.
I'm trying to connect from my windows 7 (32 bit)machine to oracle linux
machine (Details :VM, 64 bit).Note I have not installed ZooKeeper.
Any suggestion or
15 matches
Mail list logo
