[jira] [Updated] (OAK-4054) FileStore.containsSegment returns alway true (almost)
[
https://issues.apache.org/jira/browse/OAK-4054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-4054:
---
Labels: compaction gc stability (was: compaction gc)
> FileStore.containsSegment returns alway true (almost)
> -
>
> Key: OAK-4054
> URL: https://issues.apache.org/jira/browse/OAK-4054
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segmentmk
>Reporter: Michael Dürig
> Labels: compaction, gc, stability
>
> {{FileStore.containsSegment()}} looks
> [funky|https://github.com/mduerig/jackrabbit-oak/blob/36cb3bf6e5078e3afa75581fb789eeca7b5df2e2/oak-segment/src/main/java/org/apache/jackrabbit/oak/plugins/segment/file/FileStore.java#L1197-L1197].
> This "optimisation" causes it to always return {{true}}.
> {{containsSegment}} is used for deduplication and revision gc. The current
> implementation causes {{SNFE}} exceptions once gc is effective (as I
> experienced while working on OAK-3348).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-4054) FileStore.containsSegment returns alway true (almost)
[
https://issues.apache.org/jira/browse/OAK-4054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig reassigned OAK-4054:
--
Assignee: Michael Dürig
> FileStore.containsSegment returns alway true (almost)
> -
>
> Key: OAK-4054
> URL: https://issues.apache.org/jira/browse/OAK-4054
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segmentmk
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: compaction, gc, stability
>
> {{FileStore.containsSegment()}} looks
> [funky|https://github.com/mduerig/jackrabbit-oak/blob/36cb3bf6e5078e3afa75581fb789eeca7b5df2e2/oak-segment/src/main/java/org/apache/jackrabbit/oak/plugins/segment/file/FileStore.java#L1197-L1197].
> This "optimisation" causes it to always return {{true}}.
> {{containsSegment}} is used for deduplication and revision gc. The current
> implementation causes {{SNFE}} exceptions once gc is effective (as I
> experienced while working on OAK-3348).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4054) FileStore.containsSegment returns alway true (almost)
[
https://issues.apache.org/jira/browse/OAK-4054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15163788#comment-15163788
]
Michael Dürig commented on OAK-4054:
Test case at http://svn.apache.org/viewvc?rev=1732230=rev
The obvious fix would be to remove the
[check|https://github.com/mduerig/jackrabbit-oak/blob/36cb3bf6e5078e3afa75581fb789eeca7b5df2e2/oak-segment/src/main/java/org/apache/jackrabbit/oak/plugins/segment/file/FileStore.java#L1196-L1198]
at the beginning of {{containsSegment}}. Not sure about the fall out this
would generate though and whether we should target it for 1.4.
cc [~alex.parvulescu], [~frm]
> FileStore.containsSegment returns alway true (almost)
> -
>
> Key: OAK-4054
> URL: https://issues.apache.org/jira/browse/OAK-4054
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segmentmk
>Reporter: Michael Dürig
> Labels: compaction, gc
>
> {{FileStore.containsSegment()}} looks
> [funky|https://github.com/mduerig/jackrabbit-oak/blob/36cb3bf6e5078e3afa75581fb789eeca7b5df2e2/oak-segment/src/main/java/org/apache/jackrabbit/oak/plugins/segment/file/FileStore.java#L1197-L1197].
> This "optimisation" causes it to always return {{true}}.
> {{containsSegment}} is used for deduplication and revision gc. The current
> implementation causes {{SNFE}} exceptions once gc is effective (as I
> experienced while working on OAK-3348).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-4054) FileStore.containsSegment returns alway true (almost)
Michael Dürig created OAK-4054:
--
Summary: FileStore.containsSegment returns alway true (almost)
Key: OAK-4054
URL: https://issues.apache.org/jira/browse/OAK-4054
Project: Jackrabbit Oak
Issue Type: Bug
Components: segmentmk
Reporter: Michael Dürig
{{FileStore.containsSegment()}} looks
[funky|https://github.com/mduerig/jackrabbit-oak/blob/36cb3bf6e5078e3afa75581fb789eeca7b5df2e2/oak-segment/src/main/java/org/apache/jackrabbit/oak/plugins/segment/file/FileStore.java#L1197-L1197].
This "optimisation" causes it to always return {{true}}.
{{containsSegment}} is used for deduplication and revision gc. The current
implementation causes {{SNFE}} exceptions once gc is effective (as I
experienced while working on OAK-3348).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-3930) Sysview import of single valued mv property creates sv property
[ https://issues.apache.org/jira/browse/OAK-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15163188#comment-15163188 ] angela edited comment on OAK-3930 at 2/24/16 7:45 PM: -- Committed revision 1732170 including test-case. building oak including ITs passed. was (Author: anchela): Committed revision 1732170. > Sysview import of single valued mv property creates sv property > --- > > Key: OAK-3930 > URL: https://issues.apache.org/jira/browse/OAK-3930 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Affects Versions: 1.3.14 >Reporter: Tobias Bocanegra >Assignee: angela > Fix For: 1.3.17 > > > See test in filevault [0]. > it imports a multivalue property that only has 1 value, via [1]. the same > test succeeds in jackrabbit 2.0, but fails in oak 1.3.14 > [0] > https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.1.26/vault-core/src/test/java/org/apache/jackrabbit/vault/packaging/integration/TestUserContentPackage.java#L297-L326 > [1] > https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.1.26/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/JcrSysViewTransformer.java#L146-L148 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-3930) Sysview import of single valued mv property creates sv property
[
https://issues.apache.org/jira/browse/OAK-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15162956#comment-15162956
]
angela edited comment on OAK-3930 at 2/24/16 7:44 PM:
--
[~tripod], just had a quick look... IMO that's a plain bug in
{{SysViewImportHandler}} line 280: the {{PropInfo}} is created without passing
the {{currentPropMultipleStatus}} to the constructor. I will create test-cases
illustrating what I believe is the issue you reported and commit the fix if all
tests including ITs pass.
was (Author: anchela):
[~tripod], just had a quick look... IMO that's a plain bug in
{{SysViewImportHandler}} line 280: the {{PropInfo}} is created with passing the
{{currentPropMultipleStatus}} to the constructor. I will create test-cases
illustrating what I believe is the issue you reported and commit the fix if all
tests including ITs pass.
> Sysview import of single valued mv property creates sv property
> ---
>
> Key: OAK-3930
> URL: https://issues.apache.org/jira/browse/OAK-3930
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.3.14
>Reporter: Tobias Bocanegra
>Assignee: angela
> Fix For: 1.3.17
>
>
> See test in filevault [0].
> it imports a multivalue property that only has 1 value, via [1]. the same
> test succeeds in jackrabbit 2.0, but fails in oak 1.3.14
> [0]
> https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.1.26/vault-core/src/test/java/org/apache/jackrabbit/vault/packaging/integration/TestUserContentPackage.java#L297-L326
> [1]
> https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.1.26/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/JcrSysViewTransformer.java#L146-L148
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-3228) Delayed visibility of new groups when using PrincipalManager
[
https://issues.apache.org/jira/browse/OAK-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-3228.
-
Resolution: Cannot Reproduce
[~kwin], [~henzlerg], if you can provide an updated test-case that allows me to
reproduce your finding in Oak trunk or the 1.2 branch, please feel free to
reopen with a patch (or instructions). thanks a lot.
> Delayed visibility of new groups when using PrincipalManager
> -
>
> Key: OAK-3228
> URL: https://issues.apache.org/jira/browse/OAK-3228
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.2.2
>Reporter: Georg Henzler
> Attachments: OAK-3228_testcase.patch
>
>
> PrincipalManager does not show groups that were just created (this is causing
> problems in our code). As workaround we use now
> UserManager.getAuthorizable().getPrincipal() which curiously works
> immediately after saving a group. Also it does not seem to be an index
> problem, as a query {{SELECT * FROM [rep:Authorizable] WHERE
> [rep:principalName] = "mygroup"}} also immediately shows a new group.
> See the following servlet snippet for easy reproduction:
> {code}
> ...
> @SlingServlet(paths = "/bin/CreateGroupAndRetrievePrincipal", methods = "GET")
> public class CreateGroupAndRetrievePrincipalServlet extends
> SlingSafeMethodsServlet {
> private static final long serialVersionUID = 1L;
> private static final Logger LOG =
> LoggerFactory.getLogger(CreateGroupAndRetrievePrincipalServlet.class);
> @Reference
> private SlingRepository repository;
> @Override
> @SuppressWarnings("deprecation")
> protected void doGet(final SlingHttpServletRequest request, final
> SlingHttpServletResponse response) throws ServletException,
> IOException {
> response.setContentType("text/plain");
> PrintWriter out = response.getWriter();
> final String groupName = request.getParameter("g");
> LOG.debug("test");
> Session session = null;
> try {
> session = repository.loginAdministrative(null);
> UserManager usermanager = ((JackrabbitSession)
> session).getUserManager();
> Group newGroup = usermanager.createGroup(new
> java.security.Principal() {
> @Override
> public String getName() {
> return groupName;
> }
> }, "principaltest");
> out.println("Created Group " + newGroup);
> session.save();
> } catch (Exception e) {
> throw new ServletException(e.getMessage(), e);
> } finally {
> if (session != null) {
> session.logout();
> session = null;
> }
> }
> out.println();
> try {
> session = repository.loginAdministrative(null);
> // No 1: PrincipalManager
> PrincipalManager principalManager = ((JackrabbitSession)
> session).getPrincipalManager();
> Principal principal = principalManager.getPrincipal(groupName);
> out.println("PrincipalManager: principal: " + principal);
> // No 2: UserManager
> UserManager usermanager = ((JackrabbitSession)
> session).getUserManager();
> Authorizable authorizable =
> usermanager.getAuthorizable(groupName);
> out.println("UserManager: authorizable: " + authorizable);
> // No 3: query
> QueryManager queryManager =
> session.getWorkspace().getQueryManager();
> final Query query = queryManager.createQuery("SELECT * FROM
> [rep:Authorizable] WHERE [rep:principalName] = \"" + groupName
> + "\"", Query.JCR_SQL2);
> QueryResult result = query.execute();
> NodeIterator nodes = result.getNodes();
> if (!nodes.hasNext()) {
> out.println("QUERY: group not found: " + groupName);
> }
> while (nodes.hasNext()) {
> Node resultNode = (Node) nodes.next();
> out.println("QUERY: node " + resultNode.getPath() + "
> property rep:principalName="
> +
> resultNode.getProperty("rep:principalName").getString());
> }
> query.execute();
> } catch (Exception e) {
> throw new ServletException(e.getMessage(), e);
> } finally {
> if (session != null) {
> session.logout();
> session = null;
> }
> }
> }
> }
> {code}
> returns (using AEM 6.1)
> {code}
> Created Group Group 'my-test-group'
> PrincipalManager: principal: null
> UserManager: authorizable: Group 'my-test-group'
> QUERY: node
[jira] [Commented] (OAK-3228) Delayed visibility of new groups when using PrincipalManager
[
https://issues.apache.org/jira/browse/OAK-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15163405#comment-15163405
]
angela commented on OAK-3228:
-
[~kwin], just applied my test-class on the 1.2 branch and both tests (same and
other session) passed.
> Delayed visibility of new groups when using PrincipalManager
> -
>
> Key: OAK-3228
> URL: https://issues.apache.org/jira/browse/OAK-3228
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.2.2
>Reporter: Georg Henzler
> Attachments: OAK-3228_testcase.patch
>
>
> PrincipalManager does not show groups that were just created (this is causing
> problems in our code). As workaround we use now
> UserManager.getAuthorizable().getPrincipal() which curiously works
> immediately after saving a group. Also it does not seem to be an index
> problem, as a query {{SELECT * FROM [rep:Authorizable] WHERE
> [rep:principalName] = "mygroup"}} also immediately shows a new group.
> See the following servlet snippet for easy reproduction:
> {code}
> ...
> @SlingServlet(paths = "/bin/CreateGroupAndRetrievePrincipal", methods = "GET")
> public class CreateGroupAndRetrievePrincipalServlet extends
> SlingSafeMethodsServlet {
> private static final long serialVersionUID = 1L;
> private static final Logger LOG =
> LoggerFactory.getLogger(CreateGroupAndRetrievePrincipalServlet.class);
> @Reference
> private SlingRepository repository;
> @Override
> @SuppressWarnings("deprecation")
> protected void doGet(final SlingHttpServletRequest request, final
> SlingHttpServletResponse response) throws ServletException,
> IOException {
> response.setContentType("text/plain");
> PrintWriter out = response.getWriter();
> final String groupName = request.getParameter("g");
> LOG.debug("test");
> Session session = null;
> try {
> session = repository.loginAdministrative(null);
> UserManager usermanager = ((JackrabbitSession)
> session).getUserManager();
> Group newGroup = usermanager.createGroup(new
> java.security.Principal() {
> @Override
> public String getName() {
> return groupName;
> }
> }, "principaltest");
> out.println("Created Group " + newGroup);
> session.save();
> } catch (Exception e) {
> throw new ServletException(e.getMessage(), e);
> } finally {
> if (session != null) {
> session.logout();
> session = null;
> }
> }
> out.println();
> try {
> session = repository.loginAdministrative(null);
> // No 1: PrincipalManager
> PrincipalManager principalManager = ((JackrabbitSession)
> session).getPrincipalManager();
> Principal principal = principalManager.getPrincipal(groupName);
> out.println("PrincipalManager: principal: " + principal);
> // No 2: UserManager
> UserManager usermanager = ((JackrabbitSession)
> session).getUserManager();
> Authorizable authorizable =
> usermanager.getAuthorizable(groupName);
> out.println("UserManager: authorizable: " + authorizable);
> // No 3: query
> QueryManager queryManager =
> session.getWorkspace().getQueryManager();
> final Query query = queryManager.createQuery("SELECT * FROM
> [rep:Authorizable] WHERE [rep:principalName] = \"" + groupName
> + "\"", Query.JCR_SQL2);
> QueryResult result = query.execute();
> NodeIterator nodes = result.getNodes();
> if (!nodes.hasNext()) {
> out.println("QUERY: group not found: " + groupName);
> }
> while (nodes.hasNext()) {
> Node resultNode = (Node) nodes.next();
> out.println("QUERY: node " + resultNode.getPath() + "
> property rep:principalName="
> +
> resultNode.getProperty("rep:principalName").getString());
> }
> query.execute();
> } catch (Exception e) {
> throw new ServletException(e.getMessage(), e);
> } finally {
> if (session != null) {
> session.logout();
> session = null;
> }
> }
> }
> }
> {code}
> returns (using AEM 6.1)
> {code}
> Created Group Group 'my-test-group'
> PrincipalManager: principal: null
> UserManager: authorizable: Group 'my-test-group'
> QUERY: node /home/groups/principaltest/qb2WDGrrC0q9bE8jaObH property
> rep:principalName=my-test-group
> {code}
> Potentially the problem is that the
[jira] [Commented] (OAK-4030) DocumentNodeStore: required server time accuracy
[ https://issues.apache.org/jira/browse/OAK-4030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15163296#comment-15163296 ] Stefan Egli commented on OAK-4030: -- Re the fact that some RDB have a server time resolution of 1sec - resulting in higher likelihood of the overall diff to be reported as 2 sec - the [DocumentNodeStore allows up to 2000ms diff|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentNodeStoreService.java#L516] (using ) - so no need for any change in that regard > DocumentNodeStore: required server time accuracy > > > Key: OAK-4030 > URL: https://issues.apache.org/jira/browse/OAK-4030 > Project: Jackrabbit Oak > Issue Type: Bug > Components: documentmk >Reporter: Julian Reschke > Labels: resilience > Fix For: 1.4 > > > The DocumentNodeStore currently requires that the local time and the > persistence time differ at most 2 seconds. > I recently tried to run a cluster with two Windows machines, and despite them > being configured to use the same NTP service, they were still 4..5 s off. > https://blogs.technet.microsoft.com/askds/2007/10/23/high-accuracy-w32time-requirements/ > seems to confirm that by default, Windows can't provide the required > accuracy. > One workaround seems to be to install custom ntp clients; but do we really > want to require this? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3866) Sorting on relative properties doesn't work in Solr
[
https://issues.apache.org/jira/browse/OAK-3866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili updated OAK-3866:
-
Affects Version/s: 1.2.9
> Sorting on relative properties doesn't work in Solr
> ---
>
> Key: OAK-3866
> URL: https://issues.apache.org/jira/browse/OAK-3866
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: solr
>Affects Versions: 1.0.22, 1.2.9, 1.3.13
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: 1.6
>
>
> Executing a query like
> {noformat}
> /jcr:root/content/foo//*[(@sling:resourceType = 'x' or @sling:resourceType =
> 'y') and jcr:contains(., 'bar*~')] order by jcr:content/@jcr:primaryType
> descending
> {noformat}
> would assume sorting on the _jcr:primaryType_ property of resulting nodes'
> _jcr:content_ children.
> That is currently not supported in Solr, while it is in Lucene as the latter
> supports index time aggregation.
> We should inspect if it's possible to extend support for Solr too, most
> probably via index time aggregation.
> The query should not fail but at least log a warning about that limitation
> for the time being.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-4047) Option for collapsing jcr:content nodes doesn't work in embedded Solr
[ https://issues.apache.org/jira/browse/OAK-4047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved OAK-4047. -- Resolution: Fixed Fix Version/s: (was: 1.4) 1.3.17 fixed in r1732175 > Option for collapsing jcr:content nodes doesn't work in embedded Solr > - > > Key: OAK-4047 > URL: https://issues.apache.org/jira/browse/OAK-4047 > Project: Jackrabbit Oak > Issue Type: Bug > Components: solr >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > Fix For: 1.3.17 > > > When enabling _collapseJcrContentNodes_ in the Solr index configuration while > using an embedded server, querying will fail because of an unsatisfied > dependency (_com.carrotsearch.hpc_ which is ~1.3MB) in _oak-solr-osgi_ > pom.xml. > The mentioned dependency should be added to _oak-solr-osgi_ pom in order to > make it possible to use that option with embedded server too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4049) Session mbean does not provide initStacktrace anymore
[ https://issues.apache.org/jira/browse/OAK-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Parvulescu updated OAK-4049: - Priority: Minor (was: Major) > Session mbean does not provide initStacktrace anymore > - > > Key: OAK-4049 > URL: https://issues.apache.org/jira/browse/OAK-4049 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Affects Versions: 1.3.16 >Reporter: Jörg Hoh >Priority: Minor > > I just checked the session statistics MBeans of a 1.3.16 instance and found, > that the property "InitStackTrace" is no longer populated. > This is different in the 1.0.x branch, where I can find the unformatted > stacktrace where this session has been created. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-3930) Sysview import of single valued mv property creates sv property
[ https://issues.apache.org/jira/browse/OAK-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-3930. - Resolution: Fixed Committed revision 1732170. > Sysview import of single valued mv property creates sv property > --- > > Key: OAK-3930 > URL: https://issues.apache.org/jira/browse/OAK-3930 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Affects Versions: 1.3.14 >Reporter: Tobias Bocanegra >Assignee: angela > Fix For: 1.3.17 > > > See test in filevault [0]. > it imports a multivalue property that only has 1 value, via [1]. the same > test succeeds in jackrabbit 2.0, but fails in oak 1.3.14 > [0] > https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.1.26/vault-core/src/test/java/org/apache/jackrabbit/vault/packaging/integration/TestUserContentPackage.java#L297-L326 > [1] > https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.1.26/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/JcrSysViewTransformer.java#L146-L148 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3234) LIRS cache: possible deadlock while loading an entry
[ https://issues.apache.org/jira/browse/OAK-3234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15163184#comment-15163184 ] Tomek Rękawek commented on OAK-3234: Thanks Alex, I didn't know this. For me (as a non-committer) preparing such patch aligned to the historic branches is all I can do :) > LIRS cache: possible deadlock while loading an entry > > > Key: OAK-3234 > URL: https://issues.apache.org/jira/browse/OAK-3234 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Labels: candidate_oak_1_0, candidate_oak_1_2 > Fix For: 1.3.4 > > Attachments: OAK-3234-backported.patch > > > If multiple threads concurrently load entries while they are already loading > entries (using a cache loader or callable), then it is possible to get into a > deadlock. For example: > * Thread 1 loads entry A, so it is calling the loader... > * Thread 2 loads entry B, so it is calling the loader... > * Thread 1 (within the loader) tries to load entry B, so it waits for thread > 2... > * Thread 2 (within the loader) tries to load entry A, so it waits for thread > 1... > One solution is to detect the case that the current thread is already loading > an entry, and then instead of waiting for the other thread, it can also load > the entry. A small optimization for that is to only load the entry (not > waiting for the other thread) if the hash code of the key is smaller or equal > the entry that this thread is loading. So that there is a clear order. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3228) Delayed visibility of new groups when using PrincipalManager
[
https://issues.apache.org/jira/browse/OAK-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15163182#comment-15163182
]
angela commented on OAK-3228:
-
committed the test-case revision 1732169.
> Delayed visibility of new groups when using PrincipalManager
> -
>
> Key: OAK-3228
> URL: https://issues.apache.org/jira/browse/OAK-3228
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.2.2
>Reporter: Georg Henzler
> Attachments: OAK-3228_testcase.patch
>
>
> PrincipalManager does not show groups that were just created (this is causing
> problems in our code). As workaround we use now
> UserManager.getAuthorizable().getPrincipal() which curiously works
> immediately after saving a group. Also it does not seem to be an index
> problem, as a query {{SELECT * FROM [rep:Authorizable] WHERE
> [rep:principalName] = "mygroup"}} also immediately shows a new group.
> See the following servlet snippet for easy reproduction:
> {code}
> ...
> @SlingServlet(paths = "/bin/CreateGroupAndRetrievePrincipal", methods = "GET")
> public class CreateGroupAndRetrievePrincipalServlet extends
> SlingSafeMethodsServlet {
> private static final long serialVersionUID = 1L;
> private static final Logger LOG =
> LoggerFactory.getLogger(CreateGroupAndRetrievePrincipalServlet.class);
> @Reference
> private SlingRepository repository;
> @Override
> @SuppressWarnings("deprecation")
> protected void doGet(final SlingHttpServletRequest request, final
> SlingHttpServletResponse response) throws ServletException,
> IOException {
> response.setContentType("text/plain");
> PrintWriter out = response.getWriter();
> final String groupName = request.getParameter("g");
> LOG.debug("test");
> Session session = null;
> try {
> session = repository.loginAdministrative(null);
> UserManager usermanager = ((JackrabbitSession)
> session).getUserManager();
> Group newGroup = usermanager.createGroup(new
> java.security.Principal() {
> @Override
> public String getName() {
> return groupName;
> }
> }, "principaltest");
> out.println("Created Group " + newGroup);
> session.save();
> } catch (Exception e) {
> throw new ServletException(e.getMessage(), e);
> } finally {
> if (session != null) {
> session.logout();
> session = null;
> }
> }
> out.println();
> try {
> session = repository.loginAdministrative(null);
> // No 1: PrincipalManager
> PrincipalManager principalManager = ((JackrabbitSession)
> session).getPrincipalManager();
> Principal principal = principalManager.getPrincipal(groupName);
> out.println("PrincipalManager: principal: " + principal);
> // No 2: UserManager
> UserManager usermanager = ((JackrabbitSession)
> session).getUserManager();
> Authorizable authorizable =
> usermanager.getAuthorizable(groupName);
> out.println("UserManager: authorizable: " + authorizable);
> // No 3: query
> QueryManager queryManager =
> session.getWorkspace().getQueryManager();
> final Query query = queryManager.createQuery("SELECT * FROM
> [rep:Authorizable] WHERE [rep:principalName] = \"" + groupName
> + "\"", Query.JCR_SQL2);
> QueryResult result = query.execute();
> NodeIterator nodes = result.getNodes();
> if (!nodes.hasNext()) {
> out.println("QUERY: group not found: " + groupName);
> }
> while (nodes.hasNext()) {
> Node resultNode = (Node) nodes.next();
> out.println("QUERY: node " + resultNode.getPath() + "
> property rep:principalName="
> +
> resultNode.getProperty("rep:principalName").getString());
> }
> query.execute();
> } catch (Exception e) {
> throw new ServletException(e.getMessage(), e);
> } finally {
> if (session != null) {
> session.logout();
> session = null;
> }
> }
> }
> }
> {code}
> returns (using AEM 6.1)
> {code}
> Created Group Group 'my-test-group'
> PrincipalManager: principal: null
> UserManager: authorizable: Group 'my-test-group'
> QUERY: node /home/groups/principaltest/qb2WDGrrC0q9bE8jaObH property
> rep:principalName=my-test-group
> {code}
> Potentially the problem is that the principal manager holds its own session
> (even though it was
[jira] [Updated] (OAK-4049) Session mbean does not provide initStacktrace anymore
[ https://issues.apache.org/jira/browse/OAK-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Parvulescu updated OAK-4049: - Issue Type: Improvement (was: Bug) > Session mbean does not provide initStacktrace anymore > - > > Key: OAK-4049 > URL: https://issues.apache.org/jira/browse/OAK-4049 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Affects Versions: 1.3.16 >Reporter: Jörg Hoh > > I just checked the session statistics MBeans of a 1.3.16 instance and found, > that the property "InitStackTrace" is no longer populated. > This is different in the 1.0.x branch, where I can find the unformatted > stacktrace where this session has been created. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4030) DocumentNodeStore: required server time accuracy
[ https://issues.apache.org/jira/browse/OAK-4030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Marth updated OAK-4030: --- Labels: resilience (was: ) > DocumentNodeStore: required server time accuracy > > > Key: OAK-4030 > URL: https://issues.apache.org/jira/browse/OAK-4030 > Project: Jackrabbit Oak > Issue Type: Bug > Components: documentmk >Reporter: Julian Reschke > Labels: resilience > Fix For: 1.4 > > > The DocumentNodeStore currently requires that the local time and the > persistence time differ at most 2 seconds. > I recently tried to run a cluster with two Windows machines, and despite them > being configured to use the same NTP service, they were still 4..5 s off. > https://blogs.technet.microsoft.com/askds/2007/10/23/high-accuracy-w32time-requirements/ > seems to confirm that by default, Windows can't provide the required > accuracy. > One workaround seems to be to install custom ntp clients; but do we really > want to require this? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4030) DocumentNodeStore: required server time accuracy
[ https://issues.apache.org/jira/browse/OAK-4030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Marth updated OAK-4030: --- Fix Version/s: 1.4 > DocumentNodeStore: required server time accuracy > > > Key: OAK-4030 > URL: https://issues.apache.org/jira/browse/OAK-4030 > Project: Jackrabbit Oak > Issue Type: Bug > Components: documentmk >Reporter: Julian Reschke > Labels: resilience > Fix For: 1.4 > > > The DocumentNodeStore currently requires that the local time and the > persistence time differ at most 2 seconds. > I recently tried to run a cluster with two Windows machines, and despite them > being configured to use the same NTP service, they were still 4..5 s off. > https://blogs.technet.microsoft.com/askds/2007/10/23/high-accuracy-w32time-requirements/ > seems to confirm that by default, Windows can't provide the required > accuracy. > One workaround seems to be to install custom ntp clients; but do we really > want to require this? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4043) Oak run checkpoints needs to account for multiple index lanes
[
https://issues.apache.org/jira/browse/OAK-4043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Marth updated OAK-4043:
---
Priority: Critical (was: Blocker)
> Oak run checkpoints needs to account for multiple index lanes
> -
>
> Key: OAK-4043
> URL: https://issues.apache.org/jira/browse/OAK-4043
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, run
>Reporter: Alex Parvulescu
>Priority: Critical
> Fix For: 1.4, 1.3.17
>
>
> Oak run {{checkpoints rm-unreferenced}} [0] currently is hardcoded on a
> single checkpoint reference (the default one). Now is it possible to add
> multiple lanes, which we already did in AEM, but the checkpoint tool is
> blissfully unaware of this and it might trigger a full reindex following
> offline compaction.
> This needs fixing before the big 1.4 release, so I'm marking it as a blocker.
> fyi [~edivad], [~chetanm]
> [0] https://github.com/apache/jackrabbit-oak/tree/trunk/oak-run#checkpoints
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-4039) The package o.a.j.o.query exposes multiple classes from unexported packages
[
https://issues.apache.org/jira/browse/OAK-4039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller reassigned OAK-4039:
---
Assignee: Thomas Mueller
> The package o.a.j.o.query exposes multiple classes from unexported packages
> ---
>
> Key: OAK-4039
> URL: https://issues.apache.org/jira/browse/OAK-4039
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: Francesco Mari
>Assignee: Thomas Mueller
> Fix For: 1.4
>
>
> Multiple exported classes in {{org.apache.jackrabbit.oak.query}} use in their
> public API other classes from unexported packages.
> {{org.apache.jackrabbit.oak.query.plan.SelectorExecutionPlan}},
> {{org.apache.jackrabbit.oak.query.index.FilterImpl}}, and multiple classes
> from {{org.apache.jackrabbit.oak.query.ast}} are used in the public APIs of
> many other classes from {{org.apache.jackrabbit.oak.query}} but they are not
> exported by their relative packages.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-4038) o.a.j.o.spi.query.Filter exposes unexported class o.a.j.o.query.ast.SelectorImpl
[
https://issues.apache.org/jira/browse/OAK-4038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller reassigned OAK-4038:
---
Assignee: Thomas Mueller
> o.a.j.o.spi.query.Filter exposes unexported class
> o.a.j.o.query.ast.SelectorImpl
>
>
> Key: OAK-4038
> URL: https://issues.apache.org/jira/browse/OAK-4038
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: Francesco Mari
>Assignee: Thomas Mueller
> Fix For: 1.4
>
>
> The interface {{o.a.j.o.spi.query.Filter}} uses in its public API the class
> {{o.a.j.o.query.ast.SelectorImpl}}, but while the former is contained in an
> exported package, the latter is not.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4049) Session mbean does not provide initStacktrace anymore
[ https://issues.apache.org/jira/browse/OAK-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15163106#comment-15163106 ] Jörg Hoh commented on OAK-4049: --- [~alex.parvulescu] Hah, haven't noticed, that lowering this value down to "1" has the very same effect. So only thing we could do is this adding a message (such as "set the system property "oak.sessionState.initStackTreshold=1 to get this information" as a comment in the property "initStackTrace", so it gets immediately obvious :-) > Session mbean does not provide initStacktrace anymore > - > > Key: OAK-4049 > URL: https://issues.apache.org/jira/browse/OAK-4049 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.3.16 >Reporter: Jörg Hoh > > I just checked the session statistics MBeans of a 1.3.16 instance and found, > that the property "InitStackTrace" is no longer populated. > This is different in the 1.0.x branch, where I can find the unformatted > stacktrace where this session has been created. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2065) JMX stats for operations being performed in DocumentNodeStore
[ https://issues.apache.org/jira/browse/OAK-2065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated OAK-2065: - Fix Version/s: (was: 1.4) 1.6 > JMX stats for operations being performed in DocumentNodeStore > - > > Key: OAK-2065 > URL: https://issues.apache.org/jira/browse/OAK-2065 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Labels: tooling > Fix For: 1.6 > > Attachments: > 0001-OAK-2065-JMX-stats-for-operations-being-performed-in.patch, > OAK-2065-1.patch > > > Currently DocumentStore performs various background operations like > # Cache consistency check > # Pushing the lastRev updates > # Synchrnizing the root node version > We should capture some stats like time taken in various task and expose them > over JMX to determine if those background operations are performing well or > not. For example its important that all tasks performed in background task > should be completed under 1 sec (default polling interval). If the time taken > increases then it would be cause of concern > See http://markmail.org/thread/57fax4nyabbubbef -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4038) o.a.j.o.spi.query.Filter exposes unexported class o.a.j.o.query.ast.SelectorImpl
[
https://issues.apache.org/jira/browse/OAK-4038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15163084#comment-15163084
]
Thomas Mueller commented on OAK-4038:
-
Yes, the method getSelector() should be removed. It was added for OAK-1965, but
OAK-1965 is no longer needed due to OAK-1617. It makes sense to remove
getSelector() now.
> o.a.j.o.spi.query.Filter exposes unexported class
> o.a.j.o.query.ast.SelectorImpl
>
>
> Key: OAK-4038
> URL: https://issues.apache.org/jira/browse/OAK-4038
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: Francesco Mari
> Fix For: 1.4
>
>
> The interface {{o.a.j.o.spi.query.Filter}} uses in its public API the class
> {{o.a.j.o.query.ast.SelectorImpl}}, but while the former is contained in an
> exported package, the latter is not.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3234) LIRS cache: possible deadlock while loading an entry
[
https://issues.apache.org/jira/browse/OAK-3234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15163065#comment-15163065
]
Alex Parvulescu commented on OAK-3234:
--
FWIW we don't usually apply backported patches on branches, we do {{svn merge}}
on the trunk commits so the svn history is clearer.
> LIRS cache: possible deadlock while loading an entry
>
>
> Key: OAK-3234
> URL: https://issues.apache.org/jira/browse/OAK-3234
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
> Labels: candidate_oak_1_0, candidate_oak_1_2
> Fix For: 1.3.4
>
> Attachments: OAK-3234-backported.patch
>
>
> If multiple threads concurrently load entries while they are already loading
> entries (using a cache loader or callable), then it is possible to get into a
> deadlock. For example:
> * Thread 1 loads entry A, so it is calling the loader...
> * Thread 2 loads entry B, so it is calling the loader...
> * Thread 1 (within the loader) tries to load entry B, so it waits for thread
> 2...
> * Thread 2 (within the loader) tries to load entry A, so it waits for thread
> 1...
> One solution is to detect the case that the current thread is already loading
> an entry, and then instead of waiting for the other thread, it can also load
> the entry. A small optimization for that is to only load the entry (not
> waiting for the other thread) if the hash code of the key is smaller or equal
> the entry that this thread is loading. So that there is a clear order.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3234) LIRS cache: possible deadlock while loading an entry
[ https://issues.apache.org/jira/browse/OAK-3234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Marth updated OAK-3234: --- Labels: candidate_oak_1_0 candidate_oak_1_2 (was: ) > LIRS cache: possible deadlock while loading an entry > > > Key: OAK-3234 > URL: https://issues.apache.org/jira/browse/OAK-3234 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Labels: candidate_oak_1_0, candidate_oak_1_2 > Fix For: 1.3.4 > > Attachments: OAK-3234-backported.patch > > > If multiple threads concurrently load entries while they are already loading > entries (using a cache loader or callable), then it is possible to get into a > deadlock. For example: > * Thread 1 loads entry A, so it is calling the loader... > * Thread 2 loads entry B, so it is calling the loader... > * Thread 1 (within the loader) tries to load entry B, so it waits for thread > 2... > * Thread 2 (within the loader) tries to load entry A, so it waits for thread > 1... > One solution is to detect the case that the current thread is already loading > an entry, and then instead of waiting for the other thread, it can also load > the entry. A small optimization for that is to only load the entry (not > waiting for the other thread) if the hash code of the key is smaller or equal > the entry that this thread is loading. So that there is a clear order. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4032) Performance issues on Oracle after introducing bulk updates
[
https://issues.apache.org/jira/browse/OAK-4032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-4032:
--
Fix Version/s: (was: 1.4)
1.3.17
> Performance issues on Oracle after introducing bulk updates
> ---
>
> Key: OAK-4032
> URL: https://issues.apache.org/jira/browse/OAK-4032
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: rdbmk
>Reporter: Tomek Rękawek
>Priority: Critical
> Fix For: 1.3.17
>
>
> OAK-2066 introduces bulk updates support for Mongo and RDB document stores.
> New feature is used in the {{Commit}} class to improve the performance. Due
> to bug OAK-3938, batch updates have been disabled for the Oracle DB - as a
> result, the bulk {{createOrUpdate()}} method applies changes sequentially on
> Oracle.
> However, after the OAK-3724, the Commit class sends all inserts using the new
> {{createOrUpdate()}} (rather than bulk {{create()}}, as it used to do). As a
> result, Oracle doesn't use bulk INSERTs anymore.
> Possible solutions:
> * check if OAK-4027 makes the new createOrUpdate() works on the Oracle. If
> so, require the new Oracle JDBC driver in the RDBDocumentStore.
> * improve the fallback createOrUpdate() to insert documents in bulk and
> update them sequentially.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-4032) Performance issues on Oracle after introducing bulk updates
[
https://issues.apache.org/jira/browse/OAK-4032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomek Rękawek resolved OAK-4032.
Resolution: Fixed
Fixed via OAK-4027.
> Performance issues on Oracle after introducing bulk updates
> ---
>
> Key: OAK-4032
> URL: https://issues.apache.org/jira/browse/OAK-4032
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: rdbmk
>Reporter: Tomek Rękawek
>Priority: Critical
> Fix For: 1.4
>
>
> OAK-2066 introduces bulk updates support for Mongo and RDB document stores.
> New feature is used in the {{Commit}} class to improve the performance. Due
> to bug OAK-3938, batch updates have been disabled for the Oracle DB - as a
> result, the bulk {{createOrUpdate()}} method applies changes sequentially on
> Oracle.
> However, after the OAK-3724, the Commit class sends all inserts using the new
> {{createOrUpdate()}} (rather than bulk {{create()}}, as it used to do). As a
> result, Oracle doesn't use bulk INSERTs anymore.
> Possible solutions:
> * check if OAK-4027 makes the new createOrUpdate() works on the Oracle. If
> so, require the new Oracle JDBC driver in the RDBDocumentStore.
> * improve the fallback createOrUpdate() to insert documents in bulk and
> update them sequentially.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-3234) LIRS cache: possible deadlock while loading an entry
[ https://issues.apache.org/jira/browse/OAK-3234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15163031#comment-15163031 ] Tomek Rękawek edited comment on OAK-3234 at 2/24/16 2:05 PM: - Attached patch backported for 1.0 and 1.2. [~tmueller], could you apply it? There are Oak 1.0 customers suffering from this deadlock. was (Author: tomek.rekawek): Attached patch backported for 1.0 and 1.2. > LIRS cache: possible deadlock while loading an entry > > > Key: OAK-3234 > URL: https://issues.apache.org/jira/browse/OAK-3234 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.3.4 > > Attachments: OAK-3234-backported.patch > > > If multiple threads concurrently load entries while they are already loading > entries (using a cache loader or callable), then it is possible to get into a > deadlock. For example: > * Thread 1 loads entry A, so it is calling the loader... > * Thread 2 loads entry B, so it is calling the loader... > * Thread 1 (within the loader) tries to load entry B, so it waits for thread > 2... > * Thread 2 (within the loader) tries to load entry A, so it waits for thread > 1... > One solution is to detect the case that the current thread is already loading > an entry, and then instead of waiting for the other thread, it can also load > the entry. A small optimization for that is to only load the entry (not > waiting for the other thread) if the hash code of the key is smaller or equal > the entry that this thread is loading. So that there is a clear order. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3234) LIRS cache: possible deadlock while loading an entry
[ https://issues.apache.org/jira/browse/OAK-3234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15163031#comment-15163031 ] Tomek Rękawek commented on OAK-3234: Attached patch backported for 1.0 and 1.2. > LIRS cache: possible deadlock while loading an entry > > > Key: OAK-3234 > URL: https://issues.apache.org/jira/browse/OAK-3234 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.3.4 > > Attachments: OAK-3234-backported.patch > > > If multiple threads concurrently load entries while they are already loading > entries (using a cache loader or callable), then it is possible to get into a > deadlock. For example: > * Thread 1 loads entry A, so it is calling the loader... > * Thread 2 loads entry B, so it is calling the loader... > * Thread 1 (within the loader) tries to load entry B, so it waits for thread > 2... > * Thread 2 (within the loader) tries to load entry A, so it waits for thread > 1... > One solution is to detect the case that the current thread is already loading > an entry, and then instead of waiting for the other thread, it can also load > the entry. A small optimization for that is to only load the entry (not > waiting for the other thread) if the hash code of the key is smaller or equal > the entry that this thread is loading. So that there is a clear order. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3234) LIRS cache: possible deadlock while loading an entry
[ https://issues.apache.org/jira/browse/OAK-3234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomek Rękawek updated OAK-3234: --- Attachment: OAK-3234-backported.patch > LIRS cache: possible deadlock while loading an entry > > > Key: OAK-3234 > URL: https://issues.apache.org/jira/browse/OAK-3234 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.3.4 > > Attachments: OAK-3234-backported.patch > > > If multiple threads concurrently load entries while they are already loading > entries (using a cache loader or callable), then it is possible to get into a > deadlock. For example: > * Thread 1 loads entry A, so it is calling the loader... > * Thread 2 loads entry B, so it is calling the loader... > * Thread 1 (within the loader) tries to load entry B, so it waits for thread > 2... > * Thread 2 (within the loader) tries to load entry A, so it waits for thread > 1... > One solution is to detect the case that the current thread is already loading > an entry, and then instead of waiting for the other thread, it can also load > the entry. A small optimization for that is to only load the entry (not > waiting for the other thread) if the hash code of the key is smaller or equal > the entry that this thread is loading. So that there is a clear order. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3228) Delayed visibility of new groups when using PrincipalManager
[
https://issues.apache.org/jira/browse/OAK-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15162985#comment-15162985
]
Konrad Windszus commented on OAK-3228:
--
Actually there is a session save in between, but nevertheless it is the same
session. I really tested with exactly that servlet which [~henzlerg] provided
above.
[~anchela] Were you able to perform the test you included in the patch also
successfully on the branch 1.2?
> Delayed visibility of new groups when using PrincipalManager
> -
>
> Key: OAK-3228
> URL: https://issues.apache.org/jira/browse/OAK-3228
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.2.2
>Reporter: Georg Henzler
> Attachments: OAK-3228_testcase.patch
>
>
> PrincipalManager does not show groups that were just created (this is causing
> problems in our code). As workaround we use now
> UserManager.getAuthorizable().getPrincipal() which curiously works
> immediately after saving a group. Also it does not seem to be an index
> problem, as a query {{SELECT * FROM [rep:Authorizable] WHERE
> [rep:principalName] = "mygroup"}} also immediately shows a new group.
> See the following servlet snippet for easy reproduction:
> {code}
> ...
> @SlingServlet(paths = "/bin/CreateGroupAndRetrievePrincipal", methods = "GET")
> public class CreateGroupAndRetrievePrincipalServlet extends
> SlingSafeMethodsServlet {
> private static final long serialVersionUID = 1L;
> private static final Logger LOG =
> LoggerFactory.getLogger(CreateGroupAndRetrievePrincipalServlet.class);
> @Reference
> private SlingRepository repository;
> @Override
> @SuppressWarnings("deprecation")
> protected void doGet(final SlingHttpServletRequest request, final
> SlingHttpServletResponse response) throws ServletException,
> IOException {
> response.setContentType("text/plain");
> PrintWriter out = response.getWriter();
> final String groupName = request.getParameter("g");
> LOG.debug("test");
> Session session = null;
> try {
> session = repository.loginAdministrative(null);
> UserManager usermanager = ((JackrabbitSession)
> session).getUserManager();
> Group newGroup = usermanager.createGroup(new
> java.security.Principal() {
> @Override
> public String getName() {
> return groupName;
> }
> }, "principaltest");
> out.println("Created Group " + newGroup);
> session.save();
> } catch (Exception e) {
> throw new ServletException(e.getMessage(), e);
> } finally {
> if (session != null) {
> session.logout();
> session = null;
> }
> }
> out.println();
> try {
> session = repository.loginAdministrative(null);
> // No 1: PrincipalManager
> PrincipalManager principalManager = ((JackrabbitSession)
> session).getPrincipalManager();
> Principal principal = principalManager.getPrincipal(groupName);
> out.println("PrincipalManager: principal: " + principal);
> // No 2: UserManager
> UserManager usermanager = ((JackrabbitSession)
> session).getUserManager();
> Authorizable authorizable =
> usermanager.getAuthorizable(groupName);
> out.println("UserManager: authorizable: " + authorizable);
> // No 3: query
> QueryManager queryManager =
> session.getWorkspace().getQueryManager();
> final Query query = queryManager.createQuery("SELECT * FROM
> [rep:Authorizable] WHERE [rep:principalName] = \"" + groupName
> + "\"", Query.JCR_SQL2);
> QueryResult result = query.execute();
> NodeIterator nodes = result.getNodes();
> if (!nodes.hasNext()) {
> out.println("QUERY: group not found: " + groupName);
> }
> while (nodes.hasNext()) {
> Node resultNode = (Node) nodes.next();
> out.println("QUERY: node " + resultNode.getPath() + "
> property rep:principalName="
> +
> resultNode.getProperty("rep:principalName").getString());
> }
> query.execute();
> } catch (Exception e) {
> throw new ServletException(e.getMessage(), e);
> } finally {
> if (session != null) {
> session.logout();
> session = null;
> }
> }
> }
> }
> {code}
> returns (using AEM 6.1)
> {code}
> Created Group Group 'my-test-group'
> PrincipalManager: principal: null
> UserManager:
[jira] [Resolved] (OAK-4053) DocumentDiscoveryLiteServiceTest fails occasionally
[ https://issues.apache.org/jira/browse/OAK-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-4053. --- Resolution: Fixed Fix Version/s: (was: 1.4) 1.3.17 Doubled the timeout to 4 seconds. The initial 2 seconds are rather tight. The least timeout is one second and the recovery thread runs twice a second. This only gives a margin of 500 ms. Fixed in trunk: http://svn.apache.org/r1732153 > DocumentDiscoveryLiteServiceTest fails occasionally > --- > > Key: OAK-4053 > URL: https://issues.apache.org/jira/browse/OAK-4053 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, documentmk >Affects Versions: 1.3.16 >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.3.17 > > > On travis: > https://travis-ci.org/apache/jackrabbit-oak/builds/111457047 > https://travis-ci.org/apache/jackrabbit-oak/builds/111256002 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-3228) Delayed visibility of new groups when using PrincipalManager
[
https://issues.apache.org/jira/browse/OAK-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15162979#comment-15162979
]
angela edited comment on OAK-3228 at 2/24/16 1:29 PM:
--
[~kwin], no unfortunately not. but if you say
{quote}
the group which was just being created in the same session
{quote}
this is something quite different than the sling-based test above illustrates.
the test in the description first saves the changes with session A and then
uses session B to retrieve the changes. my test-case reflects the latter... the
former case (same session without calling save) is expected to not work IMO
because the principal manager performs a query by principal name, which will
IMO should only find persisted data (but i am not a query expert)
anyway: if it was crucial to have the fixed in the 1.2 branch, we would need to
invest a bit more time to identify which exact modification changed the
behavior (may this wasn't even intended). from an Oak point of view it was
therefore crucial to have the exact steps on how to reproduce it with Oak
version xyz. Adobe AEM comes with a different configuration setup and different
query indices which might result in Oak issues being resolved works-for-me
though an issue is effectively present in the Adobe product.
was (Author: anchela):
[~kwin], no unfortunately not. but if you say
{quote}
the group which was just being created in the same session
{quote}
this is something quite different than the sling-based test above illustrates.
the test in the description first saves the changes with session A and then
uses session B to retrieve the changes. my test-case reflects the latter... the
former case (same session without calling save) is expected to not work IMO
because the principal manager performs a query by principal name, which will
IMO should only find persisted data (but i am not a query expert)
anyway: if it was crucial to have the fixed in the 1.2 branch, we would need to
invest a bit more time to identify which exact modification changed the
behavior (may this wasn't even intended). from an Oak point of view it was
therefore crucial to have a the exact steps on how to reproduce it with Oak
version xyz. Adobe AEM comes with a different configuration setup and different
query indices which might result in Oak issues being resolved works-for-me
though an issue is effectively present in the Adobe product.
> Delayed visibility of new groups when using PrincipalManager
> -
>
> Key: OAK-3228
> URL: https://issues.apache.org/jira/browse/OAK-3228
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.2.2
>Reporter: Georg Henzler
> Attachments: OAK-3228_testcase.patch
>
>
> PrincipalManager does not show groups that were just created (this is causing
> problems in our code). As workaround we use now
> UserManager.getAuthorizable().getPrincipal() which curiously works
> immediately after saving a group. Also it does not seem to be an index
> problem, as a query {{SELECT * FROM [rep:Authorizable] WHERE
> [rep:principalName] = "mygroup"}} also immediately shows a new group.
> See the following servlet snippet for easy reproduction:
> {code}
> ...
> @SlingServlet(paths = "/bin/CreateGroupAndRetrievePrincipal", methods = "GET")
> public class CreateGroupAndRetrievePrincipalServlet extends
> SlingSafeMethodsServlet {
> private static final long serialVersionUID = 1L;
> private static final Logger LOG =
> LoggerFactory.getLogger(CreateGroupAndRetrievePrincipalServlet.class);
> @Reference
> private SlingRepository repository;
> @Override
> @SuppressWarnings("deprecation")
> protected void doGet(final SlingHttpServletRequest request, final
> SlingHttpServletResponse response) throws ServletException,
> IOException {
> response.setContentType("text/plain");
> PrintWriter out = response.getWriter();
> final String groupName = request.getParameter("g");
> LOG.debug("test");
> Session session = null;
> try {
> session = repository.loginAdministrative(null);
> UserManager usermanager = ((JackrabbitSession)
> session).getUserManager();
> Group newGroup = usermanager.createGroup(new
> java.security.Principal() {
> @Override
> public String getName() {
> return groupName;
> }
> }, "principaltest");
> out.println("Created Group " + newGroup);
> session.save();
> } catch (Exception e) {
> throw new ServletException(e.getMessage(), e);
> } finally {
> if (session != null) {
> session.logout();
>
[jira] [Commented] (OAK-3228) Delayed visibility of new groups when using PrincipalManager
[
https://issues.apache.org/jira/browse/OAK-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15162979#comment-15162979
]
angela commented on OAK-3228:
-
[~kwin], no unfortunately not. but if you say
{quote}
the group which was just being created in the same session
{quote}
this is something quite different than the sling-based test above illustrates.
the test in the description first saves the changes with session A and then
uses session B to retrieve the changes. my test-case reflects the latter... the
former case (same session without calling save) is expected to not work IMO
because the principal manager performs a query by principal name, which will
IMO should only find persisted data (but i am not a query expert)
anyway: if it was crucial to have the fixed in the 1.2 branch, we would need to
invest a bit more time to identify which exact modification changed the
behavior (may this wasn't even intended). from an Oak point of view it was
therefore crucial to have a the exact steps on how to reproduce it with Oak
version xyz. Adobe AEM comes with a different configuration setup and different
query indices which might result in Oak issues being resolved works-for-me
though an issue is effectively present in the Adobe product.
> Delayed visibility of new groups when using PrincipalManager
> -
>
> Key: OAK-3228
> URL: https://issues.apache.org/jira/browse/OAK-3228
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.2.2
>Reporter: Georg Henzler
> Attachments: OAK-3228_testcase.patch
>
>
> PrincipalManager does not show groups that were just created (this is causing
> problems in our code). As workaround we use now
> UserManager.getAuthorizable().getPrincipal() which curiously works
> immediately after saving a group. Also it does not seem to be an index
> problem, as a query {{SELECT * FROM [rep:Authorizable] WHERE
> [rep:principalName] = "mygroup"}} also immediately shows a new group.
> See the following servlet snippet for easy reproduction:
> {code}
> ...
> @SlingServlet(paths = "/bin/CreateGroupAndRetrievePrincipal", methods = "GET")
> public class CreateGroupAndRetrievePrincipalServlet extends
> SlingSafeMethodsServlet {
> private static final long serialVersionUID = 1L;
> private static final Logger LOG =
> LoggerFactory.getLogger(CreateGroupAndRetrievePrincipalServlet.class);
> @Reference
> private SlingRepository repository;
> @Override
> @SuppressWarnings("deprecation")
> protected void doGet(final SlingHttpServletRequest request, final
> SlingHttpServletResponse response) throws ServletException,
> IOException {
> response.setContentType("text/plain");
> PrintWriter out = response.getWriter();
> final String groupName = request.getParameter("g");
> LOG.debug("test");
> Session session = null;
> try {
> session = repository.loginAdministrative(null);
> UserManager usermanager = ((JackrabbitSession)
> session).getUserManager();
> Group newGroup = usermanager.createGroup(new
> java.security.Principal() {
> @Override
> public String getName() {
> return groupName;
> }
> }, "principaltest");
> out.println("Created Group " + newGroup);
> session.save();
> } catch (Exception e) {
> throw new ServletException(e.getMessage(), e);
> } finally {
> if (session != null) {
> session.logout();
> session = null;
> }
> }
> out.println();
> try {
> session = repository.loginAdministrative(null);
> // No 1: PrincipalManager
> PrincipalManager principalManager = ((JackrabbitSession)
> session).getPrincipalManager();
> Principal principal = principalManager.getPrincipal(groupName);
> out.println("PrincipalManager: principal: " + principal);
> // No 2: UserManager
> UserManager usermanager = ((JackrabbitSession)
> session).getUserManager();
> Authorizable authorizable =
> usermanager.getAuthorizable(groupName);
> out.println("UserManager: authorizable: " + authorizable);
> // No 3: query
> QueryManager queryManager =
> session.getWorkspace().getQueryManager();
> final Query query = queryManager.createQuery("SELECT * FROM
> [rep:Authorizable] WHERE [rep:principalName] = \"" + groupName
> + "\"", Query.JCR_SQL2);
> QueryResult result = query.execute();
> NodeIterator nodes = result.getNodes();
> if (!nodes.hasNext()) {
>
[jira] [Assigned] (OAK-3930) Sysview import of single valued mv property creates sv property
[ https://issues.apache.org/jira/browse/OAK-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela reassigned OAK-3930: --- Assignee: angela > Sysview import of single valued mv property creates sv property > --- > > Key: OAK-3930 > URL: https://issues.apache.org/jira/browse/OAK-3930 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Affects Versions: 1.3.14 >Reporter: Tobias Bocanegra >Assignee: angela > Fix For: 1.3.17 > > > See test in filevault [0]. > it imports a multivalue property that only has 1 value, via [1]. the same > test succeeds in jackrabbit 2.0, but fails in oak 1.3.14 > [0] > https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.1.26/vault-core/src/test/java/org/apache/jackrabbit/vault/packaging/integration/TestUserContentPackage.java#L297-L326 > [1] > https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.1.26/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/JcrSysViewTransformer.java#L146-L148 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3930) Sysview import of single valued mv property creates sv property
[ https://issues.apache.org/jira/browse/OAK-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-3930: Fix Version/s: 1.3.17 > Sysview import of single valued mv property creates sv property > --- > > Key: OAK-3930 > URL: https://issues.apache.org/jira/browse/OAK-3930 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Affects Versions: 1.3.14 >Reporter: Tobias Bocanegra >Assignee: angela > Fix For: 1.3.17 > > > See test in filevault [0]. > it imports a multivalue property that only has 1 value, via [1]. the same > test succeeds in jackrabbit 2.0, but fails in oak 1.3.14 > [0] > https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.1.26/vault-core/src/test/java/org/apache/jackrabbit/vault/packaging/integration/TestUserContentPackage.java#L297-L326 > [1] > https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.1.26/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/JcrSysViewTransformer.java#L146-L148 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3930) Sysview import of single valued mv property creates sv property
[
https://issues.apache.org/jira/browse/OAK-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15162956#comment-15162956
]
angela commented on OAK-3930:
-
[~tripod], just had a quick look... IMO that's a plain bug in
{{SysViewImportHandler}} line 280: the {{PropInfo}} is created with passing the
{{currentPropMultipleStatus}} to the constructor. I will create test-cases
illustrating what I believe is the issue you reported and commit the fix if all
tests including ITs pass.
> Sysview import of single valued mv property creates sv property
> ---
>
> Key: OAK-3930
> URL: https://issues.apache.org/jira/browse/OAK-3930
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.3.14
>Reporter: Tobias Bocanegra
> Fix For: 1.3.17
>
>
> See test in filevault [0].
> it imports a multivalue property that only has 1 value, via [1]. the same
> test succeeds in jackrabbit 2.0, but fails in oak 1.3.14
> [0]
> https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.1.26/vault-core/src/test/java/org/apache/jackrabbit/vault/packaging/integration/TestUserContentPackage.java#L297-L326
> [1]
> https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.1.26/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/JcrSysViewTransformer.java#L146-L148
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-4053) DocumentDiscoveryLiteServiceTest fails occasionally
Marcel Reutegger created OAK-4053: - Summary: DocumentDiscoveryLiteServiceTest fails occasionally Key: OAK-4053 URL: https://issues.apache.org/jira/browse/OAK-4053 Project: Jackrabbit Oak Issue Type: Bug Components: core, documentmk Affects Versions: 1.3.16 Reporter: Marcel Reutegger Assignee: Marcel Reutegger Priority: Minor Fix For: 1.4 On travis: https://travis-ci.org/apache/jackrabbit-oak/builds/111457047 https://travis-ci.org/apache/jackrabbit-oak/builds/111256002 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-4052) NonLocalObservationIT fails occasionally
[ https://issues.apache.org/jira/browse/OAK-4052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-4052. --- Resolution: Fixed Fix Version/s: (was: 1.4) 1.3.17 Fixed in trunk: http://svn.apache.org/r1732139 The fix also replaces System.out calls with log.info(). > NonLocalObservationIT fails occasionally > > > Key: OAK-4052 > URL: https://issues.apache.org/jira/browse/OAK-4052 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, documentmk >Affects Versions: 1.3.16 >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.3.17 > > > On travis: > https://travis-ci.org/apache/jackrabbit-oak/builds/111341963 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4052) NonLocalObservationIT fails occasionally
[ https://issues.apache.org/jira/browse/OAK-4052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-4052: -- Priority: Minor (was: Major) > NonLocalObservationIT fails occasionally > > > Key: OAK-4052 > URL: https://issues.apache.org/jira/browse/OAK-4052 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, documentmk >Affects Versions: 1.3.16 >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.4 > > > On travis: > https://travis-ci.org/apache/jackrabbit-oak/builds/111341963 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4052) NonLocalObservationIT fails occasionally
Marcel Reutegger created OAK-4052: - Summary: NonLocalObservationIT fails occasionally Key: OAK-4052 URL: https://issues.apache.org/jira/browse/OAK-4052 Project: Jackrabbit Oak Issue Type: Bug Components: core, documentmk Affects Versions: 1.3.16 Reporter: Marcel Reutegger Assignee: Marcel Reutegger Fix For: 1.4 On travis: https://travis-ci.org/apache/jackrabbit-oak/builds/111341963 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4050) SplitOperations may not retain most recent committed _commitRoot entry
[ https://issues.apache.org/jira/browse/OAK-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-4050: -- Labels: candidate_oak_1_0 candidate_oak_1_2 (was: ) > SplitOperations may not retain most recent committed _commitRoot entry > -- > > Key: OAK-4050 > URL: https://issues.apache.org/jira/browse/OAK-4050 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, documentmk >Affects Versions: 1.0.21, 1.3.6, 1.2.6 >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Labels: candidate_oak_1_0, candidate_oak_1_2 > Fix For: 1.3.17 > > > In some rare cases it may happen that SplitOperations does not retain the > most recent committed _commitRoot entry on a document. This may result in an > undetected hierarchy conflict. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-4050) SplitOperations may not retain most recent committed _commitRoot entry
[ https://issues.apache.org/jira/browse/OAK-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-4050. --- Resolution: Fixed Fixed in trunk: http://svn.apache.org/r1732131 > SplitOperations may not retain most recent committed _commitRoot entry > -- > > Key: OAK-4050 > URL: https://issues.apache.org/jira/browse/OAK-4050 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, documentmk >Affects Versions: 1.0.21, 1.3.6, 1.2.6 >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Labels: candidate_oak_1_0, candidate_oak_1_2 > Fix For: 1.3.17 > > > In some rare cases it may happen that SplitOperations does not retain the > most recent committed _commitRoot entry on a document. This may result in an > undetected hierarchy conflict. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-3228) Delayed visibility of new groups when using PrincipalManager
[
https://issues.apache.org/jira/browse/OAK-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15162891#comment-15162891
]
Konrad Windszus edited comment on OAK-3228 at 2/24/16 12:23 PM:
I just tested again with the test servlet from above.
With AEM 6.2 (based on Oak 1.3.15) it does work but with AEM 6.1SP1 (based on
Oak 1.2.7) it doesn't (meaning the PrincipalManager will not immediately expose
the group which was just being created in the same session).
[~anchela] Do you have any idea which ticket was fixed in between, which could
have caused this behaviour?
was (Author: kwin):
I just tested again with the test servlet from above.
With AEM 6.2 (based on Oak 1.3.15) it does work but with AEM 6.1SP1 (based on
Oak 1.2.7) it doesn't (meaning the PrincipalManager will not immediately
exposed the just created group in the same session).
[~anchela] Do you have any idea which ticket was fixed in between, which could
have caused this behaviour?
> Delayed visibility of new groups when using PrincipalManager
> -
>
> Key: OAK-3228
> URL: https://issues.apache.org/jira/browse/OAK-3228
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.2.2
>Reporter: Georg Henzler
> Attachments: OAK-3228_testcase.patch
>
>
> PrincipalManager does not show groups that were just created (this is causing
> problems in our code). As workaround we use now
> UserManager.getAuthorizable().getPrincipal() which curiously works
> immediately after saving a group. Also it does not seem to be an index
> problem, as a query {{SELECT * FROM [rep:Authorizable] WHERE
> [rep:principalName] = "mygroup"}} also immediately shows a new group.
> See the following servlet snippet for easy reproduction:
> {code}
> ...
> @SlingServlet(paths = "/bin/CreateGroupAndRetrievePrincipal", methods = "GET")
> public class CreateGroupAndRetrievePrincipalServlet extends
> SlingSafeMethodsServlet {
> private static final long serialVersionUID = 1L;
> private static final Logger LOG =
> LoggerFactory.getLogger(CreateGroupAndRetrievePrincipalServlet.class);
> @Reference
> private SlingRepository repository;
> @Override
> @SuppressWarnings("deprecation")
> protected void doGet(final SlingHttpServletRequest request, final
> SlingHttpServletResponse response) throws ServletException,
> IOException {
> response.setContentType("text/plain");
> PrintWriter out = response.getWriter();
> final String groupName = request.getParameter("g");
> LOG.debug("test");
> Session session = null;
> try {
> session = repository.loginAdministrative(null);
> UserManager usermanager = ((JackrabbitSession)
> session).getUserManager();
> Group newGroup = usermanager.createGroup(new
> java.security.Principal() {
> @Override
> public String getName() {
> return groupName;
> }
> }, "principaltest");
> out.println("Created Group " + newGroup);
> session.save();
> } catch (Exception e) {
> throw new ServletException(e.getMessage(), e);
> } finally {
> if (session != null) {
> session.logout();
> session = null;
> }
> }
> out.println();
> try {
> session = repository.loginAdministrative(null);
> // No 1: PrincipalManager
> PrincipalManager principalManager = ((JackrabbitSession)
> session).getPrincipalManager();
> Principal principal = principalManager.getPrincipal(groupName);
> out.println("PrincipalManager: principal: " + principal);
> // No 2: UserManager
> UserManager usermanager = ((JackrabbitSession)
> session).getUserManager();
> Authorizable authorizable =
> usermanager.getAuthorizable(groupName);
> out.println("UserManager: authorizable: " + authorizable);
> // No 3: query
> QueryManager queryManager =
> session.getWorkspace().getQueryManager();
> final Query query = queryManager.createQuery("SELECT * FROM
> [rep:Authorizable] WHERE [rep:principalName] = \"" + groupName
> + "\"", Query.JCR_SQL2);
> QueryResult result = query.execute();
> NodeIterator nodes = result.getNodes();
> if (!nodes.hasNext()) {
> out.println("QUERY: group not found: " + groupName);
> }
> while (nodes.hasNext()) {
> Node resultNode = (Node) nodes.next();
> out.println("QUERY: node " + resultNode.getPath() + "
> property
[jira] [Commented] (OAK-3228) Delayed visibility of new groups when using PrincipalManager
[
https://issues.apache.org/jira/browse/OAK-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15162891#comment-15162891
]
Konrad Windszus commented on OAK-3228:
--
I just tested again with the test servlet from above.
With AEM 6.2 (based on Oak 1.3.15) it does work but with AEM 6.1SP1 (based on
Oak 1.2.7) it doesn't (meaning the PrincipalManager will not immediately
exposed the just created group in the same session).
[~anchela] Do you have any idea which ticket was fixed in between, which could
have caused this behaviour?
> Delayed visibility of new groups when using PrincipalManager
> -
>
> Key: OAK-3228
> URL: https://issues.apache.org/jira/browse/OAK-3228
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.2.2
>Reporter: Georg Henzler
> Attachments: OAK-3228_testcase.patch
>
>
> PrincipalManager does not show groups that were just created (this is causing
> problems in our code). As workaround we use now
> UserManager.getAuthorizable().getPrincipal() which curiously works
> immediately after saving a group. Also it does not seem to be an index
> problem, as a query {{SELECT * FROM [rep:Authorizable] WHERE
> [rep:principalName] = "mygroup"}} also immediately shows a new group.
> See the following servlet snippet for easy reproduction:
> {code}
> ...
> @SlingServlet(paths = "/bin/CreateGroupAndRetrievePrincipal", methods = "GET")
> public class CreateGroupAndRetrievePrincipalServlet extends
> SlingSafeMethodsServlet {
> private static final long serialVersionUID = 1L;
> private static final Logger LOG =
> LoggerFactory.getLogger(CreateGroupAndRetrievePrincipalServlet.class);
> @Reference
> private SlingRepository repository;
> @Override
> @SuppressWarnings("deprecation")
> protected void doGet(final SlingHttpServletRequest request, final
> SlingHttpServletResponse response) throws ServletException,
> IOException {
> response.setContentType("text/plain");
> PrintWriter out = response.getWriter();
> final String groupName = request.getParameter("g");
> LOG.debug("test");
> Session session = null;
> try {
> session = repository.loginAdministrative(null);
> UserManager usermanager = ((JackrabbitSession)
> session).getUserManager();
> Group newGroup = usermanager.createGroup(new
> java.security.Principal() {
> @Override
> public String getName() {
> return groupName;
> }
> }, "principaltest");
> out.println("Created Group " + newGroup);
> session.save();
> } catch (Exception e) {
> throw new ServletException(e.getMessage(), e);
> } finally {
> if (session != null) {
> session.logout();
> session = null;
> }
> }
> out.println();
> try {
> session = repository.loginAdministrative(null);
> // No 1: PrincipalManager
> PrincipalManager principalManager = ((JackrabbitSession)
> session).getPrincipalManager();
> Principal principal = principalManager.getPrincipal(groupName);
> out.println("PrincipalManager: principal: " + principal);
> // No 2: UserManager
> UserManager usermanager = ((JackrabbitSession)
> session).getUserManager();
> Authorizable authorizable =
> usermanager.getAuthorizable(groupName);
> out.println("UserManager: authorizable: " + authorizable);
> // No 3: query
> QueryManager queryManager =
> session.getWorkspace().getQueryManager();
> final Query query = queryManager.createQuery("SELECT * FROM
> [rep:Authorizable] WHERE [rep:principalName] = \"" + groupName
> + "\"", Query.JCR_SQL2);
> QueryResult result = query.execute();
> NodeIterator nodes = result.getNodes();
> if (!nodes.hasNext()) {
> out.println("QUERY: group not found: " + groupName);
> }
> while (nodes.hasNext()) {
> Node resultNode = (Node) nodes.next();
> out.println("QUERY: node " + resultNode.getPath() + "
> property rep:principalName="
> +
> resultNode.getProperty("rep:principalName").getString());
> }
> query.execute();
> } catch (Exception e) {
> throw new ServletException(e.getMessage(), e);
> } finally {
> if (session != null) {
> session.logout();
> session = null;
> }
> }
> }
> }
> {code}
> returns (using AEM 6.1)
>
[jira] [Resolved] (OAK-4025) Reuse ExecutorUtils to shutdown ExecutorService
[ https://issues.apache.org/jira/browse/OAK-4025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella resolved OAK-4025. --- Resolution: Fixed Fix Version/s: (was: 1.4) 1.3.17 In trunk at http://svn.apache.org/r1732072 > Reuse ExecutorUtils to shutdown ExecutorService > --- > > Key: OAK-4025 > URL: https://issues.apache.org/jira/browse/OAK-4025 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Affects Versions: 1.3.16 >Reporter: Davide Giannella >Assignee: Davide Giannella >Priority: Minor > Fix For: 1.3.17 > > Attachments: OAK-4025-1.patch > > > A utility class ExecutorUtils has been created in oak-commons. It provides a > convenience method for gracefully shutdown an ExecutorService. > For code clean-up reuse it in ExecutorCloser.java and > AtomicCounterEditorProvider.java. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-4051) NodeStateSolrServersObserverService won't activate even if enabled
[
https://issues.apache.org/jira/browse/OAK-4051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili resolved OAK-4051.
--
Resolution: Fixed
fixed in r1732055
> NodeStateSolrServersObserverService won't activate even if enabled
> --
>
> Key: OAK-4051
> URL: https://issues.apache.org/jira/browse/OAK-4051
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: solr
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: 1.3.17
>
>
> {{NodeStateSolrServersObserverService}} should only activate when _enabled_
> property is set to _true_ (it's _false_ by default), however even if that's
> enabled the property isn't correctly fetched and therefore the {{Observer}}
> service will never be started.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-4051) NodeStateSolrServersObserverService won't activate even if enabled
Tommaso Teofili created OAK-4051:
Summary: NodeStateSolrServersObserverService won't activate even
if enabled
Key: OAK-4051
URL: https://issues.apache.org/jira/browse/OAK-4051
Project: Jackrabbit Oak
Issue Type: Bug
Components: solr
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
Fix For: 1.3.17
{{NodeStateSolrServersObserverService}} should only activate when _enabled_
property is set to _true_ (it's _false_ by default), however even if that's
enabled the property isn't correctly fetched and therefore the {{Observer}}
service will never be started.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-4050) SplitOperations may not retain most recent committed _commitRoot entry
Marcel Reutegger created OAK-4050: - Summary: SplitOperations may not retain most recent committed _commitRoot entry Key: OAK-4050 URL: https://issues.apache.org/jira/browse/OAK-4050 Project: Jackrabbit Oak Issue Type: Bug Components: core, documentmk Affects Versions: 1.2.6, 1.3.6, 1.0.21 Reporter: Marcel Reutegger Assignee: Marcel Reutegger Fix For: 1.3.17 In some rare cases it may happen that SplitOperations does not retain the most recent committed _commitRoot entry on a document. This may result in an undetected hierarchy conflict. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4043) Oak run checkpoints needs to account for multiple index lanes
[
https://issues.apache.org/jira/browse/OAK-4043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15162718#comment-15162718
]
Davide Giannella commented on OAK-4043:
---
1.3.17 will be the last unstable cut that will then be the same as 1.4.0 and
branch. Added such revision.
> Oak run checkpoints needs to account for multiple index lanes
> -
>
> Key: OAK-4043
> URL: https://issues.apache.org/jira/browse/OAK-4043
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, run
>Reporter: Alex Parvulescu
>Priority: Blocker
> Fix For: 1.4, 1.3.17
>
>
> Oak run {{checkpoints rm-unreferenced}} [0] currently is hardcoded on a
> single checkpoint reference (the default one). Now is it possible to add
> multiple lanes, which we already did in AEM, but the checkpoint tool is
> blissfully unaware of this and it might trigger a full reindex following
> offline compaction.
> This needs fixing before the big 1.4 release, so I'm marking it as a blocker.
> fyi [~edivad], [~chetanm]
> [0] https://github.com/apache/jackrabbit-oak/tree/trunk/oak-run#checkpoints
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4043) Oak run checkpoints needs to account for multiple index lanes
[
https://issues.apache.org/jira/browse/OAK-4043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-4043:
--
Fix Version/s: 1.3.17
> Oak run checkpoints needs to account for multiple index lanes
> -
>
> Key: OAK-4043
> URL: https://issues.apache.org/jira/browse/OAK-4043
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, run
>Reporter: Alex Parvulescu
>Priority: Blocker
> Fix For: 1.4, 1.3.17
>
>
> Oak run {{checkpoints rm-unreferenced}} [0] currently is hardcoded on a
> single checkpoint reference (the default one). Now is it possible to add
> multiple lanes, which we already did in AEM, but the checkpoint tool is
> blissfully unaware of this and it might trigger a full reindex following
> offline compaction.
> This needs fixing before the big 1.4 release, so I'm marking it as a blocker.
> fyi [~edivad], [~chetanm]
> [0] https://github.com/apache/jackrabbit-oak/tree/trunk/oak-run#checkpoints
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4049) Session mbean does not provide initStacktrace anymore
[
https://issues.apache.org/jira/browse/OAK-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15162716#comment-15162716
]
Alex Parvulescu commented on OAK-4049:
--
bq. So a configuration option would be good to enable this feature again for
all sessions.
hmm, maybe I don't understand what you are asking for. you can use the system
property {{oak.sessionStats.initStackTraceThreshold}} (default at 1000) to
lower the threshold to whatever value you like. does this not help?
> Session mbean does not provide initStacktrace anymore
> -
>
> Key: OAK-4049
> URL: https://issues.apache.org/jira/browse/OAK-4049
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.3.16
>Reporter: Jörg Hoh
>
> I just checked the session statistics MBeans of a 1.3.16 instance and found,
> that the property "InitStackTrace" is no longer populated.
> This is different in the 1.0.x branch, where I can find the unformatted
> stacktrace where this session has been created.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3228) Delayed visibility of new groups when using PrincipalManager
[
https://issues.apache.org/jira/browse/OAK-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-3228:
Component/s: (was: core)
jcr
> Delayed visibility of new groups when using PrincipalManager
> -
>
> Key: OAK-3228
> URL: https://issues.apache.org/jira/browse/OAK-3228
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.2.2
>Reporter: Georg Henzler
> Attachments: OAK-3228_testcase.patch
>
>
> PrincipalManager does not show groups that were just created (this is causing
> problems in our code). As workaround we use now
> UserManager.getAuthorizable().getPrincipal() which curiously works
> immediately after saving a group. Also it does not seem to be an index
> problem, as a query {{SELECT * FROM [rep:Authorizable] WHERE
> [rep:principalName] = "mygroup"}} also immediately shows a new group.
> See the following servlet snippet for easy reproduction:
> {code}
> ...
> @SlingServlet(paths = "/bin/CreateGroupAndRetrievePrincipal", methods = "GET")
> public class CreateGroupAndRetrievePrincipalServlet extends
> SlingSafeMethodsServlet {
> private static final long serialVersionUID = 1L;
> private static final Logger LOG =
> LoggerFactory.getLogger(CreateGroupAndRetrievePrincipalServlet.class);
> @Reference
> private SlingRepository repository;
> @Override
> @SuppressWarnings("deprecation")
> protected void doGet(final SlingHttpServletRequest request, final
> SlingHttpServletResponse response) throws ServletException,
> IOException {
> response.setContentType("text/plain");
> PrintWriter out = response.getWriter();
> final String groupName = request.getParameter("g");
> LOG.debug("test");
> Session session = null;
> try {
> session = repository.loginAdministrative(null);
> UserManager usermanager = ((JackrabbitSession)
> session).getUserManager();
> Group newGroup = usermanager.createGroup(new
> java.security.Principal() {
> @Override
> public String getName() {
> return groupName;
> }
> }, "principaltest");
> out.println("Created Group " + newGroup);
> session.save();
> } catch (Exception e) {
> throw new ServletException(e.getMessage(), e);
> } finally {
> if (session != null) {
> session.logout();
> session = null;
> }
> }
> out.println();
> try {
> session = repository.loginAdministrative(null);
> // No 1: PrincipalManager
> PrincipalManager principalManager = ((JackrabbitSession)
> session).getPrincipalManager();
> Principal principal = principalManager.getPrincipal(groupName);
> out.println("PrincipalManager: principal: " + principal);
> // No 2: UserManager
> UserManager usermanager = ((JackrabbitSession)
> session).getUserManager();
> Authorizable authorizable =
> usermanager.getAuthorizable(groupName);
> out.println("UserManager: authorizable: " + authorizable);
> // No 3: query
> QueryManager queryManager =
> session.getWorkspace().getQueryManager();
> final Query query = queryManager.createQuery("SELECT * FROM
> [rep:Authorizable] WHERE [rep:principalName] = \"" + groupName
> + "\"", Query.JCR_SQL2);
> QueryResult result = query.execute();
> NodeIterator nodes = result.getNodes();
> if (!nodes.hasNext()) {
> out.println("QUERY: group not found: " + groupName);
> }
> while (nodes.hasNext()) {
> Node resultNode = (Node) nodes.next();
> out.println("QUERY: node " + resultNode.getPath() + "
> property rep:principalName="
> +
> resultNode.getProperty("rep:principalName").getString());
> }
> query.execute();
> } catch (Exception e) {
> throw new ServletException(e.getMessage(), e);
> } finally {
> if (session != null) {
> session.logout();
> session = null;
> }
> }
> }
> }
> {code}
> returns (using AEM 6.1)
> {code}
> Created Group Group 'my-test-group'
> PrincipalManager: principal: null
> UserManager: authorizable: Group 'my-test-group'
> QUERY: node /home/groups/principaltest/qb2WDGrrC0q9bE8jaObH property
> rep:principalName=my-test-group
> {code}
> Potentially the problem is that the principal manager holds its own session
> (even though it was retrieved by
[jira] [Updated] (OAK-3228) Delayed visibility of new groups when using PrincipalManager
[
https://issues.apache.org/jira/browse/OAK-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-3228:
Attachment: OAK-3228_testcase.patch
[~andreas.hal...@netcentric.biz], [~henzlerg], please note that neither
{{PrincipalManager}} nor {{PrincipalProvider}} holds it's _own_ session (or
root) as you state above. they are always bound to the editing JCR session (Oak
root) for which these objects have been created.
I tried to extract a test case reflecting the code you provided above (will
attach). Running that test on oak-trunk passes. My I ask you to verify that the
test matches your setup or provide a refined version that would allow me to
reproduce the issue you are experiencing?
> Delayed visibility of new groups when using PrincipalManager
> -
>
> Key: OAK-3228
> URL: https://issues.apache.org/jira/browse/OAK-3228
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.2.2
>Reporter: Georg Henzler
> Attachments: OAK-3228_testcase.patch
>
>
> PrincipalManager does not show groups that were just created (this is causing
> problems in our code). As workaround we use now
> UserManager.getAuthorizable().getPrincipal() which curiously works
> immediately after saving a group. Also it does not seem to be an index
> problem, as a query {{SELECT * FROM [rep:Authorizable] WHERE
> [rep:principalName] = "mygroup"}} also immediately shows a new group.
> See the following servlet snippet for easy reproduction:
> {code}
> ...
> @SlingServlet(paths = "/bin/CreateGroupAndRetrievePrincipal", methods = "GET")
> public class CreateGroupAndRetrievePrincipalServlet extends
> SlingSafeMethodsServlet {
> private static final long serialVersionUID = 1L;
> private static final Logger LOG =
> LoggerFactory.getLogger(CreateGroupAndRetrievePrincipalServlet.class);
> @Reference
> private SlingRepository repository;
> @Override
> @SuppressWarnings("deprecation")
> protected void doGet(final SlingHttpServletRequest request, final
> SlingHttpServletResponse response) throws ServletException,
> IOException {
> response.setContentType("text/plain");
> PrintWriter out = response.getWriter();
> final String groupName = request.getParameter("g");
> LOG.debug("test");
> Session session = null;
> try {
> session = repository.loginAdministrative(null);
> UserManager usermanager = ((JackrabbitSession)
> session).getUserManager();
> Group newGroup = usermanager.createGroup(new
> java.security.Principal() {
> @Override
> public String getName() {
> return groupName;
> }
> }, "principaltest");
> out.println("Created Group " + newGroup);
> session.save();
> } catch (Exception e) {
> throw new ServletException(e.getMessage(), e);
> } finally {
> if (session != null) {
> session.logout();
> session = null;
> }
> }
> out.println();
> try {
> session = repository.loginAdministrative(null);
> // No 1: PrincipalManager
> PrincipalManager principalManager = ((JackrabbitSession)
> session).getPrincipalManager();
> Principal principal = principalManager.getPrincipal(groupName);
> out.println("PrincipalManager: principal: " + principal);
> // No 2: UserManager
> UserManager usermanager = ((JackrabbitSession)
> session).getUserManager();
> Authorizable authorizable =
> usermanager.getAuthorizable(groupName);
> out.println("UserManager: authorizable: " + authorizable);
> // No 3: query
> QueryManager queryManager =
> session.getWorkspace().getQueryManager();
> final Query query = queryManager.createQuery("SELECT * FROM
> [rep:Authorizable] WHERE [rep:principalName] = \"" + groupName
> + "\"", Query.JCR_SQL2);
> QueryResult result = query.execute();
> NodeIterator nodes = result.getNodes();
> if (!nodes.hasNext()) {
> out.println("QUERY: group not found: " + groupName);
> }
> while (nodes.hasNext()) {
> Node resultNode = (Node) nodes.next();
> out.println("QUERY: node " + resultNode.getPath() + "
> property rep:principalName="
> +
> resultNode.getProperty("rep:principalName").getString());
> }
> query.execute();
> } catch (Exception e) {
> throw new ServletException(e.getMessage(), e);
> } finally {
> if
[jira] [Commented] (OAK-4049) Session mbean does not provide initStacktrace anymore
[ https://issues.apache.org/jira/browse/OAK-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15162680#comment-15162680 ] Jörg Hoh commented on OAK-4049: --- I do understand the performance reason, but for me it was always a good way to detect and analyze long-running sessions. So a configuration option would be good to enable this feature again for all sessions. > Session mbean does not provide initStacktrace anymore > - > > Key: OAK-4049 > URL: https://issues.apache.org/jira/browse/OAK-4049 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.3.16 >Reporter: Jörg Hoh > > I just checked the session statistics MBeans of a 1.3.16 instance and found, > that the property "InitStackTrace" is no longer populated. > This is different in the 1.0.x branch, where I can find the unformatted > stacktrace where this session has been created. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4049) Session mbean does not provide initStacktrace anymore
[ https://issues.apache.org/jira/browse/OAK-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15162674#comment-15162674 ] Alex Parvulescu commented on OAK-4049: -- I think this was disabled for perf reasons, see OAK-3153 and [0] [0] https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/session/SessionStats.java#L53 > Session mbean does not provide initStacktrace anymore > - > > Key: OAK-4049 > URL: https://issues.apache.org/jira/browse/OAK-4049 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.3.16 >Reporter: Jörg Hoh > > I just checked the session statistics MBeans of a 1.3.16 instance and found, > that the property "InitStackTrace" is no longer populated. > This is different in the 1.0.x branch, where I can find the unformatted > stacktrace where this session has been created. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-1891) Regression: non-space whitespace not allowed in item names
[ https://issues.apache.org/jira/browse/OAK-1891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-1891. - Resolution: Not A Problem resolving as suggested by [~reschke] > Regression: non-space whitespace not allowed in item names > -- > > Key: OAK-1891 > URL: https://issues.apache.org/jira/browse/OAK-1891 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.0 >Reporter: Tobias Bocanegra > > item names with a non-space whitespace are not allowed anymore in oak. > https://github.com/apache/jackrabbit-oak/blob/1.0/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/name/Namespaces.java#L252 > this used to work in jackrabbit and can be a problem for customers trying to > migrate old content. also upgrading existing content might result in > unexpected results. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4049) Session mbean does not provide initStacktrace anymore
Jörg Hoh created OAK-4049: - Summary: Session mbean does not provide initStacktrace anymore Key: OAK-4049 URL: https://issues.apache.org/jira/browse/OAK-4049 Project: Jackrabbit Oak Issue Type: Bug Components: core Affects Versions: 1.3.16 Reporter: Jörg Hoh I just checked the session statistics MBeans of a 1.3.16 instance and found, that the property "InitStackTrace" is no longer populated. This is different in the 1.0.x branch, where I can find the unformatted stacktrace where this session has been created. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
