On 7 June 2018 at 23:44, Justin Ross wrote:
> On Tue, Apr 17, 2018 at 9:10 AM Gordon Sim 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 d
On Tue, Apr 17, 2018 at 9:10 AM Gordon Sim 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 in
On 17 April 2018 at 17:10, Gordon Sim 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 me
On 16 April 2018 at 19:24, Ken Giusti wrote:
> On Mon, Apr 16, 2018 at 1:06 PM, Alan Conway wrote:
>> On Mon, Apr 16, 2018 at 12:39 PM, Ken Giusti wrote:
>>
>>> On Mon, Apr 16, 2018 at 12:11 PM, Alan Conway wrote:
>>> > On Mon, Apr 16, 2018 at 11:00 AM, Ken Giusti wrote:
>>> >
>>> >> Yeah, ex
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.
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 provi
On Mon, Apr 16, 2018 at 1:06 PM, Alan Conway wrote:
> On Mon, Apr 16, 2018 at 12:39 PM, Ken Giusti wrote:
>
>> On Mon, Apr 16, 2018 at 12:11 PM, Alan Conway wrote:
>> > On Mon, Apr 16, 2018 at 11:00 AM, Ken Giusti wrote:
>> >
>> >> Yeah, exactly.
>> >>
>> >> It's as if you applied a priority t
On Mon, Apr 16, 2018 at 1:50 PM, Gordon Sim 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 ar
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
On 16/04/18 17:39, Ken Giusti wrote:
On Mon, Apr 16, 2018 at 12:11 PM, Alan Conway wrote:
On Mon, Apr 16, 2018 at 11:00 AM, Ken Giusti wrote:
Yeah, exactly.
It's as if you applied a priority to each disposition in the following
order (highest first):
REJECTED
ACCEPTED
MODIFIED
RELEASED
Th
On Mon, Apr 16, 2018 at 12:39 PM, Ken Giusti wrote:
> On Mon, Apr 16, 2018 at 12:11 PM, Alan Conway wrote:
> > On Mon, Apr 16, 2018 at 11:00 AM, Ken Giusti wrote:
> >
> >> Yeah, exactly.
> >>
> >> It's as if you applied a priority to each disposition in the following
> >> order (highest first)
hether 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
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
> >> >
> &g
t;> >> 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://qpi
orced 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#r
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"
>>> To: users@qpid.apache.org
>>> Sent: Thu
--- Original Message -
>> From: "Ted Ross"
>> 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:
&g
needs to have a clearer explanation of the lossy nature of multicast
distribution.
- Original Message -
> From: "Ted Ross"
> To: users@qpid.apache.org
> Sent: Thursday, April 12, 2018 6:26:34 PM
> Subject: Re: Proposed Feature Removal from Dispatch Router
>
>
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 functiona
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,
c
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 wrote:
> We added a feature back in 1.0.0 to reject unsettled deliveries to
> multicast addresses by default. This can be disabled through
>
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 t
22 matches
Mail list logo
