On Tue, Jun 13, 2017 at 12:56 PM, James Peach wrote:
>
>
> On 11 Jun 2017, at 4:45, Masakazu Kitajo wrote:
>
> On Sun, Jun 11, 2017 at 1:27 PM, James Peach wrote:
>>
>>
>>>
>>> On 9 May 2017, at 0:02, Masakazu Kitajo wrote:
>>>
>>> Hi,
>>>
Don't worry guys. I'm working on it.
On 11 Jun 2017, at 4:45, Masakazu Kitajo wrote:
On Sun, Jun 11, 2017 at 1:27 PM, James Peach
wrote:
On 9 May 2017, at 0:02, Masakazu Kitajo wrote:
Hi,
Don't worry guys. I'm working on it.
I merged the PR to have a draining (shedding) logic for HTTP/2
(Double
GOAWAY frames), and now
On Sun, Jun 11, 2017 at 1:27 PM, James Peach wrote:
>
>
> On 9 May 2017, at 0:02, Masakazu Kitajo wrote:
>
> Hi,
>>
>> Don't worry guys. I'm working on it.
>>
>> I merged the PR to have a draining (shedding) logic for HTTP/2 (Double
>> GOAWAY frames), and now I'm generalizing the flag so that we
On 9 May 2017, at 0:02, Masakazu Kitajo wrote:
Hi,
Don't worry guys. I'm working on it.
I merged the PR to have a draining (shedding) logic for HTTP/2 (Double
GOAWAY frames), and now I'm generalizing the flag so that we can
invoke
draining on both HTTP/1 and HTTP/2. I'm going to add "Connec
On Tue, May 9, 2017 at 11:12 PM, James Peach wrote:
>
>
> On 9 May 2017, at 0:02, Masakazu Kitajo wrote:
>
> Hi,
>>
>> Don't worry guys. I'm working on it.
>>
>> I merged the PR to have a draining (shedding) logic for HTTP/2 (Double
>> GOAWAY frames), and now I'm generalizing the flag so that we
On 9 May 2017, at 0:02, Masakazu Kitajo wrote:
Hi,
Don't worry guys. I'm working on it.
I merged the PR to have a draining (shedding) logic for HTTP/2 (Double
GOAWAY frames), and now I'm generalizing the flag so that we can
invoke
draining on both HTTP/1 and HTTP/2. I'm going to add "Connec
Hi,
Don't worry guys. I'm working on it.
I merged the PR to have a draining (shedding) logic for HTTP/2 (Double
GOAWAY frames), and now I'm generalizing the flag so that we can invoke
draining on both HTTP/1 and HTTP/2. I'm going to add "Connection: close"
header automatically for HTTP/1. So, "pr
I don't disagree. The reasons I chose this way are:
1. We are using other stuff in my team instead of traffic_ctl to manage the
process and do the upgrade.
2. traffic_ctl --drain can only support HTTP and it can only be used when
restarting ATS. That makes it hardly useful in our use case.
2017-05
On 8 May 2017, at 21:48, Miles Libbey wrote:
We'd also like a bit more fine grained control in the process -- we
frequently want to perform maintenance on a server (upgrading ATS;
upgrading the OS; performing hardware changes, etc) after draining but
before restarting ATS. I suppose this would
We'd also like a bit more fine grained control in the process -- we
frequently want to perform maintenance on a server (upgrading ATS;
upgrading the OS; performing hardware changes, etc) after draining but
before restarting ATS. I suppose this would mean allowing the --drain
option to apply to traf
This patch adds another separate shutdown mechanism that only works for
HTTP/2. I think that we really ought to have a single, well-defined
graceful shutdown that works for all protocols.
In HTTP/1.1 it works like this:
- You (possibly dynamically) set
proxy.config.restart.active_client_thres
11 matches
Mail list logo
