jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Klimetschek <aklim...@day.com>
Subject Re: Problems storing/accessing very large files via WebDAV
Date Thu, 30 Apr 2009 08:21:18 GMT
It could be https://issues.apache.org/jira/browse/JCR-2009 which was
fixed in Jackrabbit 1.5.5.

Regards,
Alex

On Thu, Apr 30, 2009 at 1:22 AM, Laird, Nicholas J.
<Nicholas.Laird@gd-ais.com> wrote:
> I am having an issue when storing and retrieving very large files (
> 400MB -> 2GB ) to my Jackrabbit repository via WebDAV.  I am using the
> FileDataStore to store resources of size greater than 100 bytes (i.e.,
> the default configuration for FileDataStore on the Jackrabbit wiki).
>
> I need to support these large files and have the repository presented to
> the end user as a mapped network drive in Windows Explorer.  I have
> tried using both Windows Explorer's built-in WebDAV client (by mapping
> my repository as a network drive) and a product called WebDrive, which
> also does network drive mapping.  Performance with WebDrive is better
> (Explorer seems to have known WebDAV issues, at least in Windows XP),
> but for large enough files even it gets bogged down and confused.
>
> When uploading a file by drag/drop to the mapped network drive in
> Explorer, the upload seems to proceed and finish normally, from the
> WebDAV client's perspective, however Jackrabbit is performing some sort
> of internal caching (it seems) while the WebDAV session is still "open",
> with the client believing that the transfer is still in progress.
>
> A snippet of the Jackrabbit log file (with trace logging enabled) during
> the transfer is below.  Notice the timestamp difference between lines 3
> and 4:
>
> 1) 29.04.2009 16:04:56 *DEBUG* ImportContextImpl: Starting IOHandler
> (org.apache.jackrabbit.server.io.DefaultHandler)
> (DefaultIOListener.java, line 43)
> 2) 29.04.2009 16:04:56 *DEBUG* ItemManager: caching item
> e7ab8f92-d6a5-4bbf-bb9c-fb7e0ab9042e (ItemManager.java, line 787)
> 3) 29.04.2009 16:04:56 *DEBUG* ItemManager: caching item
> e7ab8f92-d6a5-4bbf-bb9c-fb7e0ab9042e/{http://www.jcp.org/jcr/1.0}data
> (ItemManager.java, line 787)
> 4) 29.04.2009 16:05:12 *DEBUG* ItemManager: caching item
> e7ab8f92-d6a5-4bbf-bb9c-fb7e0ab9042e/{http://www.jcp.org/jcr/1.0}mimeTyp
> e (ItemManager.java, line 787)
> 5) 29.04.2009 16:05:12 *DEBUG* ItemManager: caching item
> e7ab8f92-d6a5-4bbf-bb9c-fb7e0ab9042e/{http://www.jcp.org/jcr/1.0}encodin
> g (ItemManager.java, line 787)
> 6) 29.04.2009 16:05:12 *DEBUG* ItemManager: destroyed item
> e7ab8f92-d6a5-4bbf-bb9c-fb7e0ab9042e/{http://www.jcp.org/jcr/1.0}encodin
> g (ItemManager.java, line 884)
> 7) 29.04.2009 16:05:12 *DEBUG* ItemManager: removing items
> e7ab8f92-d6a5-4bbf-bb9c-fb7e0ab9042e/{http://www.jcp.org/jcr/1.0}encodin
> g from cache (ItemManager.java, line 801)
> 8) 29.04.2009 16:05:12 *DEBUG* ItemManager: caching item
> e7ab8f92-d6a5-4bbf-bb9c-fb7e0ab9042e/{http://www.jcp.org/jcr/1.0}lastMod
> ified (ItemManager.java, line 787)
> 9) 29.04.2009 16:05:12 *DEBUG* ImportContextImpl: Result for IOHandler
> (org.apache.jackrabbit.server.io.DefaultHandler): OK
> (DefaultIOListener.java, line 50)
>
> 16 seconds isn't an eternity, but the time increases as the size of the
> file increases.  At a large enough file size, Explorer gives up on the
> transfer with a "Write Delay Failed" error and WebDrive thinks the
> server has taken too long to respond and times out.  WebDrive can be
> configured to wait longer, but I have had to increase the time to 2
> minutes to try to manage files nearing 2GB.
>
> During downloads, the same situation occurs, except "caching item" of
> the jcr:data property occurs before the download can start.
>
> I am not sure exactly what Jackrabbit is doing or if there is a way to
> speed up the process (or prevent the caching altogether, if that is
> indeed what is happening).  It could be that some other operation is
> occurring that is not being revealed by the logging (though the trace
> logging seems pretty thorough and verbose).
>
> Any suggestions on how to configure or optimize for this situation is
> greatly appreciated.
>
> Sincerely,
> Nicholas Laird
>
>



-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Mime
View raw message