-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Fix LoggingHandler flush #1795
Comments
@pongad could you reword the description in terms of a command instead of a problem? (e.g. "Fix logging flush") |
@garrettjonesgoogle I never seem to be able to remember. Done. |
Also reword the extended description, recommending a course of action to take. |
LoggingHandler's buffer is redundant, since it's already using the batching feature. LoggingHandler.flush previously just flushes its own buffer and put messages in the batcher's buffer, without necessarily making RPC calls. This PR does not fix this problem, but it makes flush obviously wrong instead of subtly. The test for flush size is also removed. Flush size should be forwarded to the batcher, which already has its own test. Updates #1795.
This properly waits for the RPCs to finish with @pongad 's last change; the triggering of RPCs by the call can be done after GA. Removing the release-blocking label. |
@garrettjonesgoogle I think I need to send this back to you. The generated client must expose a way to flush. I don't think this is possible at the moment. |
I'll resolve this as duplicate of #2796. |
Logging handler's
flush()
callsLoggingImpl.write
which eventually callsLoggingClient.writeLogEntries
which uses bundling. So, handler flushing just moves messages from one buffer to another without actually making any RPC call.Proposed fix
LoggingHandler should keep a count of pending messages. The count increments with calls to publish and decrements when RPC returns.
Flush should force batcher to issue all buffered messages and just wait for the count to reach zero. No call to publish may succeed when flush is "in flight" otherwise flush could wait forever.
Encountering a log above the configured flush level should also force a flush.
The text was updated successfully, but these errors were encountered: