You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Robbie Gemmell <ro...@gmail.com> on 2019/11/01 12:16:16 UTC
Re: multicast without consumers
On Thu, 31 Oct 2019 at 17:31, Ted Ross <tr...@redhat.com> wrote:
>
> On Thu, Oct 31, 2019 at 6:57 AM Robbie Gemmell <ro...@gmail.com>
> wrote:
>
> > With the below, are you saying that previously the router would always
> > immediately accept an unsettled message sent to a multicast address,
> > and then either send it on (pre-settled) or drop it if there was
> > nowhere to direct it
>
>
> Yes.
>
>
> > ....but in the latter case, now it would release
> > it instead?
>
>
> Yes.
>
>
> > If so, is it possible to configure the old behaviour, for
> > folks that actually wanted that?
> >
>
> Perhaps. Does anyone want it? It _would_ prevent the looping behavior.
>
Who knows, did we ask? I dont think it is at all out of the realms of
possibility that some do, especially given it is essentially how a
brokered topic might often work, and how dispatch behaved until now.
My main point is jsut that it was a fairly large change in behaviour
given it worked the way it had for some time deliberately (as opposed
to some bug), and now all of a sudden it isnt possible to get that
behaviour at all. I dont think its a very nice change to have made in
a minor release without providing any option to keep things working as
they had. As suggested, sending pre-settled is the closest equivalent
now (though not quite identical), but that unfortunately may require
updating all your senders too.
>
> >
> > Or does it still accept in that case and you just meant that the end
> > receiver outcomes are now interpreted to decide the response to the
> > sender? What if the different multicast points return different
> > outcomes?
>
>
> If there are different dispositions, there is a priority list that
> determines which of the provided dispositions will be returned to the
> sender.
>
>
> > What if one recipient doesnt provide an outcome for ages?
>
>
> Then that delivery will not be settled for ages.
>
>
> > Or
> > goes away without providing one?
> >
>
> Then the outcome from that recipient will be MODIFIED at the time the
> receiver detaches.
>
>
> >
> > Or maybe it was both of the above? :)
> >
> > In some ways either of these seem like odd changes for a minor release
> > unless its possible to toggle the previous long standing behaviour,
> > and not say have to switch all your senders to pre-settled to mimmick
> > but still not quite match it (since at least with the unsettled case
> > before, youd at least know whether a [first, if multiple hops] router
> > processed the message at all).
> >
> > Robbie
> >
> > On Wed, 30 Oct 2019 at 13:54, Ken Giusti <kg...@redhat.com> wrote:
> > >
> > > On Tue, Oct 29, 2019 at 6:23 PM VERMEULEN Olivier <
> > > Olivier.VERMEULEN@murex.com> wrote:
> > >
> > > > Hello,
> > > >
> > > > Yes the waypoint address (in from broker) is using a multicast
> > > > distribution.
> > > > Unfortunately skipping the broker is not an option for us right now.
> > > > Our whole architecture relies on the broker to guarantee that no
> > messages
> > > > will ever be lost...
> > > >
> > >
> > > That won't be the case for multicast actually. Prior to release 1.9.0 of
> > > the router multicast messages would be dropped without notification when
> > > under load.
> > >
> > > This relates to the issue you're experiencing now I believe. In 1.9.0 we
> > > fixed this via
> > >
> > > https://issues.apache.org/jira/browse/DISPATCH-1266
> > >
> > > Previously multicast messages were marked a pre-settled on entry to the
> > > router and an "accepted" status was returned to the sender _before_ the
> > > multicast was forwarded at all. Since the message was marked pre-settled
> > > the router mesh will be more likely to drop it should congestion occur.
> > > (Note this not the case with unsettled anycast messages - the router will
> > > send a "release" status should the message need be discarded).
> > >
> > > This auto-settle behavior was undesirable for a number of reasons as you
> > > can imagine, so in 1.9.0 we changed the behavior of multicast deliveries:
> > >
> > > *unsettled* messages sent to multicast addresses are no longer
> > pre-settled
> > > by the router. The router will send back the final acknowledgement
> > > (accepted, release, etc) once all *present* subscribers for the multicast
> > > address return acknowledgements.
> > >
> > > The behavior of pre-settled multicast did not change.
> > >
> > > So you can probably restore the original behavior by reverted back to a
> > > pre-1.9.0 release, however be aware that even then there's no guarantee
> > the
> > > message will be dropped. In fact it's _more_ likely to be dropped (and
> > > signalled as accepted) in pre-1.9.0 releases.
> > >
> > >
> > >
> > > > For information we're asking for a quick workaround because we're
> > facing
> > > > this problem on a client production environment...
> > > >
> > > > Thanks,
> > > > Olivier
> > > >
> > > > -----Original Message-----
> > > > From: Ken Giusti <kg...@redhat.com>
> > > > Sent: mardi 29 octobre 2019 18:07
> > > > To: users <us...@qpid.apache.org>
> > > > Subject: Re: multicast without consumers
> > > >
> > > > On Tue, Oct 29, 2019 at 11:54 AM jeremy <je...@gmail.com> wrote:
> > > >
> > > > > Hello Gordon,
> > > > >
> > > > > We debugged the dispatch router, and fell on the code which releases
> > > > > undeliverable messages(
> > > > >
> > https://github.com/apache/qpid-dispatch/blob/1.5.0/src/router_core/tra
> > > > > nsfer.c#L869
> > > > > ).
> > > > >
> > > > > Check the comment on line 879. It states that if the distribution is
> > > > > multicast, the credit will be replenished after the release. The
> > issue
> > > > > that introduced this behavior is:
> > > > > https://issues.apache.org/jira/browse/DISPATCH-1012
> > > > >
> > > > >
> > > > Is the waypoint address (in from broker) using multicast distribution?
> > > >
> > > > The router treats multicast addresses like topics - you can publish to
> > a
> > > > multicast address (topic) regardless of the presence of consumers.
> > That's
> > > > the reason credit is being replenished even when no consumers are
> > present.
> > > >
> > > > That's probably what's happening here - broker sends first queued
> > message
> > > > to the router, which attempts to send it to the topic. Since there
> > are no
> > > > consumers (and the message is sent from the broker as unsettled) the
> > > > router cannot deliver it so it returns the released status. The
> > released
> > > > status causes the broker to redeliver the message. Repeat.
> > > >
> > > >
> > > >
> > > >
> > > > > In fact, we need an urgent fix/workaround for this. Perhaps there is
> > a
> > > > > quick workaround, awaiting the full analysis of this problem?
> > > > >
> > > > >
> > > > As a work around can you avoid sending these multicast messages to the
> > > > broker queue? In other words send them directly to the router instead
> > of
> > > > using a waypoint?
> > > >
> > > >
> > > >
> > > > > Thanks
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > -----
> > > > > Cheers,
> > > > > Jeremy
> > > > > --
> > > > > Sent from:
> > > > > http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For
> > > > > additional commands, e-mail: users-help@qpid.apache.org
> > > > >
> > > > >
> > > >
> > > > --
> > > > -K
> > > > *******************************
> > > > This e-mail contains information for the intended recipient only. It
> > may
> > > > contain proprietary material or confidential information. If you are
> > not
> > > > the intended recipient you are not authorized to distribute, copy or
> > use
> > > > this e-mail or any attachment to it. Murex cannot guarantee that it is
> > > > virus free and accepts no responsibility for any loss or damage arising
> > > > from its use. If you have received this e-mail in error please notify
> > > > immediately the sender and delete the original email received, any
> > > > attachments and all copies from your system.
> > > >
> > >
> > >
> > > --
> > > -K
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: multicast without consumers
Posted by Chuck Rolke <cr...@redhat.com>.
----- Original Message -----
> From: "Gordon Sim" <gs...@redhat.com>
> To: users@qpid.apache.org
> Sent: Thursday, November 7, 2019 10:00:47 AM
> Subject: Re: multicast without consumers
>
> On 07/11/2019 2:58 pm, Chuck Rolke wrote:
> > When vhost policy is in force then there is a problem problem with
> > forcing users to use anonymous links in order to send when there are
> > no consumers. The 'allowAnonymousSenders' policy setting then allows
> > the sender to send to*any* address, which is not always desirable.
>
> That should not be the case since
> https://issues.apache.org/jira/browse/DISPATCH-1273
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Correct! Sorry for the misinterpretation. That fix improves control
of anonymous links.
The final description of "how it works" still needs to include the
sender settlement mode.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: multicast without consumers
Posted by Gordon Sim <gs...@redhat.com>.
On 07/11/2019 2:58 pm, Chuck Rolke wrote:
> When vhost policy is in force then there is a problem problem with
> forcing users to use anonymous links in order to send when there are
> no consumers. The 'allowAnonymousSenders' policy setting then allows
> the sender to send to*any* address, which is not always desirable.
That should not be the case since
https://issues.apache.org/jira/browse/DISPATCH-1273
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: multicast without consumers
Posted by Ken Giusti <kg...@redhat.com>.
On Tue, Nov 12, 2019 at 6:55 AM Robbie Gemmell <ro...@gmail.com>
wrote:
> I dont recall any mention of that element changing, so its presumably
> whatever 1.9.0 does currently? Thats documented at:
>
> http://qpid.apache.org/releases/qpid-dispatch-1.9.0/user-guide/index.html#message_settlement_and_reliability
>
>
Thanks Robbie - that is the correct documentation and applies to router
1.9.0+ multicast.
The AMQP 1.0 standard does not provide any guidance regarding multicast.
As far as I'm aware, the concept of a multicast/broadcast messaging pattern
is not defined at all by the core 1.0 spec. Which means that there's no
recommended course of action given multiple different terminal outcomes
arriving for a single multicast transmit. This means the router has to
establish a behavior that "makes sense" when a publisher to a multicast
address wants an explicit terminal outcome.
From the standard the terminal outcome signals to the sender the status of
the message delivery at the consumer. The outcomes can signal whether the
receiver accepted the message, rejected it due to error, release it for
re-delivery, etc. In the case of multiple different returned terminal
outcomes (possible with multicast), the router has implemented a priority
scheme for determining the "best" single outcome to return to the sender.
This is the priority scheme used by the router as implemented in
DISPATCH-1266 <https://issues.apache.org/jira/browse/DISPATCH-1266> in
1.9.0+:
REJECTED: since REJECTED is a hard error (the message is unprocessable) it
is considered a failure and should not be filtered out as this could cause
important issues to be hidden. Therefore it is the highest priority and
will be returned to the sender regardless of other non-REJECTED outcomes.
If the sender receives a REJECTED outcome it can assume: 1) at least one
consumer received the message, and 2) the message is in error.
ACCEPTED: if no receivers REJECT the message, the next highest priority is
ACCEPTED. If the sender receives an ACCEPTED outcome it can assume that at
least one consumer has received the message.
MODIFIED: if no receivers REJECT or ACCEPT the message, but one or more
forwarding failures occur and the message delivery is in doubt the router
will return MODIFIED. If the sender receives a MODIFIED outcome that
indicates that the router is unable to determine whether or not the message
was forwarded to at least one consumer (e.g. connection drop occurs before
outcome is known).
RELEASED: lowest priority - if the sender receives a RELEASED outcome it
can be guaranteed that the message was not delivered to any consumer (and
may be safely re-sent without fear of duplication).
This behavior is as consistent as possible with the terminal outcome for
anycast links.
> I've raised https://issues.apache.org/jira/browse/DISPATCH-1479 for
> some related doc improvement suggestions in that area.
>
>
> Robbie
>
> On Tue, 12 Nov 2019 at 08:22, VERMEULEN Olivier
> <Ol...@murex.com> wrote:
> >
> > Hello,
> >
> > Regarding the multicast , what will be the behavior in 1.10.0 if all
> *present* subscribers do not return the same acknowledgment?
> >
> > Thanks,
> > Olivier
> >
> > -----Original Message-----
> > From: Ken Giusti <kg...@redhat.com>
> > Sent: jeudi 7 novembre 2019 17:11
> > To: users <us...@qpid.apache.org>
> > Subject: Re: multicast without consumers
> >
> > On Thu, Nov 7, 2019 at 9:58 AM Chuck Rolke <cr...@redhat.com> wrote:
> >
> > > > 1) All non-anonymous producer links will only be granted credit when
> > > > the router is aware of at least one consumer. This applies to all
> > > > of the address treatments uniformly (multicast, anycast, balanced,
> > > > closest, ...)
> > > >
> > > > 2) Declare the fix to DISPATCH-779 invalid and change the JIRA's
> > > > state to not-a-bug with the comment explaining the need to use
> > > > anonymous links for that use case.
> > > >
> > >
> > > When vhost policy is in force then there is a problem problem with
> > > forcing users to use anonymous links in order to send when there are
> > > no consumers. The 'allowAnonymousSenders' policy setting then allows
> > > the sender to send to *any* address, which is not always desirable.
> > >
> > > This discussion *also* needs to include the link's settlement-mode to
> > > describe router behavior for senders using links with a named or
> > > unnamed (anonymous) target. The send settlement modes are:
> > > SND_SETTLED, SND_MIXED, and SND_UNSETTLED.
> > >
> > > As I understand it:
> > > * A sender link in SND_MIXED or SND_UNSETTLED modes will behave as
> > > Option 1.
> > >
> >
> > Agreed.
> >
> > > * A sender link in SND_SETTLED mode will behave
> > > differently: senders receive credit immediately regardless of consumer
> > > presence; messages are settled and credit is restored at the router's
> > > receiver so that the sender can send as fast as possible and it looks
> > > to the sender like all messages were accepted; messages are forwarded
> > > to receivers pre-settled; messages may be dropped aggressively due to
> > > congestion. This is like a 'broadcast-best-effort' treatment.
> > >
> > >
> > That's not my observations (against master and as far back as 1.8.0).
> When I attach a sender with snd-settle-mode=1 (send all presetted), no flow
> is granted to the sender when there are no consumers present.
> >
> >
> >
> >
> > > Clients can choose the behavior they want by combining the link
> > > send-settle mode (settled, mixed, unsettled) and the sender link
> > > target (named link target or anonymous blank link target). Maybe a
> > > table or two showing how the router treats message settlement, initial
> > > credit grant, and per-message credit restoration both with and without
> > > policy restrictions would be in order.
> > >
> > > That said, I agree with option 1. Option 2 might be satisfied with
> > > documents that have the suggested table showing message treatments.
> > > Option 3 is less of an issue with 1.10 coming soon.
> > >
> > > > 3) Declare 1.9.0 to be Broken and backport the proposed fix and
> > > > release
> > > > 1.9.1
> > > >
> > > > Let me know what you all think - I'm assuming silence is tacit
> > > > approval
> > > of
> > > > this proposal ;)
> > > >
> > > > On Tue, Nov 5, 2019 at 9:29 AM Gordon Sim <gs...@redhat.com> wrote:
> > > >
> > > > > On 05/11/2019 11:31 am, Robbie Gemmell wrote:
> > > > > > I think always-accepting would be fairly consistent multicast /
> > > > > > topic like behaviour that neednt imply any consumer delivery
> > > > > > guarantee, the same way it doesnt for brokered cases, with it
> > > > > > only meaning that a router saw the message, particularly if
> covered by the documentation.
> > > > >
> > > > > I think the brokered case is different as it involves a
> > > > > store-and-forward semantic. The producer always cares only that
> > > > > the broker it sent it to got it. The forwarding of the message is
> > > > > always decoupled from that and so the state of consumers is
> > > > > irrelevant to the acknowledgement for both queues and topics.
> > > > >
> > > > > The router provides an end-to-end acknowledgement rather than
> > > > > store-and-forward. Though the limitations of the outcomes defined
> > > > > in
> > > the
> > > > > AMQP specification prevent the fullest expression of that, Ken's
> > > > > work allows what is in my view a more internally consistent
> approach.
> > > > >
> > > > > Reject always means that a receiver rejected it. Accept always
> > > > > means that a receiver accepted it, and it was not rejected.
> > > > > Release always means that either the message could not be routed
> > > > > to any receiver or that any receiver to which it was routed
> explicitly released it.
> > > > > Modified means it was routed to at least one receiver which either
> > > > > explicitly issued the modified outcome or was disconnected before
> > > > > it returned any explicit outcome.
> > > > >
> > > > > (Maybe in the future we could even have a custom outcome, support
> > > > > for which could be advertised in the connection or link
> > > > > capabilities, that allowed an explicit aggregation of the outcomes
> > > > > from each distinct receiver to which the message was routed to be
> > > > > included)
> > > > >
> > > > >
> > > > > ------------------------------------------------------------------
> > > > > --- To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For
> > > > > additional commands, e-mail: users-help@qpid.apache.org
> > > > >
> > > > >
> > > >
> > > > --
> > > > -K
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For
> > > additional commands, e-mail: users-help@qpid.apache.org
> > >
> > >
> >
> > --
> > -K
> > *******************************
> > This e-mail contains information for the intended recipient only. It may
> contain proprietary material or confidential information. If you are not
> the intended recipient you are not authorized to distribute, copy or use
> this e-mail or any attachment to it. Murex cannot guarantee that it is
> virus free and accepts no responsibility for any loss or damage arising
> from its use. If you have received this e-mail in error please notify
> immediately the sender and delete the original email received, any
> attachments and all copies from your system.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
--
-K
Re: multicast without consumers
Posted by Robbie Gemmell <ro...@gmail.com>.
I dont recall any mention of that element changing, so its presumably
whatever 1.9.0 does currently? Thats documented at:
http://qpid.apache.org/releases/qpid-dispatch-1.9.0/user-guide/index.html#message_settlement_and_reliability
I've raised https://issues.apache.org/jira/browse/DISPATCH-1479 for
some related doc improvement suggestions in that area.
Robbie
On Tue, 12 Nov 2019 at 08:22, VERMEULEN Olivier
<Ol...@murex.com> wrote:
>
> Hello,
>
> Regarding the multicast , what will be the behavior in 1.10.0 if all *present* subscribers do not return the same acknowledgment?
>
> Thanks,
> Olivier
>
> -----Original Message-----
> From: Ken Giusti <kg...@redhat.com>
> Sent: jeudi 7 novembre 2019 17:11
> To: users <us...@qpid.apache.org>
> Subject: Re: multicast without consumers
>
> On Thu, Nov 7, 2019 at 9:58 AM Chuck Rolke <cr...@redhat.com> wrote:
>
> > > 1) All non-anonymous producer links will only be granted credit when
> > > the router is aware of at least one consumer. This applies to all
> > > of the address treatments uniformly (multicast, anycast, balanced,
> > > closest, ...)
> > >
> > > 2) Declare the fix to DISPATCH-779 invalid and change the JIRA's
> > > state to not-a-bug with the comment explaining the need to use
> > > anonymous links for that use case.
> > >
> >
> > When vhost policy is in force then there is a problem problem with
> > forcing users to use anonymous links in order to send when there are
> > no consumers. The 'allowAnonymousSenders' policy setting then allows
> > the sender to send to *any* address, which is not always desirable.
> >
> > This discussion *also* needs to include the link's settlement-mode to
> > describe router behavior for senders using links with a named or
> > unnamed (anonymous) target. The send settlement modes are:
> > SND_SETTLED, SND_MIXED, and SND_UNSETTLED.
> >
> > As I understand it:
> > * A sender link in SND_MIXED or SND_UNSETTLED modes will behave as
> > Option 1.
> >
>
> Agreed.
>
> > * A sender link in SND_SETTLED mode will behave
> > differently: senders receive credit immediately regardless of consumer
> > presence; messages are settled and credit is restored at the router's
> > receiver so that the sender can send as fast as possible and it looks
> > to the sender like all messages were accepted; messages are forwarded
> > to receivers pre-settled; messages may be dropped aggressively due to
> > congestion. This is like a 'broadcast-best-effort' treatment.
> >
> >
> That's not my observations (against master and as far back as 1.8.0). When I attach a sender with snd-settle-mode=1 (send all presetted), no flow is granted to the sender when there are no consumers present.
>
>
>
>
> > Clients can choose the behavior they want by combining the link
> > send-settle mode (settled, mixed, unsettled) and the sender link
> > target (named link target or anonymous blank link target). Maybe a
> > table or two showing how the router treats message settlement, initial
> > credit grant, and per-message credit restoration both with and without
> > policy restrictions would be in order.
> >
> > That said, I agree with option 1. Option 2 might be satisfied with
> > documents that have the suggested table showing message treatments.
> > Option 3 is less of an issue with 1.10 coming soon.
> >
> > > 3) Declare 1.9.0 to be Broken and backport the proposed fix and
> > > release
> > > 1.9.1
> > >
> > > Let me know what you all think - I'm assuming silence is tacit
> > > approval
> > of
> > > this proposal ;)
> > >
> > > On Tue, Nov 5, 2019 at 9:29 AM Gordon Sim <gs...@redhat.com> wrote:
> > >
> > > > On 05/11/2019 11:31 am, Robbie Gemmell wrote:
> > > > > I think always-accepting would be fairly consistent multicast /
> > > > > topic like behaviour that neednt imply any consumer delivery
> > > > > guarantee, the same way it doesnt for brokered cases, with it
> > > > > only meaning that a router saw the message, particularly if covered by the documentation.
> > > >
> > > > I think the brokered case is different as it involves a
> > > > store-and-forward semantic. The producer always cares only that
> > > > the broker it sent it to got it. The forwarding of the message is
> > > > always decoupled from that and so the state of consumers is
> > > > irrelevant to the acknowledgement for both queues and topics.
> > > >
> > > > The router provides an end-to-end acknowledgement rather than
> > > > store-and-forward. Though the limitations of the outcomes defined
> > > > in
> > the
> > > > AMQP specification prevent the fullest expression of that, Ken's
> > > > work allows what is in my view a more internally consistent approach.
> > > >
> > > > Reject always means that a receiver rejected it. Accept always
> > > > means that a receiver accepted it, and it was not rejected.
> > > > Release always means that either the message could not be routed
> > > > to any receiver or that any receiver to which it was routed explicitly released it.
> > > > Modified means it was routed to at least one receiver which either
> > > > explicitly issued the modified outcome or was disconnected before
> > > > it returned any explicit outcome.
> > > >
> > > > (Maybe in the future we could even have a custom outcome, support
> > > > for which could be advertised in the connection or link
> > > > capabilities, that allowed an explicit aggregation of the outcomes
> > > > from each distinct receiver to which the message was routed to be
> > > > included)
> > > >
> > > >
> > > > ------------------------------------------------------------------
> > > > --- To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For
> > > > additional commands, e-mail: users-help@qpid.apache.org
> > > >
> > > >
> > >
> > > --
> > > -K
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For
> > additional commands, e-mail: users-help@qpid.apache.org
> >
> >
>
> --
> -K
> *******************************
> This e-mail contains information for the intended recipient only. It may contain proprietary material or confidential information. If you are not the intended recipient you are not authorized to distribute, copy or use this e-mail or any attachment to it. Murex cannot guarantee that it is virus free and accepts no responsibility for any loss or damage arising from its use. If you have received this e-mail in error please notify immediately the sender and delete the original email received, any attachments and all copies from your system.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
RE: multicast without consumers
Posted by VERMEULEN Olivier <Ol...@murex.com>.
Hello,
Regarding the multicast , what will be the behavior in 1.10.0 if all *present* subscribers do not return the same acknowledgment?
Thanks,
Olivier
-----Original Message-----
From: Ken Giusti <kg...@redhat.com>
Sent: jeudi 7 novembre 2019 17:11
To: users <us...@qpid.apache.org>
Subject: Re: multicast without consumers
On Thu, Nov 7, 2019 at 9:58 AM Chuck Rolke <cr...@redhat.com> wrote:
> > 1) All non-anonymous producer links will only be granted credit when
> > the router is aware of at least one consumer. This applies to all
> > of the address treatments uniformly (multicast, anycast, balanced,
> > closest, ...)
> >
> > 2) Declare the fix to DISPATCH-779 invalid and change the JIRA's
> > state to not-a-bug with the comment explaining the need to use
> > anonymous links for that use case.
> >
>
> When vhost policy is in force then there is a problem problem with
> forcing users to use anonymous links in order to send when there are
> no consumers. The 'allowAnonymousSenders' policy setting then allows
> the sender to send to *any* address, which is not always desirable.
>
> This discussion *also* needs to include the link's settlement-mode to
> describe router behavior for senders using links with a named or
> unnamed (anonymous) target. The send settlement modes are:
> SND_SETTLED, SND_MIXED, and SND_UNSETTLED.
>
> As I understand it:
> * A sender link in SND_MIXED or SND_UNSETTLED modes will behave as
> Option 1.
>
Agreed.
> * A sender link in SND_SETTLED mode will behave
> differently: senders receive credit immediately regardless of consumer
> presence; messages are settled and credit is restored at the router's
> receiver so that the sender can send as fast as possible and it looks
> to the sender like all messages were accepted; messages are forwarded
> to receivers pre-settled; messages may be dropped aggressively due to
> congestion. This is like a 'broadcast-best-effort' treatment.
>
>
That's not my observations (against master and as far back as 1.8.0). When I attach a sender with snd-settle-mode=1 (send all presetted), no flow is granted to the sender when there are no consumers present.
> Clients can choose the behavior they want by combining the link
> send-settle mode (settled, mixed, unsettled) and the sender link
> target (named link target or anonymous blank link target). Maybe a
> table or two showing how the router treats message settlement, initial
> credit grant, and per-message credit restoration both with and without
> policy restrictions would be in order.
>
> That said, I agree with option 1. Option 2 might be satisfied with
> documents that have the suggested table showing message treatments.
> Option 3 is less of an issue with 1.10 coming soon.
>
> > 3) Declare 1.9.0 to be Broken and backport the proposed fix and
> > release
> > 1.9.1
> >
> > Let me know what you all think - I'm assuming silence is tacit
> > approval
> of
> > this proposal ;)
> >
> > On Tue, Nov 5, 2019 at 9:29 AM Gordon Sim <gs...@redhat.com> wrote:
> >
> > > On 05/11/2019 11:31 am, Robbie Gemmell wrote:
> > > > I think always-accepting would be fairly consistent multicast /
> > > > topic like behaviour that neednt imply any consumer delivery
> > > > guarantee, the same way it doesnt for brokered cases, with it
> > > > only meaning that a router saw the message, particularly if covered by the documentation.
> > >
> > > I think the brokered case is different as it involves a
> > > store-and-forward semantic. The producer always cares only that
> > > the broker it sent it to got it. The forwarding of the message is
> > > always decoupled from that and so the state of consumers is
> > > irrelevant to the acknowledgement for both queues and topics.
> > >
> > > The router provides an end-to-end acknowledgement rather than
> > > store-and-forward. Though the limitations of the outcomes defined
> > > in
> the
> > > AMQP specification prevent the fullest expression of that, Ken's
> > > work allows what is in my view a more internally consistent approach.
> > >
> > > Reject always means that a receiver rejected it. Accept always
> > > means that a receiver accepted it, and it was not rejected.
> > > Release always means that either the message could not be routed
> > > to any receiver or that any receiver to which it was routed explicitly released it.
> > > Modified means it was routed to at least one receiver which either
> > > explicitly issued the modified outcome or was disconnected before
> > > it returned any explicit outcome.
> > >
> > > (Maybe in the future we could even have a custom outcome, support
> > > for which could be advertised in the connection or link
> > > capabilities, that allowed an explicit aggregation of the outcomes
> > > from each distinct receiver to which the message was routed to be
> > > included)
> > >
> > >
> > > ------------------------------------------------------------------
> > > --- To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For
> > > additional commands, e-mail: users-help@qpid.apache.org
> > >
> > >
> >
> > --
> > -K
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For
> additional commands, e-mail: users-help@qpid.apache.org
>
>
--
-K
*******************************
This e-mail contains information for the intended recipient only. It may contain proprietary material or confidential information. If you are not the intended recipient you are not authorized to distribute, copy or use this e-mail or any attachment to it. Murex cannot guarantee that it is virus free and accepts no responsibility for any loss or damage arising from its use. If you have received this e-mail in error please notify immediately the sender and delete the original email received, any attachments and all copies from your system.
Re: multicast without consumers
Posted by Ken Giusti <kg...@redhat.com>.
On Thu, Nov 7, 2019 at 9:58 AM Chuck Rolke <cr...@redhat.com> wrote:
> > 1) All non-anonymous producer links will only be granted credit when the
> > router is aware of at least one consumer. This applies to all of the
> > address treatments uniformly (multicast, anycast, balanced, closest, ...)
> >
> > 2) Declare the fix to DISPATCH-779 invalid and change the JIRA's state to
> > not-a-bug with the comment explaining the need to use anonymous links for
> > that use case.
> >
>
> When vhost policy is in force then there is a problem problem with
> forcing users to use anonymous links in order to send when there are
> no consumers. The 'allowAnonymousSenders' policy setting then allows
> the sender to send to *any* address, which is not always desirable.
>
> This discussion *also* needs to include the link's settlement-mode
> to describe router behavior for senders using links with a named
> or unnamed (anonymous) target. The send settlement modes are:
> SND_SETTLED, SND_MIXED, and SND_UNSETTLED.
>
> As I understand it:
> * A sender link in SND_MIXED or SND_UNSETTLED modes will
> behave as Option 1.
>
Agreed.
> * A sender link in SND_SETTLED mode will behave
> differently: senders receive credit immediately regardless of
> consumer presence; messages are settled and credit is restored at the
> router's receiver so that the sender can send as fast as possible and
> it looks to the sender like all messages were accepted; messages are
> forwarded to receivers pre-settled; messages may be dropped aggressively
> due to congestion. This is like a 'broadcast-best-effort' treatment.
>
>
That's not my observations (against master and as far back as 1.8.0). When
I attach a sender with snd-settle-mode=1 (send all presetted), no flow is
granted to the sender when there are no consumers present.
> Clients can choose the behavior they want by combining the link send-settle
> mode (settled, mixed, unsettled) and the sender link target (named link
> target or anonymous blank link target). Maybe a table or two showing how
> the router treats message settlement, initial credit grant, and per-message
> credit restoration both with and without policy restrictions would be
> in order.
>
> That said, I agree with option 1. Option 2 might be satisfied with
> documents that have the suggested table showing message treatments.
> Option 3 is less of an issue with 1.10 coming soon.
>
> > 3) Declare 1.9.0 to be Broken and backport the proposed fix and release
> > 1.9.1
> >
> > Let me know what you all think - I'm assuming silence is tacit approval
> of
> > this proposal ;)
> >
> > On Tue, Nov 5, 2019 at 9:29 AM Gordon Sim <gs...@redhat.com> wrote:
> >
> > > On 05/11/2019 11:31 am, Robbie Gemmell wrote:
> > > > I think always-accepting would be fairly consistent multicast / topic
> > > > like behaviour that neednt imply any consumer delivery guarantee, the
> > > > same way it doesnt for brokered cases, with it only meaning that a
> > > > router saw the message, particularly if covered by the documentation.
> > >
> > > I think the brokered case is different as it involves a
> > > store-and-forward semantic. The producer always cares only that the
> > > broker it sent it to got it. The forwarding of the message is always
> > > decoupled from that and so the state of consumers is irrelevant to the
> > > acknowledgement for both queues and topics.
> > >
> > > The router provides an end-to-end acknowledgement rather than
> > > store-and-forward. Though the limitations of the outcomes defined in
> the
> > > AMQP specification prevent the fullest expression of that, Ken's work
> > > allows what is in my view a more internally consistent approach.
> > >
> > > Reject always means that a receiver rejected it. Accept always means
> > > that a receiver accepted it, and it was not rejected. Release always
> > > means that either the message could not be routed to any receiver or
> > > that any receiver to which it was routed explicitly released it.
> > > Modified means it was routed to at least one receiver which either
> > > explicitly issued the modified outcome or was disconnected before it
> > > returned any explicit outcome.
> > >
> > > (Maybe in the future we could even have a custom outcome, support for
> > > which could be advertised in the connection or link capabilities, that
> > > allowed an explicit aggregation of the outcomes from each distinct
> > > receiver to which the message was routed to be included)
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > > For additional commands, e-mail: users-help@qpid.apache.org
> > >
> > >
> >
> > --
> > -K
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
--
-K
Re: multicast without consumers
Posted by Chuck Rolke <cr...@redhat.com>.
> 1) All non-anonymous producer links will only be granted credit when the
> router is aware of at least one consumer. This applies to all of the
> address treatments uniformly (multicast, anycast, balanced, closest, ...)
>
> 2) Declare the fix to DISPATCH-779 invalid and change the JIRA's state to
> not-a-bug with the comment explaining the need to use anonymous links for
> that use case.
>
When vhost policy is in force then there is a problem problem with
forcing users to use anonymous links in order to send when there are
no consumers. The 'allowAnonymousSenders' policy setting then allows
the sender to send to *any* address, which is not always desirable.
This discussion *also* needs to include the link's settlement-mode
to describe router behavior for senders using links with a named
or unnamed (anonymous) target. The send settlement modes are:
SND_SETTLED, SND_MIXED, and SND_UNSETTLED.
As I understand it:
* A sender link in SND_MIXED or SND_UNSETTLED modes will
behave as Option 1.
* A sender link in SND_SETTLED mode will behave
differently: senders receive credit immediately regardless of
consumer presence; messages are settled and credit is restored at the
router's receiver so that the sender can send as fast as possible and
it looks to the sender like all messages were accepted; messages are
forwarded to receivers pre-settled; messages may be dropped aggressively
due to congestion. This is like a 'broadcast-best-effort' treatment.
Clients can choose the behavior they want by combining the link send-settle
mode (settled, mixed, unsettled) and the sender link target (named link
target or anonymous blank link target). Maybe a table or two showing how
the router treats message settlement, initial credit grant, and per-message
credit restoration both with and without policy restrictions would be
in order.
That said, I agree with option 1. Option 2 might be satisfied with
documents that have the suggested table showing message treatments.
Option 3 is less of an issue with 1.10 coming soon.
> 3) Declare 1.9.0 to be Broken and backport the proposed fix and release
> 1.9.1
>
> Let me know what you all think - I'm assuming silence is tacit approval of
> this proposal ;)
>
> On Tue, Nov 5, 2019 at 9:29 AM Gordon Sim <gs...@redhat.com> wrote:
>
> > On 05/11/2019 11:31 am, Robbie Gemmell wrote:
> > > I think always-accepting would be fairly consistent multicast / topic
> > > like behaviour that neednt imply any consumer delivery guarantee, the
> > > same way it doesnt for brokered cases, with it only meaning that a
> > > router saw the message, particularly if covered by the documentation.
> >
> > I think the brokered case is different as it involves a
> > store-and-forward semantic. The producer always cares only that the
> > broker it sent it to got it. The forwarding of the message is always
> > decoupled from that and so the state of consumers is irrelevant to the
> > acknowledgement for both queues and topics.
> >
> > The router provides an end-to-end acknowledgement rather than
> > store-and-forward. Though the limitations of the outcomes defined in the
> > AMQP specification prevent the fullest expression of that, Ken's work
> > allows what is in my view a more internally consistent approach.
> >
> > Reject always means that a receiver rejected it. Accept always means
> > that a receiver accepted it, and it was not rejected. Release always
> > means that either the message could not be routed to any receiver or
> > that any receiver to which it was routed explicitly released it.
> > Modified means it was routed to at least one receiver which either
> > explicitly issued the modified outcome or was disconnected before it
> > returned any explicit outcome.
> >
> > (Maybe in the future we could even have a custom outcome, support for
> > which could be advertised in the connection or link capabilities, that
> > allowed an explicit aggregation of the outcomes from each distinct
> > receiver to which the message was routed to be included)
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> >
>
> --
> -K
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: multicast without consumers
Posted by Gordon Sim <gs...@redhat.com>.
On 06/11/2019 2:04 pm, Ken Giusti wrote:
> In summary:
>
> 1) All non-anonymous producer links will only be granted credit when the
> router is aware of at least one consumer. This applies to all of the
> address treatments uniformly (multicast, anycast, balanced, closest, ...)
I agree with this.
> 2) Declare the fix to DISPATCH-779 invalid and change the JIRA's state to
> not-a-bug with the comment explaining the need to use anonymous links for
> that use case.
I also agree with this.
> 3) Declare 1.9.0 to be Broken and backport the proposed fix and release
> 1.9.1
I'm neutral on 1.9.1, 1.10.0 or even 2.0 :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: multicast without consumers
Posted by Ken Giusti <kg...@redhat.com>.
On Wed, Nov 6, 2019 at 10:05 AM Ganesh Murthy <gm...@redhat.com> wrote:
> On Wed, Nov 6, 2019 at 9:04 AM Ken Giusti <kg...@redhat.com> wrote:
>
> > Please excuse the top-posting - we're planning the next release of
> > qdrouterd and I'd like to confirm what the plan forward is regarding
> credit
> > management for multicast links.
> >
> > After reading through this discussion I believe the general consensus is
> to
> > ensure all non-anonymous links use the same link credit semantics
> > regardless of the type of address of the link. Specifically: multicast
> > link credit semantics will be the same as anycast - block credit until
> > consumers are present.
> >
> > Now with respect to those users that expect to be able to send multicast
> > messages regardless of consumers (the behavior that was introduced in
> > DISPATCH-779 <https://issues.apache.org/jira/browse/DISPATCH-779>):
> >
> > The qdrouterd has always supported unconditional credit allocation on
> > ANONYMOUS links. In other words, anonymous links will receive
> linkCapacity
> > credit regardless of the presence of consumers (since there's no address
> to
> > block on).
> >
> > I would argue that DISPATCH-779 is in fact not-a-bug - the correct
> solution
> > was to use an ANONYMOUS link instead of an addressed link.
> >
> > In summary:
> >
> > 1) All non-anonymous producer links will only be granted credit when the
> > router is aware of at least one consumer. This applies to all of the
> > address treatments uniformly (multicast, anycast, balanced, closest, ...)
> >
> > 2) Declare the fix to DISPATCH-779 invalid and change the JIRA's state to
> > not-a-bug with the comment explaining the need to use anonymous links for
> > that use case.
> >
> > 3) Declare 1.9.0 to be Broken and backport the proposed fix and release
> > 1.9.1
> >
> With 1.10.0 coming up in a couple of weeks which will have the above fix,
> Is a 1.9.1 necessary ?
>
>
I really don't feel strongly about #3 or #2 quite frankly. What I *do*
care about is #1.
What we do regarding release(s)/backporting really depends on whether or
not we do #1, so let's postpone the #3 and #2 discussion until we decide if
#1 merits inclusion in next release.
> >
> > Let me know what you all think - I'm assuming silence is tacit approval
> of
> > this proposal ;)
> >
> > On Tue, Nov 5, 2019 at 9:29 AM Gordon Sim <gs...@redhat.com> wrote:
> >
> > > On 05/11/2019 11:31 am, Robbie Gemmell wrote:
> > > > I think always-accepting would be fairly consistent multicast / topic
> > > > like behaviour that neednt imply any consumer delivery guarantee, the
> > > > same way it doesnt for brokered cases, with it only meaning that a
> > > > router saw the message, particularly if covered by the documentation.
> > >
> > > I think the brokered case is different as it involves a
> > > store-and-forward semantic. The producer always cares only that the
> > > broker it sent it to got it. The forwarding of the message is always
> > > decoupled from that and so the state of consumers is irrelevant to the
> > > acknowledgement for both queues and topics.
> > >
> > > The router provides an end-to-end acknowledgement rather than
> > > store-and-forward. Though the limitations of the outcomes defined in
> the
> > > AMQP specification prevent the fullest expression of that, Ken's work
> > > allows what is in my view a more internally consistent approach.
> > >
> > > Reject always means that a receiver rejected it. Accept always means
> > > that a receiver accepted it, and it was not rejected. Release always
> > > means that either the message could not be routed to any receiver or
> > > that any receiver to which it was routed explicitly released it.
> > > Modified means it was routed to at least one receiver which either
> > > explicitly issued the modified outcome or was disconnected before it
> > > returned any explicit outcome.
> > >
> > > (Maybe in the future we could even have a custom outcome, support for
> > > which could be advertised in the connection or link capabilities, that
> > > allowed an explicit aggregation of the outcomes from each distinct
> > > receiver to which the message was routed to be included)
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > > For additional commands, e-mail: users-help@qpid.apache.org
> > >
> > >
> >
> > --
> > -K
> >
>
--
-K
Re: multicast without consumers
Posted by Ganesh Murthy <gm...@redhat.com>.
On Wed, Nov 6, 2019 at 9:04 AM Ken Giusti <kg...@redhat.com> wrote:
> Please excuse the top-posting - we're planning the next release of
> qdrouterd and I'd like to confirm what the plan forward is regarding credit
> management for multicast links.
>
> After reading through this discussion I believe the general consensus is to
> ensure all non-anonymous links use the same link credit semantics
> regardless of the type of address of the link. Specifically: multicast
> link credit semantics will be the same as anycast - block credit until
> consumers are present.
>
> Now with respect to those users that expect to be able to send multicast
> messages regardless of consumers (the behavior that was introduced in
> DISPATCH-779 <https://issues.apache.org/jira/browse/DISPATCH-779>):
>
> The qdrouterd has always supported unconditional credit allocation on
> ANONYMOUS links. In other words, anonymous links will receive linkCapacity
> credit regardless of the presence of consumers (since there's no address to
> block on).
>
> I would argue that DISPATCH-779 is in fact not-a-bug - the correct solution
> was to use an ANONYMOUS link instead of an addressed link.
>
> In summary:
>
> 1) All non-anonymous producer links will only be granted credit when the
> router is aware of at least one consumer. This applies to all of the
> address treatments uniformly (multicast, anycast, balanced, closest, ...)
>
> 2) Declare the fix to DISPATCH-779 invalid and change the JIRA's state to
> not-a-bug with the comment explaining the need to use anonymous links for
> that use case.
>
> 3) Declare 1.9.0 to be Broken and backport the proposed fix and release
> 1.9.1
>
With 1.10.0 coming up in a couple of weeks which will have the above fix,
Is a 1.9.1 necessary ?
>
> Let me know what you all think - I'm assuming silence is tacit approval of
> this proposal ;)
>
> On Tue, Nov 5, 2019 at 9:29 AM Gordon Sim <gs...@redhat.com> wrote:
>
> > On 05/11/2019 11:31 am, Robbie Gemmell wrote:
> > > I think always-accepting would be fairly consistent multicast / topic
> > > like behaviour that neednt imply any consumer delivery guarantee, the
> > > same way it doesnt for brokered cases, with it only meaning that a
> > > router saw the message, particularly if covered by the documentation.
> >
> > I think the brokered case is different as it involves a
> > store-and-forward semantic. The producer always cares only that the
> > broker it sent it to got it. The forwarding of the message is always
> > decoupled from that and so the state of consumers is irrelevant to the
> > acknowledgement for both queues and topics.
> >
> > The router provides an end-to-end acknowledgement rather than
> > store-and-forward. Though the limitations of the outcomes defined in the
> > AMQP specification prevent the fullest expression of that, Ken's work
> > allows what is in my view a more internally consistent approach.
> >
> > Reject always means that a receiver rejected it. Accept always means
> > that a receiver accepted it, and it was not rejected. Release always
> > means that either the message could not be routed to any receiver or
> > that any receiver to which it was routed explicitly released it.
> > Modified means it was routed to at least one receiver which either
> > explicitly issued the modified outcome or was disconnected before it
> > returned any explicit outcome.
> >
> > (Maybe in the future we could even have a custom outcome, support for
> > which could be advertised in the connection or link capabilities, that
> > allowed an explicit aggregation of the outcomes from each distinct
> > receiver to which the message was routed to be included)
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> >
>
> --
> -K
>
Re: multicast without consumers
Posted by Ken Giusti <kg...@redhat.com>.
Please excuse the top-posting - we're planning the next release of
qdrouterd and I'd like to confirm what the plan forward is regarding credit
management for multicast links.
After reading through this discussion I believe the general consensus is to
ensure all non-anonymous links use the same link credit semantics
regardless of the type of address of the link. Specifically: multicast
link credit semantics will be the same as anycast - block credit until
consumers are present.
Now with respect to those users that expect to be able to send multicast
messages regardless of consumers (the behavior that was introduced in
DISPATCH-779 <https://issues.apache.org/jira/browse/DISPATCH-779>):
The qdrouterd has always supported unconditional credit allocation on
ANONYMOUS links. In other words, anonymous links will receive linkCapacity
credit regardless of the presence of consumers (since there's no address to
block on).
I would argue that DISPATCH-779 is in fact not-a-bug - the correct solution
was to use an ANONYMOUS link instead of an addressed link.
In summary:
1) All non-anonymous producer links will only be granted credit when the
router is aware of at least one consumer. This applies to all of the
address treatments uniformly (multicast, anycast, balanced, closest, ...)
2) Declare the fix to DISPATCH-779 invalid and change the JIRA's state to
not-a-bug with the comment explaining the need to use anonymous links for
that use case.
3) Declare 1.9.0 to be Broken and backport the proposed fix and release
1.9.1
Let me know what you all think - I'm assuming silence is tacit approval of
this proposal ;)
On Tue, Nov 5, 2019 at 9:29 AM Gordon Sim <gs...@redhat.com> wrote:
> On 05/11/2019 11:31 am, Robbie Gemmell wrote:
> > I think always-accepting would be fairly consistent multicast / topic
> > like behaviour that neednt imply any consumer delivery guarantee, the
> > same way it doesnt for brokered cases, with it only meaning that a
> > router saw the message, particularly if covered by the documentation.
>
> I think the brokered case is different as it involves a
> store-and-forward semantic. The producer always cares only that the
> broker it sent it to got it. The forwarding of the message is always
> decoupled from that and so the state of consumers is irrelevant to the
> acknowledgement for both queues and topics.
>
> The router provides an end-to-end acknowledgement rather than
> store-and-forward. Though the limitations of the outcomes defined in the
> AMQP specification prevent the fullest expression of that, Ken's work
> allows what is in my view a more internally consistent approach.
>
> Reject always means that a receiver rejected it. Accept always means
> that a receiver accepted it, and it was not rejected. Release always
> means that either the message could not be routed to any receiver or
> that any receiver to which it was routed explicitly released it.
> Modified means it was routed to at least one receiver which either
> explicitly issued the modified outcome or was disconnected before it
> returned any explicit outcome.
>
> (Maybe in the future we could even have a custom outcome, support for
> which could be advertised in the connection or link capabilities, that
> allowed an explicit aggregation of the outcomes from each distinct
> receiver to which the message was routed to be included)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
--
-K
Re: multicast without consumers
Posted by Gordon Sim <gs...@redhat.com>.
On 05/11/2019 11:31 am, Robbie Gemmell wrote:
> I think always-accepting would be fairly consistent multicast / topic
> like behaviour that neednt imply any consumer delivery guarantee, the
> same way it doesnt for brokered cases, with it only meaning that a
> router saw the message, particularly if covered by the documentation.
I think the brokered case is different as it involves a
store-and-forward semantic. The producer always cares only that the
broker it sent it to got it. The forwarding of the message is always
decoupled from that and so the state of consumers is irrelevant to the
acknowledgement for both queues and topics.
The router provides an end-to-end acknowledgement rather than
store-and-forward. Though the limitations of the outcomes defined in the
AMQP specification prevent the fullest expression of that, Ken's work
allows what is in my view a more internally consistent approach.
Reject always means that a receiver rejected it. Accept always means
that a receiver accepted it, and it was not rejected. Release always
means that either the message could not be routed to any receiver or
that any receiver to which it was routed explicitly released it.
Modified means it was routed to at least one receiver which either
explicitly issued the modified outcome or was disconnected before it
returned any explicit outcome.
(Maybe in the future we could even have a custom outcome, support for
which could be advertised in the connection or link capabilities, that
allowed an explicit aggregation of the outcomes from each distinct
receiver to which the message was routed to be included)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: multicast without consumers
Posted by Robbie Gemmell <ro...@gmail.com>.
On Mon, 4 Nov 2019 at 19:47, Gordon Sim <gs...@redhat.com> wrote:
>
> On 04/11/2019 5:50 pm, Robbie Gemmell wrote:
> > If I understand the change correctly it seems like before you would
> > always have got accepted after the send regardless what happens, and
> > the send is effectively isolated from reciept. Now, the send is tied
> > to reciept, and you can only reason that for multicast (assuming you
> > know the address is doing it) getting an accepted outcome on send
> > means at least one thing got it and accepted, but it could still be
> > the case that most recipients have either explicitly not accepted it,
> > dropped after receiving it, or have missed it entirely due to
> > occurrence of momentary disconnect between routers.
>
> Reliable multicast - where an identified set of receivers each have an
> at-least-once guarantee - is only possible with some form of
> store-and-forward semantic, which the router deliberately does not
> provide itself.
>
> If what is required is something like a broker's durable subscriptions,
> the router's multicast distribution is not the right tool.
>
I appreciate that, my point was essentially that its still not
reliable-multicast, but with the change acts a little more reliable,
but at expense of not being able to get the old behaviour. However,
per the bits later in the same mail, at the time I wrote that I still
thought the routers prior behaviour was to always accept (given that
was stated on this thread, and believing it also said on some JIRAs
relating to this change being made, e.g
https://issues.apache.org/jira/browse/DISPATCH-1423?focusedCommentId=16943791&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16943791)
when actually per this threads existence the router could in fact
release multicast messages in cases previously and so did not always
accept (at least on 1.5.0, maybe 1.8.0 was different?). So the
behaviour change it seems isnt quite what I thought it was.
> > Whilst I'd agree that is in some ways more consistent with the
> > non-multicast message routing, that you know at least something has
> > accepted, I think it in some ways its also unwisely implies more of a
> > general assurance around delivery than there actually is given it
> > still doesnt preclude most recipients having not seen it at all or
> > having not accepted it.
> I would argue, given the above limits of the multicast distribution, the
> accepted outcome can always be misinterpreted as implying a stronger (or
> different) delivery guarantee than is actually possible. I think the
> solution there is to keep improving the documentation to clarify aspects
> as we realise they need clarifying.
>
> https://qpid.apache.org/releases/qpid-dispatch-1.9.0/user-guide/index.html#message_settlement_and_reliability
>
I think always-accepting would be fairly consistent multicast / topic
like behaviour that neednt imply any consumer delivery guarantee, the
same way it doesnt for brokered cases, with it only meaning that a
router saw the message, particularly if covered by the documentation.
Again though, per above that bit was written when I believed the
router actually always accepted before, which it seems it didnt.
> > Clients releasing or modifying a received
> > message could also variably result in it being resent or not by the
> > sender based on whether or not a single other consumer had accepted it
> > or not.
> >
> > Related, it seems like even if all but one recipient accepts, if the
> > last rejects then the sender gets a reject. Again, in some ways its
> > good that you can know anything rejected if you want, but in others
> > seems poor that it signals reject at the sender while overlooking
> > everything else having accepted.
>
> Given the limitations of the outcomes as defined in the AMQP 1.0
> specification, there is no perfect mapping from multiple outcomes to a
> single outcome. I think the simpler we can make the rules, the better.
>
I dont think we have made it simpler but I also dont think its
complicated, though still open to misunderstanding. That bit was also
written when I thought the router only accepted before.
> A fundamental design characteristic of the router is end-to-end
> acknowledgement.
>
> If you get a reject, you know that the message it refers to was
> delivered to at least one consumer and at least one consumer explicitly
> rejected it.
>
> If you get an accept, you again know that the message it refers to was
> delivered to at least one consumer which accepted it, and that no
> consumer rejected it.
>
> To me that seems a reasonable compromise for preserving some degree of
> end-to-end acknowledgement capability for the multicast distribution.
>
Yep. As I've said, I was never against the new behaviour existing,
there are clearly cases its a better fit. I only thought it was a bad
idea to change it in the way [I thought it] had been, without catering
to the prior behaviour at all.
However, the prior behaviour I thought/asked/was-told/read existed
didnt actually match what the router did, at least for 1.5.0 per this
thread, and so it seems the change isnt quite as severe as I thought
it was, though its still substiantially different enough from before I
probably wouldnt have done it by default without option otherwise.
> [...]
> > this thread is really about the router 'consuming messages to
> > multicast' (from a broker), which is fairly different than a producer
> > 'sending messages to a multicast address' even if the protocol
> > transfer frames are the same, and it sounds like the router behaves
> > differently in that case which I think is perfectly reasonably.
>
> I don't think the router does behave differently in these cases, does
> it? (It certainly shouldn't). The issue is that the broker handles the
> release by resending the message which other types of sender might not do).
>
I was still coming to the realisation it could release multicast
messages previously, despite seemingly being confirmed otherwise that
it always accepted. Maybe I was still misinterpretting. Or maybe it
did behave differently in the situations. Perhaps 1.5.0 as used here
and 1.8.0 did different things before it changed for 1.9.0. I'm no
longer certain of much on this thread hehe, and clearly I'm in the
minority view on the changes, so with that coupling I'll be shutting
up shortly anyhow :)
> [...]
> > To be clear, the main thing I think is 'wrong' is changing the
> > multicast behaviour 'for senders' significantly by default in a minor
> > release, without giving any way to do the long standing prior
> > behaviour.
> The behaviour already has changed significantly on more than one
> occasion between releases. Earlier in the thread, the original issue on
> which the thread began was reported to be caused by the fix for
> DISPATCH-1012, which was itself a change in semantics for all message
> routed addresses (anycast as well as multicast).
>
> I think it is better that we determine what we think the 'right'
> behaviour is, and make it so. Where there are clear and concrete
> requirements for backward compatible (not identical) behaviour, let's
> understand those and figure out options.
>
> With regard to the minor version, generally the expectation for qpid
> dispatch is that bugs etc are fixed on the latest version. So even if
> the major version was bumped for changes in semantics, that wouldn't
> imply a commitment to continued fixes for older major versions. To pick
> up fixes you would still need to go to the latest. Generally we try
> really hard not to break things, but sometimes existing behaviour is
> deemed incorrect and other times subtle differences slip through without
> being fully appreciated at the time.
>
I wasn't suggesting otherwise around what releases are maintained or
that folks are required to upgrade to for fixes and current releases
(certainly they dont do that as much as we might want anyway). Just
the timing and approach of the change.
We've previously held making trivial changes like dropping old config
names (e.g that had been replaced, or just deprecated) until the major
version bump, changes that could be inconvenient at the server side
but at least immediately visible to an upgrading user and cant go
unseen in the slightest. Here, it seemed we significantly changed some
delivery behaviour in a way that can affect application usage and
actually might not be spotted immediately, and dropped it in a minor
release with no way to restore the existing behaviour. Again though,
given the old behaviour seemingly isnt what I thought it was, the
change isnt quite as severe as I originally thought it was either.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: multicast without consumers
Posted by Gordon Sim <gs...@redhat.com>.
On 04/11/2019 5:50 pm, Robbie Gemmell wrote:
> If I understand the change correctly it seems like before you would
> always have got accepted after the send regardless what happens, and
> the send is effectively isolated from reciept. Now, the send is tied
> to reciept, and you can only reason that for multicast (assuming you
> know the address is doing it) getting an accepted outcome on send
> means at least one thing got it and accepted, but it could still be
> the case that most recipients have either explicitly not accepted it,
> dropped after receiving it, or have missed it entirely due to
> occurrence of momentary disconnect between routers.
Reliable multicast - where an identified set of receivers each have an
at-least-once guarantee - is only possible with some form of
store-and-forward semantic, which the router deliberately does not
provide itself.
If what is required is something like a broker's durable subscriptions,
the router's multicast distribution is not the right tool.
> Whilst I'd agree that is in some ways more consistent with the
> non-multicast message routing, that you know at least something has
> accepted, I think it in some ways its also unwisely implies more of a
> general assurance around delivery than there actually is given it
> still doesnt preclude most recipients having not seen it at all or
> having not accepted it.
I would argue, given the above limits of the multicast distribution, the
accepted outcome can always be misinterpreted as implying a stronger (or
different) delivery guarantee than is actually possible. I think the
solution there is to keep improving the documentation to clarify aspects
as we realise they need clarifying.
https://qpid.apache.org/releases/qpid-dispatch-1.9.0/user-guide/index.html#message_settlement_and_reliability
> Clients releasing or modifying a received
> message could also variably result in it being resent or not by the
> sender based on whether or not a single other consumer had accepted it
> or not.
>
> Related, it seems like even if all but one recipient accepts, if the
> last rejects then the sender gets a reject. Again, in some ways its
> good that you can know anything rejected if you want, but in others
> seems poor that it signals reject at the sender while overlooking
> everything else having accepted.
Given the limitations of the outcomes as defined in the AMQP 1.0
specification, there is no perfect mapping from multiple outcomes to a
single outcome. I think the simpler we can make the rules, the better.
A fundamental design characteristic of the router is end-to-end
acknowledgement.
If you get a reject, you know that the message it refers to was
delivered to at least one consumer and at least one consumer explicitly
rejected it.
If you get an accept, you again know that the message it refers to was
delivered to at least one consumer which accepted it, and that no
consumer rejected it.
To me that seems a reasonable compromise for preserving some degree of
end-to-end acknowledgement capability for the multicast distribution.
[...]
> this thread is really about the router 'consuming messages to
> multicast' (from a broker), which is fairly different than a producer
> 'sending messages to a multicast address' even if the protocol
> transfer frames are the same, and it sounds like the router behaves
> differently in that case which I think is perfectly reasonably.
I don't think the router does behave differently in these cases, does
it? (It certainly shouldn't). The issue is that the broker handles the
release by resending the message which other types of sender might not do).
[...]
> To be clear, the main thing I think is 'wrong' is changing the
> multicast behaviour 'for senders' significantly by default in a minor
> release, without giving any way to do the long standing prior
> behaviour.
The behaviour already has changed significantly on more than one
occasion between releases. Earlier in the thread, the original issue on
which the thread began was reported to be caused by the fix for
DISPATCH-1012, which was itself a change in semantics for all message
routed addresses (anycast as well as multicast).
I think it is better that we determine what we think the 'right'
behaviour is, and make it so. Where there are clear and concrete
requirements for backward compatible (not identical) behaviour, let's
understand those and figure out options.
With regard to the minor version, generally the expectation for qpid
dispatch is that bugs etc are fixed on the latest version. So even if
the major version was bumped for changes in semantics, that wouldn't
imply a commitment to continued fixes for older major versions. To pick
up fixes you would still need to go to the latest. Generally we try
really hard not to break things, but sometimes existing behaviour is
deemed incorrect and other times subtle differences slip through without
being fully appreciated at the time.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: multicast without consumers
Posted by Robbie Gemmell <ro...@gmail.com>.
On Mon, 4 Nov 2019 at 15:08, Gordon Sim <gs...@redhat.com> wrote:
>
> In my opinion, in the context of the router, the accepted outcome should
> always mean that the message was routed to an appropriate receiver which
> then accepted it.
>
> If a producer, connected to router A sends messages on address for which
> there is a consumer connected to router B, then if router A and router B
> become momentarily disconnected, those messages that could not be routed
> will be released and the producer knows that they did not make it to the
> intended recipient. Having the same behaviour by default for multicast
> makes sense in my opinion as it is more consistent.
If I understand the change correctly it seems like before you would
always have got accepted after the send regardless what happens, and
the send is effectively isolated from reciept. Now, the send is tied
to reciept, and you can only reason that for multicast (assuming you
know the address is doing it) getting an accepted outcome on send
means at least one thing got it and accepted, but it could still be
the case that most recipients have either explicitly not accepted it,
dropped after receiving it, or have missed it entirely due to
occurrence of momentary disconnect between routers.
Whilst I'd agree that is in some ways more consistent with the
non-multicast message routing, that you know at least something has
accepted, I think it in some ways its also unwisely implies more of a
general assurance around delivery than there actually is given it
still doesnt preclude most recipients having not seen it at all or
having not accepted it. Clients releasing or modifying a received
message could also variably result in it being resent or not by the
sender based on whether or not a single other consumer had accepted it
or not.
Related, it seems like even if all but one recipient accepts, if the
last rejects then the sender gets a reject. Again, in some ways its
good that you can know anything rejected if you want, but in others
seems poor that it signals reject at the sender while overlooking
everything else having accepted.
>
> The behaviour of releasing messages due to there being no consumer to
> which they can be routed, yet still reissuing credit for them, is in my
> opinion an inconsistent combination. Either the router cares about
> whether it can route on that address (in which case it will release any
> messages that can't be routed and will not grant more credit) or it does
> not (and could therefore 'accept' message though it immediately drops
> them, but always issue credit).
>
I agree that its inconsistent to issue credit and then release, I just
think that shouldn't be releasing by default....ahh <insert
realisation of misunderstanding and stupidity here>.
I have mostly been discussing the perspective of a producer, sending
messages to the router and it then sending on to recipients, e.g I
asked for clarity on some points on that which Ted addressed here
https://lists.apache.org/thread.html/1e14ca7d111d4ea7e60a483ae9c48d953590284a87e291094c518792@%3Cusers.qpid.apache.org%3E
However, considering this thread again, it seems that based on that I
have been operating on a misunderstanding that the router was
prevously always accepting messages arriving for multicast before and
now isnt, when that clearly isnt the case or this thread simply
wouldnt exist (another about dropped messages presumably would) since
it is ultimately about Dispatch 1.5.0 releasing messages for multicast
at a waypoint.
Alas, this thread is really about the router 'consuming messages to
multicast' (from a broker), which is fairly different than a producer
'sending messages to a multicast address' even if the protocol
transfer frames are the same, and it sounds like the router behaves
differently in that case which I think is perfectly reasonably. I dont
think it is unreasonable for the router to be releasing messages it
has 'consumed to multicast' if there is nowhere to send them. As
you've said, continuing to grant new credit in this scenario could
also be seen as inconsistent, and not granting there wouldnt
necessarily be unreasonable, it depends what folks want in a given
case. Its again somewhat different than the case of something sending
to a multicast address.
> Personally I would be inclined to treat DISPATCH-1423 and DISPATCH-779
> as not-a-bug. I understand that the router behaviour might not always be
> what everyone expects (particularly those thinking in terms of a 'topic'
> on a 'broker'), but I don't think it is 'wrong'.
To be clear, the main thing I think is 'wrong' is changing the
multicast behaviour 'for senders' significantly by default in a minor
release, without giving any way to do the long standing prior
behaviour. I think the new behaviour is perfectly reasonable in
general and especially for those that want it, and havent been
depending on the prior behaviour that existed until now (related note:
do people have to upgrade all their routers at once with such
dispirate router behaviour, or will it still 'just work' albeit
completely differently depending on the router in use?)
Its also clear I've been arguing around a slightly different use case
than was actually really being discussed for this thread however,
coupling it with misunderstanding of the old behaviour that doesnt
reflect reality (i.e the router could previously release messages
meant for multicast before, for a waypoint).
>I'm not yet convinced
> there is a sufficiently strong case for needing that behaviour to
> justify an extra configuration option to test and document.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: multicast without consumers
Posted by Gordon Sim <gs...@redhat.com>.
In my opinion, in the context of the router, the accepted outcome should
always mean that the message was routed to an appropriate receiver which
then accepted it.
If a producer, connected to router A sends messages on address for which
there is a consumer connected to router B, then if router A and router B
become momentarily disconnected, those messages that could not be routed
will be released and the producer knows that they did not make it to the
intended recipient. Having the same behaviour by default for multicast
makes sense in my opinion as it is more consistent.
The behaviour of releasing messages due to there being no consumer to
which they can be routed, yet still reissuing credit for them, is in my
opinion an inconsistent combination. Either the router cares about
whether it can route on that address (in which case it will release any
messages that can't be routed and will not grant more credit) or it does
not (and could therefore 'accept' message though it immediately drops
them, but always issue credit).
Personally I would be inclined to treat DISPATCH-1423 and DISPATCH-779
as not-a-bug. I understand that the router behaviour might not always be
what everyone expects (particularly those thinking in terms of a 'topic'
on a 'broker'), but I don't think it is 'wrong'. I'm not yet convinced
there is a sufficiently strong case for needing that behaviour to
justify an extra configuration option to test and document.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: multicast without consumers
Posted by Robbie Gemmell <ro...@gmail.com>.
Further to the below, there is perhaps also a middle-ground option
that certainly I've not even been considering so far.
The prior multicast behaviour accepted all the time, but forwarded
unsettled messages as pre-settled and so couldnt govern sender credit
replenishment, and could suffer from congestion handling inside a
router network.
The new multicast behaviour releases if there are no consumers, or
accepts/releases/modifies/rejects based on some decision list if there
are, and uses unsettled forwarding to help govern sender credit and
avoid congestion inside a router network.
These are to an extent two extremes, and in the middle there is maybe
something of a compromise like 'accept like a topic as before, but
govern credit like now'. Maybe that might be another option?
Robbie
On Mon, 4 Nov 2019 at 11:48, Robbie Gemmell <ro...@gmail.com> wrote:
>
> On Fri, 1 Nov 2019 at 16:16, Ted Ross <tr...@redhat.com> wrote:
> >
> > On Fri, Nov 1, 2019 at 10:46 AM Robbie Gemmell <ro...@gmail.com>
> > wrote:
> >
> > > On Thu, 31 Oct 2019 at 17:31, Ted Ross <tr...@redhat.com> wrote:
> > > >
> > > > On Thu, Oct 31, 2019 at 6:57 AM Robbie Gemmell <robbie.gemmell@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > With the below, are you saying that previously the router would always
> > > > > immediately accept an unsettled message sent to a multicast address,
> > > > > and then either send it on (pre-settled) or drop it if there was
> > > > > nowhere to direct it
> > > >
> > > >
> > > > Yes.
> > > >
> > > >
> > > > > ....but in the latter case, now it would release
> > > > > it instead?
> > > >
> > > >
> > > > Yes.
> > > >
> > > >
> > > > > If so, is it possible to configure the old behaviour, for
> > > > > folks that actually wanted that?
> > > > >
> > > >
> > > > Perhaps. Does anyone want it? It _would_ prevent the looping behavior.
> > > >
> > >
> > > Who knows, did we ask? I dont think it is at all out of the realms of
> > > possibility that some do, especially given it is essentially how a
> > > brokered topic might often work, and how dispatch behaved until now.
> > >
> > > My main point is jsut that it was a fairly large change in behaviour
> > > given it worked the way it had for some time deliberately (as opposed
> > > to some bug), and now all of a sudden it isnt possible to get that
> > > behaviour at all. I dont think its a very nice change to have made in
> > > a minor release without providing any option to keep things working as
> > > they had. As suggested, sending pre-settled is the closest equivalent
> > > now (though not quite identical), but that unfortunately may require
> > > updating all your senders too.
> > >
> >
> > I agree with you in general about the change in behavior, however the old
> > behavior in this case was never a desirable behavior.
> >
> > A little history on this feature:
> >
> > When we first supported multicast distribution, the default behavior was to
> > reject all unsettled deliveries to multicast addresses. This was
> > technically correct in that multicast was only appropriate for pre-settled
> > QoS. In practice, however, this was a pretty serious problem. Not reading
> > the fine print, developers would send unsettled deliveries to multicast
> > addresses and get rejections and not understand why their communication
> > didn't work.
> >
> > Because of this, we changed the behavior to accept unsettled deliveries
> > even if they were not delivered to any consumer. I believe there was a
> > detailed discussion of this on this email list.
> >
>
> Yes, I remember discussing this a few times on the list and elsewhere.
> I always advocated that unsettled deliveries should be allowed and so
> didnt like the earlier behaviour to forbid them, I was glad of the
> change to accepting unsettled deliveries by default. I didnt, and
> still dont, believe you should have to change to send pre-settled to
> influence certain server behaviours (particularly given the way the
> router can handle congestion with pre-settled deliveries), but rather
> only do so if its what you originally wanted at the client.
>
> > Now, we have a much more proper way to handle unsettled deliveries on
> > multicast addresses. The question that arose was how to handle the
> > situation when there are no consumers. We could behave like anycast
> > addresses and throttle the senders, or we could behave more like a topic
> > and allow the sending of messages, but release the deliveries if there are
> > no consumers.
> >
> > In light of the current conversation, I would propose that the behavior be
> > made the same as anycast distribution without any configurable options. I
> > don't think that releasing deliveries is all that "topic-like" and
> > accepting them is incorrect and misleading.
> >
>
> I agree that releasing deliveries to multicast addresses without
> consumers is not all that 'topic-like'. However, I dont think
> accepting them is incorrect or misleading. It might not be what
> someone who really wanted more queue-like behaviour expected, but its
> not particularly out of character for 'topic-like' behaviour.
>
> I think the current 1.9.0 behaviour is the wrong default/sole
> behaviour personally, and the old behaviour would be preferable as a
> default (and also nice is that would mean not significantly changing
> the default behaviour in a minor release). I appreciate the new
> behaviour has some properties that are very useful in certain cases,
> and so much preferable to some folks, so please dont think I'm saying
> I'm against such behaviour existing as I'm not.
>
> We already know from the previous bug report mentioned in the thread
> (DISPATCH-779) that there is at least one user out there who expected
> multicast addresses to grant credit and permit sending even if there
> are no consumers. I would expect the same personally, per the above. I
> expect they would also have been surprised to get releases back if
> they were sending unsettled.
>
> > What would a broker do if messages were sent to a non-persistent topic for
> > which there were no subscribers?
> >
>
> Brokers would often behave in the same way that Dispatch 1.9.0 did for
> sends...issuing credit to allow sends, accepting messages sent, and
> dropping them if there are currently no topic subscriptions to add the
> message to. On send at least they (routers, brokers) used to behave
> essentially the same here, but as of 1.9.0 they are now very
> different.
>
> >
> > >
> > > >
> > > > >
> > > > > Or does it still accept in that case and you just meant that the end
> > > > > receiver outcomes are now interpreted to decide the response to the
> > > > > sender? What if the different multicast points return different
> > > > > outcomes?
> > > >
> > > >
> > > > If there are different dispositions, there is a priority list that
> > > > determines which of the provided dispositions will be returned to the
> > > > sender.
> > > >
> > > >
> > > > > What if one recipient doesnt provide an outcome for ages?
> > > >
> > > >
> > > > Then that delivery will not be settled for ages.
> > > >
> > > >
> > > > > Or
> > > > > goes away without providing one?
> > > > >
> > > >
> > > > Then the outcome from that recipient will be MODIFIED at the time the
> > > > receiver detaches.
> > > >
> > > >
> > > > >
> > > > > Or maybe it was both of the above? :)
> > > > >
> > > > > In some ways either of these seem like odd changes for a minor release
> > > > > unless its possible to toggle the previous long standing behaviour,
> > > > > and not say have to switch all your senders to pre-settled to mimmick
> > > > > but still not quite match it (since at least with the unsettled case
> > > > > before, youd at least know whether a [first, if multiple hops] router
> > > > > processed the message at all).
> > > > >
> > > > > Robbie
> > > > >
> > > > > On Wed, 30 Oct 2019 at 13:54, Ken Giusti <kg...@redhat.com> wrote:
> > > > > >
> > > > > > On Tue, Oct 29, 2019 at 6:23 PM VERMEULEN Olivier <
> > > > > > Olivier.VERMEULEN@murex.com> wrote:
> > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > Yes the waypoint address (in from broker) is using a multicast
> > > > > > > distribution.
> > > > > > > Unfortunately skipping the broker is not an option for us right
> > > now.
> > > > > > > Our whole architecture relies on the broker to guarantee that no
> > > > > messages
> > > > > > > will ever be lost...
> > > > > > >
> > > > > >
> > > > > > That won't be the case for multicast actually. Prior to release
> > > 1.9.0 of
> > > > > > the router multicast messages would be dropped without notification
> > > when
> > > > > > under load.
> > > > > >
> > > > > > This relates to the issue you're experiencing now I believe. In
> > > 1.9.0 we
> > > > > > fixed this via
> > > > > >
> > > > > > https://issues.apache.org/jira/browse/DISPATCH-1266
> > > > > >
> > > > > > Previously multicast messages were marked a pre-settled on entry to
> > > the
> > > > > > router and an "accepted" status was returned to the sender _before_
> > > the
> > > > > > multicast was forwarded at all. Since the message was marked
> > > pre-settled
> > > > > > the router mesh will be more likely to drop it should congestion
> > > occur.
> > > > > > (Note this not the case with unsettled anycast messages - the router
> > > will
> > > > > > send a "release" status should the message need be discarded).
> > > > > >
> > > > > > This auto-settle behavior was undesirable for a number of reasons as
> > > you
> > > > > > can imagine, so in 1.9.0 we changed the behavior of multicast
> > > deliveries:
> > > > > >
> > > > > > *unsettled* messages sent to multicast addresses are no longer
> > > > > pre-settled
> > > > > > by the router. The router will send back the final acknowledgement
> > > > > > (accepted, release, etc) once all *present* subscribers for the
> > > multicast
> > > > > > address return acknowledgements.
> > > > > >
> > > > > > The behavior of pre-settled multicast did not change.
> > > > > >
> > > > > > So you can probably restore the original behavior by reverted back
> > > to a
> > > > > > pre-1.9.0 release, however be aware that even then there's no
> > > guarantee
> > > > > the
> > > > > > message will be dropped. In fact it's _more_ likely to be dropped
> > > (and
> > > > > > signalled as accepted) in pre-1.9.0 releases.
> > > > > >
> > > > > >
> > > > > >
> > > > > > > For information we're asking for a quick workaround because we're
> > > > > facing
> > > > > > > this problem on a client production environment...
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Olivier
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Ken Giusti <kg...@redhat.com>
> > > > > > > Sent: mardi 29 octobre 2019 18:07
> > > > > > > To: users <us...@qpid.apache.org>
> > > > > > > Subject: Re: multicast without consumers
> > > > > > >
> > > > > > > On Tue, Oct 29, 2019 at 11:54 AM jeremy <je...@gmail.com>
> > > wrote:
> > > > > > >
> > > > > > > > Hello Gordon,
> > > > > > > >
> > > > > > > > We debugged the dispatch router, and fell on the code which
> > > releases
> > > > > > > > undeliverable messages(
> > > > > > > >
> > > > > https://github.com/apache/qpid-dispatch/blob/1.5.0/src/router_core/tra
> > > > > > > > nsfer.c#L869
> > > > > > > > ).
> > > > > > > >
> > > > > > > > Check the comment on line 879. It states that if the
> > > distribution is
> > > > > > > > multicast, the credit will be replenished after the release. The
> > > > > issue
> > > > > > > > that introduced this behavior is:
> > > > > > > > https://issues.apache.org/jira/browse/DISPATCH-1012
> > > > > > > >
> > > > > > > >
> > > > > > > Is the waypoint address (in from broker) using multicast
> > > distribution?
> > > > > > >
> > > > > > > The router treats multicast addresses like topics - you can
> > > publish to
> > > > > a
> > > > > > > multicast address (topic) regardless of the presence of consumers.
> > > > > That's
> > > > > > > the reason credit is being replenished even when no consumers are
> > > > > present.
> > > > > > >
> > > > > > > That's probably what's happening here - broker sends first queued
> > > > > message
> > > > > > > to the router, which attempts to send it to the topic. Since
> > > there
> > > > > are no
> > > > > > > consumers (and the message is sent from the broker as unsettled)
> > > the
> > > > > > > router cannot deliver it so it returns the released status. The
> > > > > released
> > > > > > > status causes the broker to redeliver the message. Repeat.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > In fact, we need an urgent fix/workaround for this. Perhaps
> > > there is
> > > > > a
> > > > > > > > quick workaround, awaiting the full analysis of this problem?
> > > > > > > >
> > > > > > > >
> > > > > > > As a work around can you avoid sending these multicast messages to
> > > the
> > > > > > > broker queue? In other words send them directly to the router
> > > instead
> > > > > of
> > > > > > > using a waypoint?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > Thanks
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > -----
> > > > > > > > Cheers,
> > > > > > > > Jeremy
> > > > > > > > --
> > > > > > > > Sent from:
> > > > > > > >
> > > http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
> > > > > > > >
> > > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For
> > > > > > > > additional commands, e-mail: users-help@qpid.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > -K
> > > > > > > *******************************
> > > > > > > This e-mail contains information for the intended recipient only.
> > > It
> > > > > may
> > > > > > > contain proprietary material or confidential information. If you
> > > are
> > > > > not
> > > > > > > the intended recipient you are not authorized to distribute, copy
> > > or
> > > > > use
> > > > > > > this e-mail or any attachment to it. Murex cannot guarantee that
> > > it is
> > > > > > > virus free and accepts no responsibility for any loss or damage
> > > arising
> > > > > > > from its use. If you have received this e-mail in error please
> > > notify
> > > > > > > immediately the sender and delete the original email received, any
> > > > > > > attachments and all copies from your system.
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > -K
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > > > > For additional commands, e-mail: users-help@qpid.apache.org
> > > > >
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > > For additional commands, e-mail: users-help@qpid.apache.org
> > >
> > >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: multicast without consumers
Posted by Robbie Gemmell <ro...@gmail.com>.
On Fri, 1 Nov 2019 at 16:16, Ted Ross <tr...@redhat.com> wrote:
>
> On Fri, Nov 1, 2019 at 10:46 AM Robbie Gemmell <ro...@gmail.com>
> wrote:
>
> > On Thu, 31 Oct 2019 at 17:31, Ted Ross <tr...@redhat.com> wrote:
> > >
> > > On Thu, Oct 31, 2019 at 6:57 AM Robbie Gemmell <robbie.gemmell@gmail.com
> > >
> > > wrote:
> > >
> > > > With the below, are you saying that previously the router would always
> > > > immediately accept an unsettled message sent to a multicast address,
> > > > and then either send it on (pre-settled) or drop it if there was
> > > > nowhere to direct it
> > >
> > >
> > > Yes.
> > >
> > >
> > > > ....but in the latter case, now it would release
> > > > it instead?
> > >
> > >
> > > Yes.
> > >
> > >
> > > > If so, is it possible to configure the old behaviour, for
> > > > folks that actually wanted that?
> > > >
> > >
> > > Perhaps. Does anyone want it? It _would_ prevent the looping behavior.
> > >
> >
> > Who knows, did we ask? I dont think it is at all out of the realms of
> > possibility that some do, especially given it is essentially how a
> > brokered topic might often work, and how dispatch behaved until now.
> >
> > My main point is jsut that it was a fairly large change in behaviour
> > given it worked the way it had for some time deliberately (as opposed
> > to some bug), and now all of a sudden it isnt possible to get that
> > behaviour at all. I dont think its a very nice change to have made in
> > a minor release without providing any option to keep things working as
> > they had. As suggested, sending pre-settled is the closest equivalent
> > now (though not quite identical), but that unfortunately may require
> > updating all your senders too.
> >
>
> I agree with you in general about the change in behavior, however the old
> behavior in this case was never a desirable behavior.
>
> A little history on this feature:
>
> When we first supported multicast distribution, the default behavior was to
> reject all unsettled deliveries to multicast addresses. This was
> technically correct in that multicast was only appropriate for pre-settled
> QoS. In practice, however, this was a pretty serious problem. Not reading
> the fine print, developers would send unsettled deliveries to multicast
> addresses and get rejections and not understand why their communication
> didn't work.
>
> Because of this, we changed the behavior to accept unsettled deliveries
> even if they were not delivered to any consumer. I believe there was a
> detailed discussion of this on this email list.
>
Yes, I remember discussing this a few times on the list and elsewhere.
I always advocated that unsettled deliveries should be allowed and so
didnt like the earlier behaviour to forbid them, I was glad of the
change to accepting unsettled deliveries by default. I didnt, and
still dont, believe you should have to change to send pre-settled to
influence certain server behaviours (particularly given the way the
router can handle congestion with pre-settled deliveries), but rather
only do so if its what you originally wanted at the client.
> Now, we have a much more proper way to handle unsettled deliveries on
> multicast addresses. The question that arose was how to handle the
> situation when there are no consumers. We could behave like anycast
> addresses and throttle the senders, or we could behave more like a topic
> and allow the sending of messages, but release the deliveries if there are
> no consumers.
>
> In light of the current conversation, I would propose that the behavior be
> made the same as anycast distribution without any configurable options. I
> don't think that releasing deliveries is all that "topic-like" and
> accepting them is incorrect and misleading.
>
I agree that releasing deliveries to multicast addresses without
consumers is not all that 'topic-like'. However, I dont think
accepting them is incorrect or misleading. It might not be what
someone who really wanted more queue-like behaviour expected, but its
not particularly out of character for 'topic-like' behaviour.
I think the current 1.9.0 behaviour is the wrong default/sole
behaviour personally, and the old behaviour would be preferable as a
default (and also nice is that would mean not significantly changing
the default behaviour in a minor release). I appreciate the new
behaviour has some properties that are very useful in certain cases,
and so much preferable to some folks, so please dont think I'm saying
I'm against such behaviour existing as I'm not.
We already know from the previous bug report mentioned in the thread
(DISPATCH-779) that there is at least one user out there who expected
multicast addresses to grant credit and permit sending even if there
are no consumers. I would expect the same personally, per the above. I
expect they would also have been surprised to get releases back if
they were sending unsettled.
> What would a broker do if messages were sent to a non-persistent topic for
> which there were no subscribers?
>
Brokers would often behave in the same way that Dispatch 1.9.0 did for
sends...issuing credit to allow sends, accepting messages sent, and
dropping them if there are currently no topic subscriptions to add the
message to. On send at least they (routers, brokers) used to behave
essentially the same here, but as of 1.9.0 they are now very
different.
>
> >
> > >
> > > >
> > > > Or does it still accept in that case and you just meant that the end
> > > > receiver outcomes are now interpreted to decide the response to the
> > > > sender? What if the different multicast points return different
> > > > outcomes?
> > >
> > >
> > > If there are different dispositions, there is a priority list that
> > > determines which of the provided dispositions will be returned to the
> > > sender.
> > >
> > >
> > > > What if one recipient doesnt provide an outcome for ages?
> > >
> > >
> > > Then that delivery will not be settled for ages.
> > >
> > >
> > > > Or
> > > > goes away without providing one?
> > > >
> > >
> > > Then the outcome from that recipient will be MODIFIED at the time the
> > > receiver detaches.
> > >
> > >
> > > >
> > > > Or maybe it was both of the above? :)
> > > >
> > > > In some ways either of these seem like odd changes for a minor release
> > > > unless its possible to toggle the previous long standing behaviour,
> > > > and not say have to switch all your senders to pre-settled to mimmick
> > > > but still not quite match it (since at least with the unsettled case
> > > > before, youd at least know whether a [first, if multiple hops] router
> > > > processed the message at all).
> > > >
> > > > Robbie
> > > >
> > > > On Wed, 30 Oct 2019 at 13:54, Ken Giusti <kg...@redhat.com> wrote:
> > > > >
> > > > > On Tue, Oct 29, 2019 at 6:23 PM VERMEULEN Olivier <
> > > > > Olivier.VERMEULEN@murex.com> wrote:
> > > > >
> > > > > > Hello,
> > > > > >
> > > > > > Yes the waypoint address (in from broker) is using a multicast
> > > > > > distribution.
> > > > > > Unfortunately skipping the broker is not an option for us right
> > now.
> > > > > > Our whole architecture relies on the broker to guarantee that no
> > > > messages
> > > > > > will ever be lost...
> > > > > >
> > > > >
> > > > > That won't be the case for multicast actually. Prior to release
> > 1.9.0 of
> > > > > the router multicast messages would be dropped without notification
> > when
> > > > > under load.
> > > > >
> > > > > This relates to the issue you're experiencing now I believe. In
> > 1.9.0 we
> > > > > fixed this via
> > > > >
> > > > > https://issues.apache.org/jira/browse/DISPATCH-1266
> > > > >
> > > > > Previously multicast messages were marked a pre-settled on entry to
> > the
> > > > > router and an "accepted" status was returned to the sender _before_
> > the
> > > > > multicast was forwarded at all. Since the message was marked
> > pre-settled
> > > > > the router mesh will be more likely to drop it should congestion
> > occur.
> > > > > (Note this not the case with unsettled anycast messages - the router
> > will
> > > > > send a "release" status should the message need be discarded).
> > > > >
> > > > > This auto-settle behavior was undesirable for a number of reasons as
> > you
> > > > > can imagine, so in 1.9.0 we changed the behavior of multicast
> > deliveries:
> > > > >
> > > > > *unsettled* messages sent to multicast addresses are no longer
> > > > pre-settled
> > > > > by the router. The router will send back the final acknowledgement
> > > > > (accepted, release, etc) once all *present* subscribers for the
> > multicast
> > > > > address return acknowledgements.
> > > > >
> > > > > The behavior of pre-settled multicast did not change.
> > > > >
> > > > > So you can probably restore the original behavior by reverted back
> > to a
> > > > > pre-1.9.0 release, however be aware that even then there's no
> > guarantee
> > > > the
> > > > > message will be dropped. In fact it's _more_ likely to be dropped
> > (and
> > > > > signalled as accepted) in pre-1.9.0 releases.
> > > > >
> > > > >
> > > > >
> > > > > > For information we're asking for a quick workaround because we're
> > > > facing
> > > > > > this problem on a client production environment...
> > > > > >
> > > > > > Thanks,
> > > > > > Olivier
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Ken Giusti <kg...@redhat.com>
> > > > > > Sent: mardi 29 octobre 2019 18:07
> > > > > > To: users <us...@qpid.apache.org>
> > > > > > Subject: Re: multicast without consumers
> > > > > >
> > > > > > On Tue, Oct 29, 2019 at 11:54 AM jeremy <je...@gmail.com>
> > wrote:
> > > > > >
> > > > > > > Hello Gordon,
> > > > > > >
> > > > > > > We debugged the dispatch router, and fell on the code which
> > releases
> > > > > > > undeliverable messages(
> > > > > > >
> > > > https://github.com/apache/qpid-dispatch/blob/1.5.0/src/router_core/tra
> > > > > > > nsfer.c#L869
> > > > > > > ).
> > > > > > >
> > > > > > > Check the comment on line 879. It states that if the
> > distribution is
> > > > > > > multicast, the credit will be replenished after the release. The
> > > > issue
> > > > > > > that introduced this behavior is:
> > > > > > > https://issues.apache.org/jira/browse/DISPATCH-1012
> > > > > > >
> > > > > > >
> > > > > > Is the waypoint address (in from broker) using multicast
> > distribution?
> > > > > >
> > > > > > The router treats multicast addresses like topics - you can
> > publish to
> > > > a
> > > > > > multicast address (topic) regardless of the presence of consumers.
> > > > That's
> > > > > > the reason credit is being replenished even when no consumers are
> > > > present.
> > > > > >
> > > > > > That's probably what's happening here - broker sends first queued
> > > > message
> > > > > > to the router, which attempts to send it to the topic. Since
> > there
> > > > are no
> > > > > > consumers (and the message is sent from the broker as unsettled)
> > the
> > > > > > router cannot deliver it so it returns the released status. The
> > > > released
> > > > > > status causes the broker to redeliver the message. Repeat.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > > In fact, we need an urgent fix/workaround for this. Perhaps
> > there is
> > > > a
> > > > > > > quick workaround, awaiting the full analysis of this problem?
> > > > > > >
> > > > > > >
> > > > > > As a work around can you avoid sending these multicast messages to
> > the
> > > > > > broker queue? In other words send them directly to the router
> > instead
> > > > of
> > > > > > using a waypoint?
> > > > > >
> > > > > >
> > > > > >
> > > > > > > Thanks
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > -----
> > > > > > > Cheers,
> > > > > > > Jeremy
> > > > > > > --
> > > > > > > Sent from:
> > > > > > >
> > http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
> > > > > > >
> > > > > > >
> > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For
> > > > > > > additional commands, e-mail: users-help@qpid.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > -K
> > > > > > *******************************
> > > > > > This e-mail contains information for the intended recipient only.
> > It
> > > > may
> > > > > > contain proprietary material or confidential information. If you
> > are
> > > > not
> > > > > > the intended recipient you are not authorized to distribute, copy
> > or
> > > > use
> > > > > > this e-mail or any attachment to it. Murex cannot guarantee that
> > it is
> > > > > > virus free and accepts no responsibility for any loss or damage
> > arising
> > > > > > from its use. If you have received this e-mail in error please
> > notify
> > > > > > immediately the sender and delete the original email received, any
> > > > > > attachments and all copies from your system.
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > -K
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > > > For additional commands, e-mail: users-help@qpid.apache.org
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
RE: multicast without consumers
Posted by VERMEULEN Olivier <Ol...@murex.com>.
Hello,
First, thank you guys for the quick reply/analysis.
We should be able to unblock our client by upgrading their dispatch-router version to 1.9.0.
Now this is only a short term solution.
Indeed if DISPATCH-1423 makes it the master we won't be able to upgrade to newer versions of the dispatch-router... unless the multicast behavior is changed or made configurable.
Regarding the below discussion, note that pre-settled messages is not an option for us as the senders don't even know if they are sending to a multicast or balanced address...
Olivier
-----Original Message-----
From: Gordon Sim <gs...@redhat.com>
Sent: vendredi 1 novembre 2019 17:28
To: users@qpid.apache.org
Subject: Re: multicast without consumers
On 01/11/2019 3:58 pm, Ted Ross wrote:
> We could behave like anycast addresses and throttle the senders, or we
> could behave more like a topic and allow the sending of messages, but
> release the deliveries if there are no consumers.
I don't think these are alternatives, I think they are different aspects of the same 'mode'. I.e. I think when the consumer all go away, you should not renew credit but release the message you do receive (presumably sent for previously granted credit).
The alternative 'mode', if there was to be one, would neither throttle nor release, but would accept but drop messages when there were no consumers. The question then is whether there is sufficient value in adding such a 'mode' or if requiring that messages be sent presettled is an acceptable way of triggering that type of behaviour.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For additional commands, e-mail: users-help@qpid.apache.org
*******************************
This e-mail contains information for the intended recipient only. It may contain proprietary material or confidential information. If you are not the intended recipient you are not authorized to distribute, copy or use this e-mail or any attachment to it. Murex cannot guarantee that it is virus free and accepts no responsibility for any loss or damage arising from its use. If you have received this e-mail in error please notify immediately the sender and delete the original email received, any attachments and all copies from your system.
Re: multicast without consumers
Posted by Gordon Sim <gs...@redhat.com>.
On 01/11/2019 3:58 pm, Ted Ross wrote:
> We could behave like anycast addresses and throttle the senders, or
> we could behave more like a topic and allow the sending of messages,
> but release the deliveries if there are no consumers.
I don't think these are alternatives, I think they are different aspects
of the same 'mode'. I.e. I think when the consumer all go away, you
should not renew credit but release the message you do receive
(presumably sent for previously granted credit).
The alternative 'mode', if there was to be one, would neither throttle
nor release, but would accept but drop messages when there were no
consumers. The question then is whether there is sufficient value in
adding such a 'mode' or if requiring that messages be sent presettled is
an acceptable way of triggering that type of behaviour.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: multicast without consumers
Posted by Ted Ross <tr...@redhat.com>.
On Fri, Nov 1, 2019 at 10:46 AM Robbie Gemmell <ro...@gmail.com>
wrote:
> On Thu, 31 Oct 2019 at 17:31, Ted Ross <tr...@redhat.com> wrote:
> >
> > On Thu, Oct 31, 2019 at 6:57 AM Robbie Gemmell <robbie.gemmell@gmail.com
> >
> > wrote:
> >
> > > With the below, are you saying that previously the router would always
> > > immediately accept an unsettled message sent to a multicast address,
> > > and then either send it on (pre-settled) or drop it if there was
> > > nowhere to direct it
> >
> >
> > Yes.
> >
> >
> > > ....but in the latter case, now it would release
> > > it instead?
> >
> >
> > Yes.
> >
> >
> > > If so, is it possible to configure the old behaviour, for
> > > folks that actually wanted that?
> > >
> >
> > Perhaps. Does anyone want it? It _would_ prevent the looping behavior.
> >
>
> Who knows, did we ask? I dont think it is at all out of the realms of
> possibility that some do, especially given it is essentially how a
> brokered topic might often work, and how dispatch behaved until now.
>
> My main point is jsut that it was a fairly large change in behaviour
> given it worked the way it had for some time deliberately (as opposed
> to some bug), and now all of a sudden it isnt possible to get that
> behaviour at all. I dont think its a very nice change to have made in
> a minor release without providing any option to keep things working as
> they had. As suggested, sending pre-settled is the closest equivalent
> now (though not quite identical), but that unfortunately may require
> updating all your senders too.
>
I agree with you in general about the change in behavior, however the old
behavior in this case was never a desirable behavior.
A little history on this feature:
When we first supported multicast distribution, the default behavior was to
reject all unsettled deliveries to multicast addresses. This was
technically correct in that multicast was only appropriate for pre-settled
QoS. In practice, however, this was a pretty serious problem. Not reading
the fine print, developers would send unsettled deliveries to multicast
addresses and get rejections and not understand why their communication
didn't work.
Because of this, we changed the behavior to accept unsettled deliveries
even if they were not delivered to any consumer. I believe there was a
detailed discussion of this on this email list.
Now, we have a much more proper way to handle unsettled deliveries on
multicast addresses. The question that arose was how to handle the
situation when there are no consumers. We could behave like anycast
addresses and throttle the senders, or we could behave more like a topic
and allow the sending of messages, but release the deliveries if there are
no consumers.
In light of the current conversation, I would propose that the behavior be
made the same as anycast distribution without any configurable options. I
don't think that releasing deliveries is all that "topic-like" and
accepting them is incorrect and misleading.
What would a broker do if messages were sent to a non-persistent topic for
which there were no subscribers?
>
> >
> > >
> > > Or does it still accept in that case and you just meant that the end
> > > receiver outcomes are now interpreted to decide the response to the
> > > sender? What if the different multicast points return different
> > > outcomes?
> >
> >
> > If there are different dispositions, there is a priority list that
> > determines which of the provided dispositions will be returned to the
> > sender.
> >
> >
> > > What if one recipient doesnt provide an outcome for ages?
> >
> >
> > Then that delivery will not be settled for ages.
> >
> >
> > > Or
> > > goes away without providing one?
> > >
> >
> > Then the outcome from that recipient will be MODIFIED at the time the
> > receiver detaches.
> >
> >
> > >
> > > Or maybe it was both of the above? :)
> > >
> > > In some ways either of these seem like odd changes for a minor release
> > > unless its possible to toggle the previous long standing behaviour,
> > > and not say have to switch all your senders to pre-settled to mimmick
> > > but still not quite match it (since at least with the unsettled case
> > > before, youd at least know whether a [first, if multiple hops] router
> > > processed the message at all).
> > >
> > > Robbie
> > >
> > > On Wed, 30 Oct 2019 at 13:54, Ken Giusti <kg...@redhat.com> wrote:
> > > >
> > > > On Tue, Oct 29, 2019 at 6:23 PM VERMEULEN Olivier <
> > > > Olivier.VERMEULEN@murex.com> wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > Yes the waypoint address (in from broker) is using a multicast
> > > > > distribution.
> > > > > Unfortunately skipping the broker is not an option for us right
> now.
> > > > > Our whole architecture relies on the broker to guarantee that no
> > > messages
> > > > > will ever be lost...
> > > > >
> > > >
> > > > That won't be the case for multicast actually. Prior to release
> 1.9.0 of
> > > > the router multicast messages would be dropped without notification
> when
> > > > under load.
> > > >
> > > > This relates to the issue you're experiencing now I believe. In
> 1.9.0 we
> > > > fixed this via
> > > >
> > > > https://issues.apache.org/jira/browse/DISPATCH-1266
> > > >
> > > > Previously multicast messages were marked a pre-settled on entry to
> the
> > > > router and an "accepted" status was returned to the sender _before_
> the
> > > > multicast was forwarded at all. Since the message was marked
> pre-settled
> > > > the router mesh will be more likely to drop it should congestion
> occur.
> > > > (Note this not the case with unsettled anycast messages - the router
> will
> > > > send a "release" status should the message need be discarded).
> > > >
> > > > This auto-settle behavior was undesirable for a number of reasons as
> you
> > > > can imagine, so in 1.9.0 we changed the behavior of multicast
> deliveries:
> > > >
> > > > *unsettled* messages sent to multicast addresses are no longer
> > > pre-settled
> > > > by the router. The router will send back the final acknowledgement
> > > > (accepted, release, etc) once all *present* subscribers for the
> multicast
> > > > address return acknowledgements.
> > > >
> > > > The behavior of pre-settled multicast did not change.
> > > >
> > > > So you can probably restore the original behavior by reverted back
> to a
> > > > pre-1.9.0 release, however be aware that even then there's no
> guarantee
> > > the
> > > > message will be dropped. In fact it's _more_ likely to be dropped
> (and
> > > > signalled as accepted) in pre-1.9.0 releases.
> > > >
> > > >
> > > >
> > > > > For information we're asking for a quick workaround because we're
> > > facing
> > > > > this problem on a client production environment...
> > > > >
> > > > > Thanks,
> > > > > Olivier
> > > > >
> > > > > -----Original Message-----
> > > > > From: Ken Giusti <kg...@redhat.com>
> > > > > Sent: mardi 29 octobre 2019 18:07
> > > > > To: users <us...@qpid.apache.org>
> > > > > Subject: Re: multicast without consumers
> > > > >
> > > > > On Tue, Oct 29, 2019 at 11:54 AM jeremy <je...@gmail.com>
> wrote:
> > > > >
> > > > > > Hello Gordon,
> > > > > >
> > > > > > We debugged the dispatch router, and fell on the code which
> releases
> > > > > > undeliverable messages(
> > > > > >
> > > https://github.com/apache/qpid-dispatch/blob/1.5.0/src/router_core/tra
> > > > > > nsfer.c#L869
> > > > > > ).
> > > > > >
> > > > > > Check the comment on line 879. It states that if the
> distribution is
> > > > > > multicast, the credit will be replenished after the release. The
> > > issue
> > > > > > that introduced this behavior is:
> > > > > > https://issues.apache.org/jira/browse/DISPATCH-1012
> > > > > >
> > > > > >
> > > > > Is the waypoint address (in from broker) using multicast
> distribution?
> > > > >
> > > > > The router treats multicast addresses like topics - you can
> publish to
> > > a
> > > > > multicast address (topic) regardless of the presence of consumers.
> > > That's
> > > > > the reason credit is being replenished even when no consumers are
> > > present.
> > > > >
> > > > > That's probably what's happening here - broker sends first queued
> > > message
> > > > > to the router, which attempts to send it to the topic. Since
> there
> > > are no
> > > > > consumers (and the message is sent from the broker as unsettled)
> the
> > > > > router cannot deliver it so it returns the released status. The
> > > released
> > > > > status causes the broker to redeliver the message. Repeat.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > In fact, we need an urgent fix/workaround for this. Perhaps
> there is
> > > a
> > > > > > quick workaround, awaiting the full analysis of this problem?
> > > > > >
> > > > > >
> > > > > As a work around can you avoid sending these multicast messages to
> the
> > > > > broker queue? In other words send them directly to the router
> instead
> > > of
> > > > > using a waypoint?
> > > > >
> > > > >
> > > > >
> > > > > > Thanks
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > -----
> > > > > > Cheers,
> > > > > > Jeremy
> > > > > > --
> > > > > > Sent from:
> > > > > >
> http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
> > > > > >
> > > > > >
> ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For
> > > > > > additional commands, e-mail: users-help@qpid.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > -K
> > > > > *******************************
> > > > > This e-mail contains information for the intended recipient only.
> It
> > > may
> > > > > contain proprietary material or confidential information. If you
> are
> > > not
> > > > > the intended recipient you are not authorized to distribute, copy
> or
> > > use
> > > > > this e-mail or any attachment to it. Murex cannot guarantee that
> it is
> > > > > virus free and accepts no responsibility for any loss or damage
> arising
> > > > > from its use. If you have received this e-mail in error please
> notify
> > > > > immediately the sender and delete the original email received, any
> > > > > attachments and all copies from your system.
> > > > >
> > > >
> > > >
> > > > --
> > > > -K
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > > For additional commands, e-mail: users-help@qpid.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>