I'm pretty sure with JBossMQ that browsing does not include the unack'd messages.
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.
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 ...
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.