Привет всем.
Случайно обнаружил следующую вещь в исходниках Firebird:
firebird\branches\B2_0_Release\src\jrd\inf_pub.h:
isc_info_db_impl_sun_amd64 = 71, //появился в FB2.0.5
firebird\branches\B2_1_Release\src\jrd\inf_pub.h:
isc_info_db_impl_linux_mipsel = 71, //появился в FB2.1.0 isc_info_db_impl_sun_amd64 = 74, //появился в FB2.1.1
Вздрогнул и полез проверять стабильность идентификаторов в рамках пакетов исправлений.
Привет всем.
В Firebird 2.0 был исправлен алгоритм вычисления размера буфера (XSQLVAR::sqllen) текстовых колонок (CHAR/VARCHAR) — он начал учитывать кодовую страницу подключения. Спасибо Adriano dos Santos Fernandes.
Здесь были чертыхания по поводу кодовой страницы блоба и XSQLVAR::sqlscale
До этого (а в InterBase до сих пор), размер буфера под значение вычислялся как количество символов в столбце умноженное на максимальное количество байт в одном символе кодовой страницы столбца.
Проблема, к примеру, проявляется при попытках прочитать столбца с кодовой страницей WIN1251 в подключении с кодовой страницей UTF8. Вылазит ошибка «Arithmetic exception, numeric overflow, or string truncation».
Я как-то пробовал подсовывать серверу правильно вычисленное значение буфера в XSQLVAR::sqllen, но он там внутри у себя все равно использовал буфер с неправильным размером.
Но недавно появилась мысль — а если попробовать работать не с XSQLDA, а непосредственно с MSG-буфером, где появляется возможность использования таких волшебных типов BLR-типов данных как varying2 и text2, для которых можно указать кодовую страницу?
Если сервер сможет вернуть клиенту текстовые данные без приведения к кодовой странице подключения, то это автоматически решит обозначенную проблему с переполнением буфера. Привести текстовые данные к кодовой странице подключения я могу и сам.
Во какая мысль.
Пожалуй, я её попробую покопать поглубже сразу после того как допилю новый код для работы массивами.
UPD1.
Мысль, наверное, не совсем правильная. Нужно сначала попробовать varying2/text2 с указанием кодовой страницы подключения и правильного размера буфера под данные. Может прокатит.
Привет всем.
Асилил. На этом будем считать, что марафон с v3.27 завершен.
Сейчас надо собирать мозги в кучу и допиливать исправление для CORE-1588.
Потом нас ждут другие, по настоящему интересные задачи.
Привет всем.
В последнее время утомляется чтение как художественной так и технической литературы. Особенно когда рядом есть рабочий компьютер (в смысле, компьютер на котором я работаю). Появляется мысль «Н@#&р, лучше пойти повозиться с кодом. Любым». У меня его на любой вкус и цвет уже — навалом.
Так что прочитанной статье можно сказать повезло.
1. Я сегодня достаточно удолбался выполнять роль отца семейства, чтобы оставить надежду вечером повозиться «со своей прелестью» хотя бы пару часов.
2. На компьютерах работают тесты, которые жалко не то чтобы прерывать, а даже приостанавливать.
Лет двадцать назад я бы даже и не понял о чем в ней написано.
А сейчас («сидя в уютном доме, в приличном районе») могу сказать, что моя семья сделала правильные инвестиции.
—-
Впрочем, лично меня сейчас гораздо больше забавляет то, как моя гора кода, созданная за последнее десятилетие, достаточно без проблем эволюционирует и приспосабливается к моим безбашенным идеям 🙂
—-
UPD. Клиенты, надеюсь уверен, тоже неплохо вложились…
Привет всем.
На днях провел эксперименты, проверяющие работоспособность внешнего исправления для ошибки сервера (FB/IB) — CORE-1588.
Краткое описание ошибки — сервер получает и возвращает VARCHAR-массивы как CSTRING-массивы.
К счастью, этот баг имеет ограниченную область действия — в базу, в конечном итоге, пишутся VARCHAR-массивы. Это можно проверить поэлементным чтением VARCHAR-массивов.
Решение, как и было предположено ранее, заключается в самостоятельном формировании блоба массива.
Извращение, конечно. Хотя бы потому, что нужно учитывать тип процессора, на котором работает сервер базы данных. Эти сведения можно получить через информационное свойство «isc_info_implementation».
Самое приятное то, что в сервере предусмотрена лазейка для этого варварского внешнего формирования блоба с данными массива.
Будет интересно соорудить весь необходимый код и посмотреть на его работу.
Привет всем.
Собственно subj.
Последние несколько недель я размышлял над всем этим процессом и сейчас можно подвести некоторые итоги.
От начала до конца — чуть больше года. Эффективный объем времени, совпадает с начальным прогнозом — 6 месяцев. Остальное время съели релиз ADO.NET провайдера, перевод сайта на WordPress (грустно вздохнул) и другие процессы реальной жизни.
Немножко ошибся с оценкой объема исходного кода подсистемы. Думал уложиться в 800KB. Получилось 1.7MB. Учту на будущее. Впрочем, я думал что код будет компактным, но сложным. А он оказался (в конечном итоге) прямолинейным и объемным.
Объем исходных текстов модульных тестов — 3.7MB. Соотношение 1:2, в последнее время, стало нормой. Всего генерируется 24K тестов. Основной «мультипликатор» — 4 режима протокола соединения (rpc, batch_send, out_of_band, lazy_send).
32-х битная DLL провайдера увеличилась где-то на 670 килобайт. Это больше чем «весит» fbclient.dll. 200KB сожрали ресурсы с шаблонами сообщений серверных ошибок (английский и русский).
Нагрузочное тестирование показывает, что IBProvider при работе через встроенного клиента поедает на 5% процентов процессорного времени меньше, чем через fbclient.dll. А реальное время работы — вообще не поменялось. В целом, здесь сложно ожидать чуда. Код стал немного «умнее», но увеличилось количество проверок. Все, что приезжает из сети, теперь проверяется самым тщательным образом.
(далее…)
Привет всем.
Похоже, 27-е обновление вышло на финишную прямую. И с сайта IBProvider можно загрузить сборку 19276, которая (очень надеюсь) будет релизной.
Основным изменением является добавление поддержки соединения с FB0.9, FB1.0, FB1.5, FB2.0 и FB2.1 без использования fbclient.dll. Это 10-ый и 11-ый протоколы.
Привет всем.
Сегодня обнаружил что нагрузочные тесты с участием 32-битного FB2.5 (SC) уже почти сутки не работают.
Перед заморозкой сервер (он, кстати, в этот раз не упал) мужественно возвращал ошибки типа «unable to allocate memory from operating system», потом WinSock начал возвращать ошибки 10054 и 10061. Новые подключения отклоняются (WinSock last error: 10060).
Посмотрел на это дело через отладчик и задумался над %subj%.
Привет всем.
План до сих пор не утвержден, но пока выполняется день в день.
Уже можно скачать пробную версию 3.27 и попробовать работать с Firebird без использования серверного клиента (fbclient.dll). Краткая инструкция приведена в новости. Выложенные сборки были протестирована с 64-битным и 32-битным сервером (SuperClassic, Windows).
В настоящий момент начато тестирование финальной сборки v3.27.
Привет всем.
Нагрузочное тестирование работы IBProvider (3.27) c FB2.5 через нового встроенного клиента прошло без проблем. Производительность не просела. Исчезла одна ошибка.
В течении недели будет выложен релиз 3.26 и триал 3.27.
Если, конечно, удастся собрать мозги в кучу 🙂
