March 2011 - tbnl-devel@common-lisp.net - mailman3.common-lisp.net

[hunchentoot-devel] Trouble with finish-output in process-connection
by Andrey Moskvitin 04 Apr '11

04 Apr '11

Hi, A few days ago on the site lisper.ru I started using Hunchentoot from trunk. And found that the system stopped working in a few hours. I watched the behavior of the system during the day and found that some threads do not complete their work and hangs on "finish-ouptut" (in "process-connection"). When they accumulate enough, the work stops. I have this problem on Debian 64-bit with SBCL-1.0.47 and SBCL-1.0.37. I have not had this trouble when used Hunchentoot-1.1.1 After replacing the "finish-output" on "force-output" in the "process-connection" the problem was fixed for me. Andrey

3 7

[hunchentoot-devel] SSL and concurrency crashes Lisp
by Daniel Brunner 31 Mar '11

31 Mar '11

Hi to everybody, I ran into the following problem with the SSL layer: I start my Lisp (CCL or SBCL, doesn't matter) and feed it with these lines: --8<-- (ql:quickload "hunchentoot") (defparameter *server* (hunchentoot:start (make-instance 'hunchentoot:ssl-acceptor :port 4711 :ssl-certificate-file #P"/home/dbr/local-cert.pem" :ssl-privatekey-file #P"/home/dbr/local-key.pem"))) --8<-- Then a SSL-ACCEPTOR is running and serving as wished. But when I use Apache Bench with some concurreny: > ab -f SSL2 -n 1000 -c 4 https://localhost:4711/ then the Lisp crashes and runs into the debugger. E.g. on CCL/Linux: --8<-- ? Unhandled exception 11 at 0x7f1843f1ebe9, context->regs at #x7f184390f428 Exception occurred while executing foreign code at lh_insert + 137 received signal 11; faulting address: 0x7f1843f8fa08 invalid permissions for mapped object --8<-- Or on SBCL/Linux: --8<-- CORRUPTION WARNING in SBCL pid 3549(tid 140737314223872): Memory fault at 0 (pc=0x7ffff4c6f940, sp=0x7ffff59ee280) The integrity of this image is possibly compromised. Continuing with fingers crossed. --8<-- I tested this scenario on different platforms: Clozure CL (1.7-dev-r14406M-trunk but it crashes on older versions as well) - 32 Bit on Windows Server 2003 - 64 Bit on Windows Server 2008 - 32 Bit on Ubuntu 10.04 - 64 Bit on Ubuntu 10.04 (libssl.0.9.8) SBCL 1.0.46 64 Bit on Ubuntu 10.04 (libssl.0.9.8) Used libraries/hunchentoot: - dists/quicklisp/software/cl+ssl-20101006-cvs/ - dists/quicklisp/software/hunchentoot-1.1.1/ Is this a known problem? Does anybody has an idea how to solve it? Kind regards, Daniel.

3 2

[hunchentoot-devel] session-value
by Haris 30 Mar '11

30 Mar '11

Hi. Can I increase session value with javascript/parenscript ? For example, I start the session, set a session value 'sum to 0 and then I want to increase its value on :onclick event ? Thanks

2 1

[hunchentoot-devel] Questions about using the same uri, but a different function for post and get methods.
by Jim Barrows 30 Mar '11

30 Mar '11

I have a uri "/my-uri", when a get request is made I want to return whatever information I have, and when a post request made, I want to update that information. I had thought that doing this: (define-easy-handler(get-business :uri "/business" :default-request-type :get)() (with-html-output-to-string (*standard-output* nil :prologue nil :indent t) (format t "{\"success\":true, \"data\": ~a}" (encode-json-plist-to-string (business::find-business))))) (define-easy-handler(post-business :uri "/business" :default-request-type :post) (business-name) (with-html-output-to-string( *standard-output* nil :prologue nil :indent t) (format t "post-business - ~a" business-name))) would accomplish that. However, the second handler is always called, for the get and the post. I'm new to Lisp, and was wondering what I'm missing. Any help would be greatly appreciated. -- James A Barrows

4 4

[hunchentoot-devel] any way to make upload more efficient?
by valgusk lalala 25 Mar '11

25 Mar '11

Hi there. I have just started with Hunchentoot. Being also a lisp newcomer i started out with reading tutorials and docs and this one mailing list, where I found some upload problems mentioned and getting interested in testing them out. After installation of hunchentoot (as a standalone server) on sbcl and trying to upload some files I got almost 100% cpu load on the host machine with just one file being uploaded. Then I tested it, hacking the rfc2388 module to only read from stream without processing or writing anything. I got a 50%+ cpu cload. The upload on apache/php is getting 5%. I saw that the lisp is equally heating the cpu just with stream reading-writing by making a separate file read-write test. It's an sbcl stream problem as i see it, nothing can be done here, I guess. It's acceptable for apache being held on this system, but i don't really want to run php alongside with lisp just for file uploads. So, do you think it would be possible to write some foreign module for just the multipart form-data processing and use it with Hunchentoot? Any way to make upload performance reasonable?

2 1

[hunchentoot-devel] [PATCH] handle ACCEPTOR-SHUTDOWN-P correctly
by Desmond O. Chang 21 Mar '11

21 Mar '11

After stopping an acceptor with STOP, one can't start it again with START, because the START method doesn't reset the value of acceptor-shutdown-p to NIL, so the listener returns/quits instantly. Also, the default value of ACCEPTOR-SHUTDOWN-P should be T, because every acceptor should be closed when it is created. See [1] & [2] for details. [1] http://article.gmane.org/gmane.lisp.lib.tbnl.general/2469 [2] http://article.gmane.org/gmane.lisp.lib.tbnl.general/2868 --- acceptor.lisp | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/acceptor.lisp b/acceptor.lisp index ba90e2e..168c9b9 100644 --- a/acceptor.lisp +++ b/acceptor.lisp @@ -120,7 +120,7 @@ connections.") :documentation "Number of pending connections allowed in the listen socket before the kernel rejects further incoming connections.") - (acceptor-shutdown-p :initform nil + (acceptor-shutdown-p :initform t :accessor acceptor-shutdown-p :documentation "A flag that makes the acceptor shutdown itself when set to something other than NIL.") @@ -266,6 +266,7 @@ they're using secure connections - see the SSL-ACCEPTOR class.")) ;; general implementation (defmethod start ((acceptor acceptor)) + (setf (acceptor-shutdown-p acceptor) nil) (start-listening acceptor) (let ((taskmaster (acceptor-taskmaster acceptor))) (setf (taskmaster-acceptor taskmaster) acceptor) -- 1.7.4.1

3 3

[hunchentoot-devel] hunchentoot-mp
by Haris 20 Mar '11

20 Mar '11

Hi. Where do I download hunchentoot-mp package ? Thanks

4 4

[hunchentoot-devel] Installing Hunchentoot on SBCL, Ubuntu 10.X
by Oleg Sivokon 19 Mar '11

19 Mar '11

Hello. Please forgive me asking questions with probably obvious answers. I'm new to the Lisp world in general, and to using Hunchentoot too. Since I'm new, I had a lot of problems installing Hunchentoot... I had successfully did it on two Ubuntu 10.4 machines, one 32 bit and another 64 bit both running last SBCL available from Ubuntu PPA. I had also tried to record my experience so I could explain it to anyone who asked. I'm effectively writing a mock-up server to do testing for the project that otherwise runs in a different environment, yet, at some point I would like other people to be also able to replicate my steps on installing the server and running my code. Major problems I encountered: - ASDF does not update... (I know, you have nothing to do with this, yet whenever the manual on the site mentions ASDF, it would be great if it would take in account that ASDF not only may do things wrong, it most probably will...). Long story short, I've tried to update ASDF following manual on their site - never worked due to some missing methods or just reverting to the last version w/o any notion. I've also tried building SBCL from sources. The last version in development comes with latest ASDF version (2.0), yet the installation instructions are bizarre and contradict themselves... At the most successful point I could install what compiles from trunk, but in order to run that version as root, I would need to specify the sbcl.core on launch. I could also install Hunchentoot into this version of SBCL, but it had problems with UFFI (separate story below). Various other packages in this mode would report missing files or non-existing functions and so on. It proved to be unusable. - ASDF-INSTALL, similarly, trying to install from archive or from site (clicky) were subsequently unsuccessful. Having only clean SBCL install, ASDF-INSTALL would break at random trying to solve dependencies. I couldn't find the pattern. By trial and error I found, that the combination of having CL-PPCRE, USOCKET, CLOSER-MOP and CXML (!) would most of the time lead to that Hunchentoot would be able to find all dependencies during install. This happened 2 times out of maybe 8... - There's some package, which during installation would break the display in console... (the console will start displaying random non-printable characters) It would also stop during compile offering different restarts, where you are forced to play pitch-n-toss :) And if you are lucky, then the console will recover. - Finally, the most sure way I found was to just (require :hunchentoot) using ASDF v 1 and resolve missing dependencies by hand. It would sometimes break when trying to install CL-PPCRE, presumably due to another dependency having something to do with Unicode, but it succeeded more often then failed. - UFFI - for all I tried it failed to compile and install properly always. It looks like the errors are in *insignificant* tests, yet for an unexperienced user this looks scary (mistyped pointers?!) :) Often the errors when compiling this package will also break the installation started by ASDF - it will not offer to skip the failed compilation, or so I understood what happened. (I also saw some messages regarding omission of "dead" code, while compiling this package - this also looks suspicious, why would anyone release such code, and may there be any connection between that, and that the code failed to compile in the end?) Some weird things I saw during installation: an attempt was made to install SLIME. It somehow got into dependency list of Hunchentoot... I've encountered several times notion of 64-bit processor architecture in different libraries related to Common Lisp as "PPC" - I never heard of this abbreviation before in this context, (no pun intended), what does it mean? This was one of really confusing places when reading the documentation (I would assume it to be Apple Motoralla processor from 10 years ago). For whatever other arcane reason Ubuntu / Debian tech papers call supported 64-bit processors AMD86 or AMD8664 (some of them having nothing to do with AMD!). Now, my question is, is my experience something you would expect a user to undergo? Is SBCL an experimental brunch of Common Lisp, and, would I want to develop in more stable environment, do I have to switch to another version of CL? (Back in the days I've used CMUCL on Windows, albeit very shortly, but I don't recall that many problems...) Or are Hunchentoot and SBCL not really compatible, and the attempt to put them together makes it so difficult? Of course, most chances are I am doing something wrong :) Yet it would be nice if someone more experience commented. Oh, and btw, I've managed to then install CL-GD and use it with Hunchentoot, for that I had to, again, delete some shared libraries in system folders and rewrite Make file... It worked, as I said, but, again, I've a feeling I do things the wrong way and it shouldn't be this difficult... And, one last thing, if there are bugs filed against the server, is it possible to view them somewhere? I've found few bug-trackers during my setup exercises :) however, I'm not sure which is an official one. Thank you.

7 10

[hunchentoot-devel] turning off logging, and socket backlogs (patches included)
by JTK 15 Mar '11

15 Mar '11

[This is all in a recent bknr svn hunchentoot running on opencml and sbcl on a mac 10.6] 1. Logging: I've been playing with running hunchentoot under heavy loads using easy-acceptor, and running against apache-bench (ab) I noticed that logging to *error-output* often causes socket failures under heavy load, at least in SLIME. Is there a reason why with-open-file-or-console in log.lisp couldn't use a NIL pathname to simply not log, and pathname=T would log to *error-output*, which is what NIL presently means? Now, there seems to be no way to turn off logging (besides subclassing acceptor). 2. Backlog in listener: I found that in the start-listening method in acceptor.lisp, there is no BACKLOG set for usocket:socket-listen. I think that others have pointed this out as well. The default apache backlog seems to be 100 to 512 [1,2,3] though the default on a macintosh seems silently limited to 128 [4]. In the usocket routines used by hunchentoot backlog seems to be only 5. This seems two orders of magnitude smaller than what is standard for web servers. I tried putting in :BACKLOG 50 into the start-listening method in acceptor.lisp and it eliminated most failures of ab. Is there any reason why acceptor objects shouldn't have a new backlog slot default value in them much larger than 5, which should be used in the start-listening method? The appended patches implement both changes, if these suggestions are judged useful. The backlog is 50. I hope they're done correctly; I'm not experienced in submitting patches. John [1] http://groups.google.com/group/modwsgi/browse_thread/thread/b6d66d3fe5a53d2c [2] http://weblog.pigfoot.org/pigfoot/2007/07/05/whats-the-maximum-value-of-bac… [3] /usr/include/apache2/mpm_common.h:#define DEFAULT_LISTENBACKLOG 511 [4] http://developer.apple.com/library/mac/#documentation/darwin/reference/manp…

2 1

[hunchentoot-devel] sessions
by Haris 14 Mar '11

14 Mar '11

Hi. Could someone give me a simple example of using sessions ? I have a simple web application and want to add user registration so that the server knows who submitted some form. Thanks

1 0