[jira] [Updated] (OAK-2650) [Oak API remoting] Error handling
[ https://issues.apache.org/jira/browse/OAK-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg updated OAK-2650: --- Issue Type: New Feature (was: Task) [Oak API remoting] Error handling - Key: OAK-2650 URL: https://issues.apache.org/jira/browse/OAK-2650 Project: Jackrabbit Oak Issue Type: New Feature Reporter: Fabrice Hong Priority: Blocker * Implement exception handling * Provide error information to developer through debug log * Provide error information to API client -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2650) [Oak API remoting] Error handling
[ https://issues.apache.org/jira/browse/OAK-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg updated OAK-2650: --- Priority: Major (was: Blocker) [Oak API remoting] Error handling - Key: OAK-2650 URL: https://issues.apache.org/jira/browse/OAK-2650 Project: Jackrabbit Oak Issue Type: New Feature Reporter: Fabrice Hong * Implement exception handling * Provide error information to developer through debug log * Provide error information to API client -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (OAK-2237) NodeStoreKernel.getNodes throws when passing filter=
[
https://issues.apache.org/jira/browse/OAK-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg reassigned OAK-2237:
--
Assignee: Stefan Guggisberg
NodeStoreKernel.getNodes throws when passing filter=
--
Key: OAK-2237
URL: https://issues.apache.org/jira/browse/OAK-2237
Project: Jackrabbit Oak
Issue Type: Bug
Components: mk
Reporter: Stefan Guggisberg
Assignee: Stefan Guggisberg
Fix For: 1.0.8, 1.2, 1.1.2
calling {{NodeStoreKernel.getNodes}} with {{filter=}} results in the
following stacktrace:
{code}
IllegalArgumentException: [*] expected: '{'
at
org.apache.jackrabbit.oak.commons.json.JsopTokenizer.getFormatException(JsopTokenizer.java:373)
at
org.apache.jackrabbit.oak.commons.json.JsopTokenizer.read(JsopTokenizer.java:107)
at org.apache.jackrabbit.oak.kernel.JsonFilter.init(JsonFilter.java:43)
at
org.apache.jackrabbit.oak.kernel.JsonSerializer.init(JsonSerializer.java:69)
at
org.apache.jackrabbit.oak.kernel.NodeStoreKernel.getNodes(NodeStoreKernel.java:499)
at ...
{code}
according to {{MicroKernel.getNodes}}:
{quote}
@param filteroptional filter on property and/or node names; if
{{null}} or {{}} the default filter will be assumed
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-2237) NodeStoreKernel.getNodes throws when passing filter=
Stefan Guggisberg created OAK-2237:
--
Summary: NodeStoreKernel.getNodes throws when passing filter=
Key: OAK-2237
URL: https://issues.apache.org/jira/browse/OAK-2237
Project: Jackrabbit Oak
Issue Type: Bug
Components: mk
Reporter: Stefan Guggisberg
Fix For: 1.0.8, 1.2, 1.1.2
calling {{NodeStoreKernel.getNodes}} with {{filter=}} results in the
following stacktrace:
{code}
IllegalArgumentException: [*] expected: '{'
at
org.apache.jackrabbit.oak.commons.json.JsopTokenizer.getFormatException(JsopTokenizer.java:373)
at
org.apache.jackrabbit.oak.commons.json.JsopTokenizer.read(JsopTokenizer.java:107)
at org.apache.jackrabbit.oak.kernel.JsonFilter.init(JsonFilter.java:43)
at
org.apache.jackrabbit.oak.kernel.JsonSerializer.init(JsonSerializer.java:69)
at
org.apache.jackrabbit.oak.kernel.NodeStoreKernel.getNodes(NodeStoreKernel.java:499)
at ...
{code}
according to {{MicroKernel.getNodes}}:
{quote}
@param filteroptional filter on property and/or node names; if
{{null}} or {{}} the default filter will be assumed
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-2237) NodeStoreKernel.getNodes throws when passing filter=
[
https://issues.apache.org/jira/browse/OAK-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg resolved OAK-2237.
Resolution: Fixed
fixed in svn r1634898
NodeStoreKernel.getNodes throws when passing filter=
--
Key: OAK-2237
URL: https://issues.apache.org/jira/browse/OAK-2237
Project: Jackrabbit Oak
Issue Type: Bug
Components: mk
Reporter: Stefan Guggisberg
Assignee: Stefan Guggisberg
Fix For: 1.0.8, 1.2, 1.1.2
calling {{NodeStoreKernel.getNodes}} with {{filter=}} results in the
following stacktrace:
{code}
IllegalArgumentException: [*] expected: '{'
at
org.apache.jackrabbit.oak.commons.json.JsopTokenizer.getFormatException(JsopTokenizer.java:373)
at
org.apache.jackrabbit.oak.commons.json.JsopTokenizer.read(JsopTokenizer.java:107)
at org.apache.jackrabbit.oak.kernel.JsonFilter.init(JsonFilter.java:43)
at
org.apache.jackrabbit.oak.kernel.JsonSerializer.init(JsonSerializer.java:69)
at
org.apache.jackrabbit.oak.kernel.NodeStoreKernel.getNodes(NodeStoreKernel.java:499)
at ...
{code}
according to {{MicroKernel.getNodes}}:
{quote}
@param filteroptional filter on property and/or node names; if
{{null}} or {{}} the default filter will be assumed
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-2160) mk.getRevisionHistory: clarify since parameter
Stefan Guggisberg created OAK-2160:
--
Summary: mk.getRevisionHistory: clarify since parameter
Key: OAK-2160
URL: https://issues.apache.org/jira/browse/OAK-2160
Project: Jackrabbit Oak
Issue Type: Improvement
Components: mk
Reporter: Stefan Guggisberg
Assignee: Stefan Guggisberg
the {{since}} parameter (timestamp in ms) needs further clarification (i.e.
_number of milliseconds since midnight of January 1, 1970_)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2160) mk.getRevisionHistory: clarify since parameter
[
https://issues.apache.org/jira/browse/OAK-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg updated OAK-2160:
---
Description:
getRevisionHistory:
the {{since}} parameter (timestamp in ms) needs further clarification (i.e.
_number of milliseconds since midnight of January 1, 1970_)
was:the {{since}} parameter (timestamp in ms) needs further clarification
(i.e. _number of milliseconds since midnight of January 1, 1970_)
mk.getRevisionHistory: clarify since parameter
--
Key: OAK-2160
URL: https://issues.apache.org/jira/browse/OAK-2160
Project: Jackrabbit Oak
Issue Type: Improvement
Components: mk
Reporter: Stefan Guggisberg
Assignee: Stefan Guggisberg
getRevisionHistory:
the {{since}} parameter (timestamp in ms) needs further clarification (i.e.
_number of milliseconds since midnight of January 1, 1970_)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2160) mk.getRevisionHistory: clarify since parameter
[
https://issues.apache.org/jira/browse/OAK-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg updated OAK-2160:
---
Description:
getRevisionHistory:
the {{since}} parameter (timestamp in ms) needs further clarification (i.e.
_number of milliseconds since midnight, January 1, 1970 UTC_)
was:
getRevisionHistory:
the {{since}} parameter (timestamp in ms) needs further clarification (i.e.
_number of milliseconds since midnight of January 1, 1970_)
mk.getRevisionHistory: clarify since parameter
--
Key: OAK-2160
URL: https://issues.apache.org/jira/browse/OAK-2160
Project: Jackrabbit Oak
Issue Type: Improvement
Components: mk
Reporter: Stefan Guggisberg
Assignee: Stefan Guggisberg
getRevisionHistory:
the {{since}} parameter (timestamp in ms) needs further clarification (i.e.
_number of milliseconds since midnight, January 1, 1970 UTC_)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-2160) mk.getRevisionHistory: clarify since parameter
[
https://issues.apache.org/jira/browse/OAK-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg resolved OAK-2160.
Resolution: Fixed
Fix Version/s: 1.0.7
1.1
fixed in svn r1629148
mk.getRevisionHistory: clarify since parameter
--
Key: OAK-2160
URL: https://issues.apache.org/jira/browse/OAK-2160
Project: Jackrabbit Oak
Issue Type: Improvement
Components: mk
Reporter: Stefan Guggisberg
Assignee: Stefan Guggisberg
Fix For: 1.1, 1.0.7
getRevisionHistory:
the {{since}} parameter (timestamp in ms) needs further clarification (i.e.
_number of milliseconds since midnight, January 1, 1970 UTC_)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-2161) MicroKernelIT: clean test content
Stefan Guggisberg created OAK-2161: -- Summary: MicroKernelIT: clean test content Key: OAK-2161 URL: https://issues.apache.org/jira/browse/OAK-2161 Project: Jackrabbit Oak Issue Type: Improvement Components: mk Reporter: Stefan Guggisberg Assignee: Stefan Guggisberg test content is currently not cleaned. this leads to errors when running against a non-transient mk. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-2161) MicroKernelIT: clean test content
[ https://issues.apache.org/jira/browse/OAK-2161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg resolved OAK-2161. Resolution: Fixed Fix Version/s: 1.0.7 1.1 fixed in svn r1629160 MicroKernelIT: clean test content - Key: OAK-2161 URL: https://issues.apache.org/jira/browse/OAK-2161 Project: Jackrabbit Oak Issue Type: Improvement Components: mk Reporter: Stefan Guggisberg Assignee: Stefan Guggisberg Fix For: 1.1, 1.0.7 test content is currently not cleaned. this leads to errors when running against a non-transient mk. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-2162) oak-it-mk: add ClientFixture
Stefan Guggisberg created OAK-2162: -- Summary: oak-it-mk: add ClientFixture Key: OAK-2162 URL: https://issues.apache.org/jira/browse/OAK-2162 Project: Jackrabbit Oak Issue Type: Improvement Reporter: Stefan Guggisberg Assignee: Stefan Guggisberg add a ClientFixture for testing externally started remote MicroKernel instances -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2162) oak-it-mk: add ClientFixture
[ https://issues.apache.org/jira/browse/OAK-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg updated OAK-2162: --- Component/s: mk oak-it-mk: add ClientFixture Key: OAK-2162 URL: https://issues.apache.org/jira/browse/OAK-2162 Project: Jackrabbit Oak Issue Type: Improvement Components: mk Reporter: Stefan Guggisberg Assignee: Stefan Guggisberg add a ClientFixture for testing externally started remote MicroKernel instances -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-1929) MicroKernelServer not usable with user specified MicroKernel implementation
[
https://issues.apache.org/jira/browse/OAK-1929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14048885#comment-14048885
]
Stefan Guggisberg commented on OAK-1929:
i prefer 2), but 1) would be fine by me as well.
MicroKernelServer not usable with user specified MicroKernel implementation
Key: OAK-1929
URL: https://issues.apache.org/jira/browse/OAK-1929
Project: Jackrabbit Oak
Issue Type: Improvement
Components: run
Affects Versions: 1.0
Reporter: Michael Dürig
Assignee: Michael Dürig
Fix For: 1.1
{{MicroKernelServer}} is hard coded to use {{MicroKernelImpl}}, which limits
its usefulness. I suggest we either,
# make this server part of {{oak-run}}'s {{Main}} class,
# add additional command line arguments to specify the MK implementation,
# remove the class altogether.
WDYT?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (OAK-1931) MicroKernel.read() returns negative value
[
https://issues.apache.org/jira/browse/OAK-1931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg resolved OAK-1931.
Resolution: Fixed
Fix Version/s: 1.0.2
fixed implementations and adapted test cases where necessary
svn r1607081
MicroKernel.read() returns negative value
-
Key: OAK-1931
URL: https://issues.apache.org/jira/browse/OAK-1931
Project: Jackrabbit Oak
Issue Type: Bug
Components: mk
Affects Versions: 1.0
Reporter: Michael Dürig
Assignee: Stefan Guggisberg
Fix For: 1.0.2
The contract of {{MicroKernel#read}} states: This method never returns
negative values.. However, AFAICS all of our implementations *do* return -1
under certain circumstances and some test cases (e.g.
{{MicroKernelInputStreamTest}} even rely on this).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (OAK-1931) MicroKernel.read() returns negative value
[
https://issues.apache.org/jira/browse/OAK-1931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg updated OAK-1931:
---
Fix Version/s: 1.1
MicroKernel.read() returns negative value
-
Key: OAK-1931
URL: https://issues.apache.org/jira/browse/OAK-1931
Project: Jackrabbit Oak
Issue Type: Bug
Components: mk
Affects Versions: 1.0
Reporter: Michael Dürig
Assignee: Stefan Guggisberg
Fix For: 1.0.2, 1.1
The contract of {{MicroKernel#read}} states: This method never returns
negative values.. However, AFAICS all of our implementations *do* return -1
under certain circumstances and some test cases (e.g.
{{MicroKernelInputStreamTest}} even rely on this).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (OAK-1931) MicroKernel.read() returns negative value
[
https://issues.apache.org/jira/browse/OAK-1931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg reassigned OAK-1931:
--
Assignee: Stefan Guggisberg
MicroKernel.read() returns negative value
-
Key: OAK-1931
URL: https://issues.apache.org/jira/browse/OAK-1931
Project: Jackrabbit Oak
Issue Type: Bug
Components: mk
Affects Versions: 1.0
Reporter: Michael Dürig
Assignee: Stefan Guggisberg
The contract of {{MicroKernel#read}} states: This method never returns
negative values.. However, AFAICS all of our implementations *do* return -1
under certain circumstances and some test cases (e.g.
{{MicroKernelInputStreamTest}} even rely on this).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (OAK-1327) Cleanup NodeStore and MK implementations
[
https://issues.apache.org/jira/browse/OAK-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14046078#comment-14046078
]
Stefan Guggisberg commented on OAK-1327:
-1, the {{MicroKernel}} implementation *is* maintained by me.
Cleanup NodeStore and MK implementations
Key: OAK-1327
URL: https://issues.apache.org/jira/browse/OAK-1327
Project: Jackrabbit Oak
Issue Type: Wish
Components: core, mk, segmentmk
Reporter: angela
Fix For: 1.1
Attachments: OAK-1327.patch
as discussed during the oak-call today, i would like to cleanup the code base
before we officially release OAK.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (OAK-1633) Drop custom HTTP code in oak-mk-remote
[ https://issues.apache.org/jira/browse/OAK-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956230#comment-13956230 ] Stefan Guggisberg commented on OAK-1633: -1 for moving to the sandbox. the code is in use and maintained. Drop custom HTTP code in oak-mk-remote -- Key: OAK-1633 URL: https://issues.apache.org/jira/browse/OAK-1633 Project: Jackrabbit Oak Issue Type: Bug Components: mk Reporter: Jukka Zitting Priority: Critical The custom HTTP code in oak-mk-remote has subtle security flaws and should be dropped in favor of standard servlet interfaces or something like Apache HttpComponents. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (OAK-1577) H2MK: Implement refined conflict resolution for addExistingNode conflicts
[ https://issues.apache.org/jira/browse/OAK-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg resolved OAK-1577. Resolution: Fixed fixed in svn r1581319 H2MK: Implement refined conflict resolution for addExistingNode conflicts - Key: OAK-1577 URL: https://issues.apache.org/jira/browse/OAK-1577 Project: Jackrabbit Oak Issue Type: Sub-task Components: mk Reporter: Michael Dürig Assignee: Stefan Guggisberg Fix For: 0.20 Implement refined conflict resolution for addExistingNode conflicts as defined in the parent issue for the H2 MK. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (OAK-162) Oak Layering / Remoting architecture
[ https://issues.apache.org/jira/browse/OAK-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg reopened OAK-162: --- sorry, i don't agree with the resolution. Oak Layering / Remoting architecture Key: OAK-162 URL: https://issues.apache.org/jira/browse/OAK-162 Project: Jackrabbit Oak Issue Type: Bug Components: core Reporter: Stefan Guggisberg i had the impression that we started the oak project with a shared view of the layering architecture (roughly based on the jackrabbit spi abstraction/partitioning model). the jcr api already implies 2 layers (client/server): - session-related operations (transient space etc) - javax.jcr.Session - workspace-related operations (versioning, locking, node types etc) - javax.jcr.Workspace the jackrabbit spi represents the abstraction of the workspace-related functionality and obviously lends itself to be remoted. here's my understanding of how the oak layering model should look like: 1. jcr client (oak-jcr): exposes the jcr api and implements the session-related functionality (transient space!); delegates workspace-related operations to the spi (oak api) 2. server-side repository (oak-core): exposes the spi (oak api) and implements the workspace-related operations; delegates persistence-related operations to the mk (oak api) 3. persistence layer (oak-mk): exposes the mk api and implements persistence operations the oak api and the mk api are the obvious potential remoting points. i see the following issues with the current oak code base: - the 3 layers are not properly isolated, transient space operations e.g. reach through all 3 layers. workspace mgmt e.g. is handled on the client. if either the oak or the mk api is remoted this is serious potential performance problem. - there's a mismatch between the spi and the current oak api in terms of scope/functionality; several workspace operations (such as versioning, ns mgmt, node type mgmt) don't seem to be reflected in the oak api. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (OAK-162) Oak Layering / Remoting architecture
[ https://issues.apache.org/jira/browse/OAK-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13914562#comment-13914562 ] Stefan Guggisberg commented on OAK-162: --- ~jukka, i think i've expressed my concerns pretty clearly in this issue. resolving the issue as 'not a problem', after almost 2 years of silence, is IMO unacceptable. bq. This is a concern for the remoting protocol to address. what remoting protocol? bq. I don't see a compelling reason why such operations should be explicitly exposed in the API. how would a remote jcr client (oak-jcr) access e.g. versioning functionality provided by oak-core? Oak Layering / Remoting architecture Key: OAK-162 URL: https://issues.apache.org/jira/browse/OAK-162 Project: Jackrabbit Oak Issue Type: Bug Components: core Reporter: Stefan Guggisberg i had the impression that we started the oak project with a shared view of the layering architecture (roughly based on the jackrabbit spi abstraction/partitioning model). the jcr api already implies 2 layers (client/server): - session-related operations (transient space etc) - javax.jcr.Session - workspace-related operations (versioning, locking, node types etc) - javax.jcr.Workspace the jackrabbit spi represents the abstraction of the workspace-related functionality and obviously lends itself to be remoted. here's my understanding of how the oak layering model should look like: 1. jcr client (oak-jcr): exposes the jcr api and implements the session-related functionality (transient space!); delegates workspace-related operations to the spi (oak api) 2. server-side repository (oak-core): exposes the spi (oak api) and implements the workspace-related operations; delegates persistence-related operations to the mk (oak api) 3. persistence layer (oak-mk): exposes the mk api and implements persistence operations the oak api and the mk api are the obvious potential remoting points. i see the following issues with the current oak code base: - the 3 layers are not properly isolated, transient space operations e.g. reach through all 3 layers. workspace mgmt e.g. is handled on the client. if either the oak or the mk api is remoted this is serious potential performance problem. - there's a mismatch between the spi and the current oak api in terms of scope/functionality; several workspace operations (such as versioning, ns mgmt, node type mgmt) don't seem to be reflected in the oak api. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (OAK-162) Oak Layering / Remoting architecture
[ https://issues.apache.org/jira/browse/OAK-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13914614#comment-13914614 ] Stefan Guggisberg commented on OAK-162: --- bq. The way it already does. can you please elaborate? i don't see any versioning related oak-core API methods. i neither see any remoting protocol exposing equivalent functionality like batch read, batch write, checkin, copy, move, etc. Oak Layering / Remoting architecture Key: OAK-162 URL: https://issues.apache.org/jira/browse/OAK-162 Project: Jackrabbit Oak Issue Type: Bug Components: core Reporter: Stefan Guggisberg i had the impression that we started the oak project with a shared view of the layering architecture (roughly based on the jackrabbit spi abstraction/partitioning model). the jcr api already implies 2 layers (client/server): - session-related operations (transient space etc) - javax.jcr.Session - workspace-related operations (versioning, locking, node types etc) - javax.jcr.Workspace the jackrabbit spi represents the abstraction of the workspace-related functionality and obviously lends itself to be remoted. here's my understanding of how the oak layering model should look like: 1. jcr client (oak-jcr): exposes the jcr api and implements the session-related functionality (transient space!); delegates workspace-related operations to the spi (oak api) 2. server-side repository (oak-core): exposes the spi (oak api) and implements the workspace-related operations; delegates persistence-related operations to the mk (oak api) 3. persistence layer (oak-mk): exposes the mk api and implements persistence operations the oak api and the mk api are the obvious potential remoting points. i see the following issues with the current oak code base: - the 3 layers are not properly isolated, transient space operations e.g. reach through all 3 layers. workspace mgmt e.g. is handled on the client. if either the oak or the mk api is remoted this is serious potential performance problem. - there's a mismatch between the spi and the current oak api in terms of scope/functionality; several workspace operations (such as versioning, ns mgmt, node type mgmt) don't seem to be reflected in the oak api. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (OAK-1331) MicroKernel API: clarify semantics of `read` method
[
https://issues.apache.org/jira/browse/OAK-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg resolved OAK-1331.
Resolution: Fixed
Assignee: Stefan Guggisberg
fixed in svn r1567030
MicroKernel API: clarify semantics of `read` method
---
Key: OAK-1331
URL: https://issues.apache.org/jira/browse/OAK-1331
Project: Jackrabbit Oak
Issue Type: Improvement
Components: mk, mongomk, segmentmk
Reporter: Stefan Guggisberg
Assignee: Stefan Guggisberg
Labels: documentation
Fix For: 0.17
the javadoc of {{MicroKernel#read}} currently states that
{quote}
An attempt is made to read as many as {{length}} bytes, but a smaller number
may be read.
{quote}
under what conditions a smaller amount might be read is not specified.
with the current specification an api consumer would either have to know the
length of the blob in advance (i.e. by calling {{MicroKernel#getLength}}) or
would need to call the {{MicroKernel#read}} method twice to make sure that
the blob content is fully read.
i suggest to clarify the contract as follows:
Reads up to {{length}} bytes of data from the specified blob into the given
array of bytes where the actual number of bytes read is {{min(length, max(0,
blobLength - pos))}}.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (OAK-1331) MicroKernel API: clarify semantics of `read` method
Stefan Guggisberg created OAK-1331:
--
Summary: MicroKernel API: clarify semantics of `read` method
Key: OAK-1331
URL: https://issues.apache.org/jira/browse/OAK-1331
Project: Jackrabbit Oak
Issue Type: Improvement
Components: mongomk, segmentmk
Reporter: Stefan Guggisberg
Fix For: 0.15
the javadoc of {{MicroKernel#read}} currently states that
{quote}
An attempt is made to read as many as {{length}} bytes, but a smaller number
may be read.
{quote}
under what conditions a smaller amount might be read is not specified.
with the current specification an api consumer would either have to know the
length of the blob in advance (i.e. by calling {{MicroKernel#getLength}}) or
would need to call the {{MicroKernel#read}} method twice to make sure that the
blob content is fully read.
i suggest to clarify the contract as follows:
Reads up to {{length}} bytes of data from the specified blob into the given
array of bytes where the actual number of bytes read is {{min(length, max(0,
blobLength - pos))}}.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (OAK-1331) MicroKernel API: clarify semantics of `read` method
[
https://issues.apache.org/jira/browse/OAK-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg updated OAK-1331:
---
Component/s: mk
MicroKernel API: clarify semantics of `read` method
---
Key: OAK-1331
URL: https://issues.apache.org/jira/browse/OAK-1331
Project: Jackrabbit Oak
Issue Type: Improvement
Components: mk, mongomk, segmentmk
Reporter: Stefan Guggisberg
Fix For: 0.15
the javadoc of {{MicroKernel#read}} currently states that
{quote}
An attempt is made to read as many as {{length}} bytes, but a smaller number
may be read.
{quote}
under what conditions a smaller amount might be read is not specified.
with the current specification an api consumer would either have to know the
length of the blob in advance (i.e. by calling {{MicroKernel#getLength}}) or
would need to call the {{MicroKernel#read}} method twice to make sure that
the blob content is fully read.
i suggest to clarify the contract as follows:
Reads up to {{length}} bytes of data from the specified blob into the given
array of bytes where the actual number of bytes read is {{min(length, max(0,
blobLength - pos))}}.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (OAK-1203) Reset branch to previous commit
[
https://issues.apache.org/jira/browse/OAK-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13828619#comment-13828619
]
Stefan Guggisberg commented on OAK-1203:
+1 for the patch
BTW: isn't this already possible with the existing MicroKernel API
(albeit not necesseraly as efficently)?
i.e.
{code:java}
// assuming rev1 denotes the current branch revision
// and rev0 denotes an ancestor branch revision
// get reverse diff
String reverseDiff = mk.diff(rev1, rev0, null, -1);
// commit reverse diff
String rev2 = mk.commit(, reverseDiff, rev1, null);
// the trees at revisions rev0 and rev2 are now identical
{code}
Reset branch to previous commit
---
Key: OAK-1203
URL: https://issues.apache.org/jira/browse/OAK-1203
Project: Jackrabbit Oak
Issue Type: New Feature
Components: mk, mongomk
Reporter: Marcel Reutegger
Assignee: Marcel Reutegger
Attachments: OAK-1203.patch
To resolve OAK-1056 and OAK-1202 there must be a way to reset a branch to a
previous commit.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (OAK-1203) Reset branch to previous commit
[ https://issues.apache.org/jira/browse/OAK-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13828668#comment-13828668 ] Stefan Guggisberg commented on OAK-1203: bq. That's the reason why I would like to add a dedicated method for this operation. agreed Reset branch to previous commit --- Key: OAK-1203 URL: https://issues.apache.org/jira/browse/OAK-1203 Project: Jackrabbit Oak Issue Type: New Feature Components: mk, mongomk Reporter: Marcel Reutegger Assignee: Marcel Reutegger Attachments: OAK-1203.patch To resolve OAK-1056 and OAK-1202 there must be a way to reset a branch to a previous commit. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (OAK-552) AssertionError in MicroKernel.commit()
[
https://issues.apache.org/jira/browse/OAK-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13829019#comment-13829019
]
Stefan Guggisberg commented on OAK-552:
---
bq. The test now fails for me:
fixed test in r1544209
AssertionError in MicroKernel.commit()
--
Key: OAK-552
URL: https://issues.apache.org/jira/browse/OAK-552
Project: Jackrabbit Oak
Issue Type: Bug
Components: mk
Reporter: Michael Dürig
{code}
mk.commit(, -\/x/\, null, null);
{code}
results in
{code}
java.lang.AssertionError
at
org.apache.jackrabbit.oak.commons.PathUtils.concat(PathUtils.java:277)
at
org.apache.jackrabbit.mk.core.MicroKernelImpl.commit(MicroKernelImpl.java:437)
at
org.apache.jackrabbit.mk.MicroKernelImplTest.foo(MicroKernelImplTest.java:424)
{code}
since according to {{PathUtils}} {{/x/}} is not a valid path.
The commit method should throw an {{IllegalArgumentException}} instead.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (OAK-1200) occasional test failure in org.apache.jackrabbit.mk.store.DefaultRevisionStoreTest
[ https://issues.apache.org/jira/browse/OAK-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13827588#comment-13827588 ] Stefan Guggisberg commented on OAK-1200: [~dpfister], could you please have a look sometime? occasional test failure in org.apache.jackrabbit.mk.store.DefaultRevisionStoreTest -- Key: OAK-1200 URL: https://issues.apache.org/jira/browse/OAK-1200 Project: Jackrabbit Oak Issue Type: Bug Components: mk Affects Versions: 0.12 Reporter: Julian Reschke Assignee: Dominique Pfister Fix For: 0.13 Occasionally seen on W7 64bit: Tests in error: testConcurrentMergeGC(org.apache.jackrabbit.mk.store.DefaultRevisionStoreTest) : java.lang.RuntimeException: java.util.concurrent.ExecutionException: org.apache.jackrabbit.mk.store.NotFoundException: 0a9706e6ec0320c779cd6f775910826e79c97f58 --- Test set: org.apache.jackrabbit.mk.store.DefaultRevisionStoreTest --- Tests run: 5, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 11.377 sec FAILURE! testConcurrentMergeGC(org.apache.jackrabbit.mk.store.DefaultRevisionStoreTest) Time elapsed: 0.151 sec ERROR! org.apache.jackrabbit.mk.api.MicroKernelException: java.lang.RuntimeException: java.util.concurrent.ExecutionException: org.apache.jackrabbit.mk.store.NotFoundException: 0a9706e6ec0320c779cd6f775910826e79c97f58 at org.apache.jackrabbit.mk.core.MicroKernelImpl.merge(MicroKernelImpl.java:557) at org.apache.jackrabbit.mk.store.DefaultRevisionStoreTest.testConcurrentMergeGC(DefaultRevisionStoreTest.java:193) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:172) at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:104) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:70) Caused by: java.lang.RuntimeException: java.util.concurrent.ExecutionException: org.apache.jackrabbit.mk.store.NotFoundException: 0a9706e6ec0320c779cd6f775910826e79c97f58 at org.apache.jackrabbit.mk.model.TraversingNodeDiffHandler.childNodeChanged(TraversingNodeDiffHandler.java:53) at
[jira] [Reopened] (OAK-587) DefaultRevisionStoreTest.testConcurrentGC fails every now and then.
[ https://issues.apache.org/jira/browse/OAK-587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg reopened OAK-587: --- reopening since test still occur DefaultRevisionStoreTest.testConcurrentGC fails every now and then. --- Key: OAK-587 URL: https://issues.apache.org/jira/browse/OAK-587 Project: Jackrabbit Oak Issue Type: Bug Components: mk Reporter: angela Assignee: Stefan Guggisberg Fix For: 0.11 Attachments: OAK-587_aggressive_test.patch i marked the failing test with @Ignore. it would be nice though if someone could investigate why the test is failing. thanks. Tests in error: testConcurrentGC(org.apache.jackrabbit.mk.store.DefaultRevisionStoreTest): java.util.concurrent.ExecutionException: org.apache.jackrabbit.mk.store.NotFoundException: 78a45769aec95b5abf0a8d6b75d3ff2648069bd1 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (OAK-587) DefaultRevisionStoreTest.testConcurrentGC fails every now and then.
[ https://issues.apache.org/jira/browse/OAK-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13826630#comment-13826630 ] Stefan Guggisberg commented on OAK-587: --- i wasn't able to reproduce the issue anymore on my machine using the aggressive GC test. obviously the issue still exists. :( ~dpfister, could you please have a look sometime? DefaultRevisionStoreTest.testConcurrentGC fails every now and then. --- Key: OAK-587 URL: https://issues.apache.org/jira/browse/OAK-587 Project: Jackrabbit Oak Issue Type: Bug Components: mk Reporter: angela Assignee: Stefan Guggisberg Fix For: 0.11 Attachments: OAK-587_aggressive_test.patch i marked the failing test with @Ignore. it would be nice though if someone could investigate why the test is failing. thanks. Tests in error: testConcurrentGC(org.apache.jackrabbit.mk.store.DefaultRevisionStoreTest): java.util.concurrent.ExecutionException: org.apache.jackrabbit.mk.store.NotFoundException: 78a45769aec95b5abf0a8d6b75d3ff2648069bd1 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (OAK-587) DefaultRevisionStoreTest.testConcurrentGC fails every now and then.
[ https://issues.apache.org/jira/browse/OAK-587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg reassigned OAK-587: - Assignee: Dominique Pfister (was: Stefan Guggisberg) DefaultRevisionStoreTest.testConcurrentGC fails every now and then. --- Key: OAK-587 URL: https://issues.apache.org/jira/browse/OAK-587 Project: Jackrabbit Oak Issue Type: Bug Components: mk Reporter: angela Assignee: Dominique Pfister Fix For: 0.11 Attachments: OAK-587_aggressive_test.patch i marked the failing test with @Ignore. it would be nice though if someone could investigate why the test is failing. thanks. Tests in error: testConcurrentGC(org.apache.jackrabbit.mk.store.DefaultRevisionStoreTest): java.util.concurrent.ExecutionException: org.apache.jackrabbit.mk.store.NotFoundException: 78a45769aec95b5abf0a8d6b75d3ff2648069bd1 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (OAK-587) DefaultRevisionStoreTest.testConcurrentGC fails every now and then.
[ https://issues.apache.org/jira/browse/OAK-587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg resolved OAK-587. --- Resolution: Fixed fixed in svn rev. 1542292 DefaultRevisionStoreTest.testConcurrentGC fails every now and then. --- Key: OAK-587 URL: https://issues.apache.org/jira/browse/OAK-587 Project: Jackrabbit Oak Issue Type: Bug Components: mk Reporter: angela Assignee: Stefan Guggisberg Fix For: 0.12 Attachments: OAK-587_aggressive_test.patch i marked the failing test with @Ignore. it would be nice though if someone could investigate why the test is failing. thanks. Tests in error: testConcurrentGC(org.apache.jackrabbit.mk.store.DefaultRevisionStoreTest): java.util.concurrent.ExecutionException: org.apache.jackrabbit.mk.store.NotFoundException: 78a45769aec95b5abf0a8d6b75d3ff2648069bd1 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (OAK-504) DefaultRevisionStore: Exception occurred in GC cycle: NotFoundException
[
https://issues.apache.org/jira/browse/OAK-504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg reassigned OAK-504:
-
Assignee: Stefan Guggisberg
DefaultRevisionStore: Exception occurred in GC cycle: NotFoundException
---
Key: OAK-504
URL: https://issues.apache.org/jira/browse/OAK-504
Project: Jackrabbit Oak
Issue Type: Bug
Components: mk
Reporter: Jukka Zitting
Assignee: Stefan Guggisberg
I'm seeing lots of exceptions like the following when running Oak with the
default MK for a longer time:
{noformat}
org.apache.jackrabbit.mk.store.DefaultRevisionStore Exception occurred in GC
cycle org.apache.jackrabbit.mk.store.NotFoundException:
c29d5b5b12291a2a4f18be8d4f7fe1a70136eb57
at
org.apache.jackrabbit.mk.persistence.H2Persistence.readNode(H2Persistence.java:155)
at
org.apache.jackrabbit.mk.store.DefaultRevisionStore.getNode(DefaultRevisionStore.java:366)
at
org.apache.jackrabbit.mk.store.DefaultRevisionStore.markNode(DefaultRevisionStore.java:696)
at
org.apache.jackrabbit.mk.store.DefaultRevisionStore.markNode(DefaultRevisionStore.java:696)
at
org.apache.jackrabbit.mk.store.DefaultRevisionStore.markNode(DefaultRevisionStore.java:696)
at
org.apache.jackrabbit.mk.store.DefaultRevisionStore.markNode(DefaultRevisionStore.java:696)
at
org.apache.jackrabbit.mk.store.DefaultRevisionStore.markNode(DefaultRevisionStore.java:696)
at
org.apache.jackrabbit.mk.store.DefaultRevisionStore.markNode(DefaultRevisionStore.java:696)
at
org.apache.jackrabbit.mk.store.DefaultRevisionStore.markNode(DefaultRevisionStore.java:696)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (OAK-504) DefaultRevisionStore: Exception occurred in GC cycle: NotFoundException
[
https://issues.apache.org/jira/browse/OAK-504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg resolved OAK-504.
---
Resolution: Fixed
Fix Version/s: 0.12
fixed through resolution of OAK-587.
DefaultRevisionStore: Exception occurred in GC cycle: NotFoundException
---
Key: OAK-504
URL: https://issues.apache.org/jira/browse/OAK-504
Project: Jackrabbit Oak
Issue Type: Bug
Components: mk
Reporter: Jukka Zitting
Assignee: Stefan Guggisberg
Fix For: 0.12
I'm seeing lots of exceptions like the following when running Oak with the
default MK for a longer time:
{noformat}
org.apache.jackrabbit.mk.store.DefaultRevisionStore Exception occurred in GC
cycle org.apache.jackrabbit.mk.store.NotFoundException:
c29d5b5b12291a2a4f18be8d4f7fe1a70136eb57
at
org.apache.jackrabbit.mk.persistence.H2Persistence.readNode(H2Persistence.java:155)
at
org.apache.jackrabbit.mk.store.DefaultRevisionStore.getNode(DefaultRevisionStore.java:366)
at
org.apache.jackrabbit.mk.store.DefaultRevisionStore.markNode(DefaultRevisionStore.java:696)
at
org.apache.jackrabbit.mk.store.DefaultRevisionStore.markNode(DefaultRevisionStore.java:696)
at
org.apache.jackrabbit.mk.store.DefaultRevisionStore.markNode(DefaultRevisionStore.java:696)
at
org.apache.jackrabbit.mk.store.DefaultRevisionStore.markNode(DefaultRevisionStore.java:696)
at
org.apache.jackrabbit.mk.store.DefaultRevisionStore.markNode(DefaultRevisionStore.java:696)
at
org.apache.jackrabbit.mk.store.DefaultRevisionStore.markNode(DefaultRevisionStore.java:696)
at
org.apache.jackrabbit.mk.store.DefaultRevisionStore.markNode(DefaultRevisionStore.java:696)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (OAK-436) apache.jackrabbit.mk.store.NotFoundException
[
https://issues.apache.org/jira/browse/OAK-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg resolved OAK-436.
---
Resolution: Fixed
fixed through resolution of OAK-587.
apache.jackrabbit.mk.store.NotFoundException
Key: OAK-436
URL: https://issues.apache.org/jira/browse/OAK-436
Project: Jackrabbit Oak
Issue Type: Bug
Components: mk
Reporter: Michael Dürig
Assignee: Stefan Guggisberg
Fix For: 0.12
First
{code}
09.11.2012 11:42:46.941 *ERROR* [0:0:0:0:0:0:0:1%0 [1352460476169] POST
/crx/packmgr/service/script.html/etc/packages/day/cq560/product/cq-content-5.6.0.SNAPSHOT.20121109.zip
HTTP/1.1] com.day.jcr.vault.packaging.impl.ZipVaultPackage Error during
install. org.apache.jackrabbit.mk.api.MicroKernelException:
java.lang.RuntimeException: Unexpected error
at
org.apache.jackrabbit.mk.core.MicroKernelImpl.nodeExists(MicroKernelImpl.java:321)
at
org.apache.jackrabbit.oak.kernel.KernelNodeState.getChildNode(KernelNodeState.java:168)
at
org.apache.jackrabbit.oak.spi.state.AbstractNodeState.hasChildNode(AbstractNodeState.java:63)
at
org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.child(MemoryNodeBuilder.java:422)
at
org.apache.jackrabbit.oak.core.TreeImpl.getNodeBuilder(TreeImpl.java:415)
at org.apache.jackrabbit.oak.core.TreeImpl.isRemoved(TreeImpl.java:213)
at org.apache.jackrabbit.oak.core.TreeImpl.getStatus(TreeImpl.java:220)
at
org.apache.jackrabbit.oak.core.TreeImpl$NodeLocation.getStatus(TreeImpl.java:637)
at
org.apache.jackrabbit.oak.jcr.ItemDelegate.isStale(ItemDelegate.java:86)
at org.apache.jackrabbit.oak.jcr.ItemImpl.checkStatus(ItemImpl.java:159)
at org.apache.jackrabbit.oak.jcr.ItemImpl.getPath(ItemImpl.java:76)
at org.apache.jackrabbit.oak.jcr.NodeImpl.getPath(NodeImpl.java:89)
at
com.day.jcr.vault.fs.impl.io.DocViewSAXImporter.endElement(DocViewSAXImporter.java:1052)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:601)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1782)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2939)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648)
at
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
at
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
at
com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:395)
at
com.day.jcr.vault.fs.impl.io.GenericArtifactHandler.accept(GenericArtifactHandler.java:102)
at com.day.jcr.vault.fs.io.Importer.commit(Importer.java:852)
at com.day.jcr.vault.fs.io.Importer.commit(Importer.java:760)
at com.day.jcr.vault.fs.io.Importer.commit(Importer.java:797)
at com.day.jcr.vault.fs.io.Importer.commit(Importer.java:797)
at com.day.jcr.vault.fs.io.Importer.commit(Importer.java:797)
at com.day.jcr.vault.fs.io.Importer.commit(Importer.java:797)
at com.day.jcr.vault.fs.io.Importer.commit(Importer.java:797)
at com.day.jcr.vault.fs.io.Importer.run(Importer.java:420)
at
com.day.jcr.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:359)
at
com.day.jcr.vault.packaging.impl.JcrPackageImpl.extract(JcrPackageImpl.java:364)
at
com.day.jcr.vault.packaging.impl.JcrPackageImpl.install(JcrPackageImpl.java:337)
at
com.day.crx.packaging.impl.J2EEPackageManager.consoleInstall(J2EEPackageManager.java:327)
at
com.day.crx.packaging.impl.J2EEPackageManager.doPost(J2EEPackageManager.java:173)
at
com.day.crx.packaging.impl.PackageManagerServlet.doPost(PackageManagerServlet.java:144)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
[jira] [Resolved] (OAK-567) DiffBuilder performance problem
[
https://issues.apache.org/jira/browse/OAK-567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg resolved OAK-567.
---
Resolution: Fixed
Assignee: Stefan Guggisberg
fixed through resolution of OAK-997
DiffBuilder performance problem
---
Key: OAK-567
URL: https://issues.apache.org/jira/browse/OAK-567
Project: Jackrabbit Oak
Issue Type: Bug
Components: mk
Reporter: Thomas Mueller
Assignee: Stefan Guggisberg
Fix For: 0.13
Attachments: OAK-567.patch
The org.apache.jackrabbit.mk.model.tree.DiffBuilder is very slow because it
uses:
{code}
HashMapNodeState, String
{code}
and at the same time
{code}
class AbstractNodeState implements NodeState {
/**
* Returns a hash code that's compatible with how the
* {@link #equals(Object)} method is implemented. The current
* implementation simply returns zero for everything since
* {@link NodeState} instances are not intended for use as hash keys.
*
* @return hash code
*/
@Override
public int hashCode() {
return 0;
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (OAK-277) identical nodes with different content hash ids
[ https://issues.apache.org/jira/browse/OAK-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg resolved OAK-277. --- Resolution: Duplicate fixed through resolution of OAK-1017 identical nodes with different content hash ids --- Key: OAK-277 URL: https://issues.apache.org/jira/browse/OAK-277 Project: Jackrabbit Oak Issue Type: Bug Components: mk Reporter: Stefan Guggisberg Assignee: Stefan Guggisberg Priority: Minor the current implementation internally uses a HashMap to represent the properties of a node and child node entries collections. the sha-1 content hash is based on the byte stream serialization of the node state. properties are serialized by iterating over the entrySet collection of the HashMap. since HashMap doesn't guarantee any specific iteration order it's possible that 2 HashMaps containing the same mappings (map1.equals(maps2) == true) return the entries in different order, thus resulting in different content hashes. the iteration order needs obviously to be normalized when serializing the entries. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Reopened] (OAK-210) granularity of persisted data
[ https://issues.apache.org/jira/browse/OAK-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg reopened OAK-210: --- i don't agree with the resolution 'Incomplete'. the description is IMO pretty clear. granularity of persisted data - Key: OAK-210 URL: https://issues.apache.org/jira/browse/OAK-210 Project: Jackrabbit Oak Issue Type: Improvement Components: mk Reporter: Stefan Guggisberg Assignee: Stefan Guggisberg the current persistence granularity is _single nodes_ (a node consists of properties and child node information). instead of storing/retrieving single nodes it would IMO make sense to store subtree aggregates of specific nodes. the choice of granularity could be based on simple filter criteria (e.g. property value). dynamic persistence granularity would help reducing the number of records and r/w operations on the underlying store, thus improving performance. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (OAK-1126) Same node and property name support
[ https://issues.apache.org/jira/browse/OAK-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13813766#comment-13813766 ] Stefan Guggisberg commented on OAK-1126: bq. AFAICT the only change to the JSOP format would be to adjust the addNode syntax to use the :children mechanism for child nodes. that's what i meant by json_diff format changes. it's IMO a drastic change since it makes importing arbitrary JSON impossible (or at least very awkward). Same node and property name support --- Key: OAK-1126 URL: https://issues.apache.org/jira/browse/OAK-1126 Project: Jackrabbit Oak Issue Type: Sub-task Components: core, doc, jcr Reporter: Tobias Bocanegra Attachments: 0001-OAK-1126-Same-node-and-property-name-support.patch, 0002-OAK-1126-Same-node-and-property-name-support.patch, OAK-1126.patch The initial MK abstraction mandated that the nodes and properties share the same namespace (http://wiki.apache.org/jackrabbit/RepositoryMicroKernel#Data%20Model). This is a regression from Jackrabbit 2.x, which supports same name nodes and properties (SNNP). OTOH, the NodeStores can easily support SNNP and with proper escaping, the MKs can also support it. We should try to keep the support for SNNP in order to keep backward compatibility for existing content, and also keep the support for importing XML documents with same attribute and element names. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (OAK-1126) Same node and property name support
[ https://issues.apache.org/jira/browse/OAK-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13813798#comment-13813798 ] Stefan Guggisberg commented on OAK-1126: bq. This was never a use case. From the beginning on oak-core was deemed to be the only client to the MicroKernel ever. i beg to differ. the MicroKernel API was designed to be portable from scratch. therefore it's obvious that it's possible to implement and use it in different languages/stacks (e.g. c, nodejs, etc). Same node and property name support --- Key: OAK-1126 URL: https://issues.apache.org/jira/browse/OAK-1126 Project: Jackrabbit Oak Issue Type: Sub-task Components: core, doc, jcr Reporter: Tobias Bocanegra Attachments: 0001-OAK-1126-Same-node-and-property-name-support.patch, 0002-OAK-1126-Same-node-and-property-name-support.patch, OAK-1126.patch The initial MK abstraction mandated that the nodes and properties share the same namespace (http://wiki.apache.org/jackrabbit/RepositoryMicroKernel#Data%20Model). This is a regression from Jackrabbit 2.x, which supports same name nodes and properties (SNNP). OTOH, the NodeStores can easily support SNNP and with proper escaping, the MKs can also support it. We should try to keep the support for SNNP in order to keep backward compatibility for existing content, and also keep the support for importing XML documents with same attribute and element names. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (OAK-210) granularity of persisted data
[ https://issues.apache.org/jira/browse/OAK-210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13813972#comment-13813972 ] Stefan Guggisberg commented on OAK-210: --- bq. Fair enough. Do you still intend to work on this (it's been open for over a year)? If not, I suggest to resolve as Won't Fix. yes, i intend to work on this. however, i cannot commit a specific timeline. i prefer to keep this issue open. granularity of persisted data - Key: OAK-210 URL: https://issues.apache.org/jira/browse/OAK-210 Project: Jackrabbit Oak Issue Type: Improvement Components: mk Reporter: Stefan Guggisberg Assignee: Stefan Guggisberg the current persistence granularity is _single nodes_ (a node consists of properties and child node information). instead of storing/retrieving single nodes it would IMO make sense to store subtree aggregates of specific nodes. the choice of granularity could be based on simple filter criteria (e.g. property value). dynamic persistence granularity would help reducing the number of records and r/w operations on the underlying store, thus improving performance. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (OAK-1126) Same node and property name support
[ https://issues.apache.org/jira/browse/OAK-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812930#comment-13812930 ] Stefan Guggisberg commented on OAK-1126: bq. If we do apply the patch, we should also update relevant parts of the MicroKernel API and adjust the NodeStore documentation accordingly. -1 for changing the MicroKernel API until we have a clear picture of the full impact of such API changes. the change would e.g. also affect the commit method and the json_diff format. those changes, if we agree on them, need to be carefully documented. Same node and property name support --- Key: OAK-1126 URL: https://issues.apache.org/jira/browse/OAK-1126 Project: Jackrabbit Oak Issue Type: Sub-task Components: core, doc, jcr Reporter: Tobias Bocanegra Attachments: OAK-1126.patch The initial MK abstraction mandated that the nodes and properties share the same namespace (http://wiki.apache.org/jackrabbit/RepositoryMicroKernel#Data%20Model). This is a regression from Jackrabbit 2.x, which supports same name nodes and properties (SNNP). OTOH, the NodeStores can easily support SNNP and with proper escaping, the MKs can also support it. We should try to keep the support for SNNP in order to keep backward compatibility for existing content, and also keep the support for importing XML documents with same attribute and element names. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (OAK-1126) Same node and property name support
[ https://issues.apache.org/jira/browse/OAK-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13810184#comment-13810184 ] Stefan Guggisberg commented on OAK-1126: my main concern regarding SNNP is that it breaks the intuitive 1:1 JSON representation of repository content. artificial intermediary objects like e.g. :children are IMO non-intuitive and lead to awkward client code on the JSON consumer side. as discussed on the list: http://markmail.org/message/procpdcyctcibxdt Same node and property name support --- Key: OAK-1126 URL: https://issues.apache.org/jira/browse/OAK-1126 Project: Jackrabbit Oak Issue Type: Sub-task Components: core, doc, jcr Reporter: Tobias Bocanegra Attachments: OAK-1126.patch The initial MK abstraction mandated that the nodes and properties share the same namespace (http://wiki.apache.org/jackrabbit/RepositoryMicroKernel#Data%20Model). This is a regression from Jackrabbit 2.x, which supports same name nodes and properties (SNNP). OTOH, the NodeStores can easily support SNNP and with proper escaping, the MKs can also support it. We should try to keep the support for SNNP in order to keep backward compatibility for existing content, and also keep the support for importing XML documents with same attribute and element names. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (OAK-997) cleanup codebase: remove unneeded internal abstraction
[ https://issues.apache.org/jira/browse/OAK-997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg resolved OAK-997. --- Resolution: Fixed Fix Version/s: 0.9 done in rev. 1520046 cleanup codebase: remove unneeded internal abstraction -- Key: OAK-997 URL: https://issues.apache.org/jira/browse/OAK-997 Project: Jackrabbit Oak Issue Type: Improvement Components: mk Reporter: Stefan Guggisberg Assignee: Stefan Guggisberg Fix For: 0.9 the internal tree abstraction hides an essential implementation detail (content-hash based identifiers) from the very implementation, leading to confusing and sometimes awkward code. furthermore there's a considerable amount of code duplication. this internal tree abstraction should be removed for the sake of a cleaner codebase. -- 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] [Created] (OAK-997) cleanup codebase: remove unneeded internal abstraction
Stefan Guggisberg created OAK-997: - Summary: cleanup codebase: remove unneeded internal abstraction Key: OAK-997 URL: https://issues.apache.org/jira/browse/OAK-997 Project: Jackrabbit Oak Issue Type: Improvement Components: mk Reporter: Stefan Guggisberg Assignee: Stefan Guggisberg the internal tree abstraction hides an essential implementation detail (content-hash based identifiers) from the very implementation, leading to confusing and sometimes awkward code. furthermore there's a considerable amount of code duplication. this internal tree abstraction should be removed for the sake of a cleaner codebase. -- 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] [Resolved] (OAK-979) MicroKernel.diff() returns incomplete JSON when moves are involved (H2)
[
https://issues.apache.org/jira/browse/OAK-979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg resolved OAK-979.
---
Resolution: Fixed
Fix Version/s: 0.9
Assignee: Stefan Guggisberg
fixed in revision 1519368.
MicroKernel.diff() returns incomplete JSON when moves are involved (H2)
---
Key: OAK-979
URL: https://issues.apache.org/jira/browse/OAK-979
Project: Jackrabbit Oak
Issue Type: Bug
Components: mk
Reporter: Michael Dürig
Assignee: Stefan Guggisberg
Fix For: 0.9
Given the base revision
{code}
{a:{b:{}}
{code}
and the head revision
{code}
{a:{c:{},d:{}}
{code}
{{MicroKernel.diff}} will miss one of the added nodes {{c}} or {{d}}.
This only affects the H2 based MicroKernel
--
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] [Created] (OAK-987) Implement the MicroKernel API
Stefan Guggisberg created OAK-987: - Summary: Implement the MicroKernel API Key: OAK-987 URL: https://issues.apache.org/jira/browse/OAK-987 Project: Jackrabbit Oak Issue Type: Sub-task Components: segmentmk Reporter: Stefan Guggisberg -- 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] [Assigned] (OAK-976) MicroKernel.diff() returns invalid JSON (H2)
[
https://issues.apache.org/jira/browse/OAK-976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg reassigned OAK-976:
-
Assignee: Stefan Guggisberg
MicroKernel.diff() returns invalid JSON (H2)
Key: OAK-976
URL: https://issues.apache.org/jira/browse/OAK-976
Project: Jackrabbit Oak
Issue Type: Bug
Components: mk
Reporter: Michael Dürig
Assignee: Stefan Guggisberg
{{MicroKernel.diff()}} returns sometimes
{code}
^/root/N2352
/root/N2727:/root/N2733
{code}
which should be
{code}
^/root/N2352:{}
/root/N2727:/root/N2733
{code}
This only happens with the H2 based MicroKernel. MongoMK is fine.
--
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] [Resolved] (OAK-976) MicroKernel.diff() returns invalid JSON (H2)
[
https://issues.apache.org/jira/browse/OAK-976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg resolved OAK-976.
---
Resolution: Fixed
Fix Version/s: 0.9
fixed in svn r1517125.
MicroKernel.diff() returns invalid JSON (H2)
Key: OAK-976
URL: https://issues.apache.org/jira/browse/OAK-976
Project: Jackrabbit Oak
Issue Type: Bug
Components: mk
Reporter: Michael Dürig
Assignee: Stefan Guggisberg
Fix For: 0.9
{{MicroKernel.diff()}} returns sometimes
{code}
^/root/N2352
/root/N2727:/root/N2733
{code}
which should be
{code}
^/root/N2352:{}
/root/N2727:/root/N2733
{code}
This only happens with the H2 based MicroKernel. MongoMK is fine.
--
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-638) Avoid branch/merge for small commits
[ https://issues.apache.org/jira/browse/OAK-638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13581230#comment-13581230 ] Stefan Guggisberg commented on OAK-638: --- bq. This pretty much means we should push down handling of the transient space to the MK implementation. I don't think the MK was designed with this in mind. My understanding so far is that we handle transient operations in oak-jcr (to a certain amount: RootImpl#PURGE_LIMIT) and persist those changes to a branch once over the limit. +1, that's my understanding as well (see OAK-162). Avoid branch/merge for small commits Key: OAK-638 URL: https://issues.apache.org/jira/browse/OAK-638 Project: Jackrabbit Oak Issue Type: Improvement Components: core Reporter: Marcel Reutegger Priority: Minor The branch/merge features on the MicroKernel were initially introduced to stage changes of large commits. Currently oak-core creates a branch even for small changes like updating a property. I think this introduces quite some overhead for scenarios with highly concurrent updates. E.g. think of a twitter like application or a forum with comments. Well, basically user generated content. These update tend to be rather small (couple of nodes) but frequent and concurrent. Right now oak-core always does: - MK.branch() - MK.commit() to branch - MK.merge() For small commits, it ideally should do: - MK.commit() to trunk -- 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-567) DiffBuilder performance problem
[
https://issues.apache.org/jira/browse/OAK-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13557054#comment-13557054
]
Stefan Guggisberg commented on OAK-567:
---
bq. Couldn't the NodeState implementations in question (StoreNodeAsState
AFAICS) just use their id to implement hashCode()?
indeed, good catch!
DiffBuilder performance problem
---
Key: OAK-567
URL: https://issues.apache.org/jira/browse/OAK-567
Project: Jackrabbit Oak
Issue Type: Bug
Components: mk
Reporter: Thomas Mueller
Attachments: OAK-567.patch
The org.apache.jackrabbit.mk.model.tree.DiffBuilder is very slow because it
uses:
{code}
HashMapNodeState, String
{code}
and at the same time
{code}
class AbstractNodeState implements NodeState {
/**
* Returns a hash code that's compatible with how the
* {@link #equals(Object)} method is implemented. The current
* implementation simply returns zero for everything since
* {@link NodeState} instances are not intended for use as hash keys.
*
* @return hash code
*/
@Override
public int hashCode() {
return 0;
}
}
{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] [Commented] (OAK-567) DiffBuilder performance problem
[
https://issues.apache.org/jira/browse/OAK-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13557085#comment-13557085
]
Stefan Guggisberg commented on OAK-567:
---
the problem IMO is that DiffBuilder uses the tree abstraction (NodeState et al,
OAK-3) instead of StoredNode as in the original implementation. NodeState hides
the internal content-hash identifier which is central feature of this
microkernel implementation.
i'd rather change NodeBuilder to use the internal StoredNode objects again.
alternatively, we could provide another implementation leveraging the
content-hash identifiers of stored nodes.
DiffBuilder performance problem
---
Key: OAK-567
URL: https://issues.apache.org/jira/browse/OAK-567
Project: Jackrabbit Oak
Issue Type: Bug
Components: mk
Reporter: Thomas Mueller
Attachments: OAK-567.patch
The org.apache.jackrabbit.mk.model.tree.DiffBuilder is very slow because it
uses:
{code}
HashMapNodeState, String
{code}
and at the same time
{code}
class AbstractNodeState implements NodeState {
/**
* Returns a hash code that's compatible with how the
* {@link #equals(Object)} method is implemented. The current
* implementation simply returns zero for everything since
* {@link NodeState} instances are not intended for use as hash keys.
*
* @return hash code
*/
@Override
public int hashCode() {
return 0;
}
}
{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] [Commented] (OAK-567) DiffBuilder performance problem
[
https://issues.apache.org/jira/browse/OAK-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13556379#comment-13556379
]
Stefan Guggisberg commented on OAK-567:
---
bq. The org.apache.jackrabbit.mk.model.tree.DiffBuilder is very slow because it
uses:
bq. HashMapNodeState, String
i agree that needs to be fixed. i've refactored the DiffBuilder code from the
mk diff method implementation into a separate class. the original
implementation used the the (content hash) id's as keys (as documented inline).
however, during the refactoring i had to change to using NodeState instances
(from the tree abstraction), which don't expose the id... :(
ideally the DiffBuilder should use the id's again.
DiffBuilder performance problem
---
Key: OAK-567
URL: https://issues.apache.org/jira/browse/OAK-567
Project: Jackrabbit Oak
Issue Type: Bug
Components: mk
Reporter: Thomas Mueller
The org.apache.jackrabbit.mk.model.tree.DiffBuilder is very slow because it
uses:
{code}
HashMapNodeState, String
{code}
and at the same time
{code}
class AbstractNodeState implements NodeState {
/**
* Returns a hash code that's compatible with how the
* {@link #equals(Object)} method is implemented. The current
* implementation simply returns zero for everything since
* {@link NodeState} instances are not intended for use as hash keys.
*
* @return hash code
*/
@Override
public int hashCode() {
return 0;
}
}
{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] [Comment Edited] (OAK-567) DiffBuilder performance problem
[
https://issues.apache.org/jira/browse/OAK-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13556379#comment-13556379
]
Stefan Guggisberg edited comment on OAK-567 at 1/17/13 5:10 PM:
bq. The org.apache.jackrabbit.mk.model.tree.DiffBuilder is very slow because it
uses:
bq. HashMapNodeState, String
i agree that needs to be fixed. i've refactored the DiffBuilder code from the
mk diff method implementation into a separate class. the original
implementation used the (content hash) id's as keys (as documented inline).
however, during the refactoring i had to change to using NodeState instances
(from the tree abstraction), which don't expose the id... :(
ideally the DiffBuilder should use the id's again.
was (Author: stefan@jira):
bq. The org.apache.jackrabbit.mk.model.tree.DiffBuilder is very slow
because it uses:
bq. HashMapNodeState, String
i agree that needs to be fixed. i've refactored the DiffBuilder code from the
mk diff method implementation into a separate class. the original
implementation used the the (content hash) id's as keys (as documented inline).
however, during the refactoring i had to change to using NodeState instances
(from the tree abstraction), which don't expose the id... :(
ideally the DiffBuilder should use the id's again.
DiffBuilder performance problem
---
Key: OAK-567
URL: https://issues.apache.org/jira/browse/OAK-567
Project: Jackrabbit Oak
Issue Type: Bug
Components: mk
Reporter: Thomas Mueller
The org.apache.jackrabbit.mk.model.tree.DiffBuilder is very slow because it
uses:
{code}
HashMapNodeState, String
{code}
and at the same time
{code}
class AbstractNodeState implements NodeState {
/**
* Returns a hash code that's compatible with how the
* {@link #equals(Object)} method is implemented. The current
* implementation simply returns zero for everything since
* {@link NodeState} instances are not intended for use as hash keys.
*
* @return hash code
*/
@Override
public int hashCode() {
return 0;
}
}
{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] [Resolved] (OAK-543) PutTokenImpl not thread safe
[
https://issues.apache.org/jira/browse/OAK-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg resolved OAK-543.
---
Resolution: Fixed
Fix Version/s: 0.6
fixed in svn r1430761.
thanks for providing a patch!
PutTokenImpl not thread safe
Key: OAK-543
URL: https://issues.apache.org/jira/browse/OAK-543
Project: Jackrabbit Oak
Issue Type: Bug
Components: mk
Reporter: Michael Dürig
Assignee: Stefan Guggisberg
Fix For: 0.6
Attachments: OAK-543.patch
{{PutTokenImpl}} uses prefix increment on a static member to generate
presumably unique identifiers. Prefix increment is not atomic though which
might result in non unique ids being generated.
--
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-366) MongoDB microkernal integration with OSGi
[ https://issues.apache.org/jira/browse/OAK-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg updated OAK-366: -- Component/s: (was: mk) mongomk MongoDB microkernal integration with OSGi - Key: OAK-366 URL: https://issues.apache.org/jira/browse/OAK-366 Project: Jackrabbit Oak Issue Type: Sub-task Components: mongomk Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Labels: osgi Original Estimate: 2m Remaining Estimate: 2m Need to convert the oak-mongomk module to an OSGi bundle and expose the MongoMicroKernel as OSGi service -- 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-351) Inconsistency issue when committing a new node under an old parent
[ https://issues.apache.org/jira/browse/OAK-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg updated OAK-351: -- Component/s: (was: mk) mongomk Inconsistency issue when committing a new node under an old parent -- Key: OAK-351 URL: https://issues.apache.org/jira/browse/OAK-351 Project: Jackrabbit Oak Issue Type: Bug Components: mongomk Environment: all Reporter: Tudor Rogoz Attachments: OAK-351-automatedTest.patch Commit the following node structure: Commit 1: /a Commit 2: /a/b Commit 3: /a/b/c Commit 4: /a/d Commit will fail with the following exception: java.lang.RuntimeException: No such parent: a Note 1: After the commit 3 if I run the following code NodeExistsCommandMongo command2 = new NodeExistsCommandMongo( mongoConnection, /a, null); boolean exists = command2.execute(); exist will be true, so the node is visible for NodeExistsCommandMongo class. Note 2: I created an automated test for this issue CommitCommandMongoTest.commitNodeOldParent -- 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-333) 1000 character path limit in MongoMK
[ https://issues.apache.org/jira/browse/OAK-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg updated OAK-333: -- Component/s: (was: mk) 1000 character path limit in MongoMK Key: OAK-333 URL: https://issues.apache.org/jira/browse/OAK-333 Project: Jackrabbit Oak Issue Type: Bug Components: mongomk Affects Versions: 0.5 Reporter: Mete Atamel Assignee: Mete Atamel Priority: Minor Attachments: OAK-333.patch In an infinite loop try to add nodes one under another to have N0/N1/N2...NN. At some point, the current parent node will not be found and the current commit will fail. I think this happens when the path length exceeds 1000 characters. Is this enough for a path? I was able to create this way only 222 levels in the tree (and my node names were really short N1, N2 ...) There's an automated tests for this: NodeExistsCommandMongoTest.testTreeDepth -- 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] [Assigned] (OAK-543) PutTokenImpl not thread safe
[
https://issues.apache.org/jira/browse/OAK-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg reassigned OAK-543:
-
Assignee: Stefan Guggisberg
PutTokenImpl not thread safe
Key: OAK-543
URL: https://issues.apache.org/jira/browse/OAK-543
Project: Jackrabbit Oak
Issue Type: Bug
Components: mk
Reporter: Michael Dürig
Assignee: Stefan Guggisberg
Attachments: OAK-543.patch
{{PutTokenImpl}} uses prefix increment on a static member to generate
presumably unique identifiers. Prefix increment is not atomic though which
might result in non unique ids being generated.
--
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] [Assigned] (OAK-539) Wrong compareTo in micro-kernel Id class
[
https://issues.apache.org/jira/browse/OAK-539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg reassigned OAK-539:
-
Assignee: Stefan Guggisberg
Wrong compareTo in micro-kernel Id class
Key: OAK-539
URL: https://issues.apache.org/jira/browse/OAK-539
Project: Jackrabbit Oak
Issue Type: Bug
Components: mk
Affects Versions: 0.6
Reporter: Alex Rodriguez
Assignee: Stefan Guggisberg
Attachments: 67384d1ea6969347b87a8ec7a4f8dcc972f543a7.patch.txt
CompareTo method in Id class fails in some cases.
{code}
// this works
final Id id1 = Id.fromString( 0007 );
final Id id2 = Id.fromString( 000c );
assertTrue( id1 + should be less than + id2, id1.compareTo( id2 ) 0 );
// but this doesn't
final Id id1 = Id.fromString( 0070 );
final Id id2 = Id.fromString( 00c0 );
assertTrue( id1 + should be less than + id2, id1.compareTo( id2 ) 0 );
{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] [Assigned] (OAK-532) Inconsistent journal with concurrent updates
[ https://issues.apache.org/jira/browse/OAK-532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg reassigned OAK-532: - Assignee: Stefan Guggisberg Inconsistent journal with concurrent updates Key: OAK-532 URL: https://issues.apache.org/jira/browse/OAK-532 Project: Jackrabbit Oak Issue Type: Bug Components: mk Reporter: Michael Dürig Assignee: Stefan Guggisberg As discussed on the list [1] the journal might be inconsistent when merges are involved. [1] http://markmail.org/message/4xwfwbax3kpoysbp -- 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] [Assigned] (OAK-501) Add journal support for branches
[
https://issues.apache.org/jira/browse/OAK-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg reassigned OAK-501:
-
Assignee: Stefan Guggisberg
Add journal support for branches
Key: OAK-501
URL: https://issues.apache.org/jira/browse/OAK-501
Project: Jackrabbit Oak
Issue Type: New Feature
Components: mk, mongomk
Reporter: Michael Dürig
Assignee: Stefan Guggisberg
Currently the Microkernel does not support {{getJournal}} calls for branch
revisions. In order to make progress on OAK-464 [1], we would need that
support.
[1]
https://issues.apache.org/jira/browse/OAK-464?focusedCommentId=13528947page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13528947
--
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] [Resolved] (OAK-501) Add journal support for branches
[
https://issues.apache.org/jira/browse/OAK-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg resolved OAK-501.
---
Resolution: Fixed
Fix Version/s: 0.6
fixed in svn r1420717
the following ranges are are additionally supported:
- from/to within same private branch
- from an ancestor head to a descendent private branch rev
Add journal support for branches
Key: OAK-501
URL: https://issues.apache.org/jira/browse/OAK-501
Project: Jackrabbit Oak
Issue Type: New Feature
Components: mk, mongomk
Reporter: Michael Dürig
Assignee: Stefan Guggisberg
Fix For: 0.6
Currently the Microkernel does not support {{getJournal}} calls for branch
revisions. In order to make progress on OAK-464 [1], we would need that
support.
[1]
https://issues.apache.org/jira/browse/OAK-464?focusedCommentId=13528947page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13528947
--
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] [Assigned] (OAK-468) Identifier- or hash-based access in the MicroKernel
[ https://issues.apache.org/jira/browse/OAK-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg reassigned OAK-468: - Assignee: Stefan Guggisberg Identifier- or hash-based access in the MicroKernel --- Key: OAK-468 URL: https://issues.apache.org/jira/browse/OAK-468 Project: Jackrabbit Oak Issue Type: Improvement Components: mk Reporter: Jukka Zitting Assignee: Stefan Guggisberg Attachments: 0001-OAK-468-Identifier-or-hash-based-access-in-the-Micro.patch As discussed on oak-dev@ (http://markmail.org/message/nnsyvzfhy2k26xvb), it would be useful for the MicroKernel to be able to optionally provide identifier- or hash-based access to content as an alternative to always addressing content by full path. -- 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] [Resolved] (OAK-468) Identifier- or hash-based access in the MicroKernel
[ https://issues.apache.org/jira/browse/OAK-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg resolved OAK-468. --- Resolution: Fixed committed API changes, MicroKernelImpl support and adapted integration tests in svn r1412898 Identifier- or hash-based access in the MicroKernel --- Key: OAK-468 URL: https://issues.apache.org/jira/browse/OAK-468 Project: Jackrabbit Oak Issue Type: Improvement Components: mk Reporter: Jukka Zitting Assignee: Stefan Guggisberg Attachments: 0001-OAK-468-Identifier-or-hash-based-access-in-the-Micro.patch As discussed on oak-dev@ (http://markmail.org/message/nnsyvzfhy2k26xvb), it would be useful for the MicroKernel to be able to optionally provide identifier- or hash-based access to content as an alternative to always addressing content by full path. -- 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] [Created] (OAK-384) get rid of add-property json diff syntax
Stefan Guggisberg created OAK-384: - Summary: get rid of add-property json diff syntax Key: OAK-384 URL: https://issues.apache.org/jira/browse/OAK-384 Project: Jackrabbit Oak Issue Type: Improvement Components: mk Reporter: Stefan Guggisberg Assignee: Stefan Guggisberg Priority: Minor as discussed on the oak-dev list [0] i propose to remove/disallow the add-property json diff syntax, i.e. +/some/prop:some val the set-property syntax (^/some/prop:some val) is used to modify an existing property or create one if doesn't exist yet. [0] http://apache.markmail.org/thread/3mc3bah2evvfd3ut -- 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
