Github user jbertram commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
@stanlyDoge, yes, I think so.
---
Github user stanlyDoge commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
Can I close this PR?
---
Github user jostbg commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
@michaelandrepearce All thoughts and ideas are appreciated :-) I could
achieve what we need (despite it violates JMS spec) by changing the durable
flag of a QueueConfig in
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
On the note of broker plugin, you do realise you can intercept
beforeCreateAddress and beforeCreateQueue and a lot of other functions, this
way you could do what you want
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
As I stated there is already a global flag, if there is an address level
flag then this should have the exact same behaviour. Also Iâm not advocating
changing the global flag
Github user jostbg commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
@michaelandrepearce I cannot modify the durable flag of AMQP messages as
they are meant to be immutable and it would prevent using features like digital
signatures AFAIK. What we are
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
-1 for this as well. The semantics gets blurry and confusing.
Keep it simple principle broken IMO.
---
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
-1 it having different or custom behaviour, if such flag exists it should
have the same behaviour as the global just simply at the address level.
If you want custom
Github user jostbg commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
@mtaylor In our case a `persistence=false` parameter in the address
settings that only disables the persistent journal but not large message and
paging support would work too.
---
Github user mtaylor commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
Sorry guys but I am -1 on this. I thought the idea of this was to behave
in a similar way to default-max-consumers, or default-purge-on-no-consumers. I
am not happy about overriding the
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
I could easily rebase this also.. but if you could rebase it later please
---
Github user mtaylor commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
Just to be clear here. I can see a use case for this. I'm +1 on the idea
but not for overriding specific protocol / API behaviour. I Just wanted to
clarify that as it was discussed
Github user jostbg commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
@mtaylor When I talked about durability in the context of queues I meant
persistence (writing messages to disk) and not durable subscriptions.
We want to allow clients to create their
Github user mtaylor commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
@jostbg The point is, if you want the broker to create something for you,
then the broker needs to know what to create. I used JMS clients as an example
as they are usually specific
Github user jostbg commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
@mtaylor What is the difference between saying, "Artemis, create a
non-durable queue named foo during server start" vs "Artemis create a
non-durable queue named foo the moment it is first
Github user mtaylor commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
A lot of discussion here :). This should not override what the client
requests. There are a couple of ways addresses and queues can be set up in
Artemis.
The first way is to
Github user jostbg commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
I am too new to Artemis to implement that properly but I hope @stanlyDoge
can address your points.
Thanks for your feedback.
---
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
@jostbg as I said Iâm not a fan, but if you do want to implement could
you address the points I raised.
---
Github user jostbg commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
So when we pre-define non-durable anycast queues in Artemis and a JMS
client publishes to that queue or subscribes to it, we are actually already
violating the JMS spec. Therefore it would
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
JMS Queue is durable by spec.
---
Github user jostbg commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
I am not trying to annoying or anything, but how is a non-durable queue -
that is auto created the moment the first client tries to use it (in whatever
way) - less JMS compliant than a
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
@stanlyDoge as said earlier for this PR, if it is to go forwards id like to
see
- setting values should be enums, to cater for alternative way round so
people can make
Github user jostbg commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
@michaelandrepearce What if the first client does not subscribe to any
address but only sends an AMQP message to an address (either a queue or topic
via QPid JMS). Based on what criterias
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
@jostbg from the sounds of that ticket, what you hit was a bug thats been
fixed, the AMQP client should be able to request a durable or non durable
queue, and the AMQP JMS
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
@jostbg there is implications especially for JMS users, basically if a
client requests a shared subscription, it should not marry up to a durable
shared subscription or vice
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
@jostbg it can, look at the AMQP JMS client, when via JMS you make a
shared subscription, or a shared durable subscription. if the
On the Artemis side look at
Github user jostbg commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
I also don't see much of a difference if a client tries to send a message
to a pre-created non-durable queue and but expects the queue to be durable over
he a message sends to an
Github user jostbg commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
The problem is, that at least when using AMQP the client cannot control if
a durable or non-durable queue is created. The broker always auto-creates
durable queues. We discussed that at
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
This is what security settings are for e.g. you can set for address A users
can only create non-durable queues. If a client try to create a durable queue
they will get security
Github user jostbg commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
I created the ARTEMIS issue as a followup to this
https://issues.apache.org/jira/browse/ARTEMIS-1582. We actually have the
use-case that for certain namespaces we want to dictate all
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
Why is this needed? If an address is allowed for queues to be auto created,
the client describes if the queue should be durable or not. e.g. See JMS
Subscription (which maps
31 matches
Mail list logo
