|
Fixed by SVN revision 667752 and revision 667756
I've tested AMQ 5.2 SNAPSHOT for this fix with partial success. There isn't any problem every message from Topic is acknoledged but solution doesn't work when some of messages are regulary received by durable subscribers and some of them are redeliverd till they get to ActiveMQ.DLQ due to exceeding max redelivery count.
To duplicate error see attached zip . -TopicRedeliver creates two separetes durable consumers, which consumes every odd message and recover session if message number is even. Parameter "jms.redeliveryPolicy.maximumRedeliveries=1" causes that after first redelivery message goes to dead letter queue. Reproducing steps: Results: Using AMQ 5.2. stable release is even not possible run this test - after couple hundred messages one of durable subscriber get stuck (see https://issues.apache.org/activemq/browse/AMQ-2021 Tests on amq revision number 729038 with amqPersistenceAdapter as well as with kahaPersistenceAdapter but none of them was sucessful
from different reasons. With amqPersistenceAdapter, 100k msgs have been sent and data directory size is 1.1 GB. Using kahaPersistenceAdapter, after 100k msgs one of the consumer receives 100k second 99999 msgs.After another 300k msgs data directory size is 410MB. Also some errors are logged by AMQ: ERROR DataManagerImpl - Looking for key 15 but not found in fileMap: {17=data-queue-data-17 number = 17 , length = 177868 refCount = 6, 16=data-queue-data-16 number = 16 , length = 33546816 refCount = 86} For this tests it was necessary to adjust memory usage and limit settings - view attached activemq.xml. config file used to test rev. number 729038
the fix for http://issues.apache.org/activemq/browse/AMQ-2123
 will help with the "could not be recovered from the data store - already dispatched" issue. This should also help with store management as it ensures that references are correctly cleaned up. I've tested amq revision number 747951. Cleaning storage using amqPersistenceAdapter is better now, but there are still files that, in my opinion, need to be deleted - in data/journal/ directory after receiving sotps there are still files data-47 and data-87 and no other number between (I guess that in optimal state should be file numbering continous).
There is also problem that from 100k msgs sent message have been only 97208 acknowledged (it should be 100k on both receivers, while every odd message is ack) and "already dispatched" error is still there. with kahaPersistenceAdapter is behaviour very similar as before. test latest trunk 756591
in network of broker setup( 4 pair master/slave), if I kill TopicConsumers during processing messages and restart it, i will see "Message id ... could not be recovered from the data store - already dispatched" i also see "ERROR MasterBroker - Slave Failed one pair of master/slave, the results are much better. topic consumer seems to recover and continue processing Some of the commits for the
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Major
persistent messages for durable subscribers are not purged from disc storage
When jdbcPersistenceAdapter with 4.1.1(non-journal) or kahaPersistenceAdapter with 5.1 are used with 2 durable topic subscribers, disc storage is periodically emptied.