Queue message count

[timfox]

I noticed, the way message count has been implemented on the core queue is by using state.undelivered().size().

This is a *very* expensive operation and will basically lock that queue completely for the duration.

A much better way to do this is to expose SingleLinkedDeque.size() which returns the current size without any synchronization effort. I went to some efforts to ensure that a size of the deque could be maintained without any thread contention between threads adding to the deque and threads removing from the deque.

This method needs to be exposed up through the State interface and used.

(Actually the undelivered() method should be removed altogether - it's ugly and heavyweight and we should provide an iterator over the state which uses the deque iterator (which again doesn't cause lock contention) combined with an iterator over the deliveries - this is on my list and should be converted to a JIRA task for beta, but the message count implementation could be fixed easily ASAP)

[ovidiu.feodorov]

The fist goal of the "queue message count" check in was to make sure that we have in place a management mechanism that goes from the facada all the way to the core and back.

The implementation is less important at this stage, but as you say, I see no reason to use a bad implementation when we can use a better one.

Alex, this is yours ...

[timfox]

Right

The fix to this is actually a no-brainer - if there is any doubt I will be more than happy to point in the right direction.

[alexfu.novell]

Thanks for the suggestion. I'm testing it and will check in afterward.

[timfox]

Alex - looks much better :)

A couple of points:

1) Perhaps mesageCount is a better name than messageAmount?

2) The number of messages in the queue is the sum of the number of undelivered messages plus the number of messages being delivered.

i.e.

public int messageAmount()
{
 return messageRefs.size() + deliveries.size();
}

[alexfu.novell]

You are right. Done. Thanks.