This commit fixes the initialization of the StoreQueueCursor message
audit object to make sure it's shared between the persistent and non
persistent cursors. It also adds a check to ensure that duplicate calls
to start will not try and init more than once.
- a test case which demonstrates the bug.
- the first test case sendDelayedMessage_usingNormalProducer works fine because it is using a normal named JMS MessageProducer. Included just for comparison purposes.
- the 2nd test case sendDelayedMessage_usingAnonymousProducer shows the bug.
- the bug fix: swap the order of the AdvisoryBroker and SchedulerBroker BrokerFilters.
- make AdvisoryBroker come after SchedulerBroker but before RegionBroker
- this ensures that when a delayed message gets eventually forwarded to the RegionBroker, the RegionBroker will "see" the AdvisoryBroker when it invokes 'addDestination'. Thus, the AdvisoryBroker gets to send out the advisory message as expected.
This fixes network subscriptions that are generated on demand when a
consumer uses composite destinations. Before this fix conduit
subscriptions didn't work correctly. This fix now splits up the
composite dest and generates correct demand for each of the individual
destinations.
This is best practice and will prevent unlock from being attempted
inside of a finally block when the thread doesn't actually own the
lock which can happen when the lock attempt throws an exception
such as calling lockInterruptibly()
A store directory is created by MessageDatabase#getPageFile which
is called in two cases:
1. KahaDBStore.start() when creating a queue
2. KahaDBStore.size() which is performed when sending any persistent message
If both methods are called concurrently it's possible to get an IOException
thrown from the IOHelper.mkdirs method.
Topic subscriptions expire a message
This fixes topic subs to send the right advisory type, if enabled, when
the server discards a message on dispatch to a topic sub. Also add some
more expiration tests for other subscription types
current dispatched count
The previous way of computing the count of using total dispatched minus
total dequeued didn't work in the case of destination removal and
messages were not acked. The counter is needed as the dispatched list is
optional unlike prefetch subs.
The dispatched advisory doesn't really make sense to send for queue
browsers, just like we don't send a consumed advisory, as it's more of
an admin type funtion to look at the contents of a queue but it's not a
real consumer that is receiving and acking messages.
