Tuesday, October 1, 2013

Delete for files-based interprocess communiction

There are recommendations to monitor until file appears and then read it. For instance, here is java monitor official example that says that as soon as file has created, lets look into its contents (Files.probeContentType), Howerver, I do not think that this is reliable approach since file must be filled with data and closed before you can open and read it. If you eager to read as soon as file is created, I suppose there is a ricing condition and danger that you read the file before it is written and closed completely. So, you read a partial file and everything sucks.

I do not understand why authoritive sources recommend this. However, producer can create or remove another file to signal that your primary file is complete and ready to be consumed. This is what I do (and second file is useful for bi-directional communication, to send data from consumer to producer).

Server starts off by creating a dummy file toclient. with some initial, might be empty data.  Client, when needs to communicate, creates its toserver file and removes toclient. This signals to server that client has consumed the data from server and there is some data from client. Server, when ready processing it, creates the toclient file at first and removes the toserver. The latter signals client that server has consumed the data and there is some data for client. Now, it is client's turn to communicate.

I find in useful in windows batch environment where you have no pipes (see why Linux is better).

No comments: