有什么理由不允许我使用Tibco Rendezvous确认消息？

Question

我有一个设置，其中一些应用程序通过Tibco rendezvous相互通信。应用程序使用认证消息进行通信我的问题是我的两个接收器最近开始表现出他们将要获得错误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

两个RVD服务器之间的TCP连接可能无法实现。您可以检查是否可以从一个连接到另一个（从订户主机连接到发布者）？根据我的经验，CM确认是通过TCP处理的（因为我更像是最终用户而不是中间件支持人员，所以请谨慎对待）。

Answer 2

事实证明，这是应用程序级别的搞砸。 由于存在一些旧代码，在更新了依赖项（我们的消息传递层）之后，我们已经从应用程序级别确认转移到容器级别确认，但我们忘记在应用程序代码中删除显式消息确认。

总结：我们尝试两次确认消息，第二次抛出此异常。

Answer 3

我最近遇到了同样的异常 - 应用程序已经工作了几个月，突然被抛出异常。在我的情况下，在运行应用程序的Windows服务器上进行了一些维护，并且目录已标记为只读。一旦清除，异常就消失了。

在经历了其他潜在原因的麻烦时间之后发现了这一点。

Answer 4

只需我的两分钱：当您尝试在非CM传输上明确确认消息时，也会发生此异常。