The post Timeout response from HTTP-JSON service - #6 by cocreature mentions that you can use…
-Dakka.http.server.request-timeout=5s
…to configure the HTTP JSON API service.
Is there a way to include the Akka HTTP Server configuration in the logs?
Here is what I have tried…
java -Dakka.loglevel=DEBUG -jar /http-json-2.9.3-ee.jar --log-level DEBUG
But I’m not seeing any akka related configuration being logged.
Two things about this:
With Daml 2.8, Akka was replaced with Pekko. Consequently, any instructions for -Dakka.something should be -Dpekko.something.
To log the Akka/Pekko configuration for the 2.x HTTP JSON service, use:
-Dakka.log-config-on-start=true-Dpekko.log-config-on-start=trueHere is a sample excerpt:
"server" : {
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 1930
# The requested maximum length of the queue of incoming connections.
# If the server is busy and the backlog is full the OS will start dropping
# SYN-packets and connection attempts may fail. Note, that the backlog
# size is usually only a maximum size hint for the OS and the OS can
# restrict the number further based on global limits.
"backlog" : 100,
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 1843
# The time period within which the TCP binding process must be completed.
"bind-timeout" : "1s",
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 1940
# If this setting is empty the server only accepts requests that carry a
# non-empty `Host` header. Otherwise it responds with `400 Bad Request`.
# Set to a non-empty value to be used in lieu of a missing or empty `Host`
# header to make the server accept such requests.
# Note that the server will never accept HTTP/1.1 request without a `Host`
# header, i.e. this setting only affects HTTP/1.1 requests with an empty
# `Host` header as well as HTTP/1.0 requests.
# Examples: `www.spray.io` or `example.com:8080`
"default-host-header" : "",
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 1846
# Default port to bind HTTP server to when no port was explicitly given.
"default-http-port" : 80,
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 1849
# Default port to bind HTTPS server to when no port was explicitly given.
"default-https-port" : 443,
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 2006
"http2" : {
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 2043
# The number of request data bytes the HTTP/2 implementation is allowed to buffer internally per connection. Free
# space in this buffer is communicated to the peer using HTTP/2 flow-control messages to backpressure data if it
# isn't read fast enough.
#
# When there is no backpressure, this amount will limit the amount of in-flight data. It might need to be increased
# for high bandwidth-delay-product connections.
#
# There is a relation between the `incoming-connection-level-buffer-size` and the `incoming-stream-level-buffer-size`:
# If incoming-connection-level-buffer-size < incoming-stream-level-buffer-size * number_of_streams, then
# head-of-line blocking is possible between different streams on the same connection.
"incoming-connection-level-buffer-size" : "10 MB",
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 2051
# The number of request data bytes the HTTP/2 implementation is allowed to buffer internally per stream. Free space
# in this buffer is communicated to the peer using HTTP/2 flow-control messages to backpressure data if it isn't
# read fast enough.
#
# When there is no backpressure, this amount will limit the amount of in-flight data per stream. It might need to
# be increased for high bandwidth-delay-product connections.
"incoming-stream-level-buffer-size" : "512kB",
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 2089
# Enable verbose debug logging for all ingoing and outgoing frames
"log-frames" : false,
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 2022
# The maximum number of request per connection concurrently dispatched to the request handler.
# This limit is enforced as soon as the connection between the peers is established. Enforcing
# the limit even before the SETTINGS/SETTINGS_ACK exchange has completed, means
# that we will refuse extra streams/requests that were sent by the client right after
# the connection was established but before it received our SETTINGS.
"max-concurrent-streams" : 256,
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 2070
# For incoming requests, the infrastructure collects at least the given number of bytes before dispatching a HttpRequest.
# If all request data is received before or when the threshold is reached, the entity data is dispatched as a strict entity
# which allows more efficient processing of the request data without involving streams.
#
# If the given value is 0, the request is immediately dispatched and always carries a stream of data.
# You can use value `1` to create a strict entity if the request contains at most a single data frame, and a streamed
# entity otherwise.
#
# If `min-collect-strict-entity-size > 0` and a request is cancelled (RST_STREAM) before enough data has been collected and the request
# is dispatched, then the request is silently discarded.
#
# To avoid flow control dead-locks, the value must be both smaller or equal than `incoming-stream-level-buffer-size`
# and `incoming-connection-level-buffer-size / max-concurrent-streams`.
#
# Note, that if enabled, requests that expect data (endStream = false on HEADERS) but never received a DATA frame will never be
# dispatched. In a regular HTTP context, this is uncommon. It would require that a client would expect data from the server first
# before sending any own data.
"min-collect-strict-entity-size" : 0,
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 2086
# The maximum number of outgoing control frames to buffer when the peer does not read from its TCP connection before
# backpressuring incoming frames.
#
# On a healthy HTTP/2 connection this setting should have little effect because control frames are given priority over
# data frames and should not be buffered for a long time.
#
# The limit is necessary to prevent a malicious peer to solicit buffering of outgoing control frames (e.g. by sending PINGs)
# without ever reading frames ultimately leading to an out of memory situation. With the limit in place, the implementation
# stops reading incoming frames when the number of outgoing control frames has reached the given amount. This way an attacker
# isn't able to communicate any further without first freeing space in the TCP window, draining the buffered control frames.
#
# See CVE-2019-9512 for an example of such an attack.
#
# Note that only control frames are affected because data frames, in contrast, are covered by the HTTP/2 flow control.
"outgoing-control-frame-buffer-size" : 1024,
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 2093
# When there is no data transmitted in either direction, but there are active streams, send a HTTP/2 ping frame with this initial
# delay and subsequent interval to make sure the connection is kept alive, 0s disables sending ping frames.
"ping-interval" : "0s",
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 2097
# Fail the connection if a sent ping is not acknowledged within this timeout.
# When zero the ping-interval is used, if set the value must be evenly divisible by less than or equal to the ping-interval.
"ping-timeout" : "0s",
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 2031
# The maximum number of bytes to receive from a request entity in a single chunk.
#
# The reasoning to limit that amount (instead of delivering all buffered data for a stream) is that
# the amount of data in the internal buffers will drive backpressure and flow control on the HTTP/2 level. Bigger
# chunks would mean that the user-level entity reader will have to buffer all that data if it cannot read it in one
# go. The implementation would not be able to backpressure further data in that case because it does not know about
# this user-level buffer.
"request-entity-chunk-size" : "65536 b"
},
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 1824
# The time after which an idle connection will be automatically closed.
# Set to `infinite` to completely disable idle connection timeouts.
"idle-timeout" : "60 s",
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 1862
# The time period the HTTP server implementation will keep a connection open after
# all data has been delivered to the network layer. This setting is similar to the SO_LINGER socket option
# but does not only include the OS-level socket but also covers the Pekko IO / Pekko Streams network stack.
# The setting is an extra precaution that prevents clients from keeping open a connection that is
# already considered completed from the server side.
#
# If the network level buffers (including the Pekko Stream / Pekko IO networking stack buffers)
# contains more data than can be transferred to the client in the given time when the server-side considers
# to be finished with this connection, the client may encounter a connection reset.
#
# Set to 'infinite' to disable automatic connection closure (which will risk to leak connections).
"linger-timeout" : "1 min",
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 2004
# Enables/disables the logging of unencrypted HTTP traffic to and from the HTTP
# server for debugging reasons.
#
# Note: Use with care. Logging of unencrypted data traffic may expose secret data.
#
# Incoming and outgoing traffic will be logged in hexdump format. To enable logging,
# specify the number of bytes to log per chunk of data (the actual chunking depends
# on implementation details and networking conditions and should be treated as
# arbitrary).
#
# For logging on the client side, see pekko.http.client.log-unencrypted-network-bytes.
#
# `off` : no log messages are produced
# Int : determines how many bytes should be logged per data chunk
"log-unencrypted-network-bytes" : "off",
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 1876
# The maximum number of concurrently accepted connections when binding a server using
# `Http().newServerAt().bindXYZ()` methods.
#
# This setting doesn't apply to the `Http().bind` method which will still
# deliver an unlimited backpressured stream of incoming connections.
#
# Note, that this setting limits the number of the connections on a best-effort basis.
# It does *not* strictly guarantee that the number of established TCP connections will never
# exceed the limit (but it will be approximately correct) because connection termination happens
# asynchronously. It also does *not* guarantee that the number of concurrently active handler
# flow materializations will never exceed the limit for the reason that it is impossible to reliably
# detect when a materialization has ended.
"max-connections" : 1024,
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 1956
# Modify to tweak parsing settings on the server-side only.
"parsing" : {
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 1987
# When a request is so malformed we cannot create a RequestContext out of it,
# the regular exception handling does not apply, and a default error handling
# is applied that only has access to the parse error and not the actual request.
# To customize this error response, set error-handler to the FQCN of an
# implementation of org.apache.pekko.http.ParsingErrorHandler
"error-handler" : "org.apache.pekko.http.DefaultParsingErrorHandler$",
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 1980
# Default maximum content length which should not be exceeded by incoming request entities.
# Can be changed at runtime (to a higher or lower value) via the `HttpEntity::withSizeLimit` method.
# Note that it is not necessarily a problem to set this to a high value as all stream operations
# are always properly backpressured.
# Nevertheless you might want to apply some limit in order to prevent a single client from consuming
# an excessive amount of server resources.
#
# Set to `infinite` to completely disable entity length checks. (Even then you can still apply one
# programmatically via `withSizeLimit`.)
"max-content-length" : "8m"
},
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 1888
# The maximum number of requests that are accepted (and dispatched to
# the application) on one single connection before the first request
# has to be completed.
# Incoming requests that would cause the pipelining limit to be exceeded
# are not read from the connections socket so as to build up "back-pressure"
# to the client via TCP flow control.
# A setting of 1 disables HTTP pipelining, since only one request per
# connection can be "open" (i.e. being processed by the application) at any
# time. Set to higher values to enable HTTP pipelining.
# This value must be > 0 and <= 1024.
"pipelining-limit" : 1,
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 1803
# "PREVIEW" features that are not yet fully production ready.
# These flags can change or be removed between patch releases.
"preview" : {
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 1819
# If this setting is enabled AND the pekko-http2-support is found
# on the classpath, `Http().newServerAt(...).bind` and `bindSync`
# will be enabled to use HTTP/2.
#
# `Http().newServerAt(...).bindFlow` and `connectionSource()` are not supported.
"enable-http2" : "off"
},
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 1902
# Enables/disables the addition of a `Raw-Request-URI` header holding the
# original raw request URI as the client has sent it.
"raw-request-uri-header" : "off",
# application.conf @ jar:file:/http-json-2.9.3-ee.jar!/application.conf: 1
"remote-address-attribute" : "on",
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 1893
# Enables/disables the addition of a `Remote-Address` header
# holding the clients (remote) IP address.
# Deprecated since Akka HTTP 10.2.0: please use `remote-address-attribute` instead.
"remote-address-header" : "off",
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 1840
# Defines the default time period within which the application has to
# produce an HttpResponse for any given HttpRequest it received.
# The timeout begins to run when the *end* of the request has been
# received, so even potentially long uploads can have a short timeout.
# Set to `infinite` to completely disable request timeout checking.
#
# Make sure this timeout is smaller than the idle-timeout, otherwise,
# the idle-timeout will kick in first and reset the TCP connection
# without a response.
#
# If this setting is not `off` the HTTP server layer attaches a
# `Timeout-Access` header to the request, which enables programmatic
# customization of the timeout period and timeout response for each
# request individually.
"request-timeout" : "20 s",
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 1923
# The initial size of the buffer to render the response headers in.
# Can be used for fine-tuning response rendering performance but probably
# doesn't have to be fiddled with in most applications.
"response-header-size-hint" : 512,
# merge of reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 1809,pekko-http-version.conf @ jar:file:/http-json-2.9.3-ee.jar!/pekko-http-version.conf: 1
"server-header" : "pekko-http/1.0.0",
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 1934
# Socket options to set for the listening socket. If a setting is left
# undefined, it will use whatever the default on the system is.
"socket-options" : {
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 1945
"so-receive-buffer-size" : "undefined",
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 1947
"so-reuse-address" : "undefined",
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 1946
"so-send-buffer-size" : "undefined",
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 1948
"so-traffic-class" : "undefined",
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 1949
"tcp-keep-alive" : "undefined",
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 1951
"tcp-no-delay" : "undefined",
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 1950
"tcp-oob-inline" : "undefined"
},
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 2014
# Cancellation in the HTTP streams is delayed by this duration to prevent race conditions between cancellation
# and stream completion / failure. In most cases, the value chosen here should make no difference because
# HTTP streams are loops where completion and failures should propagate immediately and make the handling of
# cancellations redundant.
#
# In most cases, there should be no reason to change this setting.
#
# Set to 0 to disable the delay.
"stream-cancellation-delay" : "100 millis",
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 1950
# When graceful termination is enabled and used invoked with a deadline,
# after the deadline passes pending requests will be replied to with a "terminating" http response,
# instead of delivering those requests to the user-handler.
# This response is configurable here using configuration, or via code in case more a sophisticated (e.g. with response entity)
# response is needed.
#
"termination-deadline-exceeded-response" : {
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 1962
# Status code of the "terminating" response to be automatically sent to pending requests once the termination deadline is exceeded.
# ServiceUnavailable
"status" : 503
},
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 1910
# Enables/disables automatic handling of HEAD requests.
# If this setting is enabled the server dispatches HEAD requests as GET
# requests to the application and automatically strips off all message
# bodies from outgoing responses.
# Note that, even when this setting is off the server will never send
# out message bodies on responses to HEAD requests.
"transparent-head-requests" : "off",
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 1918
# Enables/disables the returning of more detailed error messages to
# the client in the error response.
# Should be disabled for browser-facing APIs due to the risk of XSS attacks
# and (probably) enabled for internal or non-browser APIs.
# Note that pekko-http will always produce log messages containing the full
# error details.
"verbose-error-messages" : "off",
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 2090
"websocket" : {
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 2120
# Enable verbose debug logging for all ingoing and outgoing frames
"log-frames" : false,
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 2117
# Interval for sending periodic keep-alives
# The frame sent will be the one configured in pekko.http.server.websocket.periodic-keep-alive-mode
# `infinite` by default, or a duration that is the max idle interval after which an keep-alive frame should be sent
# The value `infinite` means that *no* keep-alive heartbeat will be sent, as: "the allowed idle time is infinite"
"periodic-keep-alive-max-idle" : "infinite",
# reference.conf @ jar:file:/http-json-2.9.3-ee.jar!/reference.conf: 2111
# periodic keep alive may be implemented using by sending Ping frames
# upon which the other side is expected to reply with a Pong frame,
# or by sending a Pong frame, which serves as unidirectional heartbeat.
# Valid values:
# ping - default, for bi-directional ping/pong keep-alive heartbeating
# pong - for uni-directional pong keep-alive heartbeating
#
# It is also possible to provide a payload for each heartbeat message,
# this setting can be configured programatically by modifying the websocket settings.
# See: https://pekko.apache.org/docs/pekko-http/current/server-side/websocket-support.html
"periodic-keep-alive-mode" : "ping"
}
}