4 Replies Latest reply on Dec 28, 2006 4:17 PM by timfox

    QueueBrowser semantics

    timfox

      Currently we have implemented the queue browser to iterate over the set of all undelivered + delivered but not yet acknowledged messages in a queue.

      I don't see anything particularly wrong with this, but neither can I see anything in the JMS spec that says the iteration has to include the set of delivered but not yet unacknowledged methods.

      The reason I bring this up is that I would like to remove the set of deliveries which are currently managed in ChannelSupport. For primary JMS use cases: delivery, acknowledgement, cancellation it is not necessary for the channel to maintain a delivery set. Removing it would greatly simplify the code and probably improve performance and reduce scope for race conditions.

      If we can relax the queue browsing implementation to not include delivered but not yet acked messages then we can do this, otherwise it would be more difficult.

      My view is we shouldn't sacrifice performance and simplicity for a non primary use case (browsing) which is generally used for management.

        • 1. Re: QueueBrowser semantics
          genman

          I'm pretty sure with JBossMQ that browsing does not include the unack'd messages.

          • 2. Re: QueueBrowser semantics
            genman

            And actually, for JBossMQ queue sizes do not include the number of unack'd messages. I know this, since users often get confused when a message is being processed in an MDB, for instance, they see 0 messages in the queue and think nothing is going on.

            • 3. Re: QueueBrowser semantics
              ovidiu.feodorov

              Logically, if a message hasn't been acknowleged, it didn't leave the queue yet. It cannot be delivered to any other receiver, but it's still in the queue. I found logical that browsing would return these messages as well.

              However, I don't feel strongly about this issue, so as long it doesn't contradict the spec, implement it in the simplest possible fashion.

              Ultimately, we can have a configuration option that would say what kind of browsing the user wants ...

              • 4. Re: QueueBrowser semantics
                timfox

                I have refactored so the channel no longer maintains deliveries.

                This has furthered simplified things a lot and removed a whole area that was prone to race conditions.

                This of course results in a change to the semantics of queue browsing as discussed here.