incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Williams <william...@gmail.com>
Subject Re: Potentially serious problem with BlurClient.getClient
Date Thu, 16 Oct 2014 15:31:10 GMT
On Thu, Oct 16, 2014 at 11:00 AM, Chris Rohr <rohr.chris@gmail.com> wrote:
> Recently Andrew and I updated Blur Console to work with the changes
> for random ports on controllers and shards.  In doing so we also added
> in a BlurCachingClient that caches some calls to Blur for a period of
> time so that the console doesn't inundate Blur with requests.  The
> caching client has a method called getClient that returns the response
> from BlurClient.getClient.
>
> Looking through the code, it seems to us that getClient returns a new
> client instance every time it is called.  I'm not sure if/when this
> has changed, but I thought that in the past calling getClient over and
> over would return the same client on subsequent calls.
>
> The big problem we are seeing is that in a very short period with ~ 5
> people using the console, the console can run the system out of file
> handles because it is not closing the connections to Blur on the
> previous clients that were created.
>
> Any thoughts on this?

Hey Chris,
There's two issues here - one, the zkClient wasn't properly being
closed, so multiple calls was leaking connections.  The other is an
assumption of expected normal usage - since the BlurClient impl is
threadsafe, I thought everyone would generally create one and re-use
it over and over to avoid the parsing or maintaining the list of
connections.  That was clearly a bad assumption.

A fix for the leaky zk connections should be in any minute now.

I do think we should encourage users to grab a client and re-use it
though, there's not much downside to doing that.

Thanks,
--tim

Mime
View raw message