# Log HTTP JSON API (v 2.x) timeout configuration

**URL:** <https://forum.canton.network/t/log-http-json-api-v-2-x-timeout-configuration/7461>\
**Category:** App Development\
**Tags:** json-api\
**Created:** [October 24, 2024, 5:58pm UTC](https://forum.canton.network/t/log-http-json-api-v-2-x-timeout-configuration/7461 "2024-10-24T17:58:38Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![WallaceKelly](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/wallacekelly/32/5046_2.png) [@WallaceKelly](https://forum.canton.network/u/WallaceKelly)\
**Post date:** [October 24, 2024, 5:58pm UTC](https://forum.canton.network/t/log-http-json-api-v-2-x-timeout-configuration/7461/1 "2024-10-24T17:58:38Z")

</div>

The post [Timeout response from HTTP-JSON service - #6 by cocreature](https://discuss.daml.com/t/timeout-response-from-http-json-service/4822/6) 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…

```haskell
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.

---

<div class="post-metadata">

**Author:** ![WallaceKelly](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/wallacekelly/32/5046_2.png) [@WallaceKelly](https://forum.canton.network/u/WallaceKelly)\
**Post date:** [October 25, 2024, 3:36pm UTC](https://forum.canton.network/t/log-http-json-api-v-2-x-timeout-configuration/7461/2 "2024-10-25T15:36:09Z")

</div>

Two things about this:

1. With Daml 2.8, **Akka was replaced with Pekko**. Consequently, any instructions for `-Dakka.something` should be `-Dpekko.something`.

2. To **log the Akka/Pekko configuration** for the 2.x HTTP JSON service, use:

Here is a sample excerpt:

> **pekko.server configuration**
>
> ```haskell
> "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"
> }
> }
> 
> ```