gmane.lisp.web

Re: The Common Lisp Directory finally crashed after 823 days.

Marc Battyani — 2008-03-15T22:19:03

I use my own webapp server with Apache and mod_lisp: .http://www.fractalconcept.com/ilc2002-marc-battyani.pdf Now it would be called an Ajax framework but I don"t even know if the acronym already existed in 2000/2002. Marc

Re: The Common Lisp Directory finally crashed after 823days.

Robert Synnott — 2008-03-15T20:19:06

On Sat, Mar 15, 2008 at 5:05 PM, Marc Battyani fractalconcept.com> wrote: Well done! A new record, I suspect. As a matter of interest, does it use one of the standard servers, or did you roll your own? Rob

Re: The Common Lisp Directory finally crashed after 823days.

Gary King — 2008-03-15T20:03:56

Wow! That's very cool Marc. -- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM

The Common Lisp Directory finally crashed after 823 days.

Marc Battyani — 2008-03-15T17:05:40

[Is this list still somewhat alive?] The Common Lisp Directory (http://www.cl-user.net) lisp process crashed yesterday after 823 days of continuous service. In these 2 years and 93 days, the same lisp process (LispWorks on Linux Debian) served 273M requests without any problem. Even the crash was not really lisp's fault as it was caused by a swap disk problem which caused the kernel to kill a lot of processes. During these 823 days, I had to restart Apache every few months and the firewall router every several days. I also got several electric power outages but fortunately none longer than the 3h of UPS battery time. BTW this shows than Debian is also a stable platform for this kind of applications. So the CLD lisp process uptime experiment is now over and I will move the CLD to a better place than a simple server in my basement. Marc

Re: serving very large files from allegroserve

Nick Levine — 2007-05-03T16:54:50

I see that webactions isn't handling the timeout argument I imagine that's how it came about. Ouch. (but then again webactions is mainly used to handle html files). Well, this one leaked in there somehow and then wouldn't leak out again. Sigh. -n

Re: serving very large files from allegroserve

John Foderaro — 2007-05-03T16:27:03

There are places where you can change the behavior of the directory entity but if you did none of that and just did a vanilla publish-directory then I'm not sure how the timeout could be nil. Perhaps you can see some pattern in the file entities that ended up with a nil timeout and that would offer a clue. I see that webactions isn't handling the timeout argument (but then again webactions is mainly used to handle html files). You can also set *http-response-timeout* to a large value so that even if the entity gets a nil timeout you can still have a large timeout.

Re: serving very large files from allegroserve

Nick Levine — 2007-05-03T14:33:51

Some considerable time later... I went looking in the appropriate locator-exact structure's info slot: a hash-table which as I understand it contains a file-entity for each file implicity published when serving something under a publish-directory. The file I'd been trying to download had timeout slot nil, another file in the same directory had timeout slot 8640000. So all I have to do is remhash the offending entry and hopefully when I go home this evening I can listen to the remains of this audio file. So, what I really want to know, now that I've wasted over two hours digging into this (and everyone on this list has had to listen to me doing it), is: where did I go wrong? All I ever did was publish a directory (with no :timeout arguments) and I got my fingers stepped on. What's the route whereby the server can create a file-entity without its inherited timeout? That's all from me. - n

Re: serving very large files from allegroserve

John Foderaro — 2007-05-03T12:13:56

acl8 should be using io timeouts. look for :io-timeout on the *features* list to be sure. You can't trace mp:with-timeout since it's a macro but you can trace a function used by the expansion of with-timeout: (trace excl::positive-wait) The value passed to positive-wait should not be 300 but some very large value (i.e. 100 days worth of seconds).

Re: serving very large files from allegroserve

Nick Levine — 2007-05-03T11:38:31

(publish-directory :timeout 23234 ...) and it's inherited by all files published or if that's not done the wserver object contains a timeout value that defaults to the value of *http-response-timeout* (300) if you're using io timeouts then the default for publish-directory is a timeout of 100 days which is then inherited by all the files published. Am I right in thinking that ACL8 <=> using IO timeouts? If you're still getting timeouts after 300 seconds for files reached via a publish-directory then that is a mystery. Isn't it just. Suggestions for verifying my claims and then debugging it? - nick

Re: serving very large files from allegroserve

John Foderaro — 2007-05-03T11:19:29

There are three ways to set the timeout for a particular response You can specify it in the response code: (with-http-response (req ent :timeout 1213123) ....) if that's not done you can specify the timeout in the entity creation. (publish-file :timeout 234234 ....) or (publish-directory :timeout 23234 ...) and it's inherited by all files published or if that's not done the wserver object contains a timeout value that defaults to the value of *http-response-timeout* (300) if you're using io timeouts then the default for publish-directory is a timeout of 100 days which is then inherited by all the files published. If you're still getting timeouts after 300 seconds for files reached via a publish-directory then that is a mystery.

Re: serving very large files from allegroserve

Nick Levine — 2007-05-03T11:07:12

Date: Thu, 3 May 2007 11:50:24 +0100 (BST) From: Nick Levine ravenbrook.com> Cc: lispweb< at >red-bean.com Precedence: list Content-Type: text/plain; charset="us-ascii" Sender: lispweb-bounces< at >red-bean.com So allegroserve offers a global timeout for the whole request (which defaults to 300 seconds if you're also doing timeout on each I/O). If you know you'll be sending things that could take a long long time then feel free to change the 300 to a huge value. You're still protected by the timeout on I/O which will ensure that some progress gets made ever N seconds (default 120). Ah, well I'm not sure that was clear from the doc but thanks for the tip, I guess I need to do a separate publish on the audio files. OK I give up. Where is this set? For instance, I publish the root for ilc07.org via (publish-directory :host *ilc-vhost-names* :prefix "/" :destination "/home/alu/ilc/www/) which gives me a DIRECTORY-ENTITY. I inspect that and its timeout slot has value 8640000. Comforting in that it corresponds to what my copy of source said would happen. But it doesn't explain where the 300 is that I want to overwrite. - nick

Re: serving very large files from allegroserve

Nick Levine — 2007-05-03T10:50:24

So allegroserve offers a global timeout for the whole request (which defaults to 300 seconds if you're also doing timeout on each I/O). If you know you'll be sending things that could take a long long time then feel free to change the 300 to a huge value. You're still protected by the timeout on I/O which will ensure that some progress gets made ever N seconds (default 120). Ah, well I'm not sure that was clear from the doc but thanks for the tip, I guess I need to do a separate publish on the audio files. Thanks, -n

Re: serving very large files from allegroserve

John Foderaro — 2007-05-03T10:42:07

I wouldn't call it a contradiction at all. Suppose you have some people trying to attack your web site by making requests and very very slowly reading the response. If you just let them do this then they can tie up a lot of server resources for a long time. So allegroserve offers a global timeout for the whole request (which defaults to 300 seconds if you're also doing timeout on each I/O). If you know you'll be sending things that could take a long long time then feel free to change the 300 to a huge value. You're still protected by the timeout on I/O which will ensure that some progress gets made ever N seconds (default 120). -john foderaro

serving very large files from allegroserve

Nick Levine — 2007-05-03T09:00:31

Testing downloads of large audio recordings from ilc2007, I find that the bytes stop flowing after five minutes. Allegroserve (version 1.2.43 on ACL 8.0) spits out a 500 return code and the transaction is over. I find in AServe doc the following: (wserver-response-timeout wserver) - the number of seconds AllegroServe allows for an http request function to be run and finished sending back its response. The initial value for this slot of the wserver object is found in *http-response-timeout* which defaults to 300 seconds. You can alter this timeout value with the :timeout argument to with-http-response or by specifying a :timeout argument to the publish function creating the entity. and I'm sure this is exactly what I've hit. The thought of just cranking this number up and hoping for the best makes me cringe a little. Surely there must be better? Well, the folks at Franz obviously thought so too, because a couple of paragraphs up they say: In Acl 6.1 we added the capability of having each I/O operation to a socket stream time out. This means that we don't have to predict how long it should take to get a request or send a response. As long as we're making progress reading or writing we know that the client on the other end of the network connection is alive and well. Fine words. But totally contradicted by having a response-timeout slot in the server. Does anyone have any experience with getting AServe to monitor whether it's "making progress reading" and so knows "that the client on the other end of the network connection is alive and well"? Thanks, - nick

Announcement: CL-WEBDAV

Edi Weitz — 2007-04-18T20:14:50

A WebDAV server based on Hunchentoot: http://weitz.de/cl-webdav/ Cheers, Edi.

web development with lisp

Patrick X — 2007-03-16T04:46:38

Hey this is Patrick, from Pippen Enterprises LLC. Our company is starting up a web development company, using Common Lisp of course :-) We wondering what tools do many lisp developers, use that support Versign SSL, and other technologies for commercial use.

Araneida: request-authorized-p (implementation of genericfunctionto yield authorization status)

Joubert Nel — 2007-03-06T03:53:50

Hi, I'm trying to create an authorization scheme in Araneida. Basically whenever a location in my URL space is called I want to check whether the user is authorized and redirect to a login page if he isn't. I found this post on usenet: http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/a6990567666934d2/12bca167849b64e9?lnk=gst&q=request-authorized-p&rnum=1&hl=en&fwc=2 According to this post, the generic function "request-authorized-p" is called for every request to determine whether a client is authorized. To test this, I've got: ============= snip ================== (defclass root-page-handler (araneida:handler) ()) (defmethod request-authorized-p ((araneida:handler root-page-handler) method request) (format t "not authorized")) (defmethod request-not-authorized ((araneida:handler root-page-handler) method request) (araneida:request-redirect request *login-urlstring*)) (defmethod handle-request-response ((araneida:handler root-page-handler) method request) (araneida:request-send-headers request) (araneida:html-stream (araneida:request-stream request) `(html (body (p "logged in"))))) (defparameter *root-page-handler-instance* (make-instance 'root-page-handler)) (araneida:install-handler (http-listener-handler *listener*) *root-page-handler-instance* *app-urlstring* t) ============= snip ================== So, I've got request-authorized-p on class root-page-handler. However, I find that this method is never called by Araneida; instead, handle-request-response is still called. What gives? What am I missing? Joubert

problems installing lisp on xen vps on amd64 machine

Naveen Garg — 2007-02-25T07:55:07

_______________________________________________ lispweb mailing list lispweb< at >red-bean.com http://www.red-bean.com/mailman/listinfo/lispweb

Re: The Common Lisp Directory turns 1

Kamen TOMOV — 2006-12-15T17:11:17

Happy Birthday! May the directory grow bigger and stronger together with the Common Lisp community.

Re: The Common Lisp Directory turns 1

Nick Levine — 2006-12-15T17:08:59

Today is the first birthday of the Common Lisp Directory! As of today the CLD has 1017 entries It is interesting to notice that one year later, it is still the same Lisp process that is running. the same Lisp process has served 111 977 267 HTTP requests. Nice one. My thanks (as a humble user, essentially) to everyone who's put in the effort. Would you care to submit a paper about it to ILC 2007? - nick

[ANN] cl-migrations 0.0.1

Vamsee Kanakala — 2006-11-12T03:43:12

Hi all, I would like to announce the availability of cl-migrations, a port of the migrations feature of Ruby on Rails to Common Lisp. cl-migrations is a simple tool to manage your changes to a database as you develop your web application or any database-backed application. It works by generating a new file to for each database change, which contains the DDL required to enable and disable that change. So, effectively you can version-control your entire database structure. You can install this tool with asdf: (asdf-install:install :cl-migrations) This tool depends on clsql, so you can run migrations on any database that is supported by clsql. Many thanks to Kevin Rosenberg for maintaining such a useful library. For more info, please go to this page: http://common-lisp.net/project/cl-migrations/ Kindly raise any questions/feature requests/bug-reports here: http://common-lisp.net/cgi-bin/mailman/listinfo/cl-migrations-devel Regards, Vamsee Kanakala.