On 2013-10-15 11:33, Santiago Gala wrote:
On Mon, Oct 14, 2013 at 9:33 AM, Marcel Reutegger <[email protected]>
wrote:
Hi,
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.
you are using the built-in WebDAV support of Jackrabbit. I don't know
I have also tried the RMI connection, and in this case the problem is that
If I use RMI via, http://jackrabbit-server/rmi URIs, Jackrabbit copies
binaries to java.io.tmpdir every time they are used in a session, and
doesn't delete the copy when the session is disposed.
org.apache.jackrabbit.rmi.value.SerializableBinaryValue is the place where
the temporary is created, and never deleted.
The snippet is:
if (n.hasProperty("jcr:data")) {
Value v = n.getProperty("jcr:data").getValue();
if (v.getType() == PropertyType.BINARY) {
Binary b = v.getBinary();
System.out.println("Binary class: " + b.getClass().toString());
byte[] buff = new byte[100];
// InputStream ios = b.getStream();
// ios.skip(b.getSize() - buff.length);
// System.out
// .println("Stream class: " + ios.getClass().toString());
// int len = ios.read(buff);
// ios.close();
int len = b.read(buff, b.getSize() - buff.length);
System.out.println("Binary(" + len + "): "
+ new String(buff, "UTF-8"));
b.dispose();
}
v = null;
}
The alternative getStream() implementation shown in comments leaves the
same temporary files in java.io.tmpdir.
This is a no-no for me, as having one non-deleted copy of a 1G file per
session will fill any temporary space I could design when we use it for
media, and we have no simple way to know when the file is no longer in use.
the dispose implementation is supposed to delete the file, but this is not
happening in my tests, not sure why. It is supposed to be called by myself,
as you can see, and also automatically on finalize... I guess something
related with the transient nature of the file or the stubs is avoiding the
finalization to be called for RMI objects... This is probably a bug and
discards RMI for us.
Using a /server URL does not leave the temporary files on exit.
the implementation that well, but it may well be that it doesn't support
the seekable access you need.
It does answer to any request that includes the header "Range: bytes=0-200"
with a 200 status and the whole file (700 Megs in my test). Further,
nothing in what I have peeked into the implementations of jackrabbit
stable, unstable or oak hints to support of byte ranges at the DAV server
side.
...
Well, if this (Range request support) is indeed missing, we really
really should add it.
Best regards, Julian
Best regards,
