jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <sg...@apache.org>
Subject Re: Evaluating jackrabbit use for media content
Date Thu, 10 Oct 2013 15:02:10 GMT
Marcel Reutegger <mreutegg <at> adobe.com> writes:

> 
> 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.

I am connecting to a default jackrabbit-standalone server, which
should use a FileDataStore. I'm connecting to it with code like:

		Map<String, String> parameters = new HashMap<String, String>
();
		parameters.put("org.apache.jackrabbit.repository.uri",
				"http://localhost:8080/server");
		Repository repository = null;
		for (RepositoryFactory factory : ServiceLoader
				.load(RepositoryFactory.class)) {
			repository = factory.getRepository(parameters);
			if (repository != null)
		Map<String, String> parameters = new HashMap<String, String>
();
		parameters.put("org.apache.jackrabbit.repository.uri",
				"http://localhost:8080/server");
		Repository repository = null;
		for (RepositoryFactory factory : ServiceLoader
				.load(RepositoryFactory.class)) {
			repository = factory.getRepository(parameters);
			if (repository != null)
				break;
		}
(...)

So I guess there are at least three components involved:

* The backend JCR repository
* The webdav access to it via jetty
* The client library in my program side.

I was thinking that webdav would enable some kind of seekable access,
but I think one of those components is breaking the chain. I don't 
understand how is one supposed to get seekable access when the repository
is accessed via network.

I'm not sure if it is a bug or just that I'm not using the typical setup...

Regards
Santiago

> 
> 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 <at> gmail.com]
> > Sent: Mittwoch, 9. Oktober 2013 13:38
> > To: users <at> 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