GitHub user gaohoward opened a pull request:
https://github.com/apache/activemq-artemis/pull/1347
ARTEMIS-1221 Duplicated ID causes LargeMessage lost at backup
When a large message is replicated to backup, a pendingID is generated
when the large message is finished. This pendingID is generated by a
BatchingIDGenerator at backup.
It is possible that a pendingID generated at backup may be a duplicate
to an ID generated at live server.
This can cause a problem when a large message with a messageID that is
the same as another largemessage's pendingID is replicated and stored
in the backup's journal, and then a deleteRecord for the pendingID
is appended. If backup becomes live and loads the journal, it will
drop the large message add record because there is a deleteRecord of
the same ID (even though it is a pendingID of another message).
As a result the expecting client will never get this large message.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gaohoward/activemq-artemis master_1221
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/activemq-artemis/pull/1347.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1347
commit 1111dde2d690c78d42973a653966dbdf32718eb1
Author: Howard Gao <howard.gao@gmail.com>
Date: 2017-06-19T08:31:07Z
ARTEMIS-1221 Duplicated ID causes LargeMessage lost at backup
When a large message is replicated to backup, a pendingID is generated
when the large message is finished. This pendingID is generated by a
BatchingIDGenerator at backup.
It is possible that a pendingID generated at backup may be a duplicate
to an ID generated at live server.
This can cause a problem when a large message with a messageID that is
the same as another largemessage's pendingID is replicated and stored
in the backup's journal, and then a deleteRecord for the pendingID
is appended. If backup becomes live and loads the journal, it will
drop the large message add record because there is a deleteRecord of
the same ID (even though it is a pendingID of another message).
As a result the expecting client will never get this large message.
GitHub user gaohoward opened a pull request:
https://github.com/apache/activemq-artemis/pull/1347
ARTEMIS-1221Duplicated ID causes LargeMessage lost at backupWhen a large message is replicated to backup, a pendingID is generated
when the large message is finished. This pendingID is generated by a
BatchingIDGenerator at backup.
It is possible that a pendingID generated at backup may be a duplicate
to an ID generated at live server.
This can cause a problem when a large message with a messageID that is
the same as another largemessage's pendingID is replicated and stored
in the backup's journal, and then a deleteRecord for the pendingID
is appended. If backup becomes live and loads the journal, it will
drop the large message add record because there is a deleteRecord of
the same ID (even though it is a pendingID of another message).
As a result the expecting client will never get this large message.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gaohoward/activemq-artemis master_1221
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/activemq-artemis/pull/1347.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1347
commit 1111dde2d690c78d42973a653966dbdf32718eb1
Author: Howard Gao <howard.gao@gmail.com>
Date: 2017-06-19T08:31:07Z
ARTEMIS-1221Duplicated ID causes LargeMessage lost at backupWhen a large message is replicated to backup, a pendingID is generated
when the large message is finished. This pendingID is generated by a
BatchingIDGenerator at backup.
It is possible that a pendingID generated at backup may be a duplicate
to an ID generated at live server.
This can cause a problem when a large message with a messageID that is
the same as another largemessage's pendingID is replicated and stored
in the backup's journal, and then a deleteRecord for the pendingID
is appended. If backup becomes live and loads the journal, it will
drop the large message add record because there is a deleteRecord of
the same ID (even though it is a pendingID of another message).
As a result the expecting client will never get this large message.