FWIW... I've always required my teams to follow a practice where any class which takes ownership of a resource is required to guarantee it is released properly, and to treat leaking the resource as something worth of throwing an assert or exception unless the object was explicitly ordered to leak the resource.
In this case, I'd recommend adding an argument to open to enable/disable automatic close on delete, with the default behavior being to close on delete. That way if there is a corner case requiring such behavior, it is possible to achieve with the public API, yet the default behavior will be to handle the resource safely. In this specific use case I've seen too many leaks occurring during exception stack unwinding that were difficult to resolve cleanly... On Fri, Feb 12, 2010 at 6:32 AM, Steve Huston (JIRA) < [email protected]> wrote: > > [ > https://issues.apache.org/jira/browse/QPID-2395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12832982#action_12832982] > > Steve Huston commented on QPID-2395: > ------------------------------------ > > Stefan, the constructor doesn't initialize the fd; the open() call does, so > we're not really talking about RAII here. Thus, requiring a corresponding > close() is legitimate. > > Also, if the destructor were to close the fd, we'd introduce subtle > problems where objects may be copied and one of the copies goes out of > scope, closing the fd out from under the others. > > > fd leak in Connection > > --------------------- > > > > Key: QPID-2395 > > URL: https://issues.apache.org/jira/browse/QPID-2395 > > Project: Qpid > > Issue Type: Bug > > Components: C++ Client > > Affects Versions: 0.6 > > Environment: Linux dev-gmx001 2.6.31.8-GMX-CORE2_64 #1 SMP Tue > Dec 15 10:21:34 CET 2009 x86_64 Intel(R) Xeon(R) CPU E5405 @ 2.00GHz > GenuineIntel GNU/Linux > > Debian GNU/Linux 3.1 > > gcc version 4.3.3 (Debian 4.3.3-13.1) > > Reporter: Daniel Etzold > > Assignee: Steve Huston > > Fix For: 0.7 > > > > > > Hi, > > with the following code we are able to reproduce a fd leak: > > #include <qpid/client/Connection.h> > > int main(int argc, char** argv) > > { > > while (1) { > > qpid::client::Connection connection; > > connection.open("localhost", 5672); > > // connection.close(); > > } > > } > > When closing the connection explicitely as shown in the comment the fd > leak no longer occurs. It seems that the destructor of Connection lacks > closing the connection. > > Regards, > > Daniel > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > >
