[jira] [Commented] (OAK-9024) oak-solr-osgi imports org.slf4j.impl
[
https://issues.apache.org/jira/browse/OAK-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096922#comment-17096922
]
Manfred Baedke commented on OAK-9024:
-
Thx a lot, [~jsedding], that's a good tool to know. But don't you think that in
this case it's simpler and less risky just to embed slf4j-log4j12 as the patch
does?
> oak-solr-osgi imports org.slf4j.impl
>
>
> Key: OAK-9024
> URL: https://issues.apache.org/jira/browse/OAK-9024
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: solr
>Reporter: Julian Reschke
>Assignee: Manfred Baedke
>Priority: Minor
> Fix For: 1.28.0
>
> Attachments: OAK-9024.patch
>
>
> From the manifest:
> {{org.slf4j.impl;version="[1.6,2)"}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-9044) Improve unit test coverage of LdapProviderConfig
[ https://issues.apache.org/jira/browse/OAK-9044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-9044: Description: LdapProviderConfigTest should have a roundtrip test for every config parameter. Also there are no tests for the encoding/searchFilter methods . was:should have a roundtrip test for every config parameter > Improve unit test coverage of LdapProviderConfig > - > > Key: OAK-9044 > URL: https://issues.apache.org/jira/browse/OAK-9044 > Project: Jackrabbit Oak > Issue Type: Task > Components: auth-ldap >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > > LdapProviderConfigTest should have a roundtrip test for every config > parameter. > Also there are no tests for the encoding/searchFilter methods . -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-9044) Improve unit test coverage of LdapProviderConfig
[ https://issues.apache.org/jira/browse/OAK-9044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-9044: Description: should have a roundtrip test for every config parameter > Improve unit test coverage of LdapProviderConfig > - > > Key: OAK-9044 > URL: https://issues.apache.org/jira/browse/OAK-9044 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: auth-ldap >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > > should have a roundtrip test for every config parameter -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-9044) Improve unit test coverage of LdapProviderConfig
[ https://issues.apache.org/jira/browse/OAK-9044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-9044: Issue Type: Task (was: New Feature) > Improve unit test coverage of LdapProviderConfig > - > > Key: OAK-9044 > URL: https://issues.apache.org/jira/browse/OAK-9044 > Project: Jackrabbit Oak > Issue Type: Task > Components: auth-ldap >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > > should have a roundtrip test for every config parameter -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-9044) Improve unit test coverage of LdapProviderConfig
[ https://issues.apache.org/jira/browse/OAK-9044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-9044: Summary: Improve unit test coverage of LdapProviderConfig (was: LdapIProviderConfig should have a roundtrip test for every config parameter) > Improve unit test coverage of LdapProviderConfig > - > > Key: OAK-9044 > URL: https://issues.apache.org/jira/browse/OAK-9044 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: auth-ldap >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OAK-9046) Index function string-length should index size for binary properties
[
https://issues.apache.org/jira/browse/OAK-9046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096501#comment-17096501
]
Thomas Mueller edited comment on OAK-9046 at 4/30/20, 1:07 PM:
---
PR: https://github.com/oak-indexing/jackrabbit-oak/pull/151
was (Author: tmueller):
PR: https://github.com/apache/jackrabbit-oak/pull/205
> Index function string-length should index size for binary properties
>
>
> Key: OAK-9046
> URL: https://issues.apache.org/jira/browse/OAK-9046
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: indexing
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
>
> For index definition
> {noformat}
> jcr:primaryType="nt:unstructured"
> ordered="{Boolean}true"
> propertyIndex="{Boolean}true"
> type="Long"
> function="fn:string-length(jcr:content/@jcr:data)"/>
> {noformat}
> Expected result: Index the size of @jcr:data
> Current result:
> {noformat}
> ERROR o.a.j.o.p.i.l.LuceneDocumentMaker - Failed to calculate function value
> for [function, length, @jcr:content/jcr:data] ...
> java.lang.IllegalStateException: String is too long: 2325601444581057974
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-9046) Index function string-length should index size for binary properties
[
https://issues.apache.org/jira/browse/OAK-9046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096501#comment-17096501
]
Thomas Mueller commented on OAK-9046:
-
PR: https://github.com/apache/jackrabbit-oak/pull/205
> Index function string-length should index size for binary properties
>
>
> Key: OAK-9046
> URL: https://issues.apache.org/jira/browse/OAK-9046
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: indexing
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
>
> For index definition
> {noformat}
> jcr:primaryType="nt:unstructured"
> ordered="{Boolean}true"
> propertyIndex="{Boolean}true"
> type="Long"
> function="fn:string-length(jcr:content/@jcr:data)"/>
> {noformat}
> Expected result: Index the size of @jcr:data
> Current result:
> {noformat}
> ERROR o.a.j.o.p.i.l.LuceneDocumentMaker - Failed to calculate function value
> for [function, length, @jcr:content/jcr:data] ...
> java.lang.IllegalStateException: String is too long: 2325601444581057974
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-9046) Index function string-length should index size for binary properties
[
https://issues.apache.org/jira/browse/OAK-9046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096485#comment-17096485
]
Thomas Mueller commented on OAK-9046:
-
For SQL-2, the function is called length(). for a relational database, it would
be clear that this is the blob length (for a blob).
In xpath, there is no blob AFAIK, so the function is called string-length.
* http://jackrabbit.apache.org/oak/docs/query/grammar-sql2.html#dynamic_operand
* http://jackrabbit.apache.org/oak/docs/query/grammar-xpath.html#dynamic_operand
What we do currently is try to converting the binary to a string, then check
the length... this fails for segment store, and would fail if the binary is
large (e.g. 2 GB) due to out-of-memory.
I think it's fine to use length in number of bytes for binaries. Actually we do
that when calculating the length() function for conditions in a query as well.
> Index function string-length should index size for binary properties
>
>
> Key: OAK-9046
> URL: https://issues.apache.org/jira/browse/OAK-9046
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: indexing
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
>
> For index definition
> {noformat}
> jcr:primaryType="nt:unstructured"
> ordered="{Boolean}true"
> propertyIndex="{Boolean}true"
> type="Long"
> function="fn:string-length(jcr:content/@jcr:data)"/>
> {noformat}
> Expected result: Index the size of @jcr:data
> Current result:
> {noformat}
> ERROR o.a.j.o.p.i.l.LuceneDocumentMaker - Failed to calculate function value
> for [function, length, @jcr:content/jcr:data] ...
> java.lang.IllegalStateException: String is too long: 2325601444581057974
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OAK-9046) Index function string-length should index size for binary properties
Thomas Mueller created OAK-9046:
---
Summary: Index function string-length should index size for binary
properties
Key: OAK-9046
URL: https://issues.apache.org/jira/browse/OAK-9046
Project: Jackrabbit Oak
Issue Type: Improvement
Components: indexing
Reporter: Thomas Mueller
Assignee: Thomas Mueller
For index definition
{noformat}
{noformat}
Expected result: Index the size of @jcr:data
Current result:
{noformat}
ERROR o.a.j.o.p.i.l.LuceneDocumentMaker - Failed to calculate function value
for [function, length, @jcr:content/jcr:data] ...
java.lang.IllegalStateException: String is too long: 2325601444581057974
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-9024) oak-solr-osgi imports org.slf4j.impl
[
https://issues.apache.org/jira/browse/OAK-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096470#comment-17096470
]
Julian Reschke commented on OAK-9024:
-
https://github.com/apache/lucene-solr/blob/branch_6_6/solr/core/src/java/org/apache/solr/servlet/StartupLoggingUtils.java#L30
https://github.com/apache/lucene-solr/blob/branch_6_6/solr/core/src/java/org/apache/solr/logging/LogWatcher.java#L26
> oak-solr-osgi imports org.slf4j.impl
>
>
> Key: OAK-9024
> URL: https://issues.apache.org/jira/browse/OAK-9024
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: solr
>Reporter: Julian Reschke
>Assignee: Manfred Baedke
>Priority: Minor
> Fix For: 1.28.0
>
> Attachments: OAK-9024.patch
>
>
> From the manifest:
> {{org.slf4j.impl;version="[1.6,2)"}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-9041) Build Jackrabbit Oak #2732 failed
[ https://issues.apache.org/jira/browse/OAK-9041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096427#comment-17096427 ] Hudson commented on OAK-9041: - Build is still failing. Failed run: [Jackrabbit Oak #2737|https://builds.apache.org/job/Jackrabbit%20Oak/2737/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2737/console] > Build Jackrabbit Oak #2732 failed > - > > Key: OAK-9041 > URL: https://issues.apache.org/jira/browse/OAK-9041 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2732 has failed. > First failed run: [Jackrabbit Oak > #2732|https://builds.apache.org/job/Jackrabbit%20Oak/2732/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2732/console] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-9024) oak-solr-osgi imports org.slf4j.impl
[
https://issues.apache.org/jira/browse/OAK-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096360#comment-17096360
]
Julian Sedding commented on OAK-9024:
-
bndtools may have the answer, in particular the [xref
command|https://bnd.bndtools.org/commands/xref.html]
The following is an excerpt from its output, indicating which classes use
(i.e. import on a java level) classes from {{org.slf4j.impl}}.
{noformat}
$ bnd xref -cf target/oak-solr-osgi-1.27-SNAPSHOT.jar
...
org.slf4j.impl.StaticLoggerBinder < org.apache.solr.logging.LogWatcher
org.apache.solr.servlet.StartupLoggingUtils
...
{noformat}
Removing these two classes from the {{Embed-Dependency}} instruction should
remove the import for {{org.slf4j.impl}}. However, it woudl still be required
to analyze where the Oak code (transitively) depends on these classes and
examine if it can be safely used without them. If removing these classes is not
an option, it may still be safe to exclude the import for {{org.slf4j.impl}}
explicitly, iff no code path is used, where the {{StaticLoggerBinder}} is used.
If it _is_ used, however, then it we really need {{StaticLoggerBinder}} on the
class path (or provide an upstream fix for Solr).
> oak-solr-osgi imports org.slf4j.impl
>
>
> Key: OAK-9024
> URL: https://issues.apache.org/jira/browse/OAK-9024
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: solr
>Reporter: Julian Reschke
>Assignee: Manfred Baedke
>Priority: Minor
> Fix For: 1.28.0
>
> Attachments: OAK-9024.patch
>
>
> From the manifest:
> {{org.slf4j.impl;version="[1.6,2)"}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-9042) Improve azure archive recovery during startup
[ https://issues.apache.org/jira/browse/OAK-9042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096344#comment-17096344 ] Andrei Dulceanu commented on OAK-9042: -- Fixed in trunk at r1877193. Thanks for the contribution, [~smiroslav]! > Improve azure archive recovery during startup > - > > Key: OAK-9042 > URL: https://issues.apache.org/jira/browse/OAK-9042 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-azure, segment-tar >Affects Versions: 1.26.0 >Reporter: Miroslav Smiljanic >Assignee: Andrei Dulceanu >Priority: Major > Labels: Patch > Attachments: proposal.patch, test_tar_repo_recovery.patch > > > During repository startup if archive directory is not closed properly, > recovery will be performed. During that procedure, segents are copied to the > backup directory and deleted from the source direcory, one by one. > It can create problems and negativelly impact other ongoing actiivties, which > are accessing the same archive. This activity, for example, can be repository > cloning in order to create new environment. > Proposed patch, after creating backup is not deleting all segments from > archive, but only segments which could not be recovered. > [^proposal.patch] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OAK-9042) Improve azure archive recovery during startup
[ https://issues.apache.org/jira/browse/OAK-9042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu resolved OAK-9042. -- Fix Version/s: 1.28.0 Resolution: Fixed > Improve azure archive recovery during startup > - > > Key: OAK-9042 > URL: https://issues.apache.org/jira/browse/OAK-9042 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-azure, segment-tar >Affects Versions: 1.26.0 >Reporter: Miroslav Smiljanic >Assignee: Andrei Dulceanu >Priority: Major > Labels: Patch > Fix For: 1.28.0 > > Attachments: proposal.patch, test_tar_repo_recovery.patch > > > During repository startup if archive directory is not closed properly, > recovery will be performed. During that procedure, segents are copied to the > backup directory and deleted from the source direcory, one by one. > It can create problems and negativelly impact other ongoing actiivties, which > are accessing the same archive. This activity, for example, can be repository > cloning in order to create new environment. > Proposed patch, after creating backup is not deleting all segments from > archive, but only segments which could not be recovered. > [^proposal.patch] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8988) TarPersistence.lockRepostiory can indefinitely wait if another external process already running
[ https://issues.apache.org/jira/browse/OAK-8988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096327#comment-17096327 ] Amit Jain commented on OAK-8988: Yes, the key thing is that within the same JVM it works as documented above. But when there are 2 JVMs involved with one already holding the lock and the second trying to acquire the lock, the second instance waits indefinitely. There may be different behaviors on different platforms but that the obsereved behavior on linux. > TarPersistence.lockRepostiory can indefinitely wait if another external > process already running > --- > > Key: OAK-8988 > URL: https://issues.apache.org/jira/browse/OAK-8988 > Project: Jackrabbit Oak > Issue Type: Bug > Components: segment-tar >Reporter: Amit Jain >Priority: Major > > TarPersistence.lockRepostiory() [1] waits indefinitely when another segment > tar process is already running and has acquired the lock already. The method > should timeout if it fails to obtain a lock in a reasonable time (can be an > internal value) or have alternative means ascertaining that another process > already running e.g. by using mkdir(). > 1 - > [https://github.com/apache/jackrabbit-oak/blob/trunk/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/file/tar/TarPersistence.java#L92-L103|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/file/tar/TarPersistence.java#L92-L103] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OAK-8832) Offline Compaction fails while erroneously accessing external blob
[
https://issues.apache.org/jira/browse/OAK-8832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17093350#comment-17093350
]
Julian Reschke edited comment on OAK-8832 at 4/30/20, 8:25 AM:
---
trunk: [r1877064|http://svn.apache.org/r1877064]
[r1877063|http://svn.apache.org/r1877063]
1.22: [r1877189|http://svn.apache.org/r1877189]
[r1877129|http://svn.apache.org/r1877129]
1.8: [r1877086|http://svn.apache.org/r1877086]
[r1877083|http://svn.apache.org/r1877083]
was (Author: reschke):
trunk: [r1877064|http://svn.apache.org/r1877064]
[r1877063|http://svn.apache.org/r1877063]
1.22: [r1877129|http://svn.apache.org/viewvc?view=revision=1877129]
1.8: [r1877086|http://svn.apache.org/r1877086]
[r1877083|http://svn.apache.org/r1877083]
> Offline Compaction fails while erroneously accessing external blob
> ---
>
> Key: OAK-8832
> URL: https://issues.apache.org/jira/browse/OAK-8832
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: 1.8.11, 1.22.0
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Critical
> Fix For: 1.28.0, 1.8.22, 1.22.4
>
> Attachments: OAK-8832-02.patch, OAK-8832-test.patch, OAK-8832.patch
>
>
> Relevant stack trace:
> {noformat}
> INFO [2019-12-06 01:07:39,345]
> org.apache.jackrabbit.oak.segment.file.FileStore: TarMK GC #0: compacting
> root.
> java.lang.IllegalStateException: Attempt to read external blob with blobId
> [95c88847bd388c05fc332e737dda714630c11351d1949ffd1a03b7b09b92d1ea#71399]
> without specifying BlobStore
> INFO [2019-12-06 01:07:39,753]
> org.apache.jackrabbit.oak.segment.file.FileStore: TarMK closed:
> /mnt/sandbox/tmp/1575594001228-0
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getBlob(SegmentBlob.java:248)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getLength(SegmentBlob.java:257)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.length(SegmentBlob.java:109)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:185)
> at com.google.common.base.Objects.equal(Objects.java:52)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:59)
> at
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:664)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:558)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:422)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:651)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
>
