Different behavior of Upload along with ProgressIndicator

Hi all,

I am developing and testing my code on a Mac OS and all is working as expected but
when the code is uploaded on a Linux server under Tomcat container the behavior of Upload & ProgressIndicator becomes weird.
Seems just as a thread is locked and all other visual progress is frozen. The Upload control’s view becomes like ordinary input type=“file” and ProgressIndicator remains hidden. The file uploaded and saved at the end but without any vaadin’s UI renderings. Seems like a problem with threads.

By the way the only difference is Java 6 on a development machine and Java 5 on the hosting server.

I have built my code on the base of a sample

Upload With Progress Monitor

just implemented my own Receiver with a following method

        public OutputStream receiveUpload(String filename, String MIMEType) {
        	FileOutputStream fos = null; // Output stream to write to
            fileName = filename;
            mtype = MIMEType;
            file = new File(folder, filename);
            try {
				fos = new FileOutputStream(file);
			} catch (FileNotFoundException e) {
				return null;
			return fos;

Can I somehow avoid a such incompatibility ?
Looks like a bug related to Java version.

Similar thing is happening for me.
I implemented the sampler…but if I take uncheck the “simulate slow server”, the window is frozen and I cant see the progress bar at all.
ut, when Simulate Slow server" is checked, then Thread.sleep works and I can see what I am supposed to see.


I’d be really surprised if this is due to the JRE version.

I just committed a huge refactoring to upload related things to 6.5 branch. I might have some time next week to look into this issue. I’d be very pleased if you find some time to test whether this issue is still relevant with 6.5 nightly build (tomorrows). If so, then please post all possible environment related info: browser, server os, client os, jre, application server, vaadin test app.

BTW. 6.5 nightlies appear to be uploading to wrong directory:
http://vaadin.com/download/nightly/6.4/ . The next ones should go to right location.

Update: 6.5 nightlies now in right place: http://vaadin.com/download/nightly/6.5/


I have just tested that with the latest nightly of 6.5 and that weirdness still there. So refactoring did not resolve the issue.

Any ideas ?



No ideas. I haven’t been able to reproduce the issue, so it is quite impossible for me to say what is happening with these details.

I’d need a test case (a small test app that can be used to reproduce the issue) and complete environment description (versions of browsers, os, server software, jvm + params, and possibly network details as this may be related to e.g. timing or firewalls) to help you.


Hi Matti,

That is not an issue, I will create an example, put in on my server and provide you the source code along with environment description.
I am glad you are in since that is a really cool feature what does not work for me.


As was promised I prepared a
simple application
there the upload control is used along with ProgressIndicator. I can provide you with all additional information and sources if any needed. But the issue exists for following configurations:

SUSE Linux Enterprise Server 10 (x86_64)
JRE 1.6.0_21
Tomcat 6.0.26
Apache with Tomcat via mod_jk

CentOS release 5.5 (Final)
java version “1.6.0_0”
OpenJDK Runtime Environment (IcedTea6 1.6) (rhel-1.13.b16.el5-x86_64)
OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode) on the CentOS
Tomcat 6.0.26
Apache with Tomcat via mod_proxy_ajp

Any news from you are highly appreciated and I will respond to you immediately.


I tried quickly on your test app and it seams like the actual file upload request is not passed to the application server (from the front end apache) until it is fully sent from the client. Or the tomcat is for some reason waiting for the whole request until passing it for Vaadin servlet. Maybe this can be modified with some setting in mod_prozy/mod_jk? I hope it is easy to solve. An experienced java hosting expert (which I’m not) might be able to give the right solution without further inspection.

If nobody else can hint for the right solution, I hope to find some time to investigate this more soo.


Hi Matti,

Thank you for your effort. You have pointed me in the right direction. The tomcat conf/server.xml contains the following settings:

<!-- A "Connector" represents an endpoint by which requests are received    
     and responses are returned. Documentation at :                         
     Java HTTP Connector: /docs/config/http.html (blocking & non-blocking)  
     Java AJP  Connector: /docs/config/ajp.html                             
     APR (HTTP/AJP) Connector: /docs/apr.html                               
     Define a non-SSL HTTP/1.1 Connector on port 8080                       
<Connector port="8559" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />   

The application works correctly when I am requesting it directly on the 8559 port instead of 80. So that is definitely an Apache to Tomcat bottleneck issue. I will try to find more details related to the issue but at the end I know the direction to go.

P.S. BTW it seems an important issue because lots of people use the Apache + Tomcat pair and it would be useful to know how to deal with.


I’m having similar issues with a home-grown modal window that implements the ProgressIndicator and all the callbacks to manage upload status as well (similar to what’s implemented on the Samples page).

I put together a simple app that runs under Jetty and the same behavior is being shown. Maybe it’s the way I’ve coded all the callback listener’s, but I followed the Samples example pretty closely. If anyone wants to take a look, I’ve attached a ZIP of a simple maven project. Try picking a large file to upload to see the behavior.

Is there any update on this issue at all?

11556.zip (7.56 KB)

Note that the GWT Uploader project supports the displaying the upload progress as well - but all on the client side. So that’s another option you could consider:


Best of luck,