You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Ted Ross <tr...@redhat.com> on 2018/04/12 22:20:12 UTC
Proposed Feature Removal from Dispatch Router
We added a feature back in 1.0.0 to reject unsettled deliveries to
multicast addresses by default. This can be disabled through
configuration but is on by default.
The rationale was that the router would accept and settle unsettled
multicasts even though it might not have delivered the messages to any
consumer. The rejection with error code was intended to inform users
that they should pre-settle deliveries to multicast addresses in
keeping with the best-effort nature of multicast routing.
In practice, this is more of an annoyance because none of the example
clients (and apparently the users' clients) actually do anything with
the error code in the rejected delivery. The router appears to
silently drop such messages for no good reason and good will is wasted
in chasing down the issue to "oh, you should turn off this handy
feature".
The recently raised https://issues.apache.org/jira/browse/DISPATCH-966
is caused by this feature as well. This is because the router can
stream large messages in multiple transfers. The first transfer is
used for routing and the last transfer should be used to determine the
settlement status of the delivery. It is not a trivial fix to make
this work correctly.
For the above two reasons, I propose that we back out this feature and
allow multicasting with unsettled deliveries. We should add a clear
note in the documentation that states that multicast is best-effort,
regardless of the settlement status of the deliveries.
Any objections from the users?
-Ted
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Proposed Feature Removal from Dispatch Router
Posted by Robbie Gemmell <ro...@gmail.com>.
On 7 June 2018 at 23:44, Justin Ross <ju...@gmail.com> wrote:
> On Tue, Apr 17, 2018 at 9:10 AM Gordon Sim <gs...@redhat.com> wrote:
>
>> I think Ted is right that the feature did not reach that goal. It is not
>> sufficiently clear what is going on and on balance doesn't I think
>> justify the potential annoyance.
>>
>> However I do think that some other solution to the problem of informing
>> users would be worthwhile. This could be a warning in the log the first
>> time a link sends an unsettled message to a multicast address (along
>> with a section in the doc that clarifies the way things work).
>>
>
> I looked at the commits reverting this, and I didn't see anything about
> logging a warning. Is this filed as a future enhancement? I wasn't able
> to find anything in jira.
>
I dont think it is filed.
I dont personally think it needed.
>
>> (As a separate issue, I do also think that the way in which multicast
>> messages are dropped when necessary could be improved upon, e.g. looking
>> at ttl, priority, settled state etc when decide what to drop).
>>
>
> Same question here, supposing we have some concrete ideas about what we
> could do.
>
> I also don't fully understand why the option controlling whether this is an
> error was removed entirely, rather than changing the default value of that
> option. Maybe that's right, but it has a premise in it - that no one will
> want this behavior - that I don't think we established in this discussion.
I think Ted did somewhat in his initial mail - it was broken and
fixing it isnt trivial, so leaving an option leaves possibility of it
not working.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Proposed Feature Removal from Dispatch Router
Posted by Justin Ross <ju...@gmail.com>.
On Tue, Apr 17, 2018 at 9:10 AM Gordon Sim <gs...@redhat.com> wrote:
> I think Ted is right that the feature did not reach that goal. It is not
> sufficiently clear what is going on and on balance doesn't I think
> justify the potential annoyance.
>
> However I do think that some other solution to the problem of informing
> users would be worthwhile. This could be a warning in the log the first
> time a link sends an unsettled message to a multicast address (along
> with a section in the doc that clarifies the way things work).
>
I looked at the commits reverting this, and I didn't see anything about
logging a warning. Is this filed as a future enhancement? I wasn't able
to find anything in jira.
> (As a separate issue, I do also think that the way in which multicast
> messages are dropped when necessary could be improved upon, e.g. looking
> at ttl, priority, settled state etc when decide what to drop).
>
Same question here, supposing we have some concrete ideas about what we
could do.
I also don't fully understand why the option controlling whether this is an
error was removed entirely, rather than changing the default value of that
option. Maybe that's right, but it has a premise in it - that no one will
want this behavior - that I don't think we established in this discussion.
Re: Proposed Feature Removal from Dispatch Router
Posted by Robbie Gemmell <ro...@gmail.com>.
On 17 April 2018 at 17:10, Gordon Sim <gs...@redhat.com> wrote:
> On 17/04/18 14:24, Ken Giusti wrote:
>>
>> After thinking about the comments on this thread and
>> spending some time researching various "reliable multicast" solutions
>> I've come to the conclusion that we *should* allow multicasting
>> unsettled messages by having the ingress router provide the settlement.
>>
>> So I vote for Ted's proposal to back out the feature.
>
>
> I certainly don't think the router should be trying to implement reliable
> multicast.
>
> The original goal for the feature in question, as described in Ted's post,
> was to /inform users/ that a naive assumption about settlement was not
> accurate (and could not be accurate).
>
> I think Ted is right that the feature did not reach that goal. It is not
> sufficiently clear what is going on and on balance doesn't I think justify
> the potential annoyance.
>
Agreed. The actual functional behaviour of the multicast feature
doesnt really change depending on whether the messages are allowed to
be unsettled or not, the main thing that really does is the annoyance
level of the users trying to use multicast addresses.
> However I do think that some other solution to the problem of informing
> users would be worthwhile. This could be a warning in the log the first time
> a link sends an unsettled message to a multicast address (along with a
> section in the doc that clarifies the way things work).
That could get rather chatty over time if you have lots of addresses
or links (regardless on whether you mean per-link, per-address, or
both).
I definitely think it needs clearly documented, but I'm not personally
convinved it needs logged. I also wouldnt say it was a warning if it
were, as I dont actually think sending an unsettled message to the
address is a problem in itself.
>
> (As a separate issue, I do also think that the way in which multicast
> messages are dropped when necessary could be improved upon, e.g. looking at
> ttl, priority, settled state etc when decide what to drop).
>
>
>
> ---------------------------------------------------------------------
> 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: Proposed Feature Removal from Dispatch Router
Posted by Gordon Sim <gs...@redhat.com>.
On 17/04/18 14:24, Ken Giusti wrote:
> After thinking about the comments on this thread and
> spending some time researching various "reliable multicast" solutions
> I've come to the conclusion that we *should* allow multicasting
> unsettled messages by having the ingress router provide the settlement.
>
> So I vote for Ted's proposal to back out the feature.
I certainly don't think the router should be trying to implement
reliable multicast.
The original goal for the feature in question, as described in Ted's
post, was to /inform users/ that a naive assumption about settlement was
not accurate (and could not be accurate).
I think Ted is right that the feature did not reach that goal. It is not
sufficiently clear what is going on and on balance doesn't I think
justify the potential annoyance.
However I do think that some other solution to the problem of informing
users would be worthwhile. This could be a warning in the log the first
time a link sends an unsettled message to a multicast address (along
with a section in the doc that clarifies the way things work).
(As a separate issue, I do also think that the way in which multicast
messages are dropped when necessary could be improved upon, e.g. looking
at ttl, priority, settled state etc when decide what to drop).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Proposed Feature Removal from Dispatch Router
Posted by Ken Giusti <kg...@redhat.com>.
Apologies for thread-jacking Ted's original email thread.
After thinking about the comments on this thread and
spending some time researching various "reliable multicast" solutions
I've come to the conclusion that we *should* allow multicasting
unsettled messages by having the ingress router provide the settlement.
So I vote for Ted's proposal to back out the feature.
Reasoning:
1) From my brief research on existing 'reliable multicast' in the IP space
I think there's way too much complexity and state involved [0].
2) Having the ingress router settle the delivery locally is equivalent
to the way a traditional broker-based messaging bus handles multicast -
minus the store functionality of course.
In the broker's case a settlement merely indicates that the message bus has
taken ownership of the message. Local settlement by the ingress router means
the same thing.
[0] https://www.cisco.com/c/en/us/about/press/internet-protocol-journal/back-issues/table-contents-19/reliable-multicast.html
On Thu, Apr 12, 2018 at 6:20 PM, Ted Ross <tr...@redhat.com> wrote:
> We added a feature back in 1.0.0 to reject unsettled deliveries to
> multicast addresses by default. This can be disabled through
> configuration but is on by default.
>
> The rationale was that the router would accept and settle unsettled
> multicasts even though it might not have delivered the messages to any
> consumer. The rejection with error code was intended to inform users
> that they should pre-settle deliveries to multicast addresses in
> keeping with the best-effort nature of multicast routing.
>
> In practice, this is more of an annoyance because none of the example
> clients (and apparently the users' clients) actually do anything with
> the error code in the rejected delivery. The router appears to
> silently drop such messages for no good reason and good will is wasted
> in chasing down the issue to "oh, you should turn off this handy
> feature".
>
> The recently raised https://issues.apache.org/jira/browse/DISPATCH-966
> is caused by this feature as well. This is because the router can
> stream large messages in multiple transfers. The first transfer is
> used for routing and the last transfer should be used to determine the
> settlement status of the delivery. It is not a trivial fix to make
> this work correctly.
>
> For the above two reasons, I propose that we back out this feature and
> allow multicasting with unsettled deliveries. We should add a clear
> note in the documentation that states that multicast is best-effort,
> regardless of the settlement status of the deliveries.
>
> Any objections from the users?
>
> -Ted
>
> ---------------------------------------------------------------------
> 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: Proposed Feature Removal from Dispatch Router
Posted by Gordon Sim <gs...@redhat.com>.
On 16/04/18 17:39, Ken Giusti wrote:
> On Mon, Apr 16, 2018 at 12:11 PM, Alan Conway <ac...@redhat.com> wrote:
>> On Mon, Apr 16, 2018 at 11:00 AM, Ken Giusti <kg...@redhat.com> wrote:
>>
>>> Yeah, exactly.
>>>
>>> It's as if you applied a priority to each disposition in the following
>>> order (highest first):
>>> REJECTED
>>> ACCEPTED
>>> MODIFIED
>>> RELEASED
>>>
>>> The router returns the highest priority disposition from all
>>> consumer's returned dispositions.
>>>
>>>
>> What if some consumer never returns a disposition?
>
> Right - or classic 'slow consumer'. Without some sort of timeout
> mechanism the transfer would stall indefinitely.
> But doesn't the same apply for unicast?
With multicast, all the messages go to all receivers, so a slow consumer
will stall *all* transfers which eventually will prevent other consumers
getting any more messages.
One use of multicast is for a pub-sub style communication pattern where
you want the publishers and subscribers to be decoupled. Allowing one
subscriber to bring message flow to a halt for publishers and all other
subscribers might not be desirable in those cases.
> In the oslo.messaging driver, all message operations have a timeout
> and TTL. In that
> case the sender would abort and drop the link. Will any application
> expect to wait forever?
> Hold on - I meant to say "any well designed application" ;)
>
>
>> What if all consumers never return a disposition?
>
> Same deal.
>
>> What if there are no consumers?
>
> We have that now - credit is never granted and a sender can block indefinitely.
That is how anycast works now (if you already have credit then the
messages are released). I don't think there is any credit propagation
for multicast at present is there?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Proposed Feature Removal from Dispatch Router
Posted by Robbie Gemmell <ro...@gmail.com>.
On 16 April 2018 at 19:24, Ken Giusti <kg...@redhat.com> wrote:
> On Mon, Apr 16, 2018 at 1:06 PM, Alan Conway <ac...@redhat.com> wrote:
>> On Mon, Apr 16, 2018 at 12:39 PM, Ken Giusti <kg...@redhat.com> wrote:
>>
>>> On Mon, Apr 16, 2018 at 12:11 PM, Alan Conway <ac...@redhat.com> wrote:
>>> > On Mon, Apr 16, 2018 at 11:00 AM, Ken Giusti <kg...@redhat.com> wrote:
>>> >
>>> >> Yeah, exactly.
>>> >>
>>> >> It's as if you applied a priority to each disposition in the following
>>> >> order (highest first):
>>> >> REJECTED
>>> >> ACCEPTED
>>> >> MODIFIED
>>> >> RELEASED
>>> >>
>>> >> The router returns the highest priority disposition from all
>>> >> consumer's returned dispositions.
>>> >>
>>> >>
>>> > What if some consumer never returns a disposition?
>>>
>>> Right - or classic 'slow consumer'. Without some sort of timeout
>>> mechanism the transfer would stall indefinitely.
>>> But doesn't the same apply for unicast?
>>>
>>> In the oslo.messaging driver, all message operations have a timeout
>>> and TTL. In that
>>> case the sender would abort and drop the link. Will any application
>>> expect to wait forever?
>>> Hold on - I meant to say "any well designed application" ;)
>>>
>>>
>>> > What if all consumers never return a disposition?
>>>
>>> Same deal.
>>>
>>> > What if there are no consumers?
>>>
>>> We have that now - credit is never granted and a sender can block
>>> indefinitely.
>>>
>>
>> What is the use case for this? If I cared about the disposition of a
>> message for multiple receivers, I'd send it on multiple unicast addresses
>> so I know what happened on each one. If I didn't care, I'd send multicast
>> and pre-settled and genuinely not care.
>
> You and I both.
>
> But the original question I posited is
>
> "what does a user/app expect if they send multicast unsettled?"
>
> I'm trying to understand what people expect to happen when they do this.
>
> Right now we provide two solutions, one to explicitly fail unless they
> set the "no, I know what I'm doing" switch.
> In that case, we settle it locally, which is a subtle fake that may
> lead to unanticipated behaviors.
>
>> Multicast is very useful when some
>> unknown number of receivers, possibly zero, can subscribe based on interest
>> - but the sender doesn't know or care how many there are. What's the use
>> case where the sender must know that the message was received by somebody
>> but doesn't care who or how many?
>
> I can't see one honestly. If no one else does then the correct
> behavior should always
> be REJECT, since anything else is undefined.
>
One thing it lets you know is that it actually reached and was
processed by a router. It also means you dont have to explicitly
reconfigure your clients behaviour to use presettled or not unless you
want to. E.g imagine you want to drop routers in front of/inbetween
some clients or brokers, where you were previously using unsettled
messages against a single broker, it might be nice not to have to
recongiure the clients.
...and now I've actually read your next mail I think I'm partially
repeating what you said, oh well :)
Robbie
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Proposed Feature Removal from Dispatch Router
Posted by Ken Giusti <kg...@redhat.com>.
On Mon, Apr 16, 2018 at 1:06 PM, Alan Conway <ac...@redhat.com> wrote:
> On Mon, Apr 16, 2018 at 12:39 PM, Ken Giusti <kg...@redhat.com> wrote:
>
>> On Mon, Apr 16, 2018 at 12:11 PM, Alan Conway <ac...@redhat.com> wrote:
>> > On Mon, Apr 16, 2018 at 11:00 AM, Ken Giusti <kg...@redhat.com> wrote:
>> >
>> >> Yeah, exactly.
>> >>
>> >> It's as if you applied a priority to each disposition in the following
>> >> order (highest first):
>> >> REJECTED
>> >> ACCEPTED
>> >> MODIFIED
>> >> RELEASED
>> >>
>> >> The router returns the highest priority disposition from all
>> >> consumer's returned dispositions.
>> >>
>> >>
>> > What if some consumer never returns a disposition?
>>
>> Right - or classic 'slow consumer'. Without some sort of timeout
>> mechanism the transfer would stall indefinitely.
>> But doesn't the same apply for unicast?
>>
>> In the oslo.messaging driver, all message operations have a timeout
>> and TTL. In that
>> case the sender would abort and drop the link. Will any application
>> expect to wait forever?
>> Hold on - I meant to say "any well designed application" ;)
>>
>>
>> > What if all consumers never return a disposition?
>>
>> Same deal.
>>
>> > What if there are no consumers?
>>
>> We have that now - credit is never granted and a sender can block
>> indefinitely.
>>
>
> What is the use case for this? If I cared about the disposition of a
> message for multiple receivers, I'd send it on multiple unicast addresses
> so I know what happened on each one. If I didn't care, I'd send multicast
> and pre-settled and genuinely not care.
You and I both.
But the original question I posited is
"what does a user/app expect if they send multicast unsettled?"
I'm trying to understand what people expect to happen when they do this.
Right now we provide two solutions, one to explicitly fail unless they
set the "no, I know what I'm doing" switch.
In that case, we settle it locally, which is a subtle fake that may
lead to unanticipated behaviors.
> Multicast is very useful when some
> unknown number of receivers, possibly zero, can subscribe based on interest
> - but the sender doesn't know or care how many there are. What's the use
> case where the sender must know that the message was received by somebody
> but doesn't care who or how many?
I can't see one honestly. If no one else does then the correct
behavior should always
be REJECT, since anything else is undefined.
--
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Proposed Feature Removal from Dispatch Router
Posted by Alan Conway <ac...@redhat.com>.
On Mon, Apr 16, 2018 at 12:39 PM, Ken Giusti <kg...@redhat.com> wrote:
> On Mon, Apr 16, 2018 at 12:11 PM, Alan Conway <ac...@redhat.com> wrote:
> > On Mon, Apr 16, 2018 at 11:00 AM, Ken Giusti <kg...@redhat.com> wrote:
> >
> >> Yeah, exactly.
> >>
> >> It's as if you applied a priority to each disposition in the following
> >> order (highest first):
> >> REJECTED
> >> ACCEPTED
> >> MODIFIED
> >> RELEASED
> >>
> >> The router returns the highest priority disposition from all
> >> consumer's returned dispositions.
> >>
> >>
> > What if some consumer never returns a disposition?
>
> Right - or classic 'slow consumer'. Without some sort of timeout
> mechanism the transfer would stall indefinitely.
> But doesn't the same apply for unicast?
>
> In the oslo.messaging driver, all message operations have a timeout
> and TTL. In that
> case the sender would abort and drop the link. Will any application
> expect to wait forever?
> Hold on - I meant to say "any well designed application" ;)
>
>
> > What if all consumers never return a disposition?
>
> Same deal.
>
> > What if there are no consumers?
>
> We have that now - credit is never granted and a sender can block
> indefinitely.
>
What is the use case for this? If I cared about the disposition of a
message for multiple receivers, I'd send it on multiple unicast addresses
so I know what happened on each one. If I didn't care, I'd send multicast
and pre-settled and genuinely not care. Multicast is very useful when some
unknown number of receivers, possibly zero, can subscribe based on interest
- but the sender doesn't know or care how many there are. What's the use
case where the sender must know that the message was received by somebody
but doesn't care who or how many?
Re: Proposed Feature Removal from Dispatch Router
Posted by Ken Giusti <kg...@redhat.com>.
On Mon, Apr 16, 2018 at 12:11 PM, Alan Conway <ac...@redhat.com> wrote:
> On Mon, Apr 16, 2018 at 11:00 AM, Ken Giusti <kg...@redhat.com> wrote:
>
>> Yeah, exactly.
>>
>> It's as if you applied a priority to each disposition in the following
>> order (highest first):
>> REJECTED
>> ACCEPTED
>> MODIFIED
>> RELEASED
>>
>> The router returns the highest priority disposition from all
>> consumer's returned dispositions.
>>
>>
> What if some consumer never returns a disposition?
Right - or classic 'slow consumer'. Without some sort of timeout
mechanism the transfer would stall indefinitely.
But doesn't the same apply for unicast?
In the oslo.messaging driver, all message operations have a timeout
and TTL. In that
case the sender would abort and drop the link. Will any application
expect to wait forever?
Hold on - I meant to say "any well designed application" ;)
> What if all consumers never return a disposition?
Same deal.
> What if there are no consumers?
We have that now - credit is never granted and a sender can block indefinitely.
>
>
>
>>
>>
>> -K
>>
>>
>> On Mon, Apr 16, 2018 at 10:51 AM, Michael Goulish <mg...@redhat.com>
>> wrote:
>> > You mean your rules to be applied exclusively, and in that order, right?
>> > i.e.
>> >
>> > if ( anybody rejected )
>> > {
>> > disposition = rejected
>> > }
>> > *else*
>> > if ( anybody accepted )
>> > {
>> > disposition = accepted
>> > }
>> >
>> >
>> >
>> >
>> > On Mon, Apr 16, 2018 at 10:24 AM, Ken Giusti <kg...@redhat.com> wrote:
>> >
>> >> To reply to my own question:
>> >>
>> >> IMHO when sending an unsettled multicast I would expect
>> >> 1) that all present consumers will get a copy of the message and:
>> >> 2) that any potential consumers that are *not* present would not get a
>> >> copy of the message (right, that's a no-brainer, but hear me out).
>> >> 3) if any consumer signals a REJECT
>> >>
>> >> So I would like the router to:
>> >>
>> >> 1) send back a final disposition of REJECT if *any* client returned a
>> >> REJECT.
>> >> The spec is pretty clear that the message is considered invalid by the
>> >> recipient
>> >> in this case. That's a pretty big deal, since I assumed that the
>> message
>> >> is
>> >> not invalid when it was sent. This could possibly indicate a bug or a
>> >> state
>> >> mismatch between sender and receiver. I would want to know about this.
>> >>
>> >> 2) send back a final disposition of ACCEPTED if at least one client
>> >> ACCEPTED. Ignore MODIFIED and RELEASED in this case, since
>> >> 2a) RELEASED indicates we can resend safely, which we cannot
>> >> (someone ACCEPTED)
>> >> 2b) MODIFIED is in doubt, also cannot resend safely and I feel can
>> >> be considered as an equivalent case as #2 above
>> >>
>> >> 3) Otherwise for a mix of MODIFIED and RELEASED return MODIFIED as we
>> >> cannot re-send the same message.
>> >> 4) else all RELEASED, so return RELEASED.
>> >>
>> >>
>> >>
>> >> Again, this is MHO and I only present it as a strawman for
>> >> consideration and discussion. I'm not convinced holding state in the
>> >> router while it waits
>> >> for all consumers to reply is practical (or desired in the slow consumer
>> >> case).
>> >>
>> >>
>> >> -K
>> >>
>> >> On Mon, Apr 16, 2018 at 9:49 AM, Ken Giusti <kg...@redhat.com> wrote:
>> >> > We really should try to do something smarter in the case of unsettled
>> >> > multicast rather than either of the current approaches.
>> >> >
>> >> > What does an application/dev expect when it sends any message
>> >> > unsettled? It expects to block until eventually it gets some
>> >> > indication of whether or not the message was delivered as intended.
>> >> > In the case of single consumer the expectation is obvious and well
>> >> > handled by the router.
>> >> >
>> >> > But in the case of multicast it is a different story: here we have the
>> >> > possibility that the message may be both consumed by one recipient and
>> >> > rejected by another. So the question is: from the POV of the dev/app,
>> >> > what is the "obvious" default action the router should perform in that
>> >> > case?
>> >> >
>> >> > -K
>> >> >
>> >> >
>> >> > On Fri, Apr 13, 2018 at 3:38 PM, Chuck Rolke <cr...@redhat.com>
>> wrote:
>> >> >> I would prefer to keep the feature enforced as it is now. I was one
>> who
>> >> >> was surprised to have a sender whose message is settled by the router
>> >> >> only to find out that it was not delivered anywhere.
>> >> >>
>> >> >> The document https://qpid.apache.org/releases/qpid-dispatch-1.0.0/
>> >> book/book.html#routing-patterns
>> >> >> needs to have a clearer explanation of the lossy nature of multicast
>> >> >> distribution.
>> >> >>
>> >> >> ----- Original Message -----
>> >> >>> From: "Ted Ross" <tr...@redhat.com>
>> >> >>> To: users@qpid.apache.org
>> >> >>> Sent: Thursday, April 12, 2018 6:26:34 PM
>> >> >>> Subject: Re: Proposed Feature Removal from Dispatch Router
>> >> >>>
>> >> >>> For the record, here is the Jira for the feature in question:
>> >> >>>
>> >> >>> https://issues.apache.org/jira/browse/DISPATCH-744
>> >> >>>
>> >> >>> On Thu, Apr 12, 2018 at 6:20 PM, Ted Ross <tr...@redhat.com> wrote:
>> >> >>> > We added a feature back in 1.0.0 to reject unsettled deliveries to
>> >> >>> > multicast addresses by default. This can be disabled through
>> >> >>> > configuration but is on by default.
>> >> >>> >
>> >> >>> > The rationale was that the router would accept and settle
>> unsettled
>> >> >>> > multicasts even though it might not have delivered the messages to
>> >> any
>> >> >>> > consumer. The rejection with error code was intended to inform
>> users
>> >> >>> > that they should pre-settle deliveries to multicast addresses in
>> >> >>> > keeping with the best-effort nature of multicast routing.
>> >> >>> >
>> >> >>> > In practice, this is more of an annoyance because none of the
>> example
>> >> >>> > clients (and apparently the users' clients) actually do anything
>> with
>> >> >>> > the error code in the rejected delivery. The router appears to
>> >> >>> > silently drop such messages for no good reason and good will is
>> >> wasted
>> >> >>> > in chasing down the issue to "oh, you should turn off this handy
>> >> >>> > feature".
>> >> >>> >
>> >> >>> > The recently raised https://issues.apache.org/
>> >> jira/browse/DISPATCH-966
>> >> >>> > is caused by this feature as well. This is because the router can
>> >> >>> > stream large messages in multiple transfers. The first transfer
>> is
>> >> >>> > used for routing and the last transfer should be used to determine
>> >> the
>> >> >>> > settlement status of the delivery. It is not a trivial fix to
>> make
>> >> >>> > this work correctly.
>> >> >>> >
>> >> >>> > For the above two reasons, I propose that we back out this feature
>> >> and
>> >> >>> > allow multicasting with unsettled deliveries. We should add a
>> clear
>> >> >>> > note in the documentation that states that multicast is
>> best-effort,
>> >> >>> > regardless of the settlement status of the deliveries.
>> >> >>> >
>> >> >>> > Any objections from the users?
>> >> >>> >
>> >> >>> > -Ted
>> >> >>>
>> >> >>> ------------------------------------------------------------
>> ---------
>> >> >>> 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
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > -K
>> >>
>> >>
>> >>
>> >> --
>> >> -K
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Proposed Feature Removal from Dispatch Router
Posted by Alan Conway <ac...@redhat.com>.
On Mon, Apr 16, 2018 at 11:00 AM, Ken Giusti <kg...@redhat.com> wrote:
> Yeah, exactly.
>
> It's as if you applied a priority to each disposition in the following
> order (highest first):
> REJECTED
> ACCEPTED
> MODIFIED
> RELEASED
>
> The router returns the highest priority disposition from all
> consumer's returned dispositions.
>
>
What if some consumer never returns a disposition?
What if all consumers never return a disposition?
What if there are no consumers?
>
>
> -K
>
>
> On Mon, Apr 16, 2018 at 10:51 AM, Michael Goulish <mg...@redhat.com>
> wrote:
> > You mean your rules to be applied exclusively, and in that order, right?
> > i.e.
> >
> > if ( anybody rejected )
> > {
> > disposition = rejected
> > }
> > *else*
> > if ( anybody accepted )
> > {
> > disposition = accepted
> > }
> >
> >
> >
> >
> > On Mon, Apr 16, 2018 at 10:24 AM, Ken Giusti <kg...@redhat.com> wrote:
> >
> >> To reply to my own question:
> >>
> >> IMHO when sending an unsettled multicast I would expect
> >> 1) that all present consumers will get a copy of the message and:
> >> 2) that any potential consumers that are *not* present would not get a
> >> copy of the message (right, that's a no-brainer, but hear me out).
> >> 3) if any consumer signals a REJECT
> >>
> >> So I would like the router to:
> >>
> >> 1) send back a final disposition of REJECT if *any* client returned a
> >> REJECT.
> >> The spec is pretty clear that the message is considered invalid by the
> >> recipient
> >> in this case. That's a pretty big deal, since I assumed that the
> message
> >> is
> >> not invalid when it was sent. This could possibly indicate a bug or a
> >> state
> >> mismatch between sender and receiver. I would want to know about this.
> >>
> >> 2) send back a final disposition of ACCEPTED if at least one client
> >> ACCEPTED. Ignore MODIFIED and RELEASED in this case, since
> >> 2a) RELEASED indicates we can resend safely, which we cannot
> >> (someone ACCEPTED)
> >> 2b) MODIFIED is in doubt, also cannot resend safely and I feel can
> >> be considered as an equivalent case as #2 above
> >>
> >> 3) Otherwise for a mix of MODIFIED and RELEASED return MODIFIED as we
> >> cannot re-send the same message.
> >> 4) else all RELEASED, so return RELEASED.
> >>
> >>
> >>
> >> Again, this is MHO and I only present it as a strawman for
> >> consideration and discussion. I'm not convinced holding state in the
> >> router while it waits
> >> for all consumers to reply is practical (or desired in the slow consumer
> >> case).
> >>
> >>
> >> -K
> >>
> >> On Mon, Apr 16, 2018 at 9:49 AM, Ken Giusti <kg...@redhat.com> wrote:
> >> > We really should try to do something smarter in the case of unsettled
> >> > multicast rather than either of the current approaches.
> >> >
> >> > What does an application/dev expect when it sends any message
> >> > unsettled? It expects to block until eventually it gets some
> >> > indication of whether or not the message was delivered as intended.
> >> > In the case of single consumer the expectation is obvious and well
> >> > handled by the router.
> >> >
> >> > But in the case of multicast it is a different story: here we have the
> >> > possibility that the message may be both consumed by one recipient and
> >> > rejected by another. So the question is: from the POV of the dev/app,
> >> > what is the "obvious" default action the router should perform in that
> >> > case?
> >> >
> >> > -K
> >> >
> >> >
> >> > On Fri, Apr 13, 2018 at 3:38 PM, Chuck Rolke <cr...@redhat.com>
> wrote:
> >> >> I would prefer to keep the feature enforced as it is now. I was one
> who
> >> >> was surprised to have a sender whose message is settled by the router
> >> >> only to find out that it was not delivered anywhere.
> >> >>
> >> >> The document https://qpid.apache.org/releases/qpid-dispatch-1.0.0/
> >> book/book.html#routing-patterns
> >> >> needs to have a clearer explanation of the lossy nature of multicast
> >> >> distribution.
> >> >>
> >> >> ----- Original Message -----
> >> >>> From: "Ted Ross" <tr...@redhat.com>
> >> >>> To: users@qpid.apache.org
> >> >>> Sent: Thursday, April 12, 2018 6:26:34 PM
> >> >>> Subject: Re: Proposed Feature Removal from Dispatch Router
> >> >>>
> >> >>> For the record, here is the Jira for the feature in question:
> >> >>>
> >> >>> https://issues.apache.org/jira/browse/DISPATCH-744
> >> >>>
> >> >>> On Thu, Apr 12, 2018 at 6:20 PM, Ted Ross <tr...@redhat.com> wrote:
> >> >>> > We added a feature back in 1.0.0 to reject unsettled deliveries to
> >> >>> > multicast addresses by default. This can be disabled through
> >> >>> > configuration but is on by default.
> >> >>> >
> >> >>> > The rationale was that the router would accept and settle
> unsettled
> >> >>> > multicasts even though it might not have delivered the messages to
> >> any
> >> >>> > consumer. The rejection with error code was intended to inform
> users
> >> >>> > that they should pre-settle deliveries to multicast addresses in
> >> >>> > keeping with the best-effort nature of multicast routing.
> >> >>> >
> >> >>> > In practice, this is more of an annoyance because none of the
> example
> >> >>> > clients (and apparently the users' clients) actually do anything
> with
> >> >>> > the error code in the rejected delivery. The router appears to
> >> >>> > silently drop such messages for no good reason and good will is
> >> wasted
> >> >>> > in chasing down the issue to "oh, you should turn off this handy
> >> >>> > feature".
> >> >>> >
> >> >>> > The recently raised https://issues.apache.org/
> >> jira/browse/DISPATCH-966
> >> >>> > is caused by this feature as well. This is because the router can
> >> >>> > stream large messages in multiple transfers. The first transfer
> is
> >> >>> > used for routing and the last transfer should be used to determine
> >> the
> >> >>> > settlement status of the delivery. It is not a trivial fix to
> make
> >> >>> > this work correctly.
> >> >>> >
> >> >>> > For the above two reasons, I propose that we back out this feature
> >> and
> >> >>> > allow multicasting with unsettled deliveries. We should add a
> clear
> >> >>> > note in the documentation that states that multicast is
> best-effort,
> >> >>> > regardless of the settlement status of the deliveries.
> >> >>> >
> >> >>> > Any objections from the users?
> >> >>> >
> >> >>> > -Ted
> >> >>>
> >> >>> ------------------------------------------------------------
> ---------
> >> >>> 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
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > -K
> >>
> >>
> >>
> >> --
> >> -K
> >>
> >> ---------------------------------------------------------------------
> >> 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: Proposed Feature Removal from Dispatch Router
Posted by Ken Giusti <kg...@redhat.com>.
Yeah, exactly.
It's as if you applied a priority to each disposition in the following
order (highest first):
REJECTED
ACCEPTED
MODIFIED
RELEASED
The router returns the highest priority disposition from all
consumer's returned dispositions.
-K
On Mon, Apr 16, 2018 at 10:51 AM, Michael Goulish <mg...@redhat.com> wrote:
> You mean your rules to be applied exclusively, and in that order, right?
> i.e.
>
> if ( anybody rejected )
> {
> disposition = rejected
> }
> *else*
> if ( anybody accepted )
> {
> disposition = accepted
> }
>
>
>
>
> On Mon, Apr 16, 2018 at 10:24 AM, Ken Giusti <kg...@redhat.com> wrote:
>
>> To reply to my own question:
>>
>> IMHO when sending an unsettled multicast I would expect
>> 1) that all present consumers will get a copy of the message and:
>> 2) that any potential consumers that are *not* present would not get a
>> copy of the message (right, that's a no-brainer, but hear me out).
>> 3) if any consumer signals a REJECT
>>
>> So I would like the router to:
>>
>> 1) send back a final disposition of REJECT if *any* client returned a
>> REJECT.
>> The spec is pretty clear that the message is considered invalid by the
>> recipient
>> in this case. That's a pretty big deal, since I assumed that the message
>> is
>> not invalid when it was sent. This could possibly indicate a bug or a
>> state
>> mismatch between sender and receiver. I would want to know about this.
>>
>> 2) send back a final disposition of ACCEPTED if at least one client
>> ACCEPTED. Ignore MODIFIED and RELEASED in this case, since
>> 2a) RELEASED indicates we can resend safely, which we cannot
>> (someone ACCEPTED)
>> 2b) MODIFIED is in doubt, also cannot resend safely and I feel can
>> be considered as an equivalent case as #2 above
>>
>> 3) Otherwise for a mix of MODIFIED and RELEASED return MODIFIED as we
>> cannot re-send the same message.
>> 4) else all RELEASED, so return RELEASED.
>>
>>
>>
>> Again, this is MHO and I only present it as a strawman for
>> consideration and discussion. I'm not convinced holding state in the
>> router while it waits
>> for all consumers to reply is practical (or desired in the slow consumer
>> case).
>>
>>
>> -K
>>
>> On Mon, Apr 16, 2018 at 9:49 AM, Ken Giusti <kg...@redhat.com> wrote:
>> > We really should try to do something smarter in the case of unsettled
>> > multicast rather than either of the current approaches.
>> >
>> > What does an application/dev expect when it sends any message
>> > unsettled? It expects to block until eventually it gets some
>> > indication of whether or not the message was delivered as intended.
>> > In the case of single consumer the expectation is obvious and well
>> > handled by the router.
>> >
>> > But in the case of multicast it is a different story: here we have the
>> > possibility that the message may be both consumed by one recipient and
>> > rejected by another. So the question is: from the POV of the dev/app,
>> > what is the "obvious" default action the router should perform in that
>> > case?
>> >
>> > -K
>> >
>> >
>> > On Fri, Apr 13, 2018 at 3:38 PM, Chuck Rolke <cr...@redhat.com> wrote:
>> >> I would prefer to keep the feature enforced as it is now. I was one who
>> >> was surprised to have a sender whose message is settled by the router
>> >> only to find out that it was not delivered anywhere.
>> >>
>> >> The document https://qpid.apache.org/releases/qpid-dispatch-1.0.0/
>> book/book.html#routing-patterns
>> >> needs to have a clearer explanation of the lossy nature of multicast
>> >> distribution.
>> >>
>> >> ----- Original Message -----
>> >>> From: "Ted Ross" <tr...@redhat.com>
>> >>> To: users@qpid.apache.org
>> >>> Sent: Thursday, April 12, 2018 6:26:34 PM
>> >>> Subject: Re: Proposed Feature Removal from Dispatch Router
>> >>>
>> >>> For the record, here is the Jira for the feature in question:
>> >>>
>> >>> https://issues.apache.org/jira/browse/DISPATCH-744
>> >>>
>> >>> On Thu, Apr 12, 2018 at 6:20 PM, Ted Ross <tr...@redhat.com> wrote:
>> >>> > We added a feature back in 1.0.0 to reject unsettled deliveries to
>> >>> > multicast addresses by default. This can be disabled through
>> >>> > configuration but is on by default.
>> >>> >
>> >>> > The rationale was that the router would accept and settle unsettled
>> >>> > multicasts even though it might not have delivered the messages to
>> any
>> >>> > consumer. The rejection with error code was intended to inform users
>> >>> > that they should pre-settle deliveries to multicast addresses in
>> >>> > keeping with the best-effort nature of multicast routing.
>> >>> >
>> >>> > In practice, this is more of an annoyance because none of the example
>> >>> > clients (and apparently the users' clients) actually do anything with
>> >>> > the error code in the rejected delivery. The router appears to
>> >>> > silently drop such messages for no good reason and good will is
>> wasted
>> >>> > in chasing down the issue to "oh, you should turn off this handy
>> >>> > feature".
>> >>> >
>> >>> > The recently raised https://issues.apache.org/
>> jira/browse/DISPATCH-966
>> >>> > is caused by this feature as well. This is because the router can
>> >>> > stream large messages in multiple transfers. The first transfer is
>> >>> > used for routing and the last transfer should be used to determine
>> the
>> >>> > settlement status of the delivery. It is not a trivial fix to make
>> >>> > this work correctly.
>> >>> >
>> >>> > For the above two reasons, I propose that we back out this feature
>> and
>> >>> > allow multicasting with unsettled deliveries. We should add a clear
>> >>> > note in the documentation that states that multicast is best-effort,
>> >>> > regardless of the settlement status of the deliveries.
>> >>> >
>> >>> > Any objections from the users?
>> >>> >
>> >>> > -Ted
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> 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
>> >>
>> >
>> >
>> >
>> > --
>> > -K
>>
>>
>>
>> --
>> -K
>>
>> ---------------------------------------------------------------------
>> 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: Proposed Feature Removal from Dispatch Router
Posted by Michael Goulish <mg...@redhat.com>.
You mean your rules to be applied exclusively, and in that order, right?
i.e.
if ( anybody rejected )
{
disposition = rejected
}
*else*
if ( anybody accepted )
{
disposition = accepted
}
On Mon, Apr 16, 2018 at 10:24 AM, Ken Giusti <kg...@redhat.com> wrote:
> To reply to my own question:
>
> IMHO when sending an unsettled multicast I would expect
> 1) that all present consumers will get a copy of the message and:
> 2) that any potential consumers that are *not* present would not get a
> copy of the message (right, that's a no-brainer, but hear me out).
> 3) if any consumer signals a REJECT
>
> So I would like the router to:
>
> 1) send back a final disposition of REJECT if *any* client returned a
> REJECT.
> The spec is pretty clear that the message is considered invalid by the
> recipient
> in this case. That's a pretty big deal, since I assumed that the message
> is
> not invalid when it was sent. This could possibly indicate a bug or a
> state
> mismatch between sender and receiver. I would want to know about this.
>
> 2) send back a final disposition of ACCEPTED if at least one client
> ACCEPTED. Ignore MODIFIED and RELEASED in this case, since
> 2a) RELEASED indicates we can resend safely, which we cannot
> (someone ACCEPTED)
> 2b) MODIFIED is in doubt, also cannot resend safely and I feel can
> be considered as an equivalent case as #2 above
>
> 3) Otherwise for a mix of MODIFIED and RELEASED return MODIFIED as we
> cannot re-send the same message.
> 4) else all RELEASED, so return RELEASED.
>
>
>
> Again, this is MHO and I only present it as a strawman for
> consideration and discussion. I'm not convinced holding state in the
> router while it waits
> for all consumers to reply is practical (or desired in the slow consumer
> case).
>
>
> -K
>
> On Mon, Apr 16, 2018 at 9:49 AM, Ken Giusti <kg...@redhat.com> wrote:
> > We really should try to do something smarter in the case of unsettled
> > multicast rather than either of the current approaches.
> >
> > What does an application/dev expect when it sends any message
> > unsettled? It expects to block until eventually it gets some
> > indication of whether or not the message was delivered as intended.
> > In the case of single consumer the expectation is obvious and well
> > handled by the router.
> >
> > But in the case of multicast it is a different story: here we have the
> > possibility that the message may be both consumed by one recipient and
> > rejected by another. So the question is: from the POV of the dev/app,
> > what is the "obvious" default action the router should perform in that
> > case?
> >
> > -K
> >
> >
> > On Fri, Apr 13, 2018 at 3:38 PM, Chuck Rolke <cr...@redhat.com> wrote:
> >> I would prefer to keep the feature enforced as it is now. I was one who
> >> was surprised to have a sender whose message is settled by the router
> >> only to find out that it was not delivered anywhere.
> >>
> >> The document https://qpid.apache.org/releases/qpid-dispatch-1.0.0/
> book/book.html#routing-patterns
> >> needs to have a clearer explanation of the lossy nature of multicast
> >> distribution.
> >>
> >> ----- Original Message -----
> >>> From: "Ted Ross" <tr...@redhat.com>
> >>> To: users@qpid.apache.org
> >>> Sent: Thursday, April 12, 2018 6:26:34 PM
> >>> Subject: Re: Proposed Feature Removal from Dispatch Router
> >>>
> >>> For the record, here is the Jira for the feature in question:
> >>>
> >>> https://issues.apache.org/jira/browse/DISPATCH-744
> >>>
> >>> On Thu, Apr 12, 2018 at 6:20 PM, Ted Ross <tr...@redhat.com> wrote:
> >>> > We added a feature back in 1.0.0 to reject unsettled deliveries to
> >>> > multicast addresses by default. This can be disabled through
> >>> > configuration but is on by default.
> >>> >
> >>> > The rationale was that the router would accept and settle unsettled
> >>> > multicasts even though it might not have delivered the messages to
> any
> >>> > consumer. The rejection with error code was intended to inform users
> >>> > that they should pre-settle deliveries to multicast addresses in
> >>> > keeping with the best-effort nature of multicast routing.
> >>> >
> >>> > In practice, this is more of an annoyance because none of the example
> >>> > clients (and apparently the users' clients) actually do anything with
> >>> > the error code in the rejected delivery. The router appears to
> >>> > silently drop such messages for no good reason and good will is
> wasted
> >>> > in chasing down the issue to "oh, you should turn off this handy
> >>> > feature".
> >>> >
> >>> > The recently raised https://issues.apache.org/
> jira/browse/DISPATCH-966
> >>> > is caused by this feature as well. This is because the router can
> >>> > stream large messages in multiple transfers. The first transfer is
> >>> > used for routing and the last transfer should be used to determine
> the
> >>> > settlement status of the delivery. It is not a trivial fix to make
> >>> > this work correctly.
> >>> >
> >>> > For the above two reasons, I propose that we back out this feature
> and
> >>> > allow multicasting with unsettled deliveries. We should add a clear
> >>> > note in the documentation that states that multicast is best-effort,
> >>> > regardless of the settlement status of the deliveries.
> >>> >
> >>> > Any objections from the users?
> >>> >
> >>> > -Ted
> >>>
> >>> ---------------------------------------------------------------------
> >>> 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
> >>
> >
> >
> >
> > --
> > -K
>
>
>
> --
> -K
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Proposed Feature Removal from Dispatch Router
Posted by Alan Conway <ac...@redhat.com>.
On Mon, Apr 16, 2018 at 1:50 PM, Gordon Sim <gs...@redhat.com> wrote:
> On 16/04/18 15:24, Ken Giusti wrote:
>
>> To reply to my own question:
>>
>> IMHO when sending an unsettled multicast I would expect
>> 1) that all present consumers will get a copy of the message and:
>> 2) that any potential consumers that are *not* present would not get a
>> copy of the message (right, that's a no-brainer, but hear me out).
>> 3) if any consumer signals a REJECT
>>
>> So I would like the router to:
>>
>> 1) send back a final disposition of REJECT if *any* client returned a
>> REJECT.
>> The spec is pretty clear that the message is considered invalid by the
>> recipient
>> in this case. That's a pretty big deal, since I assumed that the
>> message is
>> not invalid when it was sent. This could possibly indicate a bug or a
>> state
>> mismatch between sender and receiver. I would want to know about this.
>>
>
> What if there are 10 consumers, and only one of them rejects it? Clearly
> there is a problem, but is it the sender that is best able to react to
> that? Perhaps the consumer that rejected it is at fault since all the other
> consumers considered the message valid.
>
> What if two of the consumer reject for different reasons (i.e. with
> different errors)?
>
> While I agree that the rejection is important information, I'm not sure
> that propagating it to the sender is the necessarily the most useful way of
> signalling this. Maybe some eventing scheme would actually be useful,
> allowing the system to configure where to direct the information so it can
> be acted upon. Failing that better control over logging of this sort of
> thing.
>
>
>
This is why I feel like multicast-with-settlement is not really a useful
feature. If you need to know what happens at the receivers then you need to
address them individually - we don't need a complicated scheme for trying
to jam multiple dispositions into one - the user needs to get multiple
dispositions via simple unicast addresses. If you need decoupled messaging
with store-forward delivery guarantees, then you need a broker. To me, the
only time router multicast is useful is when you don't care about
dispositions, and you want to send pre-settled messages on a best-effort
basis to an unknown (possibly empty) set of receivers.
Re: Proposed Feature Removal from Dispatch Router
Posted by Gordon Sim <gs...@redhat.com>.
On 16/04/18 15:24, Ken Giusti wrote:
> To reply to my own question:
>
> IMHO when sending an unsettled multicast I would expect
> 1) that all present consumers will get a copy of the message and:
> 2) that any potential consumers that are *not* present would not get a
> copy of the message (right, that's a no-brainer, but hear me out).
> 3) if any consumer signals a REJECT
>
> So I would like the router to:
>
> 1) send back a final disposition of REJECT if *any* client returned a REJECT.
> The spec is pretty clear that the message is considered invalid by the recipient
> in this case. That's a pretty big deal, since I assumed that the message is
> not invalid when it was sent. This could possibly indicate a bug or a state
> mismatch between sender and receiver. I would want to know about this.
What if there are 10 consumers, and only one of them rejects it? Clearly
there is a problem, but is it the sender that is best able to react to
that? Perhaps the consumer that rejected it is at fault since all the
other consumers considered the message valid.
What if two of the consumer reject for different reasons (i.e. with
different errors)?
While I agree that the rejection is important information, I'm not sure
that propagating it to the sender is the necessarily the most useful way
of signalling this. Maybe some eventing scheme would actually be useful,
allowing the system to configure where to direct the information so it
can be acted upon. Failing that better control over logging of this sort
of thing.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Proposed Feature Removal from Dispatch Router
Posted by Ken Giusti <kg...@redhat.com>.
To reply to my own question:
IMHO when sending an unsettled multicast I would expect
1) that all present consumers will get a copy of the message and:
2) that any potential consumers that are *not* present would not get a
copy of the message (right, that's a no-brainer, but hear me out).
3) if any consumer signals a REJECT
So I would like the router to:
1) send back a final disposition of REJECT if *any* client returned a REJECT.
The spec is pretty clear that the message is considered invalid by the recipient
in this case. That's a pretty big deal, since I assumed that the message is
not invalid when it was sent. This could possibly indicate a bug or a state
mismatch between sender and receiver. I would want to know about this.
2) send back a final disposition of ACCEPTED if at least one client
ACCEPTED. Ignore MODIFIED and RELEASED in this case, since
2a) RELEASED indicates we can resend safely, which we cannot
(someone ACCEPTED)
2b) MODIFIED is in doubt, also cannot resend safely and I feel can
be considered as an equivalent case as #2 above
3) Otherwise for a mix of MODIFIED and RELEASED return MODIFIED as we
cannot re-send the same message.
4) else all RELEASED, so return RELEASED.
Again, this is MHO and I only present it as a strawman for
consideration and discussion. I'm not convinced holding state in the
router while it waits
for all consumers to reply is practical (or desired in the slow consumer case).
-K
On Mon, Apr 16, 2018 at 9:49 AM, Ken Giusti <kg...@redhat.com> wrote:
> We really should try to do something smarter in the case of unsettled
> multicast rather than either of the current approaches.
>
> What does an application/dev expect when it sends any message
> unsettled? It expects to block until eventually it gets some
> indication of whether or not the message was delivered as intended.
> In the case of single consumer the expectation is obvious and well
> handled by the router.
>
> But in the case of multicast it is a different story: here we have the
> possibility that the message may be both consumed by one recipient and
> rejected by another. So the question is: from the POV of the dev/app,
> what is the "obvious" default action the router should perform in that
> case?
>
> -K
>
>
> On Fri, Apr 13, 2018 at 3:38 PM, Chuck Rolke <cr...@redhat.com> wrote:
>> I would prefer to keep the feature enforced as it is now. I was one who
>> was surprised to have a sender whose message is settled by the router
>> only to find out that it was not delivered anywhere.
>>
>> The document https://qpid.apache.org/releases/qpid-dispatch-1.0.0/book/book.html#routing-patterns
>> needs to have a clearer explanation of the lossy nature of multicast
>> distribution.
>>
>> ----- Original Message -----
>>> From: "Ted Ross" <tr...@redhat.com>
>>> To: users@qpid.apache.org
>>> Sent: Thursday, April 12, 2018 6:26:34 PM
>>> Subject: Re: Proposed Feature Removal from Dispatch Router
>>>
>>> For the record, here is the Jira for the feature in question:
>>>
>>> https://issues.apache.org/jira/browse/DISPATCH-744
>>>
>>> On Thu, Apr 12, 2018 at 6:20 PM, Ted Ross <tr...@redhat.com> wrote:
>>> > We added a feature back in 1.0.0 to reject unsettled deliveries to
>>> > multicast addresses by default. This can be disabled through
>>> > configuration but is on by default.
>>> >
>>> > The rationale was that the router would accept and settle unsettled
>>> > multicasts even though it might not have delivered the messages to any
>>> > consumer. The rejection with error code was intended to inform users
>>> > that they should pre-settle deliveries to multicast addresses in
>>> > keeping with the best-effort nature of multicast routing.
>>> >
>>> > In practice, this is more of an annoyance because none of the example
>>> > clients (and apparently the users' clients) actually do anything with
>>> > the error code in the rejected delivery. The router appears to
>>> > silently drop such messages for no good reason and good will is wasted
>>> > in chasing down the issue to "oh, you should turn off this handy
>>> > feature".
>>> >
>>> > The recently raised https://issues.apache.org/jira/browse/DISPATCH-966
>>> > is caused by this feature as well. This is because the router can
>>> > stream large messages in multiple transfers. The first transfer is
>>> > used for routing and the last transfer should be used to determine the
>>> > settlement status of the delivery. It is not a trivial fix to make
>>> > this work correctly.
>>> >
>>> > For the above two reasons, I propose that we back out this feature and
>>> > allow multicasting with unsettled deliveries. We should add a clear
>>> > note in the documentation that states that multicast is best-effort,
>>> > regardless of the settlement status of the deliveries.
>>> >
>>> > Any objections from the users?
>>> >
>>> > -Ted
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
>
>
> --
> -K
--
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Proposed Feature Removal from Dispatch Router
Posted by Ken Giusti <kg...@redhat.com>.
We really should try to do something smarter in the case of unsettled
multicast rather than either of the current approaches.
What does an application/dev expect when it sends any message
unsettled? It expects to block until eventually it gets some
indication of whether or not the message was delivered as intended.
In the case of single consumer the expectation is obvious and well
handled by the router.
But in the case of multicast it is a different story: here we have the
possibility that the message may be both consumed by one recipient and
rejected by another. So the question is: from the POV of the dev/app,
what is the "obvious" default action the router should perform in that
case?
-K
On Fri, Apr 13, 2018 at 3:38 PM, Chuck Rolke <cr...@redhat.com> wrote:
> I would prefer to keep the feature enforced as it is now. I was one who
> was surprised to have a sender whose message is settled by the router
> only to find out that it was not delivered anywhere.
>
> The document https://qpid.apache.org/releases/qpid-dispatch-1.0.0/book/book.html#routing-patterns
> needs to have a clearer explanation of the lossy nature of multicast
> distribution.
>
> ----- Original Message -----
>> From: "Ted Ross" <tr...@redhat.com>
>> To: users@qpid.apache.org
>> Sent: Thursday, April 12, 2018 6:26:34 PM
>> Subject: Re: Proposed Feature Removal from Dispatch Router
>>
>> For the record, here is the Jira for the feature in question:
>>
>> https://issues.apache.org/jira/browse/DISPATCH-744
>>
>> On Thu, Apr 12, 2018 at 6:20 PM, Ted Ross <tr...@redhat.com> wrote:
>> > We added a feature back in 1.0.0 to reject unsettled deliveries to
>> > multicast addresses by default. This can be disabled through
>> > configuration but is on by default.
>> >
>> > The rationale was that the router would accept and settle unsettled
>> > multicasts even though it might not have delivered the messages to any
>> > consumer. The rejection with error code was intended to inform users
>> > that they should pre-settle deliveries to multicast addresses in
>> > keeping with the best-effort nature of multicast routing.
>> >
>> > In practice, this is more of an annoyance because none of the example
>> > clients (and apparently the users' clients) actually do anything with
>> > the error code in the rejected delivery. The router appears to
>> > silently drop such messages for no good reason and good will is wasted
>> > in chasing down the issue to "oh, you should turn off this handy
>> > feature".
>> >
>> > The recently raised https://issues.apache.org/jira/browse/DISPATCH-966
>> > is caused by this feature as well. This is because the router can
>> > stream large messages in multiple transfers. The first transfer is
>> > used for routing and the last transfer should be used to determine the
>> > settlement status of the delivery. It is not a trivial fix to make
>> > this work correctly.
>> >
>> > For the above two reasons, I propose that we back out this feature and
>> > allow multicasting with unsettled deliveries. We should add a clear
>> > note in the documentation that states that multicast is best-effort,
>> > regardless of the settlement status of the deliveries.
>> >
>> > Any objections from the users?
>> >
>> > -Ted
>>
>> ---------------------------------------------------------------------
>> 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
>
--
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Proposed Feature Removal from Dispatch Router
Posted by Chuck Rolke <cr...@redhat.com>.
I would prefer to keep the feature enforced as it is now. I was one who
was surprised to have a sender whose message is settled by the router
only to find out that it was not delivered anywhere.
The document https://qpid.apache.org/releases/qpid-dispatch-1.0.0/book/book.html#routing-patterns
needs to have a clearer explanation of the lossy nature of multicast
distribution.
----- Original Message -----
> From: "Ted Ross" <tr...@redhat.com>
> To: users@qpid.apache.org
> Sent: Thursday, April 12, 2018 6:26:34 PM
> Subject: Re: Proposed Feature Removal from Dispatch Router
>
> For the record, here is the Jira for the feature in question:
>
> https://issues.apache.org/jira/browse/DISPATCH-744
>
> On Thu, Apr 12, 2018 at 6:20 PM, Ted Ross <tr...@redhat.com> wrote:
> > We added a feature back in 1.0.0 to reject unsettled deliveries to
> > multicast addresses by default. This can be disabled through
> > configuration but is on by default.
> >
> > The rationale was that the router would accept and settle unsettled
> > multicasts even though it might not have delivered the messages to any
> > consumer. The rejection with error code was intended to inform users
> > that they should pre-settle deliveries to multicast addresses in
> > keeping with the best-effort nature of multicast routing.
> >
> > In practice, this is more of an annoyance because none of the example
> > clients (and apparently the users' clients) actually do anything with
> > the error code in the rejected delivery. The router appears to
> > silently drop such messages for no good reason and good will is wasted
> > in chasing down the issue to "oh, you should turn off this handy
> > feature".
> >
> > The recently raised https://issues.apache.org/jira/browse/DISPATCH-966
> > is caused by this feature as well. This is because the router can
> > stream large messages in multiple transfers. The first transfer is
> > used for routing and the last transfer should be used to determine the
> > settlement status of the delivery. It is not a trivial fix to make
> > this work correctly.
> >
> > For the above two reasons, I propose that we back out this feature and
> > allow multicasting with unsettled deliveries. We should add a clear
> > note in the documentation that states that multicast is best-effort,
> > regardless of the settlement status of the deliveries.
> >
> > Any objections from the users?
> >
> > -Ted
>
> ---------------------------------------------------------------------
> 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: Proposed Feature Removal from Dispatch Router
Posted by Robbie Gemmell <ro...@gmail.com>.
I don't have an issue with this, I didn't originally like the default
being to reject unsettled deliveries when the ability was added,
particularly given the congestion handling for pre-settled, but also
due to the likely need for clients to jump hoops to use the
multicasting vs not.
The functionality could always be added back in later if it becomes
more feasible to resolve the issues, and in the meantime if the
unsettled message didnt actually go anywyere, its really no different
than the equivalent pre-settled message not actually going anywhere. I
dont see the use case being much/any different than the traditional
topic pub-sub case where there might be noone subscribed at the point
a message is sent.
Robbie
On 12 April 2018 at 23:26, Ted Ross <tr...@redhat.com> wrote:
> For the record, here is the Jira for the feature in question:
>
> https://issues.apache.org/jira/browse/DISPATCH-744
>
> On Thu, Apr 12, 2018 at 6:20 PM, Ted Ross <tr...@redhat.com> wrote:
>> We added a feature back in 1.0.0 to reject unsettled deliveries to
>> multicast addresses by default. This can be disabled through
>> configuration but is on by default.
>>
>> The rationale was that the router would accept and settle unsettled
>> multicasts even though it might not have delivered the messages to any
>> consumer. The rejection with error code was intended to inform users
>> that they should pre-settle deliveries to multicast addresses in
>> keeping with the best-effort nature of multicast routing.
>>
>> In practice, this is more of an annoyance because none of the example
>> clients (and apparently the users' clients) actually do anything with
>> the error code in the rejected delivery. The router appears to
>> silently drop such messages for no good reason and good will is wasted
>> in chasing down the issue to "oh, you should turn off this handy
>> feature".
>>
>> The recently raised https://issues.apache.org/jira/browse/DISPATCH-966
>> is caused by this feature as well. This is because the router can
>> stream large messages in multiple transfers. The first transfer is
>> used for routing and the last transfer should be used to determine the
>> settlement status of the delivery. It is not a trivial fix to make
>> this work correctly.
>>
>> For the above two reasons, I propose that we back out this feature and
>> allow multicasting with unsettled deliveries. We should add a clear
>> note in the documentation that states that multicast is best-effort,
>> regardless of the settlement status of the deliveries.
>>
>> Any objections from the users?
>>
>> -Ted
>
> ---------------------------------------------------------------------
> 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: Proposed Feature Removal from Dispatch Router
Posted by Kai <so...@gmail.com>.
I consider the rejected delivery to be more explicit and thus in general
the better approach. Allowing unsettled deliveries to multicast addresses
will now (probably) lead to users wondering where their messages have gone
that did not reach one or more of the multicast consumers. So, in any case,
clearly pointing out the best effort nature in the documentation of
multicast addresses seems to be the right approach.
On Fri, Apr 13, 2018 at 12:26 AM Ted Ross <tr...@redhat.com> wrote:
> For the record, here is the Jira for the feature in question:
>
> https://issues.apache.org/jira/browse/DISPATCH-744
>
> On Thu, Apr 12, 2018 at 6:20 PM, Ted Ross <tr...@redhat.com> wrote:
> > We added a feature back in 1.0.0 to reject unsettled deliveries to
> > multicast addresses by default. This can be disabled through
> > configuration but is on by default.
> >
> > The rationale was that the router would accept and settle unsettled
> > multicasts even though it might not have delivered the messages to any
> > consumer. The rejection with error code was intended to inform users
> > that they should pre-settle deliveries to multicast addresses in
> > keeping with the best-effort nature of multicast routing.
> >
> > In practice, this is more of an annoyance because none of the example
> > clients (and apparently the users' clients) actually do anything with
> > the error code in the rejected delivery. The router appears to
> > silently drop such messages for no good reason and good will is wasted
> > in chasing down the issue to "oh, you should turn off this handy
> > feature".
> >
> > The recently raised https://issues.apache.org/jira/browse/DISPATCH-966
> > is caused by this feature as well. This is because the router can
> > stream large messages in multiple transfers. The first transfer is
> > used for routing and the last transfer should be used to determine the
> > settlement status of the delivery. It is not a trivial fix to make
> > this work correctly.
> >
> > For the above two reasons, I propose that we back out this feature and
> > allow multicasting with unsettled deliveries. We should add a clear
> > note in the documentation that states that multicast is best-effort,
> > regardless of the settlement status of the deliveries.
> >
> > Any objections from the users?
> >
> > -Ted
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Proposed Feature Removal from Dispatch Router
Posted by Ted Ross <tr...@redhat.com>.
For the record, here is the Jira for the feature in question:
https://issues.apache.org/jira/browse/DISPATCH-744
On Thu, Apr 12, 2018 at 6:20 PM, Ted Ross <tr...@redhat.com> wrote:
> We added a feature back in 1.0.0 to reject unsettled deliveries to
> multicast addresses by default. This can be disabled through
> configuration but is on by default.
>
> The rationale was that the router would accept and settle unsettled
> multicasts even though it might not have delivered the messages to any
> consumer. The rejection with error code was intended to inform users
> that they should pre-settle deliveries to multicast addresses in
> keeping with the best-effort nature of multicast routing.
>
> In practice, this is more of an annoyance because none of the example
> clients (and apparently the users' clients) actually do anything with
> the error code in the rejected delivery. The router appears to
> silently drop such messages for no good reason and good will is wasted
> in chasing down the issue to "oh, you should turn off this handy
> feature".
>
> The recently raised https://issues.apache.org/jira/browse/DISPATCH-966
> is caused by this feature as well. This is because the router can
> stream large messages in multiple transfers. The first transfer is
> used for routing and the last transfer should be used to determine the
> settlement status of the delivery. It is not a trivial fix to make
> this work correctly.
>
> For the above two reasons, I propose that we back out this feature and
> allow multicasting with unsettled deliveries. We should add a clear
> note in the documentation that states that multicast is best-effort,
> regardless of the settlement status of the deliveries.
>
> Any objections from the users?
>
> -Ted
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org