4 года с момента релиза FB3
Я напомнил, а дальше вы сами 🙂
Вести с полей
В одной популярной книге по программированию для домохозяек советуют каждый день что-нибудь выкидывать из вещей. Этот ценный совет применим и для сопровождения программных систем.
Решил выкинуть из IBProvider сомнительный метод чтения с I4-колонок с приведением NULL к нулевому значению.
Он используется, в том числе, для чтения значения колонок rdb$procedure_inputs и rdb$procedure_outputs (таблица rdb$procedures).
Хотя бы из кода, работающего с базами данных FB3.
Тем более, что запрос
select * from rdb$procedures x where x.rdb$procedure_inputs is null or x.rdb$procedure_outputs is null
для тестовой базы данных FB3 возвращает пустое множество.
Для тестовой базы IB4.2 (решил копнуть в начале огорода) этот запрос возвращает непустое множество. NULL-ы есть как в INPUTS так и в OUTPUTS.
С тестовой базой FB2.5.9 — ситуация аналогична IB4.2.
А у FB3 (повторюсь) — все OK.
Задумался, улыбнулся, сделал бакап базы FB2.5.9 и отресторил её на FB3.
Фух, все в норме 🙂
Вести с полей. C++17
Текущие тестовые сборки IBProvider (v5.14.0.33732) откомпилированы с указанием режима совместимости с C++17.
Пока в коде IBP ничего из C++17 не используется. Но вот STL таки да — уже из C++17.
Хотя нет. Я же «if constexpr» задействовал во встроенном zlib1, чтобы изничтожить часть предупреждений компилятора…
Из вещей, которые уже очень хочется начать использовать в самом IBProvider:
1. Сокращенное определение вложенных пространств имен
namespace ibp::db_client::remote_fb::api::p12{ .... }
вместо
namespace ibp{namespace db_client{namespace remote_fb{namespace api{namespace p12{ .... }}}}}
2. Fold expressions:
//Код из инсталлятора ADO.NET провайдера, который уже переехал на C++17.
template<typename... Args>
void BA_ErrorUtils::Throw__Error
(HRESULT const hr,
BA_Error_SrcID const srcID,
BA_Error_MsgID const errMsgCode,
Args&&... args)
{
assert(FAILED(hr));
BA_Error exc(hr,srcID,errMsgCode);
(exc<<...<<std::forward<Args>(args));
exc.raise();
}//Throw__Error
Но это все потом.
А пока — v5.14 это тот же v5.13.
—
Вышеобозначенные сборки (v5.14.0.33732) уже проехали через нагрузочное тестирование (которое сейчас работает как хорошо отрегулированный двигатель — без спотыканий).
Так что, думаю, на этой неделе они уйдут в релиз v5.14.
А может и нет — спешить не буду.
Нагрузочное тестирование IBP v5 (vc15)
Обычно, нагрузочное тестирование IBProvider выполняется с использованием сборок, созданных компилятором последней Visual Studio. В настоящий момент времени это VS2019 (сигнатура сборок — vc16).
В личных кабинетах доступны еще сборки, собранные в VS2017.
На днях один очень старый и любимый клиент продлил лицензию. И выбрал сборки VS2017 (сигнатура vc15).
Все бы ничего, но тут на rsdn проскочило сообщение о проблемах с VS2017.
Поэтому, во избежание неприятных неожиданностей, прогнал vc15-сборки последнего релиза IBProvider через нагрузочные тесты.
Все тип-топ.
Обновление инсталлятора ADO.NET провайдера
На сайт загружен обновленный инсталлятор ADO.NET провайдера, который самостоятельно может инсталлировать и деинсталлировать VSIX-пакеты с DDEX-провайдерами для VS2017/VS2019.
Так что, вот в эту инструкцию уже можно не вникать.
Как выглядят костыли в коде (#2)
Привет.
По свежим следам, добавлю сюда заметку про недавнее изменение в коде FB3.
Вкратце о проблеме.
1. Есть объект со счетчиком ссылок (класс rem_port).
2. Этот объект управляется через смарт указатель. И, по идее, проблем быть не должно.
3. Тем не менее у него проблема с управлением времени жизни. Дважды удаляется в многопоточной среде.
4. Потому что конструктор rem_port, за каким-то …, вызывает addRef. И этот инкремент нужно где-то компенсировать однократным вызовом release.
Если я все правильно понял, багу заложили около 12 лет назад. Когда в rem_port добавили счетчик ссылок. Но это так, для ориентира.
Что делает этот патч. Он делает добавляет монопольность этого однократного вызова release.
bool releasePort()
{
Firebird::RefMutexEnsureUnlock portGuard(*port_sync, FB_FUNCTION);
const bool locked = portGuard.tryEnter();
fb_assert(locked);
fb_assert(!(port_flags & PORT_released));
if (port_flags & PORT_released)
return false;
port_flags |= PORT_released;
release();
return true;
}
При этом для блокировки он использует guard (*port_sync) и флаг (port_flags), которые находятся в самом защищаемом объекте.
Я считаю — это гениально.
Нет, правда, аплодирую стоя.
… и в продакшн
%subj% был первой мыслью с утра.
Да, походу оно как-то так у нормальных людей и организовано 🙂
[winsock][BUG CHECK] Чтение из закрытого порта подключения. Ошибка WinSock: 0
Вчера замутил инструкцию по загрузке данных из FireBird в Excel.
Многократно нарывался на %subj%.
Проблему давил OK-еем. Она не сильно мешала достижения финиша.
Позже сообразил, что она уже вылазила. Причем совсем недавно.
В том случае, проблема лечилась указанием имени пользователя в верхнем регистре (GAMER) — это (насколько я понимаю) задействовало SRP-аутентификацию. А с нижним регистром через раз отрабатывала Legacy_Auth аутентификация.
Но вчера SYSDBA был в верхнем регистре!
(далее…)
IBProvider v5.12 и NetProvider v1.16
На сайт и в личные кабинеты загружены очередные обновления OLE DB и ADO.NET провайдеров.
IBProvider v5.12
В IBProvider, как я тут раньше писал, появилась поддержка колонок с автоинкрементом.
А если конкретнее, то во множестве с описанием колонок, получаемом через интерфейс IColumnsRowset, появилась колонка DBCOLUMN_ISAUTOINCREMENT с BOOL-значением. В ней будет True для колонок с автоинкрементом и False для всех остальных колонок.
Забавно, но в провайдер пришлось внести достаточно радикальные изменения, чтобы сделать «все по уму».
На финише, в IBProvider было внесено еще одно изменение — отображение ошибки Z_MEM_ERROR компрессора данных zlib1 на E_OUTOFMEMORY.
Основные сборки (vc16), как положено, прошли через многопоточное нагрузочное тестирование.
NetProvider v1.16
В OleDbDataReader, создаваемом с указанием CommandBehavior.SchemaOnly, разрешено использование методов Read, HasRows, RecordsAffected.
Предыдущие сборки провайдера запрещали такие вызовы и выкидывали исключение.
Клиент, в процессе переезда с System.Data.OleDb, обнаружил это лютое ограничение и попросил убрать его.
Другое
Доработаны и оптимизированы тесты. Причем для обоих провайдеров. Новые тестовые таблички (в которых по 4K колонок) дали всем прикурить.
Из личных кабинетов убраны сборки IBProvider v3. Все, эпоха закончилась.
Лучше день потерять…
…потом за пять минут долететь.
В рамках тестирования следующей версии IBProvider v5.12 была создана пара UBER таблиц c 4096-ю колонок в каждой, которые добили прямолинейные алгоритмы тестирования схем метаданных «schema.002.*» основной тестовой системы.
Их там три штуки. Тот, который грузит схемы без кэширования, до последнего времени работал 6 часов. После появления вышеобозначенной сладкой парочки — 2 дня и 19 часов. То есть 67 часов.
Это означает, что после завершения всех остальных тестов, компьютер еще кучу времени тупил в одно ядро над одним тестом. 9 ядер простаивали.
Страшно думать, сколько бы оно тупило с отладочной сборкой провайдера. Сто пудов — не меньше недели … (далее…)