Github user mtaylor commented on the issue:
https://github.com/apache/activemq-artemis/pull/701
@clebertsuconic I think probably the best solution is to fail multiple
clients with the same ID and find an alternate way to handle shared
subscriptions consistently across all protocols.
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/701
@jbertram @mtaylor I will merge this for now. But this wouldn't stop us
from finding a better solution later.
---
If your project is set up for it, you can reply to this email and
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/701
>> Our Stomp implementation allows individual Stomp clients to connect to
the same durable subscription by connecting with the same client-id <<
Wouldn't be easier if we jus
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/701
@jbertram got it.. thanks
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
Github user jbertram commented on the issue:
https://github.com/apache/activemq-artemis/pull/701
The original use-case was related to Stomp durable subscriptions which in
core terms is simply a durable, non-temporary queue. Our Stomp implementation
allows individual Stomp clients to
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/701
@jbertram any one...
is this about Temporary Shared Queues? or anything in particular.
if this is just about shared temp queues, then Martyn's suggestion could
make sense
Github user jbertram commented on the issue:
https://github.com/apache/activemq-artemis/pull/701
@clebertsuconic, was your question for me or @mtaylor? If it's for me can
you elaborate a bit more. I'm not clear on what you're asking.
---
If your project is set up for it, you can re
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/701
There is one concept on core called createSharedQueue, which is a temporary
queue that will exist as long as there is an user connect into it.
shared=true might confuse with
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/701
Look at ActiveMQServerImpl::createSharedQueue
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/701
I am not sure would really be that user friendly as you defined. it
could be confusing actually.
you already have permissions to createQueue, createDurableQueue and
consume
Github user mtaylor commented on the issue:
https://github.com/apache/activemq-artemis/pull/701
To track our offline conversations.
For sake of conversation I'm describing the equivilent "virtual topics"
feature as a "shared subscription".
We've established the use ca
Github user jbertram commented on the issue:
https://github.com/apache/activemq-artemis/pull/701
There's no way to eliminate the user's need to understand how non-core
protocols map to the core implementation. We have addresses and queues and
just about all the configuration and mana
Github user mtaylor commented on the issue:
https://github.com/apache/activemq-artemis/pull/701
@clebertsuconic sure, I think that similar feature is virtual topics, which
solve the same problem as shared subscriptions. The way it works in ActiveMQ
5.x is that the user specifies the
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/701
My understanding was. There was a similar feature in AMQ5 that needed to be
similar here in which Lionel was using.if there is a way to not use the queue
name it's better for sure.
Github user mtaylor commented on the issue:
https://github.com/apache/activemq-artemis/pull/701
Also, I think this JIRA is only relevant when used in a shared subscription
scenario. See Lionel's comment about CERN's use case.
---
If your project is set up for it, you can reply to th
Github user mtaylor commented on the issue:
https://github.com/apache/activemq-artemis/pull/701
This JIRA title is: Allow fine grain access control (durable
subscriptions). There is some discussion on the JIRA that you might find
useful.
---
If your project is set up for it, you ca
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/701
The task is about using he queue name also on the control. So it has to do
so by definition right? Unless you close the Jira as won't fix.
---
If your project is set up for it, y
Github user mtaylor commented on the issue:
https://github.com/apache/activemq-artemis/pull/701
@jbertram I'm not sure about using the queue name to control access. It
requires users to understand how subscriptions work internally and how the
queue name is constructed, which might be
18 matches
Mail list logo
