|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
Здравствуйте. Начиная с версии Firebird 2.5.3, не удаётся сделать shutdown базы если есть два и более неиспользуемых соединения к ней. Команда: Код: sql 1.
просто зависает. Аналогичную проблему я видел в этой теме (Сценарий-2), но там решения я не нашёл.. Как вообще организовать shutdown базы, если есть приложение с пулом соединений? Почему-то при попытке shutdown базы с ключом -attach приложение зависает на попытке закрытия одного соединения до тех пор пока не закончится timeout у shutdown'а... ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2016, 17:00 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudКак вообще организовать shutdown базы, если есть приложение с пулом соединений? Для начала надо очень сильно обосновать необходимость этого. Потом - прочитать полный мануал по gfix и особенно внимательно - раздел о shutdown modes. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2016, 17:11 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovДля начала надо очень сильно обосновать необходимость этого. Необходимость shutdown'а или pool'а соединений? Dimitry SibiryakovПотом - прочитать полный мануал по gfix и особенно внимательно - раздел о shutdown modes. Читал вот эту статью. Есть более полный мануал? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2016, 17:22 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudНачиная с версии Firebird 2.5.3 вплоть до 2.5.6? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2016, 17:32 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
dimitrвплоть до 2.5.6? да ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2016, 17:38 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudНеобходимость shutdown'а или pool'а соединений? Их совместного использования. vitkudЧитал вот эту статью. Очевидно, только первую половину, которая не относится к версии 2.5. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2016, 17:47 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudАналогичную проблему я видел в этой теме (Сценарий-2), но там решения я не нашёл..Даже в указанной теме в первом же сообщении видна правильная строка для шатдауна. gfix -shut full -force 0 ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2016, 18:32 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovvitkudНеобходимость shutdown'а или pool'а соединений? Их совместного использования. пул соединений используется потому как приложения (их несколько) серверные, а shutdown используется в отдельном спец. приложении для обновления, уплотнения и прочих операция с базой... при этом серверные приложения завершать нельзя, они многофункциональные... Dimitry SibiryakovОчевидно, только первую половину, которая не относится к версии 2.5. я прочитал эту статью полностью. по поводу shutdown force: похоже это всё-таки ошибка в FB: http://tracker.firebirdsql.org/browse/CORE-4742 ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2016, 18:36 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudя прочитал эту статью полностью. Так с какого перепоя ты тогда используешь для версии 2.5 синтаксис версии 1.5? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2016, 18:39 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovТак с какого перепоя ты тогда используешь для версии 2.5 синтаксис версии 1.5? но ведь это не запрещено и в доке написано: multi - this is the default mode ... и это значение меня вполне устраивает, и я его явно не указываю для краткости. в любом случае, использование любого другого режима не решает проблему ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2016, 18:53 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
hvladДаже в указанной теме в первом же сообщении видна правильная строка для шатдауна. gfix -shut full -force 0 такой режим мне не подходит, а multi и так является режимом по умолчанию. В любом случае, даже такое решение не работает. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2016, 18:57 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudВ любом случае, даже такое решение не работает. В твоём случае никакое решение не будет работать, обломись. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2016, 19:00 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovВ твоём случае никакое решение не будет работать, обломись. Спасибо на добром слове. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2016, 19:03 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkud, сейчас по-быстрому проверил - действительно, gfix в 2.5.6 ждёт, пока другие коннекты сами не отвалятся. В 3.0 не ждёт. Возможно я чего-то не помню на эту тему, думал что в 2.5 это было исправлено. PS не ведись на Сибирякова, у него хамство бежит впереди всего остального ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2016, 19:17 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
hvladу него хамство бежит впереди всего остального Зато ты сегодня даже мозг включать не требуешь. Съел чего-нибудь нехорошее? Или просто не обратил внимание на слова "уплотнение базы"?.. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2016, 19:56 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, тебя нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2016, 20:20 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
злые вы велосипеды вам надо Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
21.09.2016, 13:17 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakovhvladу него хамство бежит впереди всего остального Зато ты сегодня даже мозг включать не требуешь. Съел чего-нибудь нехорошее? Или просто не обратил внимание на слова "уплотнение базы"?.. если уж делать "стройную систему подпорок и костылей", то можно делать в два шага, наверное. Сначала базу переводить в полный шатдаун, а потом переводить в single-user для обслуживания. Ну и потом - обратно в норму. Хотя один чёрт непонятно - а почему нельзя исправить само приложение. Или на худой конец рвануть все коннекты файрволом на долю секунды. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.09.2016, 16:36 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
Arioch, да хрен знает, кто там "зависает", и как. shut -force блокирует коннекты, понятно что они "зависают", надо отключиться и подключиться снова (под sysdba). Насчет "уплотнения базы" - да, стрёмный термин, неясно что там автор себе соображает. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2016, 00:48 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
kdvда хрен знает, кто там "зависает", и как. shut -force блокирует коннекты, понятно что они "зависают", надо отключиться и подключиться снова (под sysdba). Пороблема в том что зависает процесс "shut -force" хотя там стоит таймаут 0, а вот в 2.5.2 всё нормально... kdvНасчет "уплотнения базы" - да, стрёмный термин, неясно что там автор себе соображает. Я прошу прощения что не знаю устоявшийся русский термин. Это я о том, о чём написано тут , т.е. о backup/restore.. Просто базы иногда "раздуваются" и сами обратно не "сдуваются", а места мало... Эта практика пошла еще с 1.5, может в 2.5 есть другой механизм для этого? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2016, 11:20 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkud, если мусор собирается, то никаких "вспучиваний" не будет. Свободное пространство будет использовано повторно. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2016, 11:21 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
Ariochесли уж делать "стройную систему подпорок и костылей", то можно делать в два шага, наверное. Сначала базу переводить в полный шатдаун, а потом переводить в single-user для обслуживания. Ну и потом - обратно в норму. Собственно проблема в том, что не удаётся перевести базу в шатдаун (начиная с 2.5.3) нитка зависает.. AriochХотя один чёрт непонятно - а почему нельзя исправить само приложение. Или на худой конец рвануть все коннекты файрволом на долю секунды. Тут проблема в том, что есть много приложений (и локальных, и удалённых) и много баз, и нельзя останавливать ни приложения, ни Firebird. Если не использовать механизм shutdown, то для удаления базы надо как-то оповестить все приложения о том что эта база готовится к удалению, и дождаться когда все отцепятся. Но если хоть одно приложение "зависло" с открытым соединением - то облом.. Плюс нужно придумать механизм для оповещения, в том числе и удалённых приложений (без доступа к ФС). А вообще, я правильно понимаю что использование механизма shutdown всячески порицается? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2016, 11:34 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
Симонов Денисесли мусор собирается, то никаких "вспучиваний" не будет. Свободное пространство будет использовано повторно. Иногда в базу попадет много ненужных данных (по ошибке пользователей или ПО, не важно), и после их удаления база остаётся огромных размеров... ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2016, 11:39 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudА вообще, я правильно понимаю что использование механизма shutdown всячески порицается?Совершенно не правильно ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2016, 12:07 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudА вообще, я правильно понимаю что использование механизма shutdown всячески порицается? Порицается не использование shutdown, а бессмысленное использование backup/restore. Точнее backup нужен всегда, а вот постоянный рестор для уменьшения БД абсолютно бессмысленное занятие. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2016, 12:15 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
Симонов ДенисПорицается не использование shutdown, а бессмысленное использование backup/restore. Точнее backup нужен всегда, а вот постоянный рестор для уменьшения БД абсолютно бессмысленное занятие. Но мой вопрос именно про shutdown, backup/restore используется совсем не часто, но используется и эффект есть... А гораздо чаще я использую shutdown для подмены базы в интеграционных тестах, но это не имеет отношения к теме.. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2016, 12:52 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudПлюс нужно придумать механизм для оповещения, в том числе и удалённых приложений (без доступа к ФС). http://www.sql.ru/forum/187250 http://www.firebirdsql.org/file/documentation/papers_presentations/Power_Firebird_events.pdf http://firebirdsql.org/file/documentation/reference_manuals/reference_material/Firebird-2_5-LangRef-Update-Russian.pdf ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2016, 12:53 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudЕсли не использовать механизм shutdown, то для удаления базы надо как-то оповестить все приложения о том что эта база готовится к удалению еще можно попробовать отстрелить соединения с помощью monitoring tables вроде бы, но говорят не всегда хорошо получается а сервер - супер или классик? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2016, 12:55 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
Arioch http://www.sql.ru/forum/187250 http://www.firebirdsql.org/file/documentation/papers_presentations/Power_Firebird_events.pdf http://firebirdsql.org/file/documentation/reference_manuals/reference_material/Firebird-2_5-LangRef-Update-Russian.pdf Спасибо, но это вариант не подходит, т.к. приложению еще нужно понять что подсоединяться к БД можно, а как сделать это не соединяясь с ней? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2016, 13:54 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
Ariochа сервер - супер или классик? SS... Но хотелось бы, конечно, универсальное решение... ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2016, 13:58 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudAriochа сервер - супер или классик? SS... Но хотелось бы, конечно, универсальное решение... просто на классике можно отстреливать через процессы попробуй отключать всех через мониторинговые таблицы. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2016, 15:54 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudприложению еще нужно понять что подсоединяться к БД можно, а как сделать это не соединяясь с ней? а как оно это поймёт в случае shutdown'a ? сделай после события достаточно большую паузу между пересоединениями чтобы все успели отключиться и shutdown успел отработать Либо уже заводи отдельную цетнрализованную БД "доступность рабочих БД" и пуст ьвсе аппликухи туда поглядывают. Заодно сможешь сделать веб-страничку "статус наших баз данных" ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2016, 15:56 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
Ariochvitkudпропущено... SS... Но хотелось бы, конечно, универсальное решение... просто на классике можно отстреливать через процессы попробуй отключать всех через мониторинговые таблицы. не забудь прибить sweep заодно. очень полезно для здоровья базы. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2016, 16:33 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
Ariochа как оно это поймёт в случае shutdown'a ? в случае shutdown force 0 база сразу переходит в shutdown и обычные пользователи не могут подключиться, но это работало до 2.5.3. А в 2.5.3-2.5.6 все зависают... А shutdown attach с таймаутом не получатся использовать, потому как он не только "замораживает" попытки открытия баз, но и попытки закрытия, и если в одном потоке несколько соединений, то поток ждёт пока не закончится таймаут у shutdown'а, и только потом закрывает все соединения, а сам shutdown, соответственно, завершается неудачей... Ariochсделай после события достаточно большую паузу между пересоединениями чтобы все успели отключиться и shutdown успел отработать получается что нельзя запускать shutdown пока все не отключатся, а как узнать что все отключились? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2016, 17:24 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudа как узнать что все отключились? через мониторинговые таблицы от SYSDBA ну или таки сделай все же центральную БД доступности ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2016, 17:34 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkud, ну и да, служебные пoдключения типа sweep'a тоже учитывай ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2016, 17:34 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudбаза остаётся огромных размеров... например? 100 гиг, 500 гиг? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2016, 20:20 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudSS... Но хотелось бы, конечно, универсальное решение...Самым универсальным решением будет написать управляющую службу по типу fbguard, которая по отдельному tcp порту будет "рассказывать" клиентам о состоянии службы сервера и баз данных, а также, при необходимости, производить все необходимые манипуляции по shutdown'у баз, остановки службы сервера и т.д. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2016, 10:04 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudКак вообще организовать shutdown базы, если есть приложение с пулом соединений? Почему-то при попытке shutdown базы с ключом -attach приложение зависает на попытке закрытия одного соединения до тех пор пока не закончится timeout у shutdown'а... "-at[tach] : this parameter prevents any new connections to the database from being made with the exception of the SYSDBA and the database owner. The shutdown will fail if there are any sessions connected after the timeout period has expired. It makes no difference if those connected sessions belong to the SYSDBA, the database owner or any other user." Gfix - Database Housekeeping -> Database Startup and Shutdown Что мешает рубануть запросом в isql из имени SYSDBA или владельца БД все пользовательские соединения, пока выполняется: gfix -shut -attach <timeout> <db> ? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2016, 10:16 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
*из isql от имени SYSDBA P.S. И почему на форуме не сделана возможность исправления своих сообщений? Не понимаю. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2016, 10:18 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
rdb_dev, 1) потому что NNTP 2) потому что тролли этим пользовались, чтобы задним числом удалять компромат ... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2016, 11:38 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
kdvнапример? 100 гиг, 500 гиг? Ха, бывает что в системе всего 32 гига, а нужно еще место для бэкапов.. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2016, 11:46 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudбывает что в системе всего 32 гига, а нужно еще место для бэкапов.. Если бэкапы делаются на тот же диск, где и сама база, то можно сэкономить: вообще их не делать. Всё равно они совершенно бесполезны. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2016, 11:53 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
rdb_dev "-at[tach] : this parameter prevents any new connections to the database from being made with the exception of the SYSDBA and the database owner. The shutdown will fail if there are any sessions connected after the timeout period has expired. It makes no difference if those connected sessions belong to the SYSDBA, the database owner or any other user." Gfix - Database Housekeeping -> Database Startup and Shutdown Да в описании всё хорошо, но на практике, вызывая gfix -shut -attach <timeout> мы блокируем клиентов, которые хотят "добровольно" закрыть все свои соединения (если их больше одного)... rdb_devЧто мешает рубануть запросом в isql из имени SYSDBA или владельца БД все пользовательские соединения, пока выполняется: gfix -shut -attach <timeout> <db> ? Я просто не знал что есть такая возможность... пойду искать как это делается.. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2016, 12:43 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudно на практике, вызывая gfix -shut -attach <timeout> мы блокируем клиентов, которые хотят "добровольно" закрыть все свои соединения (если их больше одного)...Это что-то новое ... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2016, 13:47 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudЯ просто не знал что есть такая возможность... пойду искать как это делается..Вот как-то так: Код: cmd 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26.
... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2016, 14:57 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
Вот же кривущий форматтер!... Не забудь убрать лишние строки, особенно после строк, заканчивающихся на ^ ... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2016, 14:58 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
hvladЭто что-то новое Вот скрипт на Groovy: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55.
который создаёт пустую базу, открывает 3 соединения к ней, и пытается перевести её в режим shutdown в течении 20 сек. Параллельно, в отдельном потоке, пытается закрыть по одному соединению в секунду. Но при попытке закрыть первое же соединение, поток "замирает" до неудачного завершения shutdown'а, и только после этого закрывает остальные соединения. Вот такой вывод у меня в консоль: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2016, 17:25 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudПараллельно, в отдельном потоке, пытается закрыть по одному соединению в секунду. Но при попытке закрыть первое же соединение, поток "замирает" до неудачного завершения shutdown'а, и только после этого закрывает остальные соединения.Есс-но. Оно же всё в одном потоке. У тебя в примере нет никаких vitkudклиентов, которые хотят "добровольно" закрыть все свои соединения (если их больше одного).Ибо кроме gfix'а есть ровно один клиент, который что-то там хочет. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2016, 17:43 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
Проверил с isql: запустил 3 штуки isql запустил gfix -shut -force 0 он висит в каждом isql делаю exit - никакого ожидания, мгновенный дисконнект с ошибкой database shutdown на попытках коммита своих тр-ций. Если сделать commit заранее (сразу после старта isql и до запуска gfix) - никаких ошибок на exit нет. После последнего дисконнекта gfix просыпается и тоже отключается, без ошибки ... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2016, 17:48 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
rdb_devВот как-то так: ... Спасибо за пример, я и сам уже попробовал такой вариант, он не работает. Соединение в отдельном потоке/процессе, после запуска процедуры shutdown, не создаётся пока shutdown не завершится.. Попытка создать соединение раньше - не помогает.. Но зато, думаю, заработает вариант с поочерёдным запуском shutdown'а с нулевым таймаутом и запроса закрывающего соединения, и так до победного конца.. кривовато, конечно.. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2016, 17:53 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
hvladЕсс-но. Оно же всё в одном потоке. У тебя в примере нет никаких vitkudклиентов, которые хотят "добровольно" закрыть все свои соединения (если их больше одного).Ибо кроме gfix'а есть ровно один клиент, который что-то там хочет. в моём описании "их" относилось к соединениям, т.е. несколько клиентов с несколькими соединениями в каждом. А для примера достаточно одного клиента с несколькими соединениями. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2016, 17:58 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkud, ты противоречишь сам себе. Сначала говоришь про много соединений (неважно, сколько процессов на клиенте их создаёт). В коде твоём нет "много соединений", они создаются и уничтожаются по-одному, последовательно. Далее, опция -att не убивает текущие коннекты, в отличие от -force. Если приспичило пользовать именно -att, сделай сначала DELETE FROM MON$ATTACHMENT в любом коннекте. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2016, 18:04 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
hvladПроверил с isql: запустил 3 штуки isql isql работает с одним соединением одновременно, а вот если например в IBExpert'е зарегистрировать дважды одну базу и открыть обе... ... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2016, 18:16 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudisql работает с одним соединением одновременно, а вот если например в IBExpert'е зарегистрировать дважды одну базу и открыть обе...У тебя что, однопоточное приложение обслуживает сотню коннектов ? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2016, 19:48 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudСпасибо за пример, я и сам уже попробовал такой вариант, он не работает. Соединение в отдельном потоке/процессе, после запуска процедуры shutdown, не создаётся пока shutdown не завершится..У меня в isql от имени SYSDBA соединение прекрасно создается после "-shut -attach" и скрипт дропает подключения в соответствии с условием в предложении WHERE. Если вы пишите какой-то высоконагруженный сервер, для которого необходим пул соединений и очень хотите, чтобы сервер сам закрывал свои соединения с базой, создайте отдельно службу управления базой/сервером FB с которой ваш высоконагруженный сервер будет держать соединение и получать от этой службы указания в том числе и на закрытие всех соединений. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.09.2016, 03:08 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
hvladУ тебя что, однопоточное приложение обслуживает сотню коннектов ? Почему сразу однопоточное? Потоков несколько, но пул соединений закрывается в одном. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2016, 11:25 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
rdb_devУ меня в isql от имени SYSDBA соединение прекрасно создается после "-shut -attach" и скрипт дропает подключения в соответствии с условием в предложении WHERE. в смысле после неудачного выполнения "-shut -attach"? Так в чём тогда смысл? Или прямо во время выполнения? Тогда странно, у меня второй процесс ждёт когда завершится таймаут у shutdown'а, особенно заметно это если установить таймаут на 30 сек.. rdb_devЕсли вы пишите какой-то высоконагруженный сервер, для которого необходим пул соединений ... да нет, обычной сервер, просто пул используется для того чтобы реже подключаться к БД.. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2016, 11:37 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
hvladты противоречишь сам себе. Сначала говоришь про много соединений (неважно, сколько процессов на клиенте их создаёт). В коде твоём нет "много соединений", они создаются и уничтожаются по-одному, последовательно. Под соединениями я подразумеваю объекты типа "Connection", и изначально я писал о двух и более соединениях.. hvladДалее, опция -att не убивает текущие коннекты ... это понятно, но он мешает закрыть пул соединений hvlad... в отличие от -force. а -force - зависает, начиная с 2.5.3... hvladЕсли приспичило пользовать именно -att, сделай сначала DELETE FROM MON$ATTACHMENT в любом коннекте. не приспичило, а вынужден... судя по всему придётся пользоваться таким решением, хоть оно и несколько "кривовато"... ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2016, 11:49 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkud, я не вижу, чтобы дисконнекты зависали на фоне gfix -force ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2016, 12:31 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
hvladя не вижу, чтобы дисконнекты зависали на фоне gfix -force вот практически тот же скрипт на Groovy: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55.
с 2.5.2 вывод такой: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
а вот вывод с 2.5.6: Код: sql 1. 2.
и всё, не завершается.. кстати, если timeout у shutdown'а установить в 0, то на 2.5.6 такой вывод: Код: sql 1. 2. 3. 4.
но опять-таки зависает... ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2016, 12:59 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
А ты уверен, что внутри у jdbc драйвера подключения и отключения не сериализуются? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2016, 13:20 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkud, допилил, попробуй: Создаем в БД процедуру: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
cmd скрипт: Код: powershell 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32.
... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2016, 13:40 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
rdb_devvitkud, допилил, попробуй: ... Спасибо, попробовал - тоже самое. Я даже увеличил таймауты в 10 раз, и наблюдал по загрузки проца как ожидает своего часа процедура, но до тех пор пока shutdown не вылетит по timeout-у процесс с isql не завершается.. Собственно для проверки можно использовать тот же IBExpress: просто продублировать в нём соединение 2-3 раза и открыть их.. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2016, 14:43 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkud, Я вижу следующее: - gfix -shut -force 0 блокируется до тех пор, пока не отсоединятся все существующие коннекты - Существующие коннекты при этом блокируются при дисконнекте (простые тесты с isql это не подтверждают) - Приложение на JayBird с пулом коннектов не может одновременно сделать шатдаун (в одном потоке) и закрыть все свои коннекты из другого потока. Варианты: а) написать трекеру и ждать когда починят в 2.5.6+ (я вижу, где он ждёт) б) перейти на fb3 (там нет проблемы) в) создать обходной путь, рассчитанный на конкретное приложение ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2016, 15:15 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
hvladvitkud, Я вижу следующее: - gfix -shut -force 0 блокируется до тех пор, пока не отсоединятся все существующие коннекты - Существующие коннекты при этом блокируются при дисконнекте (простые тесты с isql это не подтверждают)Забавно, что если на момент запуска gfix -shut -attach к базе открыто не более двух любых подключений (включая подключение isql, в котором выполняется DELETE FROM MON$ATTACHMENTS), то ХП на удаление выполняется сразу и база нормально "кладется в shutdown". ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2016, 15:48 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
rdb_dev Код: plsql 1. 2.
Я не любитель фраз про "отрывание рук за такой код", но могу и пересмотреть свю точку зрения :) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2016, 16:37 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
hvlad- Существующие коннекты при этом блокируются при дисконнекте (простые тесты с isql это не подтверждают) да, с одним соединением проблем нет, а isql работает с одним соединением.. hvlad- Приложение на JayBird с пулом коннектов не может одновременно сделать шатдаун (в одном потоке) и закрыть все свои коннекты из другого потока. необязательно JayBird, то же самое повторяется с использованием IBExpert'а и gfix'а hvladВарианты: а) написать трекеру и ждать когда починят в 2.5.6+ (я вижу, где он ждёт) я уже нашёл на трекере такую проблему: CORE-4742 hvladб) перейти на fb3 (там нет проблемы) это всенепременно, но переход займёт много времени hvladв) создать обходной путь, рассчитанный на конкретное приложение так и поступлю. Спасибо за уделённое время. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2016, 16:37 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
hvladЯ не любитель фраз про "отрывание рук за такой код", но могу и пересмотреть свю точку зрения :)К сожалению, пока ничего лучше для реализации задержки в транзакции придумать не смог. Подскажи, если знаешь способ лучше. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2016, 16:44 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudда, с одним соединением проблем нет, а isql работает с одним соединением..Да по барабану это. isql нормально закрывает свой коннект, шатдаун этому не мешает. Не мешает шатдаун закрывать коннекты. Не мешает. Прочитай вот тут *каждое* слово, а не через десять : hvlad- Приложение на JayBird с пулом коннектов не может одновременно сделать шатдаун (в одном потоке) и закрыть все свои коннекты из другого потока. vitkudнеобязательно JayBird, то же самое повторяется с использованием IBExpert'а и gfix'аПроверил - не подтверждаю. IBE закрывает 4 клонированных DB и кричит при этом про database shutdown ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2016, 16:46 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
rdb_devhvladЯ не любитель фраз про "отрывание рук за такой код", но могу и пересмотреть свю точку зрения :)К сожалению, пока ничего лучше для реализации задержки в транзакции придумать не смог. Подскажи, если знаешь способ лучше.Лучше - не ставить себе глупые задачи ;) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2016, 16:47 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
hvlad, да были бы задачи, а то так... Эксперимент. Хотелось из скрипта создать соединение до shutdown, а произвести DELETE FROM MON$ATTACHMENTS уже в процессе работы gfix -shut -attach. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2016, 16:51 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
rdb_devhvlad, да были бы задачи, а то так... Эксперимент. В качестве эксперимента, у себя - что угодно делай. Но ты же другому человеку, да ещё и неопытному, каку советуешь... ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2016, 16:55 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
hvladЯ вижу следующее: - gfix -shut -force 0 блокируется до тех пор, пока не отсоединятся все существующие коннектыКстати, проблема не наблюдается с SC\CS - gfix не блокируется, коннекты по факту отключены. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2016, 17:02 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
hvlad, ну почему сразу "каку"? Не вижу ничего плохого в том, что транзакция секунду пошуршит вхолостую перед отбрасыванием соединений к БД, ничего, при этом, не блокируя. Последний пример был как вариант для проверки, против предыдущего, где соединение из isql устанавливалось в уже процессе выполнения gfix -shut -attach. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2016, 17:03 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
rdb_devНе вижу ничего плохого в том, что транзакция секунду пошуршит вхолостую перед отбрасыванием соединений к БД, ничего, при этом, не блокируя.Это ты немножко пальцем в небо ткнул - и про "секунду", и про "не блокируя" ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2016, 17:04 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
rdb_dev, под Таблоида решил закосить? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2016, 17:04 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
Симонов Денис, Таблоид тоже любитель поразвлечься с пакетными файлами? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2016, 17:06 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
hvladЭто ты немножко пальцем в небо ткнул - и про "секунду", и про "не блокируя"А это мысль... Надо попробовать DELETE FROM MON$ATTACHMENTS в автономной транзакции. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2016, 17:09 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
те же яйца... ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2016, 17:18 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
hvladПроверил - не подтверждаю. IBE закрывает 4 клонированных DB и кричит при этом про database shutdown Да, действительно при shut ... -force 0 сам gfix ждёт пока не закроются все соединения, а в IBE они закрываются при "клике" на них, по еггогу (видать IBE пытается выполнит какой-нибудь служебный запрос). что в общем-то тоже не круто, ведь таймаут-то 0.. Но, если запустить shut ... -force 40, и в эти 40 секунд попытаться закрыть соединение - то будет самое неприятное :) (соединений должно быть минимум 3) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2016, 17:42 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudДа, действительно при shut ... -force 0 сам gfix ждёт пока не закроются все соединения, а в IBE они закрываются при "клике" на нихНу так чего тебе ещё надобно ? vitkudчто в общем-то тоже не круто, ведь таймаут-то 00 в данном случае означает ожидание до упора. Что тебе "не круто" - я не знаю vitkudНо, если запустить shut ... -force 40Тебе шашечки, или ехать ? Ещё раз - SC\CS не имеют этой проблемы. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2016, 17:54 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
hvlad, что-то давненько в ветке 2.5 не было ночных снапшотов с какими-либо исправлениями и/или дополнениями. Неужто 2.5 по тихому сняли с поддержки? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2016, 18:11 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
hvlad0 в данном случае означает ожидание до упора. Что тебе "не круто" - я не знаю в документации этого нет, да и указание одной секунды не сильно меняет ситуацию.. а "не круто" то что если зависнет приложение с соединениями, то и моё зависнет при попытке shutdown'а.. hvladТебе шашечки, или ехать ? Ехать с шашечками :) hvladЕщё раз - SC\CS не имеют этой проблемы. Но клиенты обычно ставят то что по умолчанию, а в Windows это SS... ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2016, 18:51 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudhvlad0 в данном случае означает ожидание до упора. Что тебе "не круто" - я не знаю в документации этого неттеперь ты это знаешь vitkudда и указание одной секунды не сильно меняет ситуацию.. а "не круто" то что если зависнет приложение с соединениями, то и моё зависнет при попытке shutdown'а..Тебе всё рассказали, даже больше. Решений несколько, выбирай любое. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2016, 19:26 |
|
FB >2.5.2: gfix -shut -force 0 - зависает при двух открытых соединениях
|
|||
---|---|---|---|
#18+
vitkudпо поводу shutdown force: похоже это всё-таки ошибка в FB: http://tracker.firebirdsql.org/browse/CORE-4742 Можешь завтра попробовать с новым снапшотом 2.5.7 ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2016, 19:57 |
|
|
start [/forum/topic.php?all=1&fid=40&tid=1561952]: |
0ms |
get settings: |
10ms |
get forum list: |
9ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
47ms |
get topic data: |
10ms |
get forum data: |
4ms |
get page messages: |
94ms |
get tp. blocked users: |
1ms |
others: | 11ms |
total: | 194ms |
0 / 0 |