[jira] [Commented] (OAK-926) MongoMK: split documents when they are too large
[
https://issues.apache.org/jira/browse/OAK-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722267#comment-13722267
]
Thomas Mueller commented on OAK-926:
Revision 1507970: Temporarily, truncate revisions that are older than 5 minutes
if the document is larger than 512 KB
MongoMK: split documents when they are too large
Key: OAK-926
URL: https://issues.apache.org/jira/browse/OAK-926
Project: Jackrabbit Oak
Issue Type: Bug
Components: mongomk
Reporter: Thomas Mueller
Currently, the MongoMK stores all revisions of a node in the same document.
Once there are many revisions, the document gets very large.
The plan is to split the document when it gets big.
It looks like this isn't just a nice to have, but also a problem for some
use cases. Example stack trace:
{code}
21.07.2013 12:35:47.554 *ERROR* ...
Caused by: java.lang.IllegalArgumentException: 'ok' should never be null...
at com.mongodb.CommandResult.ok(CommandResult.java:48)
at com.mongodb.DBCollection.findAndModify(DBCollection.java:375)
at
org.apache.jackrabbit.oak.plugins.mongomk.MongoDocumentStore.findAndModify(MongoDocumentStore.java:302)
... 32 more
{code}
at the same time in the MongoDB log:
{code}
Sun Jul 21 12:35:47.334 [conn7] warning: log line attempted (159k) over max
size(10k),
printing beginning and end ...
Assertion: 10334:BSONObj size: 16795219 (0x53460001) is invalid.
Size must be between 0 and 16793600(16MB)
First element: :childOrder: { r1400279f22d-0-1: [], ...
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-932) RootImpl to AbstractRoot
[ https://issues.apache.org/jira/browse/OAK-932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Sanso updated OAK-932: -- Attachment: OAK-932a-patch.txt thanks for your comment [~mduerig] . attaching new patch that try to address the comments RootImpl to AbstractRoot Key: OAK-932 URL: https://issues.apache.org/jira/browse/OAK-932 Project: Jackrabbit Oak Issue Type: Improvement Components: core Reporter: Antonio Sanso Attachments: OAK-932a-patch.txt, OAK-932a-patch.txt, OAK-932-patch.txt as discussed in [0] it would be nice to have a common Root ancestor for mutable/immutable tree similar to what already exists for the Tree [0] http://oak.markmail.org/thread/fe5p4dhf2i5korqy -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (OAK-910) Privilege Management: Document changes wrt Jackrabbit
[
https://issues.apache.org/jira/browse/OAK-910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13720871#comment-13720871
]
angela edited comment on OAK-910 at 7/29/13 9:56 AM:
-
h4. 1. General Characteristics of the Privilege Management Implementation
As of OAK the built-in and custom privileges are stored in the repository
underneath /jcr:system/rep:privileges. Similar to other repository level date
(node types, namespaces and versions) this location is shared by all workspaces
present in the repository. The nodes and properties storing the privilege
definitions are protected by their node type definition. In addition a
specific privilege validator asserts the consistency of the privilege store.
h4. 2. Built-in Privilege Definitions
* All Privileges as defined by JSR 283
** jcr:read
** jcr:modifyProperties
** jcr:addChildNodes
** jcr:removeNode
** jcr:removeChildNodes
** jcr:readAccessControl
** jcr:modifyAccessControl
** jcr:lockManagement
** jcr:versionManagement
** jcr:nodeTypeManagement
** jcr:retentionManagement (NOTE: retention management not yet implemented)
** jcr:lifecycleManagement (NOTE: lifecycle management not yet implemented)
** jcr:write
** jcr:all
* All Privileges defined by JSR 333
** jcr:workspaceManagement (NOTE: wsp management not yet implemented)
** jcr:nodeTypeDefinitionManagement
** jcr:namespaceManagement
* All Privileges defined by Jackrabbit 2.x
** rep:write
** rep:privilegeManagement
* new privileges defined by OAK 1.0:
** rep:userManagement
** rep:readNodes
** rep:readProperties
** rep:addProperties
** rep:alterProperties
** rep:removeProperties
Note the following differences with respect to Jackrabbit 2.x definitions:
* jcr:read is now an aggregation of rep:readNodes and rep:readProperties
* jcr:modifyProperties is now an aggregation of rep:addProperties,
rep:alterProperties and rep:removeProperties
h4. 3. Node Type Definitions
The following privilege related built-in node types have been added in OAK 1.0:
{code}
[rep:Privileges]
+ * (rep:Privilege) = rep:Privilege protected ABORT
- rep:next (LONG) protected multiple mandatory
[rep:Privilege]
- rep:isAbstract (BOOLEAN) protected
- rep:aggregates (NAME) protected multiple
- rep:bits (LONG) protected multiple mandatory
{code}
h4. 4. API Extensions
h4. 5. Configuration
h4. 6. References
was (Author: anchela):
h4. 1. General Characteristics of the Privilege Management Implementation
h4. 2. Built-in Privilege Definitions
* All Privileges as defined by JSR 283
** jcr:read
** jcr:modifyProperties
** jcr:addChildNodes
** jcr:removeNode
** jcr:removeChildNodes
** jcr:readAccessControl
** jcr:modifyAccessControl
** jcr:lockManagement
** jcr:versionManagement
** jcr:nodeTypeManagement
** jcr:retentionManagement (NOTE: retention management not yet implemented)
** jcr:lifecycleManagement (NOTE: lifecycle management not yet implemented)
** jcr:write
** jcr:all
* All Privileges defined by JSR 333
** jcr:workspaceManagement (NOTE: wsp management not yet implemented)
** jcr:nodeTypeDefinitionManagement
** jcr:namespaceManagement
* All Privileges defined by Jackrabbit 2.x
** rep:write
** rep:privilegeManagement
* new privileges defined by OAK 1.0:
** rep:userManagement
** rep:readNodes
** rep:readProperties
** rep:addProperties
** rep:alterProperties
** rep:removeProperties
Note the following differences with respect to Jackrabbit 2.x definitions:
* jcr:read is now an aggregation of rep:readNodes and rep:readProperties
* jcr:modifyProperties is now an aggregation of rep:addProperties,
rep:alterProperties and rep:removeProperties
h4. 3. Node Type Definitions
The following privilege related built-in node types have been added in OAK 1.0:
{code}
[rep:Privileges]
+ * (rep:Privilege) = rep:Privilege protected ABORT
- rep:next (LONG) protected multiple mandatory
[rep:Privilege]
- rep:isAbstract (BOOLEAN) protected
- rep:aggregates (NAME) protected multiple
- rep:bits (LONG) protected multiple mandatory
{code}
h4. 4. API Extensions
h4. 5. Configuration
h4. 6. References
Privilege Management: Document changes wrt Jackrabbit
-
Key: OAK-910
URL: https://issues.apache.org/jira/browse/OAK-910
Project: Jackrabbit Oak
Issue Type: Sub-task
Components: core, jcr
Reporter: angela
Assignee: angela
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-803) Backwards compatibility of long-lived sessions
[ https://issues.apache.org/jira/browse/OAK-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722452#comment-13722452 ] Michael Dürig commented on OAK-803: --- bq. provide a way for clients to choose the refresh behaviour on login, [Discussion | http://markmail.org/message/lwhpglehee3jgpip] on the @dev list. Backwards compatibility of long-lived sessions -- Key: OAK-803 URL: https://issues.apache.org/jira/browse/OAK-803 Project: Jackrabbit Oak Issue Type: Improvement Components: jcr Reporter: Jukka Zitting Assignee: Michael Dürig The auto-refresh mode added in OAK-88 should perhaps be enabled by default, with warning logs to let clients know that relying on such a default behavior without explicit per-session configuration might not be supported in a future release. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-932) RootImpl to AbstractRoot
[
https://issues.apache.org/jira/browse/OAK-932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722526#comment-13722526
]
Michael Dürig commented on OAK-932:
---
At revision 1508095 I made {{RootImpl}} abstract and renamed it to
{{AbstractRoot}}.
RootImpl to AbstractRoot
Key: OAK-932
URL: https://issues.apache.org/jira/browse/OAK-932
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core
Reporter: Antonio Sanso
Attachments: OAK-932a-patch.txt, OAK-932a-patch.txt, OAK-932-patch.txt
as discussed in [0] it would be nice to have a common Root ancestor for
mutable/immutable tree similar to what already exists for the Tree
[0] http://oak.markmail.org/thread/fe5p4dhf2i5korqy
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-803) Backwards compatibility of long-lived sessions
[
https://issues.apache.org/jira/browse/OAK-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722860#comment-13722860
]
Michael Dürig commented on OAK-803:
---
At revision 1508182 I committed evaluation of the {{refresh-interval}} on
{{SimpleCredentials}} and {{TokenCredentials}} on {{Session.login()}}. The
value of the attribute is the number of seconds after which as session will be
automatically refreshed.
Backwards compatibility of long-lived sessions
--
Key: OAK-803
URL: https://issues.apache.org/jira/browse/OAK-803
Project: Jackrabbit Oak
Issue Type: Improvement
Components: jcr
Reporter: Jukka Zitting
Assignee: Michael Dürig
The auto-refresh mode added in OAK-88 should perhaps be enabled by default,
with warning logs to let clients know that relying on such a default behavior
without explicit per-session configuration might not be supported in a future
release.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
