Dear Leslie,
Thank you for this patch. I will try to test it by this weekend,
unless Ian wants to.
However, if you will forgive me being dogmatic, it would be even better
if this had a test case with it. For example, I don't think we have any
good examples of producing lots of th
> You know, I think people haven't run into this problem because may web
> servers maintain and reuse pools of worker threads - thus the # of
> connections = max concurrent threads rather than # of sessions/requests.
Hunchentoot seems to spawn a new worker on every incoming request,
or at least g
You know, I think people haven't run into this problem because may web
servers maintain and reuse pools of worker threads - thus the # of
connections = max concurrent threads rather than # of sessions/requests.
Definitely good to have this in there: dangling sockets/file refs are
bad!
Ian
> Elephant-utils has some of the basic thread stuff we need - only need
> to import one or two operators. If we add much more we'll add
> bordeaux as a dependency. Do you want to wrap this up in a bow so we
> can commit it? (Did you test by adding this to the connection
> creation routine in pm-
Elephant-utils has some of the basic thread stuff we need - only need
to import one or two operators. If we add much more we'll add
bordeaux as a dependency. Do you want to wrap this up in a bow so we
can commit it? (Did you test by adding this to the connection
creation routine in pm-co
> Hmmm...I believe that only the first to connect should attempt recovery.
I'm not so sure about that (in fact I think DB_REGISTER is only there
so you can specify DB_RECOVER for every process), but it doesn't really
matter for me as long as it works. The only solution for me therefore
is having
> Ah, you have alot of short-lived threads? A quick look at pm-
> controller.lisp seems to indicate that pm-postmodern does not close
> connections when the thread closes.
Err... amazing that no one else experienced issues with this.
After all not only people using short-lived threads will have
