newb performance question

I am new to jackrabbit and looking to use it to replace
slide.

I am using the default repository setup (derby), and
accessing it  
using WEBDAV running under jetty.

jackrabbit seems to perform well with small files, but when
it gets to  
larger file it slows way down and I see messages like:

*INFO * BundleCache: num=3496 mem=8190k max=8192k avg=2399 

hits=7690423 miss=739577 (BundleCache.java, line 109)

What is the "proper" way to fine tune jackrabbit's
performance!

I did increase the memory to the JVM when starting jetty as
I was  
getting out of memory errors in the JVM.

Thanks

Wade Girard
wade.girardgmail.com

Could you post your actual repository.xml configuration here
(after
clearing it from passwords and other sensitive data)? The
default
might depend on the version used and where you took it from,
so it's
better to post it 

Basically the "answer" for large binary files is
the global DataStore
(http://wi
ki.apache.org/jackrabbit/DataStore) - at least in the
persistence layer.

Regards,
Alex

On Tue, Jun 3, 2008 at 7:45 PM, Wade Girard
<wade.girardcomcast.net> wrote:
> I am new to jackrabbit and looking to use it to replace
slide.
>
> I am using the default repository setup (derby), and
accessing it using
> WEBDAV running under jetty.
>
> jackrabbit seems to perform well with small files, but
when it gets to
> larger file it slows way down and I see messages like:
>
> *INFO * BundleCache: num=3496 mem=8190k max=8192k
avg=2399 hits=7690423
> miss=739577 (BundleCache.java, line 109)
>
> What is the "proper" way to fine tune
jackrabbit's performance!
>
> I did increase the memory to the JVM when starting
jetty as I was getting
> out of memory errors in the JVM.
>
> Thanks
>
> Wade Girard
> wade.girardgmail.com

-- 
Alexander Klimetschek
alexander.klimetschekday.com

Sure, here it is





On Jun 3, 2008, at 1:13 PM, Alexander Klimetschek wrote:

> Could you post your actual repository.xml configuration
here (after
> clearing it from passwords and other sensitive data)?
The default
> might depend on the version used and where you took it
from, so it's
> better to post it 
>
> Basically the "answer" for large binary files
is the global DataStore
> (http://wi
ki.apache.org/jackrabbit/DataStore) - at least in the
> persistence layer.
>
> Regards,
> Alex
>
> On Tue, Jun 3, 2008 at 7:45 PM, Wade Girard  
> <wade.girardcomcast.net> wrote:
>> I am new to jackrabbit and looking to use it to
replace slide.
>>
>> I am using the default repository setup (derby),
and accessing it  
>> using
>> WEBDAV running under jetty.
>>
>> jackrabbit seems to perform well with small files,
but when it gets  
>> to
>> larger file it slows way down and I see messages
like:
>>
>> *INFO * BundleCache: num=3496 mem=8190k max=8192k
avg=2399  
>> hits=7690423
>> miss=739577 (BundleCache.java, line 109)
>>
>> What is the "proper" way to fine tune
jackrabbit's performance!
>>
>> I did increase the memory to the JVM when starting
jetty as I was  
>> getting
>> out of memory errors in the JVM.
>>
>> Thanks
>>
>> Wade Girard
>> wade.girardgmail.com
>
> -- 
> Alexander Klimetschek
> alexander.klimetschekday.com

Wade Girard
wade.girardgmail.com

Try with a DataStore configured and see if the performance
changes.
"minRecordLength" is the limit in bytes from which
on larger binary
properties will be stored in the DataStore. You need at
least
Jackrabbit 1.4 for it.

    <DataStore
class="org.apache.jackrabbit.core.data.FileDataStore&qu
ot;>
        <param name="path"
value="${rep.home}/repository/datastore"/>
        <param name="minRecordLength"
value="100"/>
    </DataStore>

Alex

-- 
Alexander Klimetschek
alexander.klimetschekday.com

I added this to my repository.xml and restarted jetty. It
looks like I  
also need re-create my repository, is that correct?

On Jun 3, 2008, at 3:02 PM, Alexander Klimetschek wrote:

> Try with a DataStore configured and see if the
performance changes.
> "minRecordLength" is the limit in bytes from
which on larger binary
> properties will be stored in the DataStore. You need at
least
> Jackrabbit 1.4 for it.
>
>    <DataStore
class="org.apache.jackrabbit.core.data.FileDataStore&qu
ot;>
>        <param name="path"
value="${rep.home}/repository/datastore"/>
>        <param name="minRecordLength"
value="100"/>
>    </DataStore>
>
> Alex
>
> -- 
> Alexander Klimetschek
> alexander.klimetschekday.com

Wade Girard
wade.girardgmail.com

Hi,

On Tue, Jun 3, 2008 at 11:18 PM, Wade Girard
<wade.girardcomcast.net> wrote:
> I added this to my repository.xml and restarted jetty.
It looks like I also
> need re-create my repository, is that correct?

The repository should be able to access also pre-datastore
content,
but you'll only get the performance benefits for newly added
binaries.

BR,

Jukka Zitting

It is still slow, now the messages that I am seeing in the
log are

*INFO * IndexMerger: merged xxx documents in yyy ms into
_aka.  
(IndexMerger.java, line 304)

Where xxx is a number, usually 1000 and yyy is a number
between 100  
and 2700

I did create a new repository and added the proposed changes
to the  
repository.xml file.

On Jun 3, 2008, at 3:35 PM, Jukka Zitting wrote:

> Hi,
>
> On Tue, Jun 3, 2008 at 11:18 PM, Wade Girard  
> <wade.girardcomcast.net> wrote:
>> I added this to my repository.xml and restarted
jetty. It looks  
>> like I also
>> need re-create my repository, is that correct?
>
> The repository should be able to access also
pre-datastore content,
> but you'll only get the performance benefits for newly
added binaries.
>
> BR,
>
> Jukka Zitting

Wade Girard
wade.girardgmail.com

Hi,

On Wed, Jun 4, 2008 at 6:34 PM, Wade Girard
<wade.girardcomcast.net> wrote:
> It is still slow, now the messages that I am seeing in
the log are
>
> *INFO * IndexMerger: merged xxx documents in yyy ms
into _aka.
> (IndexMerger.java, line 304)
>
> Where xxx is a number, usually 1000 and yyy is a number
between 100 and 2700

Just a guess, do you have many PDF files in the repository?
The PDF
text extractor is notoriously slow especially with large
files.

BR,

Jukka Zitting

No, These are all xml files ranging in size from 776 kb to 4
kb

Thanks

On Jun 4, 2008, at 3:51 PM, Jukka Zitting wrote:

> Hi,
>
> On Wed, Jun 4, 2008 at 6:34 PM, Wade Girard  
> <wade.girardcomcast.net> wrote:
>> It is still slow, now the messages that I am seeing
in the log are
>>
>> *INFO * IndexMerger: merged xxx documents in yyy ms
into _aka.
>> (IndexMerger.java, line 304)
>>
>> Where xxx is a number, usually 1000 and yyy is a
number between 100  
>> and 2700
>
> Just a guess, do you have many PDF files in the
repository? The PDF
> text extractor is notoriously slow especially with
large files.
>
> BR,
>
> Jukka Zitting

Wade Girard
wade.girardgmail.com

On Wed, Jun 4, 2008 at 10:55 PM, Wade Girard
<wade.girardcomcast.net> wrote:
> No, These are all xml files ranging in size from 776 kb
to 4 kb

Are you importing the XML content as node structures? See
this mail
for a possible improvement:
http://m
arkmail.org/message/uebgv5co6qxxgfff

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschekday.com

okay, I see this:

If you need to store XML documents as-is (as opposed to an
abstract
content model that's just serialized to XML), then I would
recommend
storing the XML as a binary property, preferably inside a
nt:file/nt:resource structure.

How do I do this?

On Jun 4, 2008, at 5:58 PM, Alexander Klimetschek wrote:

> On Wed, Jun 4, 2008 at 10:55 PM, Wade Girard  
> <wade.girardcomcast.net> wrote:
>> No, These are all xml files ranging in size from
776 kb to 4 kb
>
> Are you importing the XML content as node structures?
See this mail
> for a possible improvement:
> http://m
arkmail.org/message/uebgv5co6qxxgfff
>
> Regards,
> Alex
>
> -- 
> Alexander Klimetschek
> alexander.klimetschekday.com

Wade Girard
wade.girardgmail.com

Put the serialized XML stream into a binary property:
myfile/jcr:content/jcr:data (where myfile is of type nt:file
and
jcr:content is of nt:resource).

See also the JCR spec for more info on nt:file/nt:folder and
nt:resource.

Alex

On Thu, Jun 5, 2008 at 3:25 PM, Wade Girard
<wade.girardcomcast.net> wrote:
> okay, I see this:
>
> If you need to store XML documents as-is (as opposed to
an abstract
> content model that's just serialized to XML), then I
would recommend
> storing the XML as a binary property, preferably inside
a
> nt:file/nt:resource structure.
>
> How do I do this?
>
> On Jun 4, 2008, at 5:58 PM, Alexander Klimetschek
wrote:
>
>> On Wed, Jun 4, 2008 at 10:55 PM, Wade Girard
<wade.girardcomcast.net>
>> wrote:
>>>
>>> No, These are all xml files ranging in size
from 776 kb to 4 kb
>>
>> Are you importing the XML content as node
structures? See this mail
>> for a possible improvement:
>> http://m
arkmail.org/message/uebgv5co6qxxgfff
>>
>> Regards,
>> Alex
>>
>> --
>> Alexander Klimetschek
>> alexander.klimetschekday.com
>
> Wade Girard
> wade.girardgmail.com


-- 
Alexander Klimetschek
alexander.klimetschekday.com

I see the confusion (with me)! myfile/jcr:content/jcr:data
set when  
setting/getting the Node property in java, I am using
cadaver to put/ 
get files from a command line to jackrabbit via the WEBDAV
interface.

I have only been doing this for a few days now, can I set
this somehow  
using cadaver? Or is there a way to tell jackrabbit to treat
xml files  
this way through the repository.xml?

Thanks

On Jun 5, 2008, at 8:43 AM, Alexander Klimetschek wrote:

> Put the serialized XML stream into a binary property:
> myfile/jcr:content/jcr:data (where myfile is of type
nt:file and
> jcr:content is of nt:resource).
>
> See also the JCR spec for more info on
nt:file/nt:folder and  
> nt:resource.
>
> Alex
>
> On Thu, Jun 5, 2008 at 3:25 PM, Wade Girard  
> <wade.girardcomcast.net> wrote:
>> okay, I see this:
>>
>> If you need to store XML documents as-is (as
opposed to an abstract
>> content model that's just serialized to XML), then
I would recommend
>> storing the XML as a binary property, preferably
inside a
>> nt:file/nt:resource structure.
>>
>> How do I do this?
>>
>> On Jun 4, 2008, at 5:58 PM, Alexander Klimetschek
wrote:
>>
>>> On Wed, Jun 4, 2008 at 10:55 PM, Wade Girard
<wade.girardcomcast.net 
>>> >
>>> wrote:
>>>>
>>>> No, These are all xml files ranging in size
from 776 kb to 4 kb
>>>
>>> Are you importing the XML content as node
structures? See this mail
>>> for a possible improvement:
>>> http://m
arkmail.org/message/uebgv5co6qxxgfff
>>>
>>> Regards,
>>> Alex
>>>
>>> --
>>> Alexander Klimetschek
>>> alexander.klimetschekday.com
>>
>> Wade Girard
>> wade.girardgmail.com
>
>
> -- 
> Alexander Klimetschek
> alexander.klimetschekday.com

Wade Girard
wade.girardgmail.com

Sorry, I don't know about cadaver. The "normal"
behaviour with Webdav
should be that imported files are stores as nt:file. But
that can be
customized. Is there any specific configuration of the
Webdav in your
Jackrabbit server?

Alex

On Thu, Jun 5, 2008 at 4:03 PM, Wade Girard
<wade.girardcomcast.net> wrote:
> I see the confusion (with me)!
myfile/jcr:content/jcr:data set when
> setting/getting the Node property in java, I am using
cadaver to put/get
> files from a command line to jackrabbit via the WEBDAV
interface.
>
> I have only been doing this for a few days now, can I
set this somehow using
> cadaver? Or is there a way to tell jackrabbit to treat
xml files this way
> through the repository.xml?
>
> Thanks
>
> On Jun 5, 2008, at 8:43 AM, Alexander Klimetschek
wrote:
>
>> Put the serialized XML stream into a binary
property:
>> myfile/jcr:content/jcr:data (where myfile is of
type nt:file and
>> jcr:content is of nt:resource).
>>
>> See also the JCR spec for more info on
nt:file/nt:folder and nt:resource.
>>
>> Alex
>>
>> On Thu, Jun 5, 2008 at 3:25 PM, Wade Girard
<wade.girardcomcast.net>
>> wrote:
>>>
>>> okay, I see this:
>>>
>>> If you need to store XML documents as-is (as
opposed to an abstract
>>> content model that's just serialized to XML),
then I would recommend
>>> storing the XML as a binary property,
preferably inside a
>>> nt:file/nt:resource structure.
>>>
>>> How do I do this?
>>>
>>> On Jun 4, 2008, at 5:58 PM, Alexander
Klimetschek wrote:
>>>
>>>> On Wed, Jun 4, 2008 at 10:55 PM, Wade
Girard <wade.girardcomcast.net>
>>>> wrote:
>>>>>
>>>>> No, These are all xml files ranging in
size from 776 kb to 4 kb
>>>>
>>>> Are you importing the XML content as node
structures? See this mail
>>>> for a possible improvement:
>>>> http://m
arkmail.org/message/uebgv5co6qxxgfff
>>>>
>>>> Regards,
>>>> Alex
>>>>
>>>> --
>>>> Alexander Klimetschek
>>>> alexander.klimetschekday.com
>>>
>>> Wade Girard
>>> wade.girardgmail.com
>>
>>
>> --
>> Alexander Klimetschek
>> alexander.klimetschekday.com
>
> Wade Girard
> wade.girardgmail.com
>
>
>
>
>
>



-- 
Alexander Klimetschek
alexander.klimetschekday.com

>> Day JCR Cup 08 | Win a MacBook Pro: http://dev.day.com/ <<

----------------------------< alexander.klimetschekday.com
>----------
Alexander Klimetschek, Day Management AG, Barfuesserplatz
6,
CH - 4001 Basel, T +41 61 226 55 31, M +49 151 15 77 20 56
---------------------------------------< http://www.day.com
>-----------------

Xing: http://w
ww.xing.com/go/invite/3268380.32d2d4
LinkedIn: http://www.lin
kedin.com/in/klimetschek
Blog: http://we
blogs.goshaky.com/weblogs/alexkli/

My goal is to compare jackrabbit to our current
configuration of using  
slide, and hopefully be able to just replace slide with
little code  
change/impact on code, and hopefully improve performance.

We currently run slide under jetty and store xml, png, jgp,
txt, and  
one dtd file in the repository.

I set up a brand new install of Jetty, I added jackrabbit to
jetty,  
then created a new repository using the standard
jackrabbit-webapp-1.4  
webapp. I then checked out everything from our current slide
 
repository using cadaver, and then added all these files
into  
jackrabbit, again using cadaver.

I did it this way so that I could write a script, using
cadaver, to  
checkout all the files from the slide repository and from
the  
jackrabbit repository, and compare how long each took to
perform this  
action. slide currently performs a complete get of all the
files in  
roughly 35 seconds, jackrabbit takes nearly 10 minutes, and
I can see  
from the logs that the snag is on the larger xml files.

That said, I had never used WEBDAV until a week ago, I am
new to all  
this, another developer did the initial implementation of
slide in our  
product. So I am new to this, and my be hopping down the
wrong bunny  
trail (sorry for the pun), or asking the wrong questions. I
just want/ 
need jackrabbit to work via WEBDAV as good/better than slide
can now,  
so that we can replace slide with jackrabbit.

We prefer to stick with derby for the database, we like that
approach.  
If I can tweak something in the repository.xml to have
jackrabbit  
treat xml/everything as binary, that is fine, or if I need
to write a  
custom importer in java to check everything in in binary,
that is fine  
too. I am just looking for the correct answer.

Does this make sense?

Thanks, Wade

On Jun 5, 2008, at 10:26 AM, Alexander Klimetschek wrote:

> Sorry, I don't know about cadaver. The
"normal" behaviour with Webdav
> should be that imported files are stores as nt:file.
But that can be
> customized. Is there any specific configuration of the
Webdav in your
> Jackrabbit server?
>
> Alex
>
> On Thu, Jun 5, 2008 at 4:03 PM, Wade Girard  
> <wade.girardcomcast.net> wrote:
>> I see the confusion (with me)!
myfile/jcr:content/jcr:data set when
>> setting/getting the Node property in java, I am
using cadaver to  
>> put/get
>> files from a command line to jackrabbit via the
WEBDAV interface.
>>
>> I have only been doing this for a few days now, can
I set this  
>> somehow using
>> cadaver? Or is there a way to tell jackrabbit to
treat xml files  
>> this way
>> through the repository.xml?
>>
>> Thanks
>>
>> On Jun 5, 2008, at 8:43 AM, Alexander Klimetschek
wrote:
>>
>>> Put the serialized XML stream into a binary
property:
>>> myfile/jcr:content/jcr:data (where myfile is of
type nt:file and
>>> jcr:content is of nt:resource).
>>>
>>> See also the JCR spec for more info on
nt:file/nt:folder and  
>>> nt:resource.
>>>
>>> Alex
>>>
>>> On Thu, Jun 5, 2008 at 3:25 PM, Wade Girard  
>>> <wade.girardcomcast.net>
>>> wrote:
>>>>
>>>> okay, I see this:
>>>>
>>>> If you need to store XML documents as-is
(as opposed to an abstract
>>>> content model that's just serialized to
XML), then I would  
>>>> recommend
>>>> storing the XML as a binary property,
preferably inside a
>>>> nt:file/nt:resource structure.
>>>>
>>>> How do I do this?
>>>>
>>>> On Jun 4, 2008, at 5:58 PM, Alexander
Klimetschek wrote:
>>>>
>>>>> On Wed, Jun 4, 2008 at 10:55 PM, Wade
Girard <wade.girardcomcast.net 
>>>>> >
>>>>> wrote:
>>>>>>
>>>>>> No, These are all xml files ranging
in size from 776 kb to 4 kb
>>>>>
>>>>> Are you importing the XML content as
node structures? See this  
>>>>> mail
>>>>> for a possible improvement:
>>>>> http://m
arkmail.org/message/uebgv5co6qxxgfff
>>>>>
>>>>> Regards,
>>>>> Alex
>>>>>
>>>>> --
>>>>> Alexander Klimetschek
>>>>> alexander.klimetschekday.com
>>>>
>>>> Wade Girard
>>>> wade.girardgmail.com
>>>
>>>
>>> --
>>> Alexander Klimetschek
>>> alexander.klimetschekday.com
>>
>> Wade Girard
>> wade.girardgmail.com
>>
>>
>>
>>
>>
>>
>
>
>
> -- 
> Alexander Klimetschek
> alexander.klimetschekday.com
>
>>> Day JCR Cup 08 | Win a MacBook Pro: http://dev.day.com/ <<
>
> ----------------------------<
alexander.klimetschekday.com  
> >----------
> Alexander Klimetschek, Day Management AG,
Barfuesserplatz 6,
> CH - 4001 Basel, T +41 61 226 55 31, M +49 151 15 77 20
56
> ---------------------------------------< http://www.day.com  
> >-----------------
>
> Xing: http://w
ww.xing.com/go/invite/3268380.32d2d4
> LinkedIn: http://www.lin
kedin.com/in/klimetschek
> Blog: http://we
blogs.goshaky.com/weblogs/alexkli/

Wade Girard
wade.girardgmail.com

Wade Girard wrote:
> It is still slow, now the messages that I am seeing in
the log are
> 
> *INFO * IndexMerger: merged xxx documents in yyy ms
into _aka. 
> (IndexMerger.java, line 304)
> 
> Where xxx is a number, usually 1000 and yyy is a number
between 100 and 
> 2700

the IndexMerger runs in a background thread and does not
have an immediate 
effect on the performance you see when you call JCR API
methods.

regards
  marcel

Here is what I am doing/seeing.

As I said before, a brand new install of Jetty, no other
third party  
stuff, just what comes with Jetty 6.1.10. I install
Jackrabbit 1.4 web  
app and the jcr-1.0 jar file. I start jetty, I go to http://host:8
080/jackrabbit-webapp-1.4/ 
  and select the button to create a new repository.

Next I edit the repository.xml file and add the definition
for the  
file data store.

Then I hop on another computer and start cadaver in a
terminal, I open  
a connection to http://host:8
080/jackrabbit-webapp-1.4/ repository/ 
default, log in using a username and password, then create a
"column"  
using cadaver, mkcol views, then I cd into that
"column" and "put" a  
bunch of xml files, the output from cadaver looks like:
...
Uploading ComMQSoftwareWASDurableSubscriptionStats.xml to
`/jackrabbit- 
webapp-1.4/repository/default/views/ 
ComMQSoftwareWASDurableSubscriptionStats.xml':
Progress: [=============================>] 100.0% of
133087 bytes  
succeeded.
Uploading ComMQSoftwareWASDCSStatsSummary.xml to
`/jackrabbit- 
webapp-1.4/repository/default/views/ 
ComMQSoftwareWASDCSStatsSummary.xml':
Progress: [=============================>] 100.0% of
163705 bytes  
succeeded.
Uploading ComMQSoftwareWASDCSStats.xml to
`/jackrabbit-webapp-1.4/ 
repository/default/views/ComMQSoftwareWASDCSStats.xml':
Progress: [=============================>] 100.0% of
164067 bytes  
succeeded.
Uploading ComMQSoftwareWASConnectionFactory.xml to
`/jackrabbit- 
webapp-1.4/repository/default/views/ 
ComMQSoftwareWASConnectionFactory.xml':
Progress: [=============================>] 100.0% of
161661 bytes  
succeeded.
....
Note that the Progress indicator jumps to 100% very quickly,
but does  
not return with "succeeded" until 1 to several
seconds have passed.  
The time it takes to upload each file varies, I assume based
on file  
size.

The log output from jetty when uploading these files looks
like:
...
06.06.2008 09:32:11 *INFO * IndexMerger: merged 1000
documents in 110  
ms into _cdr. (IndexMerger.java, line 304)
06.06.2008 09:32:16 *INFO * IndexMerger: merged 924
documents in 110  
ms into _cel. (IndexMerger.java, line 304)
06.06.2008 09:32:16 *INFO * IndexMerger: merged 1000
documents in 125  
ms into _cem. (IndexMerger.java, line 304)
06.06.2008 09:32:16 *INFO * IndexMerger: merged 1000
documents in 125  
ms into _cen. (IndexMerger.java, line 304)
06.06.2008 09:32:30 *INFO * IndexMerger: merged 890
documents in 110  
ms into _ch1. (IndexMerger.java, line 304)
06.06.2008 09:32:30 *INFO * IndexMerger: merged 1000
documents in 125  
ms into _ch2. (IndexMerger.java, line 304)
06.06.2008 09:32:30 *INFO * IndexMerger: merged 1000
documents in 110  
ms into _ch3. (IndexMerger.java, line 304)
....
I do not see output like this in the log files when I am
putting/ 
getting jpg, png, or other file types that I have been using
other  
than xml.

I get similar results when I "get" these same
files from the  
repository, also using cadaver.

I have also observed that the file sizes of these files is
larger  
after I "get" them using cadaver. So I assume that
jackrabbit is  
mucking with them somehow.

If all I need to do to get consistent behavior is to tell
jackrabbit  
to treat all files as binary, then it would be nice to have
that as an  
option in the repository.xml file. Is this possible?

Thanks,
Wade

On Jun 6, 2008, at 9:22 AM, Marcel Reutegger wrote:

> Wade Girard wrote:
>> It is still slow, now the messages that I am seeing
in the log are
>> *INFO * IndexMerger: merged xxx documents in yyy ms
into _aka.  
>> (IndexMerger.java, line 304)
>> Where xxx is a number, usually 1000 and yyy is a
number between 100  
>> and 2700
>
> the IndexMerger runs in a background thread and does
not have an  
> immediate effect on the performance you see when you
call JCR API  
> methods.
>
> regards
> marcel

Wade Girard
wade.girardgmail.com

Wade Girard wrote:
> The log output from jetty when uploading these files
looks like:
> ...
> 06.06.2008 09:32:11 *INFO * IndexMerger: merged 1000
documents in 110 ms 
> into _cdr. (IndexMerger.java, line 304)
[...]
> ....
> I do not see output like this in the log files when I
am putting/getting 
> jpg, png, or other file types that I have been using
other than xml.

this clearly indicates that the XML files are stored
exploded in the workspace.

> If all I need to do to get consistent behavior is to
tell jackrabbit to 
> treat all files as binary, then it would be nice to
have that as an 
> option in the repository.xml file. Is this possible?

yes, it is. you can find handler for various types in
WEB-INF/config.xml

though, I'm not sure whether it is the iohandler or the
propertyhandler you have 
to change.

regards
  marcel

Hi,

On Fri, Jun 6, 2008 at 5:50 PM, Wade Girard
<wade.girardcomcast.net> wrote:
> Then I hop on another computer and start cadaver in a
terminal, I open a
> connection to http://host:8
080/jackrabbit-webapp-1.4/ repository/default,
> log in using a username and password, then create a
"column" using cadaver,
> mkcol views, then I cd into that "column" and
"put" a bunch of xml files,

Another guess at what's going on: The WebDAV support in
Jackrabbit is
configured by default to explode all XML documents into a
subtree of
nodes. This takes time especially when dealing with large
XML files
(it's roughly O(n) on the number of XML elements).

> If all I need to do to get consistent behavior is to
tell jackrabbit to
> treat all files as binary, then it would be nice to
have that as an option
> in the repository.xml file. Is this possible?

This is actually an option of the WebDAV mapping on top of
the JCR
level. You can configure it in the /WEB-INF/config.xml file
within the
Jackrabbit webapp. Just remove the XmlHandler (and
ZipHandler if you
like) entries to disable the special processing.

BR,

Jukka Zitting

That did it! Thank you so much everyone who helped.

And you'll be happy to know that jackrabbit, with this
change, is  
faster than slide.

Thanks,
Wade

On Jun 6, 2008, at 10:18 AM, Jukka Zitting wrote:

> Hi,
>
> On Fri, Jun 6, 2008 at 5:50 PM, Wade Girard  
> <wade.girardcomcast.net> wrote:
>> Then I hop on another computer and start cadaver in
a terminal, I  
>> open a
>> connection to http://host:8
080/jackrabbit-webapp-1.4/ repository/ 
>> default,
>> log in using a username and password, then create a
"column" using  
>> cadaver,
>> mkcol views, then I cd into that "column"
and "put" a bunch of xml  
>> files,
>
> Another guess at what's going on: The WebDAV support in
Jackrabbit is
> configured by default to explode all XML documents into
a subtree of
> nodes. This takes time especially when dealing with
large XML files
> (it's roughly O(n) on the number of XML elements).
>
>> If all I need to do to get consistent behavior is
to tell  
>> jackrabbit to
>> treat all files as binary, then it would be nice to
have that as an  
>> option
>> in the repository.xml file. Is this possible?
>
> This is actually an option of the WebDAV mapping on top
of the JCR
> level. You can configure it in the /WEB-INF/config.xml
file within the
> Jackrabbit webapp. Just remove the XmlHandler (and
ZipHandler if you
> like) entries to disable the special processing.
>
> BR,
>
> Jukka Zitting

Wade Girard
wade.girardgmail.com