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

Introduce a toxic that closes a connection after given time period #195

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

mgkeen
Copy link

@mgkeen mgkeen commented Nov 16, 2017

Whilst using toxiproxy to do some testing, i found the timeout toxic didn't quite suit my needs.
If i understand it correctly, the timeout toxic doesn't allow data through at all. I needed a toxic that would allow a connection to carry data, and then cut off after some amount of time.
I took inspiration from the limit_data toxic and introduced a limit_time toxic. There's probably a better name for it that i haven't thought of.

@jpittis
Copy link
Contributor

jpittis commented Nov 24, 2017

Thanks for the PR @mgkeen. I'll try to look at it at some point next week.

Copy link

@Tcoop69 Tcoop69 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can I get approval?

@Shopify Shopify deleted a comment from Tcoop69 Nov 26, 2017
@sl1pm4t
Copy link

sl1pm4t commented May 23, 2018

Thanks for the useful addition @mgkeen.
I found one issue with this Toxic that we hit due to our use case.
The current implementation doesn't work as expected (connection is not killed on timeout) if there is constant traffic on the connection (as was happening in my case with a WebSocket connection that is sending ping / pong every second).

The stub select case: case c := <-stub.Input: trips before any other and elapsed time is not recalculated.

@xmo-odoo
Copy link

Any news on this? I've got to say this is the behaviour I was expecting "timeout" to have, and the cli help didn't make it clear it would prevent all data passthrough entirely.

Though maybe this could be merged into timeout and the traffic block behaviour would be either a separate toxic to combine with, or an attribute on the toxic? In fact it seems to me traffic blocking could be done by setting bandwidth to 0.

Though I guess if you're using the chaotic mode (toxicity != 1) you may want the toxics to always be enabled together… maybe the toxics should be more orthogonal but the toxicity should apply to groups of toxics rather than individual ones?

@mgkeen
Copy link
Author

mgkeen commented Aug 14, 2018

As the previous comments suggest my implementation here probably doesn't work all that well. I might be able to have a go at doing this properly at some point soon, but I'm quite busy these days so there's a good chance that won't happen. If anybody else wants to pick it up then feel free!

@miry
Copy link
Contributor

miry commented Oct 22, 2021

I think there is a way to have same with #333.

$ toxiproxy-cli toxic add --type reset_peer --toxicName "reset_peer" \                            
                       --attribute "timeout=2000" \
                       --toxicity 1.0 http

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 this pull request may close these issues.

7 participants