Opinions on QPID-2395

[Andrew Stitcher <as...@redhat.com>]

I'm interested in opinions as to the correct behaviour for QPID-2395:
https://issues.apache.org/jira/browse/QPID-2395

The real question IMO hinges on whether copying a Connection is
allowed/makes sense.

If copying a connection isn't allowed then closing the underlying socket
on Connection destruction should be the way to go.

If copying a Connection makes sense then I think we do need a way to
close the underlying socket when the last connection closes.

I don't think that relying on Connection.close is a very safe strategy.

What do the rest of you think? How does this happen in python?

Andrew



---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

Re: Opinions on QPID-2395

[Rafael Schloming <ra...@redhat.com>]

Andrew Stitcher wrote:
> I'm interested in opinions as to the correct behaviour for QPID-2395:
> https://issues.apache.org/jira/browse/QPID-2395
> 
> The real question IMO hinges on whether copying a Connection is
> allowed/makes sense.
> 
> If copying a connection isn't allowed then closing the underlying socket
> on Connection destruction should be the way to go.
> 
> If copying a Connection makes sense then I think we do need a way to
> close the underlying socket when the last connection closes.

What would copying a connection (other than just copying a ref) mean?

> I don't think that relying on Connection.close is a very safe strategy.

FWIW in Java and Python I would consider it a programming error to not 
explicitly call Connection.close(). This is partly because in Java and 
Python you can't depend on deterministic destructor behavior, but I do 
vaguely recall some subtle cpp bug a while back that was due to over 
dependence on destructors doing cleanup.

> What do the rest of you think? How does this happen in python?

The analogous code in python would also leak file descriptors. In fact 
it would leak the whole connection object because the client's I/O 
thread will have a pointer to it until you explicitly call close.

--Rafael

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

Re: Opinions on QPID-2395

[Alan Conway <ac...@redhat.com>]

On 02/22/2010 03:43 PM, Andrew Stitcher wrote:
> I'm interested in opinions as to the correct behaviour for QPID-2395:
> https://issues.apache.org/jira/browse/QPID-2395
>
> The real question IMO hinges on whether copying a Connection is
> allowed/makes sense.
>
> If copying a connection isn't allowed then closing the underlying socket
> on Connection destruction should be the way to go.
>
> If copying a Connection makes sense then I think we do need a way to
> close the underlying socket when the last connection closes.
>
> I don't think that relying on Connection.close is a very safe strategy.
>
> What do the rest of you think? How does this happen in python?
>

Connections should automatically be cleaned up, looking at 
ConnectionImpl::~ConnectionImpl there is a clear attempt to do so. If it's 
leaking its a bug.

Note that connection uses the PIMPL idio so client::Connection is really just a 
ref-counted pointer to a ConnectionImpl. So client::Connection can indeed be 
copied and client::~Connection should definitely not calll close()

However once all the client::Connections are gone, 
ConnectionImpl::~ConnectionImpl should make sure the connection is closed.

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org