Добрый день. Есть сервер RabbitMq который получает сообщения и есть 1ска которая подсоединяется по com соединению к данном серверу. Вопрос такой выполняю соединению метод Close но по каким то причинам соединение не закрывается. Соответственно при каждом подключение плодятся соединения. Подскажите как можно насильно со стороны 1с закрыть данное соединение? Пробовал ComСоединение = неопределено не помогло.

Извиняюсь не дописал. Подключаюсьтотправляю данные на Кролика и в конце выполняю метод Close

а как определяете, что соединение не разорвалось? и какой "сом" используете? 1сный комконнектор разве умеет с чем то еще, кроме 1С-ных баз работать?

(2) < комконнектор разве умеет с чем то еще, кроме 1С-ных баз работать?>
а как по твоему он с msoffice работает?

(0) а переделать на не-com не получится?

(1) Возможно соединение не закрывается из-за живых ссылок на комобъекты?

в настройкам COM в винде поищи свойство "Повторное использование объектов".
или как то созвучно. этот механизм предназначен для экономии, чтобы ты с одним ключом запуска мог один и тот же объект использовать, а не порождать каждый раз новый с чтением из реестра\диска.

+ (5) ИЛИ научись переиспользовать КОМок.

(0) > 1ска которая подсоединяется по com соединению к данном серверу
Какая клиентская компонента используется?

Опять же,закрытие com-соединения и выход из программы - это разные вещи.
Для повторного использования нужно делать вызов GetObject,чтобы по таблице RunObjectTable искать.

С excel была такая же проблема - getobject спасало,но это делалось через MsScriptControl,которого в 64 битах нету.

(3) у тебя очевидно через коннектор, соболезную
обращайтесь к создателю кома, он не одинэсный, почему он не работает можно только догадываться. может клиент не может разорвать, может сервер не отпускает, в целом без разницы

(9) Сейчас окажется, что оно на дотнете с регистрацией через регасм и со своими тараканами по мнению о закрытию соединений и о необходимости выгрузки сборки.

Disconnecting from RabbitMQ

To disconnect, simply close the channel and the connection:

channel.close();
conn.close();

https://www.rabbitmq.com/api-guide.html#connecting

А что такое RabbitMQ если кратко? Нафига он нужен?

какой то сервер мессенджера что ли

(14) Внешний сервак, чтобы между локалками обмениваться без vpn и белых ip?

(15) не юзал, точно не скажу, есть сайт производителя. гугл человеческим языком выдал https://evilinside.ru/chto-takoe-rabbitmq-zachem-on-nuzhen-i-kak-ego-ispolzovat/#

(15) это про другое. с точки зрения сетей:
vpn и белые ip - это транспортный уровень.
кролик - это уровень приложения.

с точки зрения учетных систем:
кролик - это транспорт сообщений.

(13) Это как 1С:Шина, но хуже :)

(18) единственный вменяемый ответ ;)
а то что никто не знает что такое rabbit лишь подтверждает то что одинесники не интересуются ничем за пределами своей отрасли

(19) А Кафка у них - вообще Франц. Ну, тупые...

(19) нам ваш rabbit и наюг не нужон.

(13) (21) Вот тут более менее на пальцах рассказано зачем и почему. Еще и вариант реализации на 1с показан.
https://infostart.ru/1c/articles/1116609/

(19) грамотные специалисты подсосались. если будет нужен чатик, можно и на 1с его сделать, если уж что то сильно модное будет нужно, то на .нете. Ну а пока займемся аналитикой процессов и их автоматизацией, подобную хрень как раббит оставьте себе. Смотри как много я их теперь знаю

Amazon Web Services (AWS) Amazon MQ
Amazon Web Services (AWS) Kinesis
Apache ActiveMQ
Apache Artemis
Apache Kafka
Apache Qpid
Apache Pulsar
Cloverleaf (Enovation Lifeline - NL)
Comverse Message Broker (Comverse Technology)
Eclipse Mosquitto MQTT Broker (Eclipse Foundation)
Enduro/X Transactional Message Queue (TMQ)
Financial Fusion Message Broker (Sybase)
Fuse Message Broker (enterprise ActiveMQ)

(22) почитал, спасибо за ссылку. Укрепился в (21)

(24) Там херня написана. Да и продуктов аналогичных много. У нас стоит Kafka с подсистемой от сильвербуллет - вполне себе неплохо после доработки напильником.

(25) а в чем именно "херня" заключается? Имхо на обывательском уровне написан пример интеграции в одной из компаний и почему выбран тот или иной продукт.

(25) а расскажите, как используете и почему не веб-сервисы от 1с, к примеру?

(27) Ну потому что удобнее чем через вебсервисы.
Сообщение создали, отправили в топик (назовем его узел) в кафку и забыли.
На другой стороне периодическое задание, которое читает из топиков сообщения.
В принципе и все.

(27) потому что это аналог почты с очередями писем, рассылками и подтверждением доствки, а вебсервисы это телефонные линии

(28) (29) Ну вот этого RabbitMQ проще и надежнее создать на регистрах сведений, о которых говорил автор на инфостаре, только без тормозов и архивов.

пока клиент 1, то проще без очереди. ибо выгружать в очередь или напрямую в клиента разницы нет.
А вот когда приемников более 1... Но хотя такое очень редко бывает, что несколько приемников, но данные одинаковые

(30) Теперь умножь это число например на 150. В случае с кафкой мы создаем 1 подключение к кластеру кафки и отправляем на все 150 точек. Соответственно и получаем так же.

(30) ну создал, а теперь залей туда полтора миллиона сообщений и начни оттуда читать тридцатью разными сервисами ...и чтобы эта вся конструкция не тормозила процесс

а потом еще в процессе надо чтобы кластер пару раз упал ...а сообщеньки терять нельзя, также как обрабатывать два раза

(33) Легко

(33) (34) Вы развращены стереотипами о тормозящей 1С, конфигурацию которой спроектировали ебаклаки, которые "легко вошли в профессию", не более.

(36) в целом поддержу
этот механизм можно назвать файловым обменом каким то, принцип такой же - один положил,другой прочитал. и кажется тут могут быть вопросы с успешным забором данных, если чтец споткнулся где то, то нужен еще механизм, который как то донесет это до писателя, взаимодействие крайних точек, это осложняется прокладкой, называемой брокером сообщений. при "интерактивной" схеме через сервисы или даже ком таких проблем нет, правда есть другие, хотя именно у сервисов и других нет.
и потом, в той же 1с есть планы обмена с узлами и все теми же номерами сообщений, где то это видел, в каком то кролике кажется. + никто не мешает 150 точкам обращаться за данными самим к источнику. и если не воротить там мега логику, то все отработает нормально - 150 клиентов для сервера не проблема, 500 тоже, хоть даже это и будет дополнительно к текущим пользователям

(37) Не. Тут еще другая фишка есть.
Например создается топик НСИ и в это топик наполняется из основной базы. А читать его могут все получатели. И все получатели будут иметь актуальный НСИ.

(36) мне кажется ты недооцениваешь нагрузки в некоторых сервисах, я вот чёт слабо себе представляю 1С в качестве брокера сообщений
сколько потоков потянет? 20 очередей по 400-1000 сообщений в секунду на чтение/запись в каждом и чтобы провисаний не было?

(39) да ничего не потянет, в том то и дело
Кролик промышленный сервер очередей, 1с инф система, чего огород городить

(40) > да ничего не потянет
Мякотка, она как всегда, в деталях.

Когда инфраструктура состоит только из 1С, затык в производительности будет не на стороне брокера, а на стороне клиентов. Ну не смогут они генерировать и обрабатывать такой поток, не смогут. Потому как "инф система, чего огород городить". И в этом случае миниброкер на 1С вполне вписывается. А если еще и учесть, что маршрутизация и преобразование данных в такой инфраструктуре очень сильно зависит от прикладных сущностей 1С, то реализация обменов на 1С - вполне нормальный вариант.

И только когда в инфраструктуре появляется кто-то сторонний с бешенной производительностью, которому нужны такие потоки, тогда да, шина на 1С не при делах.

Но почувствовать себя большим и высказать покровительственное "фи" в сторону 1С очень хочется, да.

Во-первых,система очереди сообщений - это распределенная система передачи данных,конечно,можно ее поставить на одну машину и радоваться,но тогда она ничем от 1с отличаться не будет.
Суть очереди сообщений в гарантированной доставке и соблюдению порядка сообщений.
Понятно,что гарантированная доставка - это некоторая условность,но,пока узел жив,он будет доставлять сообщения.
Для использующего софта это означает,что передав сообщение и получив подтверждение от узла можно не думать о доставке.
Соблюдение порядка означает,что отправив одно сообщение за другим мы на принтмающей стороне получим именно такой порядок.

Может ли 1с быть брокером сообщений - может - но для этого,во-первых,нужно поставить на каждую иашину,с которой идет обмен сообщениями,а также добиться того,чтобы эти узлы работали независимо,а для этого,ставить сервер 1с на каждую машину и публиковать его,то есть ставить web-сервер - а не многовато ли?
Опять же,для работы с сообщениями,нужно хранилище и api для доступа из-вне.
Как бы,sql-сервер тут,скорее,как пятая нога собаки.

На самом деле,один из примеров системы сообщений - это простая электронная почта,но в ней нет гарантии доставки и порядка сообщений.
Однако,чаще всего,работа с почтой ограничивается отправкой письма - мы не можем узнать его судьбу после отправки.