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

Issue since v.0.14.1 : no logs in output file #303

Closed
ylegat opened this issue Jun 15, 2016 · 8 comments
Closed

Issue since v.0.14.1 : no logs in output file #303

ylegat opened this issue Jun 15, 2016 · 8 comments

Comments

@ylegat
Copy link
Contributor

ylegat commented Jun 15, 2016

Hey @buger , I think there is an issue with version 0.14.1. Apparently, logs are not written in the output file. Gor is launch with :

sudo ./gor --input-raw :8086  --verbose --debug --output-file ./request.gor

Two HTTP requests are then executed and we stop Gor manually. After the stop, the log file has been created but it is empty. We did a try using version 0.13.0 using the same protocol and it worked. Of course due to the bug present in the version 0.14.0 we were not able to test it.

Are you aware of this issue ?

EDIT 1 : the data are correctly written when the flush is called by the go routine, so every minutes by default
EDIT 2 : actually, we are always missing the first requests logged, even after some flushes. I just did a try without 2000 requests. The first one (sometimes a few, sometimes a hundred) are missing. I think the first file is neither flush nor closed.

@ylegat
Copy link
Contributor Author

ylegat commented Jun 15, 2016

I've found the origin of the issue : we output-file we pass is ./request.gor, but other paths are computed without the ./, so at one moment we've got "./request_0.gor" != "request_0.gor" here and the file is crushed.

So the fix is simple : filename given with the command should be normalized.

@mlallaouret
Copy link
Contributor

Hello @ylegat and @buger

Indeed the ./in the ouput-file path causes the loss of the first requests in the file. I will propose a PR to resolve this issue.

But there is still an issue with the flush of the writer when we stop the process. If we do not wait the end of the minute in order to flush the writer with the go routine and that we stop the process, no data is written. Is it intended not to flush the writer at the end of the process since the version 0.14.1 ?

@mlallaouret
Copy link
Contributor

I found the issue with the writer that is not flushed at the end of program. In gor.go, when the go routine receive the SIGTERM signal, gor iterate over all the plugins to call the Closemethod. The problem with FileOutput.Closeis that the implementation is not correct. It should declare an error as return type.

@buger
Copy link
Owner

buger commented Jun 16, 2016

Bot issues should be fixed, thanks to @mlallaouret !

@buger buger closed this as completed Jun 16, 2016
@buger
Copy link
Owner

buger commented Jun 16, 2016

Here are binaries with fixes:
gor_DEV-1466094930_mac.tar.gz
gor_DEV-1466094909_x64.tar.gz

@QasimK
Copy link

QasimK commented Jun 29, 2016

@buger Thank you for the fixed binaries. Perhaps there could be more visibility for this issue? I spent quite a while tracking down what was going on

@buger
Copy link
Owner

buger commented Jun 29, 2016

More verbose error messages will definitly help

@buger
Copy link
Owner

buger commented Aug 11, 2016

@QasimK @ylegat @mlallaouret happy to announce just released v0.15.0 version, which include those fixes.

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

No branches or pull requests

4 participants