> On Sept. 6, 2016, 8:18 p.m., Alan Conway wrote:
> > Mostly nits, one major problem: I see no way to control the frequency or 
> > limit the number of resends. We need the same kind of controls for that as 
> > we have for connection retries, otherwise we will burn CPU on client and 
> > router with constant resends if the back end takes time to recover, or 
> > never recovers, or keeps releasing the same messages.

Thought: for handling rejection and allowing manual handling of relase: can we 
throw an exception that carries the message when handling the disposition? At 
that point the user can do what they like: resend, not resend, send somewhere 
else etc. etc. When automatic resend is disabled, then I see no difference 
between release and reject: they're both things the user might need to know 
about, and in both cases the user may want to do something else with the 
message.


- Alan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/51638/#review147907
-----------------------------------------------------------


On Sept. 6, 2016, 4:53 p.m., Gordon Sim wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51638/
> -----------------------------------------------------------
> 
> (Updated Sept. 6, 2016, 4:53 p.m.)
> 
> 
> Review request for qpid and Alan Conway.
> 
> 
> Repository: qpid-cpp
> 
> 
> Description
> -------
> 
> Rejected messages cause an exception to be thrown. However this does not
>     invalidate the session in anyway. More messages can be sent after
>     catching the exception. The original behaviour - i.e. simply ignoring
>     the rejected messages - can be obtained by setting the connection option
>     'ignore_delivery_refused' to true.
>     
>     Released messages cause the transport to be aborted, triggering the usual
>     resending logic (whether defined by the application or using that defined
>     in the library itself). Again, released messages can be simply ignored as
>     they were prior to this change by setting 'ignore_undelivered' to true.
>     
>     For modified messages, if undeliverable-here is set to true, the message 
> is
>     treated as if it had been rejected, otheriwse if delivery-failed is set to
>     true it is treated as a released message. If neither is set it is simply
>     ignored with a warning (i.e. treated as accepted).
> 
> 
> Diffs
> -----
> 
>   src/qpid/messaging/ConnectionOptions.h c8c8798 
>   src/qpid/messaging/ConnectionOptions.cpp d956e9a 
>   src/qpid/messaging/amqp/ConnectionContext.cpp 25dd68d 
>   src/qpid/messaging/amqp/EncodedMessage.cpp cf60046 
>   src/qpid/messaging/amqp/SenderContext.h 467a8e0 
>   src/qpid/messaging/amqp/SenderContext.cpp fe8b4d3 
>   src/qpid/messaging/amqp/SessionContext.h 67b3c1e 
>   src/qpid/messaging/amqp/SessionContext.cpp 92bdea7 
>   src/qpid/messaging/amqp/Transaction.cpp 754b00d 
> 
> Diff: https://reviews.apache.org/r/51638/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Gordon Sim
> 
>

Reply via email to