incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew <>
Subject Re: Potentially serious problem with BlurClient.getClient
Date Thu, 16 Oct 2014 16:28:28 GMT
Thanks for the clarification. We'll definitely change the console to re-use
one client.
My concern is that this could be a breaking change. If a user was
re-requesting the client like we were, this small point release update
could break their system.
I don't know that we need to roll back the change, but we need to be sure
to clearly communicate this in the release notes.


On Thu, Oct 16, 2014 at 11:31 AM, Tim Williams <> wrote:

> On Thu, Oct 16, 2014 at 11:00 AM, Chris Rohr <> 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

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