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). Dan 27 sep 2013 kl. 13:36 skrev George Chung <[email protected]>: > 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 <[email protected]>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
