Open dentarg opened 7 years ago
This is not a bad idea... I'm wondering if there are other use-cases where not having an upstream is useful. For example, would it make sense to have the latency toxic take an optional argument of a response to send back to the client, without an upstream?
I think it make sense in many cases, to be able to specify the response, when the resource your are simulating is an external HTTP resource, which is my use-case... :)
I was first looking at pathod, which seems really nice, but I didn't find out (might not be possible) to make it simulate a timeout, like Toxiproxy.
I think this subject somewhat ties into #50 (maybe just to make it easier to pick between some common responses)
Yeah, this might actually not be too hard with the work that's going into #50 for 2.2. Jacob can add some more thought on this :)
I've thought about this for things like protocol aware toxics where you could potentially mock out the backend server entirely. There's definitely a few applications for it, it's just a matter of figuring out a good way to specify backend type.
Currently the connection is made to the backend as soon as a client connects, and return immediately if it's down, regardless of toxics. This means whatever the settings is, it would need to be on the proxy, not a toxic. Maybe a special noop or blank upstream would be enough to tell the proxy not to connect to a backend?
Maybe a special noop or blank upstream would be enough to tell the proxy not to connect to a backend?
Sounds good
This might only make sense for the timeout toxic used with
timeout=0
, but wouldn't it be nice if it could work without a responding upstream?I tried with a "dummy" upstream, just picking a port where nothing was listening
But toxiproxy didn't like that
I was actually able to workaround this by setting the upstream to toxiproxy itself (
"upstream": "127.0.0.1:8474"
):WDYT about the workaround, might be enough that that works?