I tried this patch and ran some load, w/o an assert. It would seem to
assert that all HttpSM transitions occur on the same thread which would
seem to imply that only one thread ever invoked a given HttpSM. Ideas?
john
diff --git a/proxy/http/HttpSM.cc b/proxy/http/HttpSM.cc
index 2f069ef..ec7f9fa 100644
--- a/proxy/http/HttpSM.cc
+++ b/proxy/http/HttpSM.cc
@@ -338,6 +338,7 @@ HttpSM::HttpSM()
_make_scatter_list(this);
scatter_init = 1;
}
+ ethread = 0;
}
void
@@ -6309,6 +6310,8 @@ HttpSM::dump_state_hdr(HTTPHdr *h, const char *s)
void
HttpSM::call_transact_and_set_next_state(TransactEntryFunc_t f)
{
+ if (!ethread) ethread = this_ethread();
+ ink_release_assert(ethread == this_ethread());
last_action = t_state.next_action; // remember where we were
// The callee can either specify a method to call in to Transact,
diff --git a/proxy/http/HttpSM.h b/proxy/http/HttpSM.h
index 961fe61..30a5e48 100644
--- a/proxy/http/HttpSM.h
+++ b/proxy/http/HttpSM.h
@@ -302,6 +302,7 @@ public:
//AuthHttpAdapter authAdapter;
void set_http_schedule(Continuation *);
int get_http_schedule(int event, void *data);
+ EThread *ethread;
protected:
IOBufferReader * ua_buffer_reader;
On Sat, Mar 17, 2012 at 10:34 PM, John Plevyak <jplev...@acm.org> wrote:
>
> 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
>>
>
>
