On 28 March 2013 02:45, Rafael Schloming <r...@alum.mit.edu> wrote:
> On Wed, Mar 27, 2013 at 6:34 PM, Rob Godfrey <rob.j.godf...@gmail.com
> > On 27 March 2013 21:16, Rafael Schloming <r...@alum.mit.edu> wrote:
> > > On Wed, Mar 27, 2013 at 11:53 AM, Keith W <keith.w...@gmail.com>
> > >
> > [..snip..]
> > >
> > >> 3. How will the application using top half API know an error has
> > >> occured? What are the application's responsibilities when it learns of
> > >> an error?
> > >>
> > >
> > > The transport has an error variable which can be inspected to get more
> > > information about what has happened. Also, if/when the transport is
> > unbound
> > > from the connection, all of the remote endpoint states will transition
> > back
> > > to UNINIT.
> > >
> > > I'm not sure how to answer what the applications responsibilities are.
> > That
> > > seems to depend on the application. It could just decide to shutdown
> > > an error message or it could decide to employ some sort of retry
> > strategy,
> > > e.g. connect to a backup service, create a new transport, and bind it
> > > the same top half. I'm not sure I'd say it has any hard and fast
> > > responsibilities per/se though.
> > >
> > >
> > I think the point Keith was trying to make here is that in order for a
> > component to be compliant with the AMQP specification, anywhere where
> > the spec says "The connection/session/link should be
> > closed/ended/detached with the X error", is it the application that
> > actually has responsibility for setting the local error state and
> > calling the close() on the appropriate endpoint. If it is we are
> > placing a burden on the application authors to preserve AMQP
> > compliance.
> Ah, that makes sense. Thanks for clarifying. I don't recall offhand all the
> places the spec says close/end/detach with an X error, but in situations
> like framing errors or missing/invalid arguments required by the transport
> to properly maintain state, say an out-of-sequence delivery-id, that is
> something the transport would handle automatically. I expect there may be
> some cases that the top half would need to initiate explicitly though, e.g.
> obviously a redirect error would need to be initiated by the top half.
So when you say the transport handles automatically, how does that work
from the app's perspective? Is the transport updating the local state of
the endpoint, or the remote state... if the transport is actually injecting
the close performative into the outgoing stream (the detach, end, or close)
then it seems somewhat weird if the local app still sees this endpoint as
locally open.. on the other hand it is also weird if the local state is now
a shared responsibility between the app and the transport.
Also what about cases where the error is in the opening performative for
the endpoint (open,begin,attach)... if the way to communicate the error is
by responding with the paired closing performative, this may first require
the sending of an opening... For example, if there is an error in an
incoming (unsolicited) open frame - say the container id is null - then the
only way to communicate this back to the other side is to send a valid open
immediately followed bby a close frame with the appropriate error code.
Are you saying that the transport would do all this silently without this
being visible to the app?