Hello again,
Alex just pointed out to me that I missed an important part of
the JMS 2.0 spec. In chapter 8.3 it says:
A shared non-durable subscription is identified by a name
specified by the client and by the client identifier if set.
I take that to mean that each client Id should have their own
separate namespace. Maybe that is what was meant in QPIDJMS-220?
In this case I retract my previous proposal and just propose a
clarification to QPIDJMS-220:
* Each clientId creates their own namespace
* If no clientId is set this is treated like a separate
anonymous namespace
* Within each of those namespaces there exists the following
sub-namespaces:
* Durable (shared + non-shared) with durable, non-share
requiring a clientId
* Volatile shared
* Volatile non-shared are somewhat special in that they have a
randomly assigned name so they should never conflict with
anything
Kind regards,
Lorenz
On 11/01/17 08:51, Lorenz Quack 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: [email protected]
For additional commands, e-mail: [email protected]
