activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "james (JIRA)" <j...@apache.org>
Subject [jira] [Created] (AMQ-6572) KahaDB journal may not handle max file length changes correctly
Date Fri, 20 Jan 2017 16:44:26 GMT
james created AMQ-6572:
--------------------------

             Summary: 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
            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)

Mime
View raw message