trafficserver-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Uri Shachar <ushac...@hotmail.com>
Subject RE: TS-857 and finer grained locking
Date Thu, 15 Mar 2012 16:39:38 GMT

> Date: Wed, 14 Mar 2012 19:29:43 -0700
> From: jplevyak@acm.org
> 
> On Wed, Mar 14, 2012 at 8:22 AM, Alan M. Carroll <
> amc@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
 		 	   		  

Mime
View raw message