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

Unable to generate audit report on large node with lots of data #144

Closed
mrfelton opened this issue Nov 15, 2020 · 3 comments · Fixed by #148
Closed

Unable to generate audit report on large node with lots of data #144

mrfelton opened this issue Nov 15, 2020 · 3 comments · Fixed by #148
Assignees

Comments

@mrfelton
Copy link

Hi

I seem to be unable to generate an audit report for a large node with lots of data.

The command errors with:

[frcli] rpc error: code = Internal desc = stream terminated by RST_STREAM with error code: INTERNAL_ERROR

And in the logs I see:

2020-11-15 13:59:18.059 [INF] LITD: Handling gRPC request: /frdrpc.FaradayServer/NodeAudit
2020-11-15 13:59:18.106 [WRN] FRPC: creating accounting report without bitcoin backend, some fee entries will be missing (see logs)
2020-11-15 13:59:28.061 [WRN] GRPC: grpc: Server.processUnaryRPC failed to write status: connection error: desc = "transport is closing"

I'm able to do the report successfully on nodes with less data.

I tried setting start_date to yesterday in the hope that limiting the dataset would get it to work, but I get the same issue.

@guggero guggero self-assigned this Nov 16, 2020
@guggero
Copy link
Member

guggero commented Nov 16, 2020

This looks suspiciously like a timeout closing the connection. I'll look into it.

guggero added a commit that referenced this issue Nov 16, 2020
To make sure that long-running calls and indefinitely opened streaming
connections aren't terminated by the internal proxy, we need to disable
all timeouts except the one for reading the HTTP headers.
That timeout shouldn't be removed as we would otherwise be prone to the
slowloris attack where an attacker takes too long to send the headers
and uses up connections that way.
Once the headers are read, we either know it's a static ressource and
can deliver that very cheaply or check the authentication for other
calls.

Fixes #140 and #144.
guggero added a commit that referenced this issue Nov 16, 2020
To make sure that long-running calls and indefinitely opened streaming
connections aren't terminated by the internal proxy, we need to disable
all timeouts except the one for reading the HTTP headers.
That timeout shouldn't be removed as we would otherwise be prone to the
slowloris attack where an attacker takes too long to send the headers
and uses up connections that way.
Once the headers are read, we either know it's a static resource and
can deliver that very cheaply or check the authentication for other
calls.

Fixes #140 and #144.
@mrfelton
Copy link
Author

Confirmed - this resolves the issue. Thanks!

@rockstardev
Copy link

Thanks for the quick fix @guggero

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 a pull request may close this issue.

3 participants