On 5/31/16, 11:22 AM, "Susan Hinrichs" wrote:
>Craig,
>
>Of the bugs you listed below, I'd only look at TS-4309. There are still
>some issues there that oknet points out. But that might be easier to
>debug. If nothing else, your initial read shouldn't be limited to 125
>bytes.
The ini
Craig,
Of the bugs you listed below, I'd only look at TS-4309. There are still
some issues there that oknet points out. But that might be easier to
debug. If nothing else, your initial read shouldn't be limited to 125
bytes.
Looked more closely at your debug output again. Is this the fir
TS-4260 isn't ready to ship yet, so you don't want that. TS-4309 is useful but
only fixes an issue that arises due to timing changes from TS-4260. I'm not
sure about the other two.
On Tuesday, May 31, 2016 9:12 AM, Craig Schomburg (craigs)
wrote:
Susan,
- TS-4309 Reduced SSL upload/downlo
Ah, that's just a limit on write though. All writing needs to happen at the
first available byte so it is naturally constrained. The second block is
checked only so that if the first block is full a new block is *not* allocated
until it is needed. For this same reason it should never be the case
Susan,
Have a few questions in trying to determine what direction we need to go from
our end on our issue.
Due to our pre-release test cycle time we are currently prepared to ship our
next product update using the ATS 6.0.0 code base. Unfortunately we do not
have the test window to move to a
Thanks all,
Between the info from Alan and Chao I think I understand a bit better why we
saw a max of 2 buffer reads (even with my temp tweak). I also was not clear on
how the resumption of the read worked. Think I need to go back and look at
that part again based on Alan’s comment below. Is
gt;
> Craig S.
>
>
> From: Alan Carroll solidwallofc...@yahoo-inc.com>>
> Reply-To: Alan Carroll solidwallofc...@yahoo-inc.com>>
> Date: Friday, May 27, 2016 at 11:09 AM
> To: "dev@trafficserver.apache.org<mailto:dev@trafficserver.apache.org>" <
...@yahoo-inc.com>>
Date: Friday, May 27, 2016 at 11:09 AM
To: "dev@trafficserver.apache.org<mailto:dev@trafficserver.apache.org>"
mailto:dev@trafficserver.apache.org>>
Cc: Craig Schomburg mailto:cra...@cisco.com>>
Subject: Re: SSLNetVConnection IOBufferBlock m
New blocks should be added to the writer chain in
SSLNetVConnection::net_read_io with the call to buf.writer()->read_avail
(because of the type of buf, MIOBufferAccessor, buf.writer() is MIOBuffer* and
its write_avail() should extend the write chain if there is less than the low
water mark of s
There is a PR that uses the buffer interface instead of the block
interface which results in simpler code. We are running this code
internally in Yahoo. It fixed a performance problem introduced by a fix
not yet landed in open source. Since the current code works, I haven't
pushed this PR.
The IOBufferBlock _end and _start should never be reset to free the buffer
space. The block itself should be released and a new one allocated to store
additional information. The buffer block chain can be of arbitrary length, I
haven't seen anywhere in the code that a max length is presumed. Cou
11 matches
Mail list logo
