Design approach for QueueBrowser
timfox May 6, 2005 2:35 AMHi All-
I've started looking at JBMESSAGING-38: QueueBrowser.
I'm knocking together an initial swipe at this, and wanted to check my design approach with you.
I'm implementing a new delegate: BrowserDelegate which supports the distilled down functionality for the QueueBrowser. The client side proxy is created (as per normal pattern) in the server delegate, in this case ServerSessionDelegate.
I've created a JBossQueueBrowser class that implements QueueBrowser, this is what the user of JMS handles. This doesn't hold any state and just calls the delegate to get it's job done.
As to how to get the messages from the server to the client so they can be browsed, I can think of two main approaches here:
1. Get all the messages in the queue in one go from the server and serialise them to the client (if not colocated), then create an enumeration over them for the jms user to use.
2. Chunk the messages either one-by-one from the server or in configurable "batch sizes" (is that the right term?), e.g. get the messages 50 at a time from the server (this can be configurable). This is transparent to the JMS User who is just smoothly enumerating through an enumeration.
Option 1, seems to be the approach that SpyderMQ uses. I could be wrong, but I'm guessing there might be problems here both with the initial time expense in starting the enumeration, and with client side memory usage if there are a lot of undelivered messages.
So, so far I'm going with Option 2 - I would greatly appreciate your input here as to whether this is a sound decision.
The "batching" I'm doing in a new client side interceptor "BrowserInterceptor". I haven't worked out yet how this would be configurable.
My second main issue, is how to see the messages in the queue in the first place, using the core classes.
My initial thought here is to get the message ids of the unacked messages using getUnacknowledged() on the channel and then looking them up in the message store.
Currently the getUnacknowledged() implementation for the queue locks the queue and creates the unacked ids in a new Set before returning it. I'm not sure if this is necessary for browsing since according to the JMS spec we don't have to guarantee a static snapshot of the queue. My thoughts are that not locking or creating a new Set could perhaps improve concurrency and memory usage.
Again, I'd appreciate your thoughts on this.
Cheers
-Tim