Ivan_Pisarevsky,

Кстати, да - хороший вопрос - как эти таймауты должны задаваться, и чья установка главнее - админа (в конфиге) или прикладного разработчика (в dpb\tpb\etc)

DarkMasterА мы не напоремся на труднопонимаемые ситуации несвоевременным отстрелом? Ну когда долгий отчет формируется за 10 минут. Потом мы вливаем туда порцию данных, ломаем индекс или еще чего и отчет начинает формироваться 15 минут. При вводе ограничения например на 12 минут мы утром обнаруживаем, что отчет не сфомировался, т.к. нас "отстрелили". А что не понятного в этой ситуации ?
Тут даже есть плюс - ты своевременно узнаешь о том, что отчёт стал формироваться слишком долго.

DarkMasterПричем это сервером считается как штатная ситуация и в логах мы по идее фиг что увидим.А почему тот, кто формировал отчёт, не сохранил сообщение об ошибке ? Это ведь может быть не только таймаут, а что угодно. Причём же тут серверные логи ?

Симонов Денися конечно имею ввиду логировать только то, что отвалилось по таймаутуДавайте не будем впадать в маразм. Ибо так легко получить логгирование вообще всех запросов.
Кому надо логгировать таймауты - трейс в зубы.

DarkMaster1) Отчет может формироваться роботом. У которого одна задача - на приход часа Х запустить процедуру У.
2) Отстрел по таймауту - это ошибка? Ну я же вроде задаю интервал, значит закладываюсь на какие-то временные рамки.1. Если он не ведёт лог своей работы с протоколом полученных ошибок - это плохой робот, бесполезный.
2. Для клиента - конечно ошибка, так же как и отмена запроса\аттача.

Симонов Денис,

ну так это уже другой вопрос :)

Вообще с таймаутами не всё так просто, как кажется на первый взгляд.

Один из приципиальных вопросов : кто должен отсчитывать время - клиент или сервер ?
Ответ в лоб - конечно сервер, т.к. клиент может отвалиться или зависнуть, а сервер об этом не узнает.
Однако может быть и обратная ситуация, когда клиент не обнаруживает потерю соединения или же сервер висит\слишком загружен чтобы вовремя информировать клиента о таймауте.
Таким образом мы приходим к необходимости отслеживать таймауты с обеих сторон.
И тут же возникает новый вопрос - нужно ли делать отдельные опции для клиента и сервера, или же ограничиться одним и тем же значением. Если идти по второму пути, то клиент должен как-то узнавать значение таймаута, заданное на сервере по-умолчанию.

Далее. Как считать таймаут для запроса ? Нужно ли начинать отсчёт времени заново после каждого фетча или выключать таймер сразу же после первого фетча ?

DarkMasterНеоднозначно. Т.е. я как разработчик должен закладываться на какие-то среднепотолочные значения таймаутов "чтобы наверняка успеть", отдавать заказчику и молится, чтобы через Н-е время меня не начали задалбывать вопросами "а почему это наш супер пупер важный отчет не ушел на мыло директору?".Всё однозначно, ты просто не даёшь себе подумать.
1. Отключай таймаут для своего проложения\БД, если ты не умеешь его готовить.
2. Для конкретного запроса выставляй заведомо большое значение таймаута.
3. Всегда все роботы обязаны реагировать на любые ошибки (кроме внезапного саморазрушения :) )

DarkMasterДа и для админом начнется тихий ужас с захардкоженными в коде таймаутами (по закону подлости его начнуть пихать куда можно и куда нельзя)...А вот тут см. 14966027

PS И не надо бояться, в других серверах давно есть таймауты и никто о них не плачет :)

Dimitry Sibiryakovhvladввести такие таймауты
IMHO - нах-нах. Геморроя много, пользы мало.А ты с кем разговариваешь ?
Т.е. на что ты вообще отвечаешь ? Ты против любых таймаутов ? Аргументация, как обычно, блестяща и полна

DarkMasterЗовем какие-то хитросделанные УДФ`ы, которые могут бог знает что делать - получаем непонятное поведение. Никаких фетчей, а время тю-тю...Есс-но, самый первый раз таймер взводится в момент начала выполения запроса.
Ты может таки начнёшь хоть чуть-чуть думать, перед тем как писать ?