> Date: Wed, 14 Mar 2012 19:29:43 -0700
> From: jplev...@acm.org
>
> On Wed, Mar 14, 2012 at 8:22 AM, Alan M. Carroll <
> a...@network-geographics.com> wrote:
>
> >
> > > There is, however, one situation where this simple and safe order of
> > events
> > > is not followed. That is connection sharing to origin servers. Here the
> > > situations starts the same, but when the client is done with the
> > connection
> > > it does not issue a do_io_close(), and this is where the problems can
> > begin.
> >
> > That's not my interpretation of the crashes. We tried various settings for
> > connection sharing to no observed effect on crashing type or frequency. In
> > fact all of the configurations I use for testing have connection sharing
> > disabled.
> >
>
> "As far as I can tell the problem arises when the VCs in a
> HttpServerSession are split across two threads"
>
> This can only occur when there is some connection sharing or if someone has
> introduced a thread switch in some other processor which triggers the OS
> connection. AFAIK the OS connection is initiated on the thread which has
> the client connection and thus, without connection sharing, they should be
> on the same thread.
>
>
> >
> > One might ask, why is HttpServerSession split across threads like that? I
> > have no idea. But it seems to happen much more with forward proxy (note: I
> > have only indirect evidence for that).
> >
>
> I question I have as well. This should not be the case and is going to
> cause performance problems. That said, it should not result in a crash.
>
Might be talking nonsense here, but I'm pretty sure this can also happen if a
plugin uses TSContSched and reenables from the scheduled continuation --
something like:
1) Request comes in and hits the READ_REQ_HDRS
2) Plugin does not reenable, set a scheduled continuation
3) Scheduled continuation activates on another thread, and reenables the
transaction.
--Uri
