From user-return-55551-archive-asf-public=cust-asf.ponee.io@hbase.apache.org Tue Sep 25 16:47:31 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 8C37F18061A for ; Tue, 25 Sep 2018 16:47:30 +0200 (CEST) Received: (qmail 95295 invoked by uid 500); 25 Sep 2018 14:47:29 -0000 Mailing-List: contact user-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@hbase.apache.org Delivered-To: mailing list user@hbase.apache.org Received: (qmail 95284 invoked by uid 99); 25 Sep 2018 14:47:29 -0000 Received: from mail-relay.apache.org (HELO mailrelay2-lw-us.apache.org) (207.244.88.137) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 25 Sep 2018 14:47:29 +0000 Received: from mail-qt1-f177.google.com (mail-qt1-f177.google.com [209.85.160.177]) by mailrelay2-lw-us.apache.org (ASF Mail Server at mailrelay2-lw-us.apache.org) with ESMTPSA id 3F0E42332 for ; Tue, 25 Sep 2018 14:47:28 +0000 (UTC) Received: by mail-qt1-f177.google.com with SMTP id z14-v6so8617949qtn.2 for ; Tue, 25 Sep 2018 07:47:28 -0700 (PDT) X-Gm-Message-State: ABuFfogaro88bZWRrSWftZa/6MkmsQs94Dbj/HX+bZSbkqhBPXmxKXCV FFMeNqwxqP18FKIEv6S3ewRQS3Rq1gYY2Wy7Th0= X-Google-Smtp-Source: ACcGV63mRnLEaU0Kt3ocCHudQaHB1tmnX/IHMu60MxF37RYMwLhUeR/IQ2S2rx0Hpf0ALcu9pt5AfKER9GtDYk09PAo= X-Received: by 2002:ac8:3396:: with SMTP id c22-v6mr1054597qtb.190.1537886847890; Tue, 25 Sep 2018 07:47:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Sean Busbey Date: Tue, 25 Sep 2018 07:47:15 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: HBase REST Client class appears not to be Thread Safe To: user@hbase.apache.org Content-Type: multipart/alternative; boundary="00000000000045f9ed0576b32f9e" --00000000000045f9ed0576b32f9e Content-Type: text/plain; charset="UTF-8" Yep! Raise a JIRA describing the issue. If you're up for fixing it leave a comment stating so and one of the JIRA admins will make it so you can assign the ticket to yourself. We fix things in the most recent branch impacted first; for this it'd be master. Thanks for pointing this issue out! On Tue, Sep 25, 2018, 01:57 Jon Poulton wrote: > Hi there, > Not that hard to make it thread safe to be honest. And given the older > version of the client was thread safe, "principal of least surprise" > suggests that it continue to be so. Apache Http Components is a nice > library that is well understood, and it looks like its being used correctly > elsewhere in the class. The instance variables are only used in a couple of > places, and can be replaced with variables at the method level, which seems > to have been done correctly in most methods. You could then explicitly > state in the Javadoc that the client is intended to be thread safe. > > Would I raise a raise a ticket with your issue tracking system first? And > which branch would this be fixed in? Apologies, I'm not really a regular > open source contributor. > > Jon > > On Tue, 25 Sep 2018 at 04:50, Stack wrote: > > > Yeah, looks like it is not written thread-safe. > > > > As you suggest, we should note that at the least. You think it possible > to > > make it thread-safe Jon? Is it onerous running multiple clients or a pool > > of clients? > > > > Thanks, > > M > > > > On Mon, Sep 24, 2018 at 11:04 AM Jon Poulton wrote: > > > > > I was looking at moving up to the 2.1 version of the HBase REST API and > > was > > > poking around the code base wondering how I set headers on a per > request > > > basis, when I noticed the the "Client" class at: > > > > > > > > > https://github.com/apache/hbase/blob/branch-2.1/hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/client/Client.java > > > appears to have HttpGet and HttpResponse instance variables (line 68 > and > > > 69) that are not synchronised, nor do they have any kind of associated > > > lock. The thread safety of the Client is undocumented, but usually > Client > > > classes can assumed to be thread safe. > > > > > > These instance variables are used further down in the class in > > > unsynchronized blocks, meaning that were more than one thread to access > > > methods that accessed the variables there is a potential race > condition. > > I > > > was wondering if this is a known issue, a deliberate choice for some > > > reason, or if the class is not supposed to be used in a multithreaded > > > manner, and is intended to be used only within ThreadLocal? > > > > > > I checked in the master branch of the project and the issue appears to > be > > > present there also. > > > > > > Thanks > > > > > > Jon > > > > > > --00000000000045f9ed0576b32f9e--