I think you're making this more complex than it needs to be:

I'd probably do something like the following, let's say you've added a method to get an iterator on the queue, then you just need to write a bit of code that does this (pseudocode)

Iterator iter = queue.iterator();

while (iter.hasNext())
{
 MessageReference ref = iter.next();
 HandleStatus status = consumer.handle(ref);
 if (status == HandleStatus.BUSY)
 {
 break;
 }
}

Jeff, I don' t see any files there?

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?

Why 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
}

 private void doHandleCreateConsumer(final SessionCreateConsumerMessage packet)
{
....


 if (browseOnly)
 {
 Queue theQueue = new QueueIteratorImpl(binding.getBindable());
 }

In summary, your code don't know how to resume sending at all.

On the process of resuming send, you should also check if largeMessageDeliverer != null and resume sending a largeMessage.


If you provide some sort of QueueIterator implements Queue as I said you won't need to change a line on the ServerConsumer, what would be much easier to debug.

Writing the thread the way you did may look a shortcut (less code), but this promptDelivery thing was a hard thing to tune up. (I needed some time to get my head into it). If you avoid touching it would be better for you.


Just my 2 cents.. and my idea anyway.

I looked at the patch too, and it doesn't look right.

I guess I didn't explain myself well to Jeff.

I'll chat with Jeff in the morning and try to explain the solution better.