Question

FME Server 2022.2 - problem updating upload files

  • 18 October 2023
  • 2 replies
  • 32 views

Badge +5

Hello,

We have updated FME Server from 2020 to 2022.2. Then there is something wrong with the upload files :

  • We publish into FMEServer a workbench containing a "File/URL" User parameter
  • Then we RUN the workspace 2 times : The file we upload has the same name, but the content of these 2 files is different

--> FME Server doesn't update the file located here : FME Server\\SystemShare\\resources\\system\\temp\\upload\\ if we don't purge the folder (In case we change the file name, it works well.)

We have not encountered this problem with FME 2020.2

 

Can anyone help?

Thank you

Ronan


2 replies

Badge +5

Hello,

This could be a 2022.2.4 bug where there was an issue with Data Upload Service when a file of the same name was uploaded using the Web UI on the Job Submitter page. The upload service when running a workspace, had a source dataset parameter[ In that case, the file format was .csv] .

This issue occurs when the user uploads a file of the same name. A .tmp file is created in the /Resouces/system/temp/upload when the user uploads the file, indicating the file is uploaded correctly. However, the temp folder <repository>/<workspace> which is created to hold the temp upload does not clean up and can’t be replaced when a new file is uploaded. This has been fixed in 2023.0

and 2023.1. The workaround for this issue is to run a temp cleanup system event to get rid of the old file.

How is this job running on FME Server- via automation, workspace app or manually on run workspace page ?

 

If this is not helpful, would you be able to create a case with the following information-

  • Job logs for the two job runs
  • The workspace file
Badge +5

Hello,

This could be a 2022.2.4 bug where there was an issue with Data Upload Service when a file of the same name was uploaded using the Web UI on the Job Submitter page. The upload service when running a workspace, had a source dataset parameter[ In that case, the file format was .csv] .

This issue occurs when the user uploads a file of the same name. A .tmp file is created in the /Resouces/system/temp/upload when the user uploads the file, indicating the file is uploaded correctly. However, the temp folder <repository>/<workspace> which is created to hold the temp upload does not clean up and can’t be replaced when a new file is uploaded. This has been fixed in 2023.0

and 2023.1. The workaround for this issue is to run a temp cleanup system event to get rid of the old file.

How is this job running on FME Server- via automation, workspace app or manually on run workspace page ?

 

If this is not helpful, would you be able to create a case with the following information-

  • Job logs for the two job runs
  • The workspace file

Hello,

 

Thanks a lot for your answer.

The bug you describe is exactly what happen. I have checked directly in the folder /Resouces/system/temp/upload and the file doesn't update when the user uploads a file with the same name. I encountered the problem with 2 completely different workspaces.

In each case, we use a workspace app.

- I understand that the solution you suggest is to use a temp cleanup system event to get rid of the old files/subfolder of this folder : \\FME Server\\SystemShare\\resources\\system\\temp\\upload : Do you mean the solution would be to increase the frequency of : System configuration --> system cleanup --> Delete_dataUpload_File task? Couldn't there be a side effect if the cleaning process is carried out while another job is running?

- Sometimes, the users perform the same workspace twice at 3 minutes intervals. The upload file name is the same, the content is different : using the schedule to launch a cleaning process does not seem to be a perfect solution, it would then be necessary to run the process every 2 minutes to prevent the bug? Are maybe can we perform the process after a trigger? Is there a trigger like: after such worskpace is finished?

- Is it possible to directly apply a patch to the FME server 2022.2 installed in our environment to resolve the problem at the roots?

 

 

 

 

 

Reply