April 2007 - tbnl-devel@common-lisp.net - mailman3.common-lisp.net

[hunchentoot-devel] FIXED: New release 0.8.6 (Was: hunchentoot-mp and OpenMCL problems)
by Joel Boehland 18 Apr '07

18 Apr '07

Hi Edi, Hunchentoot version 0.8.6 fixed the problem. I can load up the test application without problems on OpenMCL/linux. That was very fast. Thanks! --Joel On 4/18/07, Edi Weitz <edi(a)agharta.de> wrote: > On Wed, 18 Apr 2007 11:10:48 -0700, "Joel Boehland" <jboehland+tbnl(a)gmail.com> wrote: > > > The following is a transcript captured using gnu screen, where I try > > your suggestions and have captured a back trace. > > Could you please try the new release and check if this fixes it? > > Thanks for the report, > Edi. > _______________________________________________ > tbnl-devel site list > tbnl-devel(a)common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel >

1 0

[hunchentoot-devel] hunchentoot-mp and OpenMCL problems
by Joel Boehland 18 Apr '07

18 Apr '07

Hi, I just ran into a problem starting up-to-date darcs hunchentoot on OpenMCL 1.1 (releases 070408 and 070214, linux-x86-64). I believe this problem is related to the recently added hunchentoot-mp package, as this error doesn't occur in an earlier install of darcs hunchentoot from March, right before the addition of that package. While trying to load this file: (hello-hunchentoot.lisp) (require :asdf) (asdf:oos 'asdf:load-op :hunchentoot-test) (hunchentoot:start-server :port 4242) I got this error: > Error: The function MAKE-LOCK is predefined in OpenMCL. > While executing: CCL::REDEFINE-KERNEL-FUNCTION, in process listener(1). > Type :GO to continue, :POP to abort, :R for a list of available restarts. > If continued: Replace the definition of MAKE-LOCK. > Type :? for other options. 1 > If anyone needs any more info, or wants me to test anything to help out, let me know. Thanks, Joel

2 3

[hunchentoot-devel] Handling Lisp errors.
by Victor Kryukov 17 Apr '07

17 Apr '07

Hello list, I want to accomplish the following: every time a lisp error happens, the whole backtrace and some additional information is sent to my mail account. The question is, what is the best way to do it with Hunchentoot? (I do know how to send email messages from lisp with the help of mel-base). The second question is: how do you use CLSQL thread-safely with Hunchentoot / SBCL? SBCL don't provide thread properties, so my first solution[1] was to create a hash-table and to assign each thread a connection, to check from every thread whether it already has a connection, and then to clean that hash-table periodically, closing connections for dead threads. That worked pretty well, but I was afraid of exhausting limit of database threads somehow, so I switched to the second solution. The second solution[2] is to open new connection every time I need to save something to database or read something from it, and to close it right after that. That of course solves connection limit problem (unless I have very many users simultaneously, which is not expected in the near term), however it's much slower. Anybody can share his/her strategy? Best regards, Victor. [1] http://paste.lisp.org/display/39787 (defparameter *database-mutex* (sb-thread:make-mutex :name "database lock")) (defparameter *threads-connection* (make-hash-table)) (defun setup-connection () (connect '("localhost" "lj" "victor" "victor") :database-type :postgresql :if-exists :new)) (defun db () (handler-case (sb-thread:with-mutex (*database-mutex*) (or (gethash sb-thread:*current-thread* *threads-connection*) (setf (gethash sb-thread:*current-thread* *threads-connection*) (setup-connection)))) (error () (progn (close-old-connections) (db))))) (defun close-old-connections () (maphash #'(lambda (thread connection) (unless (sb-thread:thread-alive-p thread) (clsql:disconnect :database connection) (remhash thread *threads-connection*))) *threads-connection*)) (let ((old-select (symbol-function 'clsql:select))) (defun select (&rest args) (let ((*default-database* (db))) (apply old-select args)))) (let ((old-insert-records (symbol-function 'insert-records))) (defun insert-records (&rest args) (apply old-insert-records :database (db) args))) [2] http://paste.lisp.org/display/39787#1 (defun db () (connect *connection-spec* :database-type :postgresql :if-exists :new)) (let ((old-select (symbol-function 'clsql:select))) (defun select (&rest args) (let ((clsql:*default-database* (db))) (prog1 (apply old-select args) (disconnect :database clsql:*default-database*))))) (let ((old-insert-records (symbol-function 'insert-records))) (defun insert-records (&rest args) (let ((db (db))) (prog1 (apply old-insert-records :database db args) (disconnect :database db))))) -- Yours Sincerely, Victor Kryukov

6 9

[hunchentoot-devel] Headers eaten during HTTP POST...
by Timofei Shatrov 16 Apr '07

16 Apr '07

I'm rather new to web-programming and I seem to have stumbled upon something horrible. My setup is lighttpd+mod_proxy on Windows XP which redirect to Hunchentoot running on SBCL on Ubuntu Feisty, which is running on VMWare player on the same PC. Everything works fine except HTTP POST, which behaves very weirdly. When I submit POST data, everything is screwed. After some attempts to debug, I found that beginning of headers becomes eaten for some reason, for example the first line may be: "8.1.2) Gecko/20061201 Firefox/2.0.0.2 (Ubuntu-feisty)" (which is part of User-agent: header), when it should be "POST /cl/test-form /HTTP1.1" After that Hunchentoot tries to parse this line and you can guess that nothing good comes out of it... Note that this only happens when I access the page through mod_proxy, when I point at Hunchentoot's IP, everything is fine. However I can't believe mod_proxy randomly eats headers, because that's rather huge bug and would be noticed by everyone. This is reproduceable with hutchentoot-test examples which involve POST. -- Best regards, Timofei Shatrov mailto:grue@mail.ru

2 1

[hunchentoot-devel] finish-output usage in create-static-file-dispatcher-and-handler
by Volkan YAZICI 16 Apr '07

16 Apr '07

Hi, Just for curiosity, in create-static-file-dispatcher-and-handler function, wouldn't it be better if we flush the buffer finally in the loop instead of calling finish-output at every step. Does it have a special objective, e.g., for debugging purposes, portability issues? And maybe, it'd even be better to use (or to support optionally) force-output instead of finish-output. (With price of not receiving any acknowledgment about the flushed buffer.) Regards.

2 1

[hunchentoot-devel] Unit testing Hunchentoot websites
by Slava Akhmechet 16 Apr '07

16 Apr '07

I'm building a web framework on top of Hunchentoot and I ran into problems while trying to unit test some of my code. Essentially I need to unit test behavior that happens accross requests. I want to do it without starting Hunchentoot by faking the necessary objects (request, session, etc.) The documentation says the usual special variables passed to handlers contain opaque objects. Hunchentoot provides no means of instantiating them manually (unless I get into internal code, which will tie me to the implementation). I see two possible solutions: 1. Abstract my code away from Hunchentoot objects. This way I can fake the necessary environment during unit testing and use Hunchentoot's environment during the real thing. 2. Create my own objects and make sure all appropriate symbols are defined for them - essentially faking Huchentoot's API. It seems like the first option is a better one, but I feel like Huchentoot should provide some support for this. I'd be happy to hack it in if I get some direction (as I'm new to Hunchentoot and CL in general). -- Regards, Slava Akhmechet.

3 7

[hunchentoot-devel] I/O timeout error (SBCL)
by red daly 16 Apr '07

16 Apr '07

This is a repeat of an earlier problem one user had, as documented in this thread: http://common-lisp.net/pipermail/tbnl-devel/2006-December/000876.html >Basically, mx explanation in the other email was right except for the >logging part. There should /probably/ be some cleanup that prevents >errors like this one (that aren't really errors) to pop up the >debugger. Maybe an intrigued soul will contribute a patch. The bug is more of an annoyance than anything. The original email before I noticed it was a repeat report: I have been noticing this IO error since several months ago. When catch-signals is nil, hunchentoot occasionally throws me into the debugger. It signals at seemingly random points during a server's lifetime. I have a backtrace, but I do not know the source of the error. I am running a 64 bit version of SBCL, though I have noticed this on 32 bit SBCL, too. I/O timeout reading #<SB-SYS:FD-STREAM for "a constant string" {10028FCEB1}> [Condition of type SB-SYS:IO-TIMEOUT] Restarts: 0: [TERMINATE-THREAD] Terminate this thread (#<THREAD "hunchentoot-worker-79" {10027721A1}>) Backtrace: 0: ((LAMBDA (SWANK-BACKEND::DEBUGGER-LOOP-FN)) #<FUNCTION (LAMBDA #) {10067D6969}>) 1: (SWANK::DEBUG-IN-EMACS #<SB-SYS:IO-TIMEOUT {1003007811}>) 2: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {1003007C19}>) 3: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION {10034586B1}> #<CLOSURE (LAMBDA #) {1003007C39}>) 4: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {10034586B1}> #<CLOSURE (LAMBDA #) {1003007C19}>) 5: (INVOKE-DEBUGGER #<SB-SYS:IO-TIMEOUT {1003007811}>) 6: (INVOKE-DEBUGGER #<SB-SYS:IO-TIMEOUT {1003007811}>) 7: (HUNCHENTOOT::MAYBE-INVOKE-DEBUGGER #<SB-SYS:IO-TIMEOUT {1003007811}>) 8: (SIGNAL #<SB-SYS:IO-TIMEOUT {1003007811}>) 9: (ERROR SB-SYS:IO-TIMEOUT) 10: (SB-IMPL::REFILL-BUFFER/FD #<SB-SYS:FD-STREAM for "a constant string" {10028FCEB1}>) 11: (SB-IMPL::INPUT-UNSIGNED-8BIT-BYTE #<SB-SYS:FD-STREAM for "a constant string" {10028FCEB1}> NIL :EOF) 12: ((SB-PCL::FAST-METHOD STREAM-READ-BYTE (CHUNGA:CHUNKED-INPUT-STREAM)) (#(8 9) . #()) #<unavailable argument> #<CHUNGA:CHUNKED-IO-STREAM {1002BE9B91}>) 13: ((SB-PCL::FAST-METHOD FLEXI-STREAMS::READ-BYTE* (FLEXI-STREAMS:FLEXI-INPUT-STREAM)) #<unavailable argument> #<unavailable argument> #<unavailable argument>) 14: ((SB-PCL::FAST-METHOD STREAM-READ-CHAR (FLEXI-STREAMS::FLEXI-LATIN-1-INPUT-STREAM)) #<unavailable argument> #<unavailable argument> #<unavailable argument>) 15: (READ-CHAR #<FLEXI-STREAMS::FLEXI-LATIN-1-IO-STREAM {1002BFEF81}> T NIL #<unused argument>) 16: (CHUNGA:READ-LINE* #<FLEXI-STREAMS::FLEXI-LATIN-1-IO-STREAM {1002BFEF81}> NIL) 17: (HUNCHENTOOT::GET-REQUEST-DATA) 18: (HUNCHENTOOT::PROCESS-CONNECTION #<HUNCHENTOOT::SERVER {10038DFDB1}> #<SB-BSD-SOCKETS:INET-SOCKET descriptor 10 {1002771261}>) 19: ((LAMBDA ())) 20: ("foreign function: #x41EE32") 21: ("foreign function: #x416EF1") -red

2 2

[hunchentoot-devel] Running multiple web application
by Andrei Stebakov 13 Apr '07

13 Apr '07

I just wanted to consult what's the best strategy for using multiple hunchentoot applications. Is it better to use one *dispatch-table* and insert multiple handlers for different application in this table or have many servers listening on different ports? I'd like to go with multiple hunchentoot:start-server, does it have any disadvantages? Thank you, Andrew

6 14

[hunchentoot-devel] *http-error-handler* on IE 7.0 (http code 500)
by Andrei Stebakov 10 Apr '07

10 Apr '07

When I use the *http-error-handler* it works fine on Firefox displaying my message and doing some extra job. On IE it says "Can not display page" and shows the HTTP 500 code. I guess I need to filter out the http status code 500 and replace it for status ok somewhere. How can I replace the status code or fix the page in IE? BTW, when I use (redirect) inside of some of my handlers call I also get to the *http-error-handler*. I guess the proper thing to do is to add +http-moved-temporarily+ into the *approved-return-codes*. Thank you, Andrew

3 5

[hunchentoot-devel] New release 0.8.5
by Edi Weitz 09 Apr '07

09 Apr '07

ChangeLog: Version 0.8.5 2007-04-10 Correct behaviour for "100 Continue" responses Download: http://weitz.de/files/hunchentoot.tar.gz Cheers, Edi.

1 0