- # Timeout after which the startup of the remoting subsystem is considered
- # to be failed. Increase this value if your transport drivers (see the
- # enabled-transports section) need longer time to be loaded.
- startup-timeout = 10 s
-
- # Timout after which the graceful shutdown of the remoting subsystem is
- # considered to be failed. After the timeout the remoting system is
- # forcefully shut down. Increase this value if your transport drivers
- # (see the enabled-transports section) need longer time to stop properly.
- shutdown-timeout = 10 s
-
- # Before shutting down the drivers, the remoting subsystem attempts to flush
- # all pending writes. This setting controls the maximum time the remoting is
- # willing to wait before moving on to shut down the drivers.
- flush-wait-on-shutdown = 2 s
-
- # Reuse inbound connections for outbound messages
- use-passive-connections = on
-
- # Controls the backoff interval after a refused write is reattempted.
- # (Transports may refuse writes if their internal buffer is full)
- backoff-interval = 5 ms
-
- # Acknowledgment timeout of management commands sent to the transport stack.
- command-ack-timeout = 30 s
-
- # The timeout for outbound associations to perform the handshake.
- # If the transport is akka.remote.classic.netty.tcp or akka.remote.classic.netty.ssl
- # the configured connection-timeout for the transport will be used instead.
- handshake-timeout = 15 s
-
- ### Security settings
-
- # Enable untrusted mode for full security of server managed actors, prevents
- # system messages to be send by clients, e.g. messages like 'Create',
- # 'Suspend', 'Resume', 'Terminate', 'Supervise', 'Link' etc.
- untrusted-mode = off
-
- # When 'untrusted-mode=on' inbound actor selections are by default discarded.
- # Actors with paths defined in this list are granted permission to receive actor
- # selections messages.
- # E.g. trusted-selection-paths = ["/user/receptionist", "/user/namingService"]
- trusted-selection-paths = []
-
- ### Logging
-
- # If this is "on", Akka will log all inbound messages at DEBUG level,
- # if off then they are not logged
- log-received-messages = off
-
- # If this is "on", Akka will log all outbound messages at DEBUG level,
- # if off then they are not logged
- log-sent-messages = off
-
- # Sets the log granularity level at which Akka logs remoting events. This setting
- # can take the values OFF, ERROR, WARNING, INFO, DEBUG, or ON. For compatibility
- # reasons the setting "on" will default to "debug" level. Please note that the effective
- # logging level is still determined by the global logging level of the actor system:
- # for example debug level remoting events will be only logged if the system
- # is running with debug level logging.
- # Failures to deserialize received messages also fall under this flag.
- log-remote-lifecycle-events = on
-
- # Logging of message types with payload size in bytes larger than
- # this value. Maximum detected size per message type is logged once,
- # with an increase threshold of 10%.
- # By default this feature is turned off. Activate it by setting the property to
- # a value in bytes, such as 1000b. Note that for all messages larger than this
- # limit there will be extra performance and scalability cost.
- log-frame-size-exceeding = off
-
- # Log warning if the number of messages in the backoff buffer in the endpoint
- # writer exceeds this limit. It can be disabled by setting the value to off.
- log-buffer-size-exceeding = 50000
-
- # After failed to establish an outbound connection, the remoting will mark the
- # address as failed. This configuration option controls how much time should
- # be elapsed before reattempting a new connection. While the address is
- # gated, all messages sent to the address are delivered to dead-letters.
- # Since this setting limits the rate of reconnects setting it to a
- # very short interval (i.e. less than a second) may result in a storm of
- # reconnect attempts.
- retry-gate-closed-for = 5 s
-
- # After catastrophic communication failures that result in the loss of system
- # messages or after the remote DeathWatch triggers the remote system gets
- # quarantined to prevent inconsistent behavior.
- # This setting controls how long the Quarantine marker will be kept around
- # before being removed to avoid long-term memory leaks.
- # WARNING: DO NOT change this to a small value to re-enable communication with
- # quarantined nodes. Such feature is not supported and any behavior between
- # the affected systems after lifting the quarantine is undefined.
- prune-quarantine-marker-after = 5 d
-
- # If system messages have been exchanged between two systems (i.e. remote death
- # watch or remote deployment has been used) a remote system will be marked as
- # quarantined after the two system has no active association, and no
- # communication happens during the time configured here.
- # The only purpose of this setting is to avoid storing system message redelivery
- # data (sequence number state, etc.) for an undefined amount of time leading to long
- # term memory leak. Instead, if a system has been gone for this period,
- # or more exactly
- # - there is no association between the two systems (TCP connection, if TCP transport is used)
- # - neither side has been attempting to communicate with the other
- # - there are no pending system messages to deliver
- # for the amount of time configured here, the remote system will be quarantined and all state
- # associated with it will be dropped.
- #
- # Maximum value depends on the scheduler's max limit (default 248 days) and if configured
- # to a longer duration this feature will effectively be disabled. Setting the value to
- # 'off' will also disable the feature. Note that if disabled there is a risk of a long
- # term memory leak.
- quarantine-after-silence = 2 d
-
- # This setting defines the maximum number of unacknowledged system messages
- # allowed for a remote system. If this limit is reached the remote system is
- # declared to be dead and its UID marked as tainted.
- system-message-buffer-size = 20000
-
- # This setting defines the maximum idle time after an individual
- # acknowledgement for system messages is sent. System message delivery
- # is guaranteed by explicit acknowledgement messages. These acks are
- # piggybacked on ordinary traffic messages. If no traffic is detected
- # during the time period configured here, the remoting will send out
- # an individual ack.
- system-message-ack-piggyback-timeout = 0.3 s
-
- # This setting defines the time after internal management signals
- # between actors (used for DeathWatch and supervision) that have not been
- # explicitly acknowledged or negatively acknowledged are resent.
- # Messages that were negatively acknowledged are always immediately
- # resent.
- resend-interval = 2 s
-
- # Maximum number of unacknowledged system messages that will be resent
- # each 'resend-interval'. If you watch many (> 1000) remote actors you can
- # increase this value to for example 600, but a too large limit (e.g. 10000)
- # may flood the connection and might cause false failure detection to trigger.
- # Test such a configuration by watching all actors at the same time and stop
- # all watched actors at the same time.
- resend-limit = 200
-
- # WARNING: this setting should not be not changed unless all of its consequences
- # are properly understood which assumes experience with remoting internals
- # or expert advice.
- # This setting defines the time after redelivery attempts of internal management
- # signals are stopped to a remote system that has been not confirmed to be alive by
- # this system before.
- initial-system-message-delivery-timeout = 3 m
-
- ### Transports and adapters
-
- # List of the transport drivers that will be loaded by the remoting.
- # A list of fully qualified config paths must be provided where
- # the given configuration path contains a transport-class key
- # pointing to an implementation class of the Transport interface.
- # If multiple transports are provided, the address of the first
- # one will be used as a default address.
- enabled-transports = ["akka.remote.classic.netty.tcp"]
-
- # Transport drivers can be augmented with adapters by adding their
- # name to the applied-adapters setting in the configuration of a
- # transport. The available adapters should be configured in this
- # section by providing a name, and the fully qualified name of
- # their corresponding implementation. The class given here
- # must implement akka.akka.remote.transport.TransportAdapterProvider
- # and have public constructor without parameters.
- adapters {
- gremlin = "akka.remote.transport.FailureInjectorProvider"
- trttl = "akka.remote.transport.ThrottlerProvider"
- }