iv_an_rusocimedБерем архитектуру LAMP и просвещаемся до полного просветления, где и как кому там положено падать и когда, чтоб не завалить вообще всехНа нагрузках, которые требуются нашим клиентам, LAMP не имеет ни малейших шансов. Ни A, ни M, ни P. Ни вместе, ни по отдельности. Потому что полные безнадёжные тормоза.

Ути пути, глаза-то подраззуй, я выше говорил про haproxy и nginx. Чукча не читатель?

WebSharperНе могли бы вы из жалости хотя бы сказать, как в данном случае поступать правильно?
Кусок кода в действии, как правильно отрабатывать коды возврата ошибок?

Да очень просто. assert подобное действие. Вида

#define EHANDLE(expr) { if (!(expr)) mycoredump(); }

...

EHANDLE((n = recv(....)) > 0 || errno == EWOULDBLOCK || errno == EAGAIN)


иди так (но так опаснее, errno могут перепротереть)

n = recv(....);

...

EHANDLE((n = > 0 || errno == EWOULDBLOCK || errno == EAGAIN)


Т.е. пессиместический сценарий - если мы способны справиться с кодом возврата - идем дальше, если нет - тупо падаем нафиг.
И так обрабатывается КАЖДЫЙ внешний вызов, системный в т.ч. Новые коды возврата, ВНЕЗАПНО появившиеся в новой редакции GLIBC просто не пройдут - приложение будет брякаться оземь каждый раз, когда на них наступит (мы так обнаружили EAGAIN, к примеру, на блокирующихся сокетах, где его быть не должно, а оно было!)




WebSharperВ смысле? Все необработанные ошибки валятся в логи, и логи регулярно разбираются. В 99% случаев это помогает выявить недокодированные обработки в общем-то вполне себе штатных ситуаций, а не какие-то там исключения.


То есть получается что пока ситуация не возникнет вы об этом не узнаете?
Я то как раз узнаю. И довольно быстро.


WebSharperА как они достигают лога? Вот, например у меня есть вызов какой-нибудь функции. Если нет исключений обычно либо она возвращает код ошибки (типа HRESULT под виндой), либо устанавливает какой-нибудь признак ошибки (типа GetLastError) если ничего специального не делать, то она ни в лог не попадет ни обработается. Могу себе представить, что сообщение второго типа можно записать в лог, но это будет только последнее такая ситуация на момент записи в лог и предыдущую она замаскирует.

Как сделано у вас?

В лог пишется сообщение всегда, и процессом компонента, и отдельно - процессом монитора. Т.е. и процесс сам на себя пишет посмертный некролог (если сможет), и монитор, видя по условиям, что компонент помер (ээээ, heartbeart таймер в shm) - тоже пишет по нему в лог некролог, вдруг у померающего сил не хватит на себя кляузу в лог понаписать (бывает и такое, довольно часто).

Просто системный монитор пишет скупо, а сам помирающий про себя может понапиасть не в пример больше - и стэк трейс, и номера строк, и даже какие локальные и не только значения переменных.

iv_an_rusocimedпропущено...


Ути пути, глаза-то подраззуй, я выше говорил про haproxy и nginx.Поскольку бред ваш мало связен, я даже не пытаюсь увязать ваши разные посты. Если вы не путаетесь на протяжении одного поста, то это у вас уже достижение. Поэтому раз пост про lamp, то и ответ про lamp.

Да и чем бы помогли "haproxy и nginx" --- непонятно.

Человек, не понимающий, как связаны высокие нагрузки и haproxy вещает (сидя в погребе), что ему мало что понятно, и что дескать раз ему, ото сидя в погребе, мало что понятно, то это бред?

Зачот!

Еще каких откровений навернешь, про то что у тебя с основами туговато, и я в этом виноват, не могут тебе в каждом посте развернуто давать ликбез по всем затрагиваемым вопросам?

Это просто жесть, товарищи, просто. Куда я попал?

WebSharpersocimedEHANDLE((n = recv(....)) > 0 || errno == EWOULDBLOCK || errno == EAGAIN)


Вы это ручками вставляете в каждый вызов или у вас есть слой функций с проверками?
Есть ли статический вылидатор (Типа PVS Studio) который убеждается, что EHADNLE не забыли вставить.

Каждый вызов внешних (не своих) функций так оборачивается. Реально - вообще всех (которые возвращают что-то про ошибку, есть такие функции которые не фейлятся никогда чисто по дизайну - их не обернешь). Доверять третьей стороне у меня никаких оснований нет.

Насчет PVS Studio не знаю (не пользуемся), но PC-Lint это (разворачивание макросов) отрабатывает на ура, ну и кто попроще, вроде cppcheck (правда ими уже не пользуемся - толку ноль).


WebSharperпропущено...


Я то как раз узнаю. И довольно быстро.


Обратите внимание на слова Пока ситуация не возникла . То есть чтобы обнаружить необработанную ошибку надо запустить софт и дождаться, чогда он дойдет до определенной ветки.

И еще что происходит с ошибками, которые известны (то есть проходят фильтр в EHANDLE ) как они обрабатываются потом?

Нет, обычно читается вдумчиво документация, и на каждый описанный случай возможных возвратов ошибок пишется обработчик.

Но как уже было писано ранее, често документация врет - к примеру было сказано, что EAGAIN на блокируемых сокетах вроде как не должен возвращаться, а он возвращается.

Пару раз было (не по glibc) что разработчики втихую расширяли список кодов возврата, даже не удосужившись это поместить в Changes (а фигли, типо читайте коммиты и код, ага). Тоже поймали постфактум.

Но обычно редко - заранее прописанные обработки спасают отцов демократии и не только. И это единственно верно, в сравнении с тупейшим (даже кретинским) подходом на finally и catch пофиг какой ошибки, типо на все ошибки обработка одинакова (привет безумный мир ООП).

iv_an_rusocimedЧеловек, не понимающий, как связаны относительно высокие нагрузки и haproxy Поправил. Начиная с какого-то уровня, никакие красивые картинки "здесь у нас фронт а здесь у нас база" _не__ра_бо_та_ют. Round-robin DNS, симметричная кластерная СУБД, в которой каждая нода сама отвечает на HTTP- и прочие запросы, и на этом всё.

Я и так уже понял, что ты в highload не бум бум, не надо усугублять.

iv_an_rusocimed,

Если бы вы имели достаточную квалификацию, чтобы оценки расставлять --- бум бум я или не бум бум --- то мы были бы знакомы либо лично, либо "через одного". Это не шутка и не фигура речи, это медицинский факт. Поэтому если хотите разбираться и учиться --- может быть и есть некий смысл продолжать, если хочется потроллить --- не тратьте всехнее время, КПД все равно ноль.

Вообще-то это рт тебя реально КПД ноль, ни одной свежей идеи, факта или просто мысли ты за все эти страницы не высказал.

Зато наговорил вполне забавных глупостей про архитектуру вашего типо сервера вполне прилично, чтоб я вообще перестал прислушиваться к тому, что ты тут на форумах говоришь иногда.

Что впрочем не важно, ибо пользуются им всего 5 с половиной контор, и то не факт что, что объясняет практически всё.

WebSharpersocimedКаждый вызов внешних (не своих) функций так оборачивается. Реально - вообще всех (которые возвращают что-то про ошибку, есть такие функции которые не фейлятся никогда чисто по дизайну - их не обернешь). Доверять третьей стороне у меня никаких оснований нет.


То есть получается, что в каждом месте, где находится вызов упомянутой recv есть перечисление кодов ошибок нам извенстных внутри вызова макроса EHANDLE. После чего идет уже обработчик ошибок где они же перечисляются еще раз (ну типа кейза большого)?
В целом примерно да, но в данном случае нет.

За сетевой трафик отвечает отдельный компонент, и он может падать при всяких неожиданных чихах. Реально это даже специально сделано - если в канале (сокете) что-то пошло не так, то проще помереть (потому что там может быть атакующий всякими скриптами с той стороны), чем выжить любой ценой и нагадить уже следующему клиенту отказом в обслуживании из-за покренившегося не на шутку внутреннего состояния (для REST API это вообще на 100% полный ОК).

А так, я уже говорил - существует вариант 2 - ты сначала получаешь код возврата, а потом пишешь case обработчики на уже полученный код. Или сразу в switch функцию тулишь, да как угодно.

Макрос EHANDLE - это лишь абстрактный пример. В реальности там целая система, отдельно макросы для сокетов, отдельно для общения с mysql, отдельно для Oracle - там своя кустистая система обработки, но все дергания этих API - только через спец обработчики, никаких игнорирований кодов возврата (кстати, PC-LINT тыкает носом, каждый раз, когда горе кодер забывает про код возврата, и это очень ОК).


Я лишь показал принцип - любой код возврата нужно ловить и разбирать по месту, а не перекладывать проблемы на вызывающего.
У вызывающего вообще мыслей нет на тему того, что у тебя там внизу поломалось, он просто от тебя хочет порцию данных, а никак не горит желанием расхлебывать твои трудности.


WebSharperНасчет PVS Studio не знаю (не пользуемся), но PC-Lint это (разворачивание макросов) отрабатывает на ура, ну и кто попроще, вроде cppcheck (правда ими уже не пользуемся - толку ноль).


Я имел ввиду, что если кто-то забудет обернуть вызов в EHANDLE - будет ругаться какой-нибудь инструмент или нет.
Нет, не будет. Все мне известные анализаторы кода разворачивают даже многократно завернутые друг в друга макроподстановки.

iv_an_rusocimedни одной свежей идеи, факта или просто мысли ты за все эти страницы не высказал.Разумеется. Более того, я не написал ни одной новой свежей буквы. Потому что обсуждается одна общеизвестная азбука с использованием букв другой общеизвестной азбуки. Ни одна из этих двух азбук в нововведениях не нуждается.

Это ты наконец-то решил высказать свежую мысль? Зачем ты это пишешь?