From edi at agharta.de  Mon Feb  1 11:42:09 2010
From: edi at agharta.de (Edi Weitz)
Date: Mon, 1 Feb 2010 12:42:09 +0100
Subject: [hunchentoot-devel] Hunchentoot web page gives error
In-Reply-To: <20100201113603.GD7956@sidep.ath.cx>
References: <20100201113603.GD7956@sidep.ath.cx>
Message-ID: <b56421a01002010342je9084capd0f37bf2c3a07c2@mail.gmail.com>

Hi,

Please follow up on the mailing list (see Cc).  I can't see the error
and I can't open your attachment.  Which browser and OS are you using?

Thanks,
Edi.


On Mon, Feb 1, 2010 at 12:36 PM, tczy <cy at wre.ath.cx> wrote:
> Hi.
>
> http://www.weitz.de/hunchentoot/
>
> gives the following:
>
> =====
> This page contains the following errors:
>
> error on line 2 at column 3: Char 0x0 out of allowed range
> Below is a rendering of the page up to the first error.
> =====
>
> --
> PGP/GnuPG keyID: D7AE1B98
> Key signature: ? 9D08 F20B C9CA 4174 5968 ?C0DE 9751 20F1 D7AE 1B98
>



From mackram at gmail.com  Mon Feb  1 18:31:08 2010
From: mackram at gmail.com (Mackram Raydan)
Date: Mon, 1 Feb 2010 20:31:08 +0200
Subject: [hunchentoot-devel] silly issue with session and Hunchentoot due to
	warning
Message-ID: <37654d131002011031p7100e35blb190fcd1577b685c@mail.gmail.com>

Hey Everyone,

I am fairly certain that there must be an easy workaround to the issue I am
experiencing but I might be blind to it. I am using Hunchentoot in the
backend to handle a few things part of which is the session. Unfortuanetly
it causes an error everytime I try to use the session I get a dump similar
to this (I have cut it a bit to make more sense)
32SIGNAL

   1. Couldn't write to #<SB-SYS:FD-STREAM for "standard error"
   {1002782181}>: Input/output error

31ERROR

   1. SIMPLE-STREAM-ERROR

30SIMPLE-STREAM-PERROR

   1. Couldn't write to ~s
   2. #<FD-STREAM for "standard error" {1002782181}>
   3. 5

23INTERPRET-FORMAT-LOGICAL-BLOCK

   1. #&l t;SYNONYM-STREAM :SYMBOL SB-SYS:*STDERR* {1000148D21}>
   2. (WARNING Session secret is unbound. Using Lisp's RANDOM function to
   initialize it.)
   3. (WARNING Session secret is unbound. Using Lisp's RANDOM function to
   initialize it.)
   4.
   5. NIL
   6. (#<~S> : #<~3i> #<~:_> #<~A>)
   7.
   8. T

As you can see the problem is that it could not dump the warning on the
standard output. My guess is that I should stop the warning but trying to do
(setf hunchentoot:*log-lisp-warnings-p* nil) did not work with it.

Can anyone suggest what i am missing?


Mackram Raydan

Company: www.imagimate.com
Website: www.trailoflight.net

"An invasion of armies can be resisted, but not an idea whose time has
come." Victor Hugo


On Thu, Jan 28, 2010 at 6:54 PM, Arjan Wekking <arjan at streamtech.nl> wrote:

> On 28 jan 2010, at 15:57, Patrick May wrote:
>
>         I don't think this is a Hunchentoot issue, but I thought I'd ask
>> here first.  I've noticed that Safari seems to cache the basic authorization
>> username and password, so that even if I call (remove-session *session*) on
>> the server side, Safari just reloads the page.
>>
>
> As far as I know, Hunchentoot sessions have nothing to do with HTTP basic
> authentication, of which Safari can indeed store the credentials in the OS X
> Keychain (other browsers like Firefox or Chrome also allow you to 'save your
> username and password' somewhere).
>
> All browsers actually 'cache' HTTP authentication credentials one way or
> another between HTTP requests and usually forget them when you close the
> window and/or tab that was authenticated [1]. This is not the same as
> storing them in the Keychain but just part of how a HTTP authentication
> 'session' works in browsers.
>
> Standard Hunchentoot sessions have nothing to do with HTTP authentication
> unless you've re-implemented them to use HTTP authentication credentials as
> session identifiers somehow (which would be an interesting approach but
> that's not really relevant right now).
>
>
>         Am I interpreting the behavior correctly?  If so, how do I force a
>> re-authorization?
>>
>
> With HTTP authentication, the simple anser is that you can't. Logging in
> and out is under the HTTP client's control (where it in my opinion should
> be). Unfortunately there's no good UI in browsers yet to gracefully log in
> and out with HTTP authentication. Heck, you can't even see *if* your browser
> is supplying any HTTP credentials without inspecting your own HTTP requests.
>
> Theoretically, you can do something like:
>
>   (setf (return-code*) +http-authentication-required+)
>
> Which basically means that your webserver is telling the HTTP client that
> whatever it supplied as credentials in the current request is not accepted
> anymore (401 Unauthorized) and that it, in other words, should supply other
> credentials. Some browsers will then clear the 'cached' credentials and ask
> the user to supply new ones.
>
> This means that in browsers that do not store credentials, you will be
> presented with a new 'please enter your username and password' dialog again,
> right after logging out, and there's no way around this. I think Safari, in
> this case, simply fetches them from the Keychain again and silently 'logs
> in' again without the user even noticing, but I'm not entirely sure about
> this.
>
> Either way, it's not a real solution.
>
> One thing that might work is to embed the Hunchentoot session ID into the
> basic authentication 'realm', in which case (remove-session *session*)
> actually works. But, by doing this, you effectively break the whole 'store
> this username and password in my keychain' feature of Safari and similar
> 'remember this username and password' features of all browsers, because the
> browsers will store them along with the realm and when the realm changes, it
> cannot reuse these stored credentials.
>
> The other way is to use cookie or URL based session and store the
> authentication status in the server. This is where the Hunchentoot session
> would come in and in this case you would probably need to build a simple
> log-in HTML form, although it's possible to use HTTP authentication to
> 'authenticate' the session as well and offer both a public login form and
> HTTP authentication when directly accessing protected resources and still
> have a 'log out' option that simply destroys or de-authenticates the session
> server-side.
>
> I hope this all makes some sense :]
>
> -Arjan
>
> [1] http://en.wikipedia.org/wiki/Basic_access_authentication
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20100201/b5d6c939/attachment.html>

From mackram at gmail.com  Mon Feb  1 18:32:31 2010
From: mackram at gmail.com (Mackram Raydan)
Date: Mon, 1 Feb 2010 20:32:31 +0200
Subject: [hunchentoot-devel] silly issue with session and Hunchentoot
	due to warning
In-Reply-To: <37654d131002011031p7100e35blb190fcd1577b685c@mail.gmail.com>
References: <37654d131002011031p7100e35blb190fcd1577b685c@mail.gmail.com>
Message-ID: <37654d131002011032qf5e00b8s6be6f2c899ec9f8c@mail.gmail.com>

Apologies on the cut from previous emails in the previous email. Not
intentional.


Mackram Raydan

Company: www.imagimate.com
Website: www.trailoflight.net

"An invasion of armies can be resisted, but not an idea whose time has
come." Victor Hugo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20100201/9010c280/attachment.html>

From martin.loetzsch at gmail.com  Tue Feb  2 10:14:35 2010
From: martin.loetzsch at gmail.com (Martin Loetzsch)
Date: Tue, 2 Feb 2010 11:14:35 +0100
Subject: [hunchentoot-devel] ht-simple-ajax
Message-ID: <D1712A71-180D-4BEE-B210-4302F058E81F@gmail.com>

Hi all,

I recently posted here about HT-AJAX and Hunchentoot, which are kind  
of out of sync. I tried to make a patch for HT-AJAX that makes it  
compatible with newer versions of Hunchentoot, but I soon gave up  
because it seemed to me that a lot of functionality was already broken  
before Hunchentoot 1.0 came out.

So I decided to make HT-SIMPLE-AJAX, which can do only 10% of what HT- 
AJAX could do. On the other hand, that's what I needed for GTFL (http://martin-loetzsch.de/gtfl 
). And it's very elegant (only 150 loc) and works together with newer  
Hunchentoot versions:

http://martin-loetzsch.de/ht-simple-ajax/

Hoping that somebody finds this useful,

Martin Loetzsch



From cy at wre.ath.cx  Tue Feb  2 14:37:31 2010
From: cy at wre.ath.cx (tczy)
Date: Tue, 2 Feb 2010 16:37:31 +0200
Subject: [hunchentoot-devel] Hunchentoot web page gives error
In-Reply-To: <b56421a01002010342je9084capd0f37bf2c3a07c2@mail.gmail.com>
References: <20100201113603.GD7956@sidep.ath.cx>
	<b56421a01002010342je9084capd0f37bf2c3a07c2@mail.gmail.com>
Message-ID: <20100202143731.GA5315@sidep.ath.cx>

On Mon, Feb 01, 2010 at 12:42:09PM +0100, Edi Weitz wrote:
> On Mon, Feb 1, 2010 at 12:36 PM, tczy <cy at wre.ath.cx> wrote:
> > Hi.
> >
> > http://www.weitz.de/hunchentoot/
> >
> > gives the following:
> >
> > =====
> > This page contains the following errors:
> >
> > error on line 2 at column 3: Char 0x0 out of allowed range
> > Below is a rendering of the page up to the first error.
> > =====
>
> Hi,
> 
> Please follow up on the mailing list (see Cc).  I can't see the error
> and I can't open your attachment.  Which browser and OS are you using?
> 
> Thanks,
> Edi.

Don't bother about the attachment, it was probably the GPG signature.
I didn't attach anything manually.

OS:
Linux <host> 2.6.32-ARCH #1 SMP PREEMPT <build-date> x86_64 Intel(R)
Core(TM)2 Duo CPU T5670 @ 1.80GHz +GenuineIntel GNU/Linux

Browser:
Uzbl (experimental commit, changes a lot), running on
WebKitGTK+ 1.1.15.4

The error is not present in Firefox 3.5.7 or 3.6. However, I've noticed
that scrolling with keys 'j' and 'k' (Vimperator plugin) is impossible.

-- 
PGP/GnuPG keyID: D7AE1B98
Key signature:   9D08 F20B C9CA 4174 5968  C0DE 9751 20F1 D7AE 1B98
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20100202/428baf09/attachment.sig>

From edi at agharta.de  Tue Feb  2 16:13:56 2010
From: edi at agharta.de (Edi Weitz)
Date: Tue, 2 Feb 2010 17:13:56 +0100
Subject: [hunchentoot-devel] Hunchentoot web page gives error
In-Reply-To: <20100202143731.GA5315@sidep.ath.cx>
References: <20100201113603.GD7956@sidep.ath.cx>
	<b56421a01002010342je9084capd0f37bf2c3a07c2@mail.gmail.com>
	<20100202143731.GA5315@sidep.ath.cx>
Message-ID: <b56421a01002020813w592b0ca4l3f4c9eb11996e6d4@mail.gmail.com>

On Tue, Feb 2, 2010 at 3:37 PM, tczy <cy at wre.ath.cx> wrote:

> Browser:
> Uzbl (experimental commit, changes a lot), running on
> WebKitGTK+ 1.1.15.4

Ugh, well.  I think as long as the website works with the three or
four major browsers, I'm fine.  Having said that, if there's an actual
bug in the page (as opposed to in Uzbl), I'll be happy to fix it if
you send me a patch.

Thanks for the report, though.

Edi.



From cy at wre.ath.cx  Tue Feb  2 16:54:42 2010
From: cy at wre.ath.cx (tczy)
Date: Tue, 2 Feb 2010 18:54:42 +0200
Subject: [hunchentoot-devel] Hunchentoot web page gives error
In-Reply-To: <b56421a01002020813w592b0ca4l3f4c9eb11996e6d4@mail.gmail.com>
References: <20100201113603.GD7956@sidep.ath.cx>
	<b56421a01002010342je9084capd0f37bf2c3a07c2@mail.gmail.com>
	<20100202143731.GA5315@sidep.ath.cx>
	<b56421a01002020813w592b0ca4l3f4c9eb11996e6d4@mail.gmail.com>
Message-ID: <20100202165442.GB5315@sidep.ath.cx>

On Tue, Feb 02, 2010 at 05:13:56PM +0100, Edi Weitz wrote:
> On Tue, Feb 2, 2010 at 3:37 PM, tczy <cy at wre.ath.cx> wrote:
> 
> > Browser:
> > Uzbl (experimental commit, changes a lot), running on
> > WebKitGTK+ 1.1.15.4
> 
> Ugh, well.  I think as long as the website works with the three or
> four major browsers, I'm fine.  Having said that, if there's an actual
> bug in the page (as opposed to in Uzbl), I'll be happy to fix it if
> you send me a patch.
> 
> Thanks for the report, though.
> 
> Edi.

Yeah, I wrote to you first, and only then checked with a major browser.



From hans.huebner at gmail.com  Tue Feb  2 16:58:44 2010
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Tue, 2 Feb 2010 17:58:44 +0100
Subject: [hunchentoot-devel] Hunchentoot web page gives error
In-Reply-To: <20100202165442.GB5315@sidep.ath.cx>
References: <20100201113603.GD7956@sidep.ath.cx>
	<b56421a01002010342je9084capd0f37bf2c3a07c2@mail.gmail.com> 
	<20100202143731.GA5315@sidep.ath.cx>
	<b56421a01002020813w592b0ca4l3f4c9eb11996e6d4@mail.gmail.com> 
	<20100202165442.GB5315@sidep.ath.cx>
Message-ID: <fd2982321002020858v7df4f17aof499d6ca6efac7fd@mail.gmail.com>

Uzbl does not seem to support client-side XSLT.

"Uzbl"

Hans



From fahree at gmail.com  Sat Feb  6 00:24:54 2010
From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=)
Date: Fri, 5 Feb 2010 19:24:54 -0500
Subject: [hunchentoot-devel] after-listen-hook
Message-ID: <653bea161002051624g4f93099fhb96f64360b26655c@mail.gmail.com>

This patch, used at ITA, adds a hook whereby the server can notify
future clients when it ready to listen, without said clients having to
poll and/or introduce a race-condition.

Please consider inclusion of this feature in next release of hunchentoot.

Also, can you export WITHIN-REQUEST-P from the package?

[ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
Resentment is like taking poison and waiting for the other person to die.
        ? Malachy McCourt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: h-299694.diff
Type: text/x-diff
Size: 1168 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20100205/a3414504/attachment.diff>

From fahree at gmail.com  Sat Feb  6 00:20:48 2010
From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=)
Date: Fri, 5 Feb 2010 19:20:48 -0500
Subject: [hunchentoot-devel] Hunchentoot web page gives error
Message-ID: <653bea161002051620u2c8b1dfyd77f638426020a99@mail.gmail.com>

I'm experiencing the same error with Chromium, which is probably not
any client to tell to go to hell.

This page contains the following errors:

error on line 2 at column 3: Char 0x0 out of allowed range
Below is a rendering of the page up to the first error.

Presumably, a lot of WebKit-based browsers will fail with the same
error. Safari anyone?

[ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
For every complex problem, there is a solution that is simple, neat, and wrong.
                ? H. L. Mencken



From neuss at math.uni-karlsruhe.de  Mon Feb  8 11:01:02 2010
From: neuss at math.uni-karlsruhe.de (Nicolas Neuss)
Date: Mon, 08 Feb 2010 12:01:02 +0100
Subject: [hunchentoot-devel] Hunchentoot web page gives error
In-Reply-To: <653bea161002051620u2c8b1dfyd77f638426020a99@mail.gmail.com>
	(=?iso-8859-1?Q?=22Far=E9=22's?= message of "Fri\, 5 Feb 2010 19\:20\:48
	-0500")
References: <653bea161002051620u2c8b1dfyd77f638426020a99@mail.gmail.com>
Message-ID: <87tytsrnyp.fsf@ma-patru.mathematik.uni-karlsruhe.de>

Far? <fahree at gmail.com> writes:

> I'm experiencing the same error with Chromium, which is probably not
> any client to tell to go to hell.
>
> This page contains the following errors:
>
> error on line 2 at column 3: Char 0x0 out of allowed range
> Below is a rendering of the page up to the first error.
>
> Presumably, a lot of WebKit-based browsers will fail with the same
> error. Safari anyone?

<http://www.weitz.de/hunchentoot>?  Works with Safari (4.0.4).

Nicolas



From jackalmage at gmail.com  Mon Feb  8 13:58:26 2010
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Mon, 8 Feb 2010 07:58:26 -0600
Subject: [hunchentoot-devel] Hunchentoot web page gives error
In-Reply-To: <87tytsrnyp.fsf@ma-patru.mathematik.uni-karlsruhe.de>
References: <653bea161002051620u2c8b1dfyd77f638426020a99@mail.gmail.com> 
	<87tytsrnyp.fsf@ma-patru.mathematik.uni-karlsruhe.de>
Message-ID: <dd0fbad1002080558p21d000f9hc42e411c014e63ba@mail.gmail.com>

On Mon, Feb 8, 2010 at 5:01 AM, Nicolas Neuss
<neuss at math.uni-karlsruhe.de> wrote:
> Far? <fahree at gmail.com> writes:
>
>> I'm experiencing the same error with Chromium, which is probably not
>> any client to tell to go to hell.
>>
>> This page contains the following errors:
>>
>> error on line 2 at column 3: Char 0x0 out of allowed range
>> Below is a rendering of the page up to the first error.
>>
>> Presumably, a lot of WebKit-based browsers will fail with the same
>> error. Safari anyone?
>
> <http://www.weitz.de/hunchentoot>? ?Works with Safari (4.0.4).

It's dependent on the encoding.  If you interpret the page as utf-8,
there's an encoding error (except I get it at line 2 column 54).  If
you interpret it as Windows-1252, it displays fine.  Chrome 4.0.279.78
on Windows here.

~TJ



From fahree at gmail.com  Mon Feb  8 15:10:06 2010
From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=)
Date: Mon, 8 Feb 2010 10:10:06 -0500
Subject: [hunchentoot-devel] Hunchentoot web page gives error
In-Reply-To: <dd0fbad1002080558p21d000f9hc42e411c014e63ba@mail.gmail.com>
References: <653bea161002051620u2c8b1dfyd77f638426020a99@mail.gmail.com> 
	<87tytsrnyp.fsf@ma-patru.mathematik.uni-karlsruhe.de>
	<dd0fbad1002080558p21d000f9hc42e411c014e63ba@mail.gmail.com>
Message-ID: <653bea161002080710nfc7bf1drff84f36e57ae0a2a@mail.gmail.com>

On 8 February 2010 08:58, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> On Mon, Feb 8, 2010 at 5:01 AM, Nicolas Neuss
> <neuss at math.uni-karlsruhe.de> wrote:
>> Far? <fahree at gmail.com> writes:
>>
>>> I'm experiencing the same error with Chromium, which is probably not
>>> any client to tell to go to hell.
>>>
>>> This page contains the following errors:
>>>
>>> error on line 2 at column 3: Char 0x0 out of allowed range
>>> Below is a rendering of the page up to the first error.
>>>
>>> Presumably, a lot of WebKit-based browsers will fail with the same
>>> error. Safari anyone?
>>
>> <http://www.weitz.de/hunchentoot>? ?Works with Safari (4.0.4).
>
> It's dependent on the encoding. ?If you interpret the page as utf-8,
> there's an encoding error (except I get it at line 2 column 54). ?If
> you interpret it as Windows-1252, it displays fine. ?Chrome 4.0.279.78
> on Windows here.
>
So is the solution that said hunchentoot page should declare its
encoding in HTTP headers?

[ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
If it's not worth doing right, it's not worth doing. ? Scott McKay



From rm at seid-online.de  Mon Feb  8 15:35:15 2010
From: rm at seid-online.de (Ralf Mattes)
Date: Mon, 08 Feb 2010 16:35:15 +0100
Subject: [hunchentoot-devel] Hunchentoot web page gives error
In-Reply-To: <dd0fbad1002080558p21d000f9hc42e411c014e63ba@mail.gmail.com>
References: <653bea161002051620u2c8b1dfyd77f638426020a99@mail.gmail.com>
	<87tytsrnyp.fsf@ma-patru.mathematik.uni-karlsruhe.de>
	<dd0fbad1002080558p21d000f9hc42e411c014e63ba@mail.gmail.com>
Message-ID: <1265643315.6709.3.camel@mhflaptop01>

On Mon, 2010-02-08 at 07:58 -0600, Tab Atkins Jr. wrote:
> On Mon, Feb 8, 2010 at 5:01 AM, Nicolas Neuss
> <neuss at math.uni-karlsruhe.de> wrote:
> > Far? <fahree at gmail.com> writes:
> >
> >> I'm experiencing the same error with Chromium, which is probably not
> >> any client to tell to go to hell.
> >>
> >> This page contains the following errors:
> >>
> >> error on line 2 at column 3: Char 0x0 out of allowed range
> >> Below is a rendering of the page up to the first error.
> >>
> >> Presumably, a lot of WebKit-based browsers will fail with the same
> >> error. Safari anyone?
> >
> > <http://www.weitz.de/hunchentoot>?  Works with Safari (4.0.4).
> 
> It's dependent on the encoding.  If you interpret the page as utf-8,
> there's an encoding error (except I get it at line 2 column 54). 


Hmm - over here that's how the page source looks:

<?xml version="1.0" encoding="ISO-8859-1"?>
<?xml-stylesheet type="text/xsl" href="clixdoc.xsl" ?>

Decoding this as utf-8 can hardly be blamed on the webserver ....
Oh, header is: 

Date: Mon, 08 Feb 2010 15:30:31 GMT
Server: Apache
Last-Modified: Mon, 11 Jan 2010 12:36:29 GMT
Etag: "2c0102-204d6-47ce2c953ad40"
Accept-Ranges: bytes
Content-Length: 132310
Content-Type: application/xml

200 OK


So, no explicit content-encoding, so default encoding (ISO-8859-1 iirc).

 HTH Ralf Mattes
 
>  If
> you interpret it as Windows-1252, it displays fine.  Chrome 4.0.279.78
> on Windows here.
> 
> ~TJ
> 
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel





From jsc at crispylogics.com  Mon Feb  8 15:59:18 2010
From: jsc at crispylogics.com (Jochen Schmidt)
Date: Mon, 8 Feb 2010 16:59:18 +0100
Subject: [hunchentoot-devel] Hunchentoot web page gives error
In-Reply-To: <653bea161002080710nfc7bf1drff84f36e57ae0a2a@mail.gmail.com>
References: <653bea161002051620u2c8b1dfyd77f638426020a99@mail.gmail.com>
	<87tytsrnyp.fsf@ma-patru.mathematik.uni-karlsruhe.de>
	<dd0fbad1002080558p21d000f9hc42e411c014e63ba@mail.gmail.com>
	<653bea161002080710nfc7bf1drff84f36e57ae0a2a@mail.gmail.com>
Message-ID: <4BCBC16E-FBDB-4D6B-9245-D457E5E2D857@crispylogics.com>


Am 08.02.2010 um 16:10 schrieb Far?:

>> 
>> 
> So is the solution that said hunchentoot page should declare its
> encoding in HTTP headers?

HTTP 1.1 defaults to ISO-8859-1 if no encoding is given within the headers.

The best solution for you is not to setup your browser to default to UTF-8 when there is no information on encoding because wishful thinking just doesn't work in the wilderness of the modern web ;-). Alternatively you can always scratch your head when you encounter encoding errors like this.

ciao,
Jochen


-- 
Jochen Schmidt 
CRISPYLOGICS
Uhlandstr. 9, 90408 Nuremberg

Fon +49 (0)911 517 999 82
Fax +49 (0)911 517 999 83

mailto:(format nil "~(~36r@~36r.~36r~)" 870180 1680085828711918828 16438) http://www.crispylogics.com




From edi at agharta.de  Mon Feb  8 20:15:09 2010
From: edi at agharta.de (Edi Weitz)
Date: Mon, 8 Feb 2010 21:15:09 +0100
Subject: [hunchentoot-devel] after-listen-hook
In-Reply-To: <653bea161002051624g4f93099fhb96f64360b26655c@mail.gmail.com>
References: <653bea161002051624g4f93099fhb96f64360b26655c@mail.gmail.com>
Message-ID: <b56421a01002081215q324709f4m649ab5d7eef0bd00@mail.gmail.com>

On Sat, Feb 6, 2010 at 1:24 AM, Far? <fahree at gmail.com> wrote:
> This patch, used at ITA, adds a hook whereby the server can notify
> future clients when it ready to listen, without said clients having to
> poll and/or introduce a race-condition.
>
> Please consider inclusion of this feature in next release of hunchentoot.

Thanks, but I don't think this is terribly useful.  If you want that,
you can simply use a :before method for execute-acceptor.

> Also, can you export WITHIN-REQUEST-P from the package?

Yep, thanks for the heads-up.  It's in the dev version now.

Cheers,
Edi.



From matt.lamari at gmail.com  Wed Feb 10 22:29:07 2010
From: matt.lamari at gmail.com (Matt Lamari)
Date: Wed, 10 Feb 2010 16:29:07 -0600
Subject: [hunchentoot-devel] Terminal problem when writing to binary request
 thread on LW32/Win32, under load
Message-ID: <4B733333.9050004@gmail.com>


This is part of a wider effort, to isolate a problem I've been having
with my main app.

I have written a standalone LW deliverable, all in one directory (with
the libs used in subdirectories).  It builds to an .EXE in LW5.1 or LW6
(2 batch files).

I can't get the  same feedback running in the IDE, except for the leaks.

I am posting here to get assistance in converging on the solution.  The
problem I'm hitting may be in libraries, my usage of them, or lispworks
itself (the problem in my wider app seems to trigger
garbage-collector-level problems).

The load tester is http://openwebload.sourceforge.net/  <-- I can get
the problem to repeat with 1 connection or 100, default settings,
against the dispatcher I listed below.

It is my understanding that there are 2 ways for a Hunchentoot request
handlers to emit data - returning a string, or by calling (send-headers)
then writing to the returned stream.

I have a bare-bones hunchentoot server that returns a page that is 100x
the letter A.
If I make it return the 100x A string, it will run indefinitely, and
work fine.
If I make it write binary 65 100 times with force-output, it grenades.

Against a browser, BOTH WORK FINE.

Against the load tester, the stream-write version leaks badly (even with
the log turned off), spits a lot of errors, and eventually fails.  The
string version can run indefinitely, without errors or leaks.

Obviously the load tester is disconnecting.  But the important point is
that it's exposing some scenario that is possible.

Also, the failures I get in my main app have seemed to happen at the
garbage collector level (a dump will be included below)

I don't want to sweep this under the rug by accumulating a string, it
may be highlighting a more serious problem in something more fundamental.

Here is the hunchentoot dispatcher:  The "return 100 As string" is
there, commented out.  Force-output on each byte is there to
aggressively push the problem.  Again let me state - this code works
when interacting with a browser.  And I expect an exception when the
receiver disappears, just not one this critical.


(setq *dispatch-table*
          (append
           (list
            (create-prefix-dispatcher
             "/"
             (lambda (&rest rest)
               #| (make-string 100 :initial-element #\A) |#
               (let ((stream (send-headers)))
                 (loop for i from 1 to 100 do (progn (write-byte 65
stream) (force-output stream))))
               (force-output stream)
               nil)))
           (list #'default-dispatcher)))

This whole directory is self-contained and made of only the most minimal
code (this is most of it) and the ASDF-loads.  It includes a batch file
that can build for LW5 and for LW6.  I can hand it off to any interested
party.  If security is a concern, this core dispatch table is easily
transplantable into anyone's working Hunchentoot environment. . . . 
Note the references to "CFO" and "MARK-GENERATION".

I can provide the self-contained test project as a zipfile to anyone who
wants it.


Here is a sample error:

*** EXCEPTION DATA ***
code c0000005  flags 00000000 address 2015C250
EIP 2015c250  ESP 032fe62c  EBP 032fe644 ESI 0000002e  EDI 20bbfff2
EAX 00000140  EBX 0e84f0c1  ECX 0000007f EDX 00000100
stack dump:
032fe62c: 08048020 00001486 28b7bb52 28b7bb42
032fe63c: 00002e5e 00000480 032fe67c 204f61e3
032fe64c: 20b33b2d 20250d9b 20250d9b 20250d9b
032fe65c: 20250d9b 20250d9b 20250d9b 20250d9b
032fe66c: 20250d9b 00000c86 032fe684 2021142e
032fe67c: 032fe69c 20463860 08048020 20b33b2d
032fe68c: 20b33b1b 20746573 20b33b2d 20250d9b
032fe69c: 032fe6d8 20463c1d 20b33b1b ffffff96
032fe6ac: 032fe7d4 032fe6d8 20463c73 00000036
032fe6bc: 00000000 20b33b2d 20004003 2014bd33
032fe6cc: 20250d9b 200caac7 20b33b1b 032fe700
032fe6dc: 2046300c 00000084 200caac7 032fe70c
032fe6ec: 200caac7 200caac7 200caac7 200caac7
032fe6fc: 200caac7 032fe71c 207a8b92 20b33b1b
032fe70c: 00000100 00000056 032fe734 200caac7
032fe71c: 032fe72c 204e9f2e 20b33b1b 20b33b1b
reentrypoint 200705e2
<**> Return address not inside a CFO : 20809a13 at 2efe78c
;>>>>> dumping   2efe70c  [16] limit 2eff000
;>  2efe70c:       100 200a3b07  2efe71c 20740488
;>  2efe71c:   2efe728 204e5469 200a3b07  2efe740
;>  2efe72c:  204eb9bb       84 fffffff6  2efe810
;>  2efe73c:  200a3b07  2efe774 204e5622 201fc5c3
;>  2efe74c:  ffffff96  2efe7fc  2efe774 204e5639
;>  2efe75c:        36 201fc5c3 20628823 200a3b07
;>  2efe76c:  200a3b07 200a3ac3  2efe7a0 204aff5a
;>  2efe77c:         4 ffffff96 20b38561 201fc5c3
;>  2efe78c:  20809a13 20b385fd       30     3000
;>  2efe79c:        30  2efe7b8 204ab1b6        0
;>  2efe7ac:  20b381da 20b28f03 20a0fb2f  2efe7d4
;>  2efe7bc:  2073e8fe 20b28f03 20591a0b 206578f7
;>  2efe7cc:   2efe7f1 206e89c7  2efe944 204af6ab
;>  2efe7dc:        1c 20b28f03 90ff8096 20155383
;>  2efe7ec:        56 90ff8096 208098fb  2efe7e5
;>  2efe7fc:  ffffff96  2efe9b4  2efe944 204af738
Simple backtrace:
04ABFD30 20005170 #<Callable 2000511A>
     >>> Actually called : MARK-GENERATION
04ABFD3C 2000FACC #<Callable 2000FA1A>
04ABFD54 2006B742 #<Callable 2006B422>
04ABFD78 200343DA #<Callable 2003436A>
04ABFD98 20034926 #<Callable 2003487A>
033FE384 200345D6 #<Callable 200344A2>
     >>> Actually called : I-FULL-ALLOC-BLOCK-LOCAL
033FE394 20040EAE #<Callable 20040E8A>
     >>> Actually called : ALLOC-OBJECT
033FE3B8 2018BD98 "ALLOC-STRING"
     >>> Actually called : MAKE-BASE-STRING
033FE3D0 201AE864 "IN-MAKE-TYPED-STRING"
033FE3F8 201AEC11 "MAKE-TYPED-STRING"
033FE410 207E82E3 "MAKE-STREAM-BLOCK"
033FE430 207F27F5 "ADD-NEW-BLOCK"
033FE4BC 207F200D "(METHOD STREAM-FLUSH-BUFFER STRING-OUTPUT-STREAM .  NIL)"
     >>> Actually called : STREAM-FLUSH-BUFFER
033FE4EC 20173123 "(METHOD STREAM-WRITE-STRING (BUFFERED-STREAM T))"
033FE518 207556D9 #<Callable 20755622>
     >>> Actually called : STREAM-WRITE-STRING
033FE540 20176744 "WRITE-STRING*"
033FE56C 20126821 "SUB-FORMAT"
033FE5B4 20125E72 "CALL-SUB-FORMAT"
033FE5D0 2084FE08 "FORMAT"
033FE674 204B0CE4 "SAFER-FORMAT"
033FE780 204B04CD "(METHOD DBG-PRINT-FRAME BINDING-FRAME .  NIL)"
033FE7A8 2073E8FE #<Callable 2073E872>
     >>> Actually called : DBG-PRINT-FRAME
033FE7D4 204AF6AB "BUG-BACKTRACE"
033FE944 2044C5FA "PRINT-BACKTRACE-TO-STREAM"
033FE9AC 208243D0 "GET-BACKTRACE"
033FEA9C 20403292 "(METHOD HANDLE-REQUEST (ACCEPTOR REQUEST))"
033FEAB4 204BACC0 "SIGNAL"
033FEAF4 204CB948 "CONDITIONS-ERROR"
033FEB38 201EA995 "ERROR"
     >>> Actually called : SOCKET-ERROR
033FEB48 2043F73B "(METHOD STREAM-WRITE-BUFFER (SOCKET-STREAM T T T))"
     >>> Actually called : STREAM-WRITE-BUFFER
033FEB6C 20173AE9 "(METHOD STREAM-FLUSH-BUFFER BUFFERED-STREAM .  NIL)"
     >>> Actually called : STREAM-FLUSH-BUFFER
033FEB88 20173A11 "(METHOD STREAM-FORCE-OUTPUT BUFFERED-STREAM .  NIL)"
     >>> Actually called : FORCE-OUTPUT
033FEB94 207F21B5 "MAIN"
033FEBA8 2054562E "(METHOD HANDLE-REQUEST (ACCEPTOR REQUEST))"
033FEC70 2084A559 "(METHOD PROCESS-REQUEST T .  NIL)"
033FED08 20409679 "(METHOD PROCESS-CONNECTION (ACCEPTOR T))"
033FEDBC 20566DF9 "NEXT-METHOD-CALL-2"
033FEDDC 204F7F37 "(METHOD PROCESS-CONNECTION AROUND (ACCEPTOR T))"
033FEE88 2076DE2E #<Callable 2076DDEA>
033FEEA8 2083B4A7 "PROCESS-SG-FUNCTION"
033FEFBC 204896A2 #<Callable 2048967A>
033FEFD0 20887C6B "(DEFINE-FOREIGN-CALLABLE NIL) . 
%FOREIGN-CALLABLE/thread_initial_function"






From matt.lamari at gmail.com  Thu Feb 11 00:34:07 2010
From: matt.lamari at gmail.com (Matt Lamari)
Date: Wed, 10 Feb 2010 18:34:07 -0600
Subject: [hunchentoot-devel] Terminal problem when writing to binary
 request thread on LW32/Win32, under load
In-Reply-To: <4B733333.9050004@gmail.com>
References: <4B733333.9050004@gmail.com>
Message-ID: <4B73507F.5090203@gmail.com>


I should probably be more clear - The program goes haywire when I force
or finalize-output to this stream.  I acknowledge that, here, I should
not do that, and I don't do so on my main web app.

However, doing so seems to send the whole environment "off the rails" in
a manner similar to what happens to the main app, and I was hoping that
someone with more knowledge of what's under the API  could tell whether
or not this sort of failure should be contained, or what's going on when
this type of failure occurs.

Any help appreciated.  I realize I may not have a hunchentoot problem;
but that someone who knowns hunchentoot may be able to point me in the
right direction.

Cheers,
Matt


Matt Lamari wrote:
> This is part of a wider effort, to isolate a problem I've been having
> with my main app.
>
> I have written a standalone LW deliverable, all in one directory (with
> the libs used in subdirectories).  It builds to an .EXE in LW5.1 or LW6
> (2 batch files).
>
> I can't get the  same feedback running in the IDE, except for the leaks.
>
> I am posting here to get assistance in converging on the solution.  The
> problem I'm hitting may be in libraries, my usage of them, or lispworks
> itself (the problem in my wider app seems to trigger
> garbage-collector-level problems).
>
> The load tester is http://openwebload.sourceforge.net/  <-- I can get
> the problem to repeat with 1 connection or 100, default settings,
> against the dispatcher I listed below.
>
> It is my understanding that there are 2 ways for a Hunchentoot request
> handlers to emit data - returning a string, or by calling (send-headers)
> then writing to the returned stream.
>
> I have a bare-bones hunchentoot server that returns a page that is 100x
> the letter A.
> If I make it return the 100x A string, it will run indefinitely, and
> work fine.
> If I make it write binary 65 100 times with force-output, it grenades.
>
> Against a browser, BOTH WORK FINE.
>
> Against the load tester, the stream-write version leaks badly (even with
> the log turned off), spits a lot of errors, and eventually fails.  The
> string version can run indefinitely, without errors or leaks.
>
> Obviously the load tester is disconnecting.  But the important point is
> that it's exposing some scenario that is possible.
>
> Also, the failures I get in my main app have seemed to happen at the
> garbage collector level (a dump will be included below)
>
> I don't want to sweep this under the rug by accumulating a string, it
> may be highlighting a more serious problem in something more fundamental.
>
> Here is the hunchentoot dispatcher:  The "return 100 As string" is
> there, commented out.  Force-output on each byte is there to
> aggressively push the problem.  Again let me state - this code works
> when interacting with a browser.  And I expect an exception when the
> receiver disappears, just not one this critical.
>
>
> (setq *dispatch-table*
>           (append
>            (list
>             (create-prefix-dispatcher
>              "/"
>              (lambda (&rest rest)
>                #| (make-string 100 :initial-element #\A) |#
>                (let ((stream (send-headers)))
>                  (loop for i from 1 to 100 do (progn (write-byte 65
> stream) (force-output stream))))
>                (force-output stream)
>                nil)))
>            (list #'default-dispatcher)))
>
> This whole directory is self-contained and made of only the most minimal
> code (this is most of it) and the ASDF-loads.  It includes a batch file
> that can build for LW5 and for LW6.  I can hand it off to any interested
> party.  If security is a concern, this core dispatch table is easily
> transplantable into anyone's working Hunchentoot environment. . . . 
> Note the references to "CFO" and "MARK-GENERATION".
>
> I can provide the self-contained test project as a zipfile to anyone who
> wants it.
>
>
> Here is a sample error:
>
> *** EXCEPTION DATA ***
> code c0000005  flags 00000000 address 2015C250
> EIP 2015c250  ESP 032fe62c  EBP 032fe644 ESI 0000002e  EDI 20bbfff2
> EAX 00000140  EBX 0e84f0c1  ECX 0000007f EDX 00000100
> stack dump:
> 032fe62c: 08048020 00001486 28b7bb52 28b7bb42
> 032fe63c: 00002e5e 00000480 032fe67c 204f61e3
> 032fe64c: 20b33b2d 20250d9b 20250d9b 20250d9b
> 032fe65c: 20250d9b 20250d9b 20250d9b 20250d9b
> 032fe66c: 20250d9b 00000c86 032fe684 2021142e
> 032fe67c: 032fe69c 20463860 08048020 20b33b2d
> 032fe68c: 20b33b1b 20746573 20b33b2d 20250d9b
> 032fe69c: 032fe6d8 20463c1d 20b33b1b ffffff96
> 032fe6ac: 032fe7d4 032fe6d8 20463c73 00000036
> 032fe6bc: 00000000 20b33b2d 20004003 2014bd33
> 032fe6cc: 20250d9b 200caac7 20b33b1b 032fe700
> 032fe6dc: 2046300c 00000084 200caac7 032fe70c
> 032fe6ec: 200caac7 200caac7 200caac7 200caac7
> 032fe6fc: 200caac7 032fe71c 207a8b92 20b33b1b
> 032fe70c: 00000100 00000056 032fe734 200caac7
> 032fe71c: 032fe72c 204e9f2e 20b33b1b 20b33b1b
> reentrypoint 200705e2
> <**> Return address not inside a CFO : 20809a13 at 2efe78c
> ;>>>>> dumping   2efe70c  [16] limit 2eff000
> ;>  2efe70c:       100 200a3b07  2efe71c 20740488
> ;>  2efe71c:   2efe728 204e5469 200a3b07  2efe740
> ;>  2efe72c:  204eb9bb       84 fffffff6  2efe810
> ;>  2efe73c:  200a3b07  2efe774 204e5622 201fc5c3
> ;>  2efe74c:  ffffff96  2efe7fc  2efe774 204e5639
> ;>  2efe75c:        36 201fc5c3 20628823 200a3b07
> ;>  2efe76c:  200a3b07 200a3ac3  2efe7a0 204aff5a
> ;>  2efe77c:         4 ffffff96 20b38561 201fc5c3
> ;>  2efe78c:  20809a13 20b385fd       30     3000
> ;>  2efe79c:        30  2efe7b8 204ab1b6        0
> ;>  2efe7ac:  20b381da 20b28f03 20a0fb2f  2efe7d4
> ;>  2efe7bc:  2073e8fe 20b28f03 20591a0b 206578f7
> ;>  2efe7cc:   2efe7f1 206e89c7  2efe944 204af6ab
> ;>  2efe7dc:        1c 20b28f03 90ff8096 20155383
> ;>  2efe7ec:        56 90ff8096 208098fb  2efe7e5
> ;>  2efe7fc:  ffffff96  2efe9b4  2efe944 204af738
> Simple backtrace:
> 04ABFD30 20005170 #<Callable 2000511A>
>      >>> Actually called : MARK-GENERATION
> 04ABFD3C 2000FACC #<Callable 2000FA1A>
> 04ABFD54 2006B742 #<Callable 2006B422>
> 04ABFD78 200343DA #<Callable 2003436A>
> 04ABFD98 20034926 #<Callable 2003487A>
> 033FE384 200345D6 #<Callable 200344A2>
>      >>> Actually called : I-FULL-ALLOC-BLOCK-LOCAL
> 033FE394 20040EAE #<Callable 20040E8A>
>      >>> Actually called : ALLOC-OBJECT
> 033FE3B8 2018BD98 "ALLOC-STRING"
>      >>> Actually called : MAKE-BASE-STRING
> 033FE3D0 201AE864 "IN-MAKE-TYPED-STRING"
> 033FE3F8 201AEC11 "MAKE-TYPED-STRING"
> 033FE410 207E82E3 "MAKE-STREAM-BLOCK"
> 033FE430 207F27F5 "ADD-NEW-BLOCK"
> 033FE4BC 207F200D "(METHOD STREAM-FLUSH-BUFFER STRING-OUTPUT-STREAM .  NIL)"
>      >>> Actually called : STREAM-FLUSH-BUFFER
> 033FE4EC 20173123 "(METHOD STREAM-WRITE-STRING (BUFFERED-STREAM T))"
> 033FE518 207556D9 #<Callable 20755622>
>      >>> Actually called : STREAM-WRITE-STRING
> 033FE540 20176744 "WRITE-STRING*"
> 033FE56C 20126821 "SUB-FORMAT"
> 033FE5B4 20125E72 "CALL-SUB-FORMAT"
> 033FE5D0 2084FE08 "FORMAT"
> 033FE674 204B0CE4 "SAFER-FORMAT"
> 033FE780 204B04CD "(METHOD DBG-PRINT-FRAME BINDING-FRAME .  NIL)"
> 033FE7A8 2073E8FE #<Callable 2073E872>
>      >>> Actually called : DBG-PRINT-FRAME
> 033FE7D4 204AF6AB "BUG-BACKTRACE"
> 033FE944 2044C5FA "PRINT-BACKTRACE-TO-STREAM"
> 033FE9AC 208243D0 "GET-BACKTRACE"
> 033FEA9C 20403292 "(METHOD HANDLE-REQUEST (ACCEPTOR REQUEST))"
> 033FEAB4 204BACC0 "SIGNAL"
> 033FEAF4 204CB948 "CONDITIONS-ERROR"
> 033FEB38 201EA995 "ERROR"
>      >>> Actually called : SOCKET-ERROR
> 033FEB48 2043F73B "(METHOD STREAM-WRITE-BUFFER (SOCKET-STREAM T T T))"
>      >>> Actually called : STREAM-WRITE-BUFFER
> 033FEB6C 20173AE9 "(METHOD STREAM-FLUSH-BUFFER BUFFERED-STREAM .  NIL)"
>      >>> Actually called : STREAM-FLUSH-BUFFER
> 033FEB88 20173A11 "(METHOD STREAM-FORCE-OUTPUT BUFFERED-STREAM .  NIL)"
>      >>> Actually called : FORCE-OUTPUT
> 033FEB94 207F21B5 "MAIN"
> 033FEBA8 2054562E "(METHOD HANDLE-REQUEST (ACCEPTOR REQUEST))"
> 033FEC70 2084A559 "(METHOD PROCESS-REQUEST T .  NIL)"
> 033FED08 20409679 "(METHOD PROCESS-CONNECTION (ACCEPTOR T))"
> 033FEDBC 20566DF9 "NEXT-METHOD-CALL-2"
> 033FEDDC 204F7F37 "(METHOD PROCESS-CONNECTION AROUND (ACCEPTOR T))"
> 033FEE88 2076DE2E #<Callable 2076DDEA>
> 033FEEA8 2083B4A7 "PROCESS-SG-FUNCTION"
> 033FEFBC 204896A2 #<Callable 2048967A>
> 033FEFD0 20887C6B "(DEFINE-FOREIGN-CALLABLE NIL) . 
> %FOREIGN-CALLABLE/thread_initial_function"
>
>
>
>   




From matt.lamari at gmail.com  Thu Feb 11 06:23:39 2010
From: matt.lamari at gmail.com (Matt Lamari)
Date: Thu, 11 Feb 2010 00:23:39 -0600
Subject: [hunchentoot-devel] A simple repeatable leak case,
 LW32 : Re: Terminal problem when writing to binary request thread
 on LW32/Win32, under load
In-Reply-To: <4B73507F.5090203@gmail.com>
References: <4B733333.9050004@gmail.com> <4B73507F.5090203@gmail.com>
Message-ID: <4B73A26B.2080303@gmail.com>


This leaks (and eventually something bad happens).

I realize that the leadtester may be abusing it; but I'd like to assume
the worst coming from the net.  Closing the load tester does not
alleviate the problem.

Note - I've got Linux/SBCL guys telling me this works fine on their
platforms, without leaks.

Lispworks 5.1 and Lispworks 6
Hunchentoot, latest supporting libs
Win32  (I run on Vista 64)


Minimalist dispatch table: (works the same in the IDE AND in the
delivered app)

(setf hunchentoot::*session-max-time* 10) ;remove this as a variable
(setq *dispatch-table*
          (append
           (list
            (create-prefix-dispatcher
             "/"
             (lambda (&rest rest)
               (let ((stream (send-headers)))
                 (loop for i from 1 to 10000 do (write-byte 65 stream)))
               nil)))
           (list #'default-dispatcher)))

Load tester:  (Note - on Win32 this is a single executable, just drop it
somewhere and run it)

http://openwebload.sourceforge.net/ 

Command line:

openload.exe http://localhost 100


Eventually, it eats up ram and at about 600 meg memory errors start
coming forth (in the delivered EXE).

I acknowledge this may be something more fundamental with the platform. 
But I wanted to make sure that I'm using hunchentoot properly, and if
hunchentoot has anything that would help me narrow down what is happening.

Thank you for your time,
Matt


Matt Lamari wrote:
> I should probably be more clear - The program goes haywire when I force
> or finalize-output to this stream.  I acknowledge that, here, I should
> not do that, and I don't do so on my main web app.
>
> However, doing so seems to send the whole environment "off the rails" in
> a manner similar to what happens to the main app, and I was hoping that
> someone with more knowledge of what's under the API  could tell whether
> or not this sort of failure should be contained, or what's going on when
> this type of failure occurs.
>
> Any help appreciated.  I realize I may not have a hunchentoot problem;
> but that someone who knowns hunchentoot may be able to point me in the
> right direction.
>
> Cheers,
> Matt
>
>
> Matt Lamari wrote:
>   
>> This is part of a wider effort, to isolate a problem I've been having
>> with my main app.
>>
>> I have written a standalone LW deliverable, all in one directory (with
>> the libs used in subdirectories).  It builds to an .EXE in LW5.1 or LW6
>> (2 batch files).
>>
>> I can't get the  same feedback running in the IDE, except for the leaks.
>>
>> I am posting here to get assistance in converging on the solution.  The
>> problem I'm hitting may be in libraries, my usage of them, or lispworks
>> itself (the problem in my wider app seems to trigger
>> garbage-collector-level problems).
>>
>> The load tester is http://openwebload.sourceforge.net/  <-- I can get
>> the problem to repeat with 1 connection or 100, default settings,
>> against the dispatcher I listed below.
>>
>> It is my understanding that there are 2 ways for a Hunchentoot request
>> handlers to emit data - returning a string, or by calling (send-headers)
>> then writing to the returned stream.
>>
>> I have a bare-bones hunchentoot server that returns a page that is 100x
>> the letter A.
>> If I make it return the 100x A string, it will run indefinitely, and
>> work fine.
>> If I make it write binary 65 100 times with force-output, it grenades.
>>
>> Against a browser, BOTH WORK FINE.
>>
>> Against the load tester, the stream-write version leaks badly (even with
>> the log turned off), spits a lot of errors, and eventually fails.  The
>> string version can run indefinitely, without errors or leaks.
>>
>> Obviously the load tester is disconnecting.  But the important point is
>> that it's exposing some scenario that is possible.
>>
>> Also, the failures I get in my main app have seemed to happen at the
>> garbage collector level (a dump will be included below)
>>
>> I don't want to sweep this under the rug by accumulating a string, it
>> may be highlighting a more serious problem in something more fundamental.
>>
>> Here is the hunchentoot dispatcher:  The "return 100 As string" is
>> there, commented out.  Force-output on each byte is there to
>> aggressively push the problem.  Again let me state - this code works
>> when interacting with a browser.  And I expect an exception when the
>> receiver disappears, just not one this critical.
>>
>>
>> (setq *dispatch-table*
>>           (append
>>            (list
>>             (create-prefix-dispatcher
>>              "/"
>>              (lambda (&rest rest)
>>                #| (make-string 100 :initial-element #\A) |#
>>                (let ((stream (send-headers)))
>>                  (loop for i from 1 to 100 do (progn (write-byte 65
>> stream) (force-output stream))))
>>                (force-output stream)
>>                nil)))
>>            (list #'default-dispatcher)))
>>
>> This whole directory is self-contained and made of only the most minimal
>> code (this is most of it) and the ASDF-loads.  It includes a batch file
>> that can build for LW5 and for LW6.  I can hand it off to any interested
>> party.  If security is a concern, this core dispatch table is easily
>> transplantable into anyone's working Hunchentoot environment. . . . 
>> Note the references to "CFO" and "MARK-GENERATION".
>>
>> I can provide the self-contained test project as a zipfile to anyone who
>> wants it.
>>
>>
>> Here is a sample error:
>>
>> *** EXCEPTION DATA ***
>> code c0000005  flags 00000000 address 2015C250
>> EIP 2015c250  ESP 032fe62c  EBP 032fe644 ESI 0000002e  EDI 20bbfff2
>> EAX 00000140  EBX 0e84f0c1  ECX 0000007f EDX 00000100
>> stack dump:
>> 032fe62c: 08048020 00001486 28b7bb52 28b7bb42
>> 032fe63c: 00002e5e 00000480 032fe67c 204f61e3
>> 032fe64c: 20b33b2d 20250d9b 20250d9b 20250d9b
>> 032fe65c: 20250d9b 20250d9b 20250d9b 20250d9b
>> 032fe66c: 20250d9b 00000c86 032fe684 2021142e
>> 032fe67c: 032fe69c 20463860 08048020 20b33b2d
>> 032fe68c: 20b33b1b 20746573 20b33b2d 20250d9b
>> 032fe69c: 032fe6d8 20463c1d 20b33b1b ffffff96
>> 032fe6ac: 032fe7d4 032fe6d8 20463c73 00000036
>> 032fe6bc: 00000000 20b33b2d 20004003 2014bd33
>> 032fe6cc: 20250d9b 200caac7 20b33b1b 032fe700
>> 032fe6dc: 2046300c 00000084 200caac7 032fe70c
>> 032fe6ec: 200caac7 200caac7 200caac7 200caac7
>> 032fe6fc: 200caac7 032fe71c 207a8b92 20b33b1b
>> 032fe70c: 00000100 00000056 032fe734 200caac7
>> 032fe71c: 032fe72c 204e9f2e 20b33b1b 20b33b1b
>> reentrypoint 200705e2
>> <**> Return address not inside a CFO : 20809a13 at 2efe78c
>> ;>>>>> dumping   2efe70c  [16] limit 2eff000
>> ;>  2efe70c:       100 200a3b07  2efe71c 20740488
>> ;>  2efe71c:   2efe728 204e5469 200a3b07  2efe740
>> ;>  2efe72c:  204eb9bb       84 fffffff6  2efe810
>> ;>  2efe73c:  200a3b07  2efe774 204e5622 201fc5c3
>> ;>  2efe74c:  ffffff96  2efe7fc  2efe774 204e5639
>> ;>  2efe75c:        36 201fc5c3 20628823 200a3b07
>> ;>  2efe76c:  200a3b07 200a3ac3  2efe7a0 204aff5a
>> ;>  2efe77c:         4 ffffff96 20b38561 201fc5c3
>> ;>  2efe78c:  20809a13 20b385fd       30     3000
>> ;>  2efe79c:        30  2efe7b8 204ab1b6        0
>> ;>  2efe7ac:  20b381da 20b28f03 20a0fb2f  2efe7d4
>> ;>  2efe7bc:  2073e8fe 20b28f03 20591a0b 206578f7
>> ;>  2efe7cc:   2efe7f1 206e89c7  2efe944 204af6ab
>> ;>  2efe7dc:        1c 20b28f03 90ff8096 20155383
>> ;>  2efe7ec:        56 90ff8096 208098fb  2efe7e5
>> ;>  2efe7fc:  ffffff96  2efe9b4  2efe944 204af738
>> Simple backtrace:
>> 04ABFD30 20005170 #<Callable 2000511A>
>>      >>> Actually called : MARK-GENERATION
>> 04ABFD3C 2000FACC #<Callable 2000FA1A>
>> 04ABFD54 2006B742 #<Callable 2006B422>
>> 04ABFD78 200343DA #<Callable 2003436A>
>> 04ABFD98 20034926 #<Callable 2003487A>
>> 033FE384 200345D6 #<Callable 200344A2>
>>      >>> Actually called : I-FULL-ALLOC-BLOCK-LOCAL
>> 033FE394 20040EAE #<Callable 20040E8A>
>>      >>> Actually called : ALLOC-OBJECT
>> 033FE3B8 2018BD98 "ALLOC-STRING"
>>      >>> Actually called : MAKE-BASE-STRING
>> 033FE3D0 201AE864 "IN-MAKE-TYPED-STRING"
>> 033FE3F8 201AEC11 "MAKE-TYPED-STRING"
>> 033FE410 207E82E3 "MAKE-STREAM-BLOCK"
>> 033FE430 207F27F5 "ADD-NEW-BLOCK"
>> 033FE4BC 207F200D "(METHOD STREAM-FLUSH-BUFFER STRING-OUTPUT-STREAM .  NIL)"
>>      >>> Actually called : STREAM-FLUSH-BUFFER
>> 033FE4EC 20173123 "(METHOD STREAM-WRITE-STRING (BUFFERED-STREAM T))"
>> 033FE518 207556D9 #<Callable 20755622>
>>      >>> Actually called : STREAM-WRITE-STRING
>> 033FE540 20176744 "WRITE-STRING*"
>> 033FE56C 20126821 "SUB-FORMAT"
>> 033FE5B4 20125E72 "CALL-SUB-FORMAT"
>> 033FE5D0 2084FE08 "FORMAT"
>> 033FE674 204B0CE4 "SAFER-FORMAT"
>> 033FE780 204B04CD "(METHOD DBG-PRINT-FRAME BINDING-FRAME .  NIL)"
>> 033FE7A8 2073E8FE #<Callable 2073E872>
>>      >>> Actually called : DBG-PRINT-FRAME
>> 033FE7D4 204AF6AB "BUG-BACKTRACE"
>> 033FE944 2044C5FA "PRINT-BACKTRACE-TO-STREAM"
>> 033FE9AC 208243D0 "GET-BACKTRACE"
>> 033FEA9C 20403292 "(METHOD HANDLE-REQUEST (ACCEPTOR REQUEST))"
>> 033FEAB4 204BACC0 "SIGNAL"
>> 033FEAF4 204CB948 "CONDITIONS-ERROR"
>> 033FEB38 201EA995 "ERROR"
>>      >>> Actually called : SOCKET-ERROR
>> 033FEB48 2043F73B "(METHOD STREAM-WRITE-BUFFER (SOCKET-STREAM T T T))"
>>      >>> Actually called : STREAM-WRITE-BUFFER
>> 033FEB6C 20173AE9 "(METHOD STREAM-FLUSH-BUFFER BUFFERED-STREAM .  NIL)"
>>      >>> Actually called : STREAM-FLUSH-BUFFER
>> 033FEB88 20173A11 "(METHOD STREAM-FORCE-OUTPUT BUFFERED-STREAM .  NIL)"
>>      >>> Actually called : FORCE-OUTPUT
>> 033FEB94 207F21B5 "MAIN"
>> 033FEBA8 2054562E "(METHOD HANDLE-REQUEST (ACCEPTOR REQUEST))"
>> 033FEC70 2084A559 "(METHOD PROCESS-REQUEST T .  NIL)"
>> 033FED08 20409679 "(METHOD PROCESS-CONNECTION (ACCEPTOR T))"
>> 033FEDBC 20566DF9 "NEXT-METHOD-CALL-2"
>> 033FEDDC 204F7F37 "(METHOD PROCESS-CONNECTION AROUND (ACCEPTOR T))"
>> 033FEE88 2076DE2E #<Callable 2076DDEA>
>> 033FEEA8 2083B4A7 "PROCESS-SG-FUNCTION"
>> 033FEFBC 204896A2 #<Callable 2048967A>
>> 033FEFD0 20887C6B "(DEFINE-FOREIGN-CALLABLE NIL) . 
>> %FOREIGN-CALLABLE/thread_initial_function"
>>
>>
>>
>>   
>>     
>
>   




From edi at agharta.de  Thu Feb 11 06:55:28 2010
From: edi at agharta.de (Edi Weitz)
Date: Thu, 11 Feb 2010 07:55:28 +0100
Subject: [hunchentoot-devel] A simple repeatable leak case,
	LW32 : Re: Terminal problem when writing to binary request thread
	on LW32/Win32, under 	load
In-Reply-To: <4B73A26B.2080303@gmail.com>
References: <4B733333.9050004@gmail.com> <4B73507F.5090203@gmail.com>
	<4B73A26B.2080303@gmail.com>
Message-ID: <b56421a01002102255r676ef8ebic13a2c7e93e632ac@mail.gmail.com>

Matt,

The symptoms are the same on LW6 and LW5.1?  If the test case is
self-contained, I'd suggest to send it to LW support; I'm pretty sure
they'd be interested to see it.  No matter what you're doing (and I
only thought about it for a few seconds), the dump you included looks
like one of those thing that should not happen...

Thanks,
Edi.

PS: BTW, do you have backtraces enabled in your Hunchentoot?  And if
so, can you reproduce the problem with them turned off?



On Thu, Feb 11, 2010 at 7:23 AM, Matt Lamari <matt.lamari at gmail.com> wrote:
>
> This leaks (and eventually something bad happens).
>
> I realize that the leadtester may be abusing it; but I'd like to assume
> the worst coming from the net. ?Closing the load tester does not
> alleviate the problem.
>
> Note - I've got Linux/SBCL guys telling me this works fine on their
> platforms, without leaks.
>
> Lispworks 5.1 and Lispworks 6
> Hunchentoot, latest supporting libs
> Win32 ?(I run on Vista 64)
>
>
> Minimalist dispatch table: (works the same in the IDE AND in the
> delivered app)
>
> (setf hunchentoot::*session-max-time* 10) ;remove this as a variable
> (setq *dispatch-table*
> ? ? ? ? ?(append
> ? ? ? ? ? (list
> ? ? ? ? ? ?(create-prefix-dispatcher
> ? ? ? ? ? ? "/"
> ? ? ? ? ? ? (lambda (&rest rest)
> ? ? ? ? ? ? ? (let ((stream (send-headers)))
> ? ? ? ? ? ? ? ? (loop for i from 1 to 10000 do (write-byte 65 stream)))
> ? ? ? ? ? ? ? nil)))
> ? ? ? ? ? (list #'default-dispatcher)))
>
> Load tester: ?(Note - on Win32 this is a single executable, just drop it
> somewhere and run it)
>
> http://openwebload.sourceforge.net/
>
> Command line:
>
> openload.exe http://localhost 100
>
>
> Eventually, it eats up ram and at about 600 meg memory errors start
> coming forth (in the delivered EXE).
>
> I acknowledge this may be something more fundamental with the platform.
> But I wanted to make sure that I'm using hunchentoot properly, and if
> hunchentoot has anything that would help me narrow down what is happening.
>
> Thank you for your time,
> Matt
>
>
> Matt Lamari wrote:
>> I should probably be more clear - The program goes haywire when I force
>> or finalize-output to this stream. ?I acknowledge that, here, I should
>> not do that, and I don't do so on my main web app.
>>
>> However, doing so seems to send the whole environment "off the rails" in
>> a manner similar to what happens to the main app, and I was hoping that
>> someone with more knowledge of what's under the API ?could tell whether
>> or not this sort of failure should be contained, or what's going on when
>> this type of failure occurs.
>>
>> Any help appreciated. ?I realize I may not have a hunchentoot problem;
>> but that someone who knowns hunchentoot may be able to point me in the
>> right direction.
>>
>> Cheers,
>> Matt
>>
>>
>> Matt Lamari wrote:
>>
>>> This is part of a wider effort, to isolate a problem I've been having
>>> with my main app.
>>>
>>> I have written a standalone LW deliverable, all in one directory (with
>>> the libs used in subdirectories). ?It builds to an .EXE in LW5.1 or LW6
>>> (2 batch files).
>>>
>>> I can't get the ?same feedback running in the IDE, except for the leaks.
>>>
>>> I am posting here to get assistance in converging on the solution. ?The
>>> problem I'm hitting may be in libraries, my usage of them, or lispworks
>>> itself (the problem in my wider app seems to trigger
>>> garbage-collector-level problems).
>>>
>>> The load tester is http://openwebload.sourceforge.net/ ?<-- I can get
>>> the problem to repeat with 1 connection or 100, default settings,
>>> against the dispatcher I listed below.
>>>
>>> It is my understanding that there are 2 ways for a Hunchentoot request
>>> handlers to emit data - returning a string, or by calling (send-headers)
>>> then writing to the returned stream.
>>>
>>> I have a bare-bones hunchentoot server that returns a page that is 100x
>>> the letter A.
>>> If I make it return the 100x A string, it will run indefinitely, and
>>> work fine.
>>> If I make it write binary 65 100 times with force-output, it grenades.
>>>
>>> Against a browser, BOTH WORK FINE.
>>>
>>> Against the load tester, the stream-write version leaks badly (even with
>>> the log turned off), spits a lot of errors, and eventually fails. ?The
>>> string version can run indefinitely, without errors or leaks.
>>>
>>> Obviously the load tester is disconnecting. ?But the important point is
>>> that it's exposing some scenario that is possible.
>>>
>>> Also, the failures I get in my main app have seemed to happen at the
>>> garbage collector level (a dump will be included below)
>>>
>>> I don't want to sweep this under the rug by accumulating a string, it
>>> may be highlighting a more serious problem in something more fundamental.
>>>
>>> Here is the hunchentoot dispatcher: ?The "return 100 As string" is
>>> there, commented out. ?Force-output on each byte is there to
>>> aggressively push the problem. ?Again let me state - this code works
>>> when interacting with a browser. ?And I expect an exception when the
>>> receiver disappears, just not one this critical.
>>>
>>>
>>> (setq *dispatch-table*
>>> ? ? ? ? ? (append
>>> ? ? ? ? ? ?(list
>>> ? ? ? ? ? ? (create-prefix-dispatcher
>>> ? ? ? ? ? ? ?"/"
>>> ? ? ? ? ? ? ?(lambda (&rest rest)
>>> ? ? ? ? ? ? ? ?#| (make-string 100 :initial-element #\A) |#
>>> ? ? ? ? ? ? ? ?(let ((stream (send-headers)))
>>> ? ? ? ? ? ? ? ? ?(loop for i from 1 to 100 do (progn (write-byte 65
>>> stream) (force-output stream))))
>>> ? ? ? ? ? ? ? ?(force-output stream)
>>> ? ? ? ? ? ? ? ?nil)))
>>> ? ? ? ? ? ?(list #'default-dispatcher)))
>>>
>>> This whole directory is self-contained and made of only the most minimal
>>> code (this is most of it) and the ASDF-loads. ?It includes a batch file
>>> that can build for LW5 and for LW6. ?I can hand it off to any interested
>>> party. ?If security is a concern, this core dispatch table is easily
>>> transplantable into anyone's working Hunchentoot environment. . . .
>>> Note the references to "CFO" and "MARK-GENERATION".
>>>
>>> I can provide the self-contained test project as a zipfile to anyone who
>>> wants it.
>>>
>>>
>>> Here is a sample error:
>>>
>>> *** EXCEPTION DATA ***
>>> code c0000005 ?flags 00000000 address 2015C250
>>> EIP 2015c250 ?ESP 032fe62c ?EBP 032fe644 ESI 0000002e ?EDI 20bbfff2
>>> EAX 00000140 ?EBX 0e84f0c1 ?ECX 0000007f EDX 00000100
>>> stack dump:
>>> 032fe62c: 08048020 00001486 28b7bb52 28b7bb42
>>> 032fe63c: 00002e5e 00000480 032fe67c 204f61e3
>>> 032fe64c: 20b33b2d 20250d9b 20250d9b 20250d9b
>>> 032fe65c: 20250d9b 20250d9b 20250d9b 20250d9b
>>> 032fe66c: 20250d9b 00000c86 032fe684 2021142e
>>> 032fe67c: 032fe69c 20463860 08048020 20b33b2d
>>> 032fe68c: 20b33b1b 20746573 20b33b2d 20250d9b
>>> 032fe69c: 032fe6d8 20463c1d 20b33b1b ffffff96
>>> 032fe6ac: 032fe7d4 032fe6d8 20463c73 00000036
>>> 032fe6bc: 00000000 20b33b2d 20004003 2014bd33
>>> 032fe6cc: 20250d9b 200caac7 20b33b1b 032fe700
>>> 032fe6dc: 2046300c 00000084 200caac7 032fe70c
>>> 032fe6ec: 200caac7 200caac7 200caac7 200caac7
>>> 032fe6fc: 200caac7 032fe71c 207a8b92 20b33b1b
>>> 032fe70c: 00000100 00000056 032fe734 200caac7
>>> 032fe71c: 032fe72c 204e9f2e 20b33b1b 20b33b1b
>>> reentrypoint 200705e2
>>> <**> Return address not inside a CFO : 20809a13 at 2efe78c
>>> ;>>>>> dumping ? 2efe70c ?[16] limit 2eff000
>>> ;> ?2efe70c: ? ? ? 100 200a3b07 ?2efe71c 20740488
>>> ;> ?2efe71c: ? 2efe728 204e5469 200a3b07 ?2efe740
>>> ;> ?2efe72c: ?204eb9bb ? ? ? 84 fffffff6 ?2efe810
>>> ;> ?2efe73c: ?200a3b07 ?2efe774 204e5622 201fc5c3
>>> ;> ?2efe74c: ?ffffff96 ?2efe7fc ?2efe774 204e5639
>>> ;> ?2efe75c: ? ? ? ?36 201fc5c3 20628823 200a3b07
>>> ;> ?2efe76c: ?200a3b07 200a3ac3 ?2efe7a0 204aff5a
>>> ;> ?2efe77c: ? ? ? ? 4 ffffff96 20b38561 201fc5c3
>>> ;> ?2efe78c: ?20809a13 20b385fd ? ? ? 30 ? ? 3000
>>> ;> ?2efe79c: ? ? ? ?30 ?2efe7b8 204ab1b6 ? ? ? ?0
>>> ;> ?2efe7ac: ?20b381da 20b28f03 20a0fb2f ?2efe7d4
>>> ;> ?2efe7bc: ?2073e8fe 20b28f03 20591a0b 206578f7
>>> ;> ?2efe7cc: ? 2efe7f1 206e89c7 ?2efe944 204af6ab
>>> ;> ?2efe7dc: ? ? ? ?1c 20b28f03 90ff8096 20155383
>>> ;> ?2efe7ec: ? ? ? ?56 90ff8096 208098fb ?2efe7e5
>>> ;> ?2efe7fc: ?ffffff96 ?2efe9b4 ?2efe944 204af738
>>> Simple backtrace:
>>> 04ABFD30 20005170 #<Callable 2000511A>
>>> ? ? ?>>> Actually called : MARK-GENERATION
>>> 04ABFD3C 2000FACC #<Callable 2000FA1A>
>>> 04ABFD54 2006B742 #<Callable 2006B422>
>>> 04ABFD78 200343DA #<Callable 2003436A>
>>> 04ABFD98 20034926 #<Callable 2003487A>
>>> 033FE384 200345D6 #<Callable 200344A2>
>>> ? ? ?>>> Actually called : I-FULL-ALLOC-BLOCK-LOCAL
>>> 033FE394 20040EAE #<Callable 20040E8A>
>>> ? ? ?>>> Actually called : ALLOC-OBJECT
>>> 033FE3B8 2018BD98 "ALLOC-STRING"
>>> ? ? ?>>> Actually called : MAKE-BASE-STRING
>>> 033FE3D0 201AE864 "IN-MAKE-TYPED-STRING"
>>> 033FE3F8 201AEC11 "MAKE-TYPED-STRING"
>>> 033FE410 207E82E3 "MAKE-STREAM-BLOCK"
>>> 033FE430 207F27F5 "ADD-NEW-BLOCK"
>>> 033FE4BC 207F200D "(METHOD STREAM-FLUSH-BUFFER STRING-OUTPUT-STREAM . ?NIL)"
>>> ? ? ?>>> Actually called : STREAM-FLUSH-BUFFER
>>> 033FE4EC 20173123 "(METHOD STREAM-WRITE-STRING (BUFFERED-STREAM T))"
>>> 033FE518 207556D9 #<Callable 20755622>
>>> ? ? ?>>> Actually called : STREAM-WRITE-STRING
>>> 033FE540 20176744 "WRITE-STRING*"
>>> 033FE56C 20126821 "SUB-FORMAT"
>>> 033FE5B4 20125E72 "CALL-SUB-FORMAT"
>>> 033FE5D0 2084FE08 "FORMAT"
>>> 033FE674 204B0CE4 "SAFER-FORMAT"
>>> 033FE780 204B04CD "(METHOD DBG-PRINT-FRAME BINDING-FRAME . ?NIL)"
>>> 033FE7A8 2073E8FE #<Callable 2073E872>
>>> ? ? ?>>> Actually called : DBG-PRINT-FRAME
>>> 033FE7D4 204AF6AB "BUG-BACKTRACE"
>>> 033FE944 2044C5FA "PRINT-BACKTRACE-TO-STREAM"
>>> 033FE9AC 208243D0 "GET-BACKTRACE"
>>> 033FEA9C 20403292 "(METHOD HANDLE-REQUEST (ACCEPTOR REQUEST))"
>>> 033FEAB4 204BACC0 "SIGNAL"
>>> 033FEAF4 204CB948 "CONDITIONS-ERROR"
>>> 033FEB38 201EA995 "ERROR"
>>> ? ? ?>>> Actually called : SOCKET-ERROR
>>> 033FEB48 2043F73B "(METHOD STREAM-WRITE-BUFFER (SOCKET-STREAM T T T))"
>>> ? ? ?>>> Actually called : STREAM-WRITE-BUFFER
>>> 033FEB6C 20173AE9 "(METHOD STREAM-FLUSH-BUFFER BUFFERED-STREAM . ?NIL)"
>>> ? ? ?>>> Actually called : STREAM-FLUSH-BUFFER
>>> 033FEB88 20173A11 "(METHOD STREAM-FORCE-OUTPUT BUFFERED-STREAM . ?NIL)"
>>> ? ? ?>>> Actually called : FORCE-OUTPUT
>>> 033FEB94 207F21B5 "MAIN"
>>> 033FEBA8 2054562E "(METHOD HANDLE-REQUEST (ACCEPTOR REQUEST))"
>>> 033FEC70 2084A559 "(METHOD PROCESS-REQUEST T . ?NIL)"
>>> 033FED08 20409679 "(METHOD PROCESS-CONNECTION (ACCEPTOR T))"
>>> 033FEDBC 20566DF9 "NEXT-METHOD-CALL-2"
>>> 033FEDDC 204F7F37 "(METHOD PROCESS-CONNECTION AROUND (ACCEPTOR T))"
>>> 033FEE88 2076DE2E #<Callable 2076DDEA>
>>> 033FEEA8 2083B4A7 "PROCESS-SG-FUNCTION"
>>> 033FEFBC 204896A2 #<Callable 2048967A>
>>> 033FEFD0 20887C6B "(DEFINE-FOREIGN-CALLABLE NIL) .
>>> %FOREIGN-CALLABLE/thread_initial_function"
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
>



From matt.lamari at gmail.com  Thu Feb 11 07:20:34 2010
From: matt.lamari at gmail.com (Matt Lamari)
Date: Thu, 11 Feb 2010 01:20:34 -0600
Subject: [hunchentoot-devel] A simple repeatable leak case,
 LW32 : Re: Terminal problem when writing to binary request thread
 on LW32/Win32, under load
In-Reply-To: <4B73A26B.2080303@gmail.com>
References: <4B733333.9050004@gmail.com> <4B73507F.5090203@gmail.com>
	<4B73A26B.2080303@gmail.com>
Message-ID: <4B73AFC2.5080307@gmail.com>


Here's my concern.  There are 2 things amiss, that I can trigger
independently. . . .

1.  The errors when using finalize-output or force-output.
2.  The leak

The dumps you see below are from (1)

Should finalize/force-output work?

Complaining of (2) worries me - I don't see anything leaking per se' in
hunchentoot's workings; but am not sure if I could give a leaking
codebase to LW and have them trusting that it isn't the algorithm.

Which symtom(s) should I emphasize to them?



Matt Lamari wrote:
> This leaks (and eventually something bad happens).
>
> I realize that the leadtester may be abusing it; but I'd like to assume
> the worst coming from the net.  Closing the load tester does not
> alleviate the problem.
>
> Note - I've got Linux/SBCL guys telling me this works fine on their
> platforms, without leaks.
>
> Lispworks 5.1 and Lispworks 6
> Hunchentoot, latest supporting libs
> Win32  (I run on Vista 64)
>
>
> Minimalist dispatch table: (works the same in the IDE AND in the
> delivered app)
>
> (setf hunchentoot::*session-max-time* 10) ;remove this as a variable
> (setq *dispatch-table*
>           (append
>            (list
>             (create-prefix-dispatcher
>              "/"
>              (lambda (&rest rest)
>                (let ((stream (send-headers)))
>                  (loop for i from 1 to 10000 do (write-byte 65 stream)))
>                nil)))
>            (list #'default-dispatcher)))
>
> Load tester:  (Note - on Win32 this is a single executable, just drop it
> somewhere and run it)
>
> http://openwebload.sourceforge.net/ 
>
> Command line:
>
> openload.exe http://localhost 100
>
>
> Eventually, it eats up ram and at about 600 meg memory errors start
> coming forth (in the delivered EXE).
>
> I acknowledge this may be something more fundamental with the platform. 
> But I wanted to make sure that I'm using hunchentoot properly, and if
> hunchentoot has anything that would help me narrow down what is happening.
>
> Thank you for your time,
> Matt
>
>
> Matt Lamari wrote:
>   
>> I should probably be more clear - The program goes haywire when I force
>> or finalize-output to this stream.  I acknowledge that, here, I should
>> not do that, and I don't do so on my main web app.
>>
>> However, doing so seems to send the whole environment "off the rails" in
>> a manner similar to what happens to the main app, and I was hoping that
>> someone with more knowledge of what's under the API  could tell whether
>> or not this sort of failure should be contained, or what's going on when
>> this type of failure occurs.
>>
>> Any help appreciated.  I realize I may not have a hunchentoot problem;
>> but that someone who knowns hunchentoot may be able to point me in the
>> right direction.
>>
>> Cheers,
>> Matt
>>
>>
>> Matt Lamari wrote:
>>   
>>     
>>> This is part of a wider effort, to isolate a problem I've been having
>>> with my main app.
>>>
>>> I have written a standalone LW deliverable, all in one directory (with
>>> the libs used in subdirectories).  It builds to an .EXE in LW5.1 or LW6
>>> (2 batch files).
>>>
>>> I can't get the  same feedback running in the IDE, except for the leaks.
>>>
>>> I am posting here to get assistance in converging on the solution.  The
>>> problem I'm hitting may be in libraries, my usage of them, or lispworks
>>> itself (the problem in my wider app seems to trigger
>>> garbage-collector-level problems).
>>>
>>> The load tester is http://openwebload.sourceforge.net/  <-- I can get
>>> the problem to repeat with 1 connection or 100, default settings,
>>> against the dispatcher I listed below.
>>>
>>> It is my understanding that there are 2 ways for a Hunchentoot request
>>> handlers to emit data - returning a string, or by calling (send-headers)
>>> then writing to the returned stream.
>>>
>>> I have a bare-bones hunchentoot server that returns a page that is 100x
>>> the letter A.
>>> If I make it return the 100x A string, it will run indefinitely, and
>>> work fine.
>>> If I make it write binary 65 100 times with force-output, it grenades.
>>>
>>> Against a browser, BOTH WORK FINE.
>>>
>>> Against the load tester, the stream-write version leaks badly (even with
>>> the log turned off), spits a lot of errors, and eventually fails.  The
>>> string version can run indefinitely, without errors or leaks.
>>>
>>> Obviously the load tester is disconnecting.  But the important point is
>>> that it's exposing some scenario that is possible.
>>>
>>> Also, the failures I get in my main app have seemed to happen at the
>>> garbage collector level (a dump will be included below)
>>>
>>> I don't want to sweep this under the rug by accumulating a string, it
>>> may be highlighting a more serious problem in something more fundamental.
>>>
>>> Here is the hunchentoot dispatcher:  The "return 100 As string" is
>>> there, commented out.  Force-output on each byte is there to
>>> aggressively push the problem.  Again let me state - this code works
>>> when interacting with a browser.  And I expect an exception when the
>>> receiver disappears, just not one this critical.
>>>
>>>
>>> (setq *dispatch-table*
>>>           (append
>>>            (list
>>>             (create-prefix-dispatcher
>>>              "/"
>>>              (lambda (&rest rest)
>>>                #| (make-string 100 :initial-element #\A) |#
>>>                (let ((stream (send-headers)))
>>>                  (loop for i from 1 to 100 do (progn (write-byte 65
>>> stream) (force-output stream))))
>>>                (force-output stream)
>>>                nil)))
>>>            (list #'default-dispatcher)))
>>>
>>> This whole directory is self-contained and made of only the most minimal
>>> code (this is most of it) and the ASDF-loads.  It includes a batch file
>>> that can build for LW5 and for LW6.  I can hand it off to any interested
>>> party.  If security is a concern, this core dispatch table is easily
>>> transplantable into anyone's working Hunchentoot environment. . . . 
>>> Note the references to "CFO" and "MARK-GENERATION".
>>>
>>> I can provide the self-contained test project as a zipfile to anyone who
>>> wants it.
>>>
>>>
>>> Here is a sample error:
>>>
>>> *** EXCEPTION DATA ***
>>> code c0000005  flags 00000000 address 2015C250
>>> EIP 2015c250  ESP 032fe62c  EBP 032fe644 ESI 0000002e  EDI 20bbfff2
>>> EAX 00000140  EBX 0e84f0c1  ECX 0000007f EDX 00000100
>>> stack dump:
>>> 032fe62c: 08048020 00001486 28b7bb52 28b7bb42
>>> 032fe63c: 00002e5e 00000480 032fe67c 204f61e3
>>> 032fe64c: 20b33b2d 20250d9b 20250d9b 20250d9b
>>> 032fe65c: 20250d9b 20250d9b 20250d9b 20250d9b
>>> 032fe66c: 20250d9b 00000c86 032fe684 2021142e
>>> 032fe67c: 032fe69c 20463860 08048020 20b33b2d
>>> 032fe68c: 20b33b1b 20746573 20b33b2d 20250d9b
>>> 032fe69c: 032fe6d8 20463c1d 20b33b1b ffffff96
>>> 032fe6ac: 032fe7d4 032fe6d8 20463c73 00000036
>>> 032fe6bc: 00000000 20b33b2d 20004003 2014bd33
>>> 032fe6cc: 20250d9b 200caac7 20b33b1b 032fe700
>>> 032fe6dc: 2046300c 00000084 200caac7 032fe70c
>>> 032fe6ec: 200caac7 200caac7 200caac7 200caac7
>>> 032fe6fc: 200caac7 032fe71c 207a8b92 20b33b1b
>>> 032fe70c: 00000100 00000056 032fe734 200caac7
>>> 032fe71c: 032fe72c 204e9f2e 20b33b1b 20b33b1b
>>> reentrypoint 200705e2
>>> <**> Return address not inside a CFO : 20809a13 at 2efe78c
>>> ;>>>>> dumping   2efe70c  [16] limit 2eff000
>>> ;>  2efe70c:       100 200a3b07  2efe71c 20740488
>>> ;>  2efe71c:   2efe728 204e5469 200a3b07  2efe740
>>> ;>  2efe72c:  204eb9bb       84 fffffff6  2efe810
>>> ;>  2efe73c:  200a3b07  2efe774 204e5622 201fc5c3
>>> ;>  2efe74c:  ffffff96  2efe7fc  2efe774 204e5639
>>> ;>  2efe75c:        36 201fc5c3 20628823 200a3b07
>>> ;>  2efe76c:  200a3b07 200a3ac3  2efe7a0 204aff5a
>>> ;>  2efe77c:         4 ffffff96 20b38561 201fc5c3
>>> ;>  2efe78c:  20809a13 20b385fd       30     3000
>>> ;>  2efe79c:        30  2efe7b8 204ab1b6        0
>>> ;>  2efe7ac:  20b381da 20b28f03 20a0fb2f  2efe7d4
>>> ;>  2efe7bc:  2073e8fe 20b28f03 20591a0b 206578f7
>>> ;>  2efe7cc:   2efe7f1 206e89c7  2efe944 204af6ab
>>> ;>  2efe7dc:        1c 20b28f03 90ff8096 20155383
>>> ;>  2efe7ec:        56 90ff8096 208098fb  2efe7e5
>>> ;>  2efe7fc:  ffffff96  2efe9b4  2efe944 204af738
>>> Simple backtrace:
>>> 04ABFD30 20005170 #<Callable 2000511A>
>>>      >>> Actually called : MARK-GENERATION
>>> 04ABFD3C 2000FACC #<Callable 2000FA1A>
>>> 04ABFD54 2006B742 #<Callable 2006B422>
>>> 04ABFD78 200343DA #<Callable 2003436A>
>>> 04ABFD98 20034926 #<Callable 2003487A>
>>> 033FE384 200345D6 #<Callable 200344A2>
>>>      >>> Actually called : I-FULL-ALLOC-BLOCK-LOCAL
>>> 033FE394 20040EAE #<Callable 20040E8A>
>>>      >>> Actually called : ALLOC-OBJECT
>>> 033FE3B8 2018BD98 "ALLOC-STRING"
>>>      >>> Actually called : MAKE-BASE-STRING
>>> 033FE3D0 201AE864 "IN-MAKE-TYPED-STRING"
>>> 033FE3F8 201AEC11 "MAKE-TYPED-STRING"
>>> 033FE410 207E82E3 "MAKE-STREAM-BLOCK"
>>> 033FE430 207F27F5 "ADD-NEW-BLOCK"
>>> 033FE4BC 207F200D "(METHOD STREAM-FLUSH-BUFFER STRING-OUTPUT-STREAM .  NIL)"
>>>      >>> Actually called : STREAM-FLUSH-BUFFER
>>> 033FE4EC 20173123 "(METHOD STREAM-WRITE-STRING (BUFFERED-STREAM T))"
>>> 033FE518 207556D9 #<Callable 20755622>
>>>      >>> Actually called : STREAM-WRITE-STRING
>>> 033FE540 20176744 "WRITE-STRING*"
>>> 033FE56C 20126821 "SUB-FORMAT"
>>> 033FE5B4 20125E72 "CALL-SUB-FORMAT"
>>> 033FE5D0 2084FE08 "FORMAT"
>>> 033FE674 204B0CE4 "SAFER-FORMAT"
>>> 033FE780 204B04CD "(METHOD DBG-PRINT-FRAME BINDING-FRAME .  NIL)"
>>> 033FE7A8 2073E8FE #<Callable 2073E872>
>>>      >>> Actually called : DBG-PRINT-FRAME
>>> 033FE7D4 204AF6AB "BUG-BACKTRACE"
>>> 033FE944 2044C5FA "PRINT-BACKTRACE-TO-STREAM"
>>> 033FE9AC 208243D0 "GET-BACKTRACE"
>>> 033FEA9C 20403292 "(METHOD HANDLE-REQUEST (ACCEPTOR REQUEST))"
>>> 033FEAB4 204BACC0 "SIGNAL"
>>> 033FEAF4 204CB948 "CONDITIONS-ERROR"
>>> 033FEB38 201EA995 "ERROR"
>>>      >>> Actually called : SOCKET-ERROR
>>> 033FEB48 2043F73B "(METHOD STREAM-WRITE-BUFFER (SOCKET-STREAM T T T))"
>>>      >>> Actually called : STREAM-WRITE-BUFFER
>>> 033FEB6C 20173AE9 "(METHOD STREAM-FLUSH-BUFFER BUFFERED-STREAM .  NIL)"
>>>      >>> Actually called : STREAM-FLUSH-BUFFER
>>> 033FEB88 20173A11 "(METHOD STREAM-FORCE-OUTPUT BUFFERED-STREAM .  NIL)"
>>>      >>> Actually called : FORCE-OUTPUT
>>> 033FEB94 207F21B5 "MAIN"
>>> 033FEBA8 2054562E "(METHOD HANDLE-REQUEST (ACCEPTOR REQUEST))"
>>> 033FEC70 2084A559 "(METHOD PROCESS-REQUEST T .  NIL)"
>>> 033FED08 20409679 "(METHOD PROCESS-CONNECTION (ACCEPTOR T))"
>>> 033FEDBC 20566DF9 "NEXT-METHOD-CALL-2"
>>> 033FEDDC 204F7F37 "(METHOD PROCESS-CONNECTION AROUND (ACCEPTOR T))"
>>> 033FEE88 2076DE2E #<Callable 2076DDEA>
>>> 033FEEA8 2083B4A7 "PROCESS-SG-FUNCTION"
>>> 033FEFBC 204896A2 #<Callable 2048967A>
>>> 033FEFD0 20887C6B "(DEFINE-FOREIGN-CALLABLE NIL) . 
>>> %FOREIGN-CALLABLE/thread_initial_function"
>>>
>>>
>>>
>>>   
>>>     
>>>       
>>   
>>     
>
>   




From matt.lamari at gmail.com  Thu Feb 11 07:37:01 2010
From: matt.lamari at gmail.com (Matt Lamari)
Date: Thu, 11 Feb 2010 01:37:01 -0600
Subject: [hunchentoot-devel] A simple repeatable leak case,
 LW32 : Re: Terminal problem when writing to binary request thread
 on LW32/Win32, under load
In-Reply-To: <b56421a01002102255r676ef8ebic13a2c7e93e632ac@mail.gmail.com>
References: <4B733333.9050004@gmail.com> <4B73507F.5090203@gmail.com>	
	<4B73A26B.2080303@gmail.com>
	<b56421a01002102255r676ef8ebic13a2c7e93e632ac@mail.gmail.com>
Message-ID: <4B73B39D.5000500@gmail.com>

All logs disabled, I set backtrace to NIL for good measure.

(Heavy error output + global-lock lead to another degenerative condition
that I'm trying to remove from the equation, running out of processes
when they all lock trying to get to the log file).



Edi Weitz wrote:
> Matt,
>
> The symptoms are the same on LW6 and LW5.1?  If the test case is
> self-contained, I'd suggest to send it to LW support; I'm pretty sure
> they'd be interested to see it.  No matter what you're doing (and I
> only thought about it for a few seconds), the dump you included looks
> like one of those thing that should not happen...
>
> Thanks,
> Edi.
>
> PS: BTW, do you have backtraces enabled in your Hunchentoot?  And if
> so, can you reproduce the problem with them turned off?
>
>
>
> On Thu, Feb 11, 2010 at 7:23 AM, Matt Lamari <matt.lamari at gmail.com> wrote:
>   
>> This leaks (and eventually something bad happens).
>>
>> I realize that the leadtester may be abusing it; but I'd like to assume
>> the worst coming from the net.  Closing the load tester does not
>> alleviate the problem.
>>
>> Note - I've got Linux/SBCL guys telling me this works fine on their
>> platforms, without leaks.
>>
>> Lispworks 5.1 and Lispworks 6
>> Hunchentoot, latest supporting libs
>> Win32  (I run on Vista 64)
>>
>>
>> Minimalist dispatch table: (works the same in the IDE AND in the
>> delivered app)
>>
>> (setf hunchentoot::*session-max-time* 10) ;remove this as a variable
>> (setq *dispatch-table*
>>          (append
>>           (list
>>            (create-prefix-dispatcher
>>             "/"
>>             (lambda (&rest rest)
>>               (let ((stream (send-headers)))
>>                 (loop for i from 1 to 10000 do (write-byte 65 stream)))
>>               nil)))
>>           (list #'default-dispatcher)))
>>
>> Load tester:  (Note - on Win32 this is a single executable, just drop it
>> somewhere and run it)
>>
>> http://openwebload.sourceforge.net/
>>
>> Command line:
>>
>> openload.exe http://localhost 100
>>
>>
>> Eventually, it eats up ram and at about 600 meg memory errors start
>> coming forth (in the delivered EXE).
>>
>> I acknowledge this may be something more fundamental with the platform.
>> But I wanted to make sure that I'm using hunchentoot properly, and if
>> hunchentoot has anything that would help me narrow down what is happening.
>>
>> Thank you for your time,
>> Matt
>>
>>
>> Matt Lamari wrote:
>>     
>>> I should probably be more clear - The program goes haywire when I force
>>> or finalize-output to this stream.  I acknowledge that, here, I should
>>> not do that, and I don't do so on my main web app.
>>>
>>> However, doing so seems to send the whole environment "off the rails" in
>>> a manner similar to what happens to the main app, and I was hoping that
>>> someone with more knowledge of what's under the API  could tell whether
>>> or not this sort of failure should be contained, or what's going on when
>>> this type of failure occurs.
>>>
>>> Any help appreciated.  I realize I may not have a hunchentoot problem;
>>> but that someone who knowns hunchentoot may be able to point me in the
>>> right direction.
>>>
>>> Cheers,
>>> Matt
>>>
>>>
>>> Matt Lamari wrote:
>>>
>>>       
>>>> This is part of a wider effort, to isolate a problem I've been having
>>>> with my main app.
>>>>
>>>> I have written a standalone LW deliverable, all in one directory (with
>>>> the libs used in subdirectories).  It builds to an .EXE in LW5.1 or LW6
>>>> (2 batch files).
>>>>
>>>> I can't get the  same feedback running in the IDE, except for the leaks.
>>>>
>>>> I am posting here to get assistance in converging on the solution.  The
>>>> problem I'm hitting may be in libraries, my usage of them, or lispworks
>>>> itself (the problem in my wider app seems to trigger
>>>> garbage-collector-level problems).
>>>>
>>>> The load tester is http://openwebload.sourceforge.net/  <-- I can get
>>>> the problem to repeat with 1 connection or 100, default settings,
>>>> against the dispatcher I listed below.
>>>>
>>>> It is my understanding that there are 2 ways for a Hunchentoot request
>>>> handlers to emit data - returning a string, or by calling (send-headers)
>>>> then writing to the returned stream.
>>>>
>>>> I have a bare-bones hunchentoot server that returns a page that is 100x
>>>> the letter A.
>>>> If I make it return the 100x A string, it will run indefinitely, and
>>>> work fine.
>>>> If I make it write binary 65 100 times with force-output, it grenades.
>>>>
>>>> Against a browser, BOTH WORK FINE.
>>>>
>>>> Against the load tester, the stream-write version leaks badly (even with
>>>> the log turned off), spits a lot of errors, and eventually fails.  The
>>>> string version can run indefinitely, without errors or leaks.
>>>>
>>>> Obviously the load tester is disconnecting.  But the important point is
>>>> that it's exposing some scenario that is possible.
>>>>
>>>> Also, the failures I get in my main app have seemed to happen at the
>>>> garbage collector level (a dump will be included below)
>>>>
>>>> I don't want to sweep this under the rug by accumulating a string, it
>>>> may be highlighting a more serious problem in something more fundamental.
>>>>
>>>> Here is the hunchentoot dispatcher:  The "return 100 As string" is
>>>> there, commented out.  Force-output on each byte is there to
>>>> aggressively push the problem.  Again let me state - this code works
>>>> when interacting with a browser.  And I expect an exception when the
>>>> receiver disappears, just not one this critical.
>>>>
>>>>
>>>> (setq *dispatch-table*
>>>>           (append
>>>>            (list
>>>>             (create-prefix-dispatcher
>>>>              "/"
>>>>              (lambda (&rest rest)
>>>>                #| (make-string 100 :initial-element #\A) |#
>>>>                (let ((stream (send-headers)))
>>>>                  (loop for i from 1 to 100 do (progn (write-byte 65
>>>> stream) (force-output stream))))
>>>>                (force-output stream)
>>>>                nil)))
>>>>            (list #'default-dispatcher)))
>>>>
>>>> This whole directory is self-contained and made of only the most minimal
>>>> code (this is most of it) and the ASDF-loads.  It includes a batch file
>>>> that can build for LW5 and for LW6.  I can hand it off to any interested
>>>> party.  If security is a concern, this core dispatch table is easily
>>>> transplantable into anyone's working Hunchentoot environment. . . .
>>>> Note the references to "CFO" and "MARK-GENERATION".
>>>>
>>>> I can provide the self-contained test project as a zipfile to anyone who
>>>> wants it.
>>>>
>>>>
>>>> Here is a sample error:
>>>>
>>>> *** EXCEPTION DATA ***
>>>> code c0000005  flags 00000000 address 2015C250
>>>> EIP 2015c250  ESP 032fe62c  EBP 032fe644 ESI 0000002e  EDI 20bbfff2
>>>> EAX 00000140  EBX 0e84f0c1  ECX 0000007f EDX 00000100
>>>> stack dump:
>>>> 032fe62c: 08048020 00001486 28b7bb52 28b7bb42
>>>> 032fe63c: 00002e5e 00000480 032fe67c 204f61e3
>>>> 032fe64c: 20b33b2d 20250d9b 20250d9b 20250d9b
>>>> 032fe65c: 20250d9b 20250d9b 20250d9b 20250d9b
>>>> 032fe66c: 20250d9b 00000c86 032fe684 2021142e
>>>> 032fe67c: 032fe69c 20463860 08048020 20b33b2d
>>>> 032fe68c: 20b33b1b 20746573 20b33b2d 20250d9b
>>>> 032fe69c: 032fe6d8 20463c1d 20b33b1b ffffff96
>>>> 032fe6ac: 032fe7d4 032fe6d8 20463c73 00000036
>>>> 032fe6bc: 00000000 20b33b2d 20004003 2014bd33
>>>> 032fe6cc: 20250d9b 200caac7 20b33b1b 032fe700
>>>> 032fe6dc: 2046300c 00000084 200caac7 032fe70c
>>>> 032fe6ec: 200caac7 200caac7 200caac7 200caac7
>>>> 032fe6fc: 200caac7 032fe71c 207a8b92 20b33b1b
>>>> 032fe70c: 00000100 00000056 032fe734 200caac7
>>>> 032fe71c: 032fe72c 204e9f2e 20b33b1b 20b33b1b
>>>> reentrypoint 200705e2
>>>> <**> Return address not inside a CFO : 20809a13 at 2efe78c
>>>> ;>>>>> dumping   2efe70c  [16] limit 2eff000
>>>> ;>  2efe70c:       100 200a3b07  2efe71c 20740488
>>>> ;>  2efe71c:   2efe728 204e5469 200a3b07  2efe740
>>>> ;>  2efe72c:  204eb9bb       84 fffffff6  2efe810
>>>> ;>  2efe73c:  200a3b07  2efe774 204e5622 201fc5c3
>>>> ;>  2efe74c:  ffffff96  2efe7fc  2efe774 204e5639
>>>> ;>  2efe75c:        36 201fc5c3 20628823 200a3b07
>>>> ;>  2efe76c:  200a3b07 200a3ac3  2efe7a0 204aff5a
>>>> ;>  2efe77c:         4 ffffff96 20b38561 201fc5c3
>>>> ;>  2efe78c:  20809a13 20b385fd       30     3000
>>>> ;>  2efe79c:        30  2efe7b8 204ab1b6        0
>>>> ;>  2efe7ac:  20b381da 20b28f03 20a0fb2f  2efe7d4
>>>> ;>  2efe7bc:  2073e8fe 20b28f03 20591a0b 206578f7
>>>> ;>  2efe7cc:   2efe7f1 206e89c7  2efe944 204af6ab
>>>> ;>  2efe7dc:        1c 20b28f03 90ff8096 20155383
>>>> ;>  2efe7ec:        56 90ff8096 208098fb  2efe7e5
>>>> ;>  2efe7fc:  ffffff96  2efe9b4  2efe944 204af738
>>>> Simple backtrace:
>>>> 04ABFD30 20005170 #<Callable 2000511A>
>>>>      >>> Actually called : MARK-GENERATION
>>>> 04ABFD3C 2000FACC #<Callable 2000FA1A>
>>>> 04ABFD54 2006B742 #<Callable 2006B422>
>>>> 04ABFD78 200343DA #<Callable 2003436A>
>>>> 04ABFD98 20034926 #<Callable 2003487A>
>>>> 033FE384 200345D6 #<Callable 200344A2>
>>>>      >>> Actually called : I-FULL-ALLOC-BLOCK-LOCAL
>>>> 033FE394 20040EAE #<Callable 20040E8A>
>>>>      >>> Actually called : ALLOC-OBJECT
>>>> 033FE3B8 2018BD98 "ALLOC-STRING"
>>>>      >>> Actually called : MAKE-BASE-STRING
>>>> 033FE3D0 201AE864 "IN-MAKE-TYPED-STRING"
>>>> 033FE3F8 201AEC11 "MAKE-TYPED-STRING"
>>>> 033FE410 207E82E3 "MAKE-STREAM-BLOCK"
>>>> 033FE430 207F27F5 "ADD-NEW-BLOCK"
>>>> 033FE4BC 207F200D "(METHOD STREAM-FLUSH-BUFFER STRING-OUTPUT-STREAM .  NIL)"
>>>>      >>> Actually called : STREAM-FLUSH-BUFFER
>>>> 033FE4EC 20173123 "(METHOD STREAM-WRITE-STRING (BUFFERED-STREAM T))"
>>>> 033FE518 207556D9 #<Callable 20755622>
>>>>      >>> Actually called : STREAM-WRITE-STRING
>>>> 033FE540 20176744 "WRITE-STRING*"
>>>> 033FE56C 20126821 "SUB-FORMAT"
>>>> 033FE5B4 20125E72 "CALL-SUB-FORMAT"
>>>> 033FE5D0 2084FE08 "FORMAT"
>>>> 033FE674 204B0CE4 "SAFER-FORMAT"
>>>> 033FE780 204B04CD "(METHOD DBG-PRINT-FRAME BINDING-FRAME .  NIL)"
>>>> 033FE7A8 2073E8FE #<Callable 2073E872>
>>>>      >>> Actually called : DBG-PRINT-FRAME
>>>> 033FE7D4 204AF6AB "BUG-BACKTRACE"
>>>> 033FE944 2044C5FA "PRINT-BACKTRACE-TO-STREAM"
>>>> 033FE9AC 208243D0 "GET-BACKTRACE"
>>>> 033FEA9C 20403292 "(METHOD HANDLE-REQUEST (ACCEPTOR REQUEST))"
>>>> 033FEAB4 204BACC0 "SIGNAL"
>>>> 033FEAF4 204CB948 "CONDITIONS-ERROR"
>>>> 033FEB38 201EA995 "ERROR"
>>>>      >>> Actually called : SOCKET-ERROR
>>>> 033FEB48 2043F73B "(METHOD STREAM-WRITE-BUFFER (SOCKET-STREAM T T T))"
>>>>      >>> Actually called : STREAM-WRITE-BUFFER
>>>> 033FEB6C 20173AE9 "(METHOD STREAM-FLUSH-BUFFER BUFFERED-STREAM .  NIL)"
>>>>      >>> Actually called : STREAM-FLUSH-BUFFER
>>>> 033FEB88 20173A11 "(METHOD STREAM-FORCE-OUTPUT BUFFERED-STREAM .  NIL)"
>>>>      >>> Actually called : FORCE-OUTPUT
>>>> 033FEB94 207F21B5 "MAIN"
>>>> 033FEBA8 2054562E "(METHOD HANDLE-REQUEST (ACCEPTOR REQUEST))"
>>>> 033FEC70 2084A559 "(METHOD PROCESS-REQUEST T .  NIL)"
>>>> 033FED08 20409679 "(METHOD PROCESS-CONNECTION (ACCEPTOR T))"
>>>> 033FEDBC 20566DF9 "NEXT-METHOD-CALL-2"
>>>> 033FEDDC 204F7F37 "(METHOD PROCESS-CONNECTION AROUND (ACCEPTOR T))"
>>>> 033FEE88 2076DE2E #<Callable 2076DDEA>
>>>> 033FEEA8 2083B4A7 "PROCESS-SG-FUNCTION"
>>>> 033FEFBC 204896A2 #<Callable 2048967A>
>>>> 033FEFD0 20887C6B "(DEFINE-FOREIGN-CALLABLE NIL) .
>>>> %FOREIGN-CALLABLE/thread_initial_function"
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>         
>>>       
>> _______________________________________________
>> tbnl-devel site list
>> tbnl-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>
>>
>>     




From edi at agharta.de  Thu Feb 11 09:49:41 2010
From: edi at agharta.de (Edi Weitz)
Date: Thu, 11 Feb 2010 10:49:41 +0100
Subject: [hunchentoot-devel] A simple repeatable leak case,
	LW32 : Re: Terminal problem when writing to binary request thread
	on LW32/Win32, under 	load
In-Reply-To: <4B73AFC2.5080307@gmail.com>
References: <4B733333.9050004@gmail.com> <4B73507F.5090203@gmail.com>
	<4B73A26B.2080303@gmail.com> <4B73AFC2.5080307@gmail.com>
Message-ID: <b56421a01002110149g5b6e71d0t53c2d7c1b5a2b73d@mail.gmail.com>

On Thu, Feb 11, 2010 at 8:20 AM, Matt Lamari <matt.lamari at gmail.com> wrote:

> Should finalize/force-output work?

For sure it should work...

> Which symtom(s) should I emphasize to them?

I don't have the time to look at this in more detail and I'll be out
of town for a couple of days, but if you can present them with a
self-contained test case that triggers an error in the garbage
collector, that should be interesting enough, I'd think.



From rm at seid-online.de  Wed Feb 17 15:18:58 2010
From: rm at seid-online.de (Ralf Mattes)
Date: Wed, 17 Feb 2010 16:18:58 +0100
Subject: [hunchentoot-devel] Cl-WebDAV broken?
Message-ID: <1266419938.7243.3.camel@mhflaptop01>

Hello list,

this is with a fresh svn checkout from: 
 svn://bknr.net/svn/trunk/thirdparty/hunchentoot
 svn://bknr.net/svn/trunk/thirdparty/cl-webdav


In a shell:

  cadaver http://localhost:4243/

triggers the following backtrace:

The function (SETF HUNCHENTOOT:CONTENT-TYPE) is undefined.
   [Condition of type UNDEFINED-FUNCTION]

Restarts:
 0: [TERMINATE-THREAD] Terminate this thread (#<THREAD "Hunchentoot worker (client: 127.0.0.1:35255)" RUNNING {C164E19}>)

Backtrace:
  0: ((LAMBDA (SWANK-BACKEND::DEBUGGER-LOOP-FN)) #<FUNCTION (LAMBDA #) {AF28C2D}>)
  1: (SWANK::DEBUG-IN-EMACS #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE) {C1B8FF1}>)
  2: (SWANK-BACKEND::CALL-WITH-BREAK-HOOK #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {C1B909D}>)
  3: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {C1B909D}>)
  4: (SWANK::CALL-WITH-BINDINGS ..)
  5: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {B366A09}> #<CLOSURE (LAMBDA #) {C1B909D}>)
  6: (SWANK:INVOKE-SLIME-DEBUGGER #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE) {C1B8FF1}>)
  7: (SWANK-BACKEND::CALL-WITH-BREAK-HOOK #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {C1B907D}>)
  8: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {C1B907D}>)
  9: (SWANK:SWANK-DEBUGGER-HOOK #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE) {C1B8FF1}> #<unavailable argument>)
 10: (INVOKE-DEBUGGER #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE) {C1B8FF1}>)
 11: ((SB-PCL::FAST-METHOD HUNCHENTOOT:MAYBE-INVOKE-DEBUGGER (T)) #<unavailable argument> #<unavailable argument> #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE) {C1B8FF1}>)
 12: (SIGNAL #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE) {C1B8FF1}>)[:EXTERNAL]
 13: (ERROR UNDEFINED-FUNCTION)[:EXTERNAL]
 14: (SB-KERNEL::UNDEFINED-FUN-ERROR-HANDLER #<unavailable argument> #.(SB-SYS:INT-SAP #XB6561D10) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #XB6561A1C :TYPE (* (STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (14))
 15: (SB-KERNEL:INTERNAL-ERROR #.(SB-SYS:INT-SAP #XB6561A1C) #<unavailable argument>)
 16: ("foreign function: #x806726B")
 17: ("foreign function: #x8052FE8")
 18: ("foreign function: #x805872E")
 19: ("foreign function: #x8056E2B")
 --more--

Is this a known problem?

 TIA Ralf Mattes




From martin.loetzsch at gmail.com  Wed Feb 17 15:37:25 2010
From: martin.loetzsch at gmail.com (Martin Loetzsch)
Date: Wed, 17 Feb 2010 16:37:25 +0100
Subject: [hunchentoot-devel] Cl-WebDAV broken?
In-Reply-To: <1266419938.7243.3.camel@mhflaptop01>
References: <1266419938.7243.3.camel@mhflaptop01>
Message-ID: <F57F7832-FE5B-4D7F-A1B3-E3071F042BC5@gmail.com>

Since Hunchentoot 1.0, a lot of functions for setting HTTP header  
informations changed their name from foo to foo*.

So you can fix this in your copy by calling content-type* instead of  
content-type
http://www.weitz.de/hunchentoot/#content-type*

But that of course doesn't fix the svn.

Best, Martin

On Feb 17, 2010, at 4:18 PM, Ralf Mattes wrote:

> Hello list,
>
> this is with a fresh svn checkout from:
> svn://bknr.net/svn/trunk/thirdparty/hunchentoot
> svn://bknr.net/svn/trunk/thirdparty/cl-webdav
>
>
> In a shell:
>
>  cadaver http://localhost:4243/
>
> triggers the following backtrace:
>
> The function (SETF HUNCHENTOOT:CONTENT-TYPE) is undefined.
>   [Condition of type UNDEFINED-FUNCTION]
>
> Restarts:
> 0: [TERMINATE-THREAD] Terminate this thread (#<THREAD "Hunchentoot  
> worker (client: 127.0.0.1:35255)" RUNNING {C164E19}>)
>
> Backtrace:
>  0: ((LAMBDA (SWANK-BACKEND::DEBUGGER-LOOP-FN)) #<FUNCTION (LAMBDA  
> #) {AF28C2D}>)
>  1: (SWANK::DEBUG-IN-EMACS #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE)  
> {C1B8FF1}>)
>  2: (SWANK-BACKEND::CALL-WITH-BREAK-HOOK #<FUNCTION SWANK:SWANK- 
> DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {C1B909D}>)
>  3: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION  
> SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {C1B909D}>)
>  4: (SWANK::CALL-WITH-BINDINGS ..)
>  5: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {B366A09}>  
> #<CLOSURE (LAMBDA #) {C1B909D}>)
>  6: (SWANK:INVOKE-SLIME-DEBUGGER #<UNDEFINED-FUNCTION (SETF CONTENT- 
> TYPE) {C1B8FF1}>)
>  7: (SWANK-BACKEND::CALL-WITH-BREAK-HOOK #<FUNCTION SWANK:SWANK- 
> DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {C1B907D}>)
>  8: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION  
> SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {C1B907D}>)
>  9: (SWANK:SWANK-DEBUGGER-HOOK #<UNDEFINED-FUNCTION (SETF CONTENT- 
> TYPE) {C1B8FF1}> #<unavailable argument>)
> 10: (INVOKE-DEBUGGER #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE)  
> {C1B8FF1}>)
> 11: ((SB-PCL::FAST-METHOD HUNCHENTOOT:MAYBE-INVOKE-DEBUGGER (T))  
> #<unavailable argument> #<unavailable argument> #<UNDEFINED-FUNCTION  
> (SETF CONTENT-TYPE) {C1B8FF1}>)
> 12: (SIGNAL #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE) {C1B8FF1}>) 
> [:EXTERNAL]
> 13: (ERROR UNDEFINED-FUNCTION)[:EXTERNAL]
> 14: (SB-KERNEL::UNDEFINED-FUN-ERROR-HANDLER #<unavailable argument>  
> #.(SB-SYS:INT-SAP #XB6561D10) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP  
> #XB6561A1C :TYPE (* (STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (14))
> 15: (SB-KERNEL:INTERNAL-ERROR #.(SB-SYS:INT-SAP #XB6561A1C)  
> #<unavailable argument>)
> 16: ("foreign function: #x806726B")
> 17: ("foreign function: #x8052FE8")
> 18: ("foreign function: #x805872E")
> 19: ("foreign function: #x8056E2B")
> --more--
>
> Is this a known problem?
>
> TIA Ralf Mattes
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel




From mjcurry at gmail.com  Wed Feb 17 15:46:54 2010
From: mjcurry at gmail.com (Matthew Curry)
Date: Wed, 17 Feb 2010 10:46:54 -0500
Subject: [hunchentoot-devel] Cl-WebDAV broken?
In-Reply-To: <1266419938.7243.3.camel@mhflaptop01>
References: <1266419938.7243.3.camel@mhflaptop01>
Message-ID: <75b4567b1002170746w76e66bc7pf59c9129dd9916c9@mail.gmail.com>

Well, cl-webdav had not been brought fully up to speed with
hunchentoot v1.x yet.  I submitted a simple patch to get some
cl-webdav commands working (basically what Martin notes: <function> to
<function>*) although that alone doesn't get all the commands working
(but I thought the command you ran was working last I looked at it).
I haven't finished with it yet, so this is my bad, as Edi asked me to
look at it awhile ago, and I got busy with other things.

-Matt



On Wed, Feb 17, 2010 at 10:18 AM, Ralf Mattes <rm at seid-online.de> wrote:
> Hello list,
>
> this is with a fresh svn checkout from:
> ?svn://bknr.net/svn/trunk/thirdparty/hunchentoot
> ?svn://bknr.net/svn/trunk/thirdparty/cl-webdav
>
>
> In a shell:
>
> ?cadaver http://localhost:4243/
>
> triggers the following backtrace:
>
> The function (SETF HUNCHENTOOT:CONTENT-TYPE) is undefined.
> ? [Condition of type UNDEFINED-FUNCTION]
>
> Restarts:
> ?0: [TERMINATE-THREAD] Terminate this thread (#<THREAD "Hunchentoot worker (client: 127.0.0.1:35255)" RUNNING {C164E19}>)
>
> Backtrace:
> ?0: ((LAMBDA (SWANK-BACKEND::DEBUGGER-LOOP-FN)) #<FUNCTION (LAMBDA #) {AF28C2D}>)
> ?1: (SWANK::DEBUG-IN-EMACS #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE) {C1B8FF1}>)
> ?2: (SWANK-BACKEND::CALL-WITH-BREAK-HOOK #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {C1B909D}>)
> ?3: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {C1B909D}>)
> ?4: (SWANK::CALL-WITH-BINDINGS ..)
> ?5: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {B366A09}> #<CLOSURE (LAMBDA #) {C1B909D}>)
> ?6: (SWANK:INVOKE-SLIME-DEBUGGER #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE) {C1B8FF1}>)
> ?7: (SWANK-BACKEND::CALL-WITH-BREAK-HOOK #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {C1B907D}>)
> ?8: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {C1B907D}>)
> ?9: (SWANK:SWANK-DEBUGGER-HOOK #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE) {C1B8FF1}> #<unavailable argument>)
> ?10: (INVOKE-DEBUGGER #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE) {C1B8FF1}>)
> ?11: ((SB-PCL::FAST-METHOD HUNCHENTOOT:MAYBE-INVOKE-DEBUGGER (T)) #<unavailable argument> #<unavailable argument> #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE) {C1B8FF1}>)
> ?12: (SIGNAL #<UNDEFINED-FUNCTION (SETF CONTENT-TYPE) {C1B8FF1}>)[:EXTERNAL]
> ?13: (ERROR UNDEFINED-FUNCTION)[:EXTERNAL]
> ?14: (SB-KERNEL::UNDEFINED-FUN-ERROR-HANDLER #<unavailable argument> #.(SB-SYS:INT-SAP #XB6561D10) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #XB6561A1C :TYPE (* (STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (14))
> ?15: (SB-KERNEL:INTERNAL-ERROR #.(SB-SYS:INT-SAP #XB6561A1C) #<unavailable argument>)
> ?16: ("foreign function: #x806726B")
> ?17: ("foreign function: #x8052FE8")
> ?18: ("foreign function: #x805872E")
> ?19: ("foreign function: #x8056E2B")
> ?--more--
>
> Is this a known problem?
>
> ?TIA Ralf Mattes
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



From rm at seid-online.de  Wed Feb 17 20:11:02 2010
From: rm at seid-online.de (Ralf Mattes)
Date: Wed, 17 Feb 2010 21:11:02 +0100
Subject: [hunchentoot-devel] PATCH: Some minor fixes for cl-webdav under
 hunchentoot 1.0
In-Reply-To: <b56421a00911152306u36ab78b6kfef09f449269016f@mail.gmail.com>
References: <75b4567b0911151829u4fd9358bufff4bd7c482cd849@mail.gmail.com>
	<b56421a00911152306u36ab78b6kfef09f449269016f@mail.gmail.com>
Message-ID: <1266437462.7337.3.camel@mhflaptop01>

On Mon, 2009-11-16 at 08:06 +0100, Edi Weitz wrote:
> On Mon, Nov 16, 2009 at 3:29 AM, Matthew Curry <mjcurry at gmail.com> wrote:
> 
> > I took a look at it tonight anyway, and there where some obvious minor
> > fixes I spotted right away, attached is a patch that gets (using
> > cadaver) an initial connection, a put, and a get to work.  Just
> > functions that were renamed in the new hunchentoot.
> 
> Thanks a lot, it's in the repository now.

What's going on here? I can't find the changes to handlers.lisp from
that patch in the current svn version - the changes to resources.lisp
seem to be there. How can that happen?

> > Delete doesn't work, complains about a handler-done tag being unknown
> > (but thrown).  Here's the message log entry:
> > [2009-11-15 20:55:06 [ERROR]] attempt to THROW to a tag that does not
> > exist: HANDLER-DONE
> > I'm not too familiar with older versions of hunchentoot, does that
> > ring a bell for you?
> 
> I think I've fixed that now (untested):
> 
> http://bknr.net/trac/changeset/4471/trunk/thirdparty/cl-webdav
> 
> > I'll keep looking.
> 
> Maybe we should just release it now and see if someone complains?  I
> doubt that anybody really uses cl-webdav for serious work.

Autsch! I do ... until today's update :-/


 Cheers, RalfD

> Thanks again,
> Edi.
> 
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel





From rm at seid-online.de  Wed Feb 17 20:12:58 2010
From: rm at seid-online.de (Ralf Mattes)
Date: Wed, 17 Feb 2010 21:12:58 +0100
Subject: [hunchentoot-devel] Cl-WebDAV broken?
In-Reply-To: <75b4567b1002170746w76e66bc7pf59c9129dd9916c9@mail.gmail.com>
References: <1266419938.7243.3.camel@mhflaptop01>
	<75b4567b1002170746w76e66bc7pf59c9129dd9916c9@mail.gmail.com>
Message-ID: <1266437578.7337.5.camel@mhflaptop01>

On Wed, 2010-02-17 at 10:46 -0500, Matthew Curry wrote:
> Well, cl-webdav had not been brought fully up to speed with
> hunchentoot v1.x yet.  I submitted a simple patch to get some
> cl-webdav commands working (basically what Martin notes: <function> to
> <function>*) although that alone doesn't get all the commands working
> (but I thought the command you ran was working last I looked at it).

Looks like Edi didn't apply all of that patch. 

> I haven't finished with it yet, so this is my bad, as Edi asked me to
> look at it awhile ago, and I got busy with other things.

I'll try to fix it locally and maybe send a patch. 

 Thank's for your time 

  RalfD

> -Matt







From edi at agharta.de  Thu Feb 18 10:35:50 2010
From: edi at agharta.de (Edi Weitz)
Date: Thu, 18 Feb 2010 11:35:50 +0100
Subject: [hunchentoot-devel] PATCH: Some minor fixes for cl-webdav under
	hunchentoot 1.0
In-Reply-To: <1266437462.7337.3.camel@mhflaptop01>
References: <75b4567b0911151829u4fd9358bufff4bd7c482cd849@mail.gmail.com>
	<b56421a00911152306u36ab78b6kfef09f449269016f@mail.gmail.com>
	<1266437462.7337.3.camel@mhflaptop01>
Message-ID: <b56421a01002180235xeab0a0tc82d0555a9da928f@mail.gmail.com>

On Wed, Feb 17, 2010 at 9:11 PM, Ralf Mattes <rm at seid-online.de> wrote:

> What's going on here? I can't find the changes to handlers.lisp from
> that patch in the current svn version - the changes to resources.lisp
> seem to be there. How can that happen?

Aren't these the ones you were looking for?

http://bknr.net/trac/changeset/3339/trunk/thirdparty/cl-webdav



From edi at agharta.de  Thu Feb 18 10:38:16 2010
From: edi at agharta.de (Edi Weitz)
Date: Thu, 18 Feb 2010 11:38:16 +0100
Subject: [hunchentoot-devel] Cl-WebDAV broken?
In-Reply-To: <1266437578.7337.5.camel@mhflaptop01>
References: <1266419938.7243.3.camel@mhflaptop01>
	<75b4567b1002170746w76e66bc7pf59c9129dd9916c9@mail.gmail.com>
	<1266437578.7337.5.camel@mhflaptop01>
Message-ID: <b56421a01002180238y7ea8b71coa03bb7efa0b82eed@mail.gmail.com>

On Wed, Feb 17, 2010 at 9:12 PM, Ralf Mattes <rm at seid-online.de> wrote:

> Looks like Edi didn't apply all of that patch.

Hmm, I just looked at this again and it seems I /wrote/ that I applied
the patch but in fact I didn't.  Cough...

Let's see...



From rm at seid-online.de  Thu Feb 18 10:45:21 2010
From: rm at seid-online.de (Ralf Mattes)
Date: Thu, 18 Feb 2010 11:45:21 +0100
Subject: [hunchentoot-devel] PATCH: Some minor fixes for cl-webdav under
 hunchentoot 1.0
In-Reply-To: <b56421a01002180235xeab0a0tc82d0555a9da928f@mail.gmail.com>
References: <75b4567b0911151829u4fd9358bufff4bd7c482cd849@mail.gmail.com>
	<b56421a00911152306u36ab78b6kfef09f449269016f@mail.gmail.com>
	<1266437462.7337.3.camel@mhflaptop01>
	<b56421a01002180235xeab0a0tc82d0555a9da928f@mail.gmail.com>
Message-ID: <1266489921.7418.8.camel@mhflaptop01>

On Thu, 2010-02-18 at 11:35 +0100, Edi Weitz wrote:
> On Wed, Feb 17, 2010 at 9:11 PM, Ralf Mattes <rm at seid-online.de> wrote:
> 
> > What's going on here? I can't find the changes to handlers.lisp from
> > that patch in the current svn version - the changes to resources.lisp
> > seem to be there. How can that happen?
> 
> Aren't these the ones you were looking for?
> 
> http://bknr.net/trac/changeset/3339/trunk/thirdparty/cl-webdav

Hallo Edi,

yes, these _are_ the patches (and they are trivial so I already fixed
the code locally). My problem was/is: a fresh svn checkout like this:

ralf at mhflaptop01:/tmp$ svn co svn://bknr.net/svn/trunk/thirdparty/cl-webdav
A    cl-webdav/resources.lisp
A    cl-webdav/properties.lisp
A    cl-webdav/util.lisp
A    cl-webdav/packages.lisp
A    cl-webdav/CHANGELOG.txt
A    cl-webdav/doc
A    cl-webdav/doc/index.html
A    cl-webdav/doc/CVS
A    cl-webdav/doc/CVS/Repository
A    cl-webdav/doc/CVS/Root
A    cl-webdav/doc/CVS/Entries
A    cl-webdav/doc/dav.png
A    cl-webdav/handlers.lisp
A    cl-webdav/xml.lisp
A    cl-webdav/authorized-file-resources.lisp
A    cl-webdav/specials.lisp
A    cl-webdav/cl-webdav.asd
A    cl-webdav/file-resources.lisp
Checked out revision 4511.
ralf at mhflaptop01:/tmp$ grep content-type cl-webdav/handlers.lisp 
      (setf (content-type) "text/xml; charset=utf-8"                      <---- What happend to the patch?
      (setf (content-type) "text/xml; charset=utf-8"
      (setf (content-type) (resource-content-type resource))
  (setf (content-type) "text/xml; charset=utf-8"
                                          (content-type) nil)


Something seems utterly strange here. BTW, that svn url is the one used
in bknr's "ediware" svn repository - is this out of date?

Cheers RalfD





From edi at agharta.de  Thu Feb 18 10:52:06 2010
From: edi at agharta.de (Edi Weitz)
Date: Thu, 18 Feb 2010 11:52:06 +0100
Subject: [hunchentoot-devel] PATCH: Some minor fixes for cl-webdav under
	hunchentoot 1.0
In-Reply-To: <1266489921.7418.8.camel@mhflaptop01>
References: <75b4567b0911151829u4fd9358bufff4bd7c482cd849@mail.gmail.com>
	<b56421a00911152306u36ab78b6kfef09f449269016f@mail.gmail.com>
	<1266437462.7337.3.camel@mhflaptop01>
	<b56421a01002180235xeab0a0tc82d0555a9da928f@mail.gmail.com>
	<1266489921.7418.8.camel@mhflaptop01>
Message-ID: <b56421a01002180252r393c4b49g7a234a8347883f98@mail.gmail.com>

I think the problem was that my checkout was somehow botched.  I just
tried to clean up the mess.  Please check if it works now.  If you're
OK with the changes, we can make this an official release.  (Now that
I know that there /is/ one user... :)

And, yes, the URL should be right.


On Thu, Feb 18, 2010 at 11:45 AM, Ralf Mattes <rm at seid-online.de> wrote:
> On Thu, 2010-02-18 at 11:35 +0100, Edi Weitz wrote:
>> On Wed, Feb 17, 2010 at 9:11 PM, Ralf Mattes <rm at seid-online.de> wrote:
>>
>> > What's going on here? I can't find the changes to handlers.lisp from
>> > that patch in the current svn version - the changes to resources.lisp
>> > seem to be there. How can that happen?
>>
>> Aren't these the ones you were looking for?
>>
>> http://bknr.net/trac/changeset/3339/trunk/thirdparty/cl-webdav
>
> Hallo Edi,
>
> yes, these _are_ the patches (and they are trivial so I already fixed
> the code locally). My problem was/is: a fresh svn checkout like this:
>
> ralf at mhflaptop01:/tmp$ svn co svn://bknr.net/svn/trunk/thirdparty/cl-webdav
> A ? ?cl-webdav/resources.lisp
> A ? ?cl-webdav/properties.lisp
> A ? ?cl-webdav/util.lisp
> A ? ?cl-webdav/packages.lisp
> A ? ?cl-webdav/CHANGELOG.txt
> A ? ?cl-webdav/doc
> A ? ?cl-webdav/doc/index.html
> A ? ?cl-webdav/doc/CVS
> A ? ?cl-webdav/doc/CVS/Repository
> A ? ?cl-webdav/doc/CVS/Root
> A ? ?cl-webdav/doc/CVS/Entries
> A ? ?cl-webdav/doc/dav.png
> A ? ?cl-webdav/handlers.lisp
> A ? ?cl-webdav/xml.lisp
> A ? ?cl-webdav/authorized-file-resources.lisp
> A ? ?cl-webdav/specials.lisp
> A ? ?cl-webdav/cl-webdav.asd
> A ? ?cl-webdav/file-resources.lisp
> Checked out revision 4511.
> ralf at mhflaptop01:/tmp$ grep content-type cl-webdav/handlers.lisp
> ? ? ?(setf (content-type) "text/xml; charset=utf-8" ? ? ? ? ? ? ? ? ? ? ?<---- What happend to the patch?
> ? ? ?(setf (content-type) "text/xml; charset=utf-8"
> ? ? ?(setf (content-type) (resource-content-type resource))
> ?(setf (content-type) "text/xml; charset=utf-8"
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(content-type) nil)
>
>
> Something seems utterly strange here. BTW, that svn url is the one used
> in bknr's "ediware" svn repository - is this out of date?
>
> Cheers RalfD
>
>
>



From rm at seid-online.de  Thu Feb 18 11:39:55 2010
From: rm at seid-online.de (Ralf Mattes)
Date: Thu, 18 Feb 2010 12:39:55 +0100
Subject: [hunchentoot-devel] PATCH: Some minor fixes for cl-webdav under
 hunchentoot 1.0
In-Reply-To: <b56421a01002180252r393c4b49g7a234a8347883f98@mail.gmail.com>
References: <75b4567b0911151829u4fd9358bufff4bd7c482cd849@mail.gmail.com>
	<b56421a00911152306u36ab78b6kfef09f449269016f@mail.gmail.com>
	<1266437462.7337.3.camel@mhflaptop01>
	<b56421a01002180235xeab0a0tc82d0555a9da928f@mail.gmail.com>
	<1266489921.7418.8.camel@mhflaptop01>
	<b56421a01002180252r393c4b49g7a234a8347883f98@mail.gmail.com>
Message-ID: <1266493195.7418.11.camel@mhflaptop01>

On Thu, 2010-02-18 at 11:52 +0100, Edi Weitz wrote:
> I think the problem was that my checkout was somehow botched.  I just
> tried to clean up the mess.  Please check if it works now.  If you're
> OK with the changes, we can make this an official release.  (Now that
> I know that there /is/ one user... :)

O.k. - first tests look promising. BTW, where is the source for the
documentation? I'd like to send a patch ...

 Cheers, RalfD
> And, yes, the URL should be right.
> 
> 





From edi at agharta.de  Thu Feb 18 12:10:30 2010
From: edi at agharta.de (Edi Weitz)
Date: Thu, 18 Feb 2010 13:10:30 +0100
Subject: [hunchentoot-devel] PATCH: Some minor fixes for cl-webdav under
	hunchentoot 1.0
In-Reply-To: <1266493195.7418.11.camel@mhflaptop01>
References: <75b4567b0911151829u4fd9358bufff4bd7c482cd849@mail.gmail.com>
	<b56421a00911152306u36ab78b6kfef09f449269016f@mail.gmail.com>
	<1266437462.7337.3.camel@mhflaptop01>
	<b56421a01002180235xeab0a0tc82d0555a9da928f@mail.gmail.com>
	<1266489921.7418.8.camel@mhflaptop01>
	<b56421a01002180252r393c4b49g7a234a8347883f98@mail.gmail.com>
	<1266493195.7418.11.camel@mhflaptop01>
Message-ID: <b56421a01002180410l58526d5fm43e66a70f96a4419@mail.gmail.com>

On Thu, Feb 18, 2010 at 12:39 PM, Ralf Mattes <rm at seid-online.de> wrote:
> BTW, where is the source for the
> documentation?

Should be included in your checkout.  (The HTML /is/ the source.)

http://weitz.de/patches.html



From rm at seid-online.de  Thu Feb 18 12:35:24 2010
From: rm at seid-online.de (Ralf Mattes)
Date: Thu, 18 Feb 2010 13:35:24 +0100
Subject: [hunchentoot-devel] PATCH: Some minor fixes for cl-webdav under
 hunchentoot 1.0
In-Reply-To: <b56421a01002180410l58526d5fm43e66a70f96a4419@mail.gmail.com>
References: <75b4567b0911151829u4fd9358bufff4bd7c482cd849@mail.gmail.com>
	<b56421a00911152306u36ab78b6kfef09f449269016f@mail.gmail.com>
	<1266437462.7337.3.camel@mhflaptop01>
	<b56421a01002180235xeab0a0tc82d0555a9da928f@mail.gmail.com>
	<1266489921.7418.8.camel@mhflaptop01>
	<b56421a01002180252r393c4b49g7a234a8347883f98@mail.gmail.com>
	<1266493195.7418.11.camel@mhflaptop01>
	<b56421a01002180410l58526d5fm43e66a70f96a4419@mail.gmail.com>
Message-ID: <1266496524.7418.13.camel@mhflaptop01>

On Thu, 2010-02-18 at 13:10 +0100, Edi Weitz wrote:
> On Thu, Feb 18, 2010 at 12:39 PM, Ralf Mattes <rm at seid-online.de> wrote:
> > BTW, where is the source for the
> > documentation?
> 
> Should be included in your checkout.  (The HTML /is/ the source.)
> 
> http://weitz.de/patches.html

Ok, here's a trivial doc patch (see attachment)

 Cheers, RalfD

P.S.: It might be a good idea to mention that JavaScipt need to be
enabled to see the documentation - I often get bitten by garbled doc
formatting without enabling JavaScript ...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: doc-patch.diff
Type: text/x-patch
Size: 627 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20100218/062ae0ca/attachment.bin>

From edi at agharta.de  Thu Feb 18 13:02:53 2010
From: edi at agharta.de (Edi Weitz)
Date: Thu, 18 Feb 2010 14:02:53 +0100
Subject: [hunchentoot-devel] PATCH: Some minor fixes for cl-webdav under
	hunchentoot 1.0
In-Reply-To: <1266496524.7418.13.camel@mhflaptop01>
References: <75b4567b0911151829u4fd9358bufff4bd7c482cd849@mail.gmail.com>
	<b56421a00911152306u36ab78b6kfef09f449269016f@mail.gmail.com>
	<1266437462.7337.3.camel@mhflaptop01>
	<b56421a01002180235xeab0a0tc82d0555a9da928f@mail.gmail.com>
	<1266489921.7418.8.camel@mhflaptop01>
	<b56421a01002180252r393c4b49g7a234a8347883f98@mail.gmail.com>
	<1266493195.7418.11.camel@mhflaptop01>
	<b56421a01002180410l58526d5fm43e66a70f96a4419@mail.gmail.com>
	<1266496524.7418.13.camel@mhflaptop01>
Message-ID: <b56421a01002180502v2d4feeaeva1d9f26d10bc9d13@mail.gmail.com>

On Thu, Feb 18, 2010 at 1:35 PM, Ralf Mattes <rm at seid-online.de> wrote:

> Ok, here's a trivial doc patch (see attachment)

Thanks, applied.

> P.S.: It might be a good idea to mention that JavaScipt need to be
> enabled to see the documentation - I often get bitten by garbled doc
> formatting without enabling JavaScript ...

You mean the Hunchentoot documentation or CL-WEBDAV's?  I think in the
case of Hunchentoot's documentation there's no easy way to show such a
message, but maybe Hans can chime in.



From rm at seid-online.de  Thu Feb 18 14:17:57 2010
From: rm at seid-online.de (Ralf Mattes)
Date: Thu, 18 Feb 2010 15:17:57 +0100
Subject: [hunchentoot-devel] PATCH: Some minor fixes for cl-webdav under
 hunchentoot 1.0
In-Reply-To: <b56421a01002180502v2d4feeaeva1d9f26d10bc9d13@mail.gmail.com>
References: <75b4567b0911151829u4fd9358bufff4bd7c482cd849@mail.gmail.com>
	<b56421a00911152306u36ab78b6kfef09f449269016f@mail.gmail.com>
	<1266437462.7337.3.camel@mhflaptop01>
	<b56421a01002180235xeab0a0tc82d0555a9da928f@mail.gmail.com>
	<1266489921.7418.8.camel@mhflaptop01>
	<b56421a01002180252r393c4b49g7a234a8347883f98@mail.gmail.com>
	<1266493195.7418.11.camel@mhflaptop01>
	<b56421a01002180410l58526d5fm43e66a70f96a4419@mail.gmail.com>
	<1266496524.7418.13.camel@mhflaptop01>
	<b56421a01002180502v2d4feeaeva1d9f26d10bc9d13@mail.gmail.com>
Message-ID: <1266502677.7418.20.camel@mhflaptop01>

On Thu, 2010-02-18 at 14:02 +0100, Edi Weitz wrote:
> On Thu, Feb 18, 2010 at 1:35 PM, Ralf Mattes <rm at seid-online.de> wrote:
> 
> > Ok, here's a trivial doc patch (see attachment)
> 
> Thanks, applied.
> 
> > P.S.: It might be a good idea to mention that JavaScipt need to be
> > enabled to see the documentation - I often get bitten by garbled doc
> > formatting without enabling JavaScript ...
> 
> You mean the Hunchentoot documentation or CL-WEBDAV's?  I think in the
> case of Hunchentoot's documentation there's no easy way to show such a
> message, but maybe Hans can chime in.

CL-WebDAV, mainly:

<noscript>Please enable JavaScipt for proper formatting </noscript>

For hunchentoot:  maybe serverside rendering ...


 cheers, RalfD
 




From edi at agharta.de  Thu Feb 18 14:52:16 2010
From: edi at agharta.de (Edi Weitz)
Date: Thu, 18 Feb 2010 15:52:16 +0100
Subject: [hunchentoot-devel] PATCH: Some minor fixes for cl-webdav under
	hunchentoot 1.0
In-Reply-To: <1266502677.7418.20.camel@mhflaptop01>
References: <75b4567b0911151829u4fd9358bufff4bd7c482cd849@mail.gmail.com>
	<1266437462.7337.3.camel@mhflaptop01>
	<b56421a01002180235xeab0a0tc82d0555a9da928f@mail.gmail.com>
	<1266489921.7418.8.camel@mhflaptop01>
	<b56421a01002180252r393c4b49g7a234a8347883f98@mail.gmail.com>
	<1266493195.7418.11.camel@mhflaptop01>
	<b56421a01002180410l58526d5fm43e66a70f96a4419@mail.gmail.com>
	<1266496524.7418.13.camel@mhflaptop01>
	<b56421a01002180502v2d4feeaeva1d9f26d10bc9d13@mail.gmail.com>
	<1266502677.7418.20.camel@mhflaptop01>
Message-ID: <b56421a01002180652t48553b0era497942eb9f8b558@mail.gmail.com>

On Thu, Feb 18, 2010 at 3:17 PM, Ralf Mattes <rm at seid-online.de> wrote:

> CL-WebDAV, mainly:
>
> <noscript>Please enable JavaScipt for proper formatting </noscript>

Where does the CL-WEBDAV page use Javascript?

> For hunchentoot: ?maybe serverside rendering ...

Definitely not.  Too much work and you couldn't use it offline anymore.



From patrick.may at mac.com  Fri Feb 19 11:48:56 2010
From: patrick.may at mac.com (Patrick May)
Date: Fri, 19 Feb 2010 06:48:56 -0500
Subject: [hunchentoot-devel] hunchentoot-mp
Message-ID: <41ED5A4D-5CFA-450E-A5C9-5D303533B59C@mac.com>

	While looking for examples of locking within Hunchentoot, I came across a blog post from late 2007 that mentioned hunchentoot-mp and the make-lock / with-lock functionality.  Is this still supported?  Has it been renamed?  Is there any documentation?

Thanks,

Patrick

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2421 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20100219/0ae587fa/attachment.bin>

From edi at agharta.de  Fri Feb 19 13:51:40 2010
From: edi at agharta.de (Edi Weitz)
Date: Fri, 19 Feb 2010 14:51:40 +0100
Subject: [hunchentoot-devel] hunchentoot-mp
In-Reply-To: <41ED5A4D-5CFA-450E-A5C9-5D303533B59C@mac.com>
References: <41ED5A4D-5CFA-450E-A5C9-5D303533B59C@mac.com>
Message-ID: <b56421a01002190551r7abc9ca1n50b3981ffd538b7@mail.gmail.com>

It has been replaced by Bordeaux Threads.

Edi.


On Fri, Feb 19, 2010 at 12:48 PM, Patrick May <patrick.may at mac.com> wrote:
> ? ? ? ?While looking for examples of locking within Hunchentoot, I came across a blog post from late 2007 that mentioned hunchentoot-mp and the make-lock / with-lock functionality. ?Is this still supported? ?Has it been renamed? ?Is there any documentation?
>
> Thanks,
>
> Patrick
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



From patrick.may at mac.com  Fri Feb 19 16:20:23 2010
From: patrick.may at mac.com (Patrick May)
Date: Fri, 19 Feb 2010 11:20:23 -0500
Subject: [hunchentoot-devel] hunchentoot-mp
In-Reply-To: <b56421a01002190551r7abc9ca1n50b3981ffd538b7@mail.gmail.com>
References: <41ED5A4D-5CFA-450E-A5C9-5D303533B59C@mac.com>
	<b56421a01002190551r7abc9ca1n50b3981ffd538b7@mail.gmail.com>
Message-ID: <FE366A24-C074-42E0-AE23-1351F9C97779@mac.com>

	Thanks.  That means I can use make-lock and with-lock-held within a Hunchentoot application?

Regards,

Patrick

On Feb 19, 2010, at 8:51 AM, Edi Weitz wrote:

> It has been replaced by Bordeaux Threads.
> 
> Edi.
> 
> 
> On Fri, Feb 19, 2010 at 12:48 PM, Patrick May <patrick.may at mac.com> wrote:
>>        While looking for examples of locking within Hunchentoot, I came across a blog post from late 2007 that mentioned hunchentoot-mp and the make-lock / with-lock functionality.  Is this still supported?  Has it been renamed?  Is there any documentation?
>> 
>> Thanks,
>> 
>> Patrick
>> 
>> 
>> _______________________________________________
>> tbnl-devel site list
>> tbnl-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>> 
> 
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2421 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20100219/3cc13d19/attachment.bin>

From edi at agharta.de  Fri Feb 19 18:27:08 2010
From: edi at agharta.de (Edi Weitz)
Date: Fri, 19 Feb 2010 19:27:08 +0100
Subject: [hunchentoot-devel] hunchentoot-mp
In-Reply-To: <FE366A24-C074-42E0-AE23-1351F9C97779@mac.com>
References: <41ED5A4D-5CFA-450E-A5C9-5D303533B59C@mac.com>
	<b56421a01002190551r7abc9ca1n50b3981ffd538b7@mail.gmail.com>
	<FE366A24-C074-42E0-AE23-1351F9C97779@mac.com>
Message-ID: <b56421a01002191027t73ee6066ubcf8325e0ecb6f6b@mail.gmail.com>

Sure, there's no reason not to do it.

On Fri, Feb 19, 2010 at 5:20 PM, Patrick May <patrick.may at mac.com> wrote:
> ? ? ? ?Thanks. ?That means I can use make-lock and with-lock-held within a Hunchentoot application?
>
> Regards,
>
> Patrick
>
> On Feb 19, 2010, at 8:51 AM, Edi Weitz wrote:
>
>> It has been replaced by Bordeaux Threads.
>>
>> Edi.
>>
>>
>> On Fri, Feb 19, 2010 at 12:48 PM, Patrick May <patrick.may at mac.com> wrote:
>>> ? ? ? ?While looking for examples of locking within Hunchentoot, I came across a blog post from late 2007 that mentioned hunchentoot-mp and the make-lock / with-lock functionality. ?Is this still supported? ?Has it been renamed? ?Is there any documentation?
>>>
>>> Thanks,
>>>
>>> Patrick
>>>
>>>
>>> _______________________________________________
>>> tbnl-devel site list
>>> tbnl-devel at common-lisp.net
>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>
>>
>> _______________________________________________
>> tbnl-devel site list
>> tbnl-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



From mjcurry at gmail.com  Sat Feb 20 05:00:32 2010
From: mjcurry at gmail.com (Matthew Curry)
Date: Sat, 20 Feb 2010 00:00:32 -0500
Subject: [hunchentoot-devel] PATCH: Some minor fixes for cl-webdav under
	hunchentoot 1.0
In-Reply-To: <b56421a01002180252r393c4b49g7a234a8347883f98@mail.gmail.com>
References: <75b4567b0911151829u4fd9358bufff4bd7c482cd849@mail.gmail.com> 
	<b56421a00911152306u36ab78b6kfef09f449269016f@mail.gmail.com> 
	<1266437462.7337.3.camel@mhflaptop01>
	<b56421a01002180235xeab0a0tc82d0555a9da928f@mail.gmail.com> 
	<1266489921.7418.8.camel@mhflaptop01>
	<b56421a01002180252r393c4b49g7a234a8347883f98@mail.gmail.com>
Message-ID: <75b4567b1002192100t3476a5d9w8bfa873d21e80dda@mail.gmail.com>

Edi,

Looks like there are a couple of (return-code) -> (return-code*)
renames missing in the svn repository (revision 4513 right now).  One
of them I musta missed in my original patch anyway.
copy/move return a 502 Bad Gateway response, which seems odd, but all
other (supported) cadaver commands seem to work.  patch attached.

-Matt



On Thu, Feb 18, 2010 at 5:52 AM, Edi Weitz <edi at agharta.de> wrote:
> I think the problem was that my checkout was somehow botched. ?I just
> tried to clean up the mess. ?Please check if it works now. ?If you're
> OK with the changes, we can make this an official release. ?(Now that
> I know that there /is/ one user... :)
>
> And, yes, the URL should be right.
>
>
> On Thu, Feb 18, 2010 at 11:45 AM, Ralf Mattes <rm at seid-online.de> wrote:
>> On Thu, 2010-02-18 at 11:35 +0100, Edi Weitz wrote:
>>> On Wed, Feb 17, 2010 at 9:11 PM, Ralf Mattes <rm at seid-online.de> wrote:
>>>
>>> > What's going on here? I can't find the changes to handlers.lisp from
>>> > that patch in the current svn version - the changes to resources.lisp
>>> > seem to be there. How can that happen?
>>>
>>> Aren't these the ones you were looking for?
>>>
>>> http://bknr.net/trac/changeset/3339/trunk/thirdparty/cl-webdav
>>
>> Hallo Edi,
>>
>> yes, these _are_ the patches (and they are trivial so I already fixed
>> the code locally). My problem was/is: a fresh svn checkout like this:
>>
>> ralf at mhflaptop01:/tmp$ svn co svn://bknr.net/svn/trunk/thirdparty/cl-webdav
>> A ? ?cl-webdav/resources.lisp
>> A ? ?cl-webdav/properties.lisp
>> A ? ?cl-webdav/util.lisp
>> A ? ?cl-webdav/packages.lisp
>> A ? ?cl-webdav/CHANGELOG.txt
>> A ? ?cl-webdav/doc
>> A ? ?cl-webdav/doc/index.html
>> A ? ?cl-webdav/doc/CVS
>> A ? ?cl-webdav/doc/CVS/Repository
>> A ? ?cl-webdav/doc/CVS/Root
>> A ? ?cl-webdav/doc/CVS/Entries
>> A ? ?cl-webdav/doc/dav.png
>> A ? ?cl-webdav/handlers.lisp
>> A ? ?cl-webdav/xml.lisp
>> A ? ?cl-webdav/authorized-file-resources.lisp
>> A ? ?cl-webdav/specials.lisp
>> A ? ?cl-webdav/cl-webdav.asd
>> A ? ?cl-webdav/file-resources.lisp
>> Checked out revision 4511.
>> ralf at mhflaptop01:/tmp$ grep content-type cl-webdav/handlers.lisp
>> ? ? ?(setf (content-type) "text/xml; charset=utf-8" ? ? ? ? ? ? ? ? ? ? ?<---- What happend to the patch?
>> ? ? ?(setf (content-type) "text/xml; charset=utf-8"
>> ? ? ?(setf (content-type) (resource-content-type resource))
>> ?(setf (content-type) "text/xml; charset=utf-8"
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(content-type) nil)
>>
>>
>> Something seems utterly strange here. BTW, that svn url is the one used
>> in bknr's "ediware" svn repository - is this out of date?
>>
>> Cheers RalfD
>>
>>
>>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: remaining-webdav.patch
Type: text/x-patch
Size: 1079 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20100220/2ffeaf38/attachment.bin>

From edi at agharta.de  Sun Feb 21 13:04:03 2010
From: edi at agharta.de (Edi Weitz)
Date: Sun, 21 Feb 2010 14:04:03 +0100
Subject: [hunchentoot-devel] PATCH: Some minor fixes for cl-webdav under
	hunchentoot 1.0
In-Reply-To: <75b4567b1002192100t3476a5d9w8bfa873d21e80dda@mail.gmail.com>
References: <75b4567b0911151829u4fd9358bufff4bd7c482cd849@mail.gmail.com>
	<b56421a00911152306u36ab78b6kfef09f449269016f@mail.gmail.com>
	<1266437462.7337.3.camel@mhflaptop01>
	<b56421a01002180235xeab0a0tc82d0555a9da928f@mail.gmail.com>
	<1266489921.7418.8.camel@mhflaptop01>
	<b56421a01002180252r393c4b49g7a234a8347883f98@mail.gmail.com>
	<75b4567b1002192100t3476a5d9w8bfa873d21e80dda@mail.gmail.com>
Message-ID: <b56421a01002210504n2e93d675p41f485fbeeb5e512@mail.gmail.com>

Thanks, I've applied your patches and made a new release (0.2.0) of
cl-webdav which can be downloaded from http://weitz.de/ as usual.


On Sat, Feb 20, 2010 at 6:00 AM, Matthew Curry <mjcurry at gmail.com> wrote:
> Edi,
>
> Looks like there are a couple of (return-code) -> (return-code*)
> renames missing in the svn repository (revision 4513 right now). ?One
> of them I musta missed in my original patch anyway.
> copy/move return a 502 Bad Gateway response, which seems odd, but all
> other (supported) cadaver commands seem to work. ?patch attached.
>
> -Matt
>
>
>
> On Thu, Feb 18, 2010 at 5:52 AM, Edi Weitz <edi at agharta.de> wrote:
>> I think the problem was that my checkout was somehow botched. ?I just
>> tried to clean up the mess. ?Please check if it works now. ?If you're
>> OK with the changes, we can make this an official release. ?(Now that
>> I know that there /is/ one user... :)
>>
>> And, yes, the URL should be right.
>>
>>
>> On Thu, Feb 18, 2010 at 11:45 AM, Ralf Mattes <rm at seid-online.de> wrote:
>>> On Thu, 2010-02-18 at 11:35 +0100, Edi Weitz wrote:
>>>> On Wed, Feb 17, 2010 at 9:11 PM, Ralf Mattes <rm at seid-online.de> wrote:
>>>>
>>>> > What's going on here? I can't find the changes to handlers.lisp from
>>>> > that patch in the current svn version - the changes to resources.lisp
>>>> > seem to be there. How can that happen?
>>>>
>>>> Aren't these the ones you were looking for?
>>>>
>>>> http://bknr.net/trac/changeset/3339/trunk/thirdparty/cl-webdav
>>>
>>> Hallo Edi,
>>>
>>> yes, these _are_ the patches (and they are trivial so I already fixed
>>> the code locally). My problem was/is: a fresh svn checkout like this:
>>>
>>> ralf at mhflaptop01:/tmp$ svn co svn://bknr.net/svn/trunk/thirdparty/cl-webdav
>>> A ? ?cl-webdav/resources.lisp
>>> A ? ?cl-webdav/properties.lisp
>>> A ? ?cl-webdav/util.lisp
>>> A ? ?cl-webdav/packages.lisp
>>> A ? ?cl-webdav/CHANGELOG.txt
>>> A ? ?cl-webdav/doc
>>> A ? ?cl-webdav/doc/index.html
>>> A ? ?cl-webdav/doc/CVS
>>> A ? ?cl-webdav/doc/CVS/Repository
>>> A ? ?cl-webdav/doc/CVS/Root
>>> A ? ?cl-webdav/doc/CVS/Entries
>>> A ? ?cl-webdav/doc/dav.png
>>> A ? ?cl-webdav/handlers.lisp
>>> A ? ?cl-webdav/xml.lisp
>>> A ? ?cl-webdav/authorized-file-resources.lisp
>>> A ? ?cl-webdav/specials.lisp
>>> A ? ?cl-webdav/cl-webdav.asd
>>> A ? ?cl-webdav/file-resources.lisp
>>> Checked out revision 4511.
>>> ralf at mhflaptop01:/tmp$ grep content-type cl-webdav/handlers.lisp
>>> ? ? ?(setf (content-type) "text/xml; charset=utf-8" ? ? ? ? ? ? ? ? ? ? ?<---- What happend to the patch?
>>> ? ? ?(setf (content-type) "text/xml; charset=utf-8"
>>> ? ? ?(setf (content-type) (resource-content-type resource))
>>> ?(setf (content-type) "text/xml; charset=utf-8"
>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(content-type) nil)
>>>
>>>
>>> Something seems utterly strange here. BTW, that svn url is the one used
>>> in bknr's "ediware" svn repository - is this out of date?
>>>
>>> Cheers RalfD
>>>
>>>
>>>
>>
>> _______________________________________________
>> tbnl-devel site list
>> tbnl-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>
>



From edi at agharta.de  Sun Feb 21 13:11:15 2010
From: edi at agharta.de (Edi Weitz)
Date: Sun, 21 Feb 2010 14:11:15 +0100
Subject: [hunchentoot-devel] A potential Hunchentoot/Lispworks(?) fix
In-Reply-To: <4B79D1AF.6000101@gmail.com>
References: <4B733333.9050004@gmail.com> <4B73507F.5090203@gmail.com>
	<4B73A26B.2080303@gmail.com>
	<b56421a01002102255r676ef8ebic13a2c7e93e632ac@mail.gmail.com>
	<4B73B34B.5090003@gmail.com>
	<b56421a01002110151n6c1e4643s87ff5e0be6ec4d18@mail.gmail.com>
	<4B79D1AF.6000101@gmail.com>
Message-ID: <b56421a01002210511s59b29eb0uccff96de34705ed1@mail.gmail.com>

[Cc to mailing list.]

Thanks, that makes sense.  I've applied your patch to the dev version.

Edi.


On Mon, Feb 15, 2010 at 11:58 PM, Matt Lamari <matt.lamari at gmail.com> wrote:
>
> (Thanks to Martin Simmons of Lispworks for this).
>
>
> I'm still testing; but
> in Acceptor.lisp
> process-connection
>
> At the end - change it so, even if the force-output fails, the stream
> will still be closed.
>
> (I'm still testing at my end - this took the leaking problem WAY down)
>
>
> (when *hunchentoot-stream*
> ? ? ? ?;; as we are at the end of the request here, we ignore all
> ? ? ? ?;; errors that may occur while flushing and/or closing the
> ? ? ? ?;; stream.
> ? ? ? ?(ignore-errors*
> ? ? ? ? ?(force-output *hunchentoot-stream*))
> ? ? ? ?(ignore-errors*
> ? ? ? ? ?(close *hunchentoot-stream* :abort t)))
>
> Edi Weitz wrote:
>> On Thu, Feb 11, 2010 at 8:35 AM, Matt Lamari <matt.lamari at gmail.com> wrote:
>>
>>
>>> Sorry to pester you privately; but I was wondering if you could verify
>>> the leak on your Win32 Lispworks before I approach Lispworks.
>>>
>>> I don't know anyone else with a Win32 lispworks.
>>>
>>
>> I'll be out of town for a week and I'm pretty busy right now. ?I
>> wouldn't be able to test anything before end of next week. ?Maybe you
>> should ask on the LW mailing list if you're unsure? ?There are lots of
>> people there using Win32 LW... :)
>>
>
>