Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Mon, 13 Aug 2012 10:35:38 +1100 (NCT)
From: "Lars Hofhansl (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <1339316425.217.1344814538344.JavaMail.jiratomcat@arcas>
In-Reply-To: <1645191706.48.1344806797813.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (HBASE-6561) Gets/Puts with many columns send
 the RegionServer into an "endless" loop
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Lars Hofhansl commented on HBASE-6561:
--------------------------------------

Looking at the code again, I am actually not sure anymore why building tailSet in MemStoreScanner and then calling next on the iterators would be scanning through so many more KVs with newer memstoreTSs. There might be something else at play here.
                
> Gets/Puts with many columns send the RegionServer into an "endless" loop
> ------------------------------------------------------------------------
>
>                 Key: HBASE-6561
>                 URL: https://issues.apache.org/jira/browse/HBASE-6561
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Lars Hofhansl
>            Assignee: Lars Hofhansl
>             Fix For: 0.96.0, 0.94.2
>
>         Attachments: 6561-0.94.txt, 6561-0.96.txt
>
>
> This came from the mailing this:
> We were able to replicate this behavior in a pseudo-distributed hbase
> (hbase-0.94.1) environment. We wrote a test program that creates a test
> table "MyTestTable" and populates it with random rows, then it creates a
> row with 60,000 columns and repeatedly updates it. Each column has a 18
> byte qualifier and a 50 byte value. In our tests, when we ran the
> program, we usually never got beyond 15 updates before it would flush
> for a really long time. The rows that are being updated are about 4MB
> each (minues any hbase metadata).
> It doesn't seem like it's caused by GC. I turned on gc logging, and
> didn't see any long pauses. This is the gc log during the flush.
> http://pastebin.com/vJKKXDx5
> This is the regionserver log with debug on during the same flush
> http://pastebin.com/Fh5213mg
> This is the test program we wrote.
> http://pastebin.com/aZ0k5tx2
> You should be able to just compile it, and run it against a running
> HBase cluster.
> $ java TestTable
> Carlos

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira