jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "angela (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-1300) spi2dav Improve performance for large binary properties
Date Tue, 19 Feb 2008 17:10:43 GMT

    [ https://issues.apache.org/jira/browse/JCR-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12570311#action_12570311

angela commented on JCR-1300:

please find attached a quick hack that add the following changes:


- addProperty(NodeId, Name, QValue)
  sends a PUT with a StringRequestEntity or InputStreamRequestEntity.
  using a custom contentType (see jcr-server)

- addProperty(NodeId, Name, QValue[])
  Not changed. Still sends xml-request body with a ValuesProperty.
  TODO: added instructions what need to be changed on the server in order to get rid of that.

- setValue(PropertyId, QValue)
  sends a PUT with a StringRequestEntity or InputStreamRequestEntity.
  using a custom contentType (see jcr-server)
  TODO: PUT is not totally correct since 'setValue' should fail if the property
  does not exist on the server.

- setValue(PropertyId, QValue[])
   Not changed. Still makes a PROPPATCH request containing ValuesProperty
   TODO: find a way to avoid the xml (see addProperty).

- getItemInfos:
  since Batch-READ has not yet been implemented, the method returns the same as getNodeInfo.
  Added code that builds PropertyInfo objects for jcr:uuid, jcr:primaryType and jcr:mixins
  if the corresponding info is present in the NodeInfo.

- getPropertyInfo:
  Changed PROPFIND request to retrieve 'length' or 'lengths' of the prop-values instead
  of retrieving the values themselves.
  A ValueLoader takes care of requesting the prop-values on demand and not by default.


ItemResourceConstants: defines a new constant that represent the start of the content-type
to be used, when a property-value is sent without enclosing ValueProperty.

DefaultItemCollection.addMember has been modified:
if the contentType matches the new custom content-type (see above) the request body
is not parsed into a xml-Document. instead the stream is passed to Node.setProperty
(Binary types only) or converted into a String and the passed to Node.setProperty(String,

i quickly let the general read, property read and property write test from the TCK run
on a setup jcr2spi-spi2dav-jcrserver. 
I.e. not really tested if the modification don't break any (or are beneficial).

Jozef, could you try if that helps you? (testing is delegated to you ;)


> spi2dav Improve performance for large binary properties
> -------------------------------------------------------
>                 Key: JCR-1300
>                 URL: https://issues.apache.org/jira/browse/JCR-1300
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: contrib, jackrabbit-jcr-server
>            Reporter: Jozef Wagner
>         Attachments: JCR-1300_jcr-server.patch, JCR-1300_spi2dav.patch
> Sending large binary properties over spi2dav is slow and requires a lot of heap space
in both client and server.
> One problematic part is base64 conversion of the property value.
> On the contrary, using 'normal' webdav interface (/repository/default/ instead of /server)
for uploading a file (through traditional webdav client) it is pretty fast and don't have
such impact on heap space.
> Some suggestions from the previous discussion:
>  - avoid temporary copies of the data, and persist large objects as early as possible.

>  - transfer large objects in blocks from the Jackrabbit SPI client to the server (and
>  - make usage of the global data store (JCR-926). 
>  - straight forward PUT for single-valued properties
> Link to discussion: http://www.mail-archive.com/dev@jackrabbit.apache.org/msg09481.html

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message