On Fri, 2016-04-08 at 10:21 +0100, Gordon Sim wrote: > On 07/04/16 21:07, Alan Conway wrote: > > > > Currently proton-C and the various bindings do *not* auto-close > > contained objects when the container closes. I.e. closing a > > connection > > does not close its sessions, closing a session does not close its > > links > > etc. Also closing a transport does not automatically close its > > connection. > > > > I believe there are some reconnect use-cases that require this, > > e.g. if > > the transport closes unexpectedly you want to keep the connection > > and > > its children around so you can use them to re-build connection > > state on > > a new transport. > > > > However in the majority of cases it is a huge pain. Look at the > > existing broker.cpp example, `remove_stale_consumers`. The example > > isn't even complete: you must implement transport_close, > > connection_close, link_close (or in C++ sender_close and > > receiver_close) AND session_close (forgotten in the broker.cpp > > example) > > to clean up link resources correctly. > The way I think of this, it is not that contained objects are not > 'auto-closed' so much as that there is no event that can be used to > hook > in application specific cleanup that is required whether or not the > object was closed explicitly or implicitly (as a result of the object > in > which it is contained being closed). > > > > > I'd like to find a way to automate this that doesn't break the > > reconnect cases. Ideally I'd like it to be the default behavior > > unless > > a reconnect handler is in play. Can that be done with the existing > > event set or do we need new events? > I think it would be prudent to retain the ability to distinguish > between > implicit and explicit 'close' if needed. It is also vital to > distinguish > between (at a minimum) detach and close for links, since these have > different behaviour for many cases. (Ending a session detaches a > link > rather than closing it).
Agreed that auto-close is a bad way to phrase it. If we were to add convenience cleanup events they would need to be clearly distinguished, e.g. on_x_final. I'm undecided on whether we should put the final events in the model or just leave it to the application. They are not strictly necessary (since they can be deduced from close events) and complicate the interface. Here's what prompted this: the broker examples only need to track senders. But to correctly clean up they must implement on_close for every endpoint: transport, connection, session and link, when they have no other reason to handle these events. It is error prone, the proof: existing examples all forgot to handle on_session_close. Cheers, Alan. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
