tbnl-devel August 2008

tbnl-devel@common-lisp.net

8 participants
5 discussions

[hunchentoot-devel] Request methods suffixed with * -- not backwards compatible?
by Chaitanya Gupta 03 Sep '08

03 Sep '08

Hi, I was trying to use the svn branch of Hunchentoot, and found, to my surprise, that most of my old code didn't work anymore. The culprit mainly seems to be request.lisp, where a lot of old functions/methods have been renamed with a * suffixed to their name. Are these changes permanent? Will these make it into the release version? Also, what is the reason behind this? I tried searching the mailing list for any discussion on this, but couldn't find anything. One more thing, there were no such changes to reply.lisp i.e. no *-suffixed names there. Will the reply methods also undergo these changes? Chaitanya

4 10

[hunchentoot-devel] Reading and writing additional cookies.
by Yarek Kowalik 27 Aug '08

27 Aug '08

I'm in the process of writing an application based on Weblocks. Weblocks uses Hunchentoot - I have been using version 0.11.1. I would like to set some application specific cookies. I would I go about doing that? My initial guess would be to setup a handler in the dispatch table and access (via special) the *reply* object to set the cookie using setf on cookies-out, and similarly access the *reqest* object to read the cookie value. Am I on the right track? Suggestions please. Thanks, Yarek

2 3

[hunchentoot-devel] Re: The old hunchentoot shared thread on openmcl bug
by Edi Weitz 18 Aug '08

18 Aug '08

Hi Mikel, Please send Hunchentoot question to the appropriate mailing list, see Cc. On Sun, 17 Aug 2008 06:08:54 -0500, mikel evins <mevins(a)mac.com> wrote: > Sorry to bother you with an old problem, but I'm stumbling over a > problem that is maybe an old one you're familiar with. I have a web > application built on Hunchentoot and cl-prevalence. I got fairly far > along and then ran into the problem where the lisp (Clozure CL) > process dies trying to write to a stream: > > Error: Stream #<BASIC-FILE-CHARACTER-OUTPUT-STREAM ("/Users/mikel/ > Valise/guild/trunk/src/ccl-src/ymra.world.db/transaction-log.xml"/6 > ISO-8859-1) #x30004294610D> is private to #<PROCESS hunchentoot- > worker-7(10) [Exhausted] #x300042944F8D> > > Presumably the cl-prevalence code that tries to write to the db is > using a stream that was created private in a different thread. Do > you remember where I should look for the code you used to fix this > for other cases? I'll track down the culprit and fix it; I was just > hoping to speed the process along by finding code that already did > the right thing somewhere. > > Thanks for any help. > > In case it's of interest, I'm using Hunchentoot 0.15.6 on Clozure CL > 1.2-r10477M-trunk with cl-prevalence 1.6. This looks like a CCL-specific problem not really related to Hunchentoot. Look at the :SHARING :LOCK keyword arguments to OPEN in log.lisp, maybe this'll help for your streams. Cheers, Edi.

1 0

[hunchentoot-devel] re: thread pool benchmark results
by Nick Allen 16 Aug '08

16 Aug '08

on Friday, July 18, 2008, 7:34:27 AM Hans wrote: > On Fri, Jul 18, 2008 at 03:00, Anton Vodonosov <avodonosov at yandex.ru> wrote: >> I have set up a little benchmark to test ithow >> thread pool may improve the hunchentoot performance. >> >> In two words it looks useful. Details are below. > [...] >> Patch for port-sbcl.lisp with the simple thread pool >> implementation is also attached. It is against 0.15.7, >> sorry it's not for the current development version of >> hunchentoot, but I created this thead pool code about >> half a year ago. > I think we would accept performance patches to the development > version. The revised connection management should make it easier to > integrate thread pooling in a portable fashion. I used pcall http://marijn.haverbeke.nl/pcall/ to make a portable thread-pool-powered connection manager (note: I don't have lispworks and I have no idea if pcall and lispworks work together since it uses bordeaux threads) darcs get http://common-lisp.net/project/bpm/darcs/pcall-connection-manager I think once the cl.net darcsweb script it might be browsable on the web at http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=bpm-pcall-connection… but I'm not 100% positive and I don't know how long it will take for it to be visible... note: in order to use it you have to add &ALLOW-OTHER-KEYS to the end of the parameters to HUNCHENTOOT:START-SERVER so it will accept the :CONNECTION-MANAGER-CLASS keyword arg anyways I tried to benchmark it against the one-thread-per-connection-manager on my laptop using siege. I used both the default dispatcher (the default hunchentoot landing page) and a dispatcher that returned a handler that slept for 3 seconds and returned a page (defun wait-for-3-seconds (hunchentoot:*request*) (lambda () (sleep 3) "this is the page")) with 3-5 threads in the pool the 1-thread-per-connection manager performed a lot better with both dispatchers. with 20-50 threads both connections managers had about the same performance with the 1-thread-per-connection manager being slightly faster. I'm sure there are better ways to benchmark it, but I'm not in a position to be playing with our server at the moment. I haven't taken a look at Anton's tests yet. Nick

2 2

[hunchentoot-devel] Is there a better way?
by Kevin Raison 08 Aug '08

08 Aug '08

I am trying to determine the best way to accomplish the following task and could use some help. I am writing a web-based (using hunchentoot, of course) application for managing voicemail that is stored in Cisco's Unity system. I can access the voicemail box of a given use via IMAP. The mel project has helped make that part easy. However, I am not sure the best way to send the audio stream to the user's browser. The method below illustrates (inefficiently) what I need to do. Can anyone suggest a more efficient method that does not use (send-headers)? The hunchentoot docs say, "If your handlers return the full body as a string or as an array of octets, you should not call this function." However, I cannot find an alternative way to do what I need to do. I must fetch the voicemail as an email via IMAP and then decode the base64-encoded body, which contains the voicemail as a wav file. Writing out a wav file and pointing the user's browser to it would introduce security issues, so I must do this entire process in memory. Any help is appreciated. (defmethod send-audio-stream ((user user) msg-id) "Convert the message body and send the wav content to the user." (handler-case (let ((msg (mel:find-message (mbox user) msg-id))) (setf (content-type) "audio/x-wav") (setf (header-out "Content-Disposition") (format t "inline; filename=~a.wav" msg-id)) (setf (content-length) ;; FIXME! Why do this twice? (length (base64-decode-msg-body-to-array msg))) (let ((stream (send-headers))) (base64-decode-msg-body-to-stream msg :stream stream))) (error (condition) (format nil "Unable to play message: ~a" condition)))) Cheers. Kevin Raison

3 8

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

tbnl-devel August 2008