You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "angela (Created) (JIRA)" <ji...@apache.org> on 2011/10/05 14:50:34 UTC
[jira] [Created] (JCR-3093) Inconsistency between
Session.getProperty and Node.getProperty for binary values
Inconsistency between Session.getProperty and Node.getProperty for binary values
--------------------------------------------------------------------------------
Key: JCR-3093
URL: https://issues.apache.org/jira/browse/JCR-3093
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-spi2dav
Reporter: angela
there an inconsistency in the binary handling between the batch-reading facility and those cases where a property is directly
accessed without having accessed the parent node before.
this issue came up with timothee maret running into performance issues when retrieving the length of a binary property:
if the property-entry has been created in the run of a batch-read operation the corresponding property-data object
contains internal values that contain the length of the binary (such as transported with the json response) and only
read the data from the server if the value stream is explicitly requested.
however, if the property is accessed directly (e.g. Session.getProperty or Node.getProperty with a relative path)
a GET request is made to the corresponding dav resource and the stream is read immediately.
possible solution:
if RepositoryService#getItemInfos(SessionInfo, ItemId) is called with a PropertyId the implementation
should not result in a GET request to the corresponding resource by calling super.getPropertyInfo(sessionInfo, (PropertyId) itemId).
instead it should be consistent with the batch-read and only make a PROPFIND request for the property
length. the returned PropertyInfo object would in that case be identical to the one generated by the batch-read functionality.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3093) Inconsistency between
Session.getProperty and Node.getProperty for binary values
Posted by "angela (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
angela updated JCR-3093:
------------------------
Fix Version/s: (was: 2.3.2)
2.3.3
> Inconsistency between Session.getProperty and Node.getProperty for binary values
> --------------------------------------------------------------------------------
>
> Key: JCR-3093
> URL: https://issues.apache.org/jira/browse/JCR-3093
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-spi2dav
> Reporter: angela
> Assignee: angela
> Fix For: 2.3.3
>
> Attachments: JCR-3093.patch
>
>
> there an inconsistency in the binary handling between the batch-reading facility and those cases where a property is directly
> accessed without having accessed the parent node before.
> this issue came up with timothee maret running into performance issues when retrieving the length of a binary property:
> if the property-entry has been created in the run of a batch-read operation the corresponding property-data object
> contains internal values that contain the length of the binary (such as transported with the json response) and only
> read the data from the server if the value stream is explicitly requested.
> however, if the property is accessed directly (e.g. Session.getProperty or Node.getProperty with a relative path)
> a GET request is made to the corresponding dav resource and the stream is read immediately.
> possible solution:
> if RepositoryService#getItemInfos(SessionInfo, ItemId) is called with a PropertyId the implementation
> should not result in a GET request to the corresponding resource by calling super.getPropertyInfo(sessionInfo, (PropertyId) itemId).
> instead it should be consistent with the batch-read and only make a PROPFIND request for the property
> length. the returned PropertyInfo object would in that case be identical to the one generated by the batch-read functionality.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3093) Inconsistency between
Session.getProperty and Node.getProperty for binary values
Posted by "angela (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13120928#comment-13120928 ]
angela commented on JCR-3093:
-----------------------------
public void testBinaryLength() throws Exception {
Node test = testRootNode.addNode("test");
Property p = test.setProperty("prop", generateValue());
superuser.save();
Session s = getHelper().getSuperuserSession();
try {
Node n = s.getNode(Text.getRelativeParent(p.getPath(), 1));
Property prop = n.getProperty("prop");
// alternative call to demonstrate the difference:
// Property prop = s.getProperty(p.getPath());
long l = prop.getLength();
} finally {
s.logout();
}
}
> Inconsistency between Session.getProperty and Node.getProperty for binary values
> --------------------------------------------------------------------------------
>
> Key: JCR-3093
> URL: https://issues.apache.org/jira/browse/JCR-3093
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-spi2dav
> Reporter: angela
>
> there an inconsistency in the binary handling between the batch-reading facility and those cases where a property is directly
> accessed without having accessed the parent node before.
> this issue came up with timothee maret running into performance issues when retrieving the length of a binary property:
> if the property-entry has been created in the run of a batch-read operation the corresponding property-data object
> contains internal values that contain the length of the binary (such as transported with the json response) and only
> read the data from the server if the value stream is explicitly requested.
> however, if the property is accessed directly (e.g. Session.getProperty or Node.getProperty with a relative path)
> a GET request is made to the corresponding dav resource and the stream is read immediately.
> possible solution:
> if RepositoryService#getItemInfos(SessionInfo, ItemId) is called with a PropertyId the implementation
> should not result in a GET request to the corresponding resource by calling super.getPropertyInfo(sessionInfo, (PropertyId) itemId).
> instead it should be consistent with the batch-read and only make a PROPFIND request for the property
> length. the returned PropertyInfo object would in that case be identical to the one generated by the batch-read functionality.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3093) Inconsistency between
Session.getProperty and Node.getProperty for binary values
Posted by "Jukka Zitting (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting updated JCR-3093:
-------------------------------
Resolution: Fixed
Status: Resolved (was: Patch Available)
Patch committed in revision 1199312.
> Inconsistency between Session.getProperty and Node.getProperty for binary values
> --------------------------------------------------------------------------------
>
> Key: JCR-3093
> URL: https://issues.apache.org/jira/browse/JCR-3093
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-spi2dav
> Reporter: angela
> Assignee: angela
> Fix For: 2.3.3
>
> Attachments: JCR-3093.patch, JCR-3093_2.patch
>
>
> there an inconsistency in the binary handling between the batch-reading facility and those cases where a property is directly
> accessed without having accessed the parent node before.
> this issue came up with timothee maret running into performance issues when retrieving the length of a binary property:
> if the property-entry has been created in the run of a batch-read operation the corresponding property-data object
> contains internal values that contain the length of the binary (such as transported with the json response) and only
> read the data from the server if the value stream is explicitly requested.
> however, if the property is accessed directly (e.g. Session.getProperty or Node.getProperty with a relative path)
> a GET request is made to the corresponding dav resource and the stream is read immediately.
> possible solution:
> if RepositoryService#getItemInfos(SessionInfo, ItemId) is called with a PropertyId the implementation
> should not result in a GET request to the corresponding resource by calling super.getPropertyInfo(sessionInfo, (PropertyId) itemId).
> instead it should be consistent with the batch-read and only make a PROPFIND request for the property
> length. the returned PropertyInfo object would in that case be identical to the one generated by the batch-read functionality.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (JCR-3093) Inconsistency between
Session.getProperty and Node.getProperty for binary values
Posted by "angela (Reopened) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
angela reopened JCR-3093:
-------------------------
ooops the fix introduced a regression as it used wrong index to build binary values
of a single-valued property.
> Inconsistency between Session.getProperty and Node.getProperty for binary values
> --------------------------------------------------------------------------------
>
> Key: JCR-3093
> URL: https://issues.apache.org/jira/browse/JCR-3093
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-spi2dav
> Reporter: angela
> Assignee: angela
> Fix For: 2.3.3
>
> Attachments: JCR-3093.patch
>
>
> there an inconsistency in the binary handling between the batch-reading facility and those cases where a property is directly
> accessed without having accessed the parent node before.
> this issue came up with timothee maret running into performance issues when retrieving the length of a binary property:
> if the property-entry has been created in the run of a batch-read operation the corresponding property-data object
> contains internal values that contain the length of the binary (such as transported with the json response) and only
> read the data from the server if the value stream is explicitly requested.
> however, if the property is accessed directly (e.g. Session.getProperty or Node.getProperty with a relative path)
> a GET request is made to the corresponding dav resource and the stream is read immediately.
> possible solution:
> if RepositoryService#getItemInfos(SessionInfo, ItemId) is called with a PropertyId the implementation
> should not result in a GET request to the corresponding resource by calling super.getPropertyInfo(sessionInfo, (PropertyId) itemId).
> instead it should be consistent with the batch-read and only make a PROPFIND request for the property
> length. the returned PropertyInfo object would in that case be identical to the one generated by the batch-read functionality.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3093) Inconsistency between
Session.getProperty and Node.getProperty for binary values
Posted by "Timothee Maret (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Timothee Maret updated JCR-3093:
--------------------------------
Status: Patch Available (was: Open)
This patch implements the solution described by angela.
It spools a binary property only if explicitely requested (even with Session.getProperty)
> Inconsistency between Session.getProperty and Node.getProperty for binary values
> --------------------------------------------------------------------------------
>
> Key: JCR-3093
> URL: https://issues.apache.org/jira/browse/JCR-3093
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-spi2dav
> Reporter: angela
>
> there an inconsistency in the binary handling between the batch-reading facility and those cases where a property is directly
> accessed without having accessed the parent node before.
> this issue came up with timothee maret running into performance issues when retrieving the length of a binary property:
> if the property-entry has been created in the run of a batch-read operation the corresponding property-data object
> contains internal values that contain the length of the binary (such as transported with the json response) and only
> read the data from the server if the value stream is explicitly requested.
> however, if the property is accessed directly (e.g. Session.getProperty or Node.getProperty with a relative path)
> a GET request is made to the corresponding dav resource and the stream is read immediately.
> possible solution:
> if RepositoryService#getItemInfos(SessionInfo, ItemId) is called with a PropertyId the implementation
> should not result in a GET request to the corresponding resource by calling super.getPropertyInfo(sessionInfo, (PropertyId) itemId).
> instead it should be consistent with the batch-read and only make a PROPFIND request for the property
> length. the returned PropertyInfo object would in that case be identical to the one generated by the batch-read functionality.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (JCR-3093) Inconsistency between
Session.getProperty and Node.getProperty for binary values
Posted by "Timothee Maret (Issue Comment Edited) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13122694#comment-13122694 ]
Timothee Maret edited comment on JCR-3093 at 10/7/11 11:30 AM:
---------------------------------------------------------------
The patch JCR-3093.patch implements the solution described by angela.
It spools a binary property only if explicitely requested (even with Session.getProperty)
was (Author: marett):
This patch implements the solution described by angela.
It spools a binary property only if explicitely requested (even with Session.getProperty)
> Inconsistency between Session.getProperty and Node.getProperty for binary values
> --------------------------------------------------------------------------------
>
> Key: JCR-3093
> URL: https://issues.apache.org/jira/browse/JCR-3093
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-spi2dav
> Reporter: angela
> Attachments: JCR-3093.patch
>
>
> there an inconsistency in the binary handling between the batch-reading facility and those cases where a property is directly
> accessed without having accessed the parent node before.
> this issue came up with timothee maret running into performance issues when retrieving the length of a binary property:
> if the property-entry has been created in the run of a batch-read operation the corresponding property-data object
> contains internal values that contain the length of the binary (such as transported with the json response) and only
> read the data from the server if the value stream is explicitly requested.
> however, if the property is accessed directly (e.g. Session.getProperty or Node.getProperty with a relative path)
> a GET request is made to the corresponding dav resource and the stream is read immediately.
> possible solution:
> if RepositoryService#getItemInfos(SessionInfo, ItemId) is called with a PropertyId the implementation
> should not result in a GET request to the corresponding resource by calling super.getPropertyInfo(sessionInfo, (PropertyId) itemId).
> instead it should be consistent with the batch-read and only make a PROPFIND request for the property
> length. the returned PropertyInfo object would in that case be identical to the one generated by the batch-read functionality.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3093) Inconsistency between
Session.getProperty and Node.getProperty for binary values
Posted by "angela (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13124983#comment-13124983 ]
angela commented on JCR-3093:
-----------------------------
thanks for the patch. there is one thing that is wrong IMO:
- the path parameter for the PropertyInfoImpl constructor should be the path of the item and not
only the path part of the propertyID. i will fix that.
and then there is one thing i wasn't aware of: the information if a property is a binary isn't known
upfront. consequently with the proposed solution an additional GET request is generated for
non-binary properties. whether or not that has an impact depends a bit on the frequency of
properties being directly accessed... just one thing i noticed.
an alternative solution was to get the json-serialization of the parent node and rearrange the
results such that the requested propertyInfo is the first one in the iterator. according to the
api contract the callers are required to properly deal with additional, "arbitrary" infos being
returned from getItemInfos. that was suitable if there is a greater chance that the parent
node will be read as well (sooner or later)... if that's not the case retrieving the parent and
the sibling properties add overhead for item processing on the client side.
yet another possibility was to guess whether a given propertyId refers to a binary property
(e.g. by adding that short cut for known binary property names (e.g. jcr:data))... don't really
like this one, but mentioning here for completeness.
> Inconsistency between Session.getProperty and Node.getProperty for binary values
> --------------------------------------------------------------------------------
>
> Key: JCR-3093
> URL: https://issues.apache.org/jira/browse/JCR-3093
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-spi2dav
> Reporter: angela
> Attachments: JCR-3093.patch
>
>
> there an inconsistency in the binary handling between the batch-reading facility and those cases where a property is directly
> accessed without having accessed the parent node before.
> this issue came up with timothee maret running into performance issues when retrieving the length of a binary property:
> if the property-entry has been created in the run of a batch-read operation the corresponding property-data object
> contains internal values that contain the length of the binary (such as transported with the json response) and only
> read the data from the server if the value stream is explicitly requested.
> however, if the property is accessed directly (e.g. Session.getProperty or Node.getProperty with a relative path)
> a GET request is made to the corresponding dav resource and the stream is read immediately.
> possible solution:
> if RepositoryService#getItemInfos(SessionInfo, ItemId) is called with a PropertyId the implementation
> should not result in a GET request to the corresponding resource by calling super.getPropertyInfo(sessionInfo, (PropertyId) itemId).
> instead it should be consistent with the batch-read and only make a PROPFIND request for the property
> length. the returned PropertyInfo object would in that case be identical to the one generated by the batch-read functionality.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (JCR-3093) Inconsistency between
Session.getProperty and Node.getProperty for binary values
Posted by "angela (Assigned) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
angela reassigned JCR-3093:
---------------------------
Assignee: angela
> Inconsistency between Session.getProperty and Node.getProperty for binary values
> --------------------------------------------------------------------------------
>
> Key: JCR-3093
> URL: https://issues.apache.org/jira/browse/JCR-3093
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-spi2dav
> Reporter: angela
> Assignee: angela
> Attachments: JCR-3093.patch
>
>
> there an inconsistency in the binary handling between the batch-reading facility and those cases where a property is directly
> accessed without having accessed the parent node before.
> this issue came up with timothee maret running into performance issues when retrieving the length of a binary property:
> if the property-entry has been created in the run of a batch-read operation the corresponding property-data object
> contains internal values that contain the length of the binary (such as transported with the json response) and only
> read the data from the server if the value stream is explicitly requested.
> however, if the property is accessed directly (e.g. Session.getProperty or Node.getProperty with a relative path)
> a GET request is made to the corresponding dav resource and the stream is read immediately.
> possible solution:
> if RepositoryService#getItemInfos(SessionInfo, ItemId) is called with a PropertyId the implementation
> should not result in a GET request to the corresponding resource by calling super.getPropertyInfo(sessionInfo, (PropertyId) itemId).
> instead it should be consistent with the batch-read and only make a PROPFIND request for the property
> length. the returned PropertyInfo object would in that case be identical to the one generated by the batch-read functionality.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3093) Inconsistency between
Session.getProperty and Node.getProperty for binary values
Posted by "angela (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
angela updated JCR-3093:
------------------------
Resolution: Fixed
Fix Version/s: 2.3.2
Status: Resolved (was: Patch Available)
> Inconsistency between Session.getProperty and Node.getProperty for binary values
> --------------------------------------------------------------------------------
>
> Key: JCR-3093
> URL: https://issues.apache.org/jira/browse/JCR-3093
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-spi2dav
> Reporter: angela
> Assignee: angela
> Fix For: 2.3.2
>
> Attachments: JCR-3093.patch
>
>
> there an inconsistency in the binary handling between the batch-reading facility and those cases where a property is directly
> accessed without having accessed the parent node before.
> this issue came up with timothee maret running into performance issues when retrieving the length of a binary property:
> if the property-entry has been created in the run of a batch-read operation the corresponding property-data object
> contains internal values that contain the length of the binary (such as transported with the json response) and only
> read the data from the server if the value stream is explicitly requested.
> however, if the property is accessed directly (e.g. Session.getProperty or Node.getProperty with a relative path)
> a GET request is made to the corresponding dav resource and the stream is read immediately.
> possible solution:
> if RepositoryService#getItemInfos(SessionInfo, ItemId) is called with a PropertyId the implementation
> should not result in a GET request to the corresponding resource by calling super.getPropertyInfo(sessionInfo, (PropertyId) itemId).
> instead it should be consistent with the batch-read and only make a PROPFIND request for the property
> length. the returned PropertyInfo object would in that case be identical to the one generated by the batch-read functionality.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3093) Inconsistency between
Session.getProperty and Node.getProperty for binary values
Posted by "angela (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
angela updated JCR-3093:
------------------------
Status: Patch Available (was: Reopened)
> Inconsistency between Session.getProperty and Node.getProperty for binary values
> --------------------------------------------------------------------------------
>
> Key: JCR-3093
> URL: https://issues.apache.org/jira/browse/JCR-3093
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-spi2dav
> Reporter: angela
> Assignee: angela
> Fix For: 2.3.3
>
> Attachments: JCR-3093.patch
>
>
> there an inconsistency in the binary handling between the batch-reading facility and those cases where a property is directly
> accessed without having accessed the parent node before.
> this issue came up with timothee maret running into performance issues when retrieving the length of a binary property:
> if the property-entry has been created in the run of a batch-read operation the corresponding property-data object
> contains internal values that contain the length of the binary (such as transported with the json response) and only
> read the data from the server if the value stream is explicitly requested.
> however, if the property is accessed directly (e.g. Session.getProperty or Node.getProperty with a relative path)
> a GET request is made to the corresponding dav resource and the stream is read immediately.
> possible solution:
> if RepositoryService#getItemInfos(SessionInfo, ItemId) is called with a PropertyId the implementation
> should not result in a GET request to the corresponding resource by calling super.getPropertyInfo(sessionInfo, (PropertyId) itemId).
> instead it should be consistent with the batch-read and only make a PROPFIND request for the property
> length. the returned PropertyInfo object would in that case be identical to the one generated by the batch-read functionality.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3093) Inconsistency between
Session.getProperty and Node.getProperty for binary values
Posted by "angela (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
angela updated JCR-3093:
------------------------
Attachment: JCR-3093_2.patch
fixing the regression... failed to commit due to some auth hassle
> Inconsistency between Session.getProperty and Node.getProperty for binary values
> --------------------------------------------------------------------------------
>
> Key: JCR-3093
> URL: https://issues.apache.org/jira/browse/JCR-3093
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-spi2dav
> Reporter: angela
> Assignee: angela
> Fix For: 2.3.3
>
> Attachments: JCR-3093.patch, JCR-3093_2.patch
>
>
> there an inconsistency in the binary handling between the batch-reading facility and those cases where a property is directly
> accessed without having accessed the parent node before.
> this issue came up with timothee maret running into performance issues when retrieving the length of a binary property:
> if the property-entry has been created in the run of a batch-read operation the corresponding property-data object
> contains internal values that contain the length of the binary (such as transported with the json response) and only
> read the data from the server if the value stream is explicitly requested.
> however, if the property is accessed directly (e.g. Session.getProperty or Node.getProperty with a relative path)
> a GET request is made to the corresponding dav resource and the stream is read immediately.
> possible solution:
> if RepositoryService#getItemInfos(SessionInfo, ItemId) is called with a PropertyId the implementation
> should not result in a GET request to the corresponding resource by calling super.getPropertyInfo(sessionInfo, (PropertyId) itemId).
> instead it should be consistent with the batch-read and only make a PROPFIND request for the property
> length. the returned PropertyInfo object would in that case be identical to the one generated by the batch-read functionality.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3093) Inconsistency between
Session.getProperty and Node.getProperty for binary values
Posted by "Timothee Maret (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Timothee Maret updated JCR-3093:
--------------------------------
Attachment: JCR-3093.patch
> Inconsistency between Session.getProperty and Node.getProperty for binary values
> --------------------------------------------------------------------------------
>
> Key: JCR-3093
> URL: https://issues.apache.org/jira/browse/JCR-3093
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-spi2dav
> Reporter: angela
> Attachments: JCR-3093.patch
>
>
> there an inconsistency in the binary handling between the batch-reading facility and those cases where a property is directly
> accessed without having accessed the parent node before.
> this issue came up with timothee maret running into performance issues when retrieving the length of a binary property:
> if the property-entry has been created in the run of a batch-read operation the corresponding property-data object
> contains internal values that contain the length of the binary (such as transported with the json response) and only
> read the data from the server if the value stream is explicitly requested.
> however, if the property is accessed directly (e.g. Session.getProperty or Node.getProperty with a relative path)
> a GET request is made to the corresponding dav resource and the stream is read immediately.
> possible solution:
> if RepositoryService#getItemInfos(SessionInfo, ItemId) is called with a PropertyId the implementation
> should not result in a GET request to the corresponding resource by calling super.getPropertyInfo(sessionInfo, (PropertyId) itemId).
> instead it should be consistent with the batch-read and only make a PROPFIND request for the property
> length. the returned PropertyInfo object would in that case be identical to the one generated by the batch-read functionality.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3093) Inconsistency between
Session.getProperty and Node.getProperty for binary values
Posted by "angela (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13125921#comment-13125921 ]
angela commented on JCR-3093:
-----------------------------
played around with the possibilities listed above. retrieving the json-ser of the parent node could
potentially be cumbersome if a given session is allowed to retrieve the property but not the parent node.
finally came up with a different solution:
the jcr-property resources expose a protected dav property that corresponds to the string representation
such as retrieved by Property.getString(). it is available for single-valued non-binary properties only.
consequently, getPropertyInfo only results in an additional GET request for non-binary multivalued properties.
for any other properties (single-value or binary) a single PROPFIND request is sufficient to retrieve the
information used to build the PropertyInfo object.
running the jackrabbit-jcr2dav ConformanceTest with tracing the average amount of time spent with the
getPropertyInfo calls (NOTE that the test do not contain huge binary properties):
- original code: 3248
- patch 2 request: 7529
- final patch: 4640
futher improvement could be achieved by addressing JCR-2073 that would avoid redundant calls
to getPropertyInfo.
> Inconsistency between Session.getProperty and Node.getProperty for binary values
> --------------------------------------------------------------------------------
>
> Key: JCR-3093
> URL: https://issues.apache.org/jira/browse/JCR-3093
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-spi2dav
> Reporter: angela
> Assignee: angela
> Fix For: 2.3.2
>
> Attachments: JCR-3093.patch
>
>
> there an inconsistency in the binary handling between the batch-reading facility and those cases where a property is directly
> accessed without having accessed the parent node before.
> this issue came up with timothee maret running into performance issues when retrieving the length of a binary property:
> if the property-entry has been created in the run of a batch-read operation the corresponding property-data object
> contains internal values that contain the length of the binary (such as transported with the json response) and only
> read the data from the server if the value stream is explicitly requested.
> however, if the property is accessed directly (e.g. Session.getProperty or Node.getProperty with a relative path)
> a GET request is made to the corresponding dav resource and the stream is read immediately.
> possible solution:
> if RepositoryService#getItemInfos(SessionInfo, ItemId) is called with a PropertyId the implementation
> should not result in a GET request to the corresponding resource by calling super.getPropertyInfo(sessionInfo, (PropertyId) itemId).
> instead it should be consistent with the batch-read and only make a PROPFIND request for the property
> length. the returned PropertyInfo object would in that case be identical to the one generated by the batch-read functionality.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira