4

我有一个设置，其中一些应用程序通过 Tibco 集合点相互通信。应用程序使用经过认证的消息进行通信。我的问题是我的两个接收者最近开始表现出当他们想要确认消息时会收到错误 27，不允许的行为（经过认证的消息交换中的第一条消息没有经过认证，我们已经考虑到那）。

我一直在互联网上寻找有相同错误的人，我发现了很多，但他们在尝试创建 tibco 传输时都会遇到错误。我可以很好地创建传输，但我无法确认通过它收到的任何消息。

我们的环境同时使用 tibco 7.X 和 8.X，有时混合使用。当对等方使用相同的 tibco 版本和使用不同的版本时，都会出现此问题。它不会出现在所有应用程序中，但是当它出现在应用程序中时，它仍然是“损坏的”。丢弃发送方和接收方的分类帐文件没有任何作用。我们仍然得到错误。发送者和接收者都具有写入（和创建）分类帐文件的适当权限。我们正在连接到永久运行的 rvd。发送者和接收者在不同的机器上。过去，沟通工作完美无缺，但在某些时候，它停止了。该应用程序是 java 的，我们使用的是 tibrvj.jar 自动原生库。

错误是

...
原因：TibrvException[error=27,message=Not allowed]
  在 com.tibco.tibrv.TibrvImplCmTPortC.natConfirmMsg（本机方法）
  在 com.tibco.tibrv.TibrvImplCmTPortC.confirmMsg(TibrvImplCmTPortC.java:304)
  在 com.tibco.tibrv.TibrvCmListener.confirmMsg(TibrvCmListener.java:88)
……

我知道你会问我“你做了什么让它开始发生”，我的回答是“我不知道”。

任何输入将不胜感激。

谢谢。

4

4 回答 4

1

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

于 2011-01-06T00:19:17.447 回答
1

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

总结一下：我们尝试了两次确认消息，第二次它抛出了这个异常。

于 2011-01-06T08:05:42.863 回答
1

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

在对其他潜在原因进行了数小时的故障排除后发现了这一点。

于 2011-02-14T23:05:39.557 回答
0

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

于 2013-01-30T15:56:33.287 回答