blocking batch flow control belies async logging

[benjaminp]

google-cloud-logging enables the blocking flow controller in the GAX batching library, going to lengths to modify the default gapic behavior:

java-logging/google-cloud-logging/src/main/java/com/google/cloud/logging/spi/v2/GrpcLoggingRpc.java

Lines 168 to 181 in 7b3928e

	BatchingSettings oldBatchSettings =
	logBuilder.writeLogEntriesSettings().getBatchingSettings();
	logBuilder
	.writeLogEntriesSettings()
	.setBatchingSettings(
	oldBatchSettings
	.toBuilder()
	.setFlowControlSettings(
	oldBatchSettings
	.getFlowControlSettings()
	.toBuilder()
	.setLimitExceededBehavior(LimitExceededBehavior.Block)
	.build())
	.build());

The trouble with the blocking batch flow controller is that it can block LoggingImpl.writeAsync and thus any application code that happens to log after the flow controller is full. (That can happen either because of too much application logging or because of a slow-down in the logging service.) Preferable behavior would be dropping the log messages that cannot be uploaded and leaving a note about dropped messages in the next batch or stderr.

(This issue is notwithstanding a recent regression described in #632. That regression occludes the problematic behavior described here by removing the GAX batcher.)

[minherz]

Hello, the gax batching logic cannot be controlled from the logging library because stubs are auto-generated. There is a planned work (ETA Q1'22) to migrate the batching logic from gax to the logging library. The batching configuration will be exposed to users avoiding discrepancies.
We will review the auto-generated code to ensure that its current version is synchronized with the settings of the gax-java.

[benjaminp]

So, you're saying the code in the logging library I linked to in OP is a noop?

[minherz]

I'd confirmed that the code you referenced is not auto-generated. I understand your concern about being blocked although the blocking takes place until the current batch is sent, the default GAX behavior, throwing exception seems more dangerous since it can unexpectedly crash the application.
Other mechanisms for handling errors cannot be introduced until the batching logic will be transferred into the library (see #705)

[benjaminp]

Thank you for the replies. It looks like implementing #705 would provide the behavior I desire.

[minherz]

One of its goals is to provide the control over batching configuration to the library users.