Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Wed, 23 Dec 2015 18:20:46 +0000 (UTC)
From: "Josh Elser (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12924013.1450881759000.103912.1450894846693@Atlassian.JIRA>
In-Reply-To: <JIRA.12924013.1450881759000@Atlassian.JIRA>
References: <JIRA.12924013.1450881759000@Atlassian.JIRA>
 <JIRA.12924013.1450881759937@arcas>
Subject: [jira] [Commented] (ACCUMULO-4090) BatchWriter close not cleaning
 up all resources
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Josh Elser commented on ACCUMULO-4090:
--------------------------------------

bq. Looking at the TabletServerBatchWriter objects in the heap dump I see that the closed field is always false. I wonder if the root cause is that this field is not marked as volatile (and the flushing field may be an issue too).

Wouldn't those only need to be volatile if they were accessed outside of synchronized blocks? As far as I see, {{closed}} is only accessed inside synchronized methods.

> BatchWriter close not cleaning up all resources
> -----------------------------------------------
>
>                 Key: ACCUMULO-4090
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-4090
>             Project: Accumulo
>          Issue Type: Bug
>          Components: client
>    Affects Versions: 1.7.0
>            Reporter: Eric Newton
>            Assignee: Eric Newton
>
> I'm debugging an issue with a long-running ingestor, similar to the TraceServer.
> After realizing that BatchWriter close needs to be called when a MutationsRejectedException occurs (see ACCUMULO-4088), a close was added, and the client became more stable.
> However, after a day, or so, the client became sluggish. When inspecting a heap dump, many TabletServerBatchWriter objects were still referenced.  This server should only have two BatchWriter instances at any one time, and this server had >100.
> Still debugging.
> The error that initiates the issue is a SessionID not found, presumably because the session timed out.  This is the cause of the MutationsRejectedException seen by the client.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)