This makes no sense at all then. If there is no sharing there should be only one thread in play, so there can't be a thread A and a thread B. I'd love to know where that other thread comes from. It seems like a deeper problem. I added asserts a while back to ensure that a transaction stayed entirely on a single thread. I will add them again and make sure that connection sharing is disabled and see what happens.
john On Thu, Mar 15, 2012 at 11:01 AM, Alan M. Carroll < a...@network-geographics.com> wrote: > Thursday, March 15, 2012, 12:39:08 PM, you wrote: > > > On 3/15/12 10:58 AM, Alan M. Carroll wrote: > >> Thursday, March 15, 2012, 10:43:34 AM, you wrote: > > >>>> 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. > >>> Sorry to butt in, but that was my impression as well. That's also why I > >>> added the option to have a per-thread session pools, enabled via > >>> CONFIG proxy.config.http.share_server_sessions INT 2 > >> What setting disables connection sharing? Setting that value to 0 > doesn't. > > > > Well, with 0, each client VC basically gets its own "pool". I.e. as long > as > > the client VC is alive, any origin connection(s) used by that client VC > is > > tied to that client, and stays alive as either keep-alive lets it stay > up. > > > So, the origin connection is still reused, but never shared. If it does > > indeed get shared, we have a major, major bug (probably blame me....). > > For the situation in my scenario there is no sharing. The two NetVCs in > the HttpServerSession are not shared with any other HttpServerSession (as > far as I can tell and the resulting crash does not require any sharing to > occur). > >
