Looks good. I apologize to weijin and ming_zym for being too distracted to look
closely at those even though I meant to do so. Not being able to replicate the
problem even on old code bases made it problematic as well.
Sunday, March 25, 2012, 5:56:01 PM, you wrote:
I found the problem and it
I really should have looked more closely at what their posts as well. It
took a long time for me to remember how lock switching was supposed to
work. I think it is far too brittle and clearly it was poorly documented.
I am going to add some inline documentation and when I can break some time
Thanks John and AMC, especially for AMC, he contribute a lot to solve
this problem. Thanks again.
I found the problem and it has nothing to do with any of this. The
problem, as quite rightly pointed out by weijin is that when the closed
flag by one thread, another thread can delete the NetVC. This is expected
and desirable, however, unfortunately do_io_close() is accessing the nh
variable
Saturday, March 17, 2012, 10:33:18 PM, you wrote:
On Thu, Mar 15, 2012 at 11:01 AM, Alan M. Carroll
a...@network-geographics.comwrote:
Thursday, March 15, 2012, 9:26:33 AM, you wrote:
[The lock] is only de-allocated after the close() by which time all
references to that NetVC should have
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
On Thu, Mar 15, 2012 at 11:01 AM, Alan M. Carroll
a...@network-geographics.com wrote:
Thursday, March 15, 2012, 9:26:33 AM, you wrote:
[The lock] is only de-allocated after the close() by which time all
references to that NetVC should have been dropped by the client.
Yes, I understand.
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
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.comwrote:
I think that is a event which is cancelled and destructed, but still
running
On Thu, Mar 15, 2012 at 7:05 AM, Alan M. Carroll
a...@network-geographics.com wrote:
Wednesday, March 14, 2012, 9:29:43 PM, John Plevyak wrote:
My view is that this is only one of many failure modes, albeit the most
common one.
I disagree because only in the close case is the lock itself
On 3/14/12 8:29 PM, John Plevyak wrote:
On Wed, Mar 14, 2012 at 8:22 AM, Alan M. Carroll
a...@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
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
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
Thursday, March 15, 2012, 9:26:33 AM, you wrote:
[The lock] is only de-allocated after the close() by which time all
references to that NetVC should have been dropped by the client.
Yes, I understand. What I do not understand is what actual, specific,
implementation mechanism I can use to
Alan:
I think we have make many effort on this issue already, and fairly
sure that we are closing to the root cause of it. From my team side,
we'd like to keep tracking it instead of hiding the issue. please
holding back the commit, and give us more detail on the crashing back
traces as much as
Tuesday, March 13, 2012, 11:46:15 PM, you wrote:
Here are my comments for what they are worth.
First, let me detail the issue this is trying to address.
The way that most clients work with VCs is via and Processor::open_
which calls back with and OPEN event at which point they set VIOs
On Wed, 2012-03-14 at 10:22 -0500, Alan M. Carroll wrote:
Tuesday, March 13, 2012, 11:46:15 PM, you wrote:
Here are my comments for what they are worth.
First, let me detail the issue this is trying to address.
The way that most clients work with VCs is via and Processor::open_
I remember the commit had already reverted and I said the rescheduling
patch have problems in irc.
On Wed, 2012-03-14 at 13:44 -0500, Alan M. Carroll wrote:
One thing that should be noted is that, regardless of whether this patch is a
permanent fix, I think it is clearly superior to the
I have a patch submitted for TS-857 which attempts to make a start on finer
grained locking. The essence of it is
1) Provide more powerful and standards compliant reference counted smart
pointers - lib/ts/IntrusivePtr.h
2) Provide reference counted lists that are compatible with both (1) and
19 matches
Mail list logo
