I think that is a event which is cancelled and destructed, but still running in other thread, the event id in our stack show the same issue as TS-1114, with turnout to be a locking issue, where we should protect all the vol open/write.
the event is free and the same place is filled with other data, and the data may or may not be another same structure. I am just think of that we try to focus on how to do io_close is far away to fix the problem FYI 在 2012-03-17六的 20:35 -0700，John Plevyak写道： > 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). > > > > -- zym, Zhao Yongming. aka: yonghao @ taobao.com
signature.asc
Description: This is a digitally signed message part
