RE: TS-857 commented on that with a patch. RE: TS-1114, I commented on that. That is a serious bug. We need to get that committed.
john On Sat, Mar 17, 2012 at 8:48 PM, ming....@gmail.com <ming....@gmail.com>wrote: > 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 >
