[jira] [Commented] (OAK-2647) QueryBuilder.setSelector(Authorizable.class) only returns Groups when using Java 1.8
[
https://issues.apache.org/jira/browse/OAK-2647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14371114#comment-14371114
]
angela commented on OAK-2647:
-
information provided by ben in private communication:
{quote}
Hi Angela Schreiber, we worked around the issue by allowing the query do the
sorting. However I'm confused why this occurred now with 1.8.
{quote}
I am going to resolve this as Cannot Reproduce. [~bhellema], feel free to
reopen with more information. There is for sure an java 1.8 issue but it might
be somewhere else... having your exact query would definitely have been helpful.
QueryBuilder.setSelector(Authorizable.class) only returns Groups when using
Java 1.8
Key: OAK-2647
URL: https://issues.apache.org/jira/browse/OAK-2647
Project: Jackrabbit Oak
Issue Type: Bug
Components: core, query
Affects Versions: 1.1.7
Environment: Java 1.8
Reporter: Ben Helleman
Assignee: angela
Using
org.apache.jackrabbit.api.security.user.QueryBuilder.setSelector(Authorizable.class)
the docs state that it should return both Groups and Users, however when
using Java 1.8, only Groups are returned.
Using Java 1.7, setSelector(Authorizable.class) works as expected.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-2647) QueryBuilder.setSelector(Authorizable.class) only returns Groups when using Java 1.8
[ https://issues.apache.org/jira/browse/OAK-2647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-2647. - Resolution: Cannot Reproduce QueryBuilder.setSelector(Authorizable.class) only returns Groups when using Java 1.8 Key: OAK-2647 URL: https://issues.apache.org/jira/browse/OAK-2647 Project: Jackrabbit Oak Issue Type: Bug Components: core, query Affects Versions: 1.1.7 Environment: Java 1.8 Reporter: Ben Helleman Assignee: angela Using org.apache.jackrabbit.api.security.user.QueryBuilder.setSelector(Authorizable.class) the docs state that it should return both Groups and Users, however when using Java 1.8, only Groups are returned. Using Java 1.7, setSelector(Authorizable.class) works as expected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2654) SegmentIdTable too eager to refresh
[ https://issues.apache.org/jira/browse/OAK-2654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Parvulescu updated OAK-2654: - Attachment: OAK-2654.patch proposed patch. This will reduce the number of refresh calls to only when a null value is actually seen. The hotspot here came from creating new segments, so a different approach might be to duplicate this method and add a version specifically for inserting new segment references which doesn't trigger a refresh at all. cc. [~mduerig] [~chetanm] SegmentIdTable too eager to refresh --- Key: OAK-2654 URL: https://issues.apache.org/jira/browse/OAK-2654 Project: Jackrabbit Oak Issue Type: Improvement Components: segmentmk Reporter: Alex Parvulescu Assignee: Alex Parvulescu Fix For: 1.1.8, 1.2 Attachments: OAK-2654.patch Calling SegmentIdTable#getSegmentId might trigger a reference table refresh if a certain condition is met, I think that this condition is too eager to trigger the refresh and in high write scenarios, this results in large pauses as the method is synchronized. The current condition resembles a cache miss (_index != first_) which means that when looking up a segment id by the _lsb_ it might happen that it either - is not there, so it needs to be added (no refresh on this branch) - or there is an overlap on lsb values (actually on the value returned by _getIndex(lsb)_), in which case a refresh will be triggered. In high write scenarios the refresh case happens a lot more frequently so a refresh is triggered, even if it might not be needed. a refresh makes sense when there are null references and it might make sense for them to be collected otherwise we're just creating clones of the same map over and over again. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2654) SegmentIdTable too eager to refresh
[ https://issues.apache.org/jira/browse/OAK-2654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Parvulescu updated OAK-2654: - Fix Version/s: 1.2 1.1.8 SegmentIdTable too eager to refresh --- Key: OAK-2654 URL: https://issues.apache.org/jira/browse/OAK-2654 Project: Jackrabbit Oak Issue Type: Improvement Components: segmentmk Reporter: Alex Parvulescu Assignee: Alex Parvulescu Fix For: 1.1.8, 1.2 Attachments: OAK-2654.patch Calling SegmentIdTable#getSegmentId might trigger a reference table refresh if a certain condition is met, I think that this condition is too eager to trigger the refresh and in high write scenarios, this results in large pauses as the method is synchronized. The current condition resembles a cache miss (_index != first_) which means that when looking up a segment id by the _lsb_ it might happen that it either - is not there, so it needs to be added (no refresh on this branch) - or there is an overlap on lsb values (actually on the value returned by _getIndex(lsb)_), in which case a refresh will be triggered. In high write scenarios the refresh case happens a lot more frequently so a refresh is triggered, even if it might not be needed. a refresh makes sense when there are null references and it might make sense for them to be collected otherwise we're just creating clones of the same map over and over again. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2654) SegmentIdTable too eager to refresh
[
https://issues.apache.org/jira/browse/OAK-2654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14371130#comment-14371130
]
Michael Dürig commented on OAK-2654:
Makes sense I think. Taking this further, is it even necessary to call refresh
on every {{null}} reference? So instead of the boolean {{shouldRefresh}} why
not a counter keeping track of the number of {{null}} references and only
refresh once a certain threshold is reached? With a threshold of {{1}} the
behaviour would be the same as in the patch.
SegmentIdTable too eager to refresh
---
Key: OAK-2654
URL: https://issues.apache.org/jira/browse/OAK-2654
Project: Jackrabbit Oak
Issue Type: Improvement
Components: segmentmk
Reporter: Alex Parvulescu
Assignee: Alex Parvulescu
Fix For: 1.1.8, 1.2
Attachments: OAK-2654.patch
Calling SegmentIdTable#getSegmentId might trigger a reference table refresh
if a certain condition is met, I think that this condition is too eager to
trigger the refresh and in high write scenarios, this results in large pauses
as the method is synchronized.
The current condition resembles a cache miss (_index != first_) which means
that when looking up a segment id by the _lsb_ it might happen that it either
- is not there, so it needs to be added (no refresh on this branch)
- or there is an overlap on lsb values (actually on the value returned by
_getIndex(lsb)_), in which case a refresh will be triggered.
In high write scenarios the refresh case happens a lot more frequently so a
refresh is triggered, even if it might not be needed. a refresh makes sense
when there are null references and it might make sense for them to be
collected otherwise we're just creating clones of the same map over and over
again.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2609) Thread.interrupt seems to stop repository
[ https://issues.apache.org/jira/browse/OAK-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14371139#comment-14371139 ] Michael Dürig commented on OAK-2609: +1 Thread.interrupt seems to stop repository - Key: OAK-2609 URL: https://issues.apache.org/jira/browse/OAK-2609 Project: Jackrabbit Oak Issue Type: Bug Affects Versions: 1.1.7 Environment: Java 7 Reporter: Carsten Ziegeler Priority: Critical Fix For: 1.3.0 We have a sporadic problem with Sling's JCR installer 3.3.8 and Oak (tar mk). It seems to timing related: the JCR installer does a Thread#interrupt at one point and sometimes this brings the hole instance to stop. Nothing else is going on any more. While of course, a workaround is to remove the Thread.interrupt call in the JCR installer (which we did, see SLING-4477), I have the fear that this can happen with any code that is using the repository and gets interrupted. This error is hard to reproduce, however with three people testing we could see this several times happening -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2502) Provide initial implementation of the Remote Operations specification
[ https://issues.apache.org/jira/browse/OAK-2502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14371169#comment-14371169 ] Francesco Mari commented on OAK-2502: - I'm taking care of OAK-2652. Provide initial implementation of the Remote Operations specification - Key: OAK-2502 URL: https://issues.apache.org/jira/browse/OAK-2502 Project: Jackrabbit Oak Issue Type: Sub-task Components: core Reporter: Francesco Mari Priority: Minor Labels: api, remoting Attachments: OAK-2502-01.patch To provide something that can be played with, and to verify the feasibility of the specification draft, an initial implementation of the HTTP API should be provided. The API should follow the general behavior described [here|https://wiki.apache.org/jackrabbit/frm/RemoteOperations] and the HTTP semantics defined [here|https://wiki.apache.org/jackrabbit/frm/HttpOperations]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-2641) FilterImpl violates nullability contract
[
https://issues.apache.org/jira/browse/OAK-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14371054#comment-14371054
]
angela edited comment on OAK-2641 at 3/20/15 9:49 AM:
--
proposed patch changing the annotation to @CheckForNull
was (Author: anchela):
proposed patch
FilterImpl violates nullability contract
-
Key: OAK-2641
URL: https://issues.apache.org/jira/browse/OAK-2641
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: Michael Dürig
Fix For: 1.2
Attachments: OAK-2641.patch
{{FilterImpl#getSupertypes}}, {{FilterImpl#getPrimaryTypes}} and
{{FilterImpl#getMixinTypes}} might all return {{null}} although {{Filter}}'s
contract mandates \@Nonull.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2641) FilterImpl violates nullability contract
[
https://issues.apache.org/jira/browse/OAK-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-2641:
Attachment: OAK-2641.patch
proposed patch
FilterImpl violates nullability contract
-
Key: OAK-2641
URL: https://issues.apache.org/jira/browse/OAK-2641
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: Michael Dürig
Fix For: 1.2
Attachments: OAK-2641.patch
{{FilterImpl#getSupertypes}}, {{FilterImpl#getPrimaryTypes}} and
{{FilterImpl#getMixinTypes}} might all return {{null}} although {{Filter}}'s
contract mandates \@Nonull.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2656) Test failures in LDAP authentication: Failed to bind an LDAP service
[
https://issues.apache.org/jira/browse/OAK-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14372298#comment-14372298
]
Michael Dürig commented on OAK-2656:
Can we leverage the {{reserve-network-port}} goal of the
{{build-helper-maven-plugin}} here? See
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-tarmk-standby/pom.xml#L76
Test failures in LDAP authentication: Failed to bind an LDAP service
Key: OAK-2656
URL: https://issues.apache.org/jira/browse/OAK-2656
Project: Jackrabbit Oak
Issue Type: Bug
Components: auth-ldap
Environment: Jenkins, Ubuntu:
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
Reporter: Michael Dürig
Labels: CI, Jenkins
Fix For: 1.2
The following tests all fail with the same error message Failed to bind an
LDAP service (1024) to the service registry..
{noformat}
testAuthenticateFail(org.apache.jackrabbit.oak.security.authentication.ldap.LdapProviderTest):
Failed to bind an LDAP service (1024) to the service registry.
testGetGroups2(org.apache.jackrabbit.oak.security.authentication.ldap.LdapProviderTest):
Failed to bind an LDAP service (1024) to the service registry.
org.apache.jackrabbit.oak.security.authentication.ldap.LdapDefaultLoginModuleTest:
Failed to bind an LDAP service (1024) to the service registry.
testGetUserByUserId(org.apache.jackrabbit.oak.security.authentication.ldap.LdapProviderTest):
Failed to bind an LDAP service (1024) to the service registry.
{noformat}
The stacktrace is always similar:
{noformat}
java.net.BindException: Address already in use]
at
org.apache.directory.server.ldap.LdapServer.startNetwork(LdapServer.java:528)
at
org.apache.directory.server.ldap.LdapServer.start(LdapServer.java:394)
at
org.apache.directory.server.unit.AbstractServerTest.setUp(AbstractServerTest.java:273)
at
org.apache.jackrabbit.oak.security.authentication.ldap.InternalLdapServer.setUp(InternalLdapServer.java:37)
at
org.apache.jackrabbit.oak.security.authentication.ldap.LdapLoginTestBase.beforeClass(LdapLoginTestBase.java:86)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: java.net.BindException: Address already in use
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:444)
at sun.nio.ch.Net.bind(Net.java:436)
at
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:214)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at
org.apache.mina.transport.socket.nio.NioSocketAcceptor.open(NioSocketAcceptor.java:198)
at
org.apache.mina.transport.socket.nio.NioSocketAcceptor.open(NioSocketAcceptor.java:51)
at
org.apache.mina.core.polling.AbstractPollingIoAcceptor.registerHandles(AbstractPollingIoAcceptor.java:547)
at
[jira] [Comment Edited] (OAK-2656) Test failures in LDAP authentication: Failed to bind an LDAP service
[
https://issues.apache.org/jira/browse/OAK-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14372298#comment-14372298
]
Michael Dürig edited comment on OAK-2656 at 3/20/15 11:15 PM:
--
Can we leverage the {{reserve-network-port}} goal of the
{{build-helper-maven-plugin}} here? See
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-tarmk-standby/pom.xml#L76
cc [~anchela], [~tripod]
was (Author: mduerig):
Can we leverage the {{reserve-network-port}} goal of the
{{build-helper-maven-plugin}} here? See
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-tarmk-standby/pom.xml#L76
Test failures in LDAP authentication: Failed to bind an LDAP service
Key: OAK-2656
URL: https://issues.apache.org/jira/browse/OAK-2656
Project: Jackrabbit Oak
Issue Type: Bug
Components: auth-ldap
Environment: Jenkins, Ubuntu:
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
Reporter: Michael Dürig
Labels: CI, Jenkins
Fix For: 1.2
The following tests all fail with the same error message Failed to bind an
LDAP service (1024) to the service registry..
{noformat}
testAuthenticateFail(org.apache.jackrabbit.oak.security.authentication.ldap.LdapProviderTest):
Failed to bind an LDAP service (1024) to the service registry.
testGetGroups2(org.apache.jackrabbit.oak.security.authentication.ldap.LdapProviderTest):
Failed to bind an LDAP service (1024) to the service registry.
org.apache.jackrabbit.oak.security.authentication.ldap.LdapDefaultLoginModuleTest:
Failed to bind an LDAP service (1024) to the service registry.
testGetUserByUserId(org.apache.jackrabbit.oak.security.authentication.ldap.LdapProviderTest):
Failed to bind an LDAP service (1024) to the service registry.
{noformat}
The stacktrace is always similar:
{noformat}
java.net.BindException: Address already in use]
at
org.apache.directory.server.ldap.LdapServer.startNetwork(LdapServer.java:528)
at
org.apache.directory.server.ldap.LdapServer.start(LdapServer.java:394)
at
org.apache.directory.server.unit.AbstractServerTest.setUp(AbstractServerTest.java:273)
at
org.apache.jackrabbit.oak.security.authentication.ldap.InternalLdapServer.setUp(InternalLdapServer.java:37)
at
org.apache.jackrabbit.oak.security.authentication.ldap.LdapLoginTestBase.beforeClass(LdapLoginTestBase.java:86)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: java.net.BindException: Address already in use
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:444)
at sun.nio.ch.Net.bind(Net.java:436)
at
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:214)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at
[jira] [Comment Edited] (OAK-2657) Repository Upgrade could shut down the source repository early
[ https://issues.apache.org/jira/browse/OAK-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14371324#comment-14371324 ] Alex Parvulescu edited comment on OAK-2657 at 3/20/15 2:13 PM: --- attaching proposed patch against branch 1.0. a bit rough on the edges but works. @[~chetanm] was (Author: alex.parvulescu): attaching proposed patch. a bit rough on the edges but works. @[~chetanm] Repository Upgrade could shut down the source repository early -- Key: OAK-2657 URL: https://issues.apache.org/jira/browse/OAK-2657 Project: Jackrabbit Oak Issue Type: Improvement Components: upgrade Reporter: Alex Parvulescu Attachments: OAK-2657.patch I noticed that during the upgrade we can distinguish 2 phases: first copying the data from the source, then applying all the Editors (indexes and co.). After phase 1 is done the repository upgrader could shut down the old repo to allow clearing some memory resources which might be used for the second phase. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-2476) Move our CI to Jenkins
[
https://issues.apache.org/jira/browse/OAK-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14371236#comment-14371236
]
Michael Dürig edited comment on OAK-2476 at 3/20/15 12:38 PM:
--
Still no new platform problems with [build
30|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/30/].
* All windows builds errored. Presumable due to no disk space left. I've taken
the Windows builds off line for now (via the combination filter) so it doesn't
impact the test of the builds. Let's follow up separately re. Windows.
* One test failure:
{{org.apache.jackrabbit.oak.jcr.OrderableNodesTest.testAddNode}}. --I'll file
an issue.-- See OAK-2655
* Still the problem with the {{geronimo-jta_1.0.1B_spec}} dependency. I'll
create an BUILDS issue.
was (Author: mduerig):
Still no new platform problems with [build
30|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/30/].
* All windows builds errored. Presumable due to no disk space left. I've taken
the Windows builds off line for now (via the combination filter) so it doesn't
impact the test of the builds. Let's follow up separately re. Windows.
* One test failure:
{{org.apache.jackrabbit.oak.jcr.OrderableNodesTest.testAddNode}}. I'll file an
issue.
* Still the problem with the {{geronimo-jta_1.0.1B_spec}} dependency. I'll
create an BUILDS issue.
Move our CI to Jenkins
--
Key: OAK-2476
URL: https://issues.apache.org/jira/browse/OAK-2476
Project: Jackrabbit Oak
Issue Type: Task
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
Priority: Critical
Labels: CI, build, infrastructure
Fix For: 1.2
We should strive for stabilization of our CI setup, as of now we had Buildbot
and Travis.
It seems ASF Jenkins can perform jobs on different environments (*nix,
Windows and others) so we can evaluate that and check if it better address
our needs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2657) Repository Upgrade could shut down the source repository early
[ https://issues.apache.org/jira/browse/OAK-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14371327#comment-14371327 ] Chetan Mehrotra commented on OAK-2657: -- Good idea. However one thing we need to watch out for is that currently we reuse the DataStore instance within the Oak instance. So if you close the repository it would also close the DataStore. However currently the migration logic does not make calls to datastore post migration but something we need to watch for Repository Upgrade could shut down the source repository early -- Key: OAK-2657 URL: https://issues.apache.org/jira/browse/OAK-2657 Project: Jackrabbit Oak Issue Type: Improvement Components: upgrade Reporter: Alex Parvulescu Attachments: OAK-2657.patch I noticed that during the upgrade we can distinguish 2 phases: first copying the data from the source, then applying all the Editors (indexes and co.). After phase 1 is done the repository upgrader could shut down the old repo to allow clearing some memory resources which might be used for the second phase. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-2659) Failed expectations in TarMK standby tests
Michael Dürig created OAK-2659:
--
Summary: Failed expectations in TarMK standby tests
Key: OAK-2659
URL: https://issues.apache.org/jira/browse/OAK-2659
Project: Jackrabbit Oak
Issue Type: Bug
Components: oak-tarmk-standby
Environment: Jenkins, Ubuntu:
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
Reporter: Michael Dürig
Fix For: 1.2
I see many similar test failures for {{FailoverMultipleClientsTestIT}} and
{{RecoverTestIT}} on Jenkins. For example:
{noformat}
testSyncLoop(org.apache.jackrabbit.oak.plugins.segment.standby.StandbyTestIT):
expected:{ checkpoints = { ... }, root = { ... } } but was:{ root : { } }
testLocalChanges(org.apache.jackrabbit.oak.plugins.segment.standby.RecoverTestIT):
expected: org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState{ root =
{ ... } } but was:
org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState{ root = { ... } }
{noformat}
See
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/31/jdk=jdk1.8.0_11,label=Ubuntu,nsfixtures=DOCUMENT_NS,profile=integrationTesting/console
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/31/jdk=latest1.7,label=Ubuntu,nsfixtures=SEGMENT_MK,profile=integrationTesting/console
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/31/jdk=latest1.7,label=Ubuntu,nsfixtures=DOCUMENT_NS,profile=integrationTesting/console
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2560) SegmentStore deadlock on shutdown
[
https://issues.apache.org/jira/browse/OAK-2560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14371349#comment-14371349
]
Chetan Mehrotra commented on OAK-2560:
--
bq. the Registration object doesn't properly relay the #unregister call into
the service so it knows it needs to stop processing early.
Yup thats the case
bq. Also could we improve this with a call to #close when the given
registration is an instanceof Closeable?
Yes that would fix the situation here.
bq. to also pass in the information that whatever we register is somehow linked
to the NodeStore and has a connected life cycle.
Thats was SCR component does for you. It allows SCR to track NodeStore as a
dependency for you and if NodeStore goes away it would deactivate
I think we should move out this logic as a separate dedicated SCR component. It
would allow us to later make use of OSGi config to configure some aspects of
AsyncIndexer like current 15 min timeout which is only configurable via system
property and is bit annoying if you kill the repo in mid way while indexer is
running.
SegmentStore deadlock on shutdown
-
Key: OAK-2560
URL: https://issues.apache.org/jira/browse/OAK-2560
Project: Jackrabbit Oak
Issue Type: Bug
Components: segmentmk
Reporter: Alex Parvulescu
Assignee: Alex Parvulescu
Fix For: 1.1.8
We've ran into a deadlock in the Oak SegmentNodeStore between
_org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.deactivate(SegmentNodeStoreService.java:300)_
and _
org.apache.jackrabbit.oak.plugins.segment.SegmentTracker.getSegment(SegmentTracker.java:120)_
This was seen on Oak 1.0.11.
{code}
Java stack information for the threads listed above
pool-9-thread-5:
at
org.apache.jackrabbit.oak.plugins.segment.file.FileStore.readSegment(FileStore.java:656)
- waiting to lock 0x000680024468 (a
org.apache.jackrabbit.oak.plugins.segment.file.FileStore)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentTracker.getSegment(SegmentTracker.java:120)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentId.getSegment(SegmentId.java:101)
- locked 0x0006b0b7ae28 (a
org.apache.jackrabbit.oak.plugins.segment.SegmentId)
at
org.apache.jackrabbit.oak.plugins.segment.Record.getSegment(Record.java:82)
at
org.apache.jackrabbit.oak.plugins.segment.MapRecord.size(MapRecord.java:128)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentWriter.writeMapBucket(SegmentWriter.java:462)
- locked 0x000680c634a8 (a
org.apache.jackrabbit.oak.plugins.segment.SegmentWriter)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentWriter.writeMapBucket(SegmentWriter.java:460)
- locked 0x000680c634a8 (a
org.apache.jackrabbit.oak.plugins.segment.SegmentWriter)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentWriter.writeMap(SegmentWriter.java:660)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentWriter.writeNode(SegmentWriter.java:1020)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentWriter.writeNode(SegmentWriter.java:1022)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentWriter$2.childNodeChanged(SegmentWriter.java:1003)
at
org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAgainstBaseState(ModifiedNodeState.java:396)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentWriter.writeNode(SegmentWriter.java:994)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentWriter$2.childNodeChanged(SegmentWriter.java:1003)
at
org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAgainstBaseState(ModifiedNodeState.java:396)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentWriter.writeNode(SegmentWriter.java:994)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentNodeBuilder.getNodeState(SegmentNodeBuilder.java:91)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentNodeBuilder.updated(SegmentNodeBuilder.java:77)
at
org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.updated(MemoryNodeBuilder.java:204)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentNodeBuilder.updated(SegmentNodeBuilder.java:73)
at
org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.setChildNode(MemoryNodeBuilder.java:331)
at
org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.setChildNode(MemoryNodeBuilder.java:323)
at
org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.child(MemoryNodeBuilder.java:311)
at
org.apache.jackrabbit.oak.plugins.index.property.strategy.ContentMirrorStoreStrategy.insert(ContentMirrorStoreStrategy.java:112)
at
[jira] [Created] (OAK-2656) Test failures in LDAP authentication: Failed to bind an LDAP service
Michael Dürig created OAK-2656:
--
Summary: Test failures in LDAP authentication: Failed to bind an
LDAP service
Key: OAK-2656
URL: https://issues.apache.org/jira/browse/OAK-2656
Project: Jackrabbit Oak
Issue Type: Bug
Components: auth-ldap
Environment: Jenkins, Ubuntu:
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
Reporter: Michael Dürig
Fix For: 1.2
The following tests all fail with the same error message Failed to bind an
LDAP service (1024) to the service registry..
{noformat}
testAuthenticateFail(org.apache.jackrabbit.oak.security.authentication.ldap.LdapProviderTest):
Failed to bind an LDAP service (1024) to the service registry.
testGetGroups2(org.apache.jackrabbit.oak.security.authentication.ldap.LdapProviderTest):
Failed to bind an LDAP service (1024) to the service registry.
org.apache.jackrabbit.oak.security.authentication.ldap.LdapDefaultLoginModuleTest:
Failed to bind an LDAP service (1024) to the service registry.
testGetUserByUserId(org.apache.jackrabbit.oak.security.authentication.ldap.LdapProviderTest):
Failed to bind an LDAP service (1024) to the service registry.
{noformat}
The stacktrace is always similar:
{noformat}
java.net.BindException: Address already in use]
at
org.apache.directory.server.ldap.LdapServer.startNetwork(LdapServer.java:528)
at
org.apache.directory.server.ldap.LdapServer.start(LdapServer.java:394)
at
org.apache.directory.server.unit.AbstractServerTest.setUp(AbstractServerTest.java:273)
at
org.apache.jackrabbit.oak.security.authentication.ldap.InternalLdapServer.setUp(InternalLdapServer.java:37)
at
org.apache.jackrabbit.oak.security.authentication.ldap.LdapLoginTestBase.beforeClass(LdapLoginTestBase.java:86)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: java.net.BindException: Address already in use
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:444)
at sun.nio.ch.Net.bind(Net.java:436)
at
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:214)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at
org.apache.mina.transport.socket.nio.NioSocketAcceptor.open(NioSocketAcceptor.java:198)
at
org.apache.mina.transport.socket.nio.NioSocketAcceptor.open(NioSocketAcceptor.java:51)
at
org.apache.mina.core.polling.AbstractPollingIoAcceptor.registerHandles(AbstractPollingIoAcceptor.java:547)
at
org.apache.mina.core.polling.AbstractPollingIoAcceptor.access$400(AbstractPollingIoAcceptor.java:68)
at
org.apache.mina.core.polling.AbstractPollingIoAcceptor$Acceptor.run(AbstractPollingIoAcceptor.java:422)
at
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
[jira] [Commented] (OAK-2655) Test failure: OrderableNodesTest.testAddNode
[
https://issues.apache.org/jira/browse/OAK-2655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14371295#comment-14371295
]
Julian Reschke commented on OAK-2655:
-
(it fails unreliably; seems to be an interaction with a background thread)
Test failure: OrderableNodesTest.testAddNode
Key: OAK-2655
URL: https://issues.apache.org/jira/browse/OAK-2655
Project: Jackrabbit Oak
Issue Type: Bug
Components: rdbmk
Environment: Ubuntu
Reporter: Michael Dürig
Assignee: Julian Reschke
Fix For: 1.2
{{org.apache.jackrabbit.oak.jcr.OrderableNodesTest.testAddNode}} fails on
Jenkins when running the {{DOCUMENT_RDB}} fixture.
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/30/jdk=jdk-1.6u45,label=Ubuntu,nsfixtures=DOCUMENT_RDB,profile=unittesting/testReport/junit/org.apache.jackrabbit.oak.jcr/OrderableNodesTest/testAddNode_0_/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2657) Repository Upgrade could shut down the source repository early
[ https://issues.apache.org/jira/browse/OAK-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Parvulescu updated OAK-2657: - Attachment: OAK-2657.patch attaching proposed patch. a bit rough on the edges but works. @[~chetanm] Repository Upgrade could shut down the source repository early -- Key: OAK-2657 URL: https://issues.apache.org/jira/browse/OAK-2657 Project: Jackrabbit Oak Issue Type: Improvement Components: upgrade Reporter: Alex Parvulescu Attachments: OAK-2657.patch I noticed that during the upgrade we can distinguish 2 phases: first copying the data from the source, then applying all the Editors (indexes and co.). After phase 1 is done the repository upgrader could shut down the old repo to allow clearing some memory resources which might be used for the second phase. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2659) Failed expectations in TarMK standby tests
[
https://issues.apache.org/jira/browse/OAK-2659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14371343#comment-14371343
]
Alex Parvulescu commented on OAK-2659:
--
all caused by OAK-2658 :)
Failed expectations in TarMK standby tests
--
Key: OAK-2659
URL: https://issues.apache.org/jira/browse/OAK-2659
Project: Jackrabbit Oak
Issue Type: Bug
Components: oak-tarmk-standby
Environment: Jenkins, Ubuntu:
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
Reporter: Michael Dürig
Labels: CI, Jenkins
Fix For: 1.2
I see many similar test failures for {{FailoverMultipleClientsTestIT}} and
{{RecoverTestIT}} on Jenkins. For example:
{noformat}
testSyncLoop(org.apache.jackrabbit.oak.plugins.segment.standby.StandbyTestIT):
expected:{ checkpoints = { ... }, root = { ... } } but was:{ root : { } }
testLocalChanges(org.apache.jackrabbit.oak.plugins.segment.standby.RecoverTestIT):
expected: org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState{ root
= { ... } } but was:
org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState{ root = { ... } }
{noformat}
See
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/31/jdk=jdk1.8.0_11,label=Ubuntu,nsfixtures=DOCUMENT_NS,profile=integrationTesting/console
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/31/jdk=latest1.7,label=Ubuntu,nsfixtures=SEGMENT_MK,profile=integrationTesting/console
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/31/jdk=latest1.7,label=Ubuntu,nsfixtures=DOCUMENT_NS,profile=integrationTesting/console
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-2655) Test failure: OrderableNodesTest.testAddNode
[
https://issues.apache.org/jira/browse/OAK-2655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke reassigned OAK-2655:
---
Assignee: Julian Reschke
Test failure: OrderableNodesTest.testAddNode
Key: OAK-2655
URL: https://issues.apache.org/jira/browse/OAK-2655
Project: Jackrabbit Oak
Issue Type: Bug
Components: rdbmk
Environment: Ubuntu
Reporter: Michael Dürig
Assignee: Julian Reschke
Fix For: 1.2
{{org.apache.jackrabbit.oak.jcr.OrderableNodesTest.testAddNode}} fails on
Jenkins when running the {{DOCUMENT_RDB}} fixture.
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/30/jdk=jdk-1.6u45,label=Ubuntu,nsfixtures=DOCUMENT_RDB,profile=unittesting/testReport/junit/org.apache.jackrabbit.oak.jcr/OrderableNodesTest/testAddNode_0_/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2655) Test failure: OrderableNodesTest.testAddNode
[
https://issues.apache.org/jira/browse/OAK-2655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-2655:
---
Labels: CI Jenkins (was: )
Test failure: OrderableNodesTest.testAddNode
Key: OAK-2655
URL: https://issues.apache.org/jira/browse/OAK-2655
Project: Jackrabbit Oak
Issue Type: Bug
Components: rdbmk
Environment: Jenkins, Ubuntu:
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
Reporter: Michael Dürig
Assignee: Julian Reschke
Labels: CI, Jenkins
Fix For: 1.2
{{org.apache.jackrabbit.oak.jcr.OrderableNodesTest.testAddNode}} fails on
Jenkins when running the {{DOCUMENT_RDB}} fixture.
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/30/jdk=jdk-1.6u45,label=Ubuntu,nsfixtures=DOCUMENT_RDB,profile=unittesting/testReport/junit/org.apache.jackrabbit.oak.jcr/OrderableNodesTest/testAddNode_0_/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2657) Repository Upgrade could shut down the source repository early
[ https://issues.apache.org/jira/browse/OAK-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14371341#comment-14371341 ] Alex Parvulescu commented on OAK-2657: -- good point. I still think this frees an important amount of memory for the indexers so it is interesting to add it in. maybe put it behind some sort of a flag (earlyShutdown) so people can use it out without losing the existing behavior? Repository Upgrade could shut down the source repository early -- Key: OAK-2657 URL: https://issues.apache.org/jira/browse/OAK-2657 Project: Jackrabbit Oak Issue Type: Improvement Components: upgrade Reporter: Alex Parvulescu Attachments: OAK-2657.patch I noticed that during the upgrade we can distinguish 2 phases: first copying the data from the source, then applying all the Editors (indexes and co.). After phase 1 is done the repository upgrader could shut down the old repo to allow clearing some memory resources which might be used for the second phase. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-2657) Repository Upgrade could shut down the source repository early
Alex Parvulescu created OAK-2657: Summary: Repository Upgrade could shut down the source repository early Key: OAK-2657 URL: https://issues.apache.org/jira/browse/OAK-2657 Project: Jackrabbit Oak Issue Type: Improvement Components: upgrade Reporter: Alex Parvulescu I noticed that during the upgrade we can distinguish 2 phases: first copying the data from the source, then applying all the Editors (indexes and co.). After phase 1 is done the repository upgrader could shut down the old repo to allow clearing some memory resources which might be used for the second phase. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-2658) Test failures in TarMK standby: proxy not started
Michael Dürig created OAK-2658:
--
Summary: Test failures in TarMK standby: proxy not started
Key: OAK-2658
URL: https://issues.apache.org/jira/browse/OAK-2658
Project: Jackrabbit Oak
Issue Type: Bug
Components: oak-tarmk-standby
Environment: Jenkins, Ubuntu:
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
Reporter: Michael Dürig
Fix For: 1.2
The following tests fail probably all for the same reason:
{noformat}
testProxySkippedBytes(org.apache.jackrabbit.oak.plugins.segment.standby.ExternalSharedStoreIT):
proxy not started
testProxySkippedBytesIntermediateChange(org.apache.jackrabbit.oak.plugins.segment.standby.ExternalSharedStoreIT):
proxy not started
testProxyFlippedStartByte(org.apache.jackrabbit.oak.plugins.segment.standby.ExternalSharedStoreIT):
proxy not started
testProxyFlippedIntermediateByte(org.apache.jackrabbit.oak.plugins.segment.standby.ExternalSharedStoreIT):
proxy not started
testProxyFlippedIntermediateByte2(org.apache.jackrabbit.oak.plugins.segment.standby.ExternalSharedStoreIT):
proxy not started
testProxyFlippedIntermediateByteChange(org.apache.jackrabbit.oak.plugins.segment.standby.ExternalSharedStoreIT):
proxy not started
testProxyFlippedIntermediateByteChange2(org.apache.jackrabbit.oak.plugins.segment.standby.ExternalSharedStoreIT):
proxy not started
{noformat}
Stacktraces always look something like:
{noformat}
java.lang.Exception: proxy not started
at
org.apache.jackrabbit.oak.plugins.segment.NetworkErrorProxy.reset(NetworkErrorProxy.java:87)
at
org.apache.jackrabbit.oak.plugins.segment.standby.DataStoreTestBase.useProxy(DataStoreTestBase.java:176)
at
org.apache.jackrabbit.oak.plugins.segment.standby.DataStoreTestBase.testProxySkippedBytes(DataStoreTestBase.java:118)
{noformat}
See
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/31/jdk=latest1.7,label=Ubuntu,nsfixtures=DOCUMENT_NS,profile=integrationTesting/console
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2658) Test failures in TarMK standby: Address already in use
[
https://issues.apache.org/jira/browse/OAK-2658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated OAK-2658:
-
Summary: Test failures in TarMK standby: Address already in use (was: Test
failures in TarMK standby: proxy not started)
Test failures in TarMK standby: Address already in use
--
Key: OAK-2658
URL: https://issues.apache.org/jira/browse/OAK-2658
Project: Jackrabbit Oak
Issue Type: Bug
Components: oak-tarmk-standby
Environment: Jenkins, Ubuntu:
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
Reporter: Michael Dürig
Labels: CI, jenkins
Fix For: 1.2
The following tests fail probably all for the same reason:
{noformat}
testProxySkippedBytes(org.apache.jackrabbit.oak.plugins.segment.standby.ExternalSharedStoreIT):
proxy not started
testProxySkippedBytesIntermediateChange(org.apache.jackrabbit.oak.plugins.segment.standby.ExternalSharedStoreIT):
proxy not started
testProxyFlippedStartByte(org.apache.jackrabbit.oak.plugins.segment.standby.ExternalSharedStoreIT):
proxy not started
testProxyFlippedIntermediateByte(org.apache.jackrabbit.oak.plugins.segment.standby.ExternalSharedStoreIT):
proxy not started
testProxyFlippedIntermediateByte2(org.apache.jackrabbit.oak.plugins.segment.standby.ExternalSharedStoreIT):
proxy not started
testProxyFlippedIntermediateByteChange(org.apache.jackrabbit.oak.plugins.segment.standby.ExternalSharedStoreIT):
proxy not started
testProxyFlippedIntermediateByteChange2(org.apache.jackrabbit.oak.plugins.segment.standby.ExternalSharedStoreIT):
proxy not started
{noformat}
Stacktraces always look something like:
{noformat}
java.lang.Exception: proxy not started
at
org.apache.jackrabbit.oak.plugins.segment.NetworkErrorProxy.reset(NetworkErrorProxy.java:87)
at
org.apache.jackrabbit.oak.plugins.segment.standby.DataStoreTestBase.useProxy(DataStoreTestBase.java:176)
at
org.apache.jackrabbit.oak.plugins.segment.standby.DataStoreTestBase.testProxySkippedBytes(DataStoreTestBase.java:118)
{noformat}
See
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/31/jdk=latest1.7,label=Ubuntu,nsfixtures=DOCUMENT_NS,profile=integrationTesting/console
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2654) SegmentIdTable too eager to refresh
[ https://issues.apache.org/jira/browse/OAK-2654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14371483#comment-14371483 ] Alex Parvulescu commented on OAK-2654: -- I think adding a counter might be overkill, do we really need to tweak the refresh threshold? I'm not sure what's the best value here (5, 20?, 100?), but I'm not against the idea. SegmentIdTable too eager to refresh --- Key: OAK-2654 URL: https://issues.apache.org/jira/browse/OAK-2654 Project: Jackrabbit Oak Issue Type: Improvement Components: segmentmk Reporter: Alex Parvulescu Assignee: Alex Parvulescu Fix For: 1.1.8, 1.2 Attachments: OAK-2654.patch Calling SegmentIdTable#getSegmentId might trigger a reference table refresh if a certain condition is met, I think that this condition is too eager to trigger the refresh and in high write scenarios, this results in large pauses as the method is synchronized. The current condition resembles a cache miss (_index != first_) which means that when looking up a segment id by the _lsb_ it might happen that it either - is not there, so it needs to be added (no refresh on this branch) - or there is an overlap on lsb values (actually on the value returned by _getIndex(lsb)_), in which case a refresh will be triggered. In high write scenarios the refresh case happens a lot more frequently so a refresh is triggered, even if it might not be needed. a refresh makes sense when there are null references and it might make sense for them to be collected otherwise we're just creating clones of the same map over and over again. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2476) Move our CI to Jenkins
[
https://issues.apache.org/jira/browse/OAK-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14371469#comment-14371469
]
Michael Dürig commented on OAK-2476:
Ah couple of builds fail with {{java.net.BindException: Address already in
use}} (OAK-2656, OAK-2658). Might this be caused by the tests running parallel
on the same machine? Anything we could do here besides running the builds one
after each other?
Move our CI to Jenkins
--
Key: OAK-2476
URL: https://issues.apache.org/jira/browse/OAK-2476
Project: Jackrabbit Oak
Issue Type: Task
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
Priority: Critical
Labels: CI, build, infrastructure
Fix For: 1.2
We should strive for stabilization of our CI setup, as of now we had Buildbot
and Travis.
It seems ASF Jenkins can perform jobs on different environments (*nix,
Windows and others) so we can evaluate that and check if it better address
our needs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2560) SegmentStore deadlock on shutdown
[
https://issues.apache.org/jira/browse/OAK-2560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14371408#comment-14371408
]
Alex Parvulescu commented on OAK-2560:
--
bq. I think we should move out this logic as a separate dedicated SCR component.
this is my main concern here. how would a non-OSGi setup look like then?
SegmentStore deadlock on shutdown
-
Key: OAK-2560
URL: https://issues.apache.org/jira/browse/OAK-2560
Project: Jackrabbit Oak
Issue Type: Bug
Components: segmentmk
Reporter: Alex Parvulescu
Assignee: Alex Parvulescu
Fix For: 1.1.8
We've ran into a deadlock in the Oak SegmentNodeStore between
_org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.deactivate(SegmentNodeStoreService.java:300)_
and _
org.apache.jackrabbit.oak.plugins.segment.SegmentTracker.getSegment(SegmentTracker.java:120)_
This was seen on Oak 1.0.11.
{code}
Java stack information for the threads listed above
pool-9-thread-5:
at
org.apache.jackrabbit.oak.plugins.segment.file.FileStore.readSegment(FileStore.java:656)
- waiting to lock 0x000680024468 (a
org.apache.jackrabbit.oak.plugins.segment.file.FileStore)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentTracker.getSegment(SegmentTracker.java:120)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentId.getSegment(SegmentId.java:101)
- locked 0x0006b0b7ae28 (a
org.apache.jackrabbit.oak.plugins.segment.SegmentId)
at
org.apache.jackrabbit.oak.plugins.segment.Record.getSegment(Record.java:82)
at
org.apache.jackrabbit.oak.plugins.segment.MapRecord.size(MapRecord.java:128)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentWriter.writeMapBucket(SegmentWriter.java:462)
- locked 0x000680c634a8 (a
org.apache.jackrabbit.oak.plugins.segment.SegmentWriter)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentWriter.writeMapBucket(SegmentWriter.java:460)
- locked 0x000680c634a8 (a
org.apache.jackrabbit.oak.plugins.segment.SegmentWriter)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentWriter.writeMap(SegmentWriter.java:660)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentWriter.writeNode(SegmentWriter.java:1020)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentWriter.writeNode(SegmentWriter.java:1022)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentWriter$2.childNodeChanged(SegmentWriter.java:1003)
at
org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAgainstBaseState(ModifiedNodeState.java:396)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentWriter.writeNode(SegmentWriter.java:994)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentWriter$2.childNodeChanged(SegmentWriter.java:1003)
at
org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAgainstBaseState(ModifiedNodeState.java:396)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentWriter.writeNode(SegmentWriter.java:994)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentNodeBuilder.getNodeState(SegmentNodeBuilder.java:91)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentNodeBuilder.updated(SegmentNodeBuilder.java:77)
at
org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.updated(MemoryNodeBuilder.java:204)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentNodeBuilder.updated(SegmentNodeBuilder.java:73)
at
org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.setChildNode(MemoryNodeBuilder.java:331)
at
org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.setChildNode(MemoryNodeBuilder.java:323)
at
org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.child(MemoryNodeBuilder.java:311)
at
org.apache.jackrabbit.oak.plugins.index.property.strategy.ContentMirrorStoreStrategy.insert(ContentMirrorStoreStrategy.java:112)
at
org.apache.jackrabbit.oak.plugins.index.property.strategy.ContentMirrorStoreStrategy.update(ContentMirrorStoreStrategy.java:81)
at
org.apache.jackrabbit.oak.plugins.index.property.PropertyIndexEditor.leave(PropertyIndexEditor.java:261)
at
org.apache.jackrabbit.oak.spi.commit.CompositeEditor.leave(CompositeEditor.java:74)
at
org.apache.jackrabbit.oak.spi.commit.VisibleEditor.leave(VisibleEditor.java:63)
at
org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeAdded(EditorDiff.java:130)
at
org.apache.jackrabbit.oak.plugins.memory.EmptyNodeState.compareAgainstEmptyState(EmptyNodeState.java:160)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:391)
at
[jira] [Commented] (OAK-2656) Test failures in LDAP authentication: Failed to bind an LDAP service
[
https://issues.apache.org/jira/browse/OAK-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14371467#comment-14371467
]
Michael Dürig commented on OAK-2656:
With the builds executing in parallel they might content for the port here.
Will follow up on OAK-2476 as this is likely a test setup issue.
Test failures in LDAP authentication: Failed to bind an LDAP service
Key: OAK-2656
URL: https://issues.apache.org/jira/browse/OAK-2656
Project: Jackrabbit Oak
Issue Type: Bug
Components: auth-ldap
Environment: Jenkins, Ubuntu:
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
Reporter: Michael Dürig
Labels: CI, Jenkins
Fix For: 1.2
The following tests all fail with the same error message Failed to bind an
LDAP service (1024) to the service registry..
{noformat}
testAuthenticateFail(org.apache.jackrabbit.oak.security.authentication.ldap.LdapProviderTest):
Failed to bind an LDAP service (1024) to the service registry.
testGetGroups2(org.apache.jackrabbit.oak.security.authentication.ldap.LdapProviderTest):
Failed to bind an LDAP service (1024) to the service registry.
org.apache.jackrabbit.oak.security.authentication.ldap.LdapDefaultLoginModuleTest:
Failed to bind an LDAP service (1024) to the service registry.
testGetUserByUserId(org.apache.jackrabbit.oak.security.authentication.ldap.LdapProviderTest):
Failed to bind an LDAP service (1024) to the service registry.
{noformat}
The stacktrace is always similar:
{noformat}
java.net.BindException: Address already in use]
at
org.apache.directory.server.ldap.LdapServer.startNetwork(LdapServer.java:528)
at
org.apache.directory.server.ldap.LdapServer.start(LdapServer.java:394)
at
org.apache.directory.server.unit.AbstractServerTest.setUp(AbstractServerTest.java:273)
at
org.apache.jackrabbit.oak.security.authentication.ldap.InternalLdapServer.setUp(InternalLdapServer.java:37)
at
org.apache.jackrabbit.oak.security.authentication.ldap.LdapLoginTestBase.beforeClass(LdapLoginTestBase.java:86)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: java.net.BindException: Address already in use
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:444)
at sun.nio.ch.Net.bind(Net.java:436)
at
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:214)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at
org.apache.mina.transport.socket.nio.NioSocketAcceptor.open(NioSocketAcceptor.java:198)
at
org.apache.mina.transport.socket.nio.NioSocketAcceptor.open(NioSocketAcceptor.java:51)
at
org.apache.mina.core.polling.AbstractPollingIoAcceptor.registerHandles(AbstractPollingIoAcceptor.java:547)
at
[jira] [Commented] (OAK-2658) Test failures in TarMK standby: Address already in use
[
https://issues.apache.org/jira/browse/OAK-2658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14371464#comment-14371464
]
Michael Dürig commented on OAK-2658:
Hmm interesting. So this might have the same cause as OAK-2656. With the builds
executing in parallel they might content for the port here. Will follow up on
OAK-2476 as this is likely a test setup issue then.
Test failures in TarMK standby: Address already in use
--
Key: OAK-2658
URL: https://issues.apache.org/jira/browse/OAK-2658
Project: Jackrabbit Oak
Issue Type: Bug
Components: oak-tarmk-standby
Environment: Jenkins, Ubuntu:
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
Reporter: Michael Dürig
Labels: CI, jenkins
Fix For: 1.2
The following tests fail probably all for the same reason:
{noformat}
testProxySkippedBytes(org.apache.jackrabbit.oak.plugins.segment.standby.ExternalSharedStoreIT):
proxy not started
testProxySkippedBytesIntermediateChange(org.apache.jackrabbit.oak.plugins.segment.standby.ExternalSharedStoreIT):
proxy not started
testProxyFlippedStartByte(org.apache.jackrabbit.oak.plugins.segment.standby.ExternalSharedStoreIT):
proxy not started
testProxyFlippedIntermediateByte(org.apache.jackrabbit.oak.plugins.segment.standby.ExternalSharedStoreIT):
proxy not started
testProxyFlippedIntermediateByte2(org.apache.jackrabbit.oak.plugins.segment.standby.ExternalSharedStoreIT):
proxy not started
testProxyFlippedIntermediateByteChange(org.apache.jackrabbit.oak.plugins.segment.standby.ExternalSharedStoreIT):
proxy not started
testProxyFlippedIntermediateByteChange2(org.apache.jackrabbit.oak.plugins.segment.standby.ExternalSharedStoreIT):
proxy not started
{noformat}
Stacktraces always look something like:
{noformat}
java.lang.Exception: proxy not started
at
org.apache.jackrabbit.oak.plugins.segment.NetworkErrorProxy.reset(NetworkErrorProxy.java:87)
at
org.apache.jackrabbit.oak.plugins.segment.standby.DataStoreTestBase.useProxy(DataStoreTestBase.java:176)
at
org.apache.jackrabbit.oak.plugins.segment.standby.DataStoreTestBase.testProxySkippedBytes(DataStoreTestBase.java:118)
{noformat}
See
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/31/jdk=latest1.7,label=Ubuntu,nsfixtures=DOCUMENT_NS,profile=integrationTesting/console
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2658) Test failures in TarMK standby: Address already in use
[
https://issues.apache.org/jira/browse/OAK-2658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14371492#comment-14371492
]
Alex Parvulescu commented on OAK-2658:
--
if you look at the TestBase setup, you'll see the default port when the system
property is not set is _ 52800_, so maybe that particular test setup step
doesn't execute?
Test failures in TarMK standby: Address already in use
--
Key: OAK-2658
URL: https://issues.apache.org/jira/browse/OAK-2658
Project: Jackrabbit Oak
Issue Type: Bug
Components: oak-tarmk-standby
Environment: Jenkins, Ubuntu:
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
Reporter: Michael Dürig
Labels: CI, jenkins
Fix For: 1.2
The following tests fail probably all for the same reason:
{noformat}
testProxySkippedBytes(org.apache.jackrabbit.oak.plugins.segment.standby.ExternalSharedStoreIT):
proxy not started
testProxySkippedBytesIntermediateChange(org.apache.jackrabbit.oak.plugins.segment.standby.ExternalSharedStoreIT):
proxy not started
testProxyFlippedStartByte(org.apache.jackrabbit.oak.plugins.segment.standby.ExternalSharedStoreIT):
proxy not started
testProxyFlippedIntermediateByte(org.apache.jackrabbit.oak.plugins.segment.standby.ExternalSharedStoreIT):
proxy not started
testProxyFlippedIntermediateByte2(org.apache.jackrabbit.oak.plugins.segment.standby.ExternalSharedStoreIT):
proxy not started
testProxyFlippedIntermediateByteChange(org.apache.jackrabbit.oak.plugins.segment.standby.ExternalSharedStoreIT):
proxy not started
testProxyFlippedIntermediateByteChange2(org.apache.jackrabbit.oak.plugins.segment.standby.ExternalSharedStoreIT):
proxy not started
{noformat}
Stacktraces always look something like:
{noformat}
java.lang.Exception: proxy not started
at
org.apache.jackrabbit.oak.plugins.segment.NetworkErrorProxy.reset(NetworkErrorProxy.java:87)
at
org.apache.jackrabbit.oak.plugins.segment.standby.DataStoreTestBase.useProxy(DataStoreTestBase.java:176)
at
org.apache.jackrabbit.oak.plugins.segment.standby.DataStoreTestBase.testProxySkippedBytes(DataStoreTestBase.java:118)
{noformat}
See
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/31/jdk=latest1.7,label=Ubuntu,nsfixtures=DOCUMENT_NS,profile=integrationTesting/console
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-2655) Test failure: OrderableNodesTest.testAddNode
[
https://issues.apache.org/jira/browse/OAK-2655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14371295#comment-14371295
]
Julian Reschke edited comment on OAK-2655 at 3/20/15 3:47 PM:
--
Likely a race condition with a bg thread; an update operation finds the
document, updates it in memory and tries to write it back to the db where it is
gone in the meantime; should fall back to creating it.
was (Author: reschke):
(it fails unreliably; seems to be an interaction with a background thread)
Test failure: OrderableNodesTest.testAddNode
Key: OAK-2655
URL: https://issues.apache.org/jira/browse/OAK-2655
Project: Jackrabbit Oak
Issue Type: Bug
Components: rdbmk
Environment: Jenkins, Ubuntu:
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
Reporter: Michael Dürig
Assignee: Julian Reschke
Labels: CI, Jenkins
Fix For: 1.2
{{org.apache.jackrabbit.oak.jcr.OrderableNodesTest.testAddNode}} fails on
Jenkins when running the {{DOCUMENT_RDB}} fixture.
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/30/jdk=jdk-1.6u45,label=Ubuntu,nsfixtures=DOCUMENT_RDB,profile=unittesting/testReport/junit/org.apache.jackrabbit.oak.jcr/OrderableNodesTest/testAddNode_0_/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-2399) Custom scorer for modifying score per documents
[ https://issues.apache.org/jira/browse/OAK-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller resolved OAK-2399. - Resolution: Fixed Custom scorer for modifying score per documents --- Key: OAK-2399 URL: https://issues.apache.org/jira/browse/OAK-2399 Project: Jackrabbit Oak Issue Type: New Feature Components: oak-lucene Reporter: Rishabh Maurya Assignee: Thomas Mueller Fix For: 1.1.8, 1.2 Attachments: OAK-2399_1.patch, OAK-2399_scorer.patch We have search enhancements requests based on search results relevance like - 1. boosting score of recently modified documents. 2. boosting documents which are created/last updated by current session user.(OR boosting on basis specific field value). 3. boosting documents with a field value in certain range. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (OAK-2656) Test failures in LDAP authentication: Failed to bind an LDAP service
[
https://issues.apache.org/jira/browse/OAK-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra reassigned OAK-2656:
-
Assignee: Tobias Bocanegra
Test failures in LDAP authentication: Failed to bind an LDAP service
Key: OAK-2656
URL: https://issues.apache.org/jira/browse/OAK-2656
Project: Jackrabbit Oak
Issue Type: Bug
Components: auth-ldap
Environment: Jenkins, Ubuntu:
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
Reporter: Michael Dürig
Assignee: Tobias Bocanegra
Labels: CI, Jenkins
Fix For: 1.2
The following tests all fail with the same error message Failed to bind an
LDAP service (1024) to the service registry..
{noformat}
testAuthenticateFail(org.apache.jackrabbit.oak.security.authentication.ldap.LdapProviderTest):
Failed to bind an LDAP service (1024) to the service registry.
testGetGroups2(org.apache.jackrabbit.oak.security.authentication.ldap.LdapProviderTest):
Failed to bind an LDAP service (1024) to the service registry.
org.apache.jackrabbit.oak.security.authentication.ldap.LdapDefaultLoginModuleTest:
Failed to bind an LDAP service (1024) to the service registry.
testGetUserByUserId(org.apache.jackrabbit.oak.security.authentication.ldap.LdapProviderTest):
Failed to bind an LDAP service (1024) to the service registry.
{noformat}
The stacktrace is always similar:
{noformat}
java.net.BindException: Address already in use]
at
org.apache.directory.server.ldap.LdapServer.startNetwork(LdapServer.java:528)
at
org.apache.directory.server.ldap.LdapServer.start(LdapServer.java:394)
at
org.apache.directory.server.unit.AbstractServerTest.setUp(AbstractServerTest.java:273)
at
org.apache.jackrabbit.oak.security.authentication.ldap.InternalLdapServer.setUp(InternalLdapServer.java:37)
at
org.apache.jackrabbit.oak.security.authentication.ldap.LdapLoginTestBase.beforeClass(LdapLoginTestBase.java:86)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: java.net.BindException: Address already in use
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:444)
at sun.nio.ch.Net.bind(Net.java:436)
at
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:214)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at
org.apache.mina.transport.socket.nio.NioSocketAcceptor.open(NioSocketAcceptor.java:198)
at
org.apache.mina.transport.socket.nio.NioSocketAcceptor.open(NioSocketAcceptor.java:51)
at
org.apache.mina.core.polling.AbstractPollingIoAcceptor.registerHandles(AbstractPollingIoAcceptor.java:547)
at
org.apache.mina.core.polling.AbstractPollingIoAcceptor.access$400(AbstractPollingIoAcceptor.java:68)
at
[jira] [Commented] (OAK-2656) Test failures in LDAP authentication: Failed to bind an LDAP service
[
https://issues.apache.org/jira/browse/OAK-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14372513#comment-14372513
]
Tobias Bocanegra commented on OAK-2656:
---
hmm...the tests extends from AbstractServerTest which already should find the
next available port automatically:
https://svn.apache.org/viewvc/directory/apacheds/tags/1.5.1/server-unit/src/main/java/org/apache/directory/server/unit/AbstractServerTest.java?view=markup#l233
also the time between the AvailablePortFinder.getNextAvailable() call and the
actual server startup is very little. so it is weird that this happens.
also it would be difficult to use another port - as we would need to copy-paste
the entire basetestbut doable :-)
Test failures in LDAP authentication: Failed to bind an LDAP service
Key: OAK-2656
URL: https://issues.apache.org/jira/browse/OAK-2656
Project: Jackrabbit Oak
Issue Type: Bug
Components: auth-ldap
Environment: Jenkins, Ubuntu:
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
Reporter: Michael Dürig
Assignee: Tobias Bocanegra
Labels: CI, Jenkins
Fix For: 1.2
The following tests all fail with the same error message Failed to bind an
LDAP service (1024) to the service registry..
{noformat}
testAuthenticateFail(org.apache.jackrabbit.oak.security.authentication.ldap.LdapProviderTest):
Failed to bind an LDAP service (1024) to the service registry.
testGetGroups2(org.apache.jackrabbit.oak.security.authentication.ldap.LdapProviderTest):
Failed to bind an LDAP service (1024) to the service registry.
org.apache.jackrabbit.oak.security.authentication.ldap.LdapDefaultLoginModuleTest:
Failed to bind an LDAP service (1024) to the service registry.
testGetUserByUserId(org.apache.jackrabbit.oak.security.authentication.ldap.LdapProviderTest):
Failed to bind an LDAP service (1024) to the service registry.
{noformat}
The stacktrace is always similar:
{noformat}
java.net.BindException: Address already in use]
at
org.apache.directory.server.ldap.LdapServer.startNetwork(LdapServer.java:528)
at
org.apache.directory.server.ldap.LdapServer.start(LdapServer.java:394)
at
org.apache.directory.server.unit.AbstractServerTest.setUp(AbstractServerTest.java:273)
at
org.apache.jackrabbit.oak.security.authentication.ldap.InternalLdapServer.setUp(InternalLdapServer.java:37)
at
org.apache.jackrabbit.oak.security.authentication.ldap.LdapLoginTestBase.beforeClass(LdapLoginTestBase.java:86)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: java.net.BindException: Address already in use
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:444)
at sun.nio.ch.Net.bind(Net.java:436)
at
[jira] [Commented] (OAK-2652) [Oak API remoting] Finalize http authentication
[ https://issues.apache.org/jira/browse/OAK-2652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14371188#comment-14371188 ] Francesco Mari commented on OAK-2652: - This is fixed at commit fd0ccad in my fork. [Oak API remoting] Finalize http authentication --- Key: OAK-2652 URL: https://issues.apache.org/jira/browse/OAK-2652 Project: Jackrabbit Oak Issue Type: New Feature Reporter: Fabrice Hong * In addition to unauthorized status. set response header to WWW-Authenticate =Basic realm=\Oak\ in case the user is not authenticated. see class OakServlet * Implement the other authentication Schemes (Digest, NTLM ?). Use standard libraries for this. Apache ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-2652) [Oak API remoting] Finalize http authentication
[ https://issues.apache.org/jira/browse/OAK-2652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14371188#comment-14371188 ] Francesco Mari edited comment on OAK-2652 at 3/20/15 11:57 AM: --- This is fixed at commit fd0ccad in my fork. For the moment, only Basic authentication is supported. was (Author: frm): This is fixed at commit fd0ccad in my fork. [Oak API remoting] Finalize http authentication --- Key: OAK-2652 URL: https://issues.apache.org/jira/browse/OAK-2652 Project: Jackrabbit Oak Issue Type: New Feature Reporter: Fabrice Hong * In addition to unauthorized status. set response header to WWW-Authenticate =Basic realm=\Oak\ in case the user is not authenticated. see class OakServlet * Implement the other authentication Schemes (Digest, NTLM ?). Use standard libraries for this. Apache ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-2287) ConflictHandler for merging jcr:lastModified
[ https://issues.apache.org/jira/browse/OAK-2287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig resolved OAK-2287. Resolution: Fixed Fix Version/s: (was: 1.2) 1.1.8 Fixed at http://svn.apache.org/r1667996 ConflictHandler for merging jcr:lastModified Key: OAK-2287 URL: https://issues.apache.org/jira/browse/OAK-2287 Project: Jackrabbit Oak Issue Type: Improvement Components: core, jcr Reporter: Alex Parvulescu Assignee: Michael Dürig Priority: Minor Fix For: 1.1.8 Attachments: OAK-2287-2.patch, OAK-2287-3.patch, OAK-2287.patch As discussed on oak-dev, 'jcr:lastModified' is a date property and it represents the last modification date. It makes sense to merge concurrent updates by picking the newer date of the 2 options. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2006) Verify the maven baseline output and fix the warnings
[ https://issues.apache.org/jira/browse/OAK-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-2006: --- Fix Version/s: (was: 1.2) 1.1.8 Verify the maven baseline output and fix the warnings - Key: OAK-2006 URL: https://issues.apache.org/jira/browse/OAK-2006 Project: Jackrabbit Oak Issue Type: Improvement Components: core Reporter: Alex Parvulescu Assignee: Michael Dürig Labels: build Fix For: 1.1.8 Attachments: baseline-oak-core.patch Currently the maven baseline plugin only logs the package version mismatches, it doesn't fail the build. It would be beneficial to start looking at the output and possibly fix some of the warnings (increase the OSGi package versions). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2006) Verify the maven baseline output and fix the warnings
[ https://issues.apache.org/jira/browse/OAK-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14371218#comment-14371218 ] Michael Dürig commented on OAK-2006: Set this to the same fix version as OAK-1956 and made both issues mutual blockers. I think we need to fix them in lockstep to avoid duplicate work. Verify the maven baseline output and fix the warnings - Key: OAK-2006 URL: https://issues.apache.org/jira/browse/OAK-2006 Project: Jackrabbit Oak Issue Type: Improvement Components: core Reporter: Alex Parvulescu Assignee: Michael Dürig Labels: build Fix For: 1.1.8 Attachments: baseline-oak-core.patch Currently the maven baseline plugin only logs the package version mismatches, it doesn't fail the build. It would be beneficial to start looking at the output and possibly fix some of the warnings (increase the OSGi package versions). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2476) Move our CI to Jenkins
[
https://issues.apache.org/jira/browse/OAK-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14371236#comment-14371236
]
Michael Dürig commented on OAK-2476:
Still no new platform problems with [build
30|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/30/].
* All windows builds errored. Presumable due to no disk space left. I've taken
the Windows builds off line for now (via the combination filter) so it doesn't
impact the test of the builds. Let's follow up separately re. Windows.
* One test failure:
{{org.apache.jackrabbit.oak.jcr.OrderableNodesTest.testAddNode}}. I'll file an
issue.
* Still the problem with the {{geronimo-jta_1.0.1B_spec}} dependency. I'll
create an BUILDS issue.
Move our CI to Jenkins
--
Key: OAK-2476
URL: https://issues.apache.org/jira/browse/OAK-2476
Project: Jackrabbit Oak
Issue Type: Task
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
Priority: Critical
Labels: CI, build, infrastructure
Fix For: 1.2
We should strive for stabilization of our CI setup, as of now we had Buildbot
and Travis.
It seems ASF Jenkins can perform jobs on different environments (*nix,
Windows and others) so we can evaluate that and check if it better address
our needs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2037) Define standards for plan output
[ https://issues.apache.org/jira/browse/OAK-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-2037: Fix Version/s: (was: 1.1.8) (was: 1.2) 1.3.0 Define standards for plan output Key: OAK-2037 URL: https://issues.apache.org/jira/browse/OAK-2037 Project: Jackrabbit Oak Issue Type: Improvement Components: query Reporter: Justin Edelson Assignee: Thomas Mueller Fix For: 1.3.0 Currently, the syntax for the plan output is chaotic as it varies significantly from index to index. Whereas some of this is expected - each index type will have different data to output, Oak should provide some standards about how a plan will appear. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-2661) Glob restriction test failures on Jenkins
Michael Dürig created OAK-2661:
--
Summary: Glob restriction test failures on Jenkins
Key: OAK-2661
URL: https://issues.apache.org/jira/browse/OAK-2661
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Environment: Jenkins, Ubuntu:
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
Reporter: Michael Dürig
Fix For: 1.2
The following tests fail often on Jenkins:
{noformat}
testGlobRestriction2(org.apache.jackrabbit.oak.jcr.security.authorization.ReadTest):
Authorizable with ID group2 already exists
testGlobRestriction3(org.apache.jackrabbit.oak.jcr.security.authorization.ReadTest):
Authorizable with ID group2 already exists
{noformat}
See
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/33/jdk=jdk1.8.0_11,label=Ubuntu,nsfixtures=DOCUMENT_NS,profile=unittesting/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2660) wrong resultset multiple ORs, lucene index, full-text
[
https://issues.apache.org/jira/browse/OAK-2660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14371690#comment-14371690
]
Davide Giannella commented on OAK-2660:
---
Ignored test case in http://svn.apache.org/r1668104
wrong resultset multiple ORs, lucene index, full-text
-
Key: OAK-2660
URL: https://issues.apache.org/jira/browse/OAK-2660
Project: Jackrabbit Oak
Issue Type: Bug
Components: query
Affects Versions: 1.1.7
Reporter: Davide Giannella
Assignee: Davide Giannella
Fix For: 1.1.8
When executing a query like
{code}
SELECT *
FROM [nt:unstructured] AS c
WHERE ( c.[name] = 'yes'
OR CONTAINS(c.[surname], 'yes')
OR CONTAINS(c.[description], 'yes') )
AND ISDESCENDANTNODE(c, '/content')
ORDER BY added DESC
{code}
and a lucene property index is serving all the properties: {{name, surname,
description, added}} the full index is returned and no extra condition is
applied.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-2660) wrong resultset multiple ORs, lucene index, full-text
Davide Giannella created OAK-2660:
-
Summary: wrong resultset multiple ORs, lucene index, full-text
Key: OAK-2660
URL: https://issues.apache.org/jira/browse/OAK-2660
Project: Jackrabbit Oak
Issue Type: Bug
Components: query
Affects Versions: 1.1.7
Reporter: Davide Giannella
Assignee: Davide Giannella
Fix For: 1.1.8
When executing a query like
{code}
SELECT *
FROM [nt:unstructured] AS c
WHERE ( c.[name] = 'yes'
OR CONTAINS(c.[surname], 'yes')
OR CONTAINS(c.[description], 'yes') )
AND ISDESCENDANTNODE(c, '/content')
ORDER BY added DESC
{code}
and a lucene property index is serving all the properties: {{name, surname,
description, added}} the full index is returned and no extra condition is
applied.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2476) Move our CI to Jenkins
[
https://issues.apache.org/jira/browse/OAK-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14371558#comment-14371558
]
Michael Dürig commented on OAK-2476:
Also the {{pedantic}} profile started to fail again:
{noformat}
Recording test results
Test reports were found but none of them are new. Did tests run?
For example, /home/jenkins/jenkins-slave/workspace/Apache Jackrabbit Oak
matrix/jdk/jdk1.8.0_11/label/Ubuntu/nsfixtures/SEGMENT_MK/profile/pedantic/TEST-org.apache.jackrabbit.oak.Dummy.xml
is 1 hr 56 min old
Build step 'Publish JUnit test result report' changed build result to FAILURE
Finished: FAILURE
{noformat}
It seems that my workaround with the static test result file is not enough as
Jenkins tries hard to be clever here.
Move our CI to Jenkins
--
Key: OAK-2476
URL: https://issues.apache.org/jira/browse/OAK-2476
Project: Jackrabbit Oak
Issue Type: Task
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
Priority: Critical
Labels: CI, build, infrastructure
Fix For: 1.2
We should strive for stabilization of our CI setup, as of now we had Buildbot
and Travis.
It seems ASF Jenkins can perform jobs on different environments (*nix,
Windows and others) so we can evaluate that and check if it better address
our needs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2654) SegmentIdTable too eager to refresh
[ https://issues.apache.org/jira/browse/OAK-2654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14371596#comment-14371596 ] Alex Parvulescu commented on OAK-2654: -- fyi. I tested this patch against a fresh 1.0 build migrating a 13M nodes repo and the editors part (mainly indexing) went from *55 mins* to *35 mins* on my local machine. I also used the _mmap_ flag: 'java -Xmx8g -XX:MaxPermSize=512M -jar crx2oak-*.jar --mmap old-repo new-repo'). Maybe using a counter can push this further, but I stopped seeing the #refresh listed as a bottleneck. cc [~chetanm] SegmentIdTable too eager to refresh --- Key: OAK-2654 URL: https://issues.apache.org/jira/browse/OAK-2654 Project: Jackrabbit Oak Issue Type: Improvement Components: segmentmk Reporter: Alex Parvulescu Assignee: Alex Parvulescu Fix For: 1.1.8, 1.2 Attachments: OAK-2654.patch Calling SegmentIdTable#getSegmentId might trigger a reference table refresh if a certain condition is met, I think that this condition is too eager to trigger the refresh and in high write scenarios, this results in large pauses as the method is synchronized. The current condition resembles a cache miss (_index != first_) which means that when looking up a segment id by the _lsb_ it might happen that it either - is not there, so it needs to be added (no refresh on this branch) - or there is an overlap on lsb values (actually on the value returned by _getIndex(lsb)_), in which case a refresh will be triggered. In high write scenarios the refresh case happens a lot more frequently so a refresh is triggered, even if it might not be needed. a refresh makes sense when there are null references and it might make sense for them to be collected otherwise we're just creating clones of the same map over and over again. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-2654) SegmentIdTable too eager to refresh
[
https://issues.apache.org/jira/browse/OAK-2654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14371596#comment-14371596
]
Alex Parvulescu edited comment on OAK-2654 at 3/20/15 4:48 PM:
---
fyi. I tested this patch against a fresh 1.0 build migrating a 13M nodes repo
and the editors part (mainly indexing) went from *55 mins* to *35 mins* on my
local machine. I also used the _mmap_ flag:
{code}
java -Xmx8g -XX:MaxPermSize=512M -jar crx2oak-*.jar --mmap old-repo new-repo
{code}
Maybe using a counter can push this further, but I stopped seeing the #refresh
listed as a bottleneck.
cc [~chetanm]
was (Author: alex.parvulescu):
fyi. I tested this patch against a fresh 1.0 build migrating a 13M nodes repo
and the editors part (mainly indexing) went from *55 mins* to *35 mins* on my
local machine. I also used the _mmap_ flag: 'java -Xmx8g -XX:MaxPermSize=512M
-jar crx2oak-*.jar --mmap old-repo new-repo').
Maybe using a counter can push this further, but I stopped seeing the #refresh
listed as a bottleneck.
cc [~chetanm]
SegmentIdTable too eager to refresh
---
Key: OAK-2654
URL: https://issues.apache.org/jira/browse/OAK-2654
Project: Jackrabbit Oak
Issue Type: Improvement
Components: segmentmk
Reporter: Alex Parvulescu
Assignee: Alex Parvulescu
Fix For: 1.1.8, 1.2
Attachments: OAK-2654.patch
Calling SegmentIdTable#getSegmentId might trigger a reference table refresh
if a certain condition is met, I think that this condition is too eager to
trigger the refresh and in high write scenarios, this results in large pauses
as the method is synchronized.
The current condition resembles a cache miss (_index != first_) which means
that when looking up a segment id by the _lsb_ it might happen that it either
- is not there, so it needs to be added (no refresh on this branch)
- or there is an overlap on lsb values (actually on the value returned by
_getIndex(lsb)_), in which case a refresh will be triggered.
In high write scenarios the refresh case happens a lot more frequently so a
refresh is triggered, even if it might not be needed. a refresh makes sense
when there are null references and it might make sense for them to be
collected otherwise we're just creating clones of the same map over and over
again.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-2404) Provide more information in SegmentNotFoundException
[
https://issues.apache.org/jira/browse/OAK-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig resolved OAK-2404.
Resolution: Fixed
Applied the patch at
* Trunk: http://svn.apache.org/r1668160
* 1.0: http://svn.apache.org/r1668163
Cleaned segments are now logged at INFO level to a separate logger
org.apache.jackrabbit.oak.plugins.segment.file.TarReader-GC. Let's see how
long it takes until this is called log spam. Depending on such reactions we can
the decide how to take this further into better tooling.
Provide more information in SegmentNotFoundException
Key: OAK-2404
URL: https://issues.apache.org/jira/browse/OAK-2404
Project: Jackrabbit Oak
Issue Type: Sub-task
Components: segmentmk
Reporter: Michael Dürig
Assignee: Michael Dürig
Labels: gc, monitoring
Fix For: 1.0.13, 1.2
Attachments: OAK-2404.patch
There is currently no way to distinguish between a
{{SegmentNotFoundException}} occurring because of a removed segment by gc or
because of another corruption. Optimally we would tell in the exception why
the segment is gone, how old it was when gc removed it and who/what was still
referring to it at that time. In order to do that, we probably need some kind
of log for the following data: When a segment was removed (because a new
generation of the .tar file was made, or because the .tar file was removed),
we should log the segment, the file name, and the date+time of the removal.
If the segment was then not found because it was too old, then another type
of exception should be thrown instead, for example ReadTimeoutException,
with a message that contains as much data as possible: the data+time of the
segment, date+time of the removal of the segment, about when compaction was
run, date+time of the session login and last refresh, the stack trace of
where the session was acquired.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2641) FilterImpl violates nullability contract
[
https://issues.apache.org/jira/browse/OAK-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14371067#comment-14371067
]
Michael Dürig commented on OAK-2641:
Works for me in general. However as this is a change in API, are we
sufficiently sure we are not breaking anything upstream?
FilterImpl violates nullability contract
-
Key: OAK-2641
URL: https://issues.apache.org/jira/browse/OAK-2641
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: Michael Dürig
Fix For: 1.2
Attachments: OAK-2641.patch
{{FilterImpl#getSupertypes}}, {{FilterImpl#getPrimaryTypes}} and
{{FilterImpl#getMixinTypes}} might all return {{null}} although {{Filter}}'s
contract mandates \@Nonull.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-2659) Failed expectations in TarMK standby tests
[
https://issues.apache.org/jira/browse/OAK-2659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig resolved OAK-2659.
Resolution: Fixed
Assignee: Michael Dürig
Turns out that this was caused by missing configuration for the failsafe
plugin. Fixed at http://svn.apache.org/r1668172
Failed expectations in TarMK standby tests
--
Key: OAK-2659
URL: https://issues.apache.org/jira/browse/OAK-2659
Project: Jackrabbit Oak
Issue Type: Bug
Components: oak-tarmk-standby
Environment: Jenkins, Ubuntu:
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
Reporter: Michael Dürig
Assignee: Michael Dürig
Labels: CI, Jenkins
Fix For: 1.2
I see many similar test failures for {{FailoverMultipleClientsTestIT}} and
{{RecoverTestIT}} on Jenkins. For example:
{noformat}
testSyncLoop(org.apache.jackrabbit.oak.plugins.segment.standby.StandbyTestIT):
expected:{ checkpoints = { ... }, root = { ... } } but was:{ root : { } }
testLocalChanges(org.apache.jackrabbit.oak.plugins.segment.standby.RecoverTestIT):
expected: org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState{ root
= { ... } } but was:
org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState{ root = { ... } }
{noformat}
See
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/31/jdk=jdk1.8.0_11,label=Ubuntu,nsfixtures=DOCUMENT_NS,profile=integrationTesting/console
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/31/jdk=latest1.7,label=Ubuntu,nsfixtures=SEGMENT_MK,profile=integrationTesting/console
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/31/jdk=latest1.7,label=Ubuntu,nsfixtures=DOCUMENT_NS,profile=integrationTesting/console
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
