-
Committer:
Free Ekanayaka
-
Date:
2016-11-22 13:46:55 UTC
-
mfrom:
(73.2.11 closing-logic-cleanup)
-
Revision ID:
free.ekanayaka@canonical.com-20161122134655-54eab5dvrodsx11g
This branch implements the following changes:
- TwistedDelegate.connection_close now sends a 'close-ok' method frame before
calling AMQClient.doClose. There's no response for this type of method, but
we can be confident that it will be written to the transport before the
transport gets closed, since AMQClient.doClose eventually calls
transport.loseConnection(), which does flush buffers before shutting down
the socket.
- AMQClient now has a new "disconnected" instance attribute, which is a
TwistedEvent that consumer code can wait on in order to know when the
transport has actually shut down. This is useful for integrating
txamqp with things like twisted.application.internet.ClientService (that
would start to connect again as soon as the connection is lost).
- AMQClient.closed is now properly initialized in the __init__ (it was set
dynamically before), so it's always safe to inspect it.
- The AMQClient.sendHB LoopingCall now gets the same clock as AMQClient, instead
of the global reactor. This makes unit-testing easier.
- AMQClient.queues (of type TimeoutDeferredQueue) also get same clock
as AMQClient.
- The "reason" parameter of AMQClient.close is now optional and defaults
to ConnectionDone.
- AMQClient.close has a new "within" parameter, which tells the client to
possibly try to perform a clean connection shutdown with the 'close'/'close-ok'
frames handshake. If the handshake doesn't succeed in "within" seconds, the
transport connection gets terminated without handshake. The default of the
new parameter is 0, which means "do close immediately without handshake", so
there's should be no behavior change at all for existing code, expect that
close() now returns a Deferred.
- The old AMQClient.close logic has been moved to AMQClient.doClose, which is
basically the same pattern as AMQChannel.close/doClose.
- AMQClient.checkHeartbeat now calls abortConnection rather than loseConnection: since
the peer is unresponsive it most probably won't perform the TCP closing handshake
anyways.
- Unit tests and integration tests where added for all the behavior above.