jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <santiago.g...@gmail.com>
Subject Evaluating jackrabbit use for media content
Date Wed, 09 Oct 2013 11:37:53 GMT
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.


View raw message