|
As of October 27th, please open all new issues in the Red Hat Customer Portal . |
|
[
Permlink
| « Hide
]
Martin Murphy added a comment - 05/Aug/08 01:15 PM
Here's a test case for this problem.
Martin Murphy made changes - 05/Aug/08 01:15 PM
Martin Murphy made changes - 05/Aug/08 01:22 PM
I tried setting syncOnWrite to true as well, but that doesn't seem to help either. It looks like this is a problem with how the Kaha store is setup when a message send is in one data log and it's consumption is in another.
<persistenceAdapter> <amqPersistenceAdapter directory="${activemq.base}/activemq-data/amqstore" maxFileLength="4 mb" archiveDataLogs="true" cleanupInterval="5000" syncOnWrite="true"/> </persistenceAdapter> It might help to use JDBC instead of the Kaha store: <persistenceAdapter> <jdbcPersistenceAdapter dataSource="#postgres-ds"/> </persistenceAdapter> <bean id="postgres-ds" class="org.postgresql.ds.PGPoolingDataSource"> <property name="serverName" value="localhost"/> <property name="databaseName" value="activemq"/> <property name="portNumber" value="0"/> <property name="user" value="activemq"/> <property name="password" value="activemq"/> <property name="dataSourceName" value="postgres"/> <property name="initialConnections" value="1"/> <property name="maxConnections" value="10"/> </bean> You can read more on this here
Martin Murphy made changes - 06/Aug/08 04:43 AM
Martin Murphy made changes - 06/Aug/08 09:06 AM
deleted user made changes - 06/Aug/08 12:42 PM
There are currently two choices for the current message broker - make recovery of the reference store optional - see
https://issues.apache.org/activemq/browse/AMQ-1901 
or use the a journal with jdbc rob.davies@iona.com If I read AMQ-1901
correctly :
Could setting these to false or not forcing a recovery could result in messages that were persisted to the reference store being lost? The very, very worst that could happen is that the reference store is corrupted and fails on start - but if that is the case - restart the broker with recoverReferenceStore or forceRecoverReferenceStore set.
fix from https://issues.apache.org/activemq/browse/AMQ-1901
is on the fixes branch, r46943. will be in .19
Gary Tully made changes - 20/Aug/08 08:13 AM
I think there may still be a problem with this fix. I compiled the trunk and tested it on my side. I would appreciate feedback on my findings.
I repeated the steps of the demo as described above, but this time I had persistence adapter configured not to recover the reference store. <persistenceAdapter> <amqPersistenceAdapter directory="${activemq.base}/activemq-data/amqstore" maxFileLength="4 mb" archiveDataLogs="true" cleanupInterval="5000" syncOnWrite="true" recoverReferenceStore="false"/> </persistenceAdapter> I found that the consumed message that was re-appearing no longer re-appears, so all seems good. However, in step 3 (when the broker, SpringActiveMQ, restarts), I can see that the non-consumed message seems to be removed:
This leads to a problem where as suspected the reference store is corrupted :
So, to recover from this I reset the persistence adapter to recover, I tried forceRecoverReferenceStore="true" with recoverReferenceStore="true" and recoverReferenceStore="false". <persistenceAdapter> <amqPersistenceAdapter directory="${activemq.base}/activemq-data/amqstore" maxFileLength="4 mb" archiveDataLogs="true" cleanupInterval="5000" syncOnWrite="true" recoverReferenceStore="true" forceRecoverReferenceStore="true"/> </persistenceAdapter> The problem is though, when it does recover the message that was not consumed is no longer there and the queue size is 0. It appears the message that was not consumed original is lost (Note each time I stop the broker, I use the stop (red button) in eclipse) fix for : https://issues.apache.org/activemq/browse/AMQ-1926
seems relevant. Test case behaves differently. I need to investigate a bit
Gary Tully made changes - 03/Sep/08 10:45 AM
have run the test case with trunk and it looks like amq-1926 has killed this bird also.
possibly build the fuse-5.0 branch (fix is now there also) and see if it is reproducible. It may be that the test case behaves a little differently now but it may also be that the bug is fixed. The data files are managed a little better now so deletion is more controlled.
Gary Tully made changes - 03/Sep/08 02:42 PM
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Blocker
Consumed messages re-appearing in the broker
