Azure-docs: Is the 60s listener response time deadline configurable?

Created on 8 Apr 2019  Â·  3Comments  Â·  Source: MicrosoftDocs/azure-docs

There are 2 hints on this page that a 60s response time deadline exists:
"If the service does not appear to handle the request, the service will return a 504 "Gateway Timeout" after 60 seconds." and "Responses may be sent in any order, but each request must be responded to within 60 seconds or the delivery will be reported as having failed. The 60-second deadline is counted until the response frame has been received by the service. An ongoing response with multiple binary frames cannot become idle for more than 60 seconds or it is terminated."

Is this configurable or not?

It seemed to me a couple of months ago that setting OperationTimeout (https://docs.microsoft.com/en-us/dotnet/api/microsoft.azure.relay.relayconnectionstringbuilder.operationtimeout?view=azure-dotnet#Microsoft_Azure_Relay_RelayConnectionStringBuilder_OperationTimeout) on a HybridConnectionListener avoided the 60s deadline, but recently it seems to have no effect (or I am doing something wrong). In any case it would be nice to know, if it supposed to be configurable.

Thanks!


Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

in-progress product-question service-bus-relasvc triaged

All 3 comments

Hi @KeldOelykke Thank you for your feedback! We will review and update as appropriate.

@KeldOelykke I have assigned this to content author to review and update as appropriate.

@KeldOelykke This is not configurable and it is the hard limit. I even checked this internally. So for now will proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

varma31 picture varma31  Â·  3Comments

jamesgallagher-ie picture jamesgallagher-ie  Â·  3Comments

Favna picture Favna  Â·  3Comments

monteledwards picture monteledwards  Â·  3Comments

DeepPuddles picture DeepPuddles  Â·  3Comments