[
https://issues.apache.org/jira/browse/IGNITE-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14965598#comment-14965598
]
Ivan Veselovsky commented on IGNITE-1743:
-----------------------------------------
It looks like minimal change is to modify method
org.apache.ignite.internal.processors.igfs.IgfsDataManager#processBatch
(IgfsDataManager, lines 1013 - 1050) replacing the IgfsBlocksMessage sending
with async cache.put() invocations with getting their futures, + changing the
org.apache.ignite.internal.processors.igfs.IgfsDataManager#processAckMessage
method marking those stored futures as completed.
Questions:
1) logic of differentiating collocated/non-collocated keys in method
org.apache.ignite.internal.processors.igfs.IgfsDataManager#processPartialBlockWrite
is not quite clear to me. (But may be we can leave it as is.)
2) We should state a solid contract of writing to secondary file system (dual
modes). Currently writing to the 2ndary fs is implemented via
org.apache.ignite.internal.processors.igfs.IgfsFileWorkerBatch class: this is a
runnable that asynchronously duplicates primary Fs writing to the 2ndary Fs
(asynchronously because the data slices are put into a queue and taken from
there by the worker runnable on another thread). The implementation is waiting
for this 2ndary write completion *only* in case of DUAL_SYNC mode. But in
DUAL_ASYNC mode we may complete primary write, while write to the 2ndary Fs is
not completed. This way, on an error on 2ndary Fs the file may be not
completely written on the 2ndary Fs. Is this correct behavior, and may we give
more guarantees in this case?
> IGFS: use async cache put instead of block/ack messages on data write
> ---------------------------------------------------------------------
>
> Key: IGNITE-1743
> URL: https://issues.apache.org/jira/browse/IGNITE-1743
> Project: Ignite
> Issue Type: Sub-task
> Reporter: Ivan Veselovsky
> Assignee: Ivan Veselovsky
> Fix For: 1.5
>
>
> Item "1)" from IGNITE-1697
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
