thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From George Chung <geo...@glympse.com>
Subject Re: Issues with client transport not closing sockets
Date Fri, 27 Sep 2013 11:36:11 GMT
The type of issue you are describing is sometimes called the "deterministic
finalization" issue in garbage collected environments...where the objects
wrap actual OS resources that need to be "closed" deterministically. I
haven't used Java in a while, but other languages provide support for this
for exactly this reason.


On Fri, Sep 27, 2013 at 3:21 AM, Dan Engelbrecht <dan@engelbrecht.com>wrote:

> Hi all, have been quietly following this mailinglist for a while and doing
> some thrift programming.
>
> I have stumbeled onto a java issue which relates (indirectly) to garbage
> collection.
>
> If I create a client that connects to a server and then let the client
> fall out of scope the clients socket stays open (probably until gc?) which
> can be a long while - in my testapp that equated to more or less "forever".
>
> This would not be so bad with the exception that my TThreadPool server
> wont stop.
>
> I can get around this by manually closing the transports for the client
> but that is quite ugly:
>
> client.getInputProtocol().getTransport().close();
> client.getOutputProtocol().getTransport().close();
>
> I could keep the client transport instance around but then I need to
> maintain two variables for one client.
>
> Wouldn't a .close() on the client be a better option? Or am I missing
> something?
>
> Best regards
> Dan Engelbrecht

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