jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davide Giannella (JIRA)" <j...@apache.org>
Subject [jira] [Closed] (OAK-6661) ResponseDecoder should check that the length of the received blob matches the length of the sent blob
Date Fri, 29 Sep 2017 10:10:07 GMT

     [ https://issues.apache.org/jira/browse/OAK-6661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Davide Giannella closed OAK-6661.
---------------------------------

Bulk close for 1.7.8

> ResponseDecoder should check that the length of the received blob matches the length
of the sent blob
> -----------------------------------------------------------------------------------------------------
>
>                 Key: OAK-6661
>                 URL: https://issues.apache.org/jira/browse/OAK-6661
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: segment-tar, tarmk-standby
>    Affects Versions: 1.7.6
>            Reporter: Andrei Dulceanu
>            Assignee: Andrei Dulceanu
>              Labels: cold-standby
>             Fix For: 1.7.8
>
>         Attachments: OAK-6661.patch
>
>
> As already explained in OAK-6659, there can be cases in which deleting the previous spool
file fails (Windows) and new (duplicate) content is added under the hood to the old file.
This way the persisted blob doesn't match in content and id with the original sent by the
server.
> A first improvement here is to not allow the decoding to continue if the old spool file
cannot be deleted. For this, the call to {{File#delete}} needs to be replaced with {{java.nio.file.Files#delete}}
which would throw an exception if something wrong happens.
> By ensuring that the spool file has the same size as the original blob we solve this
problem. This check is sufficient, since all the chunks received are individually checked
by hash, before appending them to the spool file. Moreover, the single threaded nature of
the client ensures that races in which a new thread starts appending new content, after the
length check has just passed can never happen.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message