Testcontainers-java: Toxiproxy cut connection behavior

Created on 9 Nov 2020  路  4Comments  路  Source: testcontainers/testcontainers-java

Hi!

I'm proxying Kafka broker with Toxiproxy and I found that setConnectionCut all it does is disabling the bandwidth in either directions. This is useful if what you try to simulate a timeout on client side but not if you want to test a closed connection.

Turns out that Toxiproxy supports this closing connection by enable/disable the whole proxy (supported also by the Toxiproxy client). So my question is, can I open a PR with modifications to allowing enable/disable the proxy? Also I would like to update the Toxiproxy version to the latest stable because the default one is not working well with my Kafka version (which is an old one, by the way).

Thanks!

good first issue help wanted resolutioacknowledged

Most helpful comment

Thanks, I didn't know about the default thingy, so turns out I was doing it right already 馃槃

About exposing the Toxy port, what I understand with this decision is that it sort of deprecates the current logic of ToxiproxyContainer.ContainerProxy, right? I mean, what is the purpose of having setConnectionCut and toxics methods if we want users to use their own Toxi client? 馃 I find it confusing because it opens to use mixed approaches: one can use the current approach to cut bandwidth but needs to create another Toxy client to disable proxy.

Either way, I will be happy to implement whatever approach you decide 馃憣馃徑

All 4 comments

Since Testcontainers 1.15.0, we discourage "default" image versions and ask the users to provide a version they want to use.

But there is an opportunity for contribution - adding getToxyPort() or similar method, so that the users can instantiate their own client and perform operations on it.
FTR It is possible even with the current version of ToxiproxyContainer, just one has to know the port number (8474).

Thanks, I didn't know about the default thingy, so turns out I was doing it right already 馃槃

About exposing the Toxy port, what I understand with this decision is that it sort of deprecates the current logic of ToxiproxyContainer.ContainerProxy, right? I mean, what is the purpose of having setConnectionCut and toxics methods if we want users to use their own Toxi client? 馃 I find it confusing because it opens to use mixed approaches: one can use the current approach to cut bandwidth but needs to create another Toxy client to disable proxy.

Either way, I will be happy to implement whatever approach you decide 馃憣馃徑

it is rather an addition to the API that we provide in case you need to do something that is not supported by the module. Think about the currently provided API as a set of shortcuts :)

@bsideup I am not sure if I understand your argument. As @aartigao described it is confusing that a method called setConnectionCut(Boolean) actually does not cut the connection but rather lowers the bandwith to 0. When it comes to toxics, the module itself exposes a ToxicList class which is part of the original Java client. So, the toxic action which is not supported is to close a connection. I am all in for adding methods enable and disable to ToxiproxyContainer.ContainerProxy. If you don't mind, I am more than willing to do it.

Was this page helpful?
0 / 5 - 0 ratings