为什么我不被允许使用 Tibco Rendezvous 确认消息？
我有一个设置，其中一些应用程序通过 Tibco rendezvous 相互通信。应用程序使用经过认证的消息进行通信。我的问题是，我的两个接收者最近开始表现出这样的行为：当他们想要确认消息时，他们会收到错误 27，不允许（经过认证的消息交换中的第一条消息未经认证，我们已经考虑到了）那）。
我一直在互联网上查找有相同错误的人，我发现了很多人，但他们在尝试创建 tibco 传输时都遇到了错误。我可以很好地创建传输，但无法确认通过它收到的任何消息。
我们的环境同时使用 tibco 7.X 和 8.X，有时会混合使用。当对等方使用相同的 tibco 版本和使用不同版本时，都会出现此问题。它不会出现在所有应用程序中，但当它出现在某个应用程序中时，它仍然是“损坏的”。丢弃发送者和接收者的账本文件没有任何作用。我们仍然收到错误。发送者和接收者都具有写入（和创建）账本文件的适当权限。我们正在连接到永久运行的 rvd。发送者和接收者位于不同的机器上。过去，沟通一直完美无瑕，但在某些时候，它不再那么有效了。该应用程序是用 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) ....
我知道你会问我“你做了什么才让它开始发生”，而我的回答是“我不知道”。
任何意见将不胜感激。
谢谢。
I have a setup in which some applications communicate with each other via Tibco rendezvous. The applications communicate using certified messaging. My problem is that two of my receivers have recently started exhibiting the behavior that they will get an Error 27, Not Permitted when they want to confirm a message (the first message in a certified message exchange isn't certified, we've accounted for that).
I've been looking around the internet to find people with the same error, and I have found many, but they all get the error when trying to create the tibco transport. I can create the transport just fine, but I can't confirm any messages received over it.
Our environment uses both tibco 7.X and 8.X, some times intermingled. This problem appears both when the peers use the same tibco version and when they use different versions. It doesn't show up for all applications, but when it does show up for an application, it remains "broken". Discarding the ledger files for both sender and receiver does nothing. We still get the error. Both sender and receiver have proper permissions to write to (and create the) ledger files. We are connecting to permanently running rvds. The sender and receiver are on different machines. Communication has worked flawlessly in the past, but at some point, it stopped doing so. The application is in java, and we're using the tibrvj.jar auto-native libraries.
The error is
... 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) ....
I know you're going to ask me "what did you do to make it start happening", and my response is "I don't know".
Any input would be appreciated.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
两个 RVD 服务器之间的 TCP 连接可能无法实现。您能否检查一下是否可以从一个主机连接到另一个主机（从订阅者主机连接回发布者主机）？根据我的经验，CM 确认是通过 TCP 处理的（请对此持保留态度，因为我更像是最终用户而不是中间件支持人员）。
It may be possible that TCP connections between the two RVD servers is not possible. Can you check if you can connect from one to the other (connect from the subscriber host back to the publisher)? In my experience, CM acknowledgments are handled over TCP (please take this with a grain of salt as I'm more an end user than a Middleware support guy).
事实证明，这是应用程序级别的一个错误。
由于存在一些旧代码，在更新依赖项（我们的消息传递层）后，我们已从应用程序级别确认转移到容器级别确认，但我们忘记删除应用程序代码中的显式消息确认。
总结一下：我们尝试两次确认该消息，第二次它抛出了此异常。
As it turns out, it was a screw-up on the application level.
Due to some old code lying around, after having updated a dependency (our messaging layer), we had moved from an application level confirmation to a container level confirmation, but we had forgotten to remove an explicit message confirmation in the application code.
To summarize: We tried to confirm the message twice, and the second time it threw this exception.
我最近遇到了同样的异常 - 应用程序已经工作了几个月，突然抛出异常。就我而言，已在运行应用程序的 Windows 服务器上进行了一些维护，并且目录已标记为只读。一旦清除，异常就消失了。
经过数小时的故障排除后发现了这一点，还有其他潜在原因。
I recently encountered the same exception - application had been working for months, suddenly was throwing exception. In my case some maintenance had been done on the Windows server the application ran on and directories had been marked read-only. Once that was cleared the exception went away.
Discovered this after trouble-shooting hours worth of other potential causes.
只是我的两分钱：当您尝试在非 CM 传输上显式确认消息时，也会发生此异常。
Just my two cents: This exception also occurs when you try to explicitly confirm message on non-CM transport.