Handling multiple things happening at the same time
Matt Davies
Asit Dhal
Hi Matt,
You should run the cronjob in a separate process and the FileServer in another process.
mux := http.NewServeMux()
fs := http.FileServer(http.Dir("fileserver"))
mux.Handle("/", fs)
http.ListenAndServe(":8080", mux)
The FileServer package provided by the standard library will be
good(and small). In this way, you just separate the responsibility
between two processes.
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
-- Warm Regards, Asit Dhal http://asit-dhal.github.io/
Caleb Doxsey
Simon Ritchie
I did similar things during a project I worked on a couple of years ago, but not using Go. That solution uses a Java web server to display data which is fetched using an off-the shelf FTP server driven by cron scripts running TCL programs. We authenticated the FTP connection using passwords and I recall that one of the challenges was to protect the password from exposure. You could probably cobble together a prototype file fetcher more quickly using a solution like that, but it would be easier to make a Go solution secure.
For maximum security, use certificate authentication rather than passwords, but that involves passing certificates around, which can delay getting the thing up and running, especially if there are lots of organisations providing the files.
Simon Ritchie
It sounds like this just moves the problem to the parent script, but actually that doesn't do very much, so it's much easier to make it (almost) never crash.
The problem then is to make the server stop when you need it to. That's achieved by making the parent script a signal catcher. One signal makes it kill its child and then stop. Another makes the child reread its configuration files and reconfigure itself. You have another script that sends the signals - the stop script. You include a call to this in the stuff that is run when the machine shuts down, so the web server is shut down tidily.
To get all that to hang together, the first parent script records its PID in a file when it starts. The stop script reads the PID from the file.
You could do worse than downloading Apache and stealing the startup and shutdown scripts. They've been in use for twenty years or more, so they are now fairly robust.
Caleb Doxsey
Asit Dhal
Hi,
Don't you think it will be over engineering.
Like Simon said, Apache can be used as a file transfer app(it has logging, loading, restarting).
Probably, his small app is an extension of some bigger go app.
His small app can use two different processes which runs under
two different user(you got system level isolation and North Korean
hackers are no more allowed to read unformulated files).
File server app usually never fails. Cron App usually fails, but
logs the error and works for the next cron job. Gocron doesn't
seem to have elegant error handling mechanism. The developer needs
to handle them somehow. Gocron will proudly fail if one
tasks fails to do error handling.
1. CronApp runs under "cron_user". On success, file permission changes to allow read to "Ftp_user".
2. Ftp_User simply sees a new file and displays them(delivers).
For a better file server, this one
https://github.com/codeskyblue/gohttpserver
As both of these processes have clearly different responsibility,
they don't need to be aware of each other.
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.