[jira] [Commented] (OAK-7083) CompositeDataStore - ReadOnly/ReadWrite Delegate Support
[
https://issues.apache.org/jira/browse/OAK-7083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16375128#comment-16375128
]
Matt Ryan commented on OAK-7083:
Let me try to describe in more detail how GC works with the
{{CompositeDataStore}} without the change to {{MarkSweepGarbageCollector}}.
Let's start with the Primary repo. It has three nodes in the repo, A1-A3. It
is connected to data store DS_P which has blobs A1_B-A3-B and a repository file
in it.
{noformat}
P
- A1
- A2
- A3
DS_P
- repository-P
- A1_B
- A2_B
- A3_B
{noformat}
At this point we create the Secondary repo by cloning the Primary. It has a
copy of the Primary node store and refers directly to data store DS_P, which
now has another repository file in it. Secondary also has another data store,
DS_S, which is empty other than the repository file for the Secondary repo.
Note that the {{CompositeDataStore}} writes the metadata files to EVERY
delegate data store, so this way the repository file appears in every data
store.
{noformat}
PS
- A1 - A1
- A2 - A2
- A3 - A3
DS_P DS_S
- repository-P - repository-S
- repository-S
- A1_B
- A2_B
- A3_B
{noformat}
Suppose on Primary nodes A2 and A3 are deleted, and on Secondary nodes A1 and
A3 are deleted. No GC has been run yet. So now we have this:
{noformat}
P S
- A1- (A1-deleted)
- (A2-deleted) - A2
- (A3-deleted) - (A3-deleted)
DS_PDS_S
- repository-P - repository-S
- repository-S
- A1_B
- A2_B
- A3_B
{noformat}
Now on Primary nodes B4 and B5 are created and on Secondary nodes C6 and C7 are
created.
{noformat}
P S
- A1- (A1-deleted)
- (A2-deleted) - A2
- (A3-deleted) - (A3-deleted)
- B4- C6
- B5- C7
DS_PDS_S
- repository-P - repository-S
- repository-S - C6_B
- A1_B - C7_B
- A2_B
- A3_B
- B4_B
- B5_B
{noformat}
Now node B5 is deleted from Primary and node C7 is deleted from Secondary.
Still no GC has been run yet.
{noformat}
P S
- A1- (A1-deleted)
- (A2-deleted) - A2
- (A3-deleted) - (A3-deleted)
- B4- C6
- (B5-deleted) - (C7-deleted)
DS_PDS_S
- repository-P - repository-S
- repository-S - C6_B
- A1_B - C7_B
- A2_B
- A3_B
- B4_B
- B5_B
{noformat}
Let's suppose GC runs and Primary does a mark first. When it is done it will
create a references file with all of the references it knows about that should
be kept.
{noformat}
P S
- A1- (A1-deleted)
- (A2-deleted) - A2
- (A3-deleted) - (A3-deleted)
- B4- C6
- (B5-deleted) - (C7-deleted)
DS_PDS_S
- repository-P - repository-S
- repository-S - C6_B
- references-P (A1, B4) - C7_B
- A1_B
- A2_B
- A3_B
- B4_B
- B5_B
{noformat}
Note at this point Primary cannot complete a sweep because Secondary has not
performed a mark phase yet. There is no references file in DS_P yet from
Secondary.
Later Secondary performs the mark phase and it creates a references file with
all of the references it knows about that should be kept. Notice the references
file gets created in both DS_S and DS_P, since {{CompositeDataStore}} performs
metadata writes to all delegate data stores.
{noformat}
P S
- A1- (A1-deleted)
- (A2-deleted) - A2
- (A3-deleted) - (A3-deleted)
- B4- C6
- (B5-deleted) - (C7-deleted)
DS_PDS_S
- repository-P - repository-S
- repository-S - references-S (A2, C6)
- references-P (A1, B4)
[jira] [Commented] (OAK-7083) CompositeDataStore - ReadOnly/ReadWrite Delegate Support
[
https://issues.apache.org/jira/browse/OAK-7083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16375021#comment-16375021
]
Matt Ryan commented on OAK-7083:
[~amitjain] [~chetanm]
{quote}Is it a requirement that the Primary should not delete blobs used by the
Secondary?
{quote}
I don't know if that was spelled out as a requirement. It seems like an
undesirable situation to have the Primary delete blobs that are still being
referenced by the Secondary. For the specific use case this was meant to
address (production system and staging system sharing the data store) it may be
acceptable that the secondary system have missing blobs, although not ideal.
But it certainly limits the usability of the system for other similar use cases.
{quote}it would still be strange for the Primary (a Production system) to have
to co-ordinate GC with a Secondary (staging or a test system) which it has no
knowledge about.
{quote}
Agreed.
> CompositeDataStore - ReadOnly/ReadWrite Delegate Support
>
>
> Key: OAK-7083
> URL: https://issues.apache.org/jira/browse/OAK-7083
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: blob, blob-cloud, blob-cloud-azure, blob-plugins
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
>
> Support a specific composite data store use case, which is the following:
> * One instance uses no composite data store, but instead is using a single
> standard Oak data store (e.g. FileDataStore)
> * Another instance is created by snapshotting the first instance node store,
> and then uses a composite data store to refer to the first instance's data
> store read-only, and refers to a second data store as a writable data store
> One way this can be used is in creating a test or staging instance from a
> production instance. At creation, the test instance will look like
> production, but any changes made to the test instance do not affect
> production. The test instance can be quickly created from production by
> cloning only the node store, and not requiring a copy of all the data in the
> data store.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-7083) CompositeDataStore - ReadOnly/ReadWrite Delegate Support
[
https://issues.apache.org/jira/browse/OAK-7083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16375012#comment-16375012
]
Matt Ryan commented on OAK-7083:
[~amitjain]
You are right that Proposal 1 and Proposal 2 are not that different.
I think you clarified something I didn't realize before - that in a normal
{{SharedDataStore}} environment, only one of the systems will have the "sweep"
phase scheduled. In other words GC sweep is only ever performed on one system.
I did not realize that.
This scenario CANNOT work with {{CompositeDataStore}} in the use case described
here. It cannot work because there will always be blobs that can only be
deleted by one system or the other. Once both the production and staging
systems are both running and operational, any binaries created on either system
from that point onward that are later deleted can only be garbage collected by
that system.
You said:
{quote}Then we don't have to make any change to the MarkSweepGarbageCollector
and the process will be the same as currently for normal deployments.
{quote}
I do not agree with that statement. I do not think it is possible for GC to
work in an environment with {{CompositeDataStore}} unless some code changes are
made to the garbage collector. Either we need to make these changes to the
{{MarkSweepGarbageCollector}} or we have to make another garbage collector that
is designed to work with {{CompositeDataStore}}.
{quote}Essentially, I am Ok with proposal 2 for a start
{quote}
In my view, Proposal 2 offers no real advantages to Proposal 1 but adds
complexity due to the requirement to coordinate between repositories on the
mark phase, beyond what is already being done. With both proposals it is still
required to make changes to the garbage collector and it is still required that
ALL repositories perform the sweep phase.
{quote}then we can enhance with the proposal that I outlined of encoding the
blob ids with the role/type of the DataStore. Could you please also add a
response on the clarifications I had above.
{quote}
I haven't forgotten this part, Amit. But currently no encoding is being done.
That's not the approach that was taken. I am not convinced yet that it is
needed or that we want to tie blobs tightly to the repository that wrote them.
I'd like to first settle on an approach to this GC issue and then see if that
additional step is actually required.
> CompositeDataStore - ReadOnly/ReadWrite Delegate Support
>
>
> Key: OAK-7083
> URL: https://issues.apache.org/jira/browse/OAK-7083
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: blob, blob-cloud, blob-cloud-azure, blob-plugins
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
>
> Support a specific composite data store use case, which is the following:
> * One instance uses no composite data store, but instead is using a single
> standard Oak data store (e.g. FileDataStore)
> * Another instance is created by snapshotting the first instance node store,
> and then uses a composite data store to refer to the first instance's data
> store read-only, and refers to a second data store as a writable data store
> One way this can be used is in creating a test or staging instance from a
> production instance. At creation, the test instance will look like
> production, but any changes made to the test instance do not affect
> production. The test instance can be quickly created from production by
> cloning only the node store, and not requiring a copy of all the data in the
> data store.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7283) Clarify usage of index-definitions-file and index-paths params when used in conjuction
[
https://issues.apache.org/jira/browse/OAK-7283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-7283:
---
Description:
Currently oak-run out of band indexing documentation \[0] says that
{{--index-paths}} is a required parameter.
But, with experimental usage, it seems that the paths to index is decided by
joining list from {{\-\-index\-paths}} (if provided) and paths listed in file
mentioned by {{--index-defnitions-file}} (if provided).
At least on of those parameters must be provided (afaics).
_Disclaimer_: The title of the issue could be a bit mis-leading by using
conjuction
\[0]:
https://jackrabbit.apache.org/oak/docs/query/oak-run-indexing.html#out-of-band-indexing
was:
Currently oak-run out of band indexing documentation \[0] says that
{{--index-paths}} is a required parameter.
But, with experimental usage, it seems that the paths to index is decided by
joining list from {{--index-paths}} (if provided) and paths listed in file
mentioned by {{--index-defnitions-file}} (if provided).
At least on of those parameters must be provided (afaics).
_Disclaimer_: The title of the issue could be a bit mis-leading by using
conjuction
\[0]:
https://jackrabbit.apache.org/oak/docs/query/oak-run-indexing.html#out-of-band-indexing
> Clarify usage of index-definitions-file and index-paths params when used in
> conjuction
> --
>
> Key: OAK-7283
> URL: https://issues.apache.org/jira/browse/OAK-7283
> Project: Jackrabbit Oak
> Issue Type: Documentation
>Reporter: Vikas Saurabh
>Priority: Major
>
> Currently oak-run out of band indexing documentation \[0] says that
> {{--index-paths}} is a required parameter.
> But, with experimental usage, it seems that the paths to index is decided by
> joining list from {{\-\-index\-paths}} (if provided) and paths listed in file
> mentioned by {{--index-defnitions-file}} (if provided).
> At least on of those parameters must be provided (afaics).
> _Disclaimer_: The title of the issue could be a bit mis-leading by using
> conjuction
> \[0]:
> https://jackrabbit.apache.org/oak/docs/query/oak-run-indexing.html#out-of-band-indexing
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-7283) Clarify usage of index-definitions-file and index-paths params when used in conjuction
[
https://issues.apache.org/jira/browse/OAK-7283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16374986#comment-16374986
]
Vikas Saurabh commented on OAK-7283:
Btw, imo, if {{--index-paths}} is provided then that's the only list that must
be used - it kind of makes reindexing process simpler by first preparing all
defs in a file and then reindex only a subset of those. (I understand that's a
behavior change... just that what felt more intuitive to me).
> Clarify usage of index-definitions-file and index-paths params when used in
> conjuction
> --
>
> Key: OAK-7283
> URL: https://issues.apache.org/jira/browse/OAK-7283
> Project: Jackrabbit Oak
> Issue Type: Documentation
>Reporter: Vikas Saurabh
>Priority: Major
>
> Currently oak-run out of band indexing documentation \[0] says that
> {{--index-paths}} is a required parameter.
> But, with experimental usage, it seems that the paths to index is decided by
> joining list from {{--index-paths}} (if provided) and paths listed in file
> mentioned by {{--index-defnitions-file}} (if provided).
> At least on of those parameters must be provided (afaics).
> _Disclaimer_: The title of the issue could be a bit mis-leading by using
> conjuction
> \[0]:
> https://jackrabbit.apache.org/oak/docs/query/oak-run-indexing.html#out-of-band-indexing
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-7283) Clarify usage of index-definitions-file and index-paths params when used in conjuction
[
https://issues.apache.org/jira/browse/OAK-7283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16374985#comment-16374985
]
Vikas Saurabh commented on OAK-7283:
[~chetanm], could you please review this issue and update the doc as you see
fit?
> Clarify usage of index-definitions-file and index-paths params when used in
> conjuction
> --
>
> Key: OAK-7283
> URL: https://issues.apache.org/jira/browse/OAK-7283
> Project: Jackrabbit Oak
> Issue Type: Documentation
>Reporter: Vikas Saurabh
>Priority: Major
>
> Currently oak-run out of band indexing documentation \[0] says that
> {{--index-paths}} is a required parameter.
> But, with experimental usage, it seems that the paths to index is decided by
> joining list from {{--index-paths}} (if provided) and paths listed in file
> mentioned by {{--index-defnitions-file}} (if provided).
> At least on of those parameters must be provided (afaics).
> _Disclaimer_: The title of the issue could be a bit mis-leading by using
> conjuction
> \[0]:
> https://jackrabbit.apache.org/oak/docs/query/oak-run-indexing.html#out-of-band-indexing
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OAK-7283) Clarify usage of index-definitions-file and index-paths params when used in conjuction
Vikas Saurabh created OAK-7283:
--
Summary: Clarify usage of index-definitions-file and index-paths
params when used in conjuction
Key: OAK-7283
URL: https://issues.apache.org/jira/browse/OAK-7283
Project: Jackrabbit Oak
Issue Type: Documentation
Reporter: Vikas Saurabh
Currently oak-run out of band indexing documentation \[0] says that
{{--index-paths}} is a required parameter.
But, with experimental usage, it seems that the paths to index is decided by
joining list from {{--index-paths}} (if provided) and paths listed in file
mentioned by {{--index-defnitions-file}} (if provided).
At least on of those parameters must be provided (afaics).
_Disclaimer_: The title of the issue could be a bit mis-leading by using
conjuction
\[0]:
https://jackrabbit.apache.org/oak/docs/query/oak-run-indexing.html#out-of-band-indexing
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-7282) RDB: enable default continuous revision GC
[ https://issues.apache.org/jira/browse/OAK-7282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16374483#comment-16374483 ] Julian Reschke commented on OAK-7282: - Potential change https://issues.apache.org/jira/secure/attachment/12911739/OAK-7282.diff which already seems to work. [~mreutegg] - is there something else (besides documentation) that needs to be done? > RDB: enable default continuous revision GC > -- > > Key: OAK-7282 > URL: https://issues.apache.org/jira/browse/OAK-7282 > Project: Jackrabbit Oak > Issue Type: Task > Components: documentmk, rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Fix For: 1.10 > > Attachments: OAK-7282.diff > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7282) RDB: enable default continuous revision GC
[ https://issues.apache.org/jira/browse/OAK-7282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-7282: Attachment: OAK-7282.diff > RDB: enable default continuous revision GC > -- > > Key: OAK-7282 > URL: https://issues.apache.org/jira/browse/OAK-7282 > Project: Jackrabbit Oak > Issue Type: Task > Components: documentmk, rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Fix For: 1.10 > > Attachments: OAK-7282.diff > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7202) RDB: potential optimization - avoid creating strings and byte arrays for serialization
[
https://issues.apache.org/jira/browse/OAK-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-7202:
Summary: RDB: potential optimization - avoid creating strings and byte
arrays for serialization (was: RDB: potential optimization - avoid creatring
strings and byte arrays for serialization)
> RDB: potential optimization - avoid creating strings and byte arrays for
> serialization
> --
>
> Key: OAK-7202
> URL: https://issues.apache.org/jira/browse/OAK-7202
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: rdbmk
>Reporter: Julian Reschke
>Priority: Minor
> Attachments: OAK-7202.diff
>
>
> We might be able avoid some temprary objects by changing the serializer to
> return {{StringBuilder}} or {{CharSequence}} instances instead of
> {{Strings}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OAK-7282) RDB: enable default continuous revision GC
Julian Reschke created OAK-7282: --- Summary: RDB: enable default continuous revision GC Key: OAK-7282 URL: https://issues.apache.org/jira/browse/OAK-7282 Project: Jackrabbit Oak Issue Type: Task Components: documentmk, rdbmk Reporter: Julian Reschke Assignee: Julian Reschke Fix For: 1.10 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7281) DocumentStore: long path handling looses information when strings are invalid
[
https://issues.apache.org/jira/browse/OAK-7281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16374328#comment-16374328
]
Julian Reschke commented on OAK-7281:
-
https://issues.apache.org/jira/secure/attachment/12911721/OAK-7281.diff
modifies {{Utils}} to use the non-permissive encoder, and also takes advantage
of not having to create byte arrays everywhere.
> DocumentStore: long path handling looses information when strings are invalid
> -
>
> Key: OAK-7281
> URL: https://issues.apache.org/jira/browse/OAK-7281
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk
>Reporter: Julian Reschke
>Priority: Minor
> Attachments: OAK-7281.diff
>
>
> The various methods related to long paths in
> {{org.apache.jackrabbit.oak.plugins.document.util.Utils}} use
> {{String.getBytes()}} which will map invalid inputs to the same replacement
> character. Thus multiple long paths might map to the same hash.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7281) DocumentStore: long path handling looses information when strings are invalid
[
https://issues.apache.org/jira/browse/OAK-7281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-7281:
Attachment: OAK-7281.diff
> DocumentStore: long path handling looses information when strings are invalid
> -
>
> Key: OAK-7281
> URL: https://issues.apache.org/jira/browse/OAK-7281
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk
>Reporter: Julian Reschke
>Priority: Minor
> Attachments: OAK-7281.diff
>
>
> The various methods related to long paths in
> {{org.apache.jackrabbit.oak.plugins.document.util.Utils}} use
> {{String.getBytes()}} which will map invalid inputs to the same replacement
> character. Thus multiple long paths might map to the same hash.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OAK-7281) DocumentStore: long path handling looses information when strings are invalid
Julian Reschke created OAK-7281:
---
Summary: DocumentStore: long path handling looses information when
strings are invalid
Key: OAK-7281
URL: https://issues.apache.org/jira/browse/OAK-7281
Project: Jackrabbit Oak
Issue Type: Bug
Components: documentmk
Reporter: Julian Reschke
The various methods related to long paths in
{{org.apache.jackrabbit.oak.plugins.document.util.Utils}} use
{{String.getBytes()}} which will map invalid inputs to the same replacement
character. Thus multiple long paths might map to the same hash.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-7276) Build Jackrabbit Oak #1256 failed
[ https://issues.apache.org/jira/browse/OAK-7276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16374308#comment-16374308 ] Hudson commented on OAK-7276: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #1260|https://builds.apache.org/job/Jackrabbit%20Oak/1260/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/1260/console] > Build Jackrabbit Oak #1256 failed > - > > Key: OAK-7276 > URL: https://issues.apache.org/jira/browse/OAK-7276 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #1256 has failed. > First failed run: [Jackrabbit Oak > #1256|https://builds.apache.org/job/Jackrabbit%20Oak/1256/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/1256/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7225) Replace AtomicCounter Supplier
[ https://issues.apache.org/jira/browse/OAK-7225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16374222#comment-16374222 ] Julian Reschke commented on OAK-7225: - OK, thanks for the explanation. So go ahead and commit :-). > Replace AtomicCounter Supplier > -- > > Key: OAK-7225 > URL: https://issues.apache.org/jira/browse/OAK-7225 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: core >Affects Versions: 1.4.0, 1.6.0 >Reporter: Davide Giannella >Assignee: Davide Giannella >Priority: Major > Attachments: OAK-7225-0.diff > > > In the > [AtomicCounter|https://github.com/apache/jackrabbit-oak/blob/7a7aa1e5d4f53f5bfb410f58264c237b288f5c74/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/atomic/AtomicCounterEditorProvider.java#L121] > we use guava's Supplier which should be trivially replaced by the JDK8 > [java.util.function.Supplier|https://docs.oracle.com/javase/8/docs/api/java/util/function/Supplier.html]. > In case of backports to Oak 1.4, and therefore Java7 it should be possible to > workaround the FunctionalInterface with a utility class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7225) Replace AtomicCounter Supplier
[ https://issues.apache.org/jira/browse/OAK-7225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16374099#comment-16374099 ] Davide Giannella commented on OAK-7225: --- It's not public API but is used during repository construction, when you register you want to have an atomic counter functionality. So it's kind-of middle-ground between public and private. IMO replacing with standard java will help us in the future in case anything change on the guava side, and the change if you can see it's very trivial with very low risk. Tell me if you have anything against the patch, otherwise I will commit it next week. Getting rid of guava completely was definitely out of scope but as I was investigating, I thought, let me see what it would take. Eventually the less we depends on external library the less the impact a change in those will have on us. > Replace AtomicCounter Supplier > -- > > Key: OAK-7225 > URL: https://issues.apache.org/jira/browse/OAK-7225 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: core >Affects Versions: 1.4.0, 1.6.0 >Reporter: Davide Giannella >Assignee: Davide Giannella >Priority: Major > Attachments: OAK-7225-0.diff > > > In the > [AtomicCounter|https://github.com/apache/jackrabbit-oak/blob/7a7aa1e5d4f53f5bfb410f58264c237b288f5c74/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/atomic/AtomicCounterEditorProvider.java#L121] > we use guava's Supplier which should be trivially replaced by the JDK8 > [java.util.function.Supplier|https://docs.oracle.com/javase/8/docs/api/java/util/function/Supplier.html]. > In case of backports to Oak 1.4, and therefore Java7 it should be possible to > workaround the FunctionalInterface with a utility class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7280) Remove superfluous methods from SegmentWriter
[
https://issues.apache.org/jira/browse/OAK-7280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16374066#comment-16374066
]
Francesco Mari commented on OAK-7280:
-
Work in progress in [this branch on
GithHub|https://github.com/francescomari/jackrabbit-oak/tree/OAK-7280].
[~mduerig], [~dulceanu], can you please review?
> Remove superfluous methods from SegmentWriter
> -
>
> Key: OAK-7280
> URL: https://issues.apache.org/jira/browse/OAK-7280
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Major
> Fix For: 1.10
>
>
> Some methods in {{SegmentWriter}} are only used in test code. Production code
> works only on a much smaller subset of the methods exposed by
> {{SegmentWriter}}. As such, the superfluous methods should be removed and the
> tests adapted.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
