[jira] [Commented] (HBASE-16164) Missing close of new compacted segments in few occasions which might leak MSLAB chunks from pool
[
https://issues.apache.org/jira/browse/HBASE-16164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15361072#comment-15361072
]
Anastasia Braginsky commented on HBASE-16164:
-
OK, leave the fix as is. Thanks!!!
> Missing close of new compacted segments in few occasions which might leak
> MSLAB chunks from pool
>
>
> Key: HBASE-16164
> URL: https://issues.apache.org/jira/browse/HBASE-16164
> Project: HBase
> Issue Type: Sub-task
>Affects Versions: 2.0.0
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-16164.patch
>
>
> An in memory compaction of N segments in progress. Inn between snapshot()
> call comes. We will stop the in progress compaction then. This just sets an
> AtomicBoolean. We check this boolean state in the compaction loop (while
> loop reading the cells from the segments) and before swapping the segments.
> But if this scenario comes, we are just ignoring the new newly compacted
> Segment. This is a problem maker when we work with MSLAB pool. The new
> segment would have acquired some chunks but when will they get released? As
> we dont close the segment this will leak them.
> Also in swap we have
> {code}
> public boolean swap(VersionedSegmentsList versionedList, ImmutableSegment
> segment) {
> if(versionedList.getVersion() != version) {
> return false;
> }
> LinkedList suffix;
> synchronized (pipeline){
> if(versionedList.getVersion() != version) {
> return false;
> }
> {code}
> I dont see any possibility for this code flow to happen. Still for
> correctness, we should close the segment here too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16164) Missing close of new compacted segments in few occasions which might leak MSLAB chunks from pool
[
https://issues.apache.org/jira/browse/HBASE-16164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15360594#comment-15360594
]
Anoop Sam John commented on HBASE-16164:
You mean finally block with a boolean indicating whether the compaction
completed and swap happend and based on that do close of result? Its fine with
cur way of if else IMHO. We don't expect any exception in this path right?
I think Ram pinged over in HBASE-14921 or the parent issue days back. We are
in process of testing our off heap write path PoC code with this new memstore.
We believe that this may help with off heaping.. Till now we are not able to
test that with PE because new memstore not able to stand high write load. PE
tool we are trying to run with a cluster of 1 RS with 50 regions. 32 GB heap
space. PE having 50 threads writing rows. FYI
Sorry that the fixes made u to refresh the patch. Once that is posted in
HBASE-14921, we will help you with reviews and get that in soon. Thanks for you
work.
> Missing close of new compacted segments in few occasions which might leak
> MSLAB chunks from pool
>
>
> Key: HBASE-16164
> URL: https://issues.apache.org/jira/browse/HBASE-16164
> Project: HBase
> Issue Type: Sub-task
>Affects Versions: 2.0.0
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-16164.patch
>
>
> An in memory compaction of N segments in progress. Inn between snapshot()
> call comes. We will stop the in progress compaction then. This just sets an
> AtomicBoolean. We check this boolean state in the compaction loop (while
> loop reading the cells from the segments) and before swapping the segments.
> But if this scenario comes, we are just ignoring the new newly compacted
> Segment. This is a problem maker when we work with MSLAB pool. The new
> segment would have acquired some chunks but when will they get released? As
> we dont close the segment this will leak them.
> Also in swap we have
> {code}
> public boolean swap(VersionedSegmentsList versionedList, ImmutableSegment
> segment) {
> if(versionedList.getVersion() != version) {
> return false;
> }
> LinkedList suffix;
> synchronized (pipeline){
> if(versionedList.getVersion() != version) {
> return false;
> }
> {code}
> I dont see any possibility for this code flow to happen. Still for
> correctness, we should close the segment here too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16164) Missing close of new compacted segments in few occasions which might leak MSLAB chunks from pool
[
https://issues.apache.org/jira/browse/HBASE-16164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15360472#comment-15360472
]
Anastasia Braginsky commented on HBASE-16164:
-
Anyhow just got aware about this fix. Indeed, true problem.
I think the better way would be to use "finally statement block" instead of
those if-else cascades...
Although, I can fix all the small coding-style issues in HBASE-14921, but I
just always have issues with rebases, due to many concurrent fixes in the same
place... :(
[~anoop.hbase], can you please ping me about this issues just on the start?
Even after getting a ping, it might take me a day to get to it.
But anyway, I wish I can have a chance to see the fix before it is committed.
> Missing close of new compacted segments in few occasions which might leak
> MSLAB chunks from pool
>
>
> Key: HBASE-16164
> URL: https://issues.apache.org/jira/browse/HBASE-16164
> Project: HBase
> Issue Type: Sub-task
>Affects Versions: 2.0.0
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-16164.patch
>
>
> An in memory compaction of N segments in progress. Inn between snapshot()
> call comes. We will stop the in progress compaction then. This just sets an
> AtomicBoolean. We check this boolean state in the compaction loop (while
> loop reading the cells from the segments) and before swapping the segments.
> But if this scenario comes, we are just ignoring the new newly compacted
> Segment. This is a problem maker when we work with MSLAB pool. The new
> segment would have acquired some chunks but when will they get released? As
> we dont close the segment this will leak them.
> Also in swap we have
> {code}
> public boolean swap(VersionedSegmentsList versionedList, ImmutableSegment
> segment) {
> if(versionedList.getVersion() != version) {
> return false;
> }
> LinkedList suffix;
> synchronized (pipeline){
> if(versionedList.getVersion() != version) {
> return false;
> }
> {code}
> I dont see any possibility for this code flow to happen. Still for
> correctness, we should close the segment here too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16164) Missing close of new compacted segments in few occasions which might leak MSLAB chunks from pool
[
https://issues.apache.org/jira/browse/HBASE-16164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15360370#comment-15360370
]
stack commented on HBASE-16164:
---
[~anastas], [~eshcar], FYI
> Missing close of new compacted segments in few occasions which might leak
> MSLAB chunks from pool
>
>
> Key: HBASE-16164
> URL: https://issues.apache.org/jira/browse/HBASE-16164
> Project: HBase
> Issue Type: Sub-task
>Affects Versions: 2.0.0
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-16164.patch
>
>
> An in memory compaction of N segments in progress. Inn between snapshot()
> call comes. We will stop the in progress compaction then. This just sets an
> AtomicBoolean. We check this boolean state in the compaction loop (while
> loop reading the cells from the segments) and before swapping the segments.
> But if this scenario comes, we are just ignoring the new newly compacted
> Segment. This is a problem maker when we work with MSLAB pool. The new
> segment would have acquired some chunks but when will they get released? As
> we dont close the segment this will leak them.
> Also in swap we have
> {code}
> public boolean swap(VersionedSegmentsList versionedList, ImmutableSegment
> segment) {
> if(versionedList.getVersion() != version) {
> return false;
> }
> LinkedList suffix;
> synchronized (pipeline){
> if(versionedList.getVersion() != version) {
> return false;
> }
> {code}
> I dont see any possibility for this code flow to happen. Still for
> correctness, we should close the segment here too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16164) Missing close of new compacted segments in few occasions which might leak MSLAB chunks from pool
[
https://issues.apache.org/jira/browse/HBASE-16164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15360126#comment-15360126
]
Hudson commented on HBASE-16164:
FAILURE: Integrated in HBase-Trunk_matrix #1154 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/1154/])
HBASE-16164 Missing close of new compacted segments in few occasions
(anoopsamjohn: rev 97f2294bfd17f7ae762d2e72ab0f25028b78f3fe)
*
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MemStoreCompactor.java
*
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/CompactionPipeline.java
*
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/CompactingMemStore.java
> Missing close of new compacted segments in few occasions which might leak
> MSLAB chunks from pool
>
>
> Key: HBASE-16164
> URL: https://issues.apache.org/jira/browse/HBASE-16164
> Project: HBase
> Issue Type: Sub-task
>Affects Versions: 2.0.0
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-16164.patch
>
>
> An in memory compaction of N segments in progress. Inn between snapshot()
> call comes. We will stop the in progress compaction then. This just sets an
> AtomicBoolean. We check this boolean state in the compaction loop (while
> loop reading the cells from the segments) and before swapping the segments.
> But if this scenario comes, we are just ignoring the new newly compacted
> Segment. This is a problem maker when we work with MSLAB pool. The new
> segment would have acquired some chunks but when will they get released? As
> we dont close the segment this will leak them.
> Also in swap we have
> {code}
> public boolean swap(VersionedSegmentsList versionedList, ImmutableSegment
> segment) {
> if(versionedList.getVersion() != version) {
> return false;
> }
> LinkedList suffix;
> synchronized (pipeline){
> if(versionedList.getVersion() != version) {
> return false;
> }
> {code}
> I dont see any possibility for this code flow to happen. Still for
> correctness, we should close the segment here too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16164) Missing close of new compacted segments in few occasions which might leak MSLAB chunks from pool
[
https://issues.apache.org/jira/browse/HBASE-16164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15360017#comment-15360017
]
Anoop Sam John commented on HBASE-16164:
We were seeing much more memory usage and GC issues using compacting memstore.
I found this by code flow walk through only. Then checked via some logs
whether it happens and it turned to be correct analysis.
> Missing close of new compacted segments in few occasions which might leak
> MSLAB chunks from pool
>
>
> Key: HBASE-16164
> URL: https://issues.apache.org/jira/browse/HBASE-16164
> Project: HBase
> Issue Type: Sub-task
>Affects Versions: 2.0.0
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-16164.patch
>
>
> An in memory compaction of N segments in progress. Inn between snapshot()
> call comes. We will stop the in progress compaction then. This just sets an
> AtomicBoolean. We check this boolean state in the compaction loop (while
> loop reading the cells from the segments) and before swapping the segments.
> But if this scenario comes, we are just ignoring the new newly compacted
> Segment. This is a problem maker when we work with MSLAB pool. The new
> segment would have acquired some chunks but when will they get released? As
> we dont close the segment this will leak them.
> Also in swap we have
> {code}
> public boolean swap(VersionedSegmentsList versionedList, ImmutableSegment
> segment) {
> if(versionedList.getVersion() != version) {
> return false;
> }
> LinkedList suffix;
> synchronized (pipeline){
> if(versionedList.getVersion() != version) {
> return false;
> }
> {code}
> I dont see any possibility for this code flow to happen. Still for
> correctness, we should close the segment here too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16164) Missing close of new compacted segments in few occasions which might leak MSLAB chunks from pool
[
https://issues.apache.org/jira/browse/HBASE-16164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15359997#comment-15359997
]
stack commented on HBASE-16164:
---
Patch looks fine. How did you figure this issue [~anoop.hbase]?
> Missing close of new compacted segments in few occasions which might leak
> MSLAB chunks from pool
>
>
> Key: HBASE-16164
> URL: https://issues.apache.org/jira/browse/HBASE-16164
> Project: HBase
> Issue Type: Sub-task
>Affects Versions: 2.0.0
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-16164.patch
>
>
> An in memory compaction of N segments in progress. Inn between snapshot()
> call comes. We will stop the in progress compaction then. This just sets an
> AtomicBoolean. We check this boolean state in the compaction loop (while
> loop reading the cells from the segments) and before swapping the segments.
> But if this scenario comes, we are just ignoring the new newly compacted
> Segment. This is a problem maker when we work with MSLAB pool. The new
> segment would have acquired some chunks but when will they get released? As
> we dont close the segment this will leak them.
> Also in swap we have
> {code}
> public boolean swap(VersionedSegmentsList versionedList, ImmutableSegment
> segment) {
> if(versionedList.getVersion() != version) {
> return false;
> }
> LinkedList suffix;
> synchronized (pipeline){
> if(versionedList.getVersion() != version) {
> return false;
> }
> {code}
> I dont see any possibility for this code flow to happen. Still for
> correctness, we should close the segment here too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16164) Missing close of new compacted segments in few occasions which might leak MSLAB chunks from pool
[
https://issues.apache.org/jira/browse/HBASE-16164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15359192#comment-15359192
]
Hadoop QA commented on HBASE-16164:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
3s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 37s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 35s
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
58s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
16s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 3s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 28s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 34s
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
45s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 41s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 41s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 38s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 38s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
57s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
16s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
27m 19s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
17s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 28s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 34s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 95m 29s
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
15s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 138m 36s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12815755/HBASE-16164.patch |
| JIRA Issue | HBASE-16164 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux asf900.gq1.ygridcore.net 3.13.0-36-lowlatency #63-Ubuntu SMP
PREEMPT Wed Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / cc73c03 |
| Default Java | 1.7.0_80 |
| Multi-JDK versions | /home/jenkins/tools/java/jdk1.8.0:1.8.0
/home/jenkins/jenkins-slave/tools/hudson.model.
[jira] [Commented] (HBASE-16164) Missing close of new compacted segments in few occasions which might leak MSLAB chunks from pool
[
https://issues.apache.org/jira/browse/HBASE-16164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15359140#comment-15359140
]
Ted Yu commented on HBASE-16164:
lgtm
> Missing close of new compacted segments in few occasions which might leak
> MSLAB chunks from pool
>
>
> Key: HBASE-16164
> URL: https://issues.apache.org/jira/browse/HBASE-16164
> Project: HBase
> Issue Type: Sub-task
>Affects Versions: 2.0.0
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-16164.patch
>
>
> An in memory compaction of N segments in progress. Inn between snapshot()
> call comes. We will stop the in progress compaction then. This just sets an
> AtomicBoolean. We check this boolean state in the compaction loop (while
> loop reading the cells from the segments) and before swapping the segments.
> But if this scenario comes, we are just ignoring the new newly compacted
> Segment. This is a problem maker when we work with MSLAB pool. The new
> segment would have acquired some chunks but when will they get released? As
> we dont close the segment this will leak them.
> Also in swap we have
> {code}
> public boolean swap(VersionedSegmentsList versionedList, ImmutableSegment
> segment) {
> if(versionedList.getVersion() != version) {
> return false;
> }
> LinkedList suffix;
> synchronized (pipeline){
> if(versionedList.getVersion() != version) {
> return false;
> }
> {code}
> I dont see any possibility for this code flow to happen. Still for
> correctness, we should close the segment here too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16164) Missing close of new compacted segments in few occasions which might leak MSLAB chunks from pool
[
https://issues.apache.org/jira/browse/HBASE-16164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15358709#comment-15358709
]
Anoop Sam John commented on HBASE-16164:
Dont mean the tail segment which was moved to snapshot. I mean the 'result'
segment created to which the Cells from N compacting segment were added. We
interrupted this op in btw and so this result segment is not getting added to
pipeline or so but just ignored. What if that used an MSLAB pool and got some
chunks? We miss close of this segment
> Missing close of new compacted segments in few occasions which might leak
> MSLAB chunks from pool
>
>
> Key: HBASE-16164
> URL: https://issues.apache.org/jira/browse/HBASE-16164
> Project: HBase
> Issue Type: Sub-task
>Affects Versions: 2.0.0
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
>Priority: Critical
> Fix For: 2.0.0
>
>
> An in memory compaction of N segments in progress. Inn between snapshot()
> call comes. We will stop the in progress compaction then. This just sets an
> AtomicBoolean. We check this boolean state in the compaction loop (while
> loop reading the cells from the segments) and before swapping the segments.
> But if this scenario comes, we are just ignoring the new newly compacted
> Segment. This is a problem maker when we work with MSLAB pool. The new
> segment would have acquired some chunks but when will they get released? As
> we dont close the segment this will leak them.
> Also in swap we have
> {code}
> public boolean swap(VersionedSegmentsList versionedList, ImmutableSegment
> segment) {
> if(versionedList.getVersion() != version) {
> return false;
> }
> LinkedList suffix;
> synchronized (pipeline){
> if(versionedList.getVersion() != version) {
> return false;
> }
> {code}
> I dont see any possibility for this code flow to happen. Still for
> correctness, we should close the segment here too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16164) Missing close of new compacted segments in few occasions which might leak MSLAB chunks from pool
[
https://issues.apache.org/jira/browse/HBASE-16164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15358699#comment-15358699
]
ramkrishna.s.vasudevan commented on HBASE-16164:
Ya closing is fine but as such won't be a problem because once snapshot (the
tail element) is flushed that segment is returned back to the pool. So is there
a chance for leak here?
> Missing close of new compacted segments in few occasions which might leak
> MSLAB chunks from pool
>
>
> Key: HBASE-16164
> URL: https://issues.apache.org/jira/browse/HBASE-16164
> Project: HBase
> Issue Type: Sub-task
>Affects Versions: 2.0.0
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
>Priority: Critical
> Fix For: 2.0.0
>
>
> An in memory compaction of N segments in progress. Inn between snapshot()
> call comes. We will stop the in progress compaction then. This just sets an
> AtomicBoolean. We check this boolean state in the compaction loop (while
> loop reading the cells from the segments) and before swapping the segments.
> But if this scenario comes, we are just ignoring the new newly compacted
> Segment. This is a problem maker when we work with MSLAB pool. The new
> segment would have acquired some chunks but when will they get released? As
> we dont close the segment this will leak them.
> Also in swap we have
> {code}
> public boolean swap(VersionedSegmentsList versionedList, ImmutableSegment
> segment) {
> if(versionedList.getVersion() != version) {
> return false;
> }
> LinkedList suffix;
> synchronized (pipeline){
> if(versionedList.getVersion() != version) {
> return false;
> }
> {code}
> I dont see any possibility for this code flow to happen. Still for
> correctness, we should close the segment here too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
