[
https://issues.apache.org/jira/browse/ARTEMIS-1220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16057754#comment-16057754
]
ASF GitHub Bot commented on ARTEMIS-1220:
-----------------------------------------
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/1351
@gaohoward nice catch!
Can we do it differntly... change LargeServerMessageImpl to not reuse the
same buffer instead?
this will introduce an extra copy for regular cases.. I would rather keep
the hot path unchnaged.. and only cause the extra copy on the actualy copy.
That is...
```java
for (;;) {
byte[] bufferBytes = new byte[100 * 1024];
ByteBuffer buffer = ByteBuffer.wrap(bufferBytes);
// The buffer is reused...
// We need to make sure we clear the limits and the buffer
before reusing it
buffer.clear();
int bytesRead = file.read(buffer);
byte[] bufferToWrite;
if (bytesRead <= 0) {
break;
} else if (bytesRead == bufferBytes.length) {
bufferToWrite = bufferBytes;
} else {
bufferToWrite = new byte[bytesRead];
System.arraycopy(bufferBytes, 0, bufferToWrite, 0,
bytesRead);
}
newMessage.addBytes(bufferToWrite);
if (bytesRead < bufferBytes.length) {
break;
}
}
```
> Diverted LargeMessage file corrupted during replication
> -------------------------------------------------------
>
> Key: ARTEMIS-1220
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1220
> 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 being diverted, a new copy of the original message is
> created and replicated (if there is a backup) to the backup.
> In LargeServerMessageImpl.copy(long) it reuse a byte array to copy message
> body. It is possible that one block of date is read into the byte array
> before the previous read has been replicated, causing the replicated bytes to
> corrupt.
> If we make a copy of the byte array before replication, the corruption of
> data will be avoided.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
