qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakub Scholz <ja...@scholz.cz>
Subject Re: Credit handling for sending messages to multicast addresses in Dispatch
Date Tue, 23 May 2017 21:32:10 GMT
FYI: I raised it as DISPATCH-779 (
https://issues.apache.org/jira/browse/DISPATCH-779)

Thanks & Regards
Jakub

On Mon, May 22, 2017 at 9:14 PM, Jakub Scholz <jakub@scholz.cz> wrote:

> Hi Ted,
>
> Ok, thanks. I will try to collect some logs and raise a JIRA.
>
> Thanks & Regards
> Jakub
>
> On Mon, May 22, 2017 at 8:55 PM, Ted Ross <tross@redhat.com> wrote:
>
>> Hi Jakub,
>>
>> I think your expected behavior should be the correct one for multicast.
>> This is a bug.
>>
>> -Ted
>>
>>
>> On 05/20/2017 05:20 PM, Jakub Scholz wrote:
>>
>>> Hi,
>>>
>>> In Dispatch, I can configure the multicast addresses:
>>> address {
>>>       prefix: /someAddress
>>>       distribution: multicast
>>> }
>>>
>>> My general expectation for such multicast address would be that:
>>> - The credit for sending messages is maintained by the router
>>> automatically
>>> independently on any receivers being attached
>>> - I can send message to such address even when there is no receiver
>>> connected to this address.
>>> - When there is no receiver connected the message is simply dropped by
>>> the
>>> router
>>> - When one or more receivers are connected, the message is sent to all of
>>> them
>>>
>>> However, currently it seems to behave a bit strangely:
>>> - When I connect my producer when no receiver is connected, I get no
>>> credit
>>> and therefore I cannot send any messages
>>> - When I connect a receiver, broker will automatically give credit to the
>>> sender. When I disconnect the receiver, the remaining credit is not taken
>>> away. So I can still send messages until I run out of credit although
>>> nobody is receiving them
>>>
>>> Even if in case original expectations were wrong, this seems to be still
>>> a
>>> bit inconsistent behaviour. So I'm wondering whether what is the expected
>>> behaviour in this case and whether this is some bug. It seems to behave
>>> the
>>> same both in 0.8.0 as well as in latest master. Can someone clarify it?
>>>
>>> Thanks & Regards
>>> Jakub
>>>
>>>
>> --
>> Ted Ross
>> Senior Principal Software Engineer
>> Red Hat
>> 314 Littleton Road
>> Westford, MA 01886
>> tross@redhat.com     T: +1-978-392-3950     M: +1-978-399-4122
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message