I have to read file on the Knime server. For various reasons, I have to read them in a shared folder and not through the workflows group.
To ease my developments, I tried to put in place a system in which the path of the file will depend on my env : local or server.
I tested 2 systems:
1- I use an input String “local” or “Server” and then I select the path depending on the input value (see KNIME_project)
2- I use the “Extract System Props” node and then in the same way i select the right path (see KNIME_project 1)
If I use a SDfile (with an SDF Reader node) all is working correctly in local or on the server.
BUT if I try to read a csv file (with the CSV Reader node), this is working correctly in local, but only the first solution is working on the server. With the second workflow I obtain the following error in the CSV Reader node:
It seems that the path is not correctly updated in this case. Can you suggest me where the error can come from?
Thanks in advance,
1- KNIME_project.knwf (20.6 KB)
2- KNIME_project 1.knwf (18.1 KB)
Adding Note: I tested the wf through the webportal, but I had the same kind of errors through the REST API on others wf
this is not a very stable approach. For example for my MacBook it says “server”, because it is not Windows. Anyways, if only you use the workflow, it should be fine. What is the output of the Rule Engine on the server? The problem shown in your screenshot is that the Java Edit Variable still outputs the Windows path and since Linux has completely different path name standards, it interprets it as a file relative to the KNIME executor. This is why it appends the “C:/tibco/iris.txt” to “/srv/…”. Can you make sure the Rule engine actually outputs “server” on the server?
Yes I understand that my rule engine work only in windows client vs Linux server. It could be made more general but it was not my goal here.
Yes the “env” variable is “server” in the second case when the workflow is executed through th webportal
And the Java Edit Variable contain the same code in both workflows.
I tried to reproduce the problem but on my server the correct path is used. What’s the value coming out of the Java Edit Variable? Is it the correct path or the wrong one?
The output of the Java Edit Variable is the good one. And it seems that in the CSV Reader the good one is put in place.
Hmm, I can for the life of me not reproduce this or understand why the CSV Reader should fail. Which version of KNIME is your executor on the server?
Have you tried to recreate the failing workflow (or a minimal example) on the Linux server from scratch? Sometimes I have seen KNIME ‘remember’ variable settings that should have been reset.
Currently I am working on a Knime Server 4.9.2.
Thanks to @mlauber71, I tested to export the wf, and reimport it in the Knime client on the server:
=> I found that the “variable Settings” that I had in the CSV Reader (Use Variable as path for the CSV file) was no more activated. So of course it was not using the variable path anymore to found the right file.
From the Knime client on the server I upload the wf on the Knime server, and now the wf is working through the webportal.
I think that maybe the problem come from that my local Knime client is on an higher version than the Knime server. However, I don’t understand why this problem appears with one wf and not the other.
now, even if I download again the wf locally, save it locally and upload it durectly to the Knime server, it works! No problem anymore. Very strange
this could be because we made some changes to some of the KNIME Analytics Platform’s nodes, e.g. the CSV Reader, but not the SDF Reader. If you have a newer version of KNIME locally than on the server, you will execute the new version of the node locally but the server will load the old version, which can lead to problems. The KNIME Server can also be configured to decline any workflows built with a newer version than the executor’s.
I have seen some strange behaviour of KNIME workflows that some ‘ghost’ information somehow seems to be still stored with a node even if you reset it.
I have not yet found a pattern I could reproduce to properly track it. It would be an appeal to the developers to double check the effects of resets and the storage of informations.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.