Clebert,
Thanks for the reply. Sorry for the long delay in following-up.
I'd like to understand how your JMS provider behaves with noLocal so I can judge what can be made mandatory, and what
needs to be made optional.
On 31/05/2012 14:46, Clebert Suconic wrote:
>
>
> On Thu, May 31, 2012 at 5:00 AM, Nigel Deakin <nigel.deakin_at_oracle.com <mailto:nigel.deakin_at_oracle.com>> wrote:
>
> Clebert,
>
>
> On 30/05/2012 18:38, Clebert Suconic wrote:
>
>
> I suggest this argument still an optional implementation. Since its dubious definition we simply don't
> implement that way.
>
>
> On all the JMS implementation I have seen here, A message produced by a producer on the same connection will
> be consumed
> by the subscription as long as the message was sent through the server's side.
>
>
> I don't understand. What does "as long as the message was sent through the server's side" mean?
>
>
>
> I meant as long as the message was received on the server and then delivered to clients.
OK. So your description is "a message produced by a producer on the same connection will be consumed by the subscription
as long as the message was received on the server and then delivered to clients."
I'm still difficulty interpreting what you mean. If you can perhaps express this in a bit more detail, perhaps with a
few examples, it would be helpful.
Thanks for looking at those use cases. Let's look at them in turn.
>
>
>
> I would be fine as long as you don't enforce this behaviour, since this will affect existing semantic
> implementations.
>
>
> Before we go any further, can you explain in detail how the products you know interpret "noLocal" for durable
> subscriptions? I give a number of use cases at http://java.net/jira/browse/JMS_SPEC-65#action_339660 - what
> happens in these three cases?
>
> Thanks,
>
> Nigel
>
>
>
*Step 1*: This is the case where a client creates a connection and calls createDurableSubscriber with noLocal=true. This
returns a TopicSubscriber. It then uses the same connection to create a MessageProducer and uses it to send a message to
the topic. The client then uses the TopicSubscriber to try to receive the message.
>
> The first example will receive a message since the subscription was created prior to the send of message.
I'm surprised you say that a message will be received. This seems to be the most unambiguous case. JMS 1.1 states that
the noLocal flag "inhibits the delivery of messages published by its own connection". In this case, noLocal=true, and
the message was published by the same connection as was used to create the subscription. This suggests to me that the
delivery of messages should be "inhibited". So I think JMS 1.1 says *no *message is received.
Can you help explain the rationale behind your product delivering the message in this case, despite noLocal being true?
Can you perhaps give an example of when setting noLocal makes a difference (for durable subscriptions)?
You suggest that the significant thing is that "the subscription was created prior to the send of message." But if the
subscription has been created *after* the send of the message then the value of noLocal would have been irrelevant,
since if you send a message before the durable subscription is first created then it will not be added to the durable
subscription, irrespective of what value of noLocal is specified when the durable subscription is subsequently created.
Since you say a message will be delivered in step 1 then this will mean no message can be delivered in step 2 since the
message has already been delivered (so isLocal is irrelevant) . So I suggest we don't consider steps 2 and 3 until I can
understand why you consider different behaviour is required for step 1.
Thanks in advance for your help here!
Nigel
*
*