[plt-scheme] Limiting Concurrent Connections to Web Server

Perhaps I misunderstood, but I think Henk was looking for a different
behavior, ie when there are too many connections in session that the
webserver would just close and forget about the other connections.

Robby

On Fri, Jan 16, 2009 at 7:47 AM, Jay McCarthy <jay.mccarthy at gmail.com> wrote:
> On Thu, Jan 15, 2009 at 11:23 PM, Henk Boom <lunarc.lists at gmail.com> wrote:
>> I tried it in one of the nightly builds, and it seems to maintain the
>> concurrency limit properly. I've noticed, though, that threads
>> belonging to cancelled connections are no longer dropped, though, so
>> if I hit refresh 10 times in firefox with a concurrency limit of 1, it
>> actually does the full calculations for all of the responses one at a
>> time before I get the final response.
>>
>> I can't tell why this happens though, from looking at the above code.
>> Maybe it's because channel-put/get share the property of 'sleep' that
>> prevents the thread from being terminated? (What is that reason, by
>> the way?)
>
> The 'lock' will be released when it is yield or when the thread dies.
> The thread will die in a few different ways: completion (but this will
> cause a yield), exceptions (but this will cause a yield, from
> dynamic-wind), calling `exit' (no yield), or being shutdown by its
> custodian (no yield).
>
> It is unlikely that your code is calling `exit', so the most common
> way for the thread to die unnaturally is when its custodian is
> shutdown. There are a few conditions when the custodian for a
> connection (and thus its handler) is shut-down:
>
> 1. Timeout
> 2. Connection is HTTP/1.0 and first request is received
> 3. Error outputting the response
> 4. Error reading the request
> 5. The request handler is the servlet dispatcher and the servlet calls exit
>
> If the client closes the connection, then there is probably going to
> be an error in #3 or #4, because the port will be written/read and it
> will fail. You'll have to see what your browser is actually doing
> though, because it could be starting a new connection without killing
> the old (leading to #1); it could be using an HTTP/1.1 connection and
> sending a new request along in sequence with the first request, so
> they are all serviced; etc.
>
> You could do a wireshark and see what actually happens to the TCP
> connections. (Or just email a dump to me.)
>
> Jay
>
>
> --
> Jay McCarthy <jay at cs.byu.edu>
> Assistant Professor / Brigham Young University
> http://teammccarthy.org/jay
>
> "The glory of God is Intelligence" - D&C 93
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
>