[jira] [Commented] (OAK-6452) IllegalStateException: too much data for a segment during oak-upgrade from segment to segment-tar
[
https://issues.apache.org/jira/browse/OAK-6452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16087360#comment-16087360
]
Valentin Olteanu commented on OAK-6452:
---
[~frm], [~mduerig], can you please take a look?
> IllegalStateException: too much data for a segment during oak-upgrade from
> segment to segment-tar
> -
>
> Key: OAK-6452
> URL: https://issues.apache.org/jira/browse/OAK-6452
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, upgrade
>Affects Versions: 1.7.3
>Reporter: Valentin Olteanu
>Priority: Critical
> Fix For: 1.7.6
>
>
> During the migration of a big repo from the {{old-segment}} format to
> {{segment-tar}} using {{oak-upgrade-1.7.3}}, I've got the following error:
> {code}
> 14.07.2017 09:05:51.920 [main] *INFO*
> org.apache.jackrabbit.oak.upgrade.RepositorySidegrade - Copying node
> #89333: /oak:index/uuid/:index/a9f9a3ed-6183-4e9e-9480-1b4fd196a829
> 14.07.2017 10:00:27.957 [TarMK flush
> [extracted/crx-quickstart/repository-oak-upgrade/segmentstore]] *ERROR*
> org.apache.jackrabbit.oak.segment.file.SafeRunnable - Uncaught exception in
> TarMK flush [extracted/crx-quickstart/repository-oak-upgrade/segmentstore]
> java.lang.IllegalStateException: too much data for a segment
> at
> org.apache.jackrabbit.oak.segment.SegmentBufferWriter.flush(SegmentBufferWriter.java:322)
> ~[oak-upgrade-1.7.3.jar:1.7.3]
> at
> org.apache.jackrabbit.oak.segment.SegmentBufferWriterPool.flush(SegmentBufferWriterPool.java:142)
> ~[oak-upgrade-1.7.3.jar:1.7.3]
> at
> org.apache.jackrabbit.oak.segment.DefaultSegmentWriter.flush(DefaultSegmentWriter.java:138)
> ~[oak-upgrade-1.7.3.jar:1.7.3]
> at
> org.apache.jackrabbit.oak.segment.file.FileStore$8.call(FileStore.java:345)
> ~[oak-upgrade-1.7.3.jar:1.7.3]
> at
> org.apache.jackrabbit.oak.segment.file.FileStore$8.call(FileStore.java:342)
> ~[oak-upgrade-1.7.3.jar:1.7.3]
> at
> org.apache.jackrabbit.oak.segment.file.TarRevisions.doFlush(TarRevisions.java:213)
> ~[oak-upgrade-1.7.3.jar:1.7.3]
> at
> org.apache.jackrabbit.oak.segment.file.TarRevisions.flush(TarRevisions.java:201)
> ~[oak-upgrade-1.7.3.jar:1.7.3]
> at
> org.apache.jackrabbit.oak.segment.file.FileStore.flush(FileStore.java:342)
> ~[oak-upgrade-1.7.3.jar:1.7.3]
> at
> org.apache.jackrabbit.oak.segment.file.FileStore$3.run(FileStore.java:242)
> ~[oak-upgrade-1.7.3.jar:1.7.3]
> at
> org.apache.jackrabbit.oak.segment.file.SafeRunnable.run(SafeRunnable.java:67)
> ~[oak-upgrade-1.7.3.jar:1.7.3]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0_131]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [na:1.8.0_131]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [na:1.8.0_131]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [na:1.8.0_131]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_131]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_131]
> at java.lang.Thread.run(Thread.java:748) [na:1.8.0_131]
> 14.07.2017 10:00:28.448 [main] *INFO*
> org.apache.jackrabbit.oak.segment.file.FileStore - TarMK closed:
> extracted/crx-quickstart/repository-oak-upgrade/segmentstore
> 14.07.2017 10:00:28.658 [main] *INFO*
> org.apache.jackrabbit.oak.plugins.segment.file.FileStore - TarMK closed:
> extracted/crx-quickstart/repository/segmentstore
> Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit
> exceeded
> at
> org.apache.jackrabbit.oak.segment.RecordType.values(RecordType.java:24)
> at
> org.apache.jackrabbit.oak.segment.ImmutableRecordNumbers$1$1.getType(ImmutableRecordNumbers.java:86)
> at
> org.apache.jackrabbit.oak.segment.Segment.forEachRecord(Segment.java:703)
> at
> org.apache.jackrabbit.oak.segment.file.AbstractFileStore.readBinaryReferences(AbstractFileStore.java:277)
> at
> org.apache.jackrabbit.oak.segment.file.FileStore.writeSegment(FileStore.java:511)
> at
> org.apache.jackrabbit.oak.segment.SegmentBufferWriter.flush(SegmentBufferWriter.java:356)
> at
> org.apache.jackrabbit.oak.segment.SegmentBufferWriter.prepare(SegmentBufferWriter.java:423)
> at
> org.apache.jackrabbit.oak.segment.RecordWriters$RecordWriter.write(RecordWriters.java:70)
> at
>
[jira] [Created] (OAK-6452) IllegalStateException: too much data for a segment during oak-upgrade from segment to segment-tar
Valentin Olteanu created OAK-6452:
-
Summary: IllegalStateException: too much data for a segment during
oak-upgrade from segment to segment-tar
Key: OAK-6452
URL: https://issues.apache.org/jira/browse/OAK-6452
Project: Jackrabbit Oak
Issue Type: Bug
Components: segment-tar, upgrade
Affects Versions: 1.7.3
Reporter: Valentin Olteanu
Priority: Critical
Fix For: 1.7.6
During the migration of a big repo from the {{old-segment}} format to
{{segment-tar}} using {{oak-upgrade-1.7.3}}, I've got the following error:
{code}
14.07.2017 09:05:51.920 [main] *INFO*
org.apache.jackrabbit.oak.upgrade.RepositorySidegrade - Copying node
#89333: /oak:index/uuid/:index/a9f9a3ed-6183-4e9e-9480-1b4fd196a829
14.07.2017 10:00:27.957 [TarMK flush
[extracted/crx-quickstart/repository-oak-upgrade/segmentstore]] *ERROR*
org.apache.jackrabbit.oak.segment.file.SafeRunnable - Uncaught exception in
TarMK flush [extracted/crx-quickstart/repository-oak-upgrade/segmentstore]
java.lang.IllegalStateException: too much data for a segment
at
org.apache.jackrabbit.oak.segment.SegmentBufferWriter.flush(SegmentBufferWriter.java:322)
~[oak-upgrade-1.7.3.jar:1.7.3]
at
org.apache.jackrabbit.oak.segment.SegmentBufferWriterPool.flush(SegmentBufferWriterPool.java:142)
~[oak-upgrade-1.7.3.jar:1.7.3]
at
org.apache.jackrabbit.oak.segment.DefaultSegmentWriter.flush(DefaultSegmentWriter.java:138)
~[oak-upgrade-1.7.3.jar:1.7.3]
at
org.apache.jackrabbit.oak.segment.file.FileStore$8.call(FileStore.java:345)
~[oak-upgrade-1.7.3.jar:1.7.3]
at
org.apache.jackrabbit.oak.segment.file.FileStore$8.call(FileStore.java:342)
~[oak-upgrade-1.7.3.jar:1.7.3]
at
org.apache.jackrabbit.oak.segment.file.TarRevisions.doFlush(TarRevisions.java:213)
~[oak-upgrade-1.7.3.jar:1.7.3]
at
org.apache.jackrabbit.oak.segment.file.TarRevisions.flush(TarRevisions.java:201)
~[oak-upgrade-1.7.3.jar:1.7.3]
at
org.apache.jackrabbit.oak.segment.file.FileStore.flush(FileStore.java:342)
~[oak-upgrade-1.7.3.jar:1.7.3]
at
org.apache.jackrabbit.oak.segment.file.FileStore$3.run(FileStore.java:242)
~[oak-upgrade-1.7.3.jar:1.7.3]
at
org.apache.jackrabbit.oak.segment.file.SafeRunnable.run(SafeRunnable.java:67)
~[oak-upgrade-1.7.3.jar:1.7.3]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[na:1.8.0_131]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
[na:1.8.0_131]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
[na:1.8.0_131]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
[na:1.8.0_131]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[na:1.8.0_131]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[na:1.8.0_131]
at java.lang.Thread.run(Thread.java:748) [na:1.8.0_131]
14.07.2017 10:00:28.448 [main] *INFO*
org.apache.jackrabbit.oak.segment.file.FileStore - TarMK closed:
extracted/crx-quickstart/repository-oak-upgrade/segmentstore
14.07.2017 10:00:28.658 [main] *INFO*
org.apache.jackrabbit.oak.plugins.segment.file.FileStore - TarMK closed:
extracted/crx-quickstart/repository/segmentstore
Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit
exceeded
at
org.apache.jackrabbit.oak.segment.RecordType.values(RecordType.java:24)
at
org.apache.jackrabbit.oak.segment.ImmutableRecordNumbers$1$1.getType(ImmutableRecordNumbers.java:86)
at
org.apache.jackrabbit.oak.segment.Segment.forEachRecord(Segment.java:703)
at
org.apache.jackrabbit.oak.segment.file.AbstractFileStore.readBinaryReferences(AbstractFileStore.java:277)
at
org.apache.jackrabbit.oak.segment.file.FileStore.writeSegment(FileStore.java:511)
at
org.apache.jackrabbit.oak.segment.SegmentBufferWriter.flush(SegmentBufferWriter.java:356)
at
org.apache.jackrabbit.oak.segment.SegmentBufferWriter.prepare(SegmentBufferWriter.java:423)
at
org.apache.jackrabbit.oak.segment.RecordWriters$RecordWriter.write(RecordWriters.java:70)
at
org.apache.jackrabbit.oak.segment.DefaultSegmentWriter$SegmentWriteOperation.writeValueRecord(DefaultSegmentWriter.java:499)
at
org.apache.jackrabbit.oak.segment.DefaultSegmentWriter$SegmentWriteOperation.writeString(DefaultSegmentWriter.java:518)
at
org.apache.jackrabbit.oak.segment.DefaultSegmentWriter$SegmentWriteOperation.writeMap(DefaultSegmentWriter.java:324)
at
org.apache.jackrabbit.oak.segment.DefaultSegmentWriter$SegmentWriteOperation.writeNodeUncached(DefaultSegmentWriter.java:870)
at
[jira] [Resolved] (OAK-6111) update maven-scr-plugin
[ https://issues.apache.org/jira/browse/OAK-6111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu resolved OAK-6111. -- Resolution: Won't Fix Fix Version/s: (was: 1.8) Closing in favour of OAK-6449 > update maven-scr-plugin > --- > > Key: OAK-6111 > URL: https://issues.apache.org/jira/browse/OAK-6111 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: parent >Reporter: Julian Reschke > Attachments: > org.apache.jackrabbit.oak.run.osgi.JaasConfigSpiTest.txt, unit-tests.log, > unit-tests.log > > > Updating maven-scr-plugin to 1.24.0 causes subsequent failures in oak-pojo-sr. > It seems we also need to update felix components, and add > org.apache.felix.scr.compat, but even with that, I still get test failures. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-4668) Make async index more resilient on documentmk
[ https://issues.apache.org/jira/browse/OAK-4668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated OAK-4668: - Fix Version/s: (was: 1.4.15) 1.4.16 > Make async index more resilient on documentmk > - > > Key: OAK-4668 > URL: https://issues.apache.org/jira/browse/OAK-4668 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Alex Deparvu >Assignee: Alex Deparvu > Labels: candidate_oak_1_2 > Fix For: 1.5.9, 1.6.0, 1.4.16 > > Attachments: OAK-4668.patch, OAK-4668-v2.patch, OAK-4668-v3.patch > > > The async index update suffers in an eventual consistency store from stale > reads of the root node. It may happen that in a cluster an indexing job > running concurrently on more nodes, would not see the lease updates coming > from another cluster node, so it would end up wiping away checkpoints and/or > triggering a full reindex. > There is not much we can do at this level, but make the code a bit more > resilient for this specific case (_reindex due to missing reference > checkpoint_) by issuing a write+read operation to force a root revision > update which would hopefully prevent a full reindex. > For background, the preferred solution is to have an upper layer choose the > node where the async jobs run (aka. use sling discovery bundles). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-4668) Make async index more resilient on documentmk
[ https://issues.apache.org/jira/browse/OAK-4668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated OAK-4668: - Labels: candidate_oak_1_2 (was: ) > Make async index more resilient on documentmk > - > > Key: OAK-4668 > URL: https://issues.apache.org/jira/browse/OAK-4668 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Alex Deparvu >Assignee: Alex Deparvu > Labels: candidate_oak_1_2 > Fix For: 1.4.15, 1.5.9, 1.6.0 > > Attachments: OAK-4668.patch, OAK-4668-v2.patch, OAK-4668-v3.patch > > > The async index update suffers in an eventual consistency store from stale > reads of the root node. It may happen that in a cluster an indexing job > running concurrently on more nodes, would not see the lease updates coming > from another cluster node, so it would end up wiping away checkpoints and/or > triggering a full reindex. > There is not much we can do at this level, but make the code a bit more > resilient for this specific case (_reindex due to missing reference > checkpoint_) by issuing a write+read operation to force a root revision > update which would hopefully prevent a full reindex. > For background, the preferred solution is to have an upper layer choose the > node where the async jobs run (aka. use sling discovery bundles). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (OAK-6451) MultiplexingPermissionProvider is ignored by the CompositeAuthorizationConfiguration
[
https://issues.apache.org/jira/browse/OAK-6451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Deparvu resolved OAK-6451.
---
Resolution: Fixed
fixed with http://svn.apache.org/viewvc?rev=1801963=rev
the solution is to use the composite only if there's no other aggregated config
available. currently there's no easy way to include it as a composite in the
default composite.
[~anchela] please take a look. this is not the cleanest solution, but it was
the least intrusive one. I'm not sure if we need to start supporting composites
of composites, or if this is ok for now.
> MultiplexingPermissionProvider is ignored by the
> CompositeAuthorizationConfiguration
>
>
> Key: OAK-6451
> URL: https://issues.apache.org/jira/browse/OAK-6451
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
> Fix For: 1.8, 1.7.4
>
>
> Because of the way {{PermissionProviders}} are aggregated [0], the
> {{MultiplexingPermissionProvider}} is ignored on account of not being a
> {{AggregatedPermissionProvider}}.
> [0]
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/composite/CompositeAuthorizationConfiguration.java#L179
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6111) update maven-scr-plugin
[ https://issues.apache.org/jira/browse/OAK-6111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16087316#comment-16087316 ] Julian Reschke commented on OAK-6111: - Yes, that sounds right. > update maven-scr-plugin > --- > > Key: OAK-6111 > URL: https://issues.apache.org/jira/browse/OAK-6111 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: parent >Reporter: Julian Reschke > Fix For: 1.8 > > Attachments: > org.apache.jackrabbit.oak.run.osgi.JaasConfigSpiTest.txt, unit-tests.log, > unit-tests.log > > > Updating maven-scr-plugin to 1.24.0 causes subsequent failures in oak-pojo-sr. > It seems we also need to update felix components, and add > org.apache.felix.scr.compat, but even with that, I still get test failures. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-4668) Make async index more resilient on documentmk
[ https://issues.apache.org/jira/browse/OAK-4668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated OAK-4668: - Labels: (was: candidate_oak_1_2) > Make async index more resilient on documentmk > - > > Key: OAK-4668 > URL: https://issues.apache.org/jira/browse/OAK-4668 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Alex Deparvu >Assignee: Alex Deparvu > Fix For: 1.4.15, 1.5.9, 1.6.0 > > Attachments: OAK-4668.patch, OAK-4668-v2.patch, OAK-4668-v3.patch > > > The async index update suffers in an eventual consistency store from stale > reads of the root node. It may happen that in a cluster an indexing job > running concurrently on more nodes, would not see the lease updates coming > from another cluster node, so it would end up wiping away checkpoints and/or > triggering a full reindex. > There is not much we can do at this level, but make the code a bit more > resilient for this specific case (_reindex due to missing reference > checkpoint_) by issuing a write+read operation to force a root revision > update which would hopefully prevent a full reindex. > For background, the preferred solution is to have an upper layer choose the > node where the async jobs run (aka. use sling discovery bundles). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-4668) Make async index more resilient on documentmk
[ https://issues.apache.org/jira/browse/OAK-4668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated OAK-4668: - Fix Version/s: 1.4.15 > Make async index more resilient on documentmk > - > > Key: OAK-4668 > URL: https://issues.apache.org/jira/browse/OAK-4668 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Alex Deparvu >Assignee: Alex Deparvu > Fix For: 1.4.15, 1.5.9, 1.6.0 > > Attachments: OAK-4668.patch, OAK-4668-v2.patch, OAK-4668-v3.patch > > > The async index update suffers in an eventual consistency store from stale > reads of the root node. It may happen that in a cluster an indexing job > running concurrently on more nodes, would not see the lease updates coming > from another cluster node, so it would end up wiping away checkpoints and/or > triggering a full reindex. > There is not much we can do at this level, but make the code a bit more > resilient for this specific case (_reindex due to missing reference > checkpoint_) by issuing a write+read operation to force a root revision > update which would hopefully prevent a full reindex. > For background, the preferred solution is to have an upper layer choose the > node where the async jobs run (aka. use sling discovery bundles). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (OAK-6451) MultiplexingPermissionProvider is ignored by the CompositeAuthorizationConfiguration
Alex Deparvu created OAK-6451:
-
Summary: MultiplexingPermissionProvider is ignored by the
CompositeAuthorizationConfiguration
Key: OAK-6451
URL: https://issues.apache.org/jira/browse/OAK-6451
Project: Jackrabbit Oak
Issue Type: Bug
Components: core, security
Reporter: Alex Deparvu
Assignee: Alex Deparvu
Fix For: 1.8, 1.7.4
Because of the way {{PermissionProviders}} are aggregated [0], the
{{MultiplexingPermissionProvider}} is ignored on account of not being a
{{AggregatedPermissionProvider}}.
[0]
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/composite/CompositeAuthorizationConfiguration.java#L179
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6359) Change behavior for very complex queries
[
https://issues.apache.org/jira/browse/OAK-6359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-6359:
Labels: candidate_oak_1_0 candidate_oak_1_2 candidate_oak_1_4
candidate_oak_1_6 (was: candidate_oak_1_2 candidate_oak_1_4 candidate_oak_1_6)
> Change behavior for very complex queries
>
>
> Key: OAK-6359
> URL: https://issues.apache.org/jira/browse/OAK-6359
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Critical
> Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4,
> candidate_oak_1_6
> Fix For: 1.8, 1.7.4
>
>
> Very complex queries can cause take a long time to parse, and can possibly
> cause OOME. It would be good if processing queries automatically stops after
> some number of loops, after some time, or some amount of memory was used. And
> then throw an exception "query too complex".
> Example query:
> {noformat}
> //element(*,rep:Authorizable)[ ( (
> jcr:like(fn:lower-case(fn:name()), 'audio%')
> or jcr:contains(@rep:principalName,'audio*')
> or jcr:contains(@cq:first-name,'audio*')
> or jcr:contains(@cq:last-name,'audio*')
> or jcr:contains(profile/@givenName,'audio*')
> or jcr:contains(profile/@familyName,'audio*') )
> and ( jcr:like(fn:lower-case(fn:name()), 'conference%')
> or jcr:contains(@rep:principalName,'conference*')
> or jcr:contains(@cq:first-name,'conference*')
> or jcr:contains(@cq:last-name,'conference*')
> or jcr:contains(profile/@givenName,'conference*')
> or jcr:contains(profile/@familyName,'conference*') )
> and ( jcr:like(fn:lower-case(fn:name()), 'details:%')
> or jcr:contains(@rep:principalName,'details:*')
> or jcr:contains(@cq:first-name,'details:*')
> or jcr:contains(@cq:last-name,'details:*')
> or jcr:contains(profile/@givenName,'details:*')
> or jcr:contains(profile/@familyName,'details:*') )
> and ( jcr:like(fn:lower-case(fn:name()), 'conference%')
> or jcr:contains(@rep:principalName,'conference*')
> or jcr:contains(@cq:first-name,'conference*')
> or jcr:contains(@cq:last-name,'conference*')
> or jcr:contains(profile/@givenName,'conference*')
> or jcr:contains(profile/@familyName,'conference*') )
> and ( jcr:like(fn:lower-case(fn:name()), 'code:%')
> or jcr:contains(@rep:principalName,'code:*')
> or jcr:contains(@cq:first-name,'code:*')
> or jcr:contains(@cq:last-name,'code:*')
> or jcr:contains(profile/@givenName,'code:*')
> or jcr:contains(profile/@familyName,'code:*') )
> and ( jcr:like(fn:lower-case(fn:name()), '123456%')
> or jcr:contains(@rep:principalName,'123456*')
> or jcr:contains(@cq:first-name,'123456*')
> or jcr:contains(@cq:last-name,'123456*')
> or jcr:contains(profile/@givenName,'123456*')
> or jcr:contains(profile/@familyName,'123456*') )
> and ( jcr:like(fn:lower-case(fn:name()), 'further%')
> or jcr:contains(@rep:principalName,'further*')
> or jcr:contains(@cq:first-name,'further*')
> or jcr:contains(@cq:last-name,'further*')
> or jcr:contains(profile/@givenName,'further*')
> or jcr:contains(profile/@familyName,'further*') )
> and ( jcr:like(fn:lower-case(fn:name()), 'dial%')
> or jcr:contains(@rep:principalName,'dial*')
> or jcr:contains(@cq:first-name,'dial*')
> or jcr:contains(@cq:last-name,'dial*')
> or jcr:contains(profile/@givenName,'dial*')
> or jcr:contains(profile/@familyName,'dial*') )
> and ( jcr:like(fn:lower-case(fn:name()), 'in%')
> or jcr:contains(@rep:principalName,'in*')
> or jcr:contains(@cq:first-name,'in*')
> or jcr:contains(@cq:last-name,'in*')
> or jcr:contains(profile/@givenName,'in*')
> or jcr:contains(profile/@familyName,'in*') )
> and ( jcr:like(fn:lower-case(fn:name()), 'numbers:%')
> or jcr:contains(@rep:principalName,'numbers:*')
> or jcr:contains(@cq:first-name,'numbers:*')
> or jcr:contains(@cq:last-name,'numbers:*')
> or jcr:contains(profile/@givenName,'numbers:*')
> or jcr:contains(profile/@familyName,'numbers:*') )
> and ( jcr:like(fn:lower-case(fn:name()), 'http://wikipedia.org%')
> or jcr:contains(@rep:principalName,'http://wikipedia.org*')
> or jcr:contains(@cq:first-name,'http://wikipedia.org*')
> or jcr:contains(@cq:last-name,'http://wikipedia.org*')
> or jcr:contains(profile/@givenName,'http://wikipedia.org*')
> or jcr:contains(profile/@familyName,'http://wikipedia.org*') )
> and ( jcr:like(fn:lower-case(fn:name()), 'conference%')
> or jcr:contains(@rep:principalName,'conference*')
> or jcr:contains(@cq:first-name,'conference*')
> or jcr:contains(@cq:last-name,'conference*')
> or jcr:contains(profile/@givenName,'conference*')
> or jcr:contains(profile/@familyName,'conference*') )
> and ( jcr:like(fn:lower-case(fn:name()), 'number(s):%')
> or
[jira] [Commented] (OAK-6111) update maven-scr-plugin
[ https://issues.apache.org/jira/browse/OAK-6111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16087192#comment-16087192 ] Robert Munteanu commented on OAK-6111: -- [~reschke] - Once OAK-6450 is fixed we are free to unable to maven-scr-plugin. However, I would prefer to resolve this as a won't fix and implement OAK-6449 instead. WDYT? > update maven-scr-plugin > --- > > Key: OAK-6111 > URL: https://issues.apache.org/jira/browse/OAK-6111 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: parent >Reporter: Julian Reschke > Fix For: 1.8 > > Attachments: > org.apache.jackrabbit.oak.run.osgi.JaasConfigSpiTest.txt, unit-tests.log, > unit-tests.log > > > Updating maven-scr-plugin to 1.24.0 causes subsequent failures in oak-pojo-sr. > It seems we also need to update felix components, and add > org.apache.felix.scr.compat, but even with that, I still get test failures. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (OAK-6111) update maven-scr-plugin
[ https://issues.apache.org/jira/browse/OAK-6111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16087192#comment-16087192 ] Robert Munteanu edited comment on OAK-6111 at 7/14/17 11:16 AM: [~reschke] - Once OAK-6450 is fixed we are free to use maven-scr-plugin. However, I would prefer to resolve this as a won't fix and implement OAK-6449 instead. WDYT? was (Author: rombert): [~reschke] - Once OAK-6450 is fixed we are free to unable to maven-scr-plugin. However, I would prefer to resolve this as a won't fix and implement OAK-6449 instead. WDYT? > update maven-scr-plugin > --- > > Key: OAK-6111 > URL: https://issues.apache.org/jira/browse/OAK-6111 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: parent >Reporter: Julian Reschke > Fix For: 1.8 > > Attachments: > org.apache.jackrabbit.oak.run.osgi.JaasConfigSpiTest.txt, unit-tests.log, > unit-tests.log > > > Updating maven-scr-plugin to 1.24.0 causes subsequent failures in oak-pojo-sr. > It seems we also need to update felix components, and add > org.apache.felix.scr.compat, but even with that, I still get test failures. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (OAK-6450) Stop relying on the service.pid property in SecurityProviderRegistration
[
https://issues.apache.org/jira/browse/OAK-6450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16087155#comment-16087155
]
Robert Munteanu edited comment on OAK-6450 at 7/14/17 10:31 AM:
I've uploaded a patch which fixes the issue.
[~anchela], [~chetanm], [~frm], [~reschke] - would appreciate your feedback
based on the discussion from OAK-6111 . I successfully ran a {{mvn clean
install -Ppedantic}} build with these changes and the maven-scr-plugin version
set to 1.24.0
To quote the commit message:
{noformat}Use the comoponent.name component property if the service.pid
is not available. The SecurityProviderRegistration property name is
unchanged, for backwards compatibility reasons.
The objectClass property may not be used as it points to the service
name(s) under which the component is registered. Using a custom property
name such as oak.security.name was considered but discarded as:
* all services would need to set this service property
* the component.name property is guaranteed to be added by the SCR
implementation, according to the OSGi Declarative Services spec 1.3 (
see OSGi Compendium R6, section 112.6 - Component Properties ){noformat}
I intend to go ahead with OAK-6449 once this is fixed.
was (Author: rombert):
I've uploaded a patch
[~anchela], [~chetanm], [~frm], [~reschke] - would appreciate your feedback
based on the discussion from OAK-6111 . I successfully ran a {mvn clean install
-Ppedantic} build with these changes and the maven-scr-plugin version set to
1.24.0
To quote the commit message:
{noformat}Use the comoponent.name component property if the service.pid
is not available. The SecurityProviderRegistration property name is
unchanged, for backwards compatibility reasons.
The objectClass property may not be used as it points to the service
name(s) under which the component is registered. Using a custom property
name such as oak.security.name was considered but discarded as:
* all services would need to set this service property
* the component.name property is guaranteed to be added by the SCR
implementation, according to the OSGi Declarative Services spec 1.3 (
see OSGi Compendium R6, section 112.6 - Component Properties ){noformat}
I intend to go ahead with OAK-6449 once this is fixed.
> Stop relying on the service.pid property in SecurityProviderRegistration
>
>
> Key: OAK-6450
> URL: https://issues.apache.org/jira/browse/OAK-6450
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: security
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: 1.8, 1.7.4
>
> Attachments:
> 0001-OAK-6450-Stop-relying-on-the-service.pid-property-in.patch
>
>
> As discussed in OAK-6111, we should stop relying on the {{service.pid}} OSGi
> property for tracking required services as it was incorrectly set so far by
> the {{maven-scr-plugin}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6450) Stop relying on the service.pid property in SecurityProviderRegistration
[
https://issues.apache.org/jira/browse/OAK-6450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated OAK-6450:
-
Attachment: 0001-OAK-6450-Stop-relying-on-the-service.pid-property-in.patch
I've uploaded a patch
[~anchela], [~chetanm], [~frm], [~reschke] - would appreciate your feedback
based on the discussion from OAK-6111 . I successfully ran a {mvn clean install
-Ppedantic} build with these changes and the maven-scr-plugin version set to
1.24.0
To quote the commit message:
{noformat}Use the comoponent.name component property if the service.pid
is not available. The SecurityProviderRegistration property name is
unchanged, for backwards compatibility reasons.
The objectClass property may not be used as it points to the service
name(s) under which the component is registered. Using a custom property
name such as oak.security.name was considered but discarded as:
* all services would need to set this service property
* the component.name property is guaranteed to be added by the SCR
implementation, according to the OSGi Declarative Services spec 1.3 (
see OSGi Compendium R6, section 112.6 - Component Properties ){noformat}
I intend to go ahead with OAK-6449 once this is fixed.
> Stop relying on the service.pid property in SecurityProviderRegistration
>
>
> Key: OAK-6450
> URL: https://issues.apache.org/jira/browse/OAK-6450
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: security
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: 1.8, 1.7.4
>
> Attachments:
> 0001-OAK-6450-Stop-relying-on-the-service.pid-property-in.patch
>
>
> As discussed in OAK-6111, we should stop relying on the {{service.pid}} OSGi
> property for tracking required services as it was incorrectly set so far by
> the {{maven-scr-plugin}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-5827) Don't use SHA-1 for new DataStore binaries
[ https://issues.apache.org/jira/browse/OAK-5827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-5827: Fix Version/s: 1.6.4 > Don't use SHA-1 for new DataStore binaries > -- > > Key: OAK-5827 > URL: https://issues.apache.org/jira/browse/OAK-5827 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Thomas Mueller >Assignee: Amit Jain > Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4 > Fix For: 1.7.0, 1.8, 1.6.4 > > Attachments: OAK-5827b.patch, OAK-5827.patch > > > A [collision for > SHA-1|https://www.schneier.com/blog/archives/2017/02/sha-1_collision.html] > has been published. We still use SHA-1 for the FileDataStore, and I believe > the S3 DataStore right now. Given there is a collision, we should switch to a > stronger algorithm, for example SHA-256, for new binaries. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-5827) Don't use SHA-1 for new DataStore binaries
[ https://issues.apache.org/jira/browse/OAK-5827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16087124#comment-16087124 ] Julian Reschke commented on OAK-5827: - trunk: [r1786122|http://svn.apache.org/r1786122] 1.6: [r1801921|http://svn.apache.org/r1801921] > Don't use SHA-1 for new DataStore binaries > -- > > Key: OAK-5827 > URL: https://issues.apache.org/jira/browse/OAK-5827 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Thomas Mueller >Assignee: Amit Jain > Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4 > Fix For: 1.7.0, 1.8, 1.6.4 > > Attachments: OAK-5827b.patch, OAK-5827.patch > > > A [collision for > SHA-1|https://www.schneier.com/blog/archives/2017/02/sha-1_collision.html] > has been published. We still use SHA-1 for the FileDataStore, and I believe > the S3 DataStore right now. Given there is a collision, we should switch to a > stronger algorithm, for example SHA-256, for new binaries. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-5827) Don't use SHA-1 for new DataStore binaries
[ https://issues.apache.org/jira/browse/OAK-5827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-5827: Labels: candidate_oak_1_0 candidate_oak_1_2 candidate_oak_1_4 (was: candidate_oak_1_0 candidate_oak_1_2 candidate_oak_1_4 candidate_oak_1_6) > Don't use SHA-1 for new DataStore binaries > -- > > Key: OAK-5827 > URL: https://issues.apache.org/jira/browse/OAK-5827 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Thomas Mueller >Assignee: Amit Jain > Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4 > Fix For: 1.7.0, 1.8, 1.6.4 > > Attachments: OAK-5827b.patch, OAK-5827.patch > > > A [collision for > SHA-1|https://www.schneier.com/blog/archives/2017/02/sha-1_collision.html] > has been published. We still use SHA-1 for the FileDataStore, and I believe > the S3 DataStore right now. Given there is a collision, we should switch to a > stronger algorithm, for example SHA-256, for new binaries. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-6442) Update Oak 1.6 to Jackrabbit 2.14.2
[ https://issues.apache.org/jira/browse/OAK-6442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16087122#comment-16087122 ] Julian Reschke commented on OAK-6442: - 1.6: [r1801921|http://svn.apache.org/r1801921] > Update Oak 1.6 to Jackrabbit 2.14.2 > --- > > Key: OAK-6442 > URL: https://issues.apache.org/jira/browse/OAK-6442 > Project: Jackrabbit Oak > Issue Type: Bug >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Trivial > Fix For: 1.8, 1.6.4 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (OAK-6442) Update Oak 1.6 to Jackrabbit 2.14.2
[ https://issues.apache.org/jira/browse/OAK-6442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved OAK-6442. - Resolution: Fixed > Update Oak 1.6 to Jackrabbit 2.14.2 > --- > > Key: OAK-6442 > URL: https://issues.apache.org/jira/browse/OAK-6442 > Project: Jackrabbit Oak > Issue Type: Bug >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Trivial > Fix For: 1.8, 1.6.4 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6442) Update Oak 1.6 to Jackrabbit 2.14.2
[ https://issues.apache.org/jira/browse/OAK-6442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-6442: Fix Version/s: 1.6.4 > Update Oak 1.6 to Jackrabbit 2.14.2 > --- > > Key: OAK-6442 > URL: https://issues.apache.org/jira/browse/OAK-6442 > Project: Jackrabbit Oak > Issue Type: Bug >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Trivial > Fix For: 1.8, 1.6.4 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-4883) Missing BlobGarbageCollection MBean on standby instance
[
https://issues.apache.org/jira/browse/OAK-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari updated OAK-4883:
Fix Version/s: 1.4.17
> Missing BlobGarbageCollection MBean on standby instance
> ---
>
> Key: OAK-4883
> URL: https://issues.apache.org/jira/browse/OAK-4883
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, segmentmk
>Reporter: Alex Deparvu
>Assignee: Francesco Mari
> Labels: candidate_oak_1_4, gc
> Fix For: Segment Tar 0.0.16, 1.4.17
>
> Attachments: OAK-4883.patch, OAK-4883.patch
>
>
> The {{BlobGarbageCollection}} MBean is no longer available on a standby
> instance, this affects non-shared datastore setups (on a shared datastore
> you'd only need to run blob gc on the primary).
> This change was introduced by OAK-4089 (and backported to 1.4 branch with
> OAK-4093).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-4883) Missing BlobGarbageCollection MBean on standby instance
[
https://issues.apache.org/jira/browse/OAK-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16087025#comment-16087025
]
Francesco Mari commented on OAK-4883:
-
Ported back to 1.4 at r1801914.
> Missing BlobGarbageCollection MBean on standby instance
> ---
>
> Key: OAK-4883
> URL: https://issues.apache.org/jira/browse/OAK-4883
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, segmentmk
>Reporter: Alex Deparvu
>Assignee: Francesco Mari
> Labels: candidate_oak_1_4, gc
> Fix For: Segment Tar 0.0.16, 1.4.17
>
> Attachments: OAK-4883.patch, OAK-4883.patch
>
>
> The {{BlobGarbageCollection}} MBean is no longer available on a standby
> instance, this affects non-shared datastore setups (on a shared datastore
> you'd only need to run blob gc on the primary).
> This change was introduced by OAK-4089 (and backported to 1.4 branch with
> OAK-4093).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (OAK-6448) Backport OAK-4883 to the 1.4 branch
[ https://issues.apache.org/jira/browse/OAK-6448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Mari resolved OAK-6448. - Resolution: Fixed Fixed at r1801914. > Backport OAK-4883 to the 1.4 branch > --- > > Key: OAK-6448 > URL: https://issues.apache.org/jira/browse/OAK-6448 > Project: Jackrabbit Oak > Issue Type: Bug >Reporter: Francesco Mari >Assignee: Francesco Mari >Priority: Blocker > Fix For: 1.4.17 > > Attachments: OAK-6448-01.patch > > > OAK-4883 should be backported to the 1.4 branch. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (OAK-6450) Stop relying on the service.pid property in SecurityProviderRegistration
Robert Munteanu created OAK-6450:
Summary: Stop relying on the service.pid property in
SecurityProviderRegistration
Key: OAK-6450
URL: https://issues.apache.org/jira/browse/OAK-6450
Project: Jackrabbit Oak
Issue Type: Improvement
Components: security
Reporter: Robert Munteanu
Assignee: Robert Munteanu
Fix For: 1.8, 1.7.4
As discussed in OAK-6111, we should stop relying on the {{service.pid}} OSGi
property for tracking required services as it was incorrectly set so far by the
{{maven-scr-plugin}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
