[jira] [Commented] (AMQ-6572) KahaDB journal may not handle max file length changes correctly

["Christopher L. Shannon (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/AMQ-6572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15834784#comment-15834784 ] 

Christopher L. Shannon commented on AMQ-6572:
---------------------------------------------

After analyzing the two potential areas I found there is only an issue with the first case (where the journal file shrinks) in that the reported journal length will be wrong.

In the first case, as suggested, the last data file length needs to be used or the totalLength reported by the Journal will be wrong as the wrong value is used when computing the unused space.  In the second case (where the journal file grows) it is ok because if the detected length is less than the offset value the journal will reset the cursor to the next file and the correct starting value here: https://fisheye.apache.org/browse/~tag=activemq-5.14.3/activemq-6/activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/disk/journal/Journal.java?hb=true#to843

Overall I would consider the issue minor because there is no message loss and the journal still works except for reported length being slightly wrong.  I will push up a patch shortly.

> KahaDB journal may not handle max file length changes correctly
> ---------------------------------------------------------------
>
>                 Key: AMQ-6572
>                 URL: https://issues.apache.org/jira/browse/AMQ-6572
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: KahaDB
>    Affects Versions: 5.14.3
>            Reporter: james
>            Assignee: Christopher L. Shannon
>            Priority: Minor
>
> I was exploring the idea of changing the kahadb journal file length on an activemq instance which already has existing data (during a system restart).  Initial response from activemq insiders was that this was a supported action, but while examining the Journal source, i stumbled on code which would seem to indicate that it isn't handled correctly
> Source thread: http://activemq.2283324.n4.nabble.com/Can-you-change-the-kahadb-journal-file-size-between-broker-starts-td4721155.html#a4721252
> Potential problem areas (from forum post):
> https://fisheye.apache.org/browse/activemq-6/activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/disk/journal/Journal.java?hb=true#to310
> This is the startup code.  it attempts to adjust the total length by shaving off an unused portion of the final data file.  if you have made the maxFileLength smaller since the last run, and you have actual data in the last journal file which is _after_ the new maxFileLength, then this computation will incorrectly return a negative value.  my suspicion is that the length of the last data file should be used here instead of maxFileLength.
> https://fisheye.apache.org/browse/activemq-6/activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/disk/journal/Journal.java?hb=true#to867
> likewise, this code attempts to handle adjustments to maxFileLength since the journal file was created, but i think it again fails.  if the maxFileLength has been increased since the data file was created, this would seem to be setting an offset which is past the length of the current data file.  again, it seems like the length of the data file should be used directly.
> in general, in order for this to work correctly, the maxFileLength should only be used for code which is creating new files.  all the other code should be solely relying on the size of the existing file, right? 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)