Upload max file size, need to increase

I tried these above,
not working
I edit server.xml in tomcat/conf, add a line
Then , come back to original server.xml file.

And I cannot get the service running again : error 503
I get this message :
503 Service Unavailable

Service Unavailable

The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
Apache/2.4.38 (Debian) Server at arpille.com Port 443

I reboot the server : same error

I am new with Tomcat/Lucee
Can you help me ?
Thanks.

Pierre, as for your 503 error,

  • are you really saying that the only change you made was to the server.xml? Nothing else since it last worked?
  • are you saying you backed up that file and reverted to it? If not, did you manually delete what you modified? If the latter, and that’s the “only change” you made, it would seem you made a mistake in removing your change
  • you refer to having added a line. The SO article did not discuss adding a line to that file, but instead adding an attribute to a line

And as for the change discussed even in that SO file, noye that it refers to changing the http connector, but you may have things setup so that instead it’s the ajp connector you’re using, and if so you need to modify THAT line in the server.xml file.

If you could first get things back to working as before, then try this second change to see if it fixes the post size issue.

If it does not, please share more what’s the exact error you get on the upload? How did you install lucee, as there are many ways. What configuration did you make regarding lucee after install?

I did add this : In conf\server.xml (tomcat dir of lucee)

Then error 503
I put back excatly as it was, and it does work again now.

So the question is how to modify the upload max file size ?
It seems to be limited at 2Mo.
Is that a parameter to change in the Lucee admnistrator (web or context)

Thanks for your help, that is a blocking factor for me.
Pierre.

Pierre, something in the formatting of your message seems improper. We can see you say, “I did add this”, but we can’t see what the this was.

Anyway, good to hear first that you’re no longer getting the 503. If you mean you got it WHEN you made the change, well yes, if you make any mistake in editing that file, you can find that either Tomcat/Lucee (and ACF) won’t start, or you may get 503’s. Once we see what you added, that may help us see what went amiss.

And as for the “blocking factor for you”, again please clarify whether the change you made was to the http or ajp connector in that file. The default for maxPostSize (if not specified there) is indeed 2mb (specified in bytes, so 2097152), as documented here. To change it to 4mb, for instance, use maxPostSize=4000000 (a 4 and six zeros). Note also that attribute names in that file are case sensitive.

Thanks for help,
What I added is : (in tomcat/conf/server.xml)

Connector port="80" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443"
                maxPostSize="67589953"

In fact I left it under comments, then I had the 503 error,
When I erase it (no comments, just as original) it worked again.

So I do not see where (what file) to make a change or add the code to get a higher post size.
Thanks again, why this is not in the Lucee admin ?
Pierre.

Hi @Pierre_Larde,

@carehart gave already good advices. It’s very difficult for us to know what is causing your 500 errors without knowing the exact changes you’ve done. Also, it is very specific to your settings. But I’ll try to add some information that might help you:

These settings are very specific web server and servlet engine settings, not CFML settings. Thus, they should be configured within the Web Servers (e.g. IIS, Apache2, NGNIX, etc.) or Servlet Engine (Tomcat, Undertow, etc.) that you are using in your specific setup. This should not be handled by the Lucee Admin.

Also, some settings might need to be set in your Web Server AND Servlet Engine, depending on their respective default settings and your specific needs.

A very common issue I’ve seen with cfml administrators is that they tend to set cfml comments with the triple dash in the server.xml ( <!--- This is a CFML comment that will break your server.xml --->), instead of XML comments with double dash <!-- This is a XML comment that should work in your server.xml -->. However, making changes in the server.xml need to be done carefully, because Tomcats parser sometimes is a little sensitive (like with tripple dashed comments).

  1. Step: First you need to know to which Tomcat connector your Web Server Apache/2.4.38 is connected to. You commented above that you changed the connector of port="80". That is very unusual for Lucee in a default Lucee setup. Usually Lucee uses port="8888" (when configured with reverseProxy) or “port=8009” (when configured with AJP). Yours is very, very, very likely port=“8888” (your Tomcar is open on that port ) . Open your server.xml and search for the string port="8888" and you should find your active connector setting .

  2. Step: When you know which connector is configured ( from “1. Step” ) in your server.xml, add the attribute maxPostSize=“67589953” to that specific connector.

  3. Step: Restart Tomcat Lucee and try the upload through port:8888 to see if it works.

  4. Step: If “Step 3” works, try it on your web servers 443. If it doesn’t work on port 443, then you’ll need to add that configuration to your Apache2 web server also. Then you go to Step 5.

  5. Step: If you can’t upload the files on port 443, then you need to add the directive line LimitRequestBody 67589953 to your Apache2 configuration, what will probably be in your /etc/apache2/apache2.conf (for global configuration) or in your VirtalHost file configuration for arpille.com

  6. Step (Important): Please, consider locking down your Lucee server:

Keep us updated :smiley:

I agree with the comments issue : <!— break the file
your points :
1 - Lucee uses `port=“8888” , this is what I find in the lucee/tomcat/conf/server.xml
2 - Then I added the line : maxPostSize=“67589953”
Connector port=“8888” protocol=“HTTP/1.1”
connectionTimeout=“20000”
redirectPort=“8443”
maxPostSize=“67589953” /
3 - Not better after restarting Lucee, may be it does not upload through port 8888 ?
4 - no try on port 443 (i do not understand)
5 - I added LimitRequestBody 67589953 in the apache2.conf as a new line
restart apache and lucee.
Same error : Bad Gateway
6 - I do not understand what is : consider locking down your Lucee server

I really need to find the solution, this is very important to upload files,
smartphone have photos of 10M , people do not know,
I am now limited at 5M , which unusable.
With no solution, I cannot continue this environment. (linux/apache/lucee)

The exact error message is :
502 Bad Gateway
Bad Gateway
The proxy server received an invalid response from an upstream server.
Apache/2.4.38 (Debian) Server at botaniquesysteme.fr Port 80

Thanks for help, manythanks for all.
Pierre.

Pierre, I still think you’re just changing the wrong line. Considering the url of the page you’re using (that fails), is it using port 8888? Are your users? I’d doubt that. Instead, you/they likely use a domain name and NO port.

In that case, again it’s the AJP connector not the http one whose line you want to add the maxPostSize attribute to. Reread my earlier comment, and let us know if that gets you going.

I have no knowledges on ports,
Then, I found port 8888 in the server.xml of lucee/tomcat/conf
Also , when accessing the Lucee admin :
http://85.14.138.82:8888/lucee/admin/server.cfm
All sites are accessed by domain names.
I do not understand well.
Thanks to follow this issue. I really need it.
Pierre.

Pierre, change the AJP connector line.

What is AJP connector line ?
where is this ?
What to write in what file ?
Thanks for precisions, I am not a specialist in that domain.
Pierre.

Pierre, in the server.xml you had found a line with this:

Connector port=“8888” protocol=“HTTP/1.1

I have been saying from my first comment that you would likely find also a line with a protocol value referring to AJP rather than http. Please search for AJP in that file.

Is the line commented out? Assuming it’s not, add the maxPostSize (again, case-sensitive) to that line. Please see my first comment for specifics on the value. Restart tomcat/lucee and let us know how it goes.

Well, I did so.
here is the lines I found (not commented) in server.xml, and I add the maxPostSize line
Connector port=“8009” protocol=“AJP/1.3”
connectionTimeout=“120000”
redirectPort=“8443”
maxPostSize=“67589953” /

Then restart Lucee.

I tried again to upload a file of 9756Ko (9Mo), get the same error : Bad Gateway
Retrying 3mn later,
It does work without error, the file have been well upload, (I can ear it, it is a mp3).

Then I tried to upload a 20Mo, no success : error Bad Gateway
maxPostSize is : 67589953 , means around 60Mo ?

Then coming back to a 9Mo (previous file) : Error again : Bad Gateway
The proxy server received an invalid response from an upstream server.
Apache/2.4.38 (Debian) Server at botaniquesysteme.fr Port 80

What to do ? other advise,

Also, when stopping and restarting Lucce, I loose some domains from the virtual host.
They work, then they deappear, not stable. So I am afraid when stop/start Lucee.
But this is another point to see later.
When all is working, I do not touch anymore to Lucee restart.

Thanks for assistance again,
Pierre.

Pierre, you say that the upload did work now, at least once. That seems good news, as your problem is then no longer about upload limits (and yes, the value you’re using is over 60mb, now well above the default of 2mb).

As Andreas had said, whatever remaining issue you have could be in the web server, in Tomcat, or in Lucee. You should be able to find an indication of the error in the logs for each, which would point to both where it’s happening and why.

Finally, it’s also possible that the cfml page that is receiving the file (perhaps doing a cf file action=upload) is itself delayed for some reason, causing the error, when Apache doesn’t get a response in the time it’s willing to wait. Again, that would be indicated in Apache logs, if so.

I appreciate you just want the problems to get solved. Like coding itself, this sort of troubleshooting involves a process of elimination and of debugging that you simply have to go through. If the answer was obvious (and if lots of people experienced the same), you would have found the answer in Google or from others days ago here.

Well, I looked into the logs,
The files found in lucee/tomcat/logs like : manager.2021-12-06.log
these log files are empty (blank).
I looked in the lucee directory which has been copied in the site root (the site where I did the tests) there are these files :
requesttimeout.log and exception.log which have been modified today. Other logs have not been modified.

In the requesttimeout.log : I find the folllowing

“ERROR”,“Thread-562”,“12/06/2021”,“14:22:15”,“controller”,"stop request (1) because run into a timeout. ATM we have 1 active request(s) and 0 active cfthreads (no path available).;java.lang.Throwable;java.lang.Throwable
at java.base@11.0.4/jdk.internal.misc.Unsafe.park(Native Method)
at java.base@11.0.4/java.util.concurrent.locks.LockSupport.parkNanos(Unknown Source)
at java.base@11.0.4/java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(Unknown Source)
at java.base@11.0.4/java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(Unknown Source)
at java.base@11.0.4/java.util.concurrent.CountDownLatch.await(Unknown Source)
at org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.awaitLatch(NioEndpoint.java:1064)
at org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.awaitReadLatch(NioEndpoint.java:1066)
at org.apache.tomcat.util.net.NioBlockingSelector.read(NioBlockingSelector.java:187)
at org.apache.tomcat.util.net.NioSelectorPool.read(NioSelectorPool.java:221)
at org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.fillReadBuffer(NioEndpoint.java:1230)
at org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.read(NioEndpoint.java:1139)
at org.apache.coyote.http11.Http11InputBuffer.fill(Http11InputBuffer.java:735)
at org.apache.coyote.http11.Http11InputBuffer.access$300(Http11InputBuffer.java:41)
at org.apache.coyote.http11.Http11InputBuffer$SocketInputBuffer.doRead(Http11InputBuffer.java:1070)
at org.apache.coyote.http11.filters.IdentityInputFilter.doRead(IdentityInputFilter.java:102)
at org.apache.coyote.http11.Http11InputBuffer.doRead(Http11InputBuffer.java:246)
at org.apache.coyote.Request.doRead(Request.java:551)
at org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:336)
at org.apache.catalina.connector.InputBuffer.checkByteBufferEof(InputBuffer.java:632)
at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:362)
at org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:132)
at org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:110)
at lucee.commons.io.IOUtil.copy(IOUtil.java:294)
at lucee.commons.io.IOUtil.copy(IOUtil.java:74)
at lucee.commons.io.IOUtil.toBytes(IOUtil.java:1071)
at lucee.commons.io.IOUtil.toBytes(IOUtil.java:1066)
at lucee.runtime.net.http.HTTPServletRequestWrap.getInputStream(HTTPServletRequestWrap.java:259)
at org.apache.commons.fileupload.servlet.ServletRequestContext.getInputStream(ServletRequestContext.java:112)
at org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl.(FileUploadBase.java:952)
at org.apache.commons.fileupload.FileUploadBase.getItemIterator(FileUploadBase.java:310)
at lucee.runtime.type.scope.FormImpl.initializeMultiPart(FormImpl.java:180)
at lucee.runtime.type.scope.FormImpl.initialize(FormImpl.java:126)
at lucee.runtime.PageContextImpl.formScope(PageContextImpl.java:1206)
at lucee.runtime.type.scope.UndefinedImpl.reinitialize(UndefinedImpl.java:620)
at lucee.runtime.type.scope.UndefinedImpl.initialize(UndefinedImpl.java:599)
at lucee.runtime.PageContextImpl.initialize(PageContextImpl.java:505)
at lucee.runtime.CFMLFactoryImpl.getPageContextImpl(CFMLFactoryImpl.java:194)
at lucee.runtime.engine.CFMLEngineImpl._service(CFMLEngineImpl.java:1138)
at lucee.runtime.engine.CFMLEngineImpl.serviceCFML(CFMLEngineImpl.java:1116)
at lucee.loader.engine.CFMLEngineWrapper.serviceCFML(CFMLEngineWrapper.java:97)
at lucee.loader.servlet.CFMLServlet.service(CFMLServlet.java:51)

In the exception.log (this log is of 10Mo, big)
I put in a new log file the example of the last 3 errors.
There are “timeout” and “java.io.IOException: Relais brisé (pipe)” kind of errors.
exception_extract.log (8.7 KB)
See attached file : which is an extract of the last 3 errors.

Does these mean someting to you ?

In etc/apache2 directory , there are no log files or directory.

Thanks for helping again.

Is there something to try with a htacccess file in the site WEB-INF directory ?

NB : I have this code in the file making the UPLOAD :
cfsetting requesttimeout = “600”

Pierre.

Are the log information posted above useful to understand the problem ?
Any other thing I can do ?
Thanks to follow.
Pierre.

Dear Pierre,

looks like you are making some progress. If you use cfsetting above “60” (value means 60 seconds) by setting it to “600”, you must adapt also Tomcats and your Web Servers timeout. Tomcat and Apache2 have a default timeout of 60 seconds, thus they will just timeout before Lucee

Explain: Setting timeout with cfsetting only tells Lucee to time out. But Tomcat and the web server Apache2 have also their own timeout setting. If your cfsetting is higher than Tomcats and Apache2, Tomcat and Apache2 will timeout before the cfsetting timout takes effect. That means: you also need to change the settings for Tomcat and Apache2:

For Tomcat:
=> Open your Tomcat server.xml and go to the connector (the one that @carehart said) and change the value of connectionTimeout to connectionTimeout=“600000” (this value is in milliseconds, so 600 seconds need to be 600000). Then restart Tomcat.

For Apache2:
=> Change the request timout for Apache2 (default is 60seconds) to 600. Here you can find instructions to change the timout for apache2

Then try again, if an error (bad gateway) occurs, watch for new error/exception logs and let us know about your progress.

1 Like

I did the 2 modifications,
in Tomcat : timeout : 600 (connectionTimeout=“600000”)
and in Apache : Timeout 600 in apache2.conf

Still, same result : bad gateway

It seems, there is no solution to this need.
Thanks to make your possible to find this.
Pierre.

All is very strange ,
I succeeded to upload a 9Mo file,
Then I tried a 18Mo file : Error : bad gateway
I tried again the file of 9Mo , and this time I get this Timeout message :
|Message|request /audio_plantes/admin/plante_modif_go.cfm (/var/www/C010/site/audio_plantes/admin/plante_modif_go.cfm) has run into a timeout (timeout: 50 seconds) and has been stopped. The thread started 51391ms ago.|

All parameters are set to 600 for the timeout, and Lucee says that the timeout is of 50sec.

Thanks for help, advise, ideas …
Who is limiting the timeout, and the max file upload ?
I think, I need to understand how linux,Apache,Tomcat,Lucee works together ?
Who is doing what, is there a guide line for this ?
Thanks, Pierre.

Pierre.

@Pierre_Larde… we will figure that out. Just keep trying. I can tell you that Lucee is capable of doing big file uploads. Distrokid.com runs with Lucee and they really have a high volume of uploads.

Somehow it looks like your Lucee request setting is not being honored. Can you try setting the Lucee request timeout in the admin at server level for testing? Do the following: Log into your Lucee Server Admin and go to Settings => Request and set your Request Timeout there.

Also…
Is it possible that your server is receiving the data sometimes with a slow connection, slowly or with delays? E.g. if your client (browser) connection has a slow upload or some delays, or your servers performance or connection is slow, then it is very possible that Lucee may timeout. Lucee will simply need more time to receive the binary file data from the browser. I suspect the sporadic changes between upload success and timeout is a sign for that.

Please try setting the timout in the admin and let us know.