@Andreas:
I had the same issue. You can define the target capability ("queue").
Artemis will create a Anycast instead of Multicast. So the queue will hold
message until a consumer comes along. I have created a c# example:
public async Task TestHelloWorld()
{
//strange, works u
> If a client doesn't explicitly (e.g. via the core API, by using a
> configured prefix, etc.) or implicitly (e.g. working with a JMS queue
> (i.e.
> anycast) or JMS topic (i.e. multicast)) specify a routing type then the
> broker uses the defaults (which is multicast for both addresses and
> queue
If a client doesn't explicitly (e.g. via the core API, by using a
configured prefix, etc.) or implicitly (e.g. working with a JMS queue (i.e.
anycast) or JMS topic (i.e. multicast)) specify a routing type then the
broker uses the defaults (which is multicast for both addresses and queues)
when auto
Hello Justin,
I am using the QPID Proton API (Python) and create a producer via AMQP 1.0.
I think there is no preference if it should be a queue or an exchange when
you create a producer using AMQP.
In the code it looks like:
*sender = container.create_sender(self.conn,
topic_name)sender.send(a
Can you elaborate on your use-case a bit? What is the client doing to
cause the queue to be auto-created (e.g. sending a message, creating a
consumer, etc.). Is the client using the JMS API? If so, it is working
with a "queue" or a "topic"?
Also, the "name" attributes of the address and queue e
Hello,
I would like to use queues which are automatically created.
So I tried it out and saw that they are not durable (persistent), which
means a late joiner will not get messages.
My try to configure some default behaviour for all queues which begin with
'M' was this:
