[
https://issues.apache.org/jira/browse/GEODE-2472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15941304#comment-15941304
]
ASF subversion and git services commented on GEODE-2472:
--------------------------------------------------------
Commit 517bb6227304545d5c0cad1e9c516a336d83434b in geode's branch
refs/heads/develop from [~agingade]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=517bb62 ]
GEODE-2472 changes are made to ensure byte array is completely flushed to oplog
channel.
The Oplog and OverflowOplog flush(OplogFile olf, ByteBuffer b1, ByteBuffer b2)
method doesn't check the results of the channel.write() call.
It could so happen partial byte array is written to the channel. The check is
added to make sure the bytes are completely written to the file channel.
> Oplog.flush method doesn't verify that the entry gets written
> -------------------------------------------------------------
>
> Key: GEODE-2472
> URL: https://issues.apache.org/jira/browse/GEODE-2472
> Project: Geode
> Issue Type: Improvement
> Components: persistence
> Reporter: Kenneth Howe
> Assignee: Anilkumar Gingade
>
> The Oplog.flush(OplogFile olf, ByteBuffer b1, ByteBuffer b2) method doesn't
> check the results of the channel.write() call. The other Oplog.flush() method
> that performs a channel write wraps the write() call in the loop
> {code}
> do {
> ...
> } while (hasRemaining);
> {code}
> to make sure the Oplog entry is written to the OplogFile.
> This method is implemented without the check loop, making the assumption that
> the write() completely writes everything from both buffers. Defensive
> programming would suggest that the results of lower level calls are checked.
> Failure to recognize a partial write to the OplogFile can result in a corrupt
> oplog that isn't found until the persistent disk store is recovered.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
