0

I am having an application in which there is a dumper action which continuously retrieves an xml stream from a web service parse it and then dumps it into a mysql DB.

Right now i am doing all the dumping action in the UI and its a real pain to both dump the data and manipulate it.

So i made a separate CLI script which will take care of the dumping action and the front end can just poll the DB every second to see if it has new data which would be a much more trivial way of doing it. But the only problem now is that i am not able to control the cli script from the web UI.

That is i want to be able to start the dumping action and stop it from the UI. I tried this method that ive seen somewhere before

while(true) {
if(file_exist($file)) {
//do action 
} else { 
break;
}
}

so ill delete the file on stop action from the frontend and there are variable problems with this method and all this doesnt seem like the correct way of doing it. So is there a better way to control Command line scripts from the Web page UI.

swordfish
  • 4,899
  • 5
  • 33
  • 61

3 Answers3

1

Since the script already has database access, why don't you create a control table for the CLI script, containing the actions it should perform? You the pull the record from the table every time the script loops.

You'd be able to fix it with one row (maybe you already got a settings table which you could (ab)use), containing a single command. If it's a 1 or "run" or true or whatever you like, your script continues, otherwise it stops.

Then, from the Web UI you can "send" the commands, which will be stored in the specified table.

CodeCaster
  • 147,647
  • 23
  • 218
  • 272
0

as long as you don't want to use kill http://linux.about.com/library/cmd/blcmdl_kill.htm to brutally kill or send a message to the running script, most methods will use a similar way to send data.

You may use a special db record or table to send/receive commands and messages between scripts, or a special file in your filesystem, or shared memory...etc. They all involve an asynchronous message passing method. You may be better designing your script to consume as little resources as possible so you dont actually have to ever kill it.

The method you're using(with the file) is actually pretty simple and robust, but its sending messages only one-way and only 1 type of message.

Quamis
  • 10,924
  • 12
  • 50
  • 66
0

Using exec is a an easy way to 'control' you CLI script however it is a security risk and I wouldn't recommend it if you scripts are not on an internal server. Instead what I recommend you to create a kind of daemon script(I recommend this but it might be a little tougher to implement) or run your CLI script through cron periodically(scheduled tasks on window). Maybe once every 3 minutes. The web UI and the CLI script 'talk' to each other using the DB. Eg. The web UI posts the data which the CLI script has to process, the CLI script posts when it is done. There can be concurrency issues with this approach but that really wouldn't be a problem if the application is not huge i.e. thousands of queries/sec.

Ravi
  • 727
  • 6
  • 19