I'm using the Java Servlet 3.0 to upload files, using the #MultipartConfig annotation and request.getParts() to obtain the files.
When a file is uploaded, a TMP file is created in the Web Application work directory (tomcat/work/Catalina/localhost/webappname). For example:
upload_7c59101b_9f97_4e3f_9fa5_e484056d26fa_00000209.tmp
The application copies the file to another directory on the server - I'm doing this using the part.write() method but it's also working by obtaining the input stream and writing the bytes. Either way works fine.
I need to remove the TMP files after the upload, but I'm having trouble doing so. The part.delete() method doesn't do anything. I've also tried accessing the files in the directory using javax.servlet.context.tempdir and iterating over them to delete, but when calling a delete method, it always returns false. Using the Files.delete(path) method from Files.nio returns an exception which claims the file is in use by another program (i.e. locked) and therefore cannot be deleted. The server is running Windows Server 2012 R2.
Does anyone have any other solutions to remove these TMP files? It's worth pointing out that I've tried using a HttpRequestListener too, but still cannot delete the files.
Many thanks
You should (must!) not manipulate the files directly, you should use the getInputStream() method of the particular Part to get the content of the uploaded file. The servlet container (Tomcat in your case) will - or at least should - take care of the temporary files.
Along with InputStream.close(), use Part.delete() to remove the stored temporary file under work directory. Please refer the javadoc: Part.delete().
I agree with Jozef Chocholacek answer, simple solution CLOSE the input.
We were using MultiPart messages with files upload.
Since we were not closing the inputStream the files were stored there for a loooong time. They were deleted only on server restart.
After slightly changing the implementation with always closing the input part at the end.
Use try-> catch-> finally and put closing in finally part which will be
called always even when the call of method fails.
The server is not storing .tmp files anymore.
Related
Can someone please help explain to me the differences between the two? The URL instance seems simple enough to me, but I am having trouble doing the same thing with a local file.
When accessing a file directly, chrome is repsonsible for accessing the file on disk and rendering it. When using a server, the server reads the file from disk and sends it over http, and then chrome renders it.
You may need to make sure you allow Chrome access to the local files. Add the --allow-file-access-from-files switch to your shortcut that starts chrome.
Otherwise, you will get errors when your HTML file tries to access other resources on disk.
See http://www.chrome-allow-file-access-from-file.com/
Update
For Firefox, you want to go to:
about:config
And change the flag for security.fileuri.strict_origin_policy to FALSE.
You should run HTTP server on your machine and make calls to http://localhost/
I am trying to upload a file, My front end application is in PHP and backend engine is in Java. They both communicate through PHP-Java_bridge.
My first action was, when a file is posted to PHP page, it will retrieve its content.
$filedata= file_get_contents($tmpUploadedLocation);
and then pass this information to Java EJB façade which accepts byte array saveFileContents(byte[] contents)
Here is how in PHP I converted the $filedata into byte array.
$bytearrayData = unpack("C*",$filedata);
and finally called the Java service (Java service object was retrieved using php-java-bridge)
$javaService->saveFileContents($bytearrayData);
This works fine if file size is less, but if the size increase 2.9 MB, I receive an error and hence file contents are not saved on to the disk.
Fatal error: Allowed memory size of 134217728 bytes exhausted //This is PHP side error due to unpack
I am not sure how to do this, Above method is not accurate, Please I have few limits.
The engine(Java) is responsible for saving and retrieving the
contents.
PHP-HTML is the front end application, It could be any thing for now its just PHP
PHP communicate with Java using PHP-Java-Bridge
EJB's methods are accessed by PHP for saving and retrieving information.
Everything was working fine with above combination, but now its about upload and saving documents. It is EJB (Application Engine access point) that will be used for any front-end application (PHP or another java application through remote interface (lookups)).
My question is how File contents from PHP can be sent to Java, where it does not break any thing (Memory)?
Instead of converting a file into an array I'd try to pass it as string. Encode the string into base64 in PHP and decode it into array in Java.
Another option is to pass the file thru the filesystem. Some Linux systems have /dev/shm or /run/shm mounted to a tmpfs, which is often a good way to pass temporary data between programs without incurring a hard-drive overhead. A typical tmpfs algorithm is 1) create a folder; 2) remove old files from it (e.g. files older than a minute); 3) save the new file; 4) pass the file path to Java; 5) remove the file. Step 2 is important in order not to waste RAM if steps 3-5 are not completed for some reason.
We develop an application which uploads some CSV file.
In order to be sure about our code, the upload has been tested with 2 differents framework : ZK (which manages upload itself) and with classic jsp/Spring REST.
On our local server (windows, tomcat 5.5) all is ok.
On client system (Unix Solaris 10, tomcat 5.5) we have a pb : the first time the file is correctly uploaded, the second time if we change something in data (even if we delete the file) we have the same file as first upload....
It seems a cache or something else disturb the upload.
Any idea ?
Thank you.
[Edit] Additional information
For information, we are on Citrix Metaframe Program Neighborhood (a old version -> v9.0).
For those present at the customer (with or without Citrix), CSV file are uploaded correctly each time.
For us, who are outside, that's not working.
File A is uploaded, then we modified it (A') then uploaded again...and the result is : file A is deleted (as expected, by programmation) then a new file appear which is the same as A (not A' as expected).
If we stop Tomcat or even make others http request, the upload works correctly.
We test upload with 2 differents framework : ZK (which manage the upload itself) and Spring MVC (REST). Both are working on our servers with same Tomcat (5.5).
Other thing strange, we have access to an another server (by VPN not Citrix) where we deployed the application on a Tomcat 7 (already installed by the client). All is OK.
Is it possible that is an hardware problem? with a router...
First of all, it is very difficult to understand your question. With what I understood, you are not able to load any file the second time as the details of the first file are still present in memory/variables. Post your code so that it will be easy.
Try these
Start the application, load a file, say A.csv, first time, then stop
the application
Start the application again, and load another file B.csv and see if it is loaded correctly.
If steps 1 and 2 work correctly, you can be sure that no one has hard-coded anything in the code.
Now, go through your code and see if you have any static variables, being set with the contents of the file.
If removing static variables doesn't work, try printing all the variables and narrow down the issue.
Good luck!
I have a servlet that does the following:
User calls the servlet
Servlet code calls a web service to download a PDF file from an Adobe Live Cycle server.
Saves that PDF to a temp file.
Calls ps2pdf14 to convert that PDF to an ancient PDF 1.4 version (which creates a second temporary file)
Returns the contents of file2 as the response
What is the best way to cleanup these files?
Batch process?
Any ideas?
Few options-
Delete the files as soon as you send the response
Run a background (housekeeping) job (some daemon thread) that would periodically delete such temp files
Do not write anything to the disk, perform the conversion operation in the memory and return the modified contents to the user directly (not sure if this is feasible)
When using a form that uploads a file to my Play! Framework application, a file is created in ${application_path}/tmp/ with an unique ID like :
0851e44f-8d7e-4afd-8edf-3d9bd6c909c9
and contains all the data sended by the form (POST & FILES)
I located the creation of this file in :
play.server.StreamChunkAggregator.java:51
But I don't know why this file is not removed when the request is finished.
Is there any reason that the file isn't removed? is it specific to Play (1.2)?
The file should be removed automatically at the end of the request, so something unusual must be going wrong.
Isn't it the classical way of Server API to manage upload files?
Why they are not deleted ? I don't know but I see the same kind of behavior in Tomcat...