buger / goreplay

GoReplay is an open-source tool for capturing and replaying live HTTP traffic into a test environment in order to continuously test your system with real data. It can be used to increase confidence in code deployments, configuration changes and infrastructure changes.

Home Page:https://goreplay.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Goreplay cannot correctly process multiple --output-http and it always only picks up the last one

fengnex opened this issue · comments

./gor --input-file "requests_0.gor" --output-http "http://target1" --output-http "http://target2"
Whenever ececuting commands like the above, gor will always create two plugins with the SAME url "http://targets" by invoking its method registerPlugin(constructor interface{}, options ...interface{}) in plugins.go.

Similarly, if your command has three or more --output-http, gor will create corresponding three or more PluginWriters, but all these output plugins will own the same url which the last --output-http specifies.

It seems that the method registerPlugin() in plugins.go always creates a new plugin by calling NewHTTPOutput(address string, config *HTTPOutputConfig) in output_http.go, which in turn calls plugin := vc.Call(vo)[0].Interface() and this line will cause the problem: the new plugin's url will always override all previously created plugins' in this scenario.

As a consequence, you can only send requests to the last --output-http target when there are more thant one --output-http in your commands, and all other --output-http will just receive no any requests.

@buger @slawosz @tambet @robyoung Would you be so kind as to check the problem, try to fix it, or give an idea on how to address it? Thanks a lot first.

Have found and confirmed the root cause of the issue lies in newConfig := config.Copy() of func NewHTTPOutput(address string, config *HTTPOutputConfig) PluginReadWriter; modifying the line as newConfig := new(HTTPOutputConfig) can solve it. Can anyone offer an idea why config.Copy() actually returns the same object and causes the issue?

same issue here (did you solve it?) @fengnex

I am seeing the same issue with version 1.3.3. Any efforts in resolving this is highly appreciated.

Any update on this?