Default timeout of HttpClient via route configuration

[RightDecision2]

Expected Behavior / New Feature

// HttpClientBuilder.cs
_defaultTimeout = TimeSpan.FromSeconds(_configuration.TimeOut);

Actual Behavior / Motivation for New Feature

// HttpClientBuilder.cs
_defaultTimeout = TimeSpan.FromSeconds(90);

Specifications

• Version: All
• Platform: All
• Subsystem: Any

[raman-m]

Are you going to create a PR these days?

[RightDecision2]

Yes вт, 26 дек. 2023 г., 22:40 Raman Maksimchuk ***@***.***>:

…

Are you going to create a PR these days? — Reply to this email directly, view it on GitHub <#1869 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BCAL2WBKF3VTJ4NYWGYKMFLYLMKZRAVCNFSM6AAAAABBDLVCA6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRZG4YTCNJVGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[raman-m]

What is the problem with default 90 seconds timeout?

As a quick fix use QoS TimeoutValue property to have custom timeout value.
I don't think that performance will be decreased dramatically: a few microseconds will be added 😄

[raman-m]

@RightDecision2 commented on Dec 26

👌 Great! Waiting for your PR creation... Will review with pleasure!
But you need to fork Ocelot repository first!
Your repos are empty now.

[RightDecision2]

I have OCR service, which process pdf file. Every request average 2mins. When I use QuOS its random cancelled after 90 seconds (few times might be worked). So fo me, is only one possible solution - increase default timeout. I think for someone it could be usefull to. вт, 26 дек. 2023 г. в 22:52, Raman Maksimchuk ***@***.***>:

…

@RightDecision2 <https://github.com/RightDecision2> commented on Dec 26 <#1869 (comment)> 👌 Great! Waiting for your PR creation... Will review with pleasure! — Reply to this email directly, view it on GitHub <#1869 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BCAL2WFXJGNECQP4CYTHO63YLMMGBAVCNFSM6AAAAABBDLVCA6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRZG4YTMNJYGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[raman-m]

Dear author, What's your name?
What's your LinkedIn?

[raman-m]

I have OCR service, which process pdf file. Every request average 2mins.
When I use QoS its random cancelled after 90 seconds (few times might be worked).

Strange cancellation of your requests by QoS logic... You need to show this behavior by sharing to us Ocelot logs.
It should not be cancelled randomly... All requests should be done without problems if TimeoutValue in QoS is greater than 2 mins (average processing time by your downstream service). If some requests failed, that means root cause is not on Ocelot's side...

What is the maximum processing time? Seems you have to define max value in route config.
What exact value of TimeoutValue?

Please attach route JSON!

[raman-m]

So for me, is only one possible solution - increase default timeout. I think for someone it could be useful to.

I'm not sure it will help you...
How stable your downstream service if you connect directly (without Ocelot routing)?

As we've agreed on, you are going to create a PR soon to manage default timeout from route config, right?
Could you Sync fork please?
Our development process requires to fork the Ocelot repo first.

[RightDecision2]

Yes, when connected directly all working fine (~2minutes for every request). Yes, would be great to manage default timeouts from config file ocelot.json ср, 27 дек. 2023 г. в 13:03, Raman Maksimchuk ***@***.***>:

…

So for me, is only one possible solution - increase default timeout. I think for someone it could be useful to. I'm not sure it will help you... How stable your downstream service if you connect directly (without Ocelot routing)? As we've agreed on, you are going to create a PR soon to manage default timeout from route config, right? — Reply to this email directly, view it on GitHub <#1869 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BCAL2WFYDB3SFQSUG77YEWDYLPP6HAVCNFSM6AAAAABBDLVCA6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZQGA4TKNJYGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[lemosluan]

The doc from ocelot's site says that there is a timeout to 90s.
You can use Polly to reach a new timeout, but in some cases, the response from our services take more than 90s, so it would be useful if the timeout on startup of ocelot can be set.

[raman-m]

@RightDecision2 commented on Jan 9

How is your development going?
I guess you should be interested in fixing your problem...
But sorry, as a team, we are busy with other more important tasks. So, you need to fix by your own and create a PR, if you wish to contribute.

Will you contribute or not?

Можешь писать на русском языке, если это ускорит нашу разработку.
Не люблю, когда скрываются под всякими анонимными никами, да ещё и отвечают с мобилы, где установлен русскоязычный почтовый клиент.
И я задавал этот вопрос
Зачем шифроваться под левой учёткой ГитХаба? Не понимаю этого! Наверняка есть основной аккаунт, другой...

[raman-m]

@lemosluan commented on Feb 8

Hi Luan!
What's your solution for Ocelot pipeline setup?

This author's problem can be fixed by a Delegating Handler.
A few lines of code in the body of the handler. Something like that:

public class TimeoutHandler : DelegatingHandler
{
    protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken token)
    {
            TimeSpan? timeout = TimeSpan.FromHours(1.0); // hardcoded but can be read from the config
            request.Properties["RequestTimeout"] = timeout;
            return await base.SendAsync(request, token);
    }
}

But I'm not sure on design correctness, it should be checked.
Personally I like the following robust solution: Better timeout handling with HttpClient

And after that, just attach TimeoutHandler to Ocelot pipeline as:

ConfigureServices(s => s
    .AddOcelot()
    .AddDelegatingHandler<TimeoutHandler>()
)

and route config is

{
  // other props
  "DelegatingHandlers": ["TimeoutHandler"]
}

[RightDecision2]

Роман, здравствуйте. Учетки не левые, создавал много лет назад. Почта основная. Касательно разработки, прогресса нет. Всё вызовы к службе OCR пустил пока напрямую, минуя Ocelot. Служба читает штрихкоды с файлов pdf, иногда занимает много времени. Я видел, что в настройках можно использовать qos и timeout будет браться из конфигурации, по исходниками тоже на это похоже. Но на проде все равно иногда проскакивал timeout к службе OCR, пришлось сделать вызовы напрямую к службам. Теперь timeout не вылетает, но в Ocelot имеется дополнительный middleware и Consul Service Discovery. Я вас понял. Вопрос не горит, но было бы здорово иметь такую возможность, настройки timeout, через файл конфигурации. чт, 22 февр. 2024 г., 22:47 Raman Maksimchuk ***@***.***>:

…

@RightDecision2 <https://github.com/RightDecision2> commented on Jan 9 <#1869 (comment)> How is your development going? I guess you should be interested in fixing your problem... But sorry, as a team, we are busy with other more important tasks. So, you need to fix by your own and create a PR, if you wish to contribute. *Will you contribute or not?* Можешь писать на русском языке, если это ускорит нашу разработку. Не люблю, когда скрываются под всякими анонимными никами, да ещё и отвечают с мобилы, где установлен русскоязычный почтовый клиент. И я задавал этот вопрос <#1869 (comment)> Зачем шифроваться под левой учёткой ГитХаба? Не понимаю этого! Наверняка есть основной аккаунт, другой... — Reply to this email directly, view it on GitHub <#1869 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BCAL2WAERG5UB5U3Y2FFXELYU6HCJAVCNFSM6AAAAABBDLVCA6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRQGA2TAMZYGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[raman-m]

@RightDecision2 Приоритет низкий!
Без понятия в какой релиз это попадёт. Если кто-то создаст ПР, то фича появится быстрее.
Ждите! Может кто-то контрибьютнет...