[jira] [Created] (HBASE-21041) Memstore's heap size will be decreased to minus zero after flush
Allan Yang created HBASE-21041: -- Summary: Memstore's heap size will be decreased to minus zero after flush Key: HBASE-21041 URL: https://issues.apache.org/jira/browse/HBASE-21041 Project: HBase Issue Type: Bug Affects Versions: 2.0.1, 2.1.0 Reporter: Allan Yang Assignee: Allan Yang When creating an active mutable segment (MutableSegment) in memstore, MutableSegment's deep overheap (208 bytes) was added to its heap size, but not to the region's memstore's heap size. And so was the immutable segment(CSLMImmutableSegment) which the mutable segment turned into (additional 8 bytes ) later. So after one flush, the memstore's heapsize will be decreased to -216 bytes, The minus number will accumulate after every flush. CompactingMemstore has this problem too. We need to record the overhead for CSLMImmutableSegment and MutableSegment to the corresponding region's memstore size. For CellArrayImmutableSegment, CellChunkImmutableSegment and CompositeImmutableSegment , it is not necessary to do so, because inside CompactingMemstore, the overheads are already be taken care of when transfer a CSLMImmutableSegment into them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21042) processor.getRowsToLock() always assumes there is some row being locked in HRegion#processRowsWithLocks
Ted Yu created HBASE-21042: -- Summary: processor.getRowsToLock() always assumes there is some row being locked in HRegion#processRowsWithLocks Key: HBASE-21042 URL: https://issues.apache.org/jira/browse/HBASE-21042 Project: HBase Issue Type: Bug Reporter: Ted Yu Assignee: Ted Yu [~tdsilva] reported at the tail of HBASE-18998 that the fix for HBASE-18998 missed finally block of HRegion#processRowsWithLocks This is to fix that remaining call. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21043) TestShell list_procedures is flakey
stack created HBASE-21043:
-
Summary: TestShell list_procedures is flakey
Key: HBASE-21043
URL: https://issues.apache.org/jira/browse/HBASE-21043
Project: HBase
Issue Type: Bug
Components: shell, test
Affects Versions: 2.0.1
Reporter: stack
Fails 30% of the time in list_procedures. Fails creating a Procedure then
trying to capture shell output to confirm it sees the just-queued Procedure
only it looks like the Procedure finishes too quickly. It works for a while
then there are a spate of failures. Then it works again.
Here is how it looks in test output:
{code}
Took 5.6355 secondsTook 0.0561 seconds...F
===
Failure: test_list_procedures(Hbase::ListProceduresTest)
src/test/ruby/shell/list_procedures_test.rb:65:in `block in
test_list_procedures'
62: end
63: end
64:
=> 65: assert_equal(1, matching_lines)
66: end
67: end
68: end
<1> expected but was
<0>
{code"
Then in the log output for the test, I see this for the running of the
Procedure:
{code}
2018-08-14 00:42:50,381 DEBUG [Time-limited test]
procedure2.ProcedureExecutor(948): Stored pid=27, state=RUNNABLE,
hasLock=false; org.apache.hadoop.hbase.client.procedure.ShellTestProcedure
2018-08-14 00:42:50,397 INFO [RS-EventLoopGroup-1-10]
ipc.ServerRpcConnection(556): Connection from 67.195.81.150:50597,
version=2.0.2-SNAPSHOT, sasl=false, ugi=jenkins (auth:SIMPLE),
service=MasterService
F
===
Failure: test_list_procedures(Hbase::ListProceduresTest)
src/test/ruby/shell/list_procedures_test.rb:65:in `block in
test_list_procedures'
2018-08-14 00:42:50,586 INFO [PEWorker-16] procedure2.ProcedureExecutor(1316):
Finished pid=27, state=SUCCESS, hasLock=false;
org.apache.hadoop.hbase.client.procedure.ShellTestProcedure in 234msec
62: end
63: end
64:
=> 65: assert_equal(1, matching_lines)
66: end
67: end
68: end
<1> expected but was
<0>
===
{code}
The Procedure runs successfully but the regex test on the other end of the
Admin is not finding what it expects -- the Procedure ran in 234ms.
Will disable in a subprocedure for now till someone has time to play w/ this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-21044) Disable flakey TestShell list_procedures
stack created HBASE-21044: - Summary: Disable flakey TestShell list_procedures Key: HBASE-21044 URL: https://issues.apache.org/jira/browse/HBASE-21044 Project: HBase Issue Type: Sub-task Components: test Reporter: stack Assignee: stack Fix For: 3.0.0, 2.0.2, 2.1.1 Disable the test for now until the parent issue is addressed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21045) Make a 2.0.2 release
stack created HBASE-21045: - Summary: Make a 2.0.2 release Key: HBASE-21045 URL: https://issues.apache.org/jira/browse/HBASE-21045 Project: HBase Issue Type: Bug Reporter: stack -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21046) Set version to 2.0.2 on branch-2.0 in prep for first RC
stack created HBASE-21046: - Summary: Set version to 2.0.2 on branch-2.0 in prep for first RC Key: HBASE-21046 URL: https://issues.apache.org/jira/browse/HBASE-21046 Project: HBase Issue Type: Sub-task Reporter: stack Assignee: stack Fix For: 2.0.2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Will put up a 2.0.2 RC in next day or so
Shout if you need to get anything in. S
[jira] [Resolved] (HBASE-21046) Set version to 2.0.2 on branch-2.0 in prep for first RC
[
https://issues.apache.org/jira/browse/HBASE-21046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-21046.
---
Resolution: Fixed
Ran {{mvn clean org.codehaus.mojo:versions-maven-plugin:2.5:set
-DnewVersion=2.0.2}} and pushed the change on branch-2.0.
> Set version to 2.0.2 on branch-2.0 in prep for first RC
> ---
>
> Key: HBASE-21046
> URL: https://issues.apache.org/jira/browse/HBASE-21046
> Project: HBase
> Issue Type: Sub-task
>Reporter: stack
>Assignee: stack
>Priority: Major
> Fix For: 2.0.2
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-21047) Object creation of StoreFileScanner thru constructor and close may leave refCount to -1
Vishal Khandelwal created HBASE-21047: - Summary: Object creation of StoreFileScanner thru constructor and close may leave refCount to -1 Key: HBASE-21047 URL: https://issues.apache.org/jira/browse/HBASE-21047 Project: HBase Issue Type: Bug Reporter: Vishal Khandelwal Assignee: Vishal Khandelwal During object creation "*StoreFileScanner*", it does not increase the refCount whereas while close it decrements the reader refCount. This will cause refCount to -1 and isReadReference method was returning true (refCount.get() != 0 This is causing store file not to be deleted. This may also cause issue in situation when some thread is holding a scanner but it may actually be closed due to above bug. Impact of this would be really high. Attatching patch for the fix which makes sure if reference is held either thru getScanner method or constructor, ref is always updated. Patch also contains a test which validates the issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
