Нет в этом необходимости. Это настолько редкая ситуация. Ну отправится раз в год одно и тоже сообщени дважды.. ну и ладно

Халтура же жжжжжж)))

На каждый сервис - свой узел

Никак нет. Просто на той стороне один и тот же объект запишется дважды одним и тем же содержимым

Это какая-то дичь, коллега) наверное так говорите пока ваш предоплаченный заказ какой-то сервиса не пропал)

В каких случаях дичь?

Мы же профессионалы! Неоптимальность детектед)

Зато обработка очереди конкурирует с записью документа.
Т.е. текущее решение не будет масштабироваться на случай когда интенсивность ввода документов возрастет и / или когда длительность обработки (отправки) возрастет настолько, что это будет мешать пользователям / процессам которые меняют документ.
А ведь исправить эту потенциальную проблему весьма просто - просто не блокировать документ, а блокировать запись очереди. Минимальные усилия.

Привет. Подскажите, а новый механизм реструктуризации реально работает? Есть какие-то нюансы или проблемы с ним?
У нас реструктуризация 6 часов. Хотелось бы побыстрее. Получится с помощью нового механизма ускорить? Кто-нибудь пробовал?

Небось maxdop у сервера / базы стоит 1?

Лучше сразу ссылкой https://its.1c.ru/db/metod8dev#content:5945:hdoc

работает круто, но иногда падает
и не переваривает то что руками в скуле создали

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

долго в СУБД, или долго на стороне 1С очистка данных (визуально можно понять по счетчику в строке состояния)?

Долго молотит  журналы документов. Половина времени уходит на них. Их всего 5

так а кто молотит то? СУБД или 1С ?

Затрудняюсь ответить.
Мы наблюдали это в конфигураторе.

это не сильно мешает, потому что копирования из таблицы в таблицу при реструктуризации занимает, например, минуты. А та же таблица при удалении типа из какого-нибудь реквизита требует полного обхода таблицы и обработки записей на стороне сервера 1С. И это уже не 1 минута, 20-40 минут.
Когда не было "джава-реструктуризации" на всех проектах было правило не удалять метаданные, не менять типы, чтобы не допускать подобных ситуаций. Их отвественный специалист планировал сам (по необходимости с манипуляцией с заменой таблиц в субд, если не вписывались в техокно 30мин в сутки).

Добрый день.
Возможно кто-то уже сталкивался с подобной ошибкой.
Версия платформы 8.3.18.1289
Получили на этой неделе лицензию КОРП, воспользовались механизмом «Фонового обновления конфигурации», при самом обновлении никаких ошибок не возникло, после обновления заходим в клиент 1С и при открытии многих форм списков, документов, элементов планов обмена получаем ошибку:
Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm:
по причине:
Ошибка при выполнении операции с информационной базой
Запись не найдена в менеджере имен базы данных.
После остаётся только закрыть или перезагрузить клиент 1С.  
Что пробовали:
- Почистили кэш локальный, серверный.
- Откатываться на предыдущий релиз.
- Переименовывать таблицы ConfigCasSave и ConfigCas на PostgreSQL, таблицы пересоздаёт пустыми, но ошибка так и остаётся.
- Частично помогает добавление нового реквизита в документ, справочник и новый запуск реструктуризации, но полностью проблему не решает.

Кажется фоновое обновление всегда проклинали так же, как и динамическое обновление. Но может что-то поменялось.
1С теряет имена - просто рестарт (с очисткой кэшей) не помогает?