Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of santiago.gala@gmail.com
 designates 209.85.214.174 as permitted sender)
MIME-Version: 1.0
Date: Wed, 9 Oct 2013 13:37:53 +0200
Message-ID: 
 <CAPXTYCUjVYJxsMCaJCTe2rYAqQnLOtLv3SwU5pOV8++D8-s21g@mail.gmail.com>
Subject: Evaluating jackrabbit use for media content
From: Santiago Gala <santiago.gala@gmail.com>
To: users@jackrabbit.apache.org
Content-Type: text/plain; charset=UTF-8

Hi all, I am evaluating the performance and suitability of jackrabbit
as a store for media (as in big movies).

We have some specific requirements:

* media needs to be accessed by native components via filesystem, dav,
http or a similar solution
* On the JCR side, media getStream() needs to be seekable, or
similarly Binary.read(byte[], long) needs to seek and not read the
whole file
* we need to connect to repository via network (

For what I'm seeing with last stable release (2.6.3) and current
unstable (2.7.1) in some simple tests, getStream or Binary.read reads
the whole file in and later select. Also I'm seeing unstability and
errors in the use of jackrabbit as a DAV server with gnome gvfs
(ubuntu 13.04 is deeply broken) or even mount.davfs.

I would have expected that a technology so mature and used for big
size files (video, audio, documents) would use
"content-length"/accept-ranges"/"content-range" headers to implement
seekability in DAV or pure HTTP, both in the jackrabbit and the linux
sides (libneon, basically), and also that the Binary.read
implementation would use them, but this is not the behavior I'm
seeing, either in the JCR side or the OS/DAV side.

I'm puzzled. Any pointers to resources describing the status of the
field WRT seekability of JCR file resources with different backends?
Googling extensively is not delivering any meaningful result.

Regards
Santiago