jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <mreut...@adobe.com>
Subject RE: Evaluating jackrabbit use for media content
Date Thu, 10 Oct 2013 07:08:25 GMT
Hi,

on the repository level it depends on the configuration and
the deployment you have. the default configuration of a
jackrabbit-standalone server uses a FileDataStore. The Binary
implementation on top of a FileDataStore shouldn't read
the complete binary when you just request part of it with
read(byte[], long). each call translates into 1) open the file,
2) seek to the requested position 3) read the bytes and
4) close the file.

if this is not what you see with the default configuration,
then it's a bug and should be fixed.

Regards
 Marcel

> -----Original Message-----
> From: Santiago Gala [mailto:santiago.gala@gmail.com]
> Sent: Mittwoch, 9. Oktober 2013 13:38
> To: users@jackrabbit.apache.org
> Subject: Evaluating jackrabbit use for media content
> 
> 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
Mime
View raw message