Paul,
yes, I think it is just a nice value for the user (on the other hand, I know
at least one WebDAV client that ignores GET's Content-length if it received
a PROPFIND before, leading to a nice crash due to a buffer overflow.).
Ok, so now I added the "hardcore" way to our SVN HEAD (manually streaming to
dev null and counting) so people can look up the code if they like to do
something similar in future (to be found here:
https://webdav-addressbook.dev.java.net/source/browse/webdav-addressbook?rev
=26
<
https://webdav-addressbook.dev.java.net/source/browse/webdav-addressbook?re
v=26&view=rev> &view=rev ). On my laptop, it needs more than one second now
to show 1000 rows (a quarter of a second without). But hey, it is a sample
app! ;-)
For the performance anecdote: The dark side of the anecdote is that it
proofs that using a second thread makes no sense if the job to do in the
background will take less than half a second. In other words, all those nice
multi core desktop CPUs will be no benefit, even with Java 7's fork/join, as
least desktop jobs will take more than half a second. I hope that this time
can get reduced soon to let's say 1/10 of a second, otherwise fork/join
wouldn't make much sense.
Have Fun
Markus
From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
Sent: Dienstag, 29. Dezember 2009 17:26
To: users_at_jersey.dev.java.net
Subject: Re: [Jersey] How to find out content-length *before* unmarshalling?
On Dec 29, 2009, at 4:43 PM, Markus Karg wrote:
Paul,
oops, seem's you're right. Strange that all currently tested WebDAV client's
don't care about this.
I think it is one of those things utilized for browsing WebDAV using say a
file-based browser, like the MacOS Finder.
On the other hand, the spec doesn't say that it must be the same value in
both cases, just that the property must be provided: Since both operations
could be interrupted by a second client modifying the length (as LOCKing is
not mandatory in WebDAV), it wouldn't make sense anyways.
BTW, just for anybody interested in it: Just finished performance tests with
WebDAV ontop Jersey. Directly listing in Vista FileExplorer (1000 "files"
taken from a embedded derby db using JPA via Jersey) on a dual core laptop
needs just a quarter of a second. For comparison: The same machine needs
several seconds to provide the same view using it's local physical NTFS.
That's just gread. :-) Strange but true, using a single thread and storing
the XML byte stream in RAM to later rewrite it is two times faster than
using two threads working in parallel using Piped*Stream or
BlockedLinkedList<ByteBuffer> -- Java's memory management seems to be
lightning fast, compared to a Thread context change (even when using
Executors.newChachedThreadPool)! Daniel worked hard on support for Windows
7, W2K3 and Office WebDAV clients, and I fixed Vista support. Seems all
current Windows OSs work well and fast now. We'll release all fixes within
2009, so in 2010 people can have complete and performance optimized "file"
API based access to their server side data. Looks like we'll have a big
party on dec 31! :-D
Cool! Thanks for the anecdotal performance info, it is very useful to hear
that.
Paul.