Hi.
I’m testing the xwiki:9-mysql-tomcat docker image, and I’m having problems importing large xar files.
The error is: “The file xxx.xar is too large. Please choose files under 32.0 Mb”.
Using the 8.4.5 image, I can import the file without problem.
I have already increased the attachment size limit and successfully attached the same xar file in the Sandbox page.
I’m thinking that maybe is a bug.
Is there a way to manually upload the file?
Thank you.
AFAIK, there should be no difference between XWiki 9.x and 8.x regarding filesize attachment limits.
So you can attach to a Sandbox page but not import in Admin UI? That’s strange indeed since importing in the Admin UI means attaching the file to a wiki page. Could you restart your wiki and try again to import the XAR?
Thanks
I tried but got the same error.
If I go to Sandbox/#Attachments and select the file to upload, I get the same error. In the previous test I was doing drag and drop on the visual editor.
Maybe the two ways of uploading use different settings?
Ok, have you tried to increase the max upload size to a greater value?
You may also need to tell your DB about the max packet size, I know MySQL has a default value that may be too low (if you’re on mysql - See http://platform.xwiki.org/xwiki/bin/view/AdminGuide/InstallationMySQL and search for “packet”).
Note that you could also switch to filesystem-based attachments, see http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Attachments
Yes, that’s the setting I mention in the OP that I have already increased. I’m using 268435456. I’ve followed this instructions http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Attachments#HSizeLimit
The docker image uses filesystem-based attachments by default. The only modification I have done to xwiki.cfg is to enable LDAP authentication.
This still applies if I’m using filesystem-based attachments?
In case I have not been clear. I can upload large files (~100MB) if I use drag-and-drop on the graphical editor. I cannot upload large files using upload forms (tested with XWikiPreferences?editor=globaladmin§ion=Import and Sandbox/#Attachments).
Is this expected? I would expect that the Maximum Upload Size value to apply for both cases.
Yes I know you did that but I was mentioning a bigger value than you one you’ve used! 
Indeed I had forgotten that I put that by default!
Nope.
It should. Again please try to increase the Maximum Upload Size value. What value did you put?
The default value is 33554432 (32MB). I’ve changed it to 268435456 (256MB).
Is something wrong with this value? I’m a bit confused about you mentioning “a bigger value…”
I will try to update it again to a larger value to see if something changes.
Changing the value to 536870912 (512MB) haven’t produced any change. Will try again after a restart.
This incident https://jira.xwiki.org/browse/XWIKI-12032 mentions that the browser may be caching some javascript related to upload. Will try clearing browser cache when xwiki restarts.
Maybe you don’t have enough space anymore on your hard drive (or database emplacement)?
Once I had this issue… 
Ok. Apparently this was the issue. After a forced refresh it let me do the upload
haha… had forgotten this and… but it seems documented at http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Attachments#HSizeLimit Guess we didn’t read it carefully enough!
Note that if you’ve already tried to attach a file and it failed, in order for the new size setting to be taken into account you might need to clear your browser’s cache.
ha ha … 
Thanks for your time and support
Piggybacking on this. This default on the docker image means that the filesystem-based storage is the recomended storage for attachments? I have this impression by reading other documentation as well. It would be great if you can confirm that. Thanks.
Yes that’s correct. We need to make it the default for the non-docker installs too. The reason we haven’t done this sooner is because there are still some known limitations.
Since I’m the one who created the Docker distribution, I took the decision to configure filesystem attachments since I believe the issues it fixes are greater than the issue that still exist with it. I could be wrong though and if you notice problems let us/me know!
Thanks
Will do. Thanks!