2 Replies Latest reply on Sep 12, 2006 5:21 AM by Tim Fox

    Semantics of no local for a durable subscription

    Tim Fox Master

      Normally, if a message consumer is created with "no local" = true, then it won't receive any messages sent to it on the same connection the consumer is receiving on.

      Durable subscriptions also can be created with "no local" specified, but this is a bit odd, since if a create a surable subscriber with no local = true, then close the subscriber, the subscription will still exist (since it is durable), but now what does no local mean, since it doesn't have a receiving connection?

      Should it, or should it not receive a message from a particulat connection.

      I think the only safe thing here is for the subscription to always receive messages irrespective of which connection they came from, and to filter them out on the receive.

        • 1. Re: Semantics of no local for a durable subscription
          Ovidiu Feodorov Master

          A "no local" consumer (durable subscriptions included) doesn't receive message sent on its connection, as long as there is a connection. The moment a durable subscription's associated consumer is closed, the durable subscription ceases to have a logical association with any connection, so it's free to accept message from any producers on any connection.
          When a new "no local" consumer for that durable subscription is created, then that subscription must not accept messages from producers sharing the connection with the new consumer. And so on. IMHO.

          • 2. Re: Semantics of no local for a durable subscription
            Tim Fox Master

            Well, if that is true you will have the some strange effects.


            Connection conn1 sends message m1

            conn1 creates consumer with no local = true.

            conn1 sends message m2

            consumer closes without receiving anything

            conn1 sends message m3

            conn1 creates consumer with no local = false

            consumer receives m1

            consumer receivers m3

            (no m2!!)

            My opinion is that no local should only apply to the *consumer* of the subscription (the subscriber), not the subscription itself, which is the way it currently is and has been for some time, and passes TCK.

            I just to wanted to clarify since the spec is a bit fuzzy about this.