Size: a a a

1С, БСП, DevOps и Архитектура

2021 February 10

JD

John Doe in 1С, БСП, DevOps и Архитектура
Andrey Borodavko
Нет, как и было выше написано
Однако, это в документации вообще нигде не требуется
Требуется
источник

AB

Andrey Borodavko in 1С, БСП, DevOps и Архитектура
John Doe
Требуется
Где? Только перезапуск веб-сервера
источник

JD

John Doe in 1С, БСП, DevOps и Архитектура
Andrey Borodavko
Где? Только перезапуск веб-сервера
ПРИМЕЧАНИЕ. Измененные значения атрибутов reuseSessions, sessionMaxAge, poolSize, poolTimeout начнут действовать только после перезапуска сервера «1С:Предприятие».
https://its.1c.ru/db/v8315doc#bookmark:adm:TI000000381
источник

AB

Andrey Borodavko in 1С, БСП, DevOps и Архитектура
John Doe
ПРИМЕЧАНИЕ. Измененные значения атрибутов reuseSessions, sessionMaxAge, poolSize, poolTimeout начнут действовать только после перезапуска сервера «1С:Предприятие».
https://its.1c.ru/db/v8315doc#bookmark:adm:TI000000381
Тьфу, блин, три раза страницу перечитывал
источник

AB

Andrey Borodavko in 1С, БСП, DevOps и Архитектура
Не, ну ладно
источник

AB

Andrey Borodavko in 1С, БСП, DevOps и Архитектура
Но у меня-то все равно только 5 соединений с хттп, при пуле 10
источник

AB

Andrey Borodavko in 1С, БСП, DevOps и Архитектура
Как мне получить хотя бы обещанные 8, с учетом запаса
источник

AB

Andrey Borodavko in 1С, БСП, DevOps и Архитектура
Вопрос исходный был именно в том, что прибитые сеансы живут в пуле
источник

JD

John Doe in 1С, БСП, DevOps и Архитектура
Andrey Borodavko
Вопрос исходный был именно в том, что прибитые сеансы живут в пуле
Как и зачем прибиваешь?
источник

AB

Andrey Borodavko in 1С, БСП, DevOps и Архитектура
John Doe
ПРИМЕЧАНИЕ. Измененные значения атрибутов reuseSessions, sessionMaxAge, poolSize, poolTimeout начнут действовать только после перезапуска сервера «1С:Предприятие».
https://its.1c.ru/db/v8315doc#bookmark:adm:TI000000381
И кстати, это написано для веб-сервисов, для http данного уточнения нет. Сложно сказать, что этим имеется ввиду.
источник

JD

John Doe in 1С, БСП, DevOps и Архитектура
Andrey Borodavko
Вопрос исходный был именно в том, что прибитые сеансы живут в пуле
Думаю, это может быть вызвано из-за нестандартного у тебя максимального времени жизни (10 минут).
Через 10 минут после прибития проверь.
источник

AB

Andrey Borodavko in 1С, БСП, DevOps и Архитектура
John Doe
Как и зачем прибиваешь?
Прибить их нужно было, т.к. была кучка сеансов под одним юзером, и кучка под другим
Нужно было чтоб кучка под одним исчезла для возможности добавления новых под другим
источник

JD

John Doe in 1С, БСП, DevOps и Архитектура
Andrey Borodavko
Прибить их нужно было, т.к. была кучка сеансов под одним юзером, и кучка под другим
Нужно было чтоб кучка под одним исчезла для возможности добавления новых под другим
Прибиваемые сеансы что-то делали?
источник

AB

Andrey Borodavko in 1С, БСП, DevOps и Архитектура
John Doe
Прибиваемые сеансы что-то делали?
нет, там время жизни стояло 7200, эти сеансы остались после тестов
источник

JD

John Doe in 1С, БСП, DevOps и Архитектура
Andrey Borodavko
нет, там время жизни стояло 7200, эти сеансы остались после тестов
Перезапускай кластер и не парь мозг)
источник

AB

Andrey Borodavko in 1С, БСП, DevOps и Архитектура
John Doe
Перезапускай кластер и не парь мозг)
низзя, блин :)
придется ждать ночи
источник

JD

John Doe in 1С, БСП, DevOps и Архитектура
Andrey Borodavko
низзя, блин :)
придется ждать ночи
Тогда выжди пару часов (7200).
Возможно, это багофича пула сеансов в кластере - то что убиение сеанса через оснастку не вызывает удаление сеанса из пула. С работой модуля расширения веб-сервера вообще много всяких нежданчиков всплывает в платформе, вплоть до неубиваемых соединений, из-за которых конфигурацию БД невозможно обновить, например.
Ну и попробуй процессы веб-сервера прибить - после этого может хоть 10 у тебя будет пускать. Хотя хз какие у тебя там были настройки на момент считывания файла кластером при запуске - может вообще 5 и стояло.
источник

AB

Andrey Borodavko in 1С, БСП, DevOps и Архитектура
John Doe
Тогда выжди пару часов (7200).
Возможно, это багофича пула сеансов в кластере - то что убиение сеанса через оснастку не вызывает удаление сеанса из пула. С работой модуля расширения веб-сервера вообще много всяких нежданчиков всплывает в платформе, вплоть до неубиваемых соединений, из-за которых конфигурацию БД невозможно обновить, например.
Ну и попробуй процессы веб-сервера прибить - после этого может хоть 10 у тебя будет пускать. Хотя хз какие у тебя там были настройки на момент считывания файла кластером при запуске - может вообще 5 и стояло.
не 5 точно, там были настройки по умолчанию, о наличии которых я узнал случайно, ибо была перепубликация...
я уже с этим приколом с сеансами сталкивался, но думал что может это косяк у меня на локальной базе
а на проде вон как вылезло, начали упираться в лимит.
источник

JD

John Doe in 1С, БСП, DevOps и Архитектура
Andrey Borodavko
не 5 точно, там были настройки по умолчанию, о наличии которых я узнал случайно, ибо была перепубликация...
я уже с этим приколом с сеансами сталкивался, но думал что может это косяк у меня на локальной базе
а на проде вон как вылезло, начали упираться в лимит.
Чтоб не попадать впросак, отвыкай публиковать через конфигуратор
источник

АМ

Александр Медведько... in 1С, БСП, DevOps и Архитектура
Nikita Gryzlov
все шаги одного стэйджа по умолчанию выполняются параллельно. ты можешь переопределить в воркфлоу порядок выполнения стэйджей. ну и публикацию пэйджей вынести в отдельный стэйдж. не обязательно, чтобы оно было в деплое
У нас на одном раннере - последовательно и я так понял что в алфавитном порядке или это совпадение?
источник