Hi all, anyone ever get to the bottom of why WebFileUploader is so fragile? Particularly when uploading large files (and when I say large, just a couple of hundred MB)… it just stops part way though, no error, no event being fired, just dies. I see through trawling the forum that this has been going on for yonks. Are Xojo unable to fix what, on the face of it, is a fairly basic requirement? Very frustrating.
Are you uploading to a Server?
Is the Server configured to accept the couple of hundred MB?
1 Like
Hi Alberto… not sure what you mean… the web app is running on a server yes, and I’m uploading from a client? Is that what you mean? Are there some other config files somewhere that I don’t know about? But even so, you’d expect an error, anything, rather than the app just stopping and making us (me) look bad! 
If the server has nginx/apache the configuration may limit the upload size.
IIRC correctly Lifeboat configures the limit to 10MB.
If you are running only your Xojo web app there, then this does not apply.
It’s the latter that I’m launching using LaunchControl…
Create an issue, upload a sample project and put your machine specification. I don’t know if there is any set limit for Web2 so Ricardo needs to review the case.
1 Like
There are generally limits set for the total upload size when an app is run on a server behind apache or nginx, so even if you get it working locally, you’re probably going to run into issues later if your app ever goes live.
That said, running from the IDE or locally using launchd, there are a couple of things to keep in mind:
- Uploads are handled differently for small and large uploads. For uploads up to ~256K (last time I was there), they are handled completely in memory during the upload. Anything bigger is immediately streamed to a file on disk. This is done because Web Servers are typically slim on memory and often when using an SSD drive, are often not set up to use virtual memory if things get tight.
- Uploads use a lot of CPU. Even though everything that comes into the app is shuttled off to a thread, uploads come in on a main thread socket. This means that they tend to slow things down for everything else. Use Activity Viewer to see what your CPU consumption is.
Beyond that, you might be able to find a developer that has made a different file uploader component. The WebSDK exposes the front and back end of the uploader separately specifically to foster innovative solutions.
Hi Greg,
There are generally limits set for the total upload size when an app is run on a server behind apache or nginx, so even if you get it working locally, you’re probably going to run into issues later if your app ever goes live.
That being said then, why don’t Xojo do something about this? Seems odd that this is a known issue for a live distribution - effectively rendering the control unrealistic to use in a commercial offering.
Also, during the upload process, less than 1% CPU, it’s running on a mother of a MacPro! Probably as fast a Mac that money can buy! Loads of RAM and loads of disk space.
I have looked at another upload solution, which does work, but doesn’t fit my site design and the developer has other projects on the go at the moment.
But, I still maintain that the given control should work as advertised. Why offer it if it doesn’t work as stated?
Xojo can’t. Apache and nginx sit in front of your app.
Xojo uses a single core and cooperative threads. If you have 16 cores, it uses 1. If you have 40 cores, your app still shares 1 for all sessions.
This is why XojoCloud and other offerings run multiple instances of your app, to take advantage of all available cores.
But, as you said, other developers have managed to do it, so technically, they can?
Appreciate that Greg, but the MacPro is up to plenty of other stuff too!
The others do it by changing the settings of Apache and Nginx.
Xojo does have a solution. It’s called XojoCloud.
1 Like
I see, however, my reasoning behind hosting the app on the server locally is it then needs to store the file data in to a blob field in an SQL database on a server which is also hosted locally.
No I don’t.
1 Like
DIdn’t mention you specifically Anthony. So no need for that comment I don’t reckon.
Just pointing out that I do it without modifications to the reverse proxy.
You are a Javascript God though.
1 Like
Haha. Hardly.
To summarise then, Xojo include a control that they know doesn’t work on a live server. You’ve suggested Xojo Cloud and you say it works there (unlikely to test) - but effectively that’s Xojo asking for at least another $49 a month to get a control working as advertised. Very ■■■■ Turpin-esque.