The default registration delay timeout of elbv2 target group is 300s which is way too long for some simple web applications and user will wait at least 5min when they cdk deploy to kickoff the service rolling update.
see discussion here https://twitter.com/pahudnet/status/1185232660081197056
Users need lower draining timeout and faster ECS service rolling update experience.
To provide a new optional drainingTimeout property for all *LoadBalanced*Service classes. If customer specify the new drainingTimeout duration, CDK update the target group attribute accordingly. Otherwaise, it remains the default 300s.
For example
const webSvc = new ecsPatterns.ApplicationLoadBalancedEc2Service(this, 'webSvc', {
cluster,
taskDefinition,
desiredCount: 3,
drainingTimeout: Duration.seconds(30),
})
To provide new ECS patters for "fast API / web server with no long connections" without surfacing the implementation details.
This is a :rocket: Feature Request
I think short-lived connections are the norm rather than the exceptions. Shouldn't this be the default for all load balanced connections? Or just for ECS?
@rix0rrr Depends on the service type, if you are running websocket service on ECS behind ALB or NLB, it will be a long-lived connection. I agree the default 300s value is way too long, but make it 30s could also break some scenarios with long-lived connections such as websocket or TCP service running on ECS behind NLB.
I understand that, but people in non-common situations can still adjust the timeout (and there should be a discoverable, convenient API for it via a Duration property!).
We should be optimizing for the common case, that helps the most people.
@rix0rrr Agree. Thanks for your input.
Most helpful comment
I understand that, but people in non-common situations can still adjust the timeout (and there should be a discoverable, convenient API for it via a
Durationproperty!).We should be optimizing for the common case, that helps the most people.