Hi Damir, welcome! :)
In addition to what Tomas wrote: > 1. App changes port number for each session Right, that's a central feature of the application server. The reasons for that are - Each user session is handled by a separate child process, to hold the state and history of the GUI, per-session user state, cached database objects and transactions. - Each connected client must know how to access its private process. This is done by each child allocating its own TCP port, and listening at that port. In that way we have a clear isolation between the processes and sessions, and it works stand-alone (without separate instances like 'nginx' or 'httpGate') for minimal setups. - For a production setup, a single-port access is better of course (mainly for security/firewall reasons). We use exclusively 'httpGate' for that. The advantages of httpGate are that it is very simple, and - the initial reason to write it - that it can handle SSL en/decryption. It does a simple rewrite of the URL, basically changing url/port to url:port. I'm convinced that this is the optimal way. If you'd use a cookie solution instead, you would have to implement the identical logic twice, once in the proxy, and once in the app (for stand-alone usage). > how can PicoLisp app be served to the wild of Internet, being > accessed via port 80? With 'httpGate' or some other proxy like Tomas' ngix solution. You can see usages of 'httpGate' in some examples and demo apps "in the wild", like http://app.7fach.de http://sushi.7fach.de http://rcsim.7fach.de http://home.picolisp.com http://wiki.picolisp.com > 2. Backup > With mysql (or any other) I do mysqdump and I'm done. Zipped .sql > files are rsynced to remote locations for greater security. > > How is backing up PicoLisp databases done in production? We are using three methods: 1. Once per night a cron job runs. 12 1 * * * ./pil lib/http.l -'client "localhost" 16000 (pack "messe/back.l?*PW=" (pw))' -bye The "messe/back.l" does the following: It connects to the server, forks a child process which then: - Stops possibly remaining sessions: (tell 'bye 2) - Locks the database (when (lock) (quit "Can't lock DB" @) ) - Does some integrity check (for (F . @) *Dbs (when (dbck F) (quit "DB Check" (cons F @)) ) ) - Creates backups (call "sh" "-c" "tar cfz messe$(date +%a).tgz db/messe/ blob/messe/") - and does a DB garbage collection (when (dbgc) (println 'dbgc @) ) Normally, the "back.l" scripts also do lots of other things, like sending mails and cleaning up other stuff. Another cronjob then saves the created *.tgz backups to some other medium. 2. In most production apps, we do a "permanent" backup, i.e. a mirroring of the database to some other, remote server. This can be done the following way: - The application's database is opened in journal mode (pool "db/messe/" *Dbs (setq *Jnl (and (info "key/messe") "fifo/messe")) ) This causes all changes to the db being written to a file "fifo/messe". - a separate 'ssl' process is started bin/ssl <remote-IP> 443 '40003/!replica' key/messe fifo/messe blob/messe/ 20 This process checks "fifo/messe" every 20 seconds, and sends it (using atomic transactions) to the remote machine. - On the remote machine, a 'replica' process is runnning bin/replica 40003 key/messe "" rpl/db/messe/ rpl/blob/messe/ 4 1 1 1 1 2 3 4 4 4 4 5 5 5 6 3 4 4 4 3 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 0 6 4 & which then maintains an exact copy of the original database. We have a single server mirroring all customer's databases, and which in turn is also backed up regularly. 'ssl' and 'replica' are part of the distribution. 3. Then, of course, there is the "normal" backup, saving the whole working directory (most importantly the database and blobs). > and 3. Is it ready for production use? > Are there any production grade apps running PicoLisp? What are > common setups and known issues beginner should expect? We (at "software-lab" and "7fach GmbH") use it exclusively since the mid-1990s. It was a constant evolution, always implementing only what was absolutely necessary for the practical problems at hand. There are more details involved than what I described above, but I hope it helps a little. Please ask any time! Cheers, - Alex -- UNSUBSCRIBE: mailto:[email protected]?subject=Unsubscribe
