When I am trying to process a file in Camel and it fails I try to move the file to an error directory but get the following error message:
org.apache.camel.component.file.GenericFileOperationFailedException: Cannot delete file:....
I don't know if Windows is locking the file, but I have closed any streams that may cause this to occur on my side. If this is Windows what could I do to release this lock?
The route is a simple from()... process().. to() and there are some headers set after the process() It is the to() where this fails and the file does not move into the error directory as expected.
Thanks.
Maybe it has something to do with this:
Cannot move/delete file after processing on Windows
There is a potential issue on Windows platform with Camel 1.5.x. That
it cannot move or delete the file after processing. You should get an
exception thrown.
The workaround is to convert the body to a String after consuming
using convertBodyTo: eg
from("file://inbox").convertBodyTo(String.class).to("file://outbox");.
There should be a fix in Camel 1.6.0 to remedy this, but we would like
to get feedback on this issue. So if you are on Windows please give it
a go.
It seems there was a rogue stream that needed changing. I found this out using Process Explorer as it identified the same file twice. One lock was removed and another was not and from this I found an open stream that wasn't handled in the catch block.
Related
Using javamail i am reading all the messages from inbox folder and use to pass the message object to executor one by one,. Executor use to read email body using get content and use to categorize it and after categorizing it I use to move it to specific folder and use to delete it from inbox folder.
But in this process I am facing issue In get content method, it is returning me body of different mail. Seems like state sharing issue in multithreading environment in Java API.
Can someone suggest me what can be the possible issue.
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.
I'm trying to remove a file after a broken upload using
final FileService fileService = FileServiceFactory.getFileService();
fileService.delete(file);
But I get:
java.lang.UnsupportedOperationException: File \/blobstore\/writable:AD8BvukH[...]qau-Bb7AD does not have a finalized name
When I try to finalize the file with
FileWriteChannel writeChannel = fileService.openWriteChannel(file, true);
writeChannel.closeFinally();
then openWriteChannel() fails with
com.google.appengine.api.files.FinalizationException
[...]
Caused by: com.google.apphosting.api.ApiProxy$ApplicationException: ApplicationError: 101:
What does ApplicationError 101 mean?
How can I properly delete the file?
It looks like others have reported this problem and, although it was addressed, there could still be a problem with broken files.
Sep 11, 2013 at 1:14 am
We have now fixed this issue from reoccurring in future. However,
there are some blobs created in the past that still give errors. We
are working on a fix for these blobs.
John Lowry On behalf of the App Engine team
http://grokbase.com/t/gg/google-appengine/138xrawqw0/broken-blobstore-files-what-to-do
UnsupportedOperationException
For the first error, the documentation states:
java.lang.UnsupportedOperationException - if a file's type is not supported by delete or file does not have a finalized name.
It could be that the file is already finalized, and you can't delete it for some other reason.
ApplicationError: 101
I think the second error refers to a not found exception.
FinalizationError: ApplicationError: 101 Blobkey not found.
This may clarify the issue for you.
You only use finalize if you create a file and write to it. But you
cannot write to a file, after it has been finalized. To update a file
in the blobstore, you always have to create a new one. And when you
read a file, you do not have to finalize it. To read a file you have
to use a blobreader. See:
https://developers.google.com/appengine/docs/python/blobstore/blobreaderclass
via https://stackoverflow.com/a/12855653/1085891
Fixing the Broken Upload
You could resume the upload.
If the transfer is interrupted, you can resume the transfer from where it left off using the --db_filename=... argument.
via How to finish a broken data upload to the production Google App Engine server?
Additional Solutions / Information:
Cannot delete entity with broken id from datastore
Handle Form Failure when uploading to Appengine Blobstore
Issue 4744: Java dev server fails at deleting blobs.
I have an issue with the following piece of java code running in Lotus Domino.
File filData = new File(domSapFilePath + "\\DOMSAP" + sdfDateTime.format((Calendar.getInstance()).getTime()) + ".csv");
FileOutputStream foData = new FileOutputStream(filData);
foData.write(DomSapGenerator.GenerateDomSapFile(con, dateFrom, dateTo).getBytes());
foData.close();
con.close();
The created file is in a UNC path but when it tries to write the file, it errors out saying that the file is in use by another process as can be seen below:
error message: java.io.FileNotFoundException: \\10.XX.XX.XX\xxxxxx\XXX\DOXXXXXX22230.csv (The process cannot access the file because it is being used by another process)
I've never programmed in Java before and I was hoping someone could point me in the right direction for a solution for this problem which is happening intermittently.
Thank you.
The most likely cause of this problem is that something else has the file open and is using it. The operating system is preventing you writing to the file because that could interfere with whatever it is that the "something else" is doing.
It is presumably happening intermittently because the "something else" is only using the file occasionally.
The solution is to figure out:
what is using the file,
why it is locking it, and
how to coordinate the different activities on the file to avoid the conflict.
As you are trying to open a UNC path, another cause for this error message could be that the code is running inside a scheduled agent.
In that case, the connection to the server \10.XX.XX.XX\ would be opened in the context of the OS account, that Domino is running under - usually "SYSTEM". As the "SYSTEM" user is not allowed to make a network connection to another server, the open call will fail.
Solution: Run the Domino service as another (AD) user that has the right to make network connections.
You didn't say what operating system, but I am going to take a guess at windows based on the UNC format.
Microsoft have a program called Process Monitor. You can use this to track what is touching the file.
http://technet.microsoft.com/en-us/sysinternals/bb896645
But I would also go with leyrers response first.
I'm trying to write a Java EE application that records sound from the input on the server.
My code works fine when debuging, and running on the server as myself (both ubuntu) however when it's running from the web sever I get an exception:
javax.sound.sampled.LineUnavailableException
at org.classpath.icedtea.pulseaudio.PulseAudioMixer.openImpl(PulseAudioMixer.java:714)
at org.classpath.icedtea.pulseaudio.PulseAudioMixer.openLocal(PulseAudioMixer.java:588)
at org.classpath.icedtea.pulseaudio.PulseAudioMixer.openLocal(PulseAudioMixer.java:584)
at org.classpath.icedtea.pulseaudio.PulseAudioMixer.open(PulseAudioMixer.java:579)
at org.classpath.icedtea.pulseaudio.PulseAudioDataLine.open(PulseAudioDataLine.java:95)
at org.classpath.icedtea.pulseaudio.PulseAudioTargetDataLine.open(PulseAudioTargetDataLine.java:111)
at org.classpath.icedtea.pulseaudio.PulseAudioTargetDataLine.open(PulseAudioTargetDataLine.java:130)
I've tried to add the tomcat user to the audio group (which some documentation suggested) but it's still throwing the exception. I think the only difference must be the environment, but I'm at a loss for where the problem might be.
I'm assuming that you've got the appropriate JARs in the CLASSPATH - either in your application WEB-INF/lib or in the Tomcat /lib.
The fact that you're trying to open something suggests that maybe you have a path problem. Web apps can't depend on an absolute file path, because they can't know where a WAR file will be installed. So it's better to use a relative path and get resources as streams. Perhaps there's a way to do it with this library.
I've managed to get this working now - but thank for the help.
In the end it was a OS level issue, under ubuntu only users in the audio group can access sound resources when not logged in (https://wiki.ubuntu.com/Audio/TheAudioGroup) and to connect to pulse audio it looks like you need X11 auth of some kind. After those changes it require a restart so tomcat could grab the sound device before anything else did.