Page History
...
Property name | Default value | Description |
---|---|---|
Incoming request processing | ||
request.timestamp.enabled | false | Whether or not the timestamp of an incoming request should be verified. The expiration time is included in the message |
request.timestamp.max-clock-skew | 300 | Maximum number of seconds the clock of the other system is allowed to derive from the receiving system. Introduced in Blueriq 18.6.1. In Blueriq 18.6.0, the value would always be 0, which was likely to cause problems. |
request.timestamp.max-ttl | 300 | Maximum time to live: maximum allowed number of seconds between the message's created and expires timestamp. If this number is greater than the specified max ttl, it is rejected. Introduced in Blueriq 18.6.1. In Blueriq 18.6.0, the value would always be 300. |
Outgoing response processing | ||
response.timestamp.enabled | false | Indicates whether a creation and expiration timestamp will be added to the response. |
request.timestamp.ttl | 300 | Time to live: maximum number of seconds that may have passed since the message's created timestamp. If the message is older, it should be rejected by the receiver. Introduced in Blueriq 18.6.1. In Blueriq 18.6.0, the value would always be 5. |
Configuration for AQ_RestServiceClient
...
Property name | Default value | Description |
---|---|---|
Outgoing request processing | ||
request.timestamp.enabled | false | Indicates whether a creation and expiration timestamp will be added to the request. |
response.timestamp.ttl | 300 | Time to live: maximum number of seconds that may have passed since the message's created timestamp. If the message is older, it should be rejected by the receiver. Introduced in Blueriq 18.6.1. In Blueriq 18.6.0, the value would always be 5. |
Incoming response processing | ||
response.timestamp.enabled | false | Indicates whether the creation and expiration timestamp should be verified. |
response.timestamp.max-clock-skew | 300 | Maximum number of seconds the clock of the other system is allowed to derive from the receiving system. Introduced in Blueriq 18.6.1. In Blueriq 18.6.0, the value would always be 0, which was likely to cause problems. |
response.timestamp.max-ttl | 300 | Maximum time to live: maximum allowed number of seconds between the message's created and expires timestamp. If this number is greater than the specified max ttl, it is rejected. Introduced in Blueriq 18.6.1. In Blueriq 18.6.0, the value would always be 300. |
...