You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Robbie Gemmell (JIRA)" <ji...@apache.org> on 2017/04/17 15:31:41 UTC

[jira] [Commented] (AMQ-6657) ActiveMQ does not respect sender and receiver link settle mode

    [ https://issues.apache.org/jira/browse/AMQ-6657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15971149#comment-15971149 ] 

Robbie Gemmell commented on AMQ-6657:
-------------------------------------

Your logs actually show the broker setting the sender-settle-mode to 'mixed', and not 'settled' as you mentioned. This is an entirely legal thing for the broker to do, essentially saying each message transfers settled value will define behaviour, though admittedly could be unexpected if the client requested something more specific.

From your mailing list post, you said:
{quote}
It is not clear, how to achieve message acceptance on client.

Following OASIS AMQP1.0 docs, I assume that I have to setup
sender-settle-mode - unsettled (0)
receiver-settle-mode - second (1)
in order to use accept/modify/reject methods, but it does not work as expected. 
{quote}

To allow the client to accept messages you'd need sender-settle-mode of 'unsettled' or 'mixed' (where messages are actually sent unsettled in the latter case), and 'first' or 'second' receiver receiver-settle-modes, i.e. what you are getting allows accepting messages. Using 'second' for the receiver-settle-mode is only needed for the 'two-ack' exactly-once delivery process, which ActiveMQ doesn't currently support, only at-least-once or at-most-once, hence the broker is properly indicating what it is actually supporting/doing by setting 'first'.

{quote}
It shows that despite the fact that there's no consumer connected to the queue I receive 'settled=true state=accepted' for the message sent
{quote}
As you should have: you sent the message to a queue, unsettled, and the broker put it in the queue and then accepted+settled the message, i.e. it got queued as you asked.

In this case I think its all actually doing exactly what you've said you want, until the point you try to 'modify' the message to indicate 'undeliverable-here' (but oddly, not delivery-failed). The ActiveMQ 5 broker currently takes that as a reason to DLQ the message, as you noticed, meaning it wont be available to another consumer except via the DLQ.

> ActiveMQ does not respect sender and receiver link settle mode
> --------------------------------------------------------------
>
>                 Key: AMQ-6657
>                 URL: https://issues.apache.org/jira/browse/AMQ-6657
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.14.4
>            Reporter: Ilya Lebedev
>
> Here is the long story
> http://activemq.2283324.n4.nabble.com/How-to-setup-policy-for-client-side-message-acceptance-td4724961.html
> Use case
> # setup policy for
> #* sender setter mode 'unsettled'
> #* receiver settle mode 'second'
> # connect to brocker
> Expected result
> * broker respects requested policy
> Actual result
> * broker resets
> ** sender settle mode - 'settle'
> ** receiver settle mode - 'first'
> Log
> {code}
>   amqp10:framing sending frame:  @attach(18) [name='test_d5c61642-99b0-4315-bef5-7bffdf0f8d64' handle=0 role=false senderSettleMode=0 receiverSettleMode=1 source=@source(40) [address='localhost' durable=0 expiryPolicy='session-end' timeout=0 dynamic=false dynamicNodeProperties={} distributionMode=null filter={} defaultOutcome=null outcomes=null capabilities=null] target=@target(41) [address='test' durable=0 expiryPolicy='session-end' timeout=0 dynamic=false dynamicNodeProperties={} capabilities=null] unsettled={} incompleteUnsettled=false initialDeliveryCount=1 maxMessageSize=0 offeredCapabilities=null desiredCapabilities=null properties={}] +1ms
>   amqp10:trace raw: [0000009602000001005312c0890ea129746573745f64356336313634322d393962302d343331352d626566352d376266666466306638643634434250005001005328c0260ba1096c6f63616c686f737443a30b73657373696f6e2d656e644342c1010040c10100404040005329c01b07a1047465737443a30b73657373696f6e2d656e644342c1010040c10100425201444040c10100] +0ms
>   amqp10:connection Rx: 0000008602000000005312c07907a129746573745f64356336313634322d393962302d343331352d626566352d376266666466306638643634434150025000005328c02308a1096c6f63616c686f737443a30b73657373696f6e2d656e644342c1010040c10100005329c01a06a1047465737443a30b73657373696f6e2d656e644342c101000000002402000000005313c017075201707fffffff5201707fffffff43520170000003e8 +1ms
>   amqp10:framing received frame:  @attach(18) [name='test_d5c61642-99b0-4315-bef5-7bffdf0f8d64' handle=0 role=true senderSettleMode=2 receiverSettleMode=0 source=@source(40) [address='localhost' durable=0 expiryPolicy='session-end' timeout=0 dynamic=false dynamicNodeProperties={} distributionMode=null filter={} defaultOutcome=null outcomes=null capabilities=null] target=@target(41) [address='test' durable=0 expiryPolicy='session-end' timeout=0 dynamic=false dynamicNodeProperties={} capabilities=null] unsettled={} incompleteUnsettled=false initialDeliveryCount=null maxMessageSize=0 offeredCapabilities=null desiredCapabilities=null properties={}] +2ms 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)