Enterprise Client Community

for big files upload should also be asynchronous to avoid heap space exceptions

...received: will be treated as "mid-term" activity... (1-2 months), maybe even a bit longer, we should keep contact on this issue...
Björn

this issue is again very actual, because we have really big files (>140mb) we want to upload with the captain casa client to the server.
Any news here?

No, issue is still queued.
Will check again...

Björn

Hi,

In the meantime, the feature is released...

I am also interested in uploading files close to the mentioned range. I have tried to upload a file of size 65mb. I have taken the example of the demo workplace with the variant StreamContent. At the very end of the byte count, the red message "Java heap space" is written.

What heap space is meant? The client JRE one or the server Tomcat one? I have increased both (-Xmx1280m in applet parameter and in startserver.bat) and also set compression="force" for the Connector element in server.xml without improvement. Can you actually now upload files >140mb? What are your tuning experiences and recommendations?

Regards, Daniel

Hi,

client side or server side? If client side message then you see the yellow-red-screen ("Tequila screen") with message inside. If it's server side then you see an plain error output (stack trace).

There are two buttons in the demo for asynch. upload: the one with byte[] processing, the other one with server side stream processing. The byte[] example is the one which requires a lot of server side memory: the upload is collected on server side as byte array, i.e. it is kept in memory. In the stream example the whole file "flows" through the systems, both on client side and on server side.

We just tested our demo workplace (we increased the max-sizes in the component definition to 100MB and did set the Tomcat server.xml maxPostSize parameter to "0") - no problems occurred with 70 MB Upload sizes - with stream processing.

Björn

Hello

we switched to asynchronous fileupload because of facing very big files in some use cases and yes, this works great!

But now, that it is asynchronous, users can go on before upload is finished. this is unprovided for our framework right now, so perhaps we could run into trouble. Would it be possible to add an attribute that fileupload dialog opens as modal popup, so that the rest of the application is locked?

another thing i want to point at: the url label which is displayed is in our case larger than the upload dialog. This doesn't look very nice.

Hi,
yes this is possible - we just need to check how to tell the component (there are more and more attributes and it is more and more complex to properly define the role of each attribute...).
Björn

...new attribute with asynchronous upload components: INFOPOPUPTYPE, values "modal","modeless" - available with next update (or on request)...

Björn

thank you.

i have another question on async upload:

my idea was just to copy input stream to fileouptputstream, but the problem is, stream starts with:

FILENAME0=C%3A%2FDokumente+und+Einstellungen%2Fkrinninger%2FEigene+Dateien%2Fcar.png&CONTENT0=

is there a cause why this info is delivered in stream? can this be removed?

Hi,

yes, in case of uploading multiple files we need some kind of separation, so each file name / file content is transferred as own parameter.

Björn

even if multiple files are not allowed?

...and: the file is sent as normal http-post-request - and this allows to pass data via parameters.

Björn

thats okay.

but now i face another problem.

i just get an binary input stream.
if an char-encoded file is uploaded i just can create an binary file on server side. But thats not what i want, i just want to have an 1-to-1 copy of the file beeing uploaded

Do you have any idea how to solve this problem?

Hi,

hmmm, I do not understand what you mean: the stream contains the byte data of the client sile file - if it is a .txt or a .bmp file. Any issue with character encoding is "application issue".

Could you give an example (e.g. attach example file) to explain? THanks!

Björn