Skip to main content

Basic settings and options

Retry

If the response value corresponds to the set error code when making a gRPC call, the call will be retried. Retry is performed according to the Retry settings. The responses and settings that are retried by default for each API are as follows.

Retry error status code

For more information, please refer to GRPC Github.

ItemDescription
CANCELLEDIf the call is canceled (usually when the caller cancels it)
UNKNOWNUnknown error, for example, if a status value received from another address is not defined for that address
- or if the API does not provide information about response errors
DEADLINE_EXCEEDEDDeadline expired before the call completed
NOT_FOUNDSome requested entity (e.g., a file or path) could not be found
RESOURCE_EXHAUSTEDSome resource is exhausted, or the user quota is insufficient, or the file system is out of space
ABORTEDUsually, if the operation is aborted due to a concurrency issue, such as a failed sequencer check or in the middle of a transaction
INTERNALInternal error
UNAVAILABLEThe service is currently unavailable
retry settings
ItemDescription
JitteredWhether to set the delay time randomly
- In most cases, jitter is set to true
InitiAlertryDelayDelay to set before first retry
- Use a value adjusted according to RetryDelayMultiplier
RetryDelayMultiplierNext call retry delay = previous call retry delay * RetryDelayMultiplier
MaxRetryDelaySet a limit on retry delay
- RetryMultiplier cannot set retry delay to more than this value
InitialRpcTimeoutSet a timeout for the first RPC
- Use a value adjusted according to RpcTimeoutMultiplier
RpcTimeoutMultiplierNext call timeout = previous call timeout * RpcTimeoutMultiplier
MaxRpcTimeoutSet the RPC timeout
- RpcTimeoutMultiplier cannot set the RPC timeout to more than this value
TotalTimeoutUltimately controls how long a remote call should be retried before the logic completely gives up
- The higher this value, the more retries will be performed

Publisher retry settings

APIRetry codeDescriptionRetry setting
create topic503     UNAVAILABLE• max attempts : 0
•jittered : true
•initial retry delay : 100ms
•retry delay multiplier : 1.3
•max retry delay : 60s
•initial rpc timeout : 60s
•rpc timeout multiplier : 1.0
•max rpc timeout : 60s
•total timeout : 60s
get topic409ABORTED
500INTERNAL
503UNAVAILABLE
list topics409ABORTED
500INTERNAL
503UNAVAILABLE
list topic subscriptions409ABORTED
500INTERNAL
503UNAVAILABLE
update topic503UNAVAILABLE
delete topic503UNAVAILABLE
publish(admin)409ABORTED• max attempts : Integer.MAX_VALUE
• jittered : true
• initial retry delay : 100ms
• retry delay multiplier : 1.3
• max retry delay : 60s
• initial rpc timeout : 5s
• rpc timeout multiplier : 1.3
• max rpc timeout : 60s
• total timeout : 60s
429RESOURCE_EXHAUSTED
499CANCELLED
500INTERNAL
UNKNOWN
503UNAVAILABLE
504DEADLINE_EXCEEDED
publish409ABORTED• max attempts : Integer.MAX_VALUE
• jittered : true
• initial retry delay : 100ms
• retry delay multiplier : 1.3
• max retry delay : 60s
• initial rpc timeout : 60s
• rpc timeout multiplier : 1.0
• max rpc timeout : 60s
• total timeout : 60s
429RESOURCE_EXHAUSTED
499CANCELLED
500INTERNAL
UNKNOWN
503UNAVAILABLE
504DEADLINE_EXCEEDED

Subscriber retry settings

APIRetry codeDescriptionRetry setting
create subscription14     UNAVAILABLE• Initial : 100ms
• Multiplier : 1.3
• Max : 60s
get subscription14UNAVAILABLE
list subscriptions14UNAVAILABLE
seek14UNAVAILABLE
update subscription14UNAVAILABLE
delete subscription14UNAVAILABLE
modify ack deadline14UNAVAILABLE
acknowledge14UNAVAILABLE
pull14UNAVAILABLE
streaming pull4DEADLINE_EXCEEDED
8RESOURCE_EXHAUSTED
13INTERNAL
14UNAVAILABLE

Batch processing

You can batch messages when making API calls.

Limit Exceeded Behavior

What to do when a flow control limit is exceeded

  • ThrowException: Useful for interactive scenarios and applications that implement custom rate limits.
  • Block: Wait until a request can be made without exceeding the limit. Useful for batch processing where the latency of individual requests is not important.
  • Ignore: Do not use flow control.
API Batching Settings
항목element count thresholdrequest bytes thresholddelay thresholdFlowControlSettings.limitExceededBehavior
publish(admin)100      1048576    10msLimitExceededBehavior.Ignore
publish1001000(=1KB)1msLimitExceededBehavior.Ignore

Logging

Netti logging

Inbound/outbound logs including server pings are not left by default. However, if the libraries of SLF4J, Log4J2, and Log4J are included in the dependency, logs are created.

  • org.slf4j
  • org.apache.logging.log4j
  • org.apache.logging.log4j

Code Example

15:11:03.551 [main] DEBUG io.grpc.netty.shaded.io.netty.util.internal.logging.InternalLoggerFactory - Using SLF4J as the default logging framework
15:11:03.560 [main] DEBUG io.grpc.netty.shaded.io.netty.util.internal.PlatformDependent0 - -Dio.netty.noUnsafe: false
15:11:03.560 [main] DEBUG io.grpc.netty.shaded.io.netty.util.internal.PlatformDependent0 - Java version: 17
15:11:03.561 [main] DEBUG io.grpc.netty.shaded.io.netty.util.internal.PlatformDependent0 - sun.misc.Unsafe.theUnsafe: available
15:11:03.562 [main] DEBUG io.grpc.netty.shaded.io.netty.util.internal.PlatformDependent0 - sun.misc.Unsafe.copyMemory: available
15:11:03.562 [main] DEBUG io.grpc.netty.shaded.io.netty.util.internal.PlatformDependent0 - sun.misc.Unsafe.storeFence: available

Internal logging

You can log requests and responses (success/failure) in Publish and StreamingPull.
Logs use the LoggingProvider type, and by default, no logs are left.
The types of log output are as follows:

  • DefaultMessageLogger: Logging to the console
  • FileStreamLogger: Logging to File output

The following values ​​can be set for Logger by default:

ItemDescription
timeUnitTime unit for log interval (milliseconds)
intervalTime interval to leave logs
levelLog level
- Default: INFO
Code Example
Example
InternalLoggingProvider.newBuilder()
.setMessageLogger(
DefaultMessageLogger.newBuilder()
.setLevel(Level.INFO)
.setTimeUnit(TimeUnit.MILLISECONDS)
.setInterval(logInterval)
.build())