[
https://issues.apache.org/jira/browse/ARTEMIS-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16057780#comment-16057780
]
ASF GitHub Bot commented on ARTEMIS-1221:
-----------------------------------------
Github user clebertsuconic commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/1347#discussion_r123297601
--- Diff:
artemis-server/src/main/java/org/apache/activemq/artemis/core/protocol/core/impl/wireformat/ReplicationLargeMessageBeginMessage.java
---
@@ -44,11 +46,13 @@ public int expectedEncodeSize() {
@Override
public void encodeRest(final ActiveMQBuffer buffer) {
buffer.writeLong(messageId);
--- End diff --
I'm not sure how this is possibly working...
expectedEncodeSize is not taking this new long into consideration...
Besides this will cause versioning issues...
So, you will need to do something like this on reading...
On reading.. you will need to verify the positioning of the buffer..
against the declared size.. if there's another long coming.. otherwise it
wouldn't read it.. and use the current semantic.
this is a -1.. can you fix it?
> Duplicated ID causes LargeMessage lost at backup
> ------------------------------------------------
>
> Key: ARTEMIS-1221
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1221
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
> Affects Versions: 1.5.5, 2.1.0
> Reporter: Howard Gao
> Assignee: Howard Gao
> Fix For: 1.5.6, 2.2.0
>
>
> 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.
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
