So here's my answers: 1.) Simply don't use the app/gui server, like I do for vizreader.com, there I use cookies (see cookie in http.l).
2.) Alex's #2 answer is a good one. 3.) See vizreader.com which has been running without any PL related hiccups for quite some time now and I must say the DB performance is marvelous. On Tue, Jul 19, 2011 at 2:25 PM, Alexander Burger <a...@software-lab.de>wrote: > 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:picolisp@software-lab.de?subject=Unsubscribe >
