Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nighthawk_client: handle termination signal #280

Closed
oschaaf opened this issue Jan 15, 2020 · 0 comments · Fixed by #367
Closed

nighthawk_client: handle termination signal #280

oschaaf opened this issue Jan 15, 2020 · 0 comments · Fixed by #367
Assignees

Comments

@oschaaf
Copy link
Member

oschaaf commented Jan 15, 2020

It would be nice if nighthawk_client could gracefully and quickly terminate on SIGTERM.
One way to achieve that is by:

  • making the signal handling currently in effect in nighthawk_service shareable.
  • add it to nighthawk_client.

upon signal reception, we could bump a counter.
we can add default termination predicates with a zero threshold to make the workers respond to that.

This gives CLI users a means to let a test run for a while and manually abort it, and still get results out.

oschaaf added a commit to oschaaf/nighthawk that referenced this issue Jan 15, 2020
In preparation of sharing functionality for signal handling,
extract what we have right now into SignalHandler.

Status: draft

For fixing envoyproxy#280

Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
oschaaf added a commit to oschaaf/nighthawk that referenced this issue Jun 16, 2020
With this, --duration 0 will be treated as a request to infinitely
execute. Other default predicates will still exist, to execution
may stop when connection failures or error response codes are
observed.

This leaves some small tech debt:

- We shouldn't need to create a foo root termination predicate
- We need test coverage, but that's much to add once
  envoyproxy#280 or envoyproxy#344 goes in

Fixes envoyproxy#333

Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
mum4k pushed a commit that referenced this issue Jun 18, 2020
In preparation of sharing functionality for signal handling,
extract what we have right now into a `SignalHandler` class.

Preparation for #280

Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
mum4k pushed a commit that referenced this issue Jun 18, 2020
Adds `--no-duration`, which will be treated as a request to infinitely
continue load generation.  Other default predicates will still exist, so\
execution may still stop when connection failures or error response codes
are observed.

This leaves some small tech debt:

- We need test coverage, but that's much easier to add once
  #280 or #344 goes in

Fixes #333

Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
@oschaaf oschaaf self-assigned this Jun 24, 2020
mum4k pushed a commit that referenced this issue Jun 24, 2020
Teach the CLI to handle SIGTERM/SIGINT, and handle those as a request to
gracefully cancel execution.

Partially resolves #280
wjuan-AFK pushed a commit to wjuan-AFK/nighthawk that referenced this issue Jul 14, 2020
Teach the CLI to handle SIGTERM/SIGINT, and handle those as a request to
gracefully cancel execution.

Partially resolves envoyproxy#280
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant