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
