Well that stack trace don't look like filesystem attachment storage stack trace. Attachment archives are handled by ListAttachmentArchive so we should have seen a ListAttachmentArchive#updateArchive call instead of the XWikiAttachment.updateContentArchive call.
I agree that your configuration looks right so not sure why you don't end up in the filesystem attachment store code. On Mon, Jan 12, 2015 at 10:05 AM, Paul Libbrecht <[email protected]> wrote: > Thomas, > > I believe I am using the filesystem attachment. At least that's when I > thought when using the following configuration: > >> # enable attachment filesystem storage >> xwiki.store.attachment.hint=file >> xwiki.store.attachment.versioning.hint=file >> xwiki.store.attachment.recyclebin.hint=file > > Any other way for me to proof? > > thanks > > Paul > > > On 12 janv. 2015, at 09:38, Thomas Mortagne <[email protected]> wrote: > >> When saving an attachment XWikiAttachment.updateContentArchive produce >> a base 64 String of the attachment (so a lot bigger than the >> attachment size) before copy it again as String[] (so again double the >> size in memory) and then sending it to the database (which is not >> quite the streamed thing you would expect in case of MySQL for >> example). There is thing that can be improved (but not much we can do >> about non streaming MySQL connector) but yes currently default >> attachment store is not exactly great to store 600 Mb files unless you >> allocate a looot of memory to your XWiki instance. >> >> Filesystem attachment should support it well (been made just for this >> kind of use case after all), see >> http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Attachments#HFilesystemAttachmentStore. > > _______________________________________________ > users mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/users -- Thomas Mortagne _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
