[jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: Server-side browser refactoring

[clebert.suconic@jboss.com]

You always start a thread that will deliver to the client from the beggining of the queue.

When you call promptDelivery, you are supposed to resume where you left sending messages. And you are aways resuming from the beggining, what is creating order issues on the test.


You are also starting multiple senders as you receive credits. And that is duplicating sends also.


The server should send messages to the client as long as you have credits, when you are out of credits you should give up sending. Next time promptDelivery is called you should resume the process again.


That is not an exclusive problem on LargeMessages. (It's just that you run out of credits earlier with Large Messages).

You will have several problems with regular messages also if you run a test where you limit your credits.


The way the Consumer used to work was on a copy of a Queue, right?

Whey don't you create some sort of QueueIterator that encapsulates the iteration?


Maybe:


  | class QueueIteratorImpl implements Queue
  | {
  |      ... you encapsulate the iteration here to the main Queue
  | }
  | 
  | 
  | 



And on ServerSessionImpl:



  | 
  |    private void doHandleCreateConsumer(final SessionCreateConsumerMessage packet)
  | {
  | ....
  | 
  | 
  |          if (browseOnly)
  |          {
  |              Queue theQueue = new QueueIteratorImpl(binding.getBindable());
  |          }
  | 
  | 




This way you won't need to change anything on ServerConsumerImpl, and I believe you won't need to create any threads to perform the delivery.


Just an idea.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4239151#4239151

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4239151