thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Engelbrecht <>
Subject Re: Issues with client transport not closing sockets
Date Fri, 27 Sep 2013 11:49:32 GMT
Yeah, I know but I need to make it "behave" so my option is the workaround currently. 

A lot of classes has an explicit "close" or "dispose" for just this purpose - open files etc.

I'm just asking if a close method on the client wouldn't be appropriate in java (and maybe
other languages for consistency).


27 sep 2013 kl. 13:36 skrev George Chung <>:

> 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 <>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

View raw message