Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 7D77E200BB6 for ; Fri, 4 Nov 2016 20:14:19 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 7C054160AEA; Fri, 4 Nov 2016 19:14:19 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id B901C160AFE for ; Fri, 4 Nov 2016 20:14:18 +0100 (CET) Received: (qmail 87424 invoked by uid 500); 4 Nov 2016 19:14:17 -0000 Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@accumulo.apache.org Delivered-To: mailing list dev@accumulo.apache.org Received: (qmail 87410 invoked by uid 99); 4 Nov 2016 19:14:17 -0000 Received: from git1-us-west.apache.org (HELO git1-us-west.apache.org) (140.211.11.23) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Nov 2016 19:14:17 +0000 Received: by git1-us-west.apache.org (ASF Mail Server at git1-us-west.apache.org, from userid 33) id 5651FE04EE; Fri, 4 Nov 2016 19:14:17 +0000 (UTC) From: ivakegg To: dev@accumulo.apache.org Reply-To: dev@accumulo.apache.org References: In-Reply-To: Subject: [GitHub] accumulo issue #179: ACCUMULO-4502 Added volative to some class members to m... Content-Type: text/plain Message-Id: <20161104191417.5651FE04EE@git1-us-west.apache.org> Date: Fri, 4 Nov 2016 19:14:17 +0000 (UTC) archived-at: Fri, 04 Nov 2016 19:14:19 -0000 Github user ivakegg commented on the issue: https://github.com/apache/accumulo/pull/179 After an exhaustive search through this code, the only reason I can come up with is an issue with a member reference in the underlying HeapIterator. The scenario would be as follows: thread 1: calls hasTop() which is invoked on then in memory data source thread 2: calls switchSource which sets up the new datasource and calls seek which results in topIdx being set thread1: calls next() which gets a value of null for topIdx So if topIdx is marked as volatile then this should not happen. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastructure@apache.org or file a JIRA ticket with INFRA. ---