From dev-return-32703-apmail-jackrabbit-dev-archive=jackrabbit.apache.org@jackrabbit.apache.org Wed Oct 12 15:23:33 2011 Return-Path: X-Original-To: apmail-jackrabbit-dev-archive@www.apache.org Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B5F577D69 for ; Wed, 12 Oct 2011 15:23:33 +0000 (UTC) Received: (qmail 1967 invoked by uid 500); 12 Oct 2011 15:23:33 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 1906 invoked by uid 500); 12 Oct 2011 15:23:33 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 1803 invoked by uid 99); 12 Oct 2011 15:23:33 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Oct 2011 15:23:33 +0000 X-ASF-Spam-Status: No, hits=-2000.5 required=5.0 tests=ALL_TRUSTED,RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Oct 2011 15:23:32 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id DB445305E40 for ; Wed, 12 Oct 2011 15:23:11 +0000 (UTC) Date: Wed, 12 Oct 2011 15:23:11 +0000 (UTC) From: "angela (Commented) (JIRA)" To: dev@jackrabbit.apache.org Message-ID: <1335729850.5428.1318432991899.JavaMail.tomcat@hel.zones.apache.org> In-Reply-To: <1569361603.11566.1317819034191.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Commented] (JCR-3093) Inconsistency between Session.getProperty and Node.getProperty for binary values MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ 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