09-18-2020 06:58 AM - edited 09-18-2020 07:30 AM
After upgrading the Server to 2020 R3, the clients continuously gets error -251611 when uploading a file. The message is
NI Skyline Writable File.lvclass:Send Last Packet (custom).vi:6300001<ERR>
Error opening file: 'D:\SystemLink Fileupload\FileIngestion\blabla\something.tdms'.
The transferred file has the expected number of bytes and does not seem to have any defects.
What could cause this error? Can I ignore this it if I query the file properties after upload? Smaller files (logs) are transferred without error.
09-18-2020 08:22 AM
I looked at C:\ProgramData\National Instruments\Skyline\Logs\ and there are rapidly growing log files that say something like this:
2020-09-18--15:00:00.10663 | FileIngestion | ERROR - Error opening file D:\SystemLink Fileupload\FileIngestion\5f6\4ae\1f0\04f\e62\5a4\dc8\5f64ae1f004fe625a4dc838a.tdms: Could not find a part of the path 'D:\SystemLink Fileupload\FileIngestion\5f6\4ae\1f0\04f\e62\5a4\dc8\5f64ae1f004fe625a4dc838a.tdms'.
2020-09-18--15:00:00.10663 | FileIngestion | ERROR - Error deleting file D:\SystemLink Fileupload\FileIngestion\5f6\4ae\1f0\04f\e62\5a4\dc8\5f64ae1f004fe625a4dc838a.tdms: Could not find a part of the path 'D:\SystemLink Fileupload\FileIngestion\5f6\4ae\1f0\04f\e62\5a4\dc8\5f64ae1f004fe625a4dc838a.tdms'.
2020-09-18--15:00:00.60764 | FileIngestion | ERROR - Error opening file D:\SystemLink Fileupload\FileIngestion\5f6\4ae\1f0\04f\e62\5a4\dc8\5f64ae1f004fe625a4dc838a.tdms: Could not find a part of the path 'D:\SystemLink Fileupload\FileIngestion\5f6\4ae\1f0\04f\e62\5a4\dc8\5f64ae1f004fe625a4dc838a.tdms'.
2020-09-18--15:00:00.60764 | FileIngestion | ERROR - Error deleting file D:\SystemLink Fileupload\FileIngestion\5f6\4ae\1f0\04f\e62\5a4\dc8\5f64ae1f004fe625a4dc838a.tdms: Could not find a part of the path 'D:\SystemLink Fileupload\FileIngestion\5f6\4ae\1f0\04f\e62\5a4\dc8\5f64ae1f004fe625a4dc838a.tdms'.
That message disappears after the file is finally at that path.
09-18-2020 03:22 PM
Hi cordm,
Thank you for bringing this to our attention. I created a simple VI that uploaded a file using the AMQP API and Last Packet and was unable to reproduce the error you are describing. Can you tell me more about the server? What version did you upgrade from? Was there file data on the system prior to the upgrade? Is the file ingestion service configured to store files on a network drive? What version of LabVIEW are you using to upload the file? Can you share any part of your program with us to assist in the reproduction?
09-21-2020 02:07 AM
- upgrade was from 19.6.3 to 2020 R3. System started out with 19.5
- yes, the server has been in use for a while
- the files are stored on a local disk
- LabVIEW 19.0.1f3
- not sure what would help, the upload part is basically a consumer loop that receives paths and calls Send File (AMQP) from the SystemLink File Transfer Palette (LabVIEW 2019\vi.lib\Skyline\File\File\Send File.vi)
I did a repair install because some services were not coming up. The folder for FileIngestion was reset to default, so I suppose some other things were also reset. I will try removing and adding the systems back to the server.
09-22-2020 07:07 AM
This problem is not due to the repair installation. We created another server from a snapshot before the upgrade, installed 2020 R3 and experience the same issue with AMQP uploads. Switching over to HTTP uploads works around the issue, which is fine for me. I think we originally used AMQP because it was more reliable. Oh well.
09-22-2020 08:28 AM
Hi cordm,
Thank you for the additional details and your continued patience on this issue. We are looking into this problem, but I unfortunately cannot report and breakthroughs as of yet.
I would encourage you to continue to use HTTP as the data communication protocol instead of AMQP for files, as well as for other data services such as tags or test results. We've been slowly moving forward with deprecating AMQP. This happen happened yet, but we are currently encouraging everyone to use HTTP(S). HTTP has enabled us to provide better security guarantees than we can make with AMQP and also provides us with simpler better tools and architectures for horizontal scaling future version of SystemLink. Additionally, HTTP is required to be used when utilizing multiple workspaces.