Re: pn_delivery_finalize Assertion failure

[Rob Godfrey]

On 24 March 2017 at 14:38, Alan Conway  wrote:

> On Thu, 2017-03-09 at 02:06 -0700, Tobias Duckworth wrote:
> > I got to the bottom of this problem.
> >
> > The problem is to to with the lifetime of the proton::delivery
> > object.
> >
> > In a connection_engine build, the IO is asynchronous to the
> > proton::handler
> > interface, and therefore this problem may only occur in
> > connection_engine
> > builds (not absolutely certain, as I've not tested on a 'normal'
> > build).
> >
> > When a message is received, it comes along with a delivery object.
> > The
> > delivery object can be used to accept, reject, release the delivery
> > with the
> > broker.
> >
> > Internally to the proton-c C implementation there are a complicated
> > set of
> > state transitions that happen which I have not totally got my head
> > around.
> > However, what I do know is that the delivery object needs to stick
> > around
> > until the operation is totally finished - Otherwise it's possible for
> > the
> > observed behaviour to happen, which causes the assertion failures or
> > a much
> > nastier crash.
> >
> > The call to proton::delivery::accept (or release, reject) returns
> > almost
> > straightaway, and then the actual work of settling the message with
> > the
> > broker happens when the underlying IO operation is invoked with
> > process(),
> > or process_nothrow(). If, by this time, the delivery object that was
> > used
> > has been deleted or destroyed, then the problem will happen
> >
> > Turning on tracing using PN_TRACE_FRM, one can see the following when
> > the
> > engine has finished with the delivery:
> >
> > [0x2b4af8030500]:1 -> @disposition(21) [role=true, first=124,
> > last=124,
> > settled=true, state=@accepted(36) []] .
> >
> > Unfortunately, there is no interface back to the C++ world to tell us
> > when
> > the delivery is finished with, and so there appears to be no way to
> > know
> > when it is safe to destroy the delivery object.
> >
>
> There are callbacks, but on the sender side the delivery is referred to
> as a "tracker", "delivery" is only used on the receiver side. This is
> an attempt to rationalize the API since there are different ops
> relevant on sender and receiver side.
>
> > Other than keeping proton::delivery objects sticking around in memory
> > forever (which does solve the problem, but is not an option), does
> > anyone
> > have any ideas for solving this?
> >
> > It seems to me like the C++ proton::delivery object itself should
> > know about
> > whether it has been settled with the broker or not, so unless anyone
> > has a
> > better suggestion this is likely to be what I will add.
> >
>
> They should be deleted automatically without user intervention after
> they settle and all events are processed. If you have a reproducer to
> show they are not then raise a JIRA (even better if you attach a fix
> :).



> Note that unsettled deliveries will outlive the link they were
> created on, the AMQP spec allows settlement after the link has closed.
>
>
To be precise the spec allows for the state of the delivery to be updated
after the link has been *detached*.  Once a link is closed then the
delivery should no longer be updatable through disposition exchanges, etc
(the default outcome for the source should be applied at that point).

(From 2.7.6 Dispositions : "The disposition performative MAY refer to
deliveries on links that are no longer attached. As long as the links have
not been closed or detached with an error then the deliveries are still
'live' and the updated state MUST be applied." -
http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#type-disposition
)

-- Rob


>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: [Proton C++ 0.16.0] Reconnect and reconnect timer

[Alan Conway]

On Fri, 2017-03-17 at 17:21 +0100, Rabih M wrote:
> Hello,
> 
> Bit of context:
> I am trying to implement a connection retry mechanism using proton. A
> bit
> similar to the failover Url in JMS...
> 
> I discovered that we can set "reconnect" option in the
> connection_options.reconnect(reconnect_timer).
> 
> There are no clear documentation, how does this option behaves?
> Does it try to reconnect only at connection start? and does it try to
> reconnect in the middle of an Amqp communication (after
> sending/receiving
> some messages)?
> 
> On the other side, how to know that the max retries or dead line
> timeout is
> reached?
> 

See include/proton/reconnect_timer.hpp for the things you can
configure. This is still an "experimental" feature and could use some
rounding out - your experience can be helpful with that.

Currently this will reconnect on an unexpected disconnect - that is to
say on_transport_closed() occurs before on_connection_closed()



-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: pn_delivery_finalize Assertion failure

[Alan Conway]

On Thu, 2017-03-09 at 02:06 -0700, Tobias Duckworth wrote:
> I got to the bottom of this problem.
> 
> The problem is to to with the lifetime of the proton::delivery
> object.
> 
> In a connection_engine build, the IO is asynchronous to the
> proton::handler
> interface, and therefore this problem may only occur in
> connection_engine
> builds (not absolutely certain, as I've not tested on a 'normal'
> build).
> 
> When a message is received, it comes along with a delivery object.
> The
> delivery object can be used to accept, reject, release the delivery
> with the
> broker.
> 
> Internally to the proton-c C implementation there are a complicated
> set of
> state transitions that happen which I have not totally got my head
> around.
> However, what I do know is that the delivery object needs to stick
> around
> until the operation is totally finished - Otherwise it's possible for
> the
> observed behaviour to happen, which causes the assertion failures or
> a much
> nastier crash.
> 
> The call to proton::delivery::accept (or release, reject) returns
> almost
> straightaway, and then the actual work of settling the message with
> the
> broker happens when the underlying IO operation is invoked with
> process(),
> or process_nothrow(). If, by this time, the delivery object that was
> used
> has been deleted or destroyed, then the problem will happen
> 
> Turning on tracing using PN_TRACE_FRM, one can see the following when
> the
> engine has finished with the delivery:
> 
> [0x2b4af8030500]:1 -> @disposition(21) [role=true, first=124,
> last=124,
> settled=true, state=@accepted(36) []] .
> 
> Unfortunately, there is no interface back to the C++ world to tell us
> when
> the delivery is finished with, and so there appears to be no way to
> know
> when it is safe to destroy the delivery object.
> 

There are callbacks, but on the sender side the delivery is referred to
as a "tracker", "delivery" is only used on the receiver side. This is
an attempt to rationalize the API since there are different ops
relevant on sender and receiver side.

> Other than keeping proton::delivery objects sticking around in memory
> forever (which does solve the problem, but is not an option), does
> anyone
> have any ideas for solving this?
> 
> It seems to me like the C++ proton::delivery object itself should
> know about
> whether it has been settled with the broker or not, so unless anyone
> has a
> better suggestion this is likely to be what I will add.
> 

They should be deleted automatically without user intervention after
they settle and all events are processed. If you have a reproducer to
show they are not then raise a JIRA (even better if you attach a fix
:). Note that unsettled deliveries will outlive the link they were
created on, the AMQP spec allows settlement after the link has closed.



-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: [qpid-proton-cpp] default_container does not implement thread safety at all?

[Alan Conway]

On Fri, 2017-03-24 at 14:06 +0530, Venkat B wrote:
> Good day,
> 
> -- Forwarded message --
> > From: Alan Conway 
> > To: users@qpid.apache.org
> > Cc:
> > Bcc:
> > Date: Wed, 22 Mar 2017 14:09:00 -0400
> > Subject: Re: [qpid-proton-cpp] default_container does not implement
> > thread
> > safety at all?
> > 
> 
> [snip]
> > 
> > And to be clear this is abuse to hack out of a short-term hole - we
> > will have a properly behaved solution soon.
> > 
> > 
> 
> Do you have something that I could test?
> The code in examples/cpp/mt does not compile out of the box on 0.17.0
> and
> in case it is being redesigned anyway then I would prefer to work
> with the
> new API.
> 

I defer to astitcher on the current state of the examples. The API
isn't changing significantly, the code in mt/broker.cpp will still be 
correct with only minor changes if any. 

The code in epoll_container.cpp will also still be basically unchanged
but writing a custom container will no longer be necessary for most
cases: the default_container will be thread-safe and we will have
epoll-native, iocp-native and libuv flavours to cover most needs.



-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: [qpid-proton-cpp] default_container does not implement thread safety at all?

[Venkat B]

Good day,

-- Forwarded message --
> From: Alan Conway 
> To: users@qpid.apache.org
> Cc:
> Bcc:
> Date: Wed, 22 Mar 2017 14:09:00 -0400
> Subject: Re: [qpid-proton-cpp] default_container does not implement thread
> safety at all?
>
[snip]
>
> And to be clear this is abuse to hack out of a short-term hole - we
> will have a properly behaved solution soon.
>
>
Do you have something that I could test?
The code in examples/cpp/mt does not compile out of the box on 0.17.0 and
in case it is being redesigned anyway then I would prefer to work with the
new API.

Regards,
Venkat