I am cropping a file with the Image Processor which is then stored in the tmpimages directory. According to Mark’s advice I copy it to another directory to rename it and do other things with it. Sometimes the copy does not work and the above error is thrown. As a workaround I added timers (up to two seconds) to give the process more time to store the file. Sometimes it works, sometimes not. Even with the same input file. So, the error is not systematic, not a problem with the logic as such. I added a routine (repeat while) that checks if the directory listing contains the expected file. And, even if the listing confirms the existence of the file the file copy routine sometimes throws an error.
Result of the crop command:
Result of the directory listing for this file pattern:
The copy request (exactly the same structure as all other copy commands before):
As I see, your app is placed in EU zone.
Provide the app id and the steps (one by one) which will lead to the error. It would be really helpful if we are are able to reproduce the problem in your app.
AppId: A2090C1B-936C-A876-FF32-277A55A60700
As said, it is not systematic and happens not at the same step with the same picture.
Use the Page testImageProcessor and press the Upload File Button. Select a picture with at least width and height of 300 px. You can find the Logic in On Upload Success. The Console Log shows you the you the long URL of the cropped piece and the entry in the directory listing of this particular file.
Wait for the error and switch to the Network Tab in Chrome.
I’ve tried to play directly with the image processor service. It works fine.
I didn’t find any error in logs. Could it be the problem is within the page logic?
We already have the internal ticket BKNDLSS-29511 (Sticky sessions in Backendless). After it is done your issue should be fixed automatically. I’ve attached a link of this topic to the ticket, so we’ll notify you as soon as it is done.
Jörg Beyer, why did you perform listing?
It’s quite heavy operation and in a architecture with several servers (and we have this) it doesn’t matter much, because the next api call can pass through different machine.
The Upload Success Event already says that the operation is completed and the file have to be on it’s place.
With our recent changes you do not need to do listing operation after file copy since all requests to the file system from one handler/client will go to the same server.
I would love to give you a positive feedback, but here on my end I need to perform this wait routine. Otherwise it is still not reliable. This workaround is fine by me. No further changes necessary.
I see what the problem is. We plan to make some architectural changes in the future, which will either completely remove, or at least significantly reduce the lag between file system synchronization. So far, that’s the only way, unfortunately. We’ll let you know when these changes are ready.
Would like to know if this issue has been worked on or solved ?
Indeed, I am encountering a very similar-sounding issue. Getting hold of the file after resizing / rotating via the image processor is hit and miss. I find it very unstable and can’t reliably get hold of the file coming out of the ImageProcessor in order to rename it and move it to the right place.
If I may suggest two options in the ImageProcessor functions :
specifying the final path and filename of the output file, instead of having to get it from the temp folder
being able to directly replace the input file in place
for what it is worth - this is my workaround. After the copy/save request I wait until the file transaction is finished. It works fine and is a stable solution.
