Ignition Perspective HttpGet Locking File

Ignition
,
1

Hello,

I am trying to read a text file from the Gateway server and then parse that text file to then dynamic set some image path that are also located on the server.

Currently I'm using system.net.httpGet where the URL is the path to the txt file on the server. I can get the file fine. The issue is that it seems like Ignition locks the file and nothing else can access it until the gateway service is restarted. The issue being that this text file is constantly being updated with image paths. So once it locked, it can't be updated with new image paths from another service.

Is there a better way to access the file or is there a way to free or close the connection from the script? I only need to open the txt file and read it briefly.

Thanks,

Brad

2

Use WebDev to serve the file. Using the Jetty folder as a poor substitute isn't really supported, partly because of this intractable problem.

If you don't have the WebDev module, and you can use a DB, you might find my free Blob Server module helpful.

1 Like
3

Thanks for the feedback! Yeah we don't have the WebDev module, we might need to look into getting that, I was reading into it before and it would be helpful in other applications as well.

I was afraid that was the answer but I was also preparing for the DB option, was just hoping since my solution was 99% of the way there, there might be a easy way around the file being lock by ignition when HttpGet is called.

4

Can I just ask why HttpGet works that way? Why would it lock down the whole file until the Gateway Ignition Service is restarted?

I know its not typically used for files on the server but is it expecting a response to close the connection and free up the file?

5

It isn't httpGet that is doing the locking. It is the Jetty webserver. That folder is its configuration folder, and the contents are expected to be static--that is, cacheable. That you can put arbitrary files there and retrieve them via HTTP is an "accidental" feature. Allowing them to be dynamically changed would turn that accidental feature into a security hole.

It won't be "fixed" the way you want.

6

Got it, thank you for the explanation!