qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robbie Gemmell <robbie.gemm...@gmail.com>
Subject Re: JMS 2.0 shared subs and clientId
Date Wed, 11 Jan 2017 10:24:12 GMT
Hi Lorenz,

Your timing couldn't be better/worse hehe. As you hadnt replied
following the related mail a month or so ago, I didn't think there was
more to discuss on this. I had actually planned to start doing the
release right about now...I almost got to it yesterday, alas ;)

I am unclear from the text exactly how you are proposing to access
this 'anonymous namespace'. The JMS ClientID is being carried using
the AMQP connection container-id, which is a mandatory field to
specify, so a container-id must be given. Did you mean for example to
have all JMS clients without a ClientID use some fixed value as their
container ID (e.g. empty string, which as rather an aside, could clash
with ideas such as those in
https://issues.apache.org/jira/browse/QPID-7605)? Assuming that is the

Using a fixed container-id for all non-ClientID-using JMS connections
was actually the original idea when we were first thought on this in
years past (there have been *many* variations before arriving at this
one). In the end we elected not to pursue that as it has some issues,
especially when interacting with the shared subscriptions stuff. For
- If multiple connections are using a fixed container-id, each needs
to name links they produce uniquely or risk stepping on another
connections toes by stealing its links (or just generally violating
the spec) given they share a container-id. This makes it likely that
over time we would be unable to reuse the same names for a given
durable subscription (without the client somehow persisting it),
creating new link names link over time and effectively forgetting
about the old ones.
- The link naming issue makes JMS durable subscription unsubscribe
(which need be based on only the link name) similarly a problem.
- It forces non-JMS clients to adjust their container naming to use
the same mechanism and share such subscriptions with such connections.
I actually see no reason that non-JMS clients shouldn't be able to
share subscriptions across container-id's, if they choose to (the
subscriptions must be marked for such to be possible, so it isnt true
that any client can access state they should not be able to) i.e have
their own container-scoped [shared] subscriptions but also access
subscriptions shared across any container. I consider the fact JMS 2.0
forces you use two different connections in that scenario to be a poor
aspect of the spec additions, it was actually one of the very first
things that hit me when I read the JMS 2 spec originally.
- It just seems nicer for connections to have their own container-id's
than all using the same one, especially given some things use the
container for naming as well.
- I think there were other reasons, but there have been so many minute
details with the various ideas gone through before settling on this,
that I can honestly no longer remember many of them.


Actually, re-reading the last section, I appear to have misinterpreted
it on my first read through and so did not address it before
considering any the above. I'll address is separetely now:

"For example, if a client with ID "foo" has a shared subscription
called "mysub" a client with ID "bar" would be prevented from also
creating a subscription of the name"

That would violate the JMS spec. Clients with different ClientIDs are
allowed to use the same subscription names at the same time.

"while a client without ID would be allowed to do this under the
QPIDJMS-220 scheme."

As they should. By not having a ClientID, they are not using the "foo"
or "bar" ID and so should be allowed to create a subscription named
"mysub" atthe same time, which only other connections without a
ClientID can use.

On 11 January 2017 at 08:51, Lorenz Quack <quack.lorenz@gmail.com> wrote:
> Hello,
> Sorry for the slightly lengthy email.
> tl;dr: I propose to change to the way JMS 2.0 subscriptions are
>        treated in the face of the (non-)existence of a clientId as
>        compared to what is outlined in QPIDJMS-220.
> Introduction:
> =============
> I am working on adding support for JMS 2.0 shared subscriptions
> [1] to the Qpid Broker for Java using the mechanisms outlined in
> QPIDJMS-220 [2].
> In QPIDJMS-220 it is outlined that there are essentially 5
> disjunct subscription namespaces:
>  * durable, shared and non-shared, with clientId
>  * durable, shared, without clientId
>  * volatile, shared, with clientId
>  * volatile, shared, without clientId
>  * volatile, non-shared, with and without clientId
> while durable, non-shared, without clientId being disallowed by
> the spec.
> While I think this is spec compliant I find it unintuitive and
> would like to discuss a different partitioning that, according to
> my interpretation of the spec, is also compliant.
> Proposal:
> =========
> The difference essentially comes down to the treatment of the
> clientId.  To me the clientId is like a namespace and not
> specifying it gives you access to an anonymous namespace (what
> QPIDJMS-220 calls "global").  In this it should be treated no
> different from other named namespaces resulting in the following
> partitioning:
>  * durable, shared and non-shared, regardless of clientId
>  * volatile, shared, regardless of clientId
>  * volatile, non-shared, regardless of clientId
> with durable, non-shared, without clientId being disallowed by
> the spec.
> Relevant parts of the Specification:
> ====================================
> From JMS 2.0 Section 8.3.2 Shared non-durable subscriptions:
>     There is no restriction to prevent a shared non-durable
>     subscription and a durable subscription having the same name. Such
>     subscriptions would be completely separate.
> From JMS 2.0 Section 6.1.3 Client identifier:
>     The purpose of client identifier is to associate a connection and
>     its objects with a state maintained on behalf of the client by a
>     provider. By definition, the client state identified by a client
>     identifier can be ‘in use’ by only one client at a time. A JMS
>     provider must prevent concurrently executing clients from using
>     it.
>     This prevention may take the form of a JMSException being thrown
>     when such use is attempted; it may result in the offending client
>     being blocked; or some other solution. A JMS provider must ensure
>     that such attempted ‘sharing’ of an individual client state does
>     not result in messages being lost or doubly processed.
> Discussion:
> ===========
> As mentioned above I think both schemes are spec compliant.  The
> difference is how they prevent concurrently executing clients from
> using each others state.  Section 6.1.3 allows the prevention to take
> the form of a JMSException (my proposal) or "some other solution"
> (QPIDJMS-220, a.k.a. separate namespaces).
> The reason for this I proposal is that I think it is a more natural
> and intuitive partitioning with easier to understand rules.
> For example, if a client with ID "foo" has a shared subscription
> called "mysub" a client with ID "bar" would be prevented from also
> creating a subscription of the name while a client without ID would be
> allowed to do this under the QPIDJMS-220 scheme.  Under my proposed
> scheme both, the "bar" client and the anonymous client, would be
> prevented from creating the subscription.
> Admittedly, it also makes my life as an implementor easier.
> Is there a use-case or rational for the schema proposed in QPIDJMS-220
> that I am not aware of?
> Kind regards,
> Lorenz
> [1] Chapters 8.3 and 6.1.2 of the JMS 2.0 specification
> [2] https://issues.apache.org/jira/browse/QPIDJMS-220
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org

To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message