[jira] [Updated] (OAK-1163) Observation events should respect permissions
[
https://issues.apache.org/jira/browse/OAK-1163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-1163:
Summary: Observation events should respect permissions (was: ACL
evaluation for observation events)
Observation events should respect permissions
-
Key: OAK-1163
URL: https://issues.apache.org/jira/browse/OAK-1163
Project: Jackrabbit Oak
Issue Type: New Feature
Components: core, jcr, security
Reporter: Alexander Klimetschek
The JCR observation implementation in Oak does not evaluate ACLs yet, so any
session currently sees all events. {{SecureValidator}} is the intended place
to do the checks.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (OAK-1165) Too frequent document splits
Marcel Reutegger created OAK-1165: - Summary: Too frequent document splits Key: OAK-1165 URL: https://issues.apache.org/jira/browse/OAK-1165 Project: Jackrabbit Oak Issue Type: Bug Components: core, mongomk Affects Versions: 0.10 Reporter: Marcel Reutegger Assignee: Marcel Reutegger After a while MongoNodeStore/MK starts to split larger documents too frequently. There should be an additional check to ensure the split off document has a minimum size. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-1156) Improve the document cache invalidation logic to selectivly invalidate doc
[
https://issues.apache.org/jira/browse/OAK-1156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-1156:
--
Summary: Improve the document cache invalidation logic to selectivly
invalidate doc (was: Improve the document cache invalidation logic to
selectivly ivalidate doc)
Improve the document cache invalidation logic to selectivly invalidate doc
--
Key: OAK-1156
URL: https://issues.apache.org/jira/browse/OAK-1156
Project: Jackrabbit Oak
Issue Type: Improvement
Components: mongomk
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Currently the Background Read operation invalidates the complete cache in
{{MongoNodeStore}} upon detecting external change. Instead of that it should
check for which cached documents are stale and only invalidate them.
It can make use of {{_lastRev}} to check if nodes within a subtree have
changed or not.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (OAK-1165) Too frequent document splits
[ https://issues.apache.org/jira/browse/OAK-1165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-1165. --- Resolution: Fixed Fix Version/s: 0.11 Fixed in http://svn.apache.org/r1540650 Too frequent document splits Key: OAK-1165 URL: https://issues.apache.org/jira/browse/OAK-1165 Project: Jackrabbit Oak Issue Type: Bug Components: core, mongomk Affects Versions: 0.10 Reporter: Marcel Reutegger Assignee: Marcel Reutegger Fix For: 0.11 After a while MongoNodeStore/MK starts to split larger documents too frequently. There should be an additional check to ensure the split off document has a minimum size. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (OAK-619) Lock-free MongoMK implementation
[ https://issues.apache.org/jira/browse/OAK-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-619. -- Resolution: Fixed I think this can be resolved now. The lock-free implementation is there and tests run with the MongoMK. There are still various open issues around the MongoMK, but it's better to track them separately. Lock-free MongoMK implementation Key: OAK-619 URL: https://issues.apache.org/jira/browse/OAK-619 Project: Jackrabbit Oak Issue Type: Bug Components: mongomk Reporter: Thomas Mueller Assignee: Thomas Mueller Fix For: 0.11 The current MongoMK implementation has some disadvantages we would like to address: - some of the collections can't be sharded easily - instances synchronize on the sync collection - concurrent changes to the same node are detected relatively late, and merging them requires a re-try To address those issues, we will write a prototype of a MongoMK implementation that uses a different storage model, that is, only one nodes collection. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-1133) Observation listener PLUS
[
https://issues.apache.org/jira/browse/OAK-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-1133:
---
Fix Version/s: 0.12
Observation listener PLUS
-
Key: OAK-1133
URL: https://issues.apache.org/jira/browse/OAK-1133
Project: Jackrabbit Oak
Issue Type: New Feature
Components: commons, jcr
Reporter: Alexander Klimetschek
Labels: performance
Fix For: 0.12
Oak should provide an *extended and efficient JCR observation listener*
mechanism to support common use cases not handled well by the restricted
options of the JCR observation (only base path, node types and raw events).
Those cases require listeners to register much more broadly and then filter
out their specific cases themselves, thus putting too many events into the
observation system and creating a huge overhead due to asynchronous access to
the modified JCR data to do the filtering. This easily is a big performance
bottleneck with many writes and thus many events.
Previous discussions [on the
list|http://markmail.org/message/oyq7fnfrveceemoh] and in OAK-1120, and
[latest discussion on the list|http://markmail.org/message/x2l6tv4m7bxjzqqq].
The goals should be:
* performance: handle filtering as early as possible, during the commit,
where access to the modified data is already present
* provide robust implementation for typical filtering cases
* provide an asynchronous listener mechanism as in JCR
* minimize effect on the lower levels on Oak (a visible addition in
oak-commons or oak-jcr should be enough)
* for delete events, allow filtering on the to-be-deleted data (currently not
possible in jcr listeners that run after the fact)
* ignore external cluster events by default; have an extra option if you
really want to register for external events
* if possible: design as an extension of the jcr observation to simplify
migration for existing code
* if possible: provide an intelligent listener that can work with pure JCR
(aka Jackrabbit 2) as well, by falling back to in-listener-filtering
* maybe: synchronous option using the same simple interface (instead of raw
Oak plugins itself); however, not sure if there is a benefit if they can only
read data and not change or block the session commit
Typical filtering cases:
- paths with globbing support (for example /content/foo/*/something)
- check for property values (equal, not equal, contains etc.), most
importantly
sling:resourceType in Sling apps
- allow to check properties on child nodes as well, typically jcr:content
- check for any parent/ancestor as well (e.g. change deep inside a node type
= foo structure should be triggered, even if the node with the type wasn't
modified; very important to support efficiently)
- node types (already in jcr observation)
- created/modified/deleted events, separate from move/copy
- and more... a custom filter should be possible to pass through (with
similar access as the {{Observer}})
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (OAK-91) Implement Authentication Support
[ https://issues.apache.org/jira/browse/OAK-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-91. --- Resolution: Fixed Fix Version/s: (was: 0.13) 0.11 resolving issue. the general authentication support can be considered completed. open authentication related issues or extensions are - OAK-608 (pluggable setup - subtask of pluggable security setup) - OAK-516 (LDAP login) Implement Authentication Support Key: OAK-91 URL: https://issues.apache.org/jira/browse/OAK-91 Project: Jackrabbit Oak Issue Type: Task Components: core, jcr Reporter: angela Assignee: angela Fix For: 0.11 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-1114) Clarify NodeBuilder.moveTo() contract
[
https://issues.apache.org/jira/browse/OAK-1114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-1114:
---
Fix Version/s: (was: 0.13)
0.12
Clarify NodeBuilder.moveTo() contract
-
Key: OAK-1114
URL: https://issues.apache.org/jira/browse/OAK-1114
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core
Reporter: Michael Dürig
Assignee: Michael Dürig
Fix For: 0.12
{{NodeBuilder.moveTo()}} currently behaves differently depending on the
implementation. We should rectify that, clarify the contract and add
respective unit tests.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (OAK-951) Consider implementing regular access control operations for ReadPolicy
[ https://issues.apache.org/jira/browse/OAK-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-951: --- Summary: Consider implementing regular access control operations for ReadPolicy (was: Implement regular access control operations for ReadPolicy) Consider implementing regular access control operations for ReadPolicy -- Key: OAK-951 URL: https://issues.apache.org/jira/browse/OAK-951 Project: Jackrabbit Oak Issue Type: Improvement Components: core Reporter: angela Fix For: 0.15 currently the new ReadPolicy are defined by the permission configuration and cannot be managed using regular access control management operations such as getApplicablePolicies, setPolicy, removePolicy. the current code should be refactored such that not only getPolicies/getEffectivePolicies support that specific policy type. the configuration may still be used for the original setup but subsequent management should be possible with the regular ac mgt api. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-1124) OAK-938 incomplete: session refresh must also be reflected on derived interfaces
[ https://issues.apache.org/jira/browse/OAK-1124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-1124: --- Fix Version/s: (was: 0.14) 0.13 OAK-938 incomplete: session refresh must also be reflected on derived interfaces Key: OAK-1124 URL: https://issues.apache.org/jira/browse/OAK-1124 Project: Jackrabbit Oak Issue Type: Bug Components: jcr Reporter: angela Assignee: Michael Dürig Fix For: 0.13 OAK-938 only wraps the UserManager; what is required in order to fully reflect the refresh was to also wrap: - Authorizable - User - Group - Impersonation -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (OAK-951) Consider implementing regular access control operations for ReadPolicy
[ https://issues.apache.org/jira/browse/OAK-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela reassigned OAK-951: -- Assignee: angela Consider implementing regular access control operations for ReadPolicy -- Key: OAK-951 URL: https://issues.apache.org/jira/browse/OAK-951 Project: Jackrabbit Oak Issue Type: Improvement Components: core Reporter: angela Assignee: angela Fix For: 0.15 currently the new ReadPolicy are defined by the permission configuration and cannot be managed using regular access control management operations such as getApplicablePolicies, setPolicy, removePolicy. the current code should be refactored such that not only getPolicies/getEffectivePolicies support that specific policy type. the configuration may still be used for the original setup but subsequent management should be possible with the regular ac mgt api. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (OAK-951) Consider implementing regular access control operations for ReadPolicy
[ https://issues.apache.org/jira/browse/OAK-951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13818852#comment-13818852 ] angela commented on OAK-951: while implementing this doesn't have too much priority IMO, it can be looked as a POC for implementing custom policies such as e.g. being used for providing closed user group setup - moving this to a separate issue in order not to block resolution of the general implement access control management task. Consider implementing regular access control operations for ReadPolicy -- Key: OAK-951 URL: https://issues.apache.org/jira/browse/OAK-951 Project: Jackrabbit Oak Issue Type: Improvement Components: core Reporter: angela Assignee: angela Fix For: 0.15 currently the new ReadPolicy are defined by the permission configuration and cannot be managed using regular access control management operations such as getApplicablePolicies, setPolicy, removePolicy. the current code should be refactored such that not only getPolicies/getEffectivePolicies support that specific policy type. the configuration may still be used for the original setup but subsequent management should be possible with the regular ac mgt api. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (OAK-1156) Improve the document cache invalidation logic to selectivly invalidate doc
[
https://issues.apache.org/jira/browse/OAK-1156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13818854#comment-13818854
]
Chetan Mehrotra commented on OAK-1156:
--
There are multiple approaches possible
*Approach A*
# Find the {{_modCount}} for all the cached documents using Mongo In query
# Then invalidate those entries where the Mod count differs
Approach A is more like brute force and might take quite a bit of time if the
number of cached entries are quite high
*Approach B*
# Create a tree structure out of the paths of the cached documents
# Start traversing the tree in breadth first mode and fetch the {{_lastRev}}
data for the nodes at same level
# If the last revision is same as the one in the cached document then in some
cases it can be considered that all nodes under that path have not been
modified. So we mark such cached documents as up-to-date and filter them out
from the traversal
In this approach we can save on lots of queries as in most cases the major
portion of tree might not have got changed. However we need to be carefull to
not to leave any stale entry in the cache. For example when ever we add a new
document to cache say at path {{/foo/bar}} it would have latest {{_lastRev}}
entry. However the already cached doc under that path would not be check in
that flow. So in above flow we might falsefully consider that tree under
{{/foo/bar}} is consistent and thus hold a stale copy
Improve the document cache invalidation logic to selectivly invalidate doc
--
Key: OAK-1156
URL: https://issues.apache.org/jira/browse/OAK-1156
Project: Jackrabbit Oak
Issue Type: Improvement
Components: mongomk
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Currently the Background Read operation invalidates the complete cache in
{{MongoNodeStore}} upon detecting external change. Instead of that it should
check for which cached documents are stale and only invalidate them.
It can make use of {{_lastRev}} to check if nodes within a subtree have
changed or not.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (OAK-792) AccessControl Management: Document changes wrt. Jackrabbit
[
https://issues.apache.org/jira/browse/OAK-792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13718362#comment-13718362
]
angela edited comment on OAK-792 at 11/11/13 11:06 AM:
---
h4. 1. Characteristics of the Default Implementation
h5. General
In general the authorization related code in OAK clearly separates between
access control management (such as defined by the JCR and Jackrabbit API) and
the internal permission evaluation (see also OAK-942).
The default implementation of the access control management corresponds to the
resource-based implementation present with Jackrabbit 2.x. The former
principal-base access control management is no longer available but it's
functionality has been incorporated both in the default ac management
implementation and the permission evaluation.
h5. JCR API
h6. AccessControlManager#hasPrivilege and #getPrivileges
As of OAK those methods throw {{PathNotFoundException}} if the corresponding
node is not accessible by the editing session. This is in accordance with the
behavior mandated by JSR 283 and a bug in Jackrabbit 2.x.
h6. AccessControlManager#getEffectivePolicies
In contrast to Jackrabbit 2.x the editing session is used to retrieve the
effective policies and the policies returned by these methods are guarantueed
to only return information that is otherwise accessible by the session. The
corresponding methods in Jackrabbit 2.x use to throw an exception in this
situation.
h6. AccessControlPolicy
OAK introduces a new type of policy that enforces regular read-access for
everyone on the trees that hold this new {{ReadPolicy}} [0]. The main usage of
this new policy is to ensure backwards compatible behavior of repository level
information (node types, namespace, privileges) that are now kept within the
content repository. In Jackrabbit 2.x this information was stored in the file
system without the ability to apply or enforce regular access control such as
present with items in the repository.
Currently these special read policies are defined as part of the overall
security configuration and cannot be managed/edited using regular access
control management API (see OAK-951).
h6. AccessControlEntry
Validation: as of OAK the implementation of the {{AccessControlEntry}}
interface is no longer in charge of validating the specified privileges. While
some validation is still performed in the corresponding {{AccessControlList}}
methods, the complete validation is delegated to the commit phase and executed
by a specific {{Validator}} implementation.
Restrictions: as of OAK the optional restrictions present with a given
{{JackrabbitAccessControlEntry}} can be multivalued (see below).
h5. Jackrabbit API
h6. Principal-based Access Control
The principal-based access control management as present in Jackrabbit-core is
no longer present with OAK. The main benefit of the principal-based approach
has been incorporated with the changes in the default permission evaluation
(see OAK-942). In addition the default access control manager implementation
supports all methods defined by {{JackrabbitAccessControlManager}}; i.e.
editing access control information by principal is possible as long as the
editing session has sufficient permission on the target node(s). Similarly, the
per principal policies exposed to a given session will always respect that
access rights of that session.
h6. Restrictions
The implementation of the additional restrictions associated with an ACE has
been modified/extended as follows:
* Separate restriction management API (see below) on the OAK level that allows
to ease plugging custom restrictions.
* Changed node type definition for storing restrictions in the default
implementation.
** as of OAK restrictions are collected underneath a separate child node
rep:restrictions
** restrictions can be multi-valued (see JCR-3637, JCR-3641)
** backwards compatible behavior for restrictions stored underneath the ACE
node directly
* New restrictions:
** rep:ntNames, which allows to limit the affected ACE to nodes of the
specified node type(s)
** rep:prefixes, which allows to limit the effect to item names that have a
specific namespace prefix.
h4. 2. Node Types
As mentioned above the node type definitions have been extended to match the
new functionality related to restrictions.
The node type definition for access control entries:
{code}
[rep:ACE]
- rep:principalName (STRING) protected mandatory
- rep:privileges (NAME) protected mandatory multiple
- rep:nodePath (PATH) protected /* deprecated in favor of restrictions */
- rep:glob (STRING) protected /* deprecated in favor of restrictions */
- * (UNDEFINED) protected /* deprecated in favor of restrictions */
+ rep:restrictions (rep:Restrictions) = rep:Restrictions protected
{code}
The new node type definition for restrictions:
{code}
/**
* @since oak 1.0
[jira] [Resolved] (OAK-792) AccessControl Management: Document changes wrt. Jackrabbit
[ https://issues.apache.org/jira/browse/OAK-792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-792. Resolution: Fixed Fix Version/s: (was: 0.12) 0.11 AccessControl Management: Document changes wrt. Jackrabbit -- Key: OAK-792 URL: https://issues.apache.org/jira/browse/OAK-792 Project: Jackrabbit Oak Issue Type: Sub-task Components: jcr Reporter: angela Assignee: angela Fix For: 0.11 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-791) UserManagement: Document changes wrt Jackrabbit 2
[ https://issues.apache.org/jira/browse/OAK-791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-791: --- Fix Version/s: (was: 0.12) 0.15 UserManagement: Document changes wrt Jackrabbit 2 - Key: OAK-791 URL: https://issues.apache.org/jira/browse/OAK-791 Project: Jackrabbit Oak Issue Type: Sub-task Components: jcr Reporter: angela Assignee: angela Fix For: 0.15 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (OAK-1058) Review TreeTypeProvider
[ https://issues.apache.org/jira/browse/OAK-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-1058. - Resolution: Fixed Fix Version/s: 0.11 Review TreeTypeProvider --- Key: OAK-1058 URL: https://issues.apache.org/jira/browse/OAK-1058 Project: Jackrabbit Oak Issue Type: Improvement Components: core Reporter: angela Priority: Minor Fix For: 0.11 reminder to review and possibly refactor the tree type provider. this part of the core-package is still marked with TODOs and we should clean it up before releasing oak. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (OAK-905) Performance issue with xml import
[ https://issues.apache.org/jira/browse/OAK-905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-905. Resolution: Duplicate Performance issue with xml import - Key: OAK-905 URL: https://issues.apache.org/jira/browse/OAK-905 Project: Jackrabbit Oak Issue Type: Bug Components: jcr Reporter: angela while playing around with the various access controlled related benchmarks from jackrabbit core, it shows that importing a huge content tree using xml-import is much slower on oak that it was on jackrabbit. initial numbers from the setup of the ReadDeepTreeTest which just reports how many ms it took to import the huge (deep) tree: jackrabbit:31464 ms oak-default: 515106 ms oak-tar: 503543 ms i therefore decided to extract that import to a separate test class and commited org.apache.jackrabbit.oak.benchmark.XmlImportTest, which just imports the xml file during runTest() at revision 1503739. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (OAK-1143) [scala] Repository init throws illegal cyclic reference involving class ChangeDispatcher
[
https://issues.apache.org/jira/browse/OAK-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13818917#comment-13818917
]
Michael Dürig commented on OAK-1143:
At http://svn.apache.org/r1540692 I went ahead and removed the {{NodeStore}}
dependency from {{ChangeDispatcher}} along with the {{getExternalChanges()}}
call, which polled the node store for cluster external changes. Latter call was
prone to deadlocks anyhow due its reverse direction of information flow (i.e.
poll instead of push). As a result passive cluster nodes will currently not
be notified about cluster external changes.
Overall this paves the way of implementing/replacing {{ChangeDispatcher}} with
the new generic {{Obserer}} implementations.
[scala] Repository init throws illegal cyclic reference involving class
ChangeDispatcher
--
Key: OAK-1143
URL: https://issues.apache.org/jira/browse/OAK-1143
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: Alex Parvulescu
Priority: Minor
I've been playing with Oak on Scala a bit and it looks like the latest
changes introduced a problem that makes Oak unusable.
Basically trying to setup a repo throws the following error:
{noformat}
OakRepository.scala:65: error: illegal cyclic reference involving class
ChangeDispatcher
[ERROR] new Oak(new SegmentNodeStore(new FileStore(new File(fname),
268435456, true)))
[ERROR] ^
[ERROR] one error found
{noformat}
I've simplified the code down to the most basic barebone repo init to make it
easier to digest [0].
This is a Scala bug, but my point is that this used to work prior to the
changedispacher changes, so I'm thinking we could move some bits around to
get it working from Scala again.
[0]
https://github.com/alexparvulescu/soak/blob/master/src/main/scala/com/pfalabs/soak/OakRepository.scala#L65
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (OAK-820) Add ContentSession#isLive()
[ https://issues.apache.org/jira/browse/OAK-820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-820. Resolution: Later Add ContentSession#isLive() --- Key: OAK-820 URL: https://issues.apache.org/jira/browse/OAK-820 Project: Jackrabbit Oak Issue Type: Improvement Components: core Reporter: angela Priority: Minor Attachments: OAK-820.patch for consistency with ContentSession#close() and in order to be able to address a remaining TODO in the user manager implementation i would like to add ContentSession#isLive. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (OAK-739) Asymmetric equals() implementation in AccessControlManagerImpl's nested classes PrincipalACL / NodeACL
[
https://issues.apache.org/jira/browse/OAK-739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-739.
Resolution: Cannot Reproduce
seems that this has been addressed in the mean time
Asymmetric equals() implementation in AccessControlManagerImpl's nested
classes PrincipalACL / NodeACL
--
Key: OAK-739
URL: https://issues.apache.org/jira/browse/OAK-739
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Affects Versions: 0.7
Reporter: Lukas Eder
Priority: Minor
I was digging in the Oak code and I've stumbled upon an assymetric equals()
implementation between the following two nested classes:
- AccessControlManagerImpl.PrincipalACL
- AccessControlManagerImpl.NodeACL
Assume the following:
{code}
PrincipalACL p = ...
NodeACL n = ...
assertTrue(n.equals(p));
assertFalse(p.equals(n));
{code}
Since PrincipalACL.equals() looks almost the same as NodeACL.equals() except
for the instanceof check, I suggest removing the override, or delegating to
super.equals() instead of returning false.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (OAK-223) Missing path convertion in oak-jcr
[ https://issues.apache.org/jira/browse/OAK-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-223. Resolution: Fixed let's resolve this issue and try to use OAK-495 in order to detect any remaining issues. wdyt? Missing path convertion in oak-jcr -- Key: OAK-223 URL: https://issues.apache.org/jira/browse/OAK-223 Project: Jackrabbit Oak Issue Type: Bug Components: jcr Reporter: angela i have the impression we discussed this ages ago looking at the current state of oak-jcr i get the impression that we still don't have consist usage of the proper path/name format in the various methods. from my understanding all paths/names passed to a oak-api call must be converted to oak-path and back to jcr-path before being exposed on the jcr-api. 2 examples without having a closer look at every single method: - SessionDelegate#getNode - SessionDelegate#getNodeByIdentifier -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (OAK-1146) Remove equals/hashcode on SecureNodeState and TreePermissionImpl
[ https://issues.apache.org/jira/browse/OAK-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13818988#comment-13818988 ] Jukka Zitting commented on OAK-1146: I don't see any significant impact on the microbenchmark results, so I think we're good here. Remove equals/hashcode on SecureNodeState and TreePermissionImpl Key: OAK-1146 URL: https://issues.apache.org/jira/browse/OAK-1146 Project: Jackrabbit Oak Issue Type: Improvement Components: core Reporter: angela Assignee: angela follow up issue for OAK-1144: as suggested by jukka we may want to remove the equals methods from SecureNodeState and TreePermissionImpl. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (OAK-1167) Background read may cause IllegalArgumentException
[
https://issues.apache.org/jira/browse/OAK-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13819020#comment-13819020
]
Marcel Reutegger commented on OAK-1167:
---
AFAICS this is caused by multiple threads concurrently calling
RevisionComparator.add() through different methods. There are mainly two
methods where add() is called for foreign revisions. The third, MongoNodeStore
constructor, is a bit of a special case because it only calls add() once on
startup.
- Revisions are added in MongoNodeStore.backgroundRead() by a dedicated
background thread
- Revisions are added in MongoNodeStore.publishRevision() by a committing
thread when a newer revision than the commit revision is seen.
The check whether to add the revision is implemented differently in the two
methods. backgroundRead() keeps a {{lastKnownRevision}} map, which contains the
most recent foreign revisions, while publishRevision() uses the head revision
to perform the check.
Either both methods must use the same algorithm to decide whether to add a
revision or RevisionComparator.add() must be more lenient when an attempt is
made to add a earlier revision.
Background read may cause IllegalArgumentException
--
Key: OAK-1167
URL: https://issues.apache.org/jira/browse/OAK-1167
Project: Jackrabbit Oak
Issue Type: Bug
Components: core, mongomk
Affects Versions: 0.10
Reporter: Marcel Reutegger
Assignee: Marcel Reutegger
When running Oak with MongoMK and multiple cluster nodes the background read
may sometimes cause an IllegalArgumentException like this:
{noformat}
02:14:40.451 [MongoNodeStore background thread] WARN
o.a.j.o.p.mongomk.MongoNodeStore - Background operation failed:
java.lang.IllegalArgumentException: Can not add an earlier revision:
r14246a7ee62-0-3 r14246a7ea36-0-3; current cluster node is 2
java.lang.IllegalArgumentException: Can not add an earlier revision:
r14246a7ee62-0-3 r14246a7ea36-0-3; current cluster node is 2
at
org.apache.jackrabbit.oak.plugins.mongomk.Revision$RevisionComparator.add(Revision.java:383)
~[oak-run-0.11-SNAPSHOT.jar:0.11-SNAPSHOT]
at
org.apache.jackrabbit.oak.plugins.mongomk.MongoNodeStore.backgroundRead(MongoNodeStore.java:1044)
~[oak-run-0.11-SNAPSHOT.jar:0.11-SNAPSHOT]
at
org.apache.jackrabbit.oak.plugins.mongomk.MongoNodeStore.runBackgroundOperations(MongoNodeStore.java:1000)
~[oak-run-0.11-SNAPSHOT.jar:0.11-SNAPSHOT]
at
org.apache.jackrabbit.oak.plugins.mongomk.MongoNodeStore$BackgroundOperation.run(MongoNodeStore.java:1221)
[oak-run-0.11-SNAPSHOT.jar:0.11-SNAPSHOT]
at java.lang.Thread.run(Thread.java:679) [na:1.6.0_24]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (OAK-1167) Background read may cause IllegalArgumentException
[
https://issues.apache.org/jira/browse/OAK-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13819031#comment-13819031
]
Marcel Reutegger commented on OAK-1167:
---
Committed a quick fix for now, which simply suppresses the
IllegalArgumentException: http://svn.apache.org/r1540753
Background read may cause IllegalArgumentException
--
Key: OAK-1167
URL: https://issues.apache.org/jira/browse/OAK-1167
Project: Jackrabbit Oak
Issue Type: Bug
Components: core, mongomk
Affects Versions: 0.10
Reporter: Marcel Reutegger
Assignee: Marcel Reutegger
When running Oak with MongoMK and multiple cluster nodes the background read
may sometimes cause an IllegalArgumentException like this:
{noformat}
02:14:40.451 [MongoNodeStore background thread] WARN
o.a.j.o.p.mongomk.MongoNodeStore - Background operation failed:
java.lang.IllegalArgumentException: Can not add an earlier revision:
r14246a7ee62-0-3 r14246a7ea36-0-3; current cluster node is 2
java.lang.IllegalArgumentException: Can not add an earlier revision:
r14246a7ee62-0-3 r14246a7ea36-0-3; current cluster node is 2
at
org.apache.jackrabbit.oak.plugins.mongomk.Revision$RevisionComparator.add(Revision.java:383)
~[oak-run-0.11-SNAPSHOT.jar:0.11-SNAPSHOT]
at
org.apache.jackrabbit.oak.plugins.mongomk.MongoNodeStore.backgroundRead(MongoNodeStore.java:1044)
~[oak-run-0.11-SNAPSHOT.jar:0.11-SNAPSHOT]
at
org.apache.jackrabbit.oak.plugins.mongomk.MongoNodeStore.runBackgroundOperations(MongoNodeStore.java:1000)
~[oak-run-0.11-SNAPSHOT.jar:0.11-SNAPSHOT]
at
org.apache.jackrabbit.oak.plugins.mongomk.MongoNodeStore$BackgroundOperation.run(MongoNodeStore.java:1221)
[oak-run-0.11-SNAPSHOT.jar:0.11-SNAPSHOT]
at java.lang.Thread.run(Thread.java:679) [na:1.6.0_24]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (OAK-808) Significant performance issue in TargetImportHandler's prefix mapping handling
[
https://issues.apache.org/jira/browse/OAK-808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-808.
Resolution: Later
Significant performance issue in TargetImportHandler's prefix mapping handling
--
Key: OAK-808
URL: https://issues.apache.org/jira/browse/OAK-808
Project: Jackrabbit Oak
Issue Type: Bug
Components: jcr
Affects Versions: 0.7
Reporter: Lukas Eder
Attachments: Screen Shot YourKit Profiling Session.png,
TargetImportHandler.java.patch
While playing around with Oak, I have observed a significant performance
bottleneck in
{code}
org.apache.jackrabbit.oak.jcr.xml.TargetImportHandler
{code}
The problem can be seen in the attached Screenshot taken from a Yourkit
profiling session. The TargetImportHandler contains a reference to a
documentContext ListMultimap, which acts like a stack of prefix - namespace
mappings. To the outside, however, it is exposed as documentPrefixMap, a
regular prefix - namespace mapping map, which only references the last
namespace for a prefix.
What's problematic here: documentPrefixMap is eagerly copied from
documentContext every time the latter is modified, which may happen a lot
in upstream products, such as Adobe CQ5. Instead, documentPrefixMap should
be a Map view exposing the desired data. An example implementation using
Guava:
{code}
// Create this view once, in the constructor
this.documentPrefixMap = Maps.transformValues(documentContext.asMap(),
new FunctionCollectionString, String() {
@Override
public String apply(CollectionString input) {
return Iterables.getLast(input, null);
}
});
{code}
The above implementation might work, as documentPrefixMap is a read-only
view of the documentContext map. More explicit, verbose implementations may
prove to be even faster.
Before I write a patch, please let me know what you think. Having a live view
may of course create concurrency issues, etc.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (OAK-66) JCR Node Type Management
[ https://issues.apache.org/jira/browse/OAK-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved OAK-66. -- Resolution: Fixed Resolving this issue as all the key functionality is in place. Some of the subtasks still need work, but we can treat those as followup issues. JCR Node Type Management Key: OAK-66 URL: https://issues.apache.org/jira/browse/OAK-66 Project: Jackrabbit Oak Issue Type: Task Components: core, jcr Reporter: angela Fix For: 0.11 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (OAK-713) Automatic property type conversion
[ https://issues.apache.org/jira/browse/OAK-713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved OAK-713. --- Resolution: Won't Fix I guess the backwards compatibility argument is too strong here, so resolving as Won't Fix. Automatic property type conversion -- Key: OAK-713 URL: https://issues.apache.org/jira/browse/OAK-713 Project: Jackrabbit Oak Issue Type: Sub-task Components: core, jcr Reporter: Jukka Zitting Assignee: Jukka Zitting Priority: Minor It would be nice if, instead of throwing a validation error, Oak could automatically do basic property type conversions that lose no content. For example a single value could automatically be transformed to a multi-valued property when required by the matching property definition. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (OAK-460) Node#getDefinition and Property#getDefinition depend on the accessibility of the parent node
[ https://issues.apache.org/jira/browse/OAK-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved OAK-460. --- Resolution: Not A Problem Fix Version/s: (was: 0.11) Resolving as Not A Problem, as the definitions will always be available to things like commit hooks that work below the read access controls. Node#getDefinition and Property#getDefinition depend on the accessibility of the parent node Key: OAK-460 URL: https://issues.apache.org/jira/browse/OAK-460 Project: Jackrabbit Oak Issue Type: Bug Components: jcr Reporter: angela currently the definition of a given item is obtained by reading the node type information of the parent node and is thus relying on the accessibility of the parent node. as discussed previously in other occasions we cannot rely on this as access to the parent might be denied. in the long run we may want to think about a way on how to determine the definition (or parts of the definition such as for example information about the protection status) in the absence of the parent. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (OAK-745) Hardcoded OpenSecurityProvider in RootImpl constructor
[
https://issues.apache.org/jira/browse/OAK-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-745.
Resolution: Fixed
Fix Version/s: (was: 0.14)
0.11
IMHO this has been fixed by extracting the AbstractRoot and creating a
dedicated SystemRoot.
Hardcoded OpenSecurityProvider in RootImpl constructor
--
Key: OAK-745
URL: https://issues.apache.org/jira/browse/OAK-745
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: Antonio Sanso
Fix For: 0.11
One of the RootImpl constructors contains an hardcoded OpenSecurityProvider
reference
public RootImpl(NodeStore store, CommitHook hook) {
// FIXME: define proper default or pass workspace name with the
constructor
this(store, hook, Oak.DEFAULT_WORKSPACE_NAME, SystemSubject.INSTANCE,
new OpenSecurityProvider(), new
CompositeQueryIndexProvider());
}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (OAK-855) NodeState.equals is sometimes very slow
[ https://issues.apache.org/jira/browse/OAK-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13819078#comment-13819078 ] angela commented on OAK-855: is this still an issue? afaik there has been a lot of modifications in that area that may have addressed this issue... NodeState.equals is sometimes very slow --- Key: OAK-855 URL: https://issues.apache.org/jira/browse/OAK-855 Project: Jackrabbit Oak Issue Type: Improvement Components: core Reporter: Thomas Mueller Fix For: 0.12 The method NodeState.equals seems to be very slow sometimes, for example if a KernelNodeState is compared against a ModifiedNodeState. A recursive traversal is used in this case. I found this problem when running the integration tests (-PintegrationTesting). I guess it's specially a problem if there are many child nodes. I wonder if we could use a shortcut when comparing a ModifiedNodeState against a non-modified one: isn't by definition the ModifiedNodeState _never_ equal to a non-modified one, unless there are no changes? When comparing two ModifiedNodeState objects (not sure if that's a common use case), then a simple optimization would also be possible. What's also not nice is: it seems multiple NodeState classes implement equals, but not hashCode. Instead of overriding the equals method, I wonder if we should use another mechanism. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-842) Incorrect interaction of orderable child nodes with permission evaluation
[
https://issues.apache.org/jira/browse/OAK-842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-842:
---
Summary: Incorrect interaction of orderable child nodes with permission
evaluation (was: Incorrect interaction of orderable child nodes with access
control )
Incorrect interaction of orderable child nodes with permission evaluation
-
Key: OAK-842
URL: https://issues.apache.org/jira/browse/OAK-842
Project: Jackrabbit Oak
Issue Type: Bug
Components: core, security
Reporter: Michael Dürig
Fix For: 0.15
Working on OAK-813 revealed problems with the interaction of the current
implementation of orderable nodes and access control:
* {{TreeImpl#getOrderedChildNames}} returns all child names regardless
whether they are accessible in the current session or not. This might cause
errors further down the line like exposure of the existence of child nodes.
* {{TreeImpl.remove}} doesn't (can't) update the child order property if the
parent is not accessible.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Assigned] (OAK-884) Add simple acl randomized test
[ https://issues.apache.org/jira/browse/OAK-884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela reassigned OAK-884: -- Assignee: angela Add simple acl randomized test -- Key: OAK-884 URL: https://issues.apache.org/jira/browse/OAK-884 Project: Jackrabbit Oak Issue Type: Improvement Components: run Reporter: Antonio Sanso Assignee: angela Fix For: 0.13 Attachments: OAK-884-patch.txt Taking as example org.apache.jackrabbit.oak.plugins.mongomk.RandomizedTest it would be nice to have some randomized test also for the ACL evaluation. The logic for the upcoming test patch is to add/remove randomly read permission entry and traverse the tree evaluation the read permission. The result is compared with a Jackrabbit (that is considered as a functional gold implementation) outcome and it is expected to match. Should not match then we have a problem... Patch to follow -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (OAK-855) NodeState.equals is sometimes very slow
[
https://issues.apache.org/jira/browse/OAK-855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting resolved OAK-855.
---
Resolution: Fixed
Fix Version/s: (was: 0.12)
0.11
Yes, for the most part this is already done.
I think the above case in {{setRoot()}} for the {{KernelNodeStore}} still
exists. But I believe the MongoNS effort makes it easier to avoid that
{{equals}} call, so it's probably best to leave the {{KernelNodeStore}} as-is
for now.
Thus resolving this as Fixed. We can follow up on any remaining cases in more
specific issues.
NodeState.equals is sometimes very slow
---
Key: OAK-855
URL: https://issues.apache.org/jira/browse/OAK-855
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core
Reporter: Thomas Mueller
Fix For: 0.11
The method NodeState.equals seems to be very slow sometimes, for example if a
KernelNodeState is compared against a ModifiedNodeState. A recursive
traversal is used in this case. I found this problem when running the
integration tests (-PintegrationTesting). I guess it's specially a problem if
there are many child nodes.
I wonder if we could use a shortcut when comparing a ModifiedNodeState
against a non-modified one: isn't by definition the ModifiedNodeState _never_
equal to a non-modified one, unless there are no changes?
When comparing two ModifiedNodeState objects (not sure if that's a common use
case), then a simple optimization would also be possible.
What's also not nice is: it seems multiple NodeState classes implement
equals, but not hashCode. Instead of overriding the equals method, I wonder
if we should use another mechanism.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (OAK-132) issues related to Node.save() as opposed to Session.save()
[ https://issues.apache.org/jira/browse/OAK-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-132. Resolution: Duplicate issues related to Node.save() as opposed to Session.save() -- Key: OAK-132 URL: https://issues.apache.org/jira/browse/OAK-132 Project: Jackrabbit Oak Issue Type: Task Components: jcr Reporter: Julian Reschke Priority: Minor (This issue is opened for tracking purposes.) JSR-283 deprecates Node.save(). OAK-JCR only partially implements this method. See OAK-993. The TCK has a few test cases that rely on the JSR-170/283 semantics. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-1105) Osgi pluggability for the TokenProvider
[ https://issues.apache.org/jira/browse/OAK-1105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-1105: Issue Type: Sub-task (was: Improvement) Parent: OAK-754 Osgi pluggability for the TokenProvider --- Key: OAK-1105 URL: https://issues.apache.org/jira/browse/OAK-1105 Project: Jackrabbit Oak Issue Type: Sub-task Components: core Reporter: Antonio Sanso Priority: Minor Attachments: OAK-1105-patch.txt It would be nice to have Osgi pluggability for the TokenProvider as for other part of Oak. Patch to follow -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (OAK-1105) Osgi pluggability for the TokenProvider
[ https://issues.apache.org/jira/browse/OAK-1105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela reassigned OAK-1105: --- Assignee: angela Osgi pluggability for the TokenProvider --- Key: OAK-1105 URL: https://issues.apache.org/jira/browse/OAK-1105 Project: Jackrabbit Oak Issue Type: Sub-task Components: core Reporter: Antonio Sanso Assignee: angela Priority: Minor Attachments: OAK-1105-patch.txt It would be nice to have Osgi pluggability for the TokenProvider as for other part of Oak. Patch to follow -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-1137) Node.getReferences() is slow due to missing property index
[ https://issues.apache.org/jira/browse/OAK-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-1137: Summary: Node.getReferences() is slow due to missing property index (was: Node.getReferences() is super slow due to missing property index) Node.getReferences() is slow due to missing property index -- Key: OAK-1137 URL: https://issues.apache.org/jira/browse/OAK-1137 Project: Jackrabbit Oak Issue Type: Bug Components: core, jcr Affects Versions: 0.10 Reporter: Tobias Bocanegra Priority: Critical Fix For: 0.11 Node.getReferences() traverses all items in the repository in order to find the properties that reference the given node. this is super slow and does not scale. the (weak) reference properties should be auto-indexed. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (OAK-98) Source code formatting, code conventions, Javadocs
[
https://issues.apache.org/jira/browse/OAK-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-98.
---
Resolution: Fixed
afaik we agreed to follow a common coding style a long time a ago... not for
everything but for some basic things.
Source code formatting, code conventions, Javadocs
--
Key: OAK-98
URL: https://issues.apache.org/jira/browse/OAK-98
Project: Jackrabbit Oak
Issue Type: Improvement
Reporter: Thomas Mueller
Priority: Minor
I would prefer if we use a somewhat unified coding style, for things like
} else {
versus
}
else {
and so on. There are various style guides, for example:
http://developers.sun.com/sunstudio/products/archive/whitepapers/java-style.pdf
http://www.oracle.com/technetwork/java/codeconv-138413.html
http://java.sun.com/docs/codeconv/CodeConventions.pdf
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (OAK-1150) NodeType index: don't index all primary and mixin types
[ https://issues.apache.org/jira/browse/OAK-1150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-1150: Component/s: core NodeType index: don't index all primary and mixin types --- Key: OAK-1150 URL: https://issues.apache.org/jira/browse/OAK-1150 Project: Jackrabbit Oak Issue Type: Improvement Components: core Reporter: Thomas Mueller Fix For: 0.12 Currently, the nodetype index indexes all primary types and mixin types (including nt:base I think). This results in many nodes in this index, which unnecessarily increases the repository size, but doesn't really help executing queries (running a query to get all nt:base nodes doesn't benefit much from using the nodetype index). It should also help reduce writes in updating the index, for example for OAK-1099 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-913) Query: relative fulltext conditions return the wrong result
[
https://issues.apache.org/jira/browse/OAK-913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-913:
---
Component/s: core
Query: relative fulltext conditions return the wrong result
---
Key: OAK-913
URL: https://issues.apache.org/jira/browse/OAK-913
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: Thomas Mueller
Fix For: 0.12
Fulltext conditions of the following form return the child node instead of
the parent node:
{code}
contains([node1/text], 'hello')
{code}
This is because the filter doesn't contain the relative path (it doesn't
contain the property name either, but that's not the problem here).
The problem here is not the Lucene index, but the filter API, so it can't be
easily fixed. I think it makes sense to fix it as part of OAK-902.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (OAK-1161) Simple failover for TarMK-based installations
[ https://issues.apache.org/jira/browse/OAK-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-1161: Component/s: segmentmk Simple failover for TarMK-based installations - Key: OAK-1161 URL: https://issues.apache.org/jira/browse/OAK-1161 Project: Jackrabbit Oak Issue Type: New Feature Components: segmentmk Reporter: Michael Marth At the moment we have a Mongo-based MK impl that Oak users for scalable deployments and TarMK for standalone (performant) deployments. I think it is OK to not implement some sort of scalability into TarMK, even if I realize that the hierarchical journals allow us to do that later if we want to. However, it would even now be great to have a failover option for TarMK (MongoMK implictly offers this through replicas). This would not be about clustering or scalability, but only about reliability. I think there are 2 parts to this: # keeping a standby repository (slave) in sync and # the actual fail over. For the first part there could be a relatively simple way to implement this: Let's consider that there is only one slave and that the slave does not accept writes. Given the MVCC nature of the tar files we could simply sync the (append-only) tar files from the master to the slave on an ongoing basis. This could be similar to an rsync (or even use actual rsync) The slave would keep on receiving and locally persisting these files. Also, the slave would either need to be in a state where it is blocks writes or even in some sort of sleep state. I think this synchronization of files could be done a rather robust way where shaky networks or high latency could be recovered from by choosing a proper way of transfer. This sync to a remote system could be implemented similarly than a tarMK-based incremental backup (OAK-1159). For the failover: Ideally, we would have 2 implementations: a native failover and an external switch (like MBean or via HTTP) that would make the slave stop accepting files from master and start up on the last completely received revision. But simply having the second option would be a good start. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (OAK-931) Importer: review usage of write-root and objects obtained from the sessioncontext
[ https://issues.apache.org/jira/browse/OAK-931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela reassigned OAK-931: -- Assignee: angela Importer: review usage of write-root and objects obtained from the sessioncontext - Key: OAK-931 URL: https://issues.apache.org/jira/browse/OAK-931 Project: Jackrabbit Oak Issue Type: Sub-task Components: jcr Reporter: angela Assignee: angela Fix For: 0.11 the current importer code (both for session and workspace import) is mixing objects based on the write-root and those based on the editing session context (which in case of a workspace import is associated with a different Root). while up to now i didn't see any failing test, i still suspect that this could lead to issues during the import in particular when it comes to node type validation. therefore opening this issue as a reminder and as issue reference for a TODO in the code. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-931) Importer: review usage of write-root and objects obtained from the sessioncontext
[ https://issues.apache.org/jira/browse/OAK-931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-931: --- Fix Version/s: (was: 0.15) 0.11 Importer: review usage of write-root and objects obtained from the sessioncontext - Key: OAK-931 URL: https://issues.apache.org/jira/browse/OAK-931 Project: Jackrabbit Oak Issue Type: Sub-task Components: jcr Reporter: angela Assignee: Chetan Mehrotra Fix For: 0.11 the current importer code (both for session and workspace import) is mixing objects based on the write-root and those based on the editing session context (which in case of a workspace import is associated with a different Root). while up to now i didn't see any failing test, i still suspect that this could lead to issues during the import in particular when it comes to node type validation. therefore opening this issue as a reminder and as issue reference for a TODO in the code. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (OAK-931) Importer: review usage of write-root and objects obtained from the sessioncontext
[ https://issues.apache.org/jira/browse/OAK-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13819128#comment-13819128 ] angela commented on OAK-931: [~chetanm] i am really not happy with the introduction and the naming of 'initialRoot' vs 'root' which are both passed to the Importer. this looks very troublesome to me and not maintainable. please, refactor the code such that only one root is passed to the Importer. Importer: review usage of write-root and objects obtained from the sessioncontext - Key: OAK-931 URL: https://issues.apache.org/jira/browse/OAK-931 Project: Jackrabbit Oak Issue Type: Sub-task Components: jcr Reporter: angela Fix For: 0.11 the current importer code (both for session and workspace import) is mixing objects based on the write-root and those based on the editing session context (which in case of a workspace import is associated with a different Root). while up to now i didn't see any failing test, i still suspect that this could lead to issues during the import in particular when it comes to node type validation. therefore opening this issue as a reminder and as issue reference for a TODO in the code. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-931) Importer: review usage of write-root and objects obtained from the sessioncontext
[ https://issues.apache.org/jira/browse/OAK-931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-931: --- Assignee: Chetan Mehrotra (was: angela) Importer: review usage of write-root and objects obtained from the sessioncontext - Key: OAK-931 URL: https://issues.apache.org/jira/browse/OAK-931 Project: Jackrabbit Oak Issue Type: Sub-task Components: jcr Reporter: angela Assignee: Chetan Mehrotra Fix For: 0.11 the current importer code (both for session and workspace import) is mixing objects based on the write-root and those based on the editing session context (which in case of a workspace import is associated with a different Root). while up to now i didn't see any failing test, i still suspect that this could lead to issues during the import in particular when it comes to node type validation. therefore opening this issue as a reminder and as issue reference for a TODO in the code. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-1148) Incomplete Javadoc with NodeState#compareAgainstBaseState
[ https://issues.apache.org/jira/browse/OAK-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-1148: Component/s: core Incomplete Javadoc with NodeState#compareAgainstBaseState - Key: OAK-1148 URL: https://issues.apache.org/jira/browse/OAK-1148 Project: Jackrabbit Oak Issue Type: Improvement Components: core Reporter: angela Fix For: 0.11 the method NodeState#compareAgainstBaseState returns a boolean value but the javadoc of the interface lacks the @return entry... i would suggest that we add this and indicate what was the meaning of getting true (or false) returned by the comparision. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Reopened] (OAK-132) issues related to Node.save() as opposed to Session.save()
[ https://issues.apache.org/jira/browse/OAK-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig reopened OAK-132: --- This is not a duplicate of OAK-141. That one is about Node.refresh, while this one is about Node.save. issues related to Node.save() as opposed to Session.save() -- Key: OAK-132 URL: https://issues.apache.org/jira/browse/OAK-132 Project: Jackrabbit Oak Issue Type: Task Components: jcr Reporter: Julian Reschke Priority: Minor (This issue is opened for tracking purposes.) JSR-283 deprecates Node.save(). OAK-JCR only partially implements this method. See OAK-993. The TCK has a few test cases that rely on the JSR-170/283 semantics. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (OAK-1148) Incomplete Javadoc with NodeState#compareAgainstBaseState
[ https://issues.apache.org/jira/browse/OAK-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved OAK-1148. Resolution: Fixed Assignee: Jukka Zitting Done in revision 1540774. Incomplete Javadoc with NodeState#compareAgainstBaseState - Key: OAK-1148 URL: https://issues.apache.org/jira/browse/OAK-1148 Project: Jackrabbit Oak Issue Type: Improvement Components: core Reporter: angela Assignee: Jukka Zitting Fix For: 0.11 the method NodeState#compareAgainstBaseState returns a boolean value but the javadoc of the interface lacks the @return entry... i would suggest that we add this and indicate what was the meaning of getting true (or false) returned by the comparision. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (OAK-1161) Simple failover for TarMK-based installations
[ https://issues.apache.org/jira/browse/OAK-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13819119#comment-13819119 ] angela commented on OAK-1161: - TarMK? do you mean SegmentNodeStore? Simple failover for TarMK-based installations - Key: OAK-1161 URL: https://issues.apache.org/jira/browse/OAK-1161 Project: Jackrabbit Oak Issue Type: New Feature Components: segmentmk Reporter: Michael Marth At the moment we have a Mongo-based MK impl that Oak users for scalable deployments and TarMK for standalone (performant) deployments. I think it is OK to not implement some sort of scalability into TarMK, even if I realize that the hierarchical journals allow us to do that later if we want to. However, it would even now be great to have a failover option for TarMK (MongoMK implictly offers this through replicas). This would not be about clustering or scalability, but only about reliability. I think there are 2 parts to this: # keeping a standby repository (slave) in sync and # the actual fail over. For the first part there could be a relatively simple way to implement this: Let's consider that there is only one slave and that the slave does not accept writes. Given the MVCC nature of the tar files we could simply sync the (append-only) tar files from the master to the slave on an ongoing basis. This could be similar to an rsync (or even use actual rsync) The slave would keep on receiving and locally persisting these files. Also, the slave would either need to be in a state where it is blocks writes or even in some sort of sleep state. I think this synchronization of files could be done a rather robust way where shaky networks or high latency could be recovered from by choosing a proper way of transfer. This sync to a remote system could be implemented similarly than a tarMK-based incremental backup (OAK-1159). For the failover: Ideally, we would have 2 implementations: a native failover and an external switch (like MBean or via HTTP) that would make the slave stop accepting files from master and start up on the last completely received revision. But simply having the second option would be a good start. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (OAK-1018) Optimise Session.getNode
[
https://issues.apache.org/jira/browse/OAK-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting resolved OAK-1018.
Resolution: Fixed
Fix Version/s: (was: 0.12)
0.11
I think we can mark this as fixed:
{noformat}
# GetNodeWithAdmin C min 10% 50% 90% max
N
Jackrabbit 1 15 15 16 17 52
3721
Oak-Tar1 15 15 16 17 84
3781
{noformat}
The anonymous case is still a bit slower, but that's being tracked separately:
{noformat}
# GetNodeWithAnonymous C min 10% 50% 90% max
N
Jackrabbit 1 17 18 18 19 32
3278
Oak-Tar1 33 33 34 36 84
1742
{noformat}
Optimise Session.getNode
Key: OAK-1018
URL: https://issues.apache.org/jira/browse/OAK-1018
Project: Jackrabbit Oak
Issue Type: Sub-task
Components: jcr
Reporter: Michael Dürig
Labels: performance
Fix For: 0.11
Added benchmark {{GetNodeTest}}.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (OAK-663) oak-jcr performance optimization
[
https://issues.apache.org/jira/browse/OAK-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting resolved OAK-663.
---
Resolution: Fixed
Fix Version/s: (was: 0.12)
0.11
Resolving this as fixed as the key problems have already been resolved. For
example the property access case that originally triggered this issue is
already covered:
{noformat}
# ReadPropertyTest C min 10% 50% 90% max
N
Jackrabbit 1 3 4 4 4 90
15074
Oak-Tar1 4 4 4 5 16
14199
{noformat}
Any remaining and/or further optimizations should be tracked in more specific
issues.
oak-jcr performance optimization
Key: OAK-663
URL: https://issues.apache.org/jira/browse/OAK-663
Project: Jackrabbit Oak
Issue Type: Improvement
Components: jcr
Reporter: Jukka Zitting
Priority: Critical
Labels: performance
Fix For: 0.11
Currently oak-jcr does a lot of unnecessary work for various reasons. This is
a major drag on performance.
For example, a getString() call on an already acquired PropertyImpl instance
(with no refresh() or other operations in between) requires 12 (!)
NodeBuilder.getProperty() calls to access that same property state over and
over again.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (OAK-392) Review ContentSession#createBlob
[
https://issues.apache.org/jira/browse/OAK-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated OAK-392:
--
Attachment: 0001-OAK-392-Review-ContentSession-createBlob.patch
I would treat uncommitted blobs as any other transient changes that may be
purged to the underlying storage already at any point before a commit(), just
as long as such content only becomes visible to other clients only *after* the
commit().
That approach also suggest a clean way to deal with the lifetime of a blob: It
will be valid at least until the associated ContentSession is closed, or longer
if it was included in a commit before the session was closed. In the latter
case the blob would remain valid until the related binary property gets removed
and garbage collected.
Such tying of blobs to the originating session makes the {{BlobFactory}}
interface less necessary and would make it more natural to put the
{{createBlob()}} method back in {{ContentSession}} or {{Root}}. The attached
patch does the latter, with the following clarification of the contract:
{code:java}
/**
* Reads (and closes) the given stream and returns a {@link Blob} that
* contains that binary. The returned blob will remain valid at least
* until the {@link ContentSession} of this root is closed, or longer
* if it has been committed as a part of a content update.
* p
* The implementation may decide to persist the blob at any point
* during or between this method method call and a {@link #commit()}
* that includes the blob, but the blob will become visible to other
* sessions only after such a commit.
*
* @param stream the stream for reading the binary
* @return the blob that was created
* @throws IOException if the stream could not be read
*/
@Nonnull
Blob createBlob(@Nonnull InputStream stream) throws IOException;
{code}
Review ContentSession#createBlob
Key: OAK-392
URL: https://issues.apache.org/jira/browse/OAK-392
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core, mk
Reporter: angela
Fix For: 0.12
Attachments: 0001-OAK-392-Review-ContentSession-createBlob.patch
see also
http://markmail.org/message/xc2klids33vjjkud
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (OAK-1145) [Observation] Support for EventJournal in Oak
[
https://issues.apache.org/jira/browse/OAK-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13819394#comment-13819394
]
Jukka Zitting commented on OAK-1145:
See http://markmail.org/message/fezewkxqg73rpxqc: Can you describe the use case
for which you need the {{EventJournal}} functionality? It would be especially
useful to know how long do you need past events to be kept around. Also, do you
need accurate PERSIST boundaries or millisecond-level event timestamps? If not,
would it be fine for example for the repository to bundle up all changes per
hour or per day into super-commits that would appear at fixed intervals in
the event journal?
[Observation] Support for EventJournal in Oak
-
Key: OAK-1145
URL: https://issues.apache.org/jira/browse/OAK-1145
Project: Jackrabbit Oak
Issue Type: New Feature
Components: jcr
Affects Versions: 0.10
Reporter: Daniel Platon
Labels: features
Fix For: 0.14
Please add support for EventJournal in Oak, as it was present in Jackrabbit 2.
Thank you.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
