On 26/09/2011 15:07, Nigel Deakin wrote:
> On 05/08/2011 15:37, Nigel Deakin wrote:
>> I have logged this JIRA issue:
>> http://java.net/jira/browse/JMS_SPEC-40
>>
>> This issue was raised by Tom Barnes, though the wording below is my own.
>>
>> Tom: Can you please confirm that this captures your requirement accurately? I suggest we wait for Tom to confirm this
>> before discussing it in too much detail.jsr
>
> I have now had the opportunity to discuss with Tom and he gave me the following feedback:
>
> Tom told me that my description of his requirement as being to "allow multiple threads in the same client to consume
> messages from the same durable or non-durable topic subscription" is incorrect. He would like a more general feature
> which would allow multiple consumers to be created on the same durable or non-durable topic subscription. These
> consumers could be on the same or different connections and in the saame or different JVMs.
>
> I've therefore changed the summary in JIRA (and the subject line of this thread) from "Allow multiple threads in same
> client to consume messages from the same topic subscription" to "Allow multiple consumers to be created on the same
> topic subscription", and updated the proposal as follows, and modified the wording in JIRA to reflect this.
>
> Tom also suggested that existing applications may rely on the JMS provider implementing the current restriction that
> only one consumer may activate a given durable subscription at a time. However on reflection I think that since a
> durable subscription is currently defined by {clientId, subscriptionName), such applications work by trying to create a
> second connection with an existing clientId and relying on this failing. My proposals will not change the requirement
> for clientId, if set, to be unique and so would not break existing applications.
>
> My updated proposal follows:
>
> ---
> This issue was raised by a member of the JSR 343 Expert Group and is logged here to allow the issue to be discussed and
> tracked.
>
> This proposal would allow multiple message consumers to be used to consume messages from the same durable or non-durable
> topic subscription. This would increase scalability by allowing messages from a topic to be processed by multiple
> consumers in a Java SE environment. Note that the existing API allows this to be achieved for messages from a queue.
>
> The multiple consumers might be in the same or different JVMs. Within the same JVM, the multiple consumers might use the
> same or different sessions and connection. Note, however, that the normal restrictions on the use of a session by
> multiple threads would continue to apply.
>
> For durable subscriptions, there would be no need to change the existing API. However it would be necessary to relax the
> existing restriction that only allows one durable subscription to be created with a given clientId and subscriptionName:
>
> TopicSubscriber topicSubscriber1 =
> topicSession.createDurableSubscriber(topic,durableSubscriptionName);
>
> This proposal assumes that clientId would be optional when creating a durable subscription, as proposed in JIRA issue
> 39, but that the existing requirement for clientId to be unique to remain.
>
> This means that for two message consumers on different connections to share a durable subscription, clientId would need
> to be left unset.
>
> For non-durable subscriptions, the existing JMS API already specifies that if two non-durable TopicSubscribers are
> created on the same topic then two independent subscriptions are created. A new API would be needed for this new case
> when it is desired that two non-durable TopicSubscribers share the same subscription, which would be identified by a new
> sharedSubscriptionName:
>
> TopicSubscriber topicSubscriber1 =
> topicSession.createSharedSubscriber(topic,sharedSubscriptionName);
>
> ---
>
> Comments?
I've further updated the description in JIRA to remove references to the domain-specific interfaces such as TopicSession
which JIRA issue 47 proposes to deprecate, and replace them with appropriate methods on Session, including the new
createDurableCOnsumer method proposed in JIRA issue 51 . This now reads as follows (or look at JIRA directly). Sorry for
the confusion...
---
This issue was raised by a member of the JSR 343 Expert Group and is logged here to allow the issue to be discussed and
tracked.
This proposal would allow multiple message consumers to be used to consume messages from the same durable or non-durable
topic subscription. This would increase scalability by allowing messages from a topic to be processed by multiple
consumers in a Java SE environment. Note that the existing API allows this to be achieved for messages from a queue.
The multiple consumers might be in the same or different JVMs. Within the same JVM, the multiple consumers might use the
same or different sessions and connection. Note, however, that the normal restrictions on the use of a session by
multiple threads would continue to apply.
For durable subscriptions, there would be no need to change the existing API. However it would be necessary to relax the
existing restriction that only allows one durable subscription to be created with a given clientId and subscriptionName:
Assuming the new method proposed in JIRA issue 51 , this would be:
session.createDurableConsumer(topic,durableSubscriptionName)
This proposal assumes that clientId would be optional when creating a durable subscription, as proposed in JIRA issue
39, but that the existing requirement for clientId to be unique to remain.
This means that for two message consumers on different connections to share a durable subscription, clientId would need
to be left unset.
For non-durable subscriptions, the existing JMS API already specifies that if two non-durable TopicSubscribers are
created on the same topic then two independent subscriptions are created. A new API would be needed for this new case
when it is desired that two non-durable subscribers share the same subscription, which would be identified by a new
sharedSubscriptionName.
MessageConsumer messageConsumer=
session.createSharedConsumer(topic,sharedSubscriptionName);
(Since JIRA issue 47 proposes that TopicSession be deprecated, no change to that interface is proposed)
----
Comments?
Nigel