[EnMasse] Publishing to specific topic and subscribing with wildcard leads to growing queue/topic

[Rob Godfrey]

On Tue, 30 Jul 2019 at 13:06, Bob Claerhout <bob.claerhout at aloxy.io> wrote:

> In eclipse-ditto I'm creating a connection which publishes the data to
> that address.
> So it should probably not create the queue and just publish to that
> address instead.
>

Yeah - are you saying that ditto is doing this (creating the queue)?

-- Rob


>
>
> On 7/30/19 11:52 AM, Rob Godfrey wrote:
>
> So, I guess the question is, what is creating the queue with the specific
> device id in it (and which presumably no-one is consuming from)?
>
> I would imagine that simply creating the topic does not create an
> queues... so, can you tell at what point this queue is being created, and
> by which process?
>
> -- Rob
>
> On Tue, 30 Jul 2019 at 11:33, Bob Claerhout <bob.claerhout at aloxy.io>
> wrote:
>
>> Rob,
>>
>> Sorry, you're correct. The address is in fact a topic:
>>
>>
>> Best regars,
>> Bob
>>
>> On 7/30/19 11:28 AM, Rob Godfrey wrote:
>>
>> I'm a little confused - this may just be imprecise use of language, but
>> you say: "Eclipse-ditto is publishing messages to a *queue* called
>> "gw/tenant/tenant:device" ", and then you talk about the backend service
>> subscribing with a (topic) wildcard.
>>
>> If there is a queue then it will receive all messages sent to that
>> (precise) address.
>>
>> A consumer subscribing to a wildcard is essentially setting up a second
>> queue which will receive all messages that match the pattern (but will not
>> receive messages that are already in the specific queue, prior to the
>> subscription).
>>
>> Is the address supposed to represent a queue (with the associated
>> guaranteed delivery semantics) or a topic (in which case it is expected
>> that messages sent when there are no consumers will be discarded)?
>>
>> -- Rob
>>
>> On Tue, 30 Jul 2019 at 11:18, Bob Claerhout <bob.claerhout at aloxy.io>
>> wrote:
>>
>>> Hi,
>>>
>>> While setting up prometheus to monitor our installation, I noticed the
>>> "artemis_message_count" on a specific address is growing while I am
>>> subscribed to this address using a wildcard.
>>> To be more specific:
>>> Eclipse-ditto is publishing messages to a queue called
>>> "gw/tenant/tenant:device". A backend service (python) is subscribed to
>>> "gw/#".
>>> In prometheus, I'm getting following artemis_message_counts:
>>>
>>>
>>> When I look at the metric "artemis_consumer_count", following records
>>> are shown:
>>>
>>>
>>> Any idea on how to prevent the queue from building up?
>>>
>>> Best regards
>>> *Bob Claerhout*
>>> Software developer
>>> M +32 479 34 84 92
>>> The Beacon, Sint-Pietersvliet 7, 2000
>>> Antwerp
>>> bob.claerhout at aloxy.io | www.aloxy.io
>>> _______________________________________________
>>> enmasse mailing list
>>> enmasse at redhat.com
>>> https://www.redhat.com/mailman/listinfo/enmasse
>>>
>>
>>
>> --
>> ____________________________________________________________
>> _________________
>>
>> Red Hat GmbH, www.de.redhat.com,
>> Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen,
>> HRB 153243,
>> Managing Directors: ,Charles Cachera, Michael Cunningham, Michael
>> O'Neill, Eric Shander
>>
>>
>>
>
> --
> ____________________________________________________________
> _________________
>
> Red Hat GmbH, www.de.redhat.com,
> Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB
> 153243,
> Managing Directors: ,Charles Cachera, Michael Cunningham, Michael O'Neill,
> Eric Shander
>
>
>

-- 
____________________________________________________________
_________________

Red Hat GmbH, www.de.redhat.com,
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB
153243,
Managing Directors: ,Charles Cachera, Michael Cunningham, Michael O'Neill,
Eric Shander
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/enmasse/attachments/20190730/127ef404/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pjligbpiifmlpkpm.png
Type: image/png
Size: 3940 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/enmasse/attachments/20190730/127ef404/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: peihckpcocfdfmcj.png
Type: image/png
Size: 50736 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/enmasse/attachments/20190730/127ef404/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bagmoinhepbbjljp.png
Type: image/png
Size: 26943 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/enmasse/attachments/20190730/127ef404/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mijgimmamimbonlh.png
Type: image/png
Size: 6330 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/enmasse/attachments/20190730/127ef404/attachment-0003.png>