iBase.ru Forum

Добрый день
Есть система на FB 2.1.0 классик, постоянно подключено и работают 7-8 клиентов. У клиентов стали появляться ошибки вроде "deadlock update conflicts with concurrent update page size parameter missing" и "deadlock update conflicts with concurrent update unknown ISC error 335544878" с регулярностью от 2 до 20 раз в день. В логе птицы - "INET/inet_error: send errno = 10054", "INET/inet_error: connect errno = 10061", "SERVER/process_packet: broken port, server exiting", хотя по времени они не совсем совпадают с временем записей в логах клиентов.

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

Про keepalive читал, но дело в том, что мне нужно моментально отреагировать на ситуацию в клиентском приложении. Для оператора ждать минуту или даже полминуты очень нехорошо. Т.е. моя задача в том, чтобы настроить сервак/локалку/изменить систему/др.варианты, так чтобы требуемые операции выполнялись в штатном режиме, в т.ч. при кратковременных потерях конекта. Куда посоветуете копать?
спс

Я бы начал с того, чтоб клиента правильно установил, и тогда не было б "unknown ISC error 335544878"

WildSery писал(а):Я бы начал с того, чтоб клиента правильно установил, и тогда не было б "unknown ISC error 335544878"

в смысле? какого клиента и что значит правильно?

Обычного, клиента Firebird.
Тогда и сообщение об ошибке будет нормальным, а не это нечто.

Переставил на серваке последнюю версию птицы, все checkbox в инсталяхе = true. Для эксперимента поставил супер вместо классика (было предположение что дедлоки появились после перехода на классик). В conf от стандартного отличается:
DefaultDbCachePages = 11264
LockMemSize = 16777216
Это является "правильной установкой"?

vik писал(а):Переставил на серваке

тебе про клиента говорят, а ты сервак переставляешь. Найди все fbclient.dll на клиентских машинах и убедись, что они версии не ниже 2.1.0.

vik писал(а):У клиентов стали появляться ошибки вроде "deadlock update conflicts with concurrent update"

код клиентских аппликух есть на руках? Какие там параметры транзакций используются?

vik писал(а):Если я правильно понимаю, то суть проблемы в том что происходят кратковременные потери коннекта, после чего зависают незакрытые транзакции. Так ли это?

вполне возможно. Особенно в случае классика.

vik писал(а):моя задача в том, чтобы настроить сервак/локалку/изменить систему/др.варианты, так чтобы требуемые операции выполнялись в штатном режиме, в т.ч. при кратковременных потерях конекта.

регулярные потери соединения с сервером - это не есть штатный режим работы

dimitr писал(а):Найди все fbclient.dll на клиентских машинах и убедись, что они версии не ниже 2.1.0.

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

dimitr писал(а):код клиентских аппликух есть на руках? Какие там параметры транзакций используются?

Да, код есть целиком, только проблема в том что система жутко старая и неустойчива к любым изменениям. Юзаются стандартные IBxxx, причем не последней версии и обновить их мягко говоря проблематично, в проекте полно IBClientDataSet, переписывать уйму всего придётся. В транзакции дополнительных параметров не указано, т.е. все значения дефолтные. Кст ещё недавно была проблема с постоянным появлением "out of memory", не знаю связано ли это с этими дедлоками. Избавился путём дополнительной синхронизации в потоках и прикручиванием менеджера памяти (Fast4MM).

dimitr писал(а):регулярные потери соединения с сервером - это не есть штатный режим работы

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

Во-вторых - потери коннекта может и не штатный режим, но скажем так - мне поставлена задача свести его к штатному с точки зрения конечного пользователя. Т.е. влияние на работу операторов должно быть минимальным. А я пока не знаю откуда начать )) Как определить где проблема - в настройке фб, в настройке сервака/клиентских машин или в логике самого приложения? Соответственно в зависимости от причины мне нужно будет поменять логику, чтобы оператору выдавать либо "всё нормально, продолжай работать" либо "стоп, сделай А, Б, Ц...". Т.е. ключевой вопрос - как точно определить причину вылета указаных ошибок?

В транзакции дополнительных параметров не указано, т.е. все значения дефолтные.

это пипец просто. Значит все транзакции snapshot.

kdv писал(а):

В транзакции дополнительных параметров не указано, т.е. все значения дефолтные.

это пипец просто. Значит все транзакции snapshot.

та ладно...:shock: а какой догадался на дефалт поставить снеп?....
спс за наводку, это место я подправлю. вот только связано ли это с собсно сабжем? снеп снепом, но дедлок может быть только на изменении, а изменяют они совсем немного, там нет длинных транзакций...

Какая разница, длинные или короткие? Главное, есть конкурентные. Этого достаточно.

WildSery писал(а):Какая разница, длинные или короткие? Главное, есть конкурентные. Этого достаточно.

но если две снеп транзакции пишут разные таблицы/записи это же не может привести к дедлоку? или я чего не понимаю?
в смысле в чем они конкурировать будут, если меняют разные данные?

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

WildSery писал(а):Если бы они всегда меняли строго разные данные, и никогда сначала один, а потом второй одни и те же, то дедлока не могло возникнуть в принципе.

Есть такое штуко в природе - триггер

Merlin писал(а):Есть такое штуко в природе - триггер

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

Всё бы ничего, только раньше дедлоков не наблюдалось. Те изменения которые были в проге не могли привести к столь частому их появлению. Потому и подозрение, что дело может быть не только в логике проги.
В любом случае попробую для начала проверить либы и переделать транзакции. Хотя подозреваю что проблему это не решит.
спс, отпишу по результатам.

а какой догадался на дефалт поставить снеп?....

а какой нихрена не читает про транзакции?
снапшот в IBX по умолчанию отроду, как и в IB/FB.
www.ibase.ru/devinfo/ibx.htm
www.ibase.ru/devinfo/ibtrans.htm

kdv писал(а): а какой нихрена не читает про транзакции?
снапшот в IBX по умолчанию отроду, как и в IB/FB.

читал я всё, читал, просто всегда юзаю FIBPlus, а там дефалт read commited, посему на дефалт фб не обратил внимания

а там дефалт read commited, посему на дефалт фб не обратил внимания

мораль - все равно не читал. и дефолты - отстой
А деврейсов лупить надо за исправление дефолта.

Такие вещи, как параметры транзакции, надо дефолтовые делать такими, чтобы вообще ничего не работало.
Тогда появится чёткий стимул - не прочитал - не разобрался - не работает.
ИМХО.