[jira] [Commented] (OAK-6943) Build failure: baseline error for o.a.j.o.spi.xml
[
https://issues.apache.org/jira/browse/OAK-6943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252898#comment-16252898
]
Hudson commented on OAK-6943:
-
Build is still failing.
Failed run: [Jackrabbit Oak
#973|https://builds.apache.org/job/Jackrabbit%20Oak/973/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/973/console]
> Build failure: baseline error for o.a.j.o.spi.xml
> -
>
> Key: OAK-6943
> URL: https://issues.apache.org/jira/browse/OAK-6943
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
> Fix For: 1.8
>
>
> No description is provided
> The build Jackrabbit Oak #971 has failed.
> First failed run: [Jackrabbit Oak
> #971|https://builds.apache.org/job/Jackrabbit%20Oak/971/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/971/console]
> Build failure is:
> {noformat}
> [INFO] --- maven-bundle-plugin:3.3.0:baseline (baseline) @ oak-security-spi
> ---
> [ERROR] org.apache.jackrabbit.oak.spi.xml: Version increase required;
> detected 0.0.1, suggested 1.0.0
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (OAK-6905) Query engine: support coalesce function as in-built method
[
https://issues.apache.org/jira/browse/OAK-6905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh resolved OAK-6905.
Resolution: Fixed
Fix Version/s: 1.7.12
Done on trunk at:
* [r1815284|https://svn.apache.org/r1815284] - Implement coalesce parsing in
query engine
* [r1815285|https://svn.apache.org/r1815285] - Implement coalesce in lucene
index
[~tmueller], can you please review that I didn't miss something. In particular,
for changes in oak-lucene (r1815285), quite a few changes were required to
parse 2 parameters for coalesce.
> Query engine: support coalesce function as in-built method
> --
>
> Key: OAK-6905
> URL: https://issues.apache.org/jira/browse/OAK-6905
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, lucene, query
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Fix For: 1.8, 1.7.12
>
>
> Sometimes the content structure stores semantically similar properties at
> different locations (due to content evolution or different locations
> genuinely represent different values).
> e.g. say a content represent a real world image as
> {{/file1.jpg/jcr:content/file}}. Where
> {{jcr:content/metadata/exif:title}} could be title of image from exif data,
> {{jcr:content/jcr:title}} could be title explicitly set by user.
> While displaying a title, it probably makes sense to show {{jcr:title}} first
> and fallback to {{exif:title}} and then probaly to node name if nothing else
> works out.
> it'd would be useful to have such overlaying be conveyed to query engine too
> for lookup, ordering (and, of course, indexing). As a method name, sql
> colesce is exactly what should serve this purpose.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (OAK-6943) Build failure: baseline error for o.a.j.o.spi.xml
[
https://issues.apache.org/jira/browse/OAK-6943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger reassigned OAK-6943:
-
Assignee: (was: Marcel Reutegger)
> Build failure: baseline error for o.a.j.o.spi.xml
> -
>
> Key: OAK-6943
> URL: https://issues.apache.org/jira/browse/OAK-6943
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
> Fix For: 1.8
>
>
> No description is provided
> The build Jackrabbit Oak #971 has failed.
> First failed run: [Jackrabbit Oak
> #971|https://builds.apache.org/job/Jackrabbit%20Oak/971/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/971/console]
> Build failure is:
> {noformat}
> [INFO] --- maven-bundle-plugin:3.3.0:baseline (baseline) @ oak-security-spi
> ---
> [ERROR] org.apache.jackrabbit.oak.spi.xml: Version increase required;
> detected 0.0.1, suggested 1.0.0
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6943) Build failure: baseline error for o.a.j.o.spi.xml
[
https://issues.apache.org/jira/browse/OAK-6943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-6943:
--
Summary: Build failure: baseline error for o.a.j.o.spi.xml (was: Build
Jackrabbit Oak #971 failed)
> Build failure: baseline error for o.a.j.o.spi.xml
> -
>
> Key: OAK-6943
> URL: https://issues.apache.org/jira/browse/OAK-6943
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>Assignee: Marcel Reutegger
> Fix For: 1.8
>
>
> No description is provided
> The build Jackrabbit Oak #971 has failed.
> First failed run: [Jackrabbit Oak
> #971|https://builds.apache.org/job/Jackrabbit%20Oak/971/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/971/console]
> Build failure is:
> {noformat}
> [INFO] --- maven-bundle-plugin:3.3.0:baseline (baseline) @ oak-security-spi
> ---
> [ERROR] org.apache.jackrabbit.oak.spi.xml: Version increase required;
> detected 0.0.1, suggested 1.0.0
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (OAK-6943) Build Jackrabbit Oak #971 failed
[
https://issues.apache.org/jira/browse/OAK-6943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger reassigned OAK-6943:
-
Assignee: Marcel Reutegger
> Build Jackrabbit Oak #971 failed
>
>
> Key: OAK-6943
> URL: https://issues.apache.org/jira/browse/OAK-6943
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>Assignee: Marcel Reutegger
> Fix For: 1.8
>
>
> No description is provided
> The build Jackrabbit Oak #971 has failed.
> First failed run: [Jackrabbit Oak
> #971|https://builds.apache.org/job/Jackrabbit%20Oak/971/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/971/console]
> Build failure is:
> {noformat}
> [INFO] --- maven-bundle-plugin:3.3.0:baseline (baseline) @ oak-security-spi
> ---
> [ERROR] org.apache.jackrabbit.oak.spi.xml: Version increase required;
> detected 0.0.1, suggested 1.0.0
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Reopened] (OAK-6938) Add package export version for spi.xml
[ https://issues.apache.org/jira/browse/OAK-6938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger reopened OAK-6938: --- This change breaks the build. See OAK-6943. > Add package export version for spi.xml > -- > > Key: OAK-6938 > URL: https://issues.apache.org/jira/browse/OAK-6938 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: security-spi >Reporter: angela >Assignee: angela >Priority: Minor > Fix For: 1.8, 1.7.12 > > > [~mduerig], for example this one :-) > [~stillalex], any objection to add proper export version for the spi.xml > package space? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6943) Build Jackrabbit Oak #971 failed
[
https://issues.apache.org/jira/browse/OAK-6943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-6943:
--
Description:
No description is provided
The build Jackrabbit Oak #971 has failed.
First failed run: [Jackrabbit Oak
#971|https://builds.apache.org/job/Jackrabbit%20Oak/971/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/971/console]
Build failure is:
{noformat}
[INFO] --- maven-bundle-plugin:3.3.0:baseline (baseline) @ oak-security-spi ---
[ERROR] org.apache.jackrabbit.oak.spi.xml: Version increase required; detected
0.0.1, suggested 1.0.0
{noformat}
was:
No description is provided
The build Jackrabbit Oak #971 has failed.
First failed run: [Jackrabbit Oak
#971|https://builds.apache.org/job/Jackrabbit%20Oak/971/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/971/console]
> Build Jackrabbit Oak #971 failed
>
>
> Key: OAK-6943
> URL: https://issues.apache.org/jira/browse/OAK-6943
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
> Fix For: 1.8
>
>
> No description is provided
> The build Jackrabbit Oak #971 has failed.
> First failed run: [Jackrabbit Oak
> #971|https://builds.apache.org/job/Jackrabbit%20Oak/971/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/971/console]
> Build failure is:
> {noformat}
> [INFO] --- maven-bundle-plugin:3.3.0:baseline (baseline) @ oak-security-spi
> ---
> [ERROR] org.apache.jackrabbit.oak.spi.xml: Version increase required;
> detected 0.0.1, suggested 1.0.0
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (OAK-6319) Review API and Utilities in oak.plugins.tree package
[ https://issues.apache.org/jira/browse/OAK-6319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-6319. - Resolution: Fixed Fix Version/s: 1.8 > Review API and Utilities in oak.plugins.tree package > > > Key: OAK-6319 > URL: https://issues.apache.org/jira/browse/OAK-6319 > Project: Jackrabbit Oak > Issue Type: Task > Components: core >Reporter: angela > Fix For: 1.8 > > > As explained in OAK-6318 the _o.a.j.oak.plugins.tree_ package space contains > an unfortunate mixture of API and utilities that prevents us from moving > forward with the modularization effort. > I would therefore suggest to review the existing package and it's usages > across the oak code base. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (OAK-6125) Consider hierarchical module structure
[
https://issues.apache.org/jira/browse/OAK-6125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-6125.
-
Resolution: Later
> Consider hierarchical module structure
> --
>
> Key: OAK-6125
> URL: https://issues.apache.org/jira/browse/OAK-6125
> Project: Jackrabbit Oak
> Issue Type: Task
>Reporter: angela
>
> Quote from [~mduerig] on the original m12n thread on oak-dev:
> {quote}
> Looking at the list of modules, its size and the names, did you consider
> switching to a hierarchical module structure? Or could this make sense
> later on? Otherwise can we come up with a naming scheme that implies
> grouping (e.g. node store implementations, blob store implementations,
> etc.)
> {quote}
> Possible candidates as Michael already mentioned:
> - "getting-started": {{oak-examples}} and {{oak-exercise}}
> - "blob": {{oak-blob}}, {{oak-blob-plugins}}, {{oak-blob-cloud}} and
> {{oak-blob-clould-azure}}
> - "node store": {{oak-store-spi}}, {{oak-segment-tar}} and later on also
> document store implementations
> Additionally I think of the following:
> - "query": {{oak-lucene}}, {{oak-solr-core}}, {{oak-solr-osgi}} and possibly
> the query and index code from {{oak-core}} if we would manage to isolate that
> - "security": {{oak-auth-external}}, {{oak-auth-ldap}},
> {{oak-authorization-cug}} and possibly the security-spi and default impl if
> we would manage to isolate that from oak-core.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6943) Build Jackrabbit Oak #971 failed
[ https://issues.apache.org/jira/browse/OAK-6943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252052#comment-16252052 ] Hudson commented on OAK-6943: - Build is still failing. Failed run: [Jackrabbit Oak #972|https://builds.apache.org/job/Jackrabbit%20Oak/972/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/972/console] > Build Jackrabbit Oak #971 failed > > > Key: OAK-6943 > URL: https://issues.apache.org/jira/browse/OAK-6943 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson > Fix For: 1.8 > > > No description is provided > The build Jackrabbit Oak #971 has failed. > First failed run: [Jackrabbit Oak > #971|https://builds.apache.org/job/Jackrabbit%20Oak/971/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/971/console] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (OAK-6882) ObservationQueueFullWarnTest.testQueueFullThenFlushing failing
[
https://issues.apache.org/jira/browse/OAK-6882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh resolved OAK-6882.
Resolution: Fixed
Fix Version/s: 1.7.12
1.8
Committed above-mentioned patch in trunk at
[r1815254|https://svn.apache.org/r1815254]. [~reschke], I'm resolving the issue
for now - we can re-open if it doesn't seem to stick.
> ObservationQueueFullWarnTest.testQueueFullThenFlushing failing
> --
>
> Key: OAK-6882
> URL: https://issues.apache.org/jira/browse/OAK-6882
> Project: Jackrabbit Oak
> Issue Type: Test
> Components: jcr
>Affects Versions: 1.7.10
>Reporter: Julian Reschke
>Assignee: Vikas Saurabh
> Fix For: 1.8, 1.7.12
>
> Attachments:
> org.apache.jackrabbit.oak.jcr.observation.ObservationQueueFullWarnTest-output.txt,
> org.apache.jackrabbit.oak.jcr.observation.ObservationQueueFullWarnTest.txt
>
>
> {noformat}
> [ERROR]
> testQueueFullThenFlushing[SegmentTar](org.apache.jackrabbit.oak.jcr.observation.ObservationQueueFullWarnTest)
> Time elapsed: 0.262 s <<< FAILURE!
> java.lang.AssertionError: Just filled queue must not convert local->external
> expected:<6> but was:<4>
> at
> org.apache.jackrabbit.oak.jcr.observation.ObservationQueueFullWarnTest.testQueueFullThenFlushing(ObservationQueueFullWarnTest.java:347)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6882) ObservationQueueFullWarnTest.testQueueFullThenFlushing failing
[
https://issues.apache.org/jira/browse/OAK-6882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-6882:
---
Issue Type: Test (was: Bug)
> ObservationQueueFullWarnTest.testQueueFullThenFlushing failing
> --
>
> Key: OAK-6882
> URL: https://issues.apache.org/jira/browse/OAK-6882
> Project: Jackrabbit Oak
> Issue Type: Test
> Components: jcr
>Affects Versions: 1.7.10
>Reporter: Julian Reschke
>Assignee: Vikas Saurabh
> Attachments:
> org.apache.jackrabbit.oak.jcr.observation.ObservationQueueFullWarnTest-output.txt,
> org.apache.jackrabbit.oak.jcr.observation.ObservationQueueFullWarnTest.txt
>
>
> {noformat}
> [ERROR]
> testQueueFullThenFlushing[SegmentTar](org.apache.jackrabbit.oak.jcr.observation.ObservationQueueFullWarnTest)
> Time elapsed: 0.262 s <<< FAILURE!
> java.lang.AssertionError: Just filled queue must not convert local->external
> expected:<6> but was:<4>
> at
> org.apache.jackrabbit.oak.jcr.observation.ObservationQueueFullWarnTest.testQueueFullThenFlushing(ObservationQueueFullWarnTest.java:347)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (OAK-6944) org.apache.jackrabbit.oak.management is exported but not used outside of oak-core
angela created OAK-6944:
---
Summary: org.apache.jackrabbit.oak.management is exported but not
used outside of oak-core
Key: OAK-6944
URL: https://issues.apache.org/jira/browse/OAK-6944
Project: Jackrabbit Oak
Issue Type: Technical task
Components: core
Reporter: angela
Assignee: angela
[~mduerig], [~stillalex], [~mreutegg] do you know why
_org.apache.jackrabbit.oak.management_ is exported despite the fact that it's
not used outside of {{oak-core}}? Is this a leftover from the refactoring where
pieced of that package where moved out?
Unless there some objection from your side I would suggest to drop the export
in oak-core (and the baseline exception in the parent pom).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6943) Build Jackrabbit Oak #971 failed
[ https://issues.apache.org/jira/browse/OAK-6943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-6943: --- Fix Version/s: 1.8 > Build Jackrabbit Oak #971 failed > > > Key: OAK-6943 > URL: https://issues.apache.org/jira/browse/OAK-6943 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson > Fix For: 1.8 > > > No description is provided > The build Jackrabbit Oak #971 has failed. > First failed run: [Jackrabbit Oak > #971|https://builds.apache.org/job/Jackrabbit%20Oak/971/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/971/console] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (OAK-6943) Build Jackrabbit Oak #971 failed
Hudson created OAK-6943: --- Summary: Build Jackrabbit Oak #971 failed Key: OAK-6943 URL: https://issues.apache.org/jira/browse/OAK-6943 Project: Jackrabbit Oak Issue Type: Bug Components: continuous integration Reporter: Hudson No description is provided The build Jackrabbit Oak #971 has failed. First failed run: [Jackrabbit Oak #971|https://builds.apache.org/job/Jackrabbit%20Oak/971/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/971/console] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (OAK-6938) Add package export version for spi.xml
[ https://issues.apache.org/jira/browse/OAK-6938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-6938. - Resolution: Fixed Fix Version/s: 1.7.12 Committed revision 1815231. > Add package export version for spi.xml > -- > > Key: OAK-6938 > URL: https://issues.apache.org/jira/browse/OAK-6938 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: security-spi >Reporter: angela >Assignee: angela >Priority: Minor > Fix For: 1.8, 1.7.12 > > > [~mduerig], for example this one :-) > [~stillalex], any objection to add proper export version for the spi.xml > package space? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (OAK-6939) Non-existing package o.a.j.oak.util is exported twice
[ https://issues.apache.org/jira/browse/OAK-6939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-6939. - Resolution: Fixed Fix Version/s: 1.7.12 1.8 Committed revision 1815230. > Non-existing package o.a.j.oak.util is exported twice > - > > Key: OAK-6939 > URL: https://issues.apache.org/jira/browse/OAK-6939 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: core >Reporter: angela >Assignee: angela > Fix For: 1.8, 1.7.12 > > > [~mduerig], [~stillalex], fyi. I am going to fix that and commit the changes > if the integration-tests pass. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-6584) Add tooling API
[
https://issues.apache.org/jira/browse/OAK-6584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251644#comment-16251644
]
Michael Dürig commented on OAK-6584:
Here is an initial implementation of the tool API based on current trunk:
https://github.com/mduerig/jackrabbit-oak/commits/OAK-6584. Please make sure to
have a recent version of the [tool API
1.0-SNAPSHOT|https://github.com/mduerig/oak-tooling-api] in your local Maven
cache.
Based on this I was able to also come up with an initial implementation of my
Scala based [script-oak|https://github.com/mduerig/script-oak/commits/OAK-6584]
console.
Loose ends:
* Figure out how to get rid of {{Store.cast()}} while still allowing
{{script-oak}} to resolve {{NodeState}} from {{RecordId}}.
* Review and validate the implementation to avoid accidentally introducing too
tight couplings. I.e. a tool should be able to use the tool API without having
to statically depend on a certain Oak version. I think we are not there yet
with this version.
* Review the naming. {{Store}} is quite general and in conversations we tend to
have to further qualify it in order to make us clear. I think it would be good
to choose a name that would be clear in its own. Same goes for the entities
where the simple class name duplicates one from the segment store (e.g.
{{RecordID}}). Implementation wise this deduplication wasn't too troublesome
but I ended up looking up 'which' record id I had in hand various times.
> Add tooling API
> ---
>
> Key: OAK-6584
> URL: https://issues.apache.org/jira/browse/OAK-6584
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: tooling
> Fix For: 1.8, 1.7.12
>
>
> h3. Current situation
> Current segment store related tools are implemented ad-hoc by potentially
> relying on internal implementation details of Oak Segment Tar. This makes
> those tools less useful, portable, stable and potentially applicable than
> they should be.
> h3. Goal
> Provide a common and sufficiently stable Oak Tooling API for implementing
> segment store related tools. The API should be independent of Oak and not
> available for normal production use of Oak. Specifically it should not be
> possible to it to implement production features and production features must
> not rely on it. It must be possible to implement the Oak Tooling API in Oak
> 1.8 and it should be possible for Oak 1.6.
> h3. Typical use cases
> * Query the number of nodes / properties / values in a given path satisfying
> some criteria
> * Aggregate a certain value on queries like the above
> * Calculate size of the content / size on disk
> * Analyse changes. E.g. how many binaries bigger than a certain threshold
> were added / removed between two given revisions. What is the sum of their
> sizes?
> * Analyse locality: measure of locality of node states. Incident plots (See
> https://issues.apache.org/jira/browse/OAK-5655?focusedCommentId=15865973=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15865973).
> * Analyse level of deduplication (e.g. of checkpoint)
> h3. Validation
> Reimplement [Script Oak|https://github.com/mduerig/script-oak] on top of the
> tooling API.
> h3. API draft
> * Whiteboard shot of the [API
> entities|https://wiki.apache.org/jackrabbit/Oakathon%20August%202017?action=AttachFile=view=IMG_20170822_163256.jpg]
> identified initially.
> * Further [drafting of the API|https://github.com/mduerig/oak-tooling-api]
> takes place on Github for now. We'll move to the Apache SVN as soon as
> considered mature enough and have a consensus of where to best move it.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6939) Non-existing package o.a.j.oak.util is exported twice
[ https://issues.apache.org/jira/browse/OAK-6939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-6939: Issue Type: Technical task (was: Bug) Parent: OAK-3919 > Non-existing package o.a.j.oak.util is exported twice > - > > Key: OAK-6939 > URL: https://issues.apache.org/jira/browse/OAK-6939 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: core >Reporter: angela >Assignee: angela > > [~mduerig], [~stillalex], fyi. I am going to fix that and commit the changes > if the integration-tests pass. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-6925) Build Jackrabbit Oak #962 failed
[ https://issues.apache.org/jira/browse/OAK-6925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251594#comment-16251594 ] Hudson commented on OAK-6925: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #970|https://builds.apache.org/job/Jackrabbit%20Oak/970/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/970/console] > Build Jackrabbit Oak #962 failed > > > Key: OAK-6925 > URL: https://issues.apache.org/jira/browse/OAK-6925 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson > Labels: ci, jenkins, test-failure > Fix For: 1.8 > > > No description is provided > The build Jackrabbit Oak #962 has failed. > First failed run: [Jackrabbit Oak > #962|https://builds.apache.org/job/Jackrabbit%20Oak/962/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/962/console] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6881) indirect test dependencies through tika-parser to vulnerable version of xmpcore
[ https://issues.apache.org/jira/browse/OAK-6881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-6881: Fix Version/s: 1.8 > indirect test dependencies through tika-parser to vulnerable version of > xmpcore > --- > > Key: OAK-6881 > URL: https://issues.apache.org/jira/browse/OAK-6881 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Julian Reschke > Fix For: 1.8 > > > We should upgrade to a version of tika-parser that fixes > https://issues.apache.org/jira/browse/TIKA-2486 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (OAK-6912) Cold standby performance regression due to segment caching
[
https://issues.apache.org/jira/browse/OAK-6912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu resolved OAK-6912.
--
Resolution: Fixed
Fixing OAK-6915 fixed this issue as well, by improving the way segment caching
is handled in TarMK. Listing below the results obtained for benchmarking
{{BasicWriteTest}} on all {{Oak-Segment-*}} fixtures:
|Oak 1.8-SNAPSHOT|{noformat}
# BasicWriteTest C min 10% 50% 90% max
N
Oak-Segment-Tar1 20 21 22 30 509
1410
Oak-Segment-Tar-DS 1 57 59 62 66 111
942
Oak-Segment-Tar-Cold 1 57 60 63 69 224
919
{noformat}
|
> Cold standby performance regression due to segment caching
> --
>
> Key: OAK-6912
> URL: https://issues.apache.org/jira/browse/OAK-6912
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, tarmk-standby
>Affects Versions: 1.7.0
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
> Labels: cold-standby, performance, scalability
> Fix For: 1.8, 1.7.12
>
>
> The changes to the segment cache introduced in r1793527 [0] introduced a
> performance regression on the primary for the case in which a standby is
> attached to it. Below a benchmark duration comparison between primary w/o and
> w/ standby for r1793527 (after the segment cache changes) and r1793526
> (before the changes) :
> |Oak 1.6 r1793527 (20170502)|{noformat}
> # BasicWriteTest C min 10% 50% 90% max
> N
> Oak-Segment-Tar1 19 21 22 26 160
> 2491
> Oak-Segment-Tar-DS 1 56 59 63 70 181
>919
> Oak-Segment-Tar-Cold(Shared DS)1 58 66 159 177 372
>302
> {noformat}|
> |Oak 1.6 r1793526 (20170502)|{noformat}
> # BasicWriteTest C min 10% 50% 90% max
> N
> Oak-Segment-Tar1 19 21 22 25 52
> 2584
> Oak-Segment-Tar-DS 1 56 60 63 69 158
>925
> Oak-Segment-Tar-Cold(Shared DS)1 57 60 64 70 122
>915
> {noformat}|
> [0]
> https://github.com/apache/jackrabbit-oak/commit/efafa4e1710621b7f3b8e92d0b2681669185fcd4
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6940) Login token name generation is prone to race conditions
[
https://issues.apache.org/jira/browse/OAK-6940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251399#comment-16251399
]
angela commented on OAK-6940:
-
[~stillalex], [~catholicon], I don't mind dropping the human readable part
otherwise we might end up fighting limitations with long paths :-)
> Login token name generation is prone to race conditions
> ---
>
> Key: OAK-6940
> URL: https://issues.apache.org/jira/browse/OAK-6940
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Minor
>
> Under high concurrency the {{TokenProviderImpl#generateTokenName}} method can
> return the same value, causing the commit to fail and be retried with a
> generic UUID value.
> This seems pretty expensive (benchmarks to follow) and it would probably be
> best to try using a random value every time, sacrificing the 'human readable'
> property of the node name.
> fyi [~anchela]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6940) Login token name generation is prone to race conditions
[
https://issues.apache.org/jira/browse/OAK-6940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-6940:
Priority: Major (was: Minor)
> Login token name generation is prone to race conditions
> ---
>
> Key: OAK-6940
> URL: https://issues.apache.org/jira/browse/OAK-6940
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>
> Under high concurrency the {{TokenProviderImpl#generateTokenName}} method can
> return the same value, causing the commit to fail and be retried with a
> generic UUID value.
> This seems pretty expensive (benchmarks to follow) and it would probably be
> best to try using a random value every time, sacrificing the 'human readable'
> property of the node name.
> fyi [~anchela]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (OAK-6942) Add package export versions for core-spi
angela created OAK-6942: --- Summary: Add package export versions for core-spi Key: OAK-6942 URL: https://issues.apache.org/jira/browse/OAK-6942 Project: Jackrabbit Oak Issue Type: Technical task Components: core-spi Reporter: angela most packages in core-spi module still don't have a _package-info.java_ file. We should add those in order to complete the modularisation effort. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6934) Add test coverage of plugins.tree package
[ https://issues.apache.org/jira/browse/OAK-6934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-6934: Summary: Add test coverage of plugins.tree package (was: Add test coverage of spi.tree package) > Add test coverage of plugins.tree package > - > > Key: OAK-6934 > URL: https://issues.apache.org/jira/browse/OAK-6934 > Project: Jackrabbit Oak > Issue Type: Task > Components: security-spi >Reporter: angela >Assignee: angela > > [~stillalex] fyi -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-3373) Observers dont survive store restart (was: LuceneIndexProvider: java.lang.IllegalStateException: open)
[
https://issues.apache.org/jira/browse/OAK-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated OAK-3373:
-
Fix Version/s: (was: 1.8)
1.10
moved this from 1.8 to 1.10 as I don't see as fitting into the 1.8 timeframe -
pls adjust if you think otherwise
> Observers dont survive store restart (was: LuceneIndexProvider:
> java.lang.IllegalStateException: open)
> --
>
> Key: OAK-3373
> URL: https://issues.apache.org/jira/browse/OAK-3373
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.3.5
>Reporter: Stefan Egli
> Fix For: 1.10
>
>
> The following exception occurs when stopping, then immediately re-starting
> the oak-core bundle (which was done as part of testing for OAK-3250 - but can
> be reproduced independently). It's not clear what the consequences are
> though..
> {code}08.09.2015 14:20:26.960 *ERROR* [oak-lucene-0]
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProvider Uncaught
> exception in
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProvider@3a4a6c5c
> org.apache.jackrabbit.oak.plugins.document.DocumentStoreException: Error
> occurred while fetching children for path /oak:index/authorizables
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentStoreException.convert(DocumentStoreException.java:48)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.getChildren(DocumentNodeStore.java:902)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.getChildNodes(DocumentNodeStore.java:1082)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeState.getChildNodeEntries(DocumentNodeState.java:508)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeState.access$100(DocumentNodeState.java:65)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeState$ChildNodeEntryIterator.fetchMore(DocumentNodeState.java:716)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeState$ChildNodeEntryIterator.(DocumentNodeState.java:681)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeState$1.iterator(DocumentNodeState.java:289)
> at
> org.apache.jackrabbit.oak.spi.state.AbstractNodeState.compareAgainstBaseState(AbstractNodeState.java:129)
> at
> org.apache.jackrabbit.oak.spi.state.AbstractNodeState.compareAgainstBaseState(AbstractNodeState.java:303)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeState.compareAgainstBaseState(DocumentNodeState.java:359)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:148)
> at
> org.apache.jackrabbit.oak.spi.state.AbstractNodeState.compareAgainstBaseState(AbstractNodeState.java:140)
> at
> org.apache.jackrabbit.oak.spi.state.AbstractNodeState.compareAgainstBaseState(AbstractNodeState.java:303)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeState.compareAgainstBaseState(DocumentNodeState.java:359)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:148)
> at
> org.apache.jackrabbit.oak.spi.state.AbstractNodeState.compareAgainstBaseState(AbstractNodeState.java:140)
> at
> org.apache.jackrabbit.oak.spi.state.AbstractNodeState.compareAgainstBaseState(AbstractNodeState.java:303)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeState.compareAgainstBaseState(DocumentNodeState.java:359)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:52)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexTracker.update(IndexTracker.java:108)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProvider.contentChanged(LuceneIndexProvider.java:73)
> at
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:127)
> at
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:121)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.IllegalStateException: open
> at org.bson.util.Assertions.isTrue(Assertions.java:36)
> at
> com.mongodb.DBTCPConnector.isMongosConnection(DBTCPConnector.java:367)
> at com.mongodb.Mongo.isMongosConnection(Mongo.java:622)
> at com.mongodb.DBCursor._check(DBCursor.java:494)
> at
[jira] [Updated] (OAK-5990) Add properties filtering support to OakEventFilter
[ https://issues.apache.org/jira/browse/OAK-5990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli updated OAK-5990: - Fix Version/s: (was: 1.8) 1.10 moved this from 1.8 to 1.10 as I don't see as fitting into the 1.8 timeframe - pls adjust if you think otherwise > Add properties filtering support to OakEventFilter > -- > > Key: OAK-5990 > URL: https://issues.apache.org/jira/browse/OAK-5990 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jcr >Affects Versions: 1.6.1 >Reporter: Stefan Egli > Fix For: 1.10 > > > SLING-6164 introduced a _property name hint_ which, when set, allows to limit > the observation events to only include those that affect at least one of the > those properties listed. The advantage is to be further able to reduce the > events sent out. This feature has not yet been implemented on the oak side. > Thus we should add this to the OakEventFilter. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-5152) Improve overflow handling in ChangeSetFilterImpl
[ https://issues.apache.org/jira/browse/OAK-5152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli updated OAK-5152: - Fix Version/s: (was: 1.8) 1.10 moved this from 1.8 to 1.10 as I don't see as fitting into the 1.8 timeframe - pls adjust if you think otherwise > Improve overflow handling in ChangeSetFilterImpl > > > Key: OAK-5152 > URL: https://issues.apache.org/jira/browse/OAK-5152 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Affects Versions: 1.5.14 >Reporter: Stefan Egli > Fix For: 1.10 > > > As described in OAK-5151 when a ChangeSet overflows, the ChangeSetFilterImpl > treats the changes as included and doesn't go further into the remaining, > perhaps not-overflown other sets. Besides more testing it wouldn't be much > effort to change this though. Putting this as outside of 1.6 scope for now > though. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-3236) integration test that simulates influence of clock drift
[ https://issues.apache.org/jira/browse/OAK-3236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli updated OAK-3236: - Fix Version/s: (was: 1.8) 1.10 moved this from 1.8 to 1.10 as I don't see as fitting into the 1.8 timeframe - pls adjust if you think otherwise > integration test that simulates influence of clock drift > > > Key: OAK-3236 > URL: https://issues.apache.org/jira/browse/OAK-3236 > Project: Jackrabbit Oak > Issue Type: Test > Components: core >Affects Versions: 1.3.4 >Reporter: Stefan Egli > Fix For: 1.10 > > > Spin-off of OAK-2739 [of this > comment|https://issues.apache.org/jira/browse/OAK-2739?focusedCommentId=14693398=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14693398] > - ie there should be an integration test that show cases the issues with > clock drift and why it is a good idea to have a lease-check (that refuses to > let the document store be used any further once the lease times out locally) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-5144) use 'allNodeTypes' of ChangeSet for nodeType-aggregate-filter
[ https://issues.apache.org/jira/browse/OAK-5144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli updated OAK-5144: - Fix Version/s: (was: 1.8) 1.10 moved this from 1.8 to 1.10 as I don't see as fitting into the 1.8 timeframe - pls adjust if you think otherwise > use 'allNodeTypes' of ChangeSet for nodeType-aggregate-filter > - > > Key: OAK-5144 > URL: https://issues.apache.org/jira/browse/OAK-5144 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jcr >Affects Versions: 1.5.14 >Reporter: Stefan Egli > Fix For: 1.10 > > > With OAK-4940 the ChangeSet now contains all node types up to root that are > related to a change. This fact could be used by the nodeType-aggregate-filter > (OAK-5021), which would likely speed up this type of filter. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-4581) Persistent local journal for more reliable event generation
[
https://issues.apache.org/jira/browse/OAK-4581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251362#comment-16251362
]
Stefan Egli commented on OAK-4581:
--
moved this from 1.8 to 1.10 as I don't see as fitting into the 1.8 timeframe -
pls adjust if you think otherwise
> Persistent local journal for more reliable event generation
> ---
>
> Key: OAK-4581
> URL: https://issues.apache.org/jira/browse/OAK-4581
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
>Reporter: Chetan Mehrotra
>Assignee: Stefan Egli
> Labels: observation
> Fix For: 1.10
>
> Attachments: OAK-4581.v0.patch
>
>
> As discussed in OAK-2683 "hitting the observation queue limit" has multiple
> drawbacks. Quite a bit of work is done to make diff generation faster.
> However there are still chances of event queue getting filled up.
> This issue is meant to implement a persistent event journal. Idea here being
> # NodeStore would push the diff into a persistent store via a synchronous
> observer
> # Observors which are meant to handle such events in async way (by virtue of
> being wrapped in BackgroundObserver) would instead pull the events from this
> persisted journal
> h3. A - What is persisted
> h4. 1 - Serialized Root States and CommitInfo
> In this approach we just persist the root states in serialized form.
> * DocumentNodeStore - This means storing the root revision vector
> * SegmentNodeStore - {color:red}Q1 - What does serialized form of
> SegmentNodeStore root state looks like{color} - Possible the RecordId of
> "root" state
> Note that with OAK-4528 DocumentNodeStore can rely on persisted remote
> journal to determine the affected paths. Which reduces the need for
> persisting complete diff locally.
> Event generation logic would then "deserialize" the persisted root states and
> then generate the diff as currently done via NodeState comparison
> h4. 2 - Serialized commit diff and CommitInfo
> In this approach we can save the diff in JSOP form. The diff only contains
> information about affected path. Similar to what is current being stored in
> DocumentNodeStore journal
> h4. CommitInfo
> The commit info would also need to be serialized. So it needs to be ensure
> whatever is stored there can be serialized or re calculated
> h3. B - How it is persisted
> h4. 1 - Use a secondary segment NodeStore
> OAK-4180 makes use of SegmentNodeStore as a secondary store for caching.
> [~mreutegg] suggested that for persisted local journal we can also utilize a
> SegmentNodeStore instance. Care needs to be taken for compaction. Either via
> generation approach or relying on online compaction
> h4. 2- Make use of write ahead log implementations
> [~ianeboston] suggested that we can make use of some write ahead log
> implementation like [1], [2] or [3]
> h3. C - How changes get pulled
> Some points to consider for event generation logic
> # Would need a way to keep pointers to journal entry on per listener basis.
> This would allow each Listener to "pull" content changes and generate diff as
> per its speed and keeping in memory overhead low
> # The journal should survive restarts
> [1] http://www.mapdb.org/javadoc/latest/mapdb/org/mapdb/WriteAheadLog.html
> [2]
> https://github.com/apache/activemq/tree/master/activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/disk/journal
> [3]
> https://github.com/elastic/elasticsearch/tree/master/core/src/main/java/org/elasticsearch/index/translog
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-4581) Persistent local journal for more reliable event generation
[
https://issues.apache.org/jira/browse/OAK-4581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated OAK-4581:
-
Fix Version/s: (was: 1.8)
1.10
> Persistent local journal for more reliable event generation
> ---
>
> Key: OAK-4581
> URL: https://issues.apache.org/jira/browse/OAK-4581
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
>Reporter: Chetan Mehrotra
>Assignee: Stefan Egli
> Labels: observation
> Fix For: 1.10
>
> Attachments: OAK-4581.v0.patch
>
>
> As discussed in OAK-2683 "hitting the observation queue limit" has multiple
> drawbacks. Quite a bit of work is done to make diff generation faster.
> However there are still chances of event queue getting filled up.
> This issue is meant to implement a persistent event journal. Idea here being
> # NodeStore would push the diff into a persistent store via a synchronous
> observer
> # Observors which are meant to handle such events in async way (by virtue of
> being wrapped in BackgroundObserver) would instead pull the events from this
> persisted journal
> h3. A - What is persisted
> h4. 1 - Serialized Root States and CommitInfo
> In this approach we just persist the root states in serialized form.
> * DocumentNodeStore - This means storing the root revision vector
> * SegmentNodeStore - {color:red}Q1 - What does serialized form of
> SegmentNodeStore root state looks like{color} - Possible the RecordId of
> "root" state
> Note that with OAK-4528 DocumentNodeStore can rely on persisted remote
> journal to determine the affected paths. Which reduces the need for
> persisting complete diff locally.
> Event generation logic would then "deserialize" the persisted root states and
> then generate the diff as currently done via NodeState comparison
> h4. 2 - Serialized commit diff and CommitInfo
> In this approach we can save the diff in JSOP form. The diff only contains
> information about affected path. Similar to what is current being stored in
> DocumentNodeStore journal
> h4. CommitInfo
> The commit info would also need to be serialized. So it needs to be ensure
> whatever is stored there can be serialized or re calculated
> h3. B - How it is persisted
> h4. 1 - Use a secondary segment NodeStore
> OAK-4180 makes use of SegmentNodeStore as a secondary store for caching.
> [~mreutegg] suggested that for persisted local journal we can also utilize a
> SegmentNodeStore instance. Care needs to be taken for compaction. Either via
> generation approach or relying on online compaction
> h4. 2- Make use of write ahead log implementations
> [~ianeboston] suggested that we can make use of some write ahead log
> implementation like [1], [2] or [3]
> h3. C - How changes get pulled
> Some points to consider for event generation logic
> # Would need a way to keep pointers to journal entry on per listener basis.
> This would allow each Listener to "pull" content changes and generate diff as
> per its speed and keeping in memory overhead low
> # The journal should survive restarts
> [1] http://www.mapdb.org/javadoc/latest/mapdb/org/mapdb/WriteAheadLog.html
> [2]
> https://github.com/apache/activemq/tree/master/activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/disk/journal
> [3]
> https://github.com/elastic/elasticsearch/tree/master/core/src/main/java/org/elasticsearch/index/translog
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6882) ObservationQueueFullWarnTest.testQueueFullThenFlushing failing
[
https://issues.apache.org/jira/browse/OAK-6882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251349#comment-16251349
]
Julian Reschke commented on OAK-6882:
-
Looks good so far.
> ObservationQueueFullWarnTest.testQueueFullThenFlushing failing
> --
>
> Key: OAK-6882
> URL: https://issues.apache.org/jira/browse/OAK-6882
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.7.10
>Reporter: Julian Reschke
>Assignee: Vikas Saurabh
> Attachments:
> org.apache.jackrabbit.oak.jcr.observation.ObservationQueueFullWarnTest-output.txt,
> org.apache.jackrabbit.oak.jcr.observation.ObservationQueueFullWarnTest.txt
>
>
> {noformat}
> [ERROR]
> testQueueFullThenFlushing[SegmentTar](org.apache.jackrabbit.oak.jcr.observation.ObservationQueueFullWarnTest)
> Time elapsed: 0.262 s <<< FAILURE!
> java.lang.AssertionError: Just filled queue must not convert local->external
> expected:<6> but was:<4>
> at
> org.apache.jackrabbit.oak.jcr.observation.ObservationQueueFullWarnTest.testQueueFullThenFlushing(ObservationQueueFullWarnTest.java:347)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6776) Correctly use IndexPlan.supportsPathRestrictions
[ https://issues.apache.org/jira/browse/OAK-6776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-6776: Fix Version/s: 1.7.12 > Correctly use IndexPlan.supportsPathRestrictions > > > Key: OAK-6776 > URL: https://issues.apache.org/jira/browse/OAK-6776 > Project: Jackrabbit Oak > Issue Type: Bug > Components: query >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.8, 1.7.12 > > > Right now, IndexPlan.supportsPathRestrictions (introduced in OAK-6734) is > used in the query engine for some kind of mixed "rule based" and "cost based" > [query optimization|https://en.wikipedia.org/wiki/Query_optimization]. > I think the current implementation isn't correct, as (for example) a query > with multiple indexes will now use the wrong index in some cases (for example > property index, even if the cost of the Lucene index is lower). > Also, if there is a Lucene index with supportsPathRestrictions, and one > without, right now always the one with supportsPathRestrictions is used. This > is probably better right now, but once OAK-6735 is resolved, this should be > fixed as well. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (OAK-6776) Correctly use IndexPlan.supportsPathRestrictions
[ https://issues.apache.org/jira/browse/OAK-6776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16194639#comment-16194639 ] Thomas Mueller edited comment on OAK-6776 at 11/14/17 12:55 PM: http://svn.apache.org/r1811334 (trunk) still missing is: lucene indexes should return multiple plans, if some indexes do support path restrictions and some not was (Author: tmueller): http://svn.apache.org/r1811334 (trunk) still missing is: lucene indexes should return multiple paths, if some indexes do support path restrictions and some not > Correctly use IndexPlan.supportsPathRestrictions > > > Key: OAK-6776 > URL: https://issues.apache.org/jira/browse/OAK-6776 > Project: Jackrabbit Oak > Issue Type: Bug > Components: query >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.8, 1.7.12 > > > Right now, IndexPlan.supportsPathRestrictions (introduced in OAK-6734) is > used in the query engine for some kind of mixed "rule based" and "cost based" > [query optimization|https://en.wikipedia.org/wiki/Query_optimization]. > I think the current implementation isn't correct, as (for example) a query > with multiple indexes will now use the wrong index in some cases (for example > property index, even if the cost of the Lucene index is lower). > Also, if there is a Lucene index with supportsPathRestrictions, and one > without, right now always the one with supportsPathRestrictions is used. This > is probably better right now, but once OAK-6735 is resolved, this should be > fixed as well. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-6938) Add package export version for spi.xml
[ https://issues.apache.org/jira/browse/OAK-6938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251335#comment-16251335 ] Alex Deparvu commented on OAK-6938: --- no objections here > Add package export version for spi.xml > -- > > Key: OAK-6938 > URL: https://issues.apache.org/jira/browse/OAK-6938 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: security-spi >Reporter: angela >Assignee: angela >Priority: Minor > Fix For: 1.8 > > > [~mduerig], for example this one :-) > [~stillalex], any objection to add proper export version for the spi.xml > package space? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-6936) use current Tika version 1.16
[ https://issues.apache.org/jira/browse/OAK-6936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251295#comment-16251295 ] Julian Reschke commented on OAK-6936: - Patch attached. Passes tests and integration tests for me. > use current Tika version 1.16 > - > > Key: OAK-6936 > URL: https://issues.apache.org/jira/browse/OAK-6936 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Priority: Minor > Fix For: 1.8 > > Attachments: OAK-6936.diff > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6936) use current Tika version 1.16
[ https://issues.apache.org/jira/browse/OAK-6936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-6936: Attachment: OAK-6936.diff > use current Tika version 1.16 > - > > Key: OAK-6936 > URL: https://issues.apache.org/jira/browse/OAK-6936 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Priority: Minor > Fix For: 1.8 > > Attachments: OAK-6936.diff > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6935) Active deletion logs warn messages when it tries to delete blobs already purged by DSGC
[ https://issues.apache.org/jira/browse/OAK-6935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh updated OAK-6935: --- Fix Version/s: 1.8 > Active deletion logs warn messages when it tries to delete blobs already > purged by DSGC > --- > > Key: OAK-6935 > URL: https://issues.apache.org/jira/browse/OAK-6935 > Project: Jackrabbit Oak > Issue Type: Bug > Components: lucene >Reporter: Vikas Saurabh >Assignee: Vikas Saurabh >Priority: Minor > Fix For: 1.8, 1.7.12 > > > In cases when BlobGC deleted the blobs which active delete logic later came > around to purge., active deletion logs a warn message. An example timeline > would be: > * t1 -> index blob gets deleted (active delete logic notes it down) > * t2 -> compaction removes ref to this blob from node store > * t3 (t1 + 24 hours) -> blob gc runs and collects the blob > * t4 -> active gc tries to purge an already deleted blob > (note, active delete runs between t1 and t3 would not delete the blobs as it > hasn't be 24 hours since blob deletion). > While this would happen for a small set of blobs (that are unfortunate to get > compacted and cleaned up by DSGC before active deletion comes around) - but, > the warn log is annoying. It would be useful to detect this case and not log > warn on failure to delete for these. > /cc [~amjain] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (OAK-6935) Active deletion logs warn messages when it tries to delete blobs already purged by DSGC
[ https://issues.apache.org/jira/browse/OAK-6935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh resolved OAK-6935. Resolution: Fixed Fix Version/s: 1.7.12 Changed logs due to DataStoreException to DEBUG in trunk at [r1815206|https://svn.apache.org/r1815206]. > Active deletion logs warn messages when it tries to delete blobs already > purged by DSGC > --- > > Key: OAK-6935 > URL: https://issues.apache.org/jira/browse/OAK-6935 > Project: Jackrabbit Oak > Issue Type: Bug > Components: lucene >Reporter: Vikas Saurabh >Assignee: Vikas Saurabh >Priority: Minor > Fix For: 1.7.12 > > > In cases when BlobGC deleted the blobs which active delete logic later came > around to purge., active deletion logs a warn message. An example timeline > would be: > * t1 -> index blob gets deleted (active delete logic notes it down) > * t2 -> compaction removes ref to this blob from node store > * t3 (t1 + 24 hours) -> blob gc runs and collects the blob > * t4 -> active gc tries to purge an already deleted blob > (note, active delete runs between t1 and t3 would not delete the blobs as it > hasn't be 24 hours since blob deletion). > While this would happen for a small set of blobs (that are unfortunate to get > compacted and cleaned up by DSGC before active deletion comes around) - but, > the warn log is annoying. It would be useful to detect this case and not log > warn on failure to delete for these. > /cc [~amjain] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-6931) Enable the -Dcache of offline compaction
[
https://issues.apache.org/jira/browse/OAK-6931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251256#comment-16251256
]
Michael Dürig commented on OAK-6931:
Announced intent to backport to 1.6:
https://lists.apache.org/thread.html/2d09104f896783a53ad8047ae0c9b9512a4f3a0fe0bf2740065b7036@%3Coak-dev.jackrabbit.apache.org%3E
> Enable the -Dcache of offline compaction
>
>
> Key: OAK-6931
> URL: https://issues.apache.org/jira/browse/OAK-6931
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Affects Versions: 1.6.7
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: compaction, gc, tooling
> Fix For: 1.8, 1.6.6, 1.7.12
>
> Attachments: OAK-6931.patch
>
>
> The {{-Dcache}} option currently has no effect when used in conjunction with
> the {{compact}} run mode of {{oak-run}}. However we should enable users to
> configure the segment cache size through this option if necessary.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6931) Enable the -Dcache of offline compaction
[
https://issues.apache.org/jira/browse/OAK-6931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251252#comment-16251252
]
Michael Dürig commented on OAK-6931:
Thanks for the valuable feedback. Applied the updated patch in trunk at
http://svn.apache.org/viewvc?rev=1815201=rev.
> Enable the -Dcache of offline compaction
>
>
> Key: OAK-6931
> URL: https://issues.apache.org/jira/browse/OAK-6931
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Affects Versions: 1.6.7
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: compaction, gc, tooling
> Fix For: 1.8, 1.6.6, 1.7.12
>
> Attachments: OAK-6931.patch
>
>
> The {{-Dcache}} option currently has no effect when used in conjunction with
> the {{compact}} run mode of {{oak-run}}. However we should enable users to
> configure the segment cache size through this option if necessary.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6935) Active deletion logs warn messages when it tries to delete blobs already purged by DSGC
[ https://issues.apache.org/jira/browse/OAK-6935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251231#comment-16251231 ] Amit Jain commented on OAK-6935: [~catholicon] Sounds ok to me as I understand the exceptions might be of these 2 variety: * Failure to delete - Any genuinely missed deletion will be covered by DataStore GC later * Already deleted - Something already done by DataStore GC > Active deletion logs warn messages when it tries to delete blobs already > purged by DSGC > --- > > Key: OAK-6935 > URL: https://issues.apache.org/jira/browse/OAK-6935 > Project: Jackrabbit Oak > Issue Type: Bug > Components: lucene >Reporter: Vikas Saurabh >Assignee: Vikas Saurabh >Priority: Minor > > In cases when BlobGC deleted the blobs which active delete logic later came > around to purge., active deletion logs a warn message. An example timeline > would be: > * t1 -> index blob gets deleted (active delete logic notes it down) > * t2 -> compaction removes ref to this blob from node store > * t3 (t1 + 24 hours) -> blob gc runs and collects the blob > * t4 -> active gc tries to purge an already deleted blob > (note, active delete runs between t1 and t3 would not delete the blobs as it > hasn't be 24 hours since blob deletion). > While this would happen for a small set of blobs (that are unfortunate to get > compacted and cleaned up by DSGC before active deletion comes around) - but, > the warn log is annoying. It would be useful to detect this case and not log > warn on failure to delete for these. > /cc [~amjain] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-6941) Compatibility matrix for oak-run compact
[
https://issues.apache.org/jira/browse/OAK-6941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251224#comment-16251224
]
Andrei Dulceanu commented on OAK-6941:
--
bq. Blacklist of versions that should not be used (with alternatives)
[~volteanu], isn't this superseded by the listing of all good {{oak-run}}
versions for a specific Oak version? IMHO, this will only make things
complicated...
> Compatibility matrix for oak-run compact
>
>
> Key: OAK-6941
> URL: https://issues.apache.org/jira/browse/OAK-6941
> Project: Jackrabbit Oak
> Issue Type: Documentation
> Components: run, segment-tar
>Reporter: Valentin Olteanu
>
> h4. Problem statement
> For compacting the segmentstore using {{oak-run}}, the safest option is to
> use the same version of {{oak-run}} as the Oak version used to generate the
> repository. Yet, sometimes, a newer {{oak-run}} version is recommended to
> benefit of bug fixes and improvements, but not every combination of source
> repo and oak-run is safe to use and the user needs a way to check the
> compatibility. Thus, the users need a tool that guides the decision of which
> version to use.
> h4. Requirements
> * Easy to decide what {{oak-run}} version should be used for a certain Oak
> version
> * Up to date with the latest releases
> * Machine readable for scripting
> * Include details on the benefits of using a certain version (release notes)
> * Blacklist of versions that should not be used (with alternatives)
> h4. Solution
> TBD
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6941) Compatibility matrix for oak-run compact
[
https://issues.apache.org/jira/browse/OAK-6941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251212#comment-16251212
]
Valentin Olteanu commented on OAK-6941:
---
Probably the simplest solution is through documentation: a page containing the
sparse matrix of known compatible versions.
Another format would be a table with the most recent known compatible version.
> Compatibility matrix for oak-run compact
>
>
> Key: OAK-6941
> URL: https://issues.apache.org/jira/browse/OAK-6941
> Project: Jackrabbit Oak
> Issue Type: Documentation
> Components: run, segment-tar
>Reporter: Valentin Olteanu
>
> h4. Problem statement
> For compacting the segmentstore using {{oak-run}}, the safest option is to
> use the same version of {{oak-run}} as the Oak version used to generate the
> repository. Yet, sometimes, a newer {{oak-run}} version is recommended to
> benefit of bug fixes and improvements, but not every combination of source
> repo and oak-run is safe to use and the user needs a way to check the
> compatibility. Thus, the users need a tool that guides the decision of which
> version to use.
> h4. Requirements
> * Easy to decide what {{oak-run}} version should be used for a certain Oak
> version
> * Up to date with the latest releases
> * Machine readable for scripting
> * Include details on the benefits of using a certain version (release notes)
> * Blacklist of versions that should not be used (with alternatives)
> h4. Solution
> TBD
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6941) Compatibility matrix for oak-run compact
[
https://issues.apache.org/jira/browse/OAK-6941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Olteanu updated OAK-6941:
--
Description:
h4. Problem statement
For compacting the segmentstore using {{oak-run}}, the safest option is to use
the same version of {{oak-run}} as the Oak version used to generate the
repository. Yet, sometimes, a newer {{oak-run}} version is recommended to
benefit of bug fixes and improvements, but not every combination of source repo
and oak-run is safe to use and the user needs a way to check the compatibility.
Thus, the users need a tool that guides the decision of which version to use.
h4. Requirements
* Easy to decide what {{oak-run}} version should be used for a certain Oak
version
* Up to date with the latest releases
* Machine readable for scripting
* Include details on the benefits of using a certain version (release notes)
* Blacklist of versions that should not be used (with alternatives)
h4. Solution
TBD
> Compatibility matrix for oak-run compact
>
>
> Key: OAK-6941
> URL: https://issues.apache.org/jira/browse/OAK-6941
> Project: Jackrabbit Oak
> Issue Type: Documentation
> Components: run, segment-tar
>Reporter: Valentin Olteanu
>
> h4. Problem statement
> For compacting the segmentstore using {{oak-run}}, the safest option is to
> use the same version of {{oak-run}} as the Oak version used to generate the
> repository. Yet, sometimes, a newer {{oak-run}} version is recommended to
> benefit of bug fixes and improvements, but not every combination of source
> repo and oak-run is safe to use and the user needs a way to check the
> compatibility. Thus, the users need a tool that guides the decision of which
> version to use.
> h4. Requirements
> * Easy to decide what {{oak-run}} version should be used for a certain Oak
> version
> * Up to date with the latest releases
> * Machine readable for scripting
> * Include details on the benefits of using a certain version (release notes)
> * Blacklist of versions that should not be used (with alternatives)
> h4. Solution
> TBD
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6882) ObservationQueueFullWarnTest.testQueueFullThenFlushing failing
[
https://issues.apache.org/jira/browse/OAK-6882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251203#comment-16251203
]
Vikas Saurabh commented on OAK-6882:
... also, I'm guessing the failures are intermittent... so, maybe it might be
easier to commit this. Can you please try a couple of times at your end before
I commit?
> ObservationQueueFullWarnTest.testQueueFullThenFlushing failing
> --
>
> Key: OAK-6882
> URL: https://issues.apache.org/jira/browse/OAK-6882
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.7.10
>Reporter: Julian Reschke
>Assignee: Vikas Saurabh
> Attachments:
> org.apache.jackrabbit.oak.jcr.observation.ObservationQueueFullWarnTest-output.txt,
> org.apache.jackrabbit.oak.jcr.observation.ObservationQueueFullWarnTest.txt
>
>
> {noformat}
> [ERROR]
> testQueueFullThenFlushing[SegmentTar](org.apache.jackrabbit.oak.jcr.observation.ObservationQueueFullWarnTest)
> Time elapsed: 0.262 s <<< FAILURE!
> java.lang.AssertionError: Just filled queue must not convert local->external
> expected:<6> but was:<4>
> at
> org.apache.jackrabbit.oak.jcr.observation.ObservationQueueFullWarnTest.testQueueFullThenFlushing(ObservationQueueFullWarnTest.java:347)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Issue Comment Deleted] (OAK-6882) ObservationQueueFullWarnTest.testQueueFullThenFlushing failing
[
https://issues.apache.org/jira/browse/OAK-6882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-6882:
---
Comment: was deleted
(was: [~reschke], can you please see if this helps:
{noformat}
diff --git
a/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/observation/ObservationQueueFullWarnTest.java
b/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/observation/ObservationQueueFullWarnTest.java
index 1901795c9f..5dcc725ccf 100644
---
a/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/observation/ObservationQueueFullWarnTest.java
+++
b/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/observation/ObservationQueueFullWarnTest.java
@@ -263,8 +263,8 @@ public class ObservationQueueFullWarnTest extends
AbstractRepositoryTest {
@Override
public void onEvent(EventIterator events) {
try {
-semaphore.acquire();
if (hasRecievedInit.get()) {
+semaphore.acquire();
long numEvents = events.getSize();
counter.addAndGet(numEvents);
System.out.println("GOT: " + numEvents + " - COUNTER:
" + counter.get());
@@ -282,6 +282,7 @@ public class ObservationQueueFullWarnTest extends
AbstractRepositoryTest {
// as other would be dispatched once we've got init
while (events.hasNext()) {
Event e = events.nextEvent();
+System.out.println(" - " + e);
if (PathUtils.getName(e.getPath()).equals("init"))
{
hasRecievedInit.set(true);
}
@@ -313,7 +314,7 @@ public class ObservationQueueFullWarnTest extends
AbstractRepositoryTest {
// To avoid this, we would put our own "init" and wait for it to show
up before continuing the test
session.getNode("/testNode").setProperty("init", 1);
session.save();
-semaphore.release(1);
+
boolean initNotTimeOut = waitFor(5000, new Condition() {
@Override
public boolean evaluate() {
{noformat}
(also, I've added another System.out.println... so, if it doesn't work for you
then another copy of stdout would be great).)
> ObservationQueueFullWarnTest.testQueueFullThenFlushing failing
> --
>
> Key: OAK-6882
> URL: https://issues.apache.org/jira/browse/OAK-6882
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.7.10
>Reporter: Julian Reschke
>Assignee: Vikas Saurabh
> Attachments:
> org.apache.jackrabbit.oak.jcr.observation.ObservationQueueFullWarnTest-output.txt,
> org.apache.jackrabbit.oak.jcr.observation.ObservationQueueFullWarnTest.txt
>
>
> {noformat}
> [ERROR]
> testQueueFullThenFlushing[SegmentTar](org.apache.jackrabbit.oak.jcr.observation.ObservationQueueFullWarnTest)
> Time elapsed: 0.262 s <<< FAILURE!
> java.lang.AssertionError: Just filled queue must not convert local->external
> expected:<6> but was:<4>
> at
> org.apache.jackrabbit.oak.jcr.observation.ObservationQueueFullWarnTest.testQueueFullThenFlushing(ObservationQueueFullWarnTest.java:347)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6937) use Tika version consistent with other modules
[ https://issues.apache.org/jira/browse/OAK-6937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251197#comment-16251197 ] Julian Reschke commented on OAK-6937: - trunk: [r1815199|http://svn.apache.org/r1815199] > use Tika version consistent with other modules > -- > > Key: OAK-6937 > URL: https://issues.apache.org/jira/browse/OAK-6937 > Project: Jackrabbit Oak > Issue Type: Task > Components: oak-http >Reporter: Julian Reschke >Priority: Minor > Fix For: 1.8, 1.7.12 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (OAK-6937) use Tika version consistent with other modules
[ https://issues.apache.org/jira/browse/OAK-6937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved OAK-6937. - Resolution: Fixed Fix Version/s: 1.7.12 > use Tika version consistent with other modules > -- > > Key: OAK-6937 > URL: https://issues.apache.org/jira/browse/OAK-6937 > Project: Jackrabbit Oak > Issue Type: Task > Components: oak-http >Reporter: Julian Reschke >Priority: Minor > Fix For: 1.8, 1.7.12 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-6940) Login token name generation is prone to race conditions
[
https://issues.apache.org/jira/browse/OAK-6940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251191#comment-16251191
]
Vikas Saurabh commented on OAK-6940:
bq. sacrificing the 'human readable' property of the node name.
I wonder if some random data is only suffixed to human readable part... That
might save the sacrifice.
> Login token name generation is prone to race conditions
> ---
>
> Key: OAK-6940
> URL: https://issues.apache.org/jira/browse/OAK-6940
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Minor
>
> Under high concurrency the {{TokenProviderImpl#generateTokenName}} method can
> return the same value, causing the commit to fail and be retried with a
> generic UUID value.
> This seems pretty expensive (benchmarks to follow) and it would probably be
> best to try using a random value every time, sacrificing the 'human readable'
> property of the node name.
> fyi [~anchela]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (OAK-6941) Compatibility matrix for oak-run compact
Valentin Olteanu created OAK-6941: - Summary: Compatibility matrix for oak-run compact Key: OAK-6941 URL: https://issues.apache.org/jira/browse/OAK-6941 Project: Jackrabbit Oak Issue Type: Documentation Components: run, segment-tar Reporter: Valentin Olteanu -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-6882) ObservationQueueFullWarnTest.testQueueFullThenFlushing failing
[
https://issues.apache.org/jira/browse/OAK-6882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251186#comment-16251186
]
Vikas Saurabh commented on OAK-6882:
[~reschke], can you please see if this helps:
{noformat}
diff --git
a/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/observation/ObservationQueueFullWarnTest.java
b/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/observation/ObservationQueueFullWarnTest.java
index 1901795c9f..5dcc725ccf 100644
---
a/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/observation/ObservationQueueFullWarnTest.java
+++
b/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/observation/ObservationQueueFullWarnTest.java
@@ -263,8 +263,8 @@ public class ObservationQueueFullWarnTest extends
AbstractRepositoryTest {
@Override
public void onEvent(EventIterator events) {
try {
-semaphore.acquire();
if (hasRecievedInit.get()) {
+semaphore.acquire();
long numEvents = events.getSize();
counter.addAndGet(numEvents);
System.out.println("GOT: " + numEvents + " - COUNTER:
" + counter.get());
@@ -282,6 +282,7 @@ public class ObservationQueueFullWarnTest extends
AbstractRepositoryTest {
// as other would be dispatched once we've got init
while (events.hasNext()) {
Event e = events.nextEvent();
+System.out.println(" - " + e);
if (PathUtils.getName(e.getPath()).equals("init"))
{
hasRecievedInit.set(true);
}
@@ -313,7 +314,7 @@ public class ObservationQueueFullWarnTest extends
AbstractRepositoryTest {
// To avoid this, we would put our own "init" and wait for it to show
up before continuing the test
session.getNode("/testNode").setProperty("init", 1);
session.save();
-semaphore.release(1);
+
boolean initNotTimeOut = waitFor(5000, new Condition() {
@Override
public boolean evaluate() {
{noformat}
(also, I've added another System.out.println... so, if it doesn't work for you
then another copy of stdout would be great).
> ObservationQueueFullWarnTest.testQueueFullThenFlushing failing
> --
>
> Key: OAK-6882
> URL: https://issues.apache.org/jira/browse/OAK-6882
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.7.10
>Reporter: Julian Reschke
>Assignee: Vikas Saurabh
> Attachments:
> org.apache.jackrabbit.oak.jcr.observation.ObservationQueueFullWarnTest-output.txt,
> org.apache.jackrabbit.oak.jcr.observation.ObservationQueueFullWarnTest.txt
>
>
> {noformat}
> [ERROR]
> testQueueFullThenFlushing[SegmentTar](org.apache.jackrabbit.oak.jcr.observation.ObservationQueueFullWarnTest)
> Time elapsed: 0.262 s <<< FAILURE!
> java.lang.AssertionError: Just filled queue must not convert local->external
> expected:<6> but was:<4>
> at
> org.apache.jackrabbit.oak.jcr.observation.ObservationQueueFullWarnTest.testQueueFullThenFlushing(ObservationQueueFullWarnTest.java:347)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6882) ObservationQueueFullWarnTest.testQueueFullThenFlushing failing
[
https://issues.apache.org/jira/browse/OAK-6882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251185#comment-16251185
]
Vikas Saurabh commented on OAK-6882:
[~reschke], can you please see if this helps:
{noformat}
diff --git
a/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/observation/ObservationQueueFullWarnTest.java
b/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/observation/ObservationQueueFullWarnTest.java
index 1901795c9f..5dcc725ccf 100644
---
a/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/observation/ObservationQueueFullWarnTest.java
+++
b/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/observation/ObservationQueueFullWarnTest.java
@@ -263,8 +263,8 @@ public class ObservationQueueFullWarnTest extends
AbstractRepositoryTest {
@Override
public void onEvent(EventIterator events) {
try {
-semaphore.acquire();
if (hasRecievedInit.get()) {
+semaphore.acquire();
long numEvents = events.getSize();
counter.addAndGet(numEvents);
System.out.println("GOT: " + numEvents + " - COUNTER:
" + counter.get());
@@ -282,6 +282,7 @@ public class ObservationQueueFullWarnTest extends
AbstractRepositoryTest {
// as other would be dispatched once we've got init
while (events.hasNext()) {
Event e = events.nextEvent();
+System.out.println(" - " + e);
if (PathUtils.getName(e.getPath()).equals("init"))
{
hasRecievedInit.set(true);
}
@@ -313,7 +314,7 @@ public class ObservationQueueFullWarnTest extends
AbstractRepositoryTest {
// To avoid this, we would put our own "init" and wait for it to show
up before continuing the test
session.getNode("/testNode").setProperty("init", 1);
session.save();
-semaphore.release(1);
+
boolean initNotTimeOut = waitFor(5000, new Condition() {
@Override
public boolean evaluate() {
{noformat}
(also, I've added another System.out.println... so, if it doesn't work for you
then another copy of stdout would be great).
> ObservationQueueFullWarnTest.testQueueFullThenFlushing failing
> --
>
> Key: OAK-6882
> URL: https://issues.apache.org/jira/browse/OAK-6882
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.7.10
>Reporter: Julian Reschke
>Assignee: Vikas Saurabh
> Attachments:
> org.apache.jackrabbit.oak.jcr.observation.ObservationQueueFullWarnTest-output.txt,
> org.apache.jackrabbit.oak.jcr.observation.ObservationQueueFullWarnTest.txt
>
>
> {noformat}
> [ERROR]
> testQueueFullThenFlushing[SegmentTar](org.apache.jackrabbit.oak.jcr.observation.ObservationQueueFullWarnTest)
> Time elapsed: 0.262 s <<< FAILURE!
> java.lang.AssertionError: Just filled queue must not convert local->external
> expected:<6> but was:<4>
> at
> org.apache.jackrabbit.oak.jcr.observation.ObservationQueueFullWarnTest.testQueueFullThenFlushing(ObservationQueueFullWarnTest.java:347)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6935) Active deletion logs warn messages when it tries to delete blobs already purged by DSGC
[
https://issues.apache.org/jira/browse/OAK-6935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251180#comment-16251180
]
Vikas Saurabh commented on OAK-6935:
[~amjain], [~chetanm], while working on this and JCR-4213, it seemed that we
might be ok to ignore (log at DEBUG) for any {{DataStoreException}}. The
rationale being, that:
* this feature was always intended as best-effort-basis
* if there's a genuine error, even then it doesn't affect the functionality of
this feature (other that, of course, unable to delete some blobs that it
"wanted" to delete)
* current logging is just a WARN to the user - but, there is no way that the
user/system can resume deletion of what has already been missed due to exception
So, I think we can probably close JCR-4213 as won't fix or later and fix this
one with switching log.warn to log.debug for DataStoreExceptions. What do you
guys think?
> Active deletion logs warn messages when it tries to delete blobs already
> purged by DSGC
> ---
>
> Key: OAK-6935
> URL: https://issues.apache.org/jira/browse/OAK-6935
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
>
> In cases when BlobGC deleted the blobs which active delete logic later came
> around to purge., active deletion logs a warn message. An example timeline
> would be:
> * t1 -> index blob gets deleted (active delete logic notes it down)
> * t2 -> compaction removes ref to this blob from node store
> * t3 (t1 + 24 hours) -> blob gc runs and collects the blob
> * t4 -> active gc tries to purge an already deleted blob
> (note, active delete runs between t1 and t3 would not delete the blobs as it
> hasn't be 24 hours since blob deletion).
> While this would happen for a small set of blobs (that are unfortunate to get
> compacted and cleaned up by DSGC before active deletion comes around) - but,
> the warn log is annoying. It would be useful to detect this case and not log
> warn on failure to delete for these.
> /cc [~amjain]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (OAK-6940) Login token name generation is prone to race conditions
Alex Deparvu created OAK-6940:
-
Summary: Login token name generation is prone to race conditions
Key: OAK-6940
URL: https://issues.apache.org/jira/browse/OAK-6940
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core, security
Reporter: Alex Deparvu
Assignee: Alex Deparvu
Priority: Minor
Under high concurrency the {{TokenProviderImpl#generateTokenName}} method can
return the same value, causing the commit to fail and be retried with a generic
UUID value.
This seems pretty expensive (benchmarks to follow) and it would probably be
best to try using a random value every time, sacrificing the 'human readable'
property of the node name.
fyi [~anchela]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (OAK-6939) Non-existing package o.a.j.oak.util is exported twice
angela created OAK-6939: --- Summary: Non-existing package o.a.j.oak.util is exported twice Key: OAK-6939 URL: https://issues.apache.org/jira/browse/OAK-6939 Project: Jackrabbit Oak Issue Type: Bug Components: core Reporter: angela Assignee: angela [~mduerig], [~stillalex], fyi. I am going to fix that and commit the changes if the integration-tests pass. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-6353) Use Document order traversal for reindexing performed on DocumentNodeStore setups
[ https://issues.apache.org/jira/browse/OAK-6353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251128#comment-16251128 ] Julian Reschke commented on OAK-6353: - Fixed nullability annotation in [r1815190|http://svn.apache.org/r1815190] > Use Document order traversal for reindexing performed on DocumentNodeStore > setups > - > > Key: OAK-6353 > URL: https://issues.apache.org/jira/browse/OAK-6353 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: run >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: 1.8 > > Attachments: OAK-6353-v1.patch, OAK-6353-v2.patch > > > [~tmueller] suggested > [here|https://issues.apache.org/jira/browse/OAK-6246?focusedCommentId=16034442=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16034442] > that document order traversal can be faster compared to current mode of path > based traversal. Initial test indicate that such a traversal can be order of > magnitude faster. > So this task is meant to implement such an approach and see if it can be a > viable indexing mode used for DocumentNodeStore based setups -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-6931) Enable the -Dcache of offline compaction
[
https://issues.apache.org/jira/browse/OAK-6931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251095#comment-16251095
]
Francesco Mari commented on OAK-6931:
-
I would add a check in {{Compact.Builder#withSegmentCacheSize}} to enforce the
provided value to be greater than or equal to zero, or throw an
{{IllegalArgumentException}} otherwise. Moreover, I would add some Javadoc on
that method, too.
> Enable the -Dcache of offline compaction
>
>
> Key: OAK-6931
> URL: https://issues.apache.org/jira/browse/OAK-6931
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Affects Versions: 1.6.7
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: compaction, gc, tooling
> Fix For: 1.8, 1.6.6, 1.7.12
>
> Attachments: OAK-6931.patch
>
>
> The {{-Dcache}} option currently has no effect when used in conjunction with
> the {{compact}} run mode of {{oak-run}}. However we should enable users to
> configure the segment cache size through this option if necessary.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (OAK-6938) Add package export version for spi.xml
angela created OAK-6938: --- Summary: Add package export version for spi.xml Key: OAK-6938 URL: https://issues.apache.org/jira/browse/OAK-6938 Project: Jackrabbit Oak Issue Type: Technical task Components: security-spi Reporter: angela Assignee: angela Priority: Minor [~mduerig], for example this one :-) [~stillalex], any objection to add proper export version for the spi.xml package space? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-3919) Properly manage APIs / SPIs intended for public consumption
[
https://issues.apache.org/jira/browse/OAK-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251088#comment-16251088
]
angela commented on OAK-3919:
-
[~mduerig], I think we should have another round looking into packages that are
exported without proper export version management. And I would suggest to do so
before cutting 1.8.
> Properly manage APIs / SPIs intended for public consumption
> ---
>
> Key: OAK-3919
> URL: https://issues.apache.org/jira/browse/OAK-3919
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Michael Dürig
> Labels: modularization, technical_debt
> Fix For: 1.8
>
>
> This is a follow up to OAK-3842, which removed package export declarations
> for all packages that we either do not want to be used outside of Oak or that
> are not stable enough yet.
> This issue is to identify those APIs and SPIs of Oak that we actually *want*
> to export and to refactor those such we *can* export them.
> Candidates that are currently used from upstream projects I know of are:
> {code}
> org.apache.jackrabbit.oak.plugins.observation
> org.apache.jackrabbit.oak.spi.commit
> org.apache.jackrabbit.oak.spi.state
> org.apache.jackrabbit.oak.commons
> org.apache.jackrabbit.oak.plugins.index.lucene
> {code}
> I suggest to create subtask for those we want to go forward with.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6770) Convert oak-segment-tar to OSGi R6 annotations
[ https://issues.apache.org/jira/browse/OAK-6770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-6770: --- Labels: osgi (was: ) > Convert oak-segment-tar to OSGi R6 annotations > -- > > Key: OAK-6770 > URL: https://issues.apache.org/jira/browse/OAK-6770 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: segment-tar >Reporter: Robert Munteanu >Priority: Minor > Labels: osgi > Fix For: 1.8 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-5859) Analyse and reduce IO amplification by OS
[ https://issues.apache.org/jira/browse/OAK-5859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-5859: --- Labels: performance scalability (was: perfomance scalability) > Analyse and reduce IO amplification by OS > - > > Key: OAK-5859 > URL: https://issues.apache.org/jira/browse/OAK-5859 > Project: Jackrabbit Oak > Issue Type: Task > Components: segment-tar >Reporter: Michael Dürig > Labels: performance, scalability > > Certain operation system settings might result in too much data actually > being read from disk causing early setting on of thrashing. E.g. transparent > huge pages or too big read aheads might be contra productive in combination > with the TarMKs memory mapping model. > * Determine the ratio of data being read by the TarMK and actual data being > read from disk. Determine the impact of relevant OS parameters (e.g. > transparent huge pages) on this ratio. > * Compare memory mapped mode with file IO mode with an accordingly increased > segment cache. This would move prediction of what is likely to be read next > from the OS layer into our segment cache eviction strategy. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-5884) Evaluate utility of RepositoryGrowthTest benchmark
[
https://issues.apache.org/jira/browse/OAK-5884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-5884:
---
Labels: benchmark (was: )
> Evaluate utility of RepositoryGrowthTest benchmark
> --
>
> Key: OAK-5884
> URL: https://issues.apache.org/jira/browse/OAK-5884
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: run, segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Labels: benchmark
> Fix For: 1.8, 1.7.12
>
>
> {{RepositoryGrowthTest}} is a benchmark which makes use of the deprecated
> {{SegmentFixture}}. Since OAK-5834 removes the old {{oak-segment}} module and
> the code associated with it, {{RepositoryGrowthTest}} was also removed. If
> there's value in it, we can adapt it to work with the new
> {{SegmentTarFixture}}.
> /cc [~chetanm]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6911) Provide a way to tune inline size while storing binaries
[ https://issues.apache.org/jira/browse/OAK-6911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-6911: --- Labels: performance scalability (was: ) > Provide a way to tune inline size while storing binaries > > > Key: OAK-6911 > URL: https://issues.apache.org/jira/browse/OAK-6911 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Reporter: Chetan Mehrotra > Labels: performance, scalability > Fix For: 1.8 > > > SegmentNodeStore currently inlines binaries of size less that 16KB > (Segment.MEDIUM_LIMIT) even if external BlobStore is configured. > Due to this behaviour quite a bit of segment tar storage consist of blob > data. In one setup out of 370 GB segmentstore size 290GB is due to inlined > binary. If most of this binary content is moved to BlobStore then it would > allow same repository to work better in lesser RAM > So it would be useful if some way is provided to disable this default > behaviour and let BlobStore take control of inline size i.e. in presence of > BlobStore no inlining is attempted by SegmentWriter. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-5859) Analyse and reduce IO amplification by OS
[ https://issues.apache.org/jira/browse/OAK-5859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-5859: --- Labels: perfomance scalability (was: ) > Analyse and reduce IO amplification by OS > - > > Key: OAK-5859 > URL: https://issues.apache.org/jira/browse/OAK-5859 > Project: Jackrabbit Oak > Issue Type: Task > Components: segment-tar >Reporter: Michael Dürig > Labels: perfomance, scalability > > Certain operation system settings might result in too much data actually > being read from disk causing early setting on of thrashing. E.g. transparent > huge pages or too big read aheads might be contra productive in combination > with the TarMKs memory mapping model. > * Determine the ratio of data being read by the TarMK and actual data being > read from disk. Determine the impact of relevant OS parameters (e.g. > transparent huge pages) on this ratio. > * Compare memory mapped mode with file IO mode with an accordingly increased > segment cache. This would move prediction of what is likely to be read next > from the OS layer into our segment cache eviction strategy. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
