Hi,
frenchc wrote:
>
> Update. This issue doesn't exist in version 3.2.1. I can't find the
> source for version3.2.1 to compare the code though with version 4 and a
> potential cause.
>
> Also, I've done some investigating of the code. I found that during a
> recover, sometimes the RecordLocation of the Journal was starting from an
> incorrect location. For instance, if I ran 10 message consumes and quit
> the broker (ctrl-c) then restarted, the recover would start on the Journal
> on the 10th "remove message" record. So, it appears when the journal
> started, it would not read all the "remove message entries" and therefore
> those messages would still be there. I made a fix to the
> JournalMessageStore removeMessage method to add the location of these
> remove message to a Hashmap that contains "inflightlocations" to see if
> this would cause the correct RecordLocation to be returned for the
> checkpoint and it seemed to work correctly now. It could be anecdotal,
> but can someone please let me know if this appear to be a bug to them as
> well? Or am I missing something completely here, and why hasn't this been
> noted by others? Can someone please offer something?
>
> Here's my code change from JournalMessageStore:
>
> public void removeMessage(ConnectionContext context, final MessageAck ack)
> throws IOException {
> final boolean debug = log.isDebugEnabled();
> JournalQueueAck remove = new JournalQueueAck();
> remove.setDestination(destination);
> remove.setMessageAck(ack);
>
> final RecordLocation location =
> peristenceAdapter.writeCommand(remove, ack.isResponseRequired());
> System.out.println("removed message: " + location);
> if( !context.isInTransaction() ) {
> if( debug )
> log.debug("Journalled message remove for:
> "+ack.getLastMessageId()+", at: "+location);
> removeMessage(ack, location);
>
> ADD==> synchronized( this ) {
> ADD==> inFlightTxLocations.add(location);
> ADD==> }
>
I'll have to look into it closer but I think you'll find that with the above
patch the inFlightTxLocations list will grow and grow without bound and
eventually cause a OME.
Regards,
Hiram
--
View this message in context:
http://www.nabble.com/Message-Redelivery-after-startup%2C-potential-BUG-with-easy-test-case-t1337282.html#a3604814
Sent from the ActiveMQ - User forum at Nabble.com.
