hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Poulton <jsp1...@gmail.com>
Subject Re: HBase REST Client class appears not to be Thread Safe
Date Tue, 25 Sep 2018 08:57:40 GMT
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.


On Tue, 25 Sep 2018 at 04:50, Stack <stack@duboce.net> 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 <jsp1611@gmail.com> 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
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message