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
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",
> 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
(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
(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
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
- The application's database is opened in journal mode
(setq *Jnl (and (info "key/messe") "fifo/messe")) )
This causes all changes to the db being written to a file
- a separate 'ssl' process is started
bin/ssl <remote-IP> 443 '40003/!replica' key/messe fifo/messe blob/messe/
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!