incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew <andrew...@gmail.com>
Subject Re: Potentially serious problem with BlurClient.getClient
Date Thu, 16 Oct 2014 16:28:28 GMT
Tim,
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.

Thanks
Andrew

On Thu, Oct 16, 2014 at 11:31 AM, Tim Williams <williamstw@gmail.com> wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message