[
https://issues.apache.org/jira/browse/AMQ-7067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Tully updated AMQ-7067:
Description:
KahaDB Recovery can experience a dangling transaction when prepare and commit
occur on different data files.
Scenario:
A XA Transaction is started, message is prepared and sent into Broker.
We then send into broker enough messages to file page file (100 message with
512 * 1024 characters in message payload). This forces a new data file to be
created.
Commit the XA transaction. Commit will land on the new data file.
Restart the Broker.
Upon restart a KahaDB recovery is executed.
The prepare in PageFile 1 is not matched to Commit on PageFile 2, as such, it
will appear in recovered message state.
Looking deeper into this scenario, it appears that the commit message is GC'd,
hence the prepare & commit can not be matched.
The MessageDatabase only checks the following for GC:
{color:#808080}// Don't GC files referenced by in-progress
tx{color}{color:#cc7832}if {color}(inProgressTxRange[{color:#6897bb}0{color}]
!= {color:#cc7832}null{color}) {
{color:#cc7832}for {color}({color:#cc7832}int
{color}pendingTx=inProgressTxRange[{color:#6897bb}0{color}].getDataFileId(){color:#cc7832};
{color}pendingTx <=
inProgressTxRange[{color:#6897bb}1{color}].getDataFileId(){color:#cc7832};
{color}pendingTx++) {
gcCandidateSet.remove(pendingTx){color:#cc7832};{color} }
}
We need to become aware of where the prepare & commits occur in pagefiles with
respect to GCing files.
was:
KahaDB Recovery can experience a dangling transaction when prepare and commit
occur on different pagefiles.
Scenario:
A XA Transaction is started, message is prepared and sent into Broker.
We then send into broker enough messages to file page file (100 message with
512 * 1024 characters in message payload). This forces a new pagefile to be
created.
Commit the XA transaction. Commit will land on the new page file.
Restart the Broker.
Upon restart a KahaDB recovery is executed.
The prepare in PageFile 1 is not matched to Commit on PageFile 2, as such, it
will appear in recovered message state.
Looking deeper into this scenario, it appears that the commit message is GC'd,
hence the prepare & commit can not be matched.
The MessageDatabase only checks the following for GC:
{color:#808080}// Don't GC files referenced by in-progress tx
{color}{color:#cc7832}if {color}(inProgressTxRange[{color:#6897bb}0{color}] !=
{color:#cc7832}null{color}) {
{color:#cc7832}for {color}({color:#cc7832}int
{color}pendingTx=inProgressTxRange[{color:#6897bb}0{color}].getDataFileId(){color:#cc7832};
{color}pendingTx <=
inProgressTxRange[{color:#6897bb}1{color}].getDataFileId(){color:#cc7832};
{color}pendingTx++) {
gcCandidateSet.remove(pendingTx){color:#cc7832};
{color} }
}
We need to become aware of where the prepare & commits occur in pagefiles with
respect to GCing files.
> KahaDB Recovery can experience a dangling transaction when prepare and commit
> occur on different data files.
>
>
> Key: AMQ-7067
> URL: https://issues.apache.org/jira/browse/AMQ-7067
> Project: ActiveMQ
> Issue Type: Bug
> Components: KahaDB, XA
>Affects Versions: 5.15.6
>Reporter: Jamie goodyear
>Priority: Critical
> Fix For: 5.16.0, 5.15.7
>
> Attachments: amq7067test.patch
>
>
> KahaDB Recovery can experience a dangling transaction when prepare and commit
> occur on different data files.
> Scenario:
> A XA Transaction is started, message is prepared and sent into Broker.
> We then send into broker enough messages to file page file (100 message with
> 512 * 1024 characters in message payload). This forces a new data file to be
> created.
> Commit the XA transaction. Commit will land on the new data file.
> Restart the Broker.
> Upon restart a KahaDB recovery is executed.
> The prepare in PageFile 1 is not matched to Commit on PageFile 2, as such, it
> will appear in recovered message state.
> Looking deeper into this scenario, it appears that the commit message is
> GC'd, hence the prepare & commit can not be matched.
> The MessageDatabase only checks the following for GC:
> {color:#808080}// Don't GC files referenced by in-progress
> tx{color}{color:#cc7832}if {color}(inProgressTxRange[{color:#6897bb}0{color}]
> != {color:#cc7832}null{color}) {
> {color:#cc7832}for {color}({color:#cc7832}int
> {color}pendingTx=inProgressTxRange[{color:#6897bb}0{color}].getDataFileId(){color:#cc7832};
> {color}pendingTx <=
> inProgressTxRange[{color:#6897bb}1{color}].getDataFileId(){color:#cc7832};
> {color}pendingTx++) {
> gcCandidateSet.remove(pendingTx){color:#cc7832};{color} }
> }
> We need to become aware of where the prepare & commits
