[
https://issues.apache.org/jira/browse/OAK-3294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14711455#comment-14711455
]
Alex Parvulescu edited comment on OAK-3294 at 8/25/15 3:37 PM:
---------------------------------------------------------------
[proposed patch|^OAK-3294.patch].
I had a lot of issues getting the RO store to be as real-time as possible,
meaning being able to open the tar file that's being currently written to.
Depending on the size, the RO store would lag behind quite a bit. After a few
back and forth the solution I went with was to try to recreate this tar file
similarly to a recover operation and pass this into the RO store. This
intermediary file is called _data0000Xa.tar.ro.bak_ and can be considered
garbage once the RO store is closed. Again this only applies to files that are
open by a writer in a different process (identified by not having a proper tar
index).
I turned a few components into Closeables, I think this is useful for resource
cleanup, but I'm not convinced on the current overall approach we have when it
comes to IOExceptions. I see very few finally blocks, so if something fails
what's the best recovery option? To further this point I wanter to use
_closeQuietly_ on the writer too, but maybe I'm taking this too far. We could
eventually continue this on a different issue.
TODO: look into automatically removing the potential garbage file.
I didn't start running all the IT tests, I'll do that next.
[~mduerig], [~frm] feedback appreciated!
was (Author: alex.parvulescu):
[proposed patch|^OAK-3294.patch].
I had a lot of issues getting the RO store to be as real-time as possible,
meaning being able to open the tar file that's being currently written to.
Depending on the size, the RO store would lag behind quite a bit. After a few
back and forth the solution I went with was to try to recreate this tar file
similarly to a recover operation and pass this into the RO store. This
intermediary file is called _data0000Xa.tar.ro.bak_ and can be considered
garbage once the RO store is closed. Again this only applies to files that are
open by a writer in a different process (identified by not having a proper tar
index).
I turned a few components into _Closeable_s, I think this is useful for
resource cleanup, but I'm not convinced on the current overall approach we have
when it comes to IOExceptions. I see very few finally blocks, so if something
fails what's the best recovery option? To further this point I wanter to use
_closeQuietly_ on the writer too, but maybe I'm taking this too far. We could
eventually continue this on a different issue.
TODO: look into automatically removing the potential garbage file.
I didn't start running all the IT tests, I'll do that next.
[~mduerig], [~frm] feedback appreciated!
> Read-only live FileStore implementation
> ---------------------------------------
>
> Key: OAK-3294
> URL: https://issues.apache.org/jira/browse/OAK-3294
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segmentmk
> Reporter: Alex Parvulescu
> Assignee: Alex Parvulescu
> Priority: Minor
> Attachments: OAK-3294.patch
>
>
> Having a read-only FileStore able to work on a running (live) FileStore would
> open the door for some interesting data collection & debugging tools that no
> longer need the repository to be shut down.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
