OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

amqp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [amqp] Correct behavior for link source with filters applied?

Priority actually is an odd example for the filter here, because doesnât that rush the message to the top of the queue anyways?


From: Robbie Gemmell <rgemmell@redhat.com>
Sent: Thursday, February 21, 2019 5:55 PM
To: Clemens Vasters <clemensv@microsoft.com>
Cc: amqp@lists.oasis-open.org
Subject: Re: [amqp] Correct behavior for link source with filters applied?




On Thu, Feb 21, 2019 at 4:50 PM Robbie Gemmell <rgemmell@redhat.com> wrote:

I guess it is silent here because the spec itself doesn't define the source (not link) filters or the node behaviour (or implementation), all of which would play into a particular overall behaviour.


This is behaviour exactly how I would expect it to, and how JMS generally expects (and tests) it should. The consumer has a filter indicating it doesn't want some messages, and it asks for messages, so it gets sent those which do match what it wants. The notion of a 'turn' is seeming like node implementation detail to me, and not something the spec would speak to. In general I wouldn't expect such a consumer to block for it to be at the head of the queue, unless it was a very specific defined behaviour of that node. It otherwise feels like more general behaviour that people might request via message groups etc to achieve some control over ordering etc.


(In this particular referenced example, it would also be unexpected to me that it would ever wait for the lower priority message to be consumed when it is specifically asking for higher priority ones, as doing so would to some extent then also defeat the point of setting priority).




JMS expectation is that you get sent messages


Ah, the dreaded 'wrote that bit elsewhere eventually, but missed out deleting original snippet'. Oops :)


On Thu, Feb 21, 2019 at 3:23 PM Clemens Vasters <clemensv@microsoft.com> wrote:

The core spec is silent on what the expected behavior is for links with applied filters.


Iâm looking at wire traces of Qpid JMS interacting with ActiveMQ during the Qpid JMS tests and there specifically at this here:




The runtime behavior with the queue appears to be that ActiveMQ instantly skips messages that donât match the given filter and doesnât block on a message thatâs ahead of messages matching the filter.


Doesnât that imply that the filter is used as a feature of the backend rather than of the link, i.e. the queue acting like a topic rather than a queue?


For a queue, I would expect that competing consumers become eligible for getting a message when it is their turn, and then thereâs a decision for whether that message is indeed transferred based on the filter and otherwise that consumer yields its turn. In this particular test, the queue should therefore block.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]