Любая причина, почему мне не разрешат подтвердить сообщение, используя Tibco Rendezvous?

Question

У меня есть настройка, в которой некоторые приложения взаимодействуют друг с другом через Tibco. Приложения общаются с использованием сертифицированных сообщений. Моя проблема в том, что два из моих получателей недавно начали демонстрировать поведение, что они получат ошибку 27, не разрешено, когда они хотят подтвердить сообщение (первое сообщение в сертифицированном обмене сообщениями не сертифицировано, мы учли что).

Я искал в интернете, чтобы найти людей с такой же ошибкой, и я нашел много, но все они получают ошибку при попытке создать транспорт Tibco. Я могу просто создать транспорт, но не могу подтвердить ни одно сообщение, полученное через него.

В нашей среде используются оба tibco 7.X и 8.X, иногда смешанные. Эта проблема возникает, когда одноранговые узлы используют одну и ту же версию Tibco и когда они используют разные версии. Он не отображается для всех приложений, но когда он появляется для приложения, он остается «сломанным». Сброс файлов регистра для отправителя и получателя ничего не дает. Мы все еще получаем ошибку. И отправитель, и получатель имеют надлежащие разрешения для записи (и создания) файлов бухгалтерской книги. Мы подключаемся к постоянно работающим rvds. Отправитель и получатель находятся на разных машинах. Связь работала безупречно в прошлом, но в какой-то момент перестала это делать. Приложение находится на Java, и мы используем автоматически встроенные библиотеки tibrvj.jar.

Ошибка

...
Caused by: TibrvException[error=27,message=Not permitted]
  at com.tibco.tibrv.TibrvImplCmTPortC.natConfirmMsg(Native Method)
  at com.tibco.tibrv.TibrvImplCmTPortC.confirmMsg(TibrvImplCmTPortC.java:304)
  at com.tibco.tibrv.TibrvCmListener.confirmMsg(TibrvCmListener.java:88)
....

Я знаю, что вы спросите меня "что вы сделали, чтобы это начало происходить", и мой ответ - "Я не знаю".

Любой вклад будет оценен.

Спасибо.

Answer 1

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

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

Answer 2

Недавно я столкнулся с тем же исключением - приложение работало месяцами, внезапно выдавало исключение. В моем случае некоторое обслуживание было выполнено на сервере Windows, на котором запущено приложение, и каталоги были помечены как доступные только для чтения. Как только это было очищено, исключение ушло.

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

Answer 3

Возможно, что TCP-соединения между двумя серверами RVD невозможны. Можете ли вы проверить, можете ли вы подключиться от одного к другому (подключиться с хоста подписчика обратно к издателю)? По моему опыту, подтверждения CM обрабатываются по протоколу TCP (пожалуйста, примите это с большой долей вероятности, так как я больше конечный пользователь, чем специалист по поддержке Middleware).

Answer 4

Только мои два цента: Это исключение также возникает, когда вы пытаетесь явно подтвердить сообщение на транспорте без CM.