jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Reschke <julian.resc...@gmx.de>
Subject Re: Evaluating jackrabbit use for media content
Date Tue, 15 Oct 2013 10:10:25 GMT
On 2013-10-15 11:33, Santiago Gala wrote:
> On Mon, Oct 14, 2013 at 9:33 AM, Marcel Reutegger <mreutegg@adobe.com>
> 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,

Mime
View raw message