问题标签 [tibco-rv]

我们使用适用于 Unix 和 windows 的 Tibco RVRD 作为消息传递系统。只是想知道，除了从 Tibco 购买 HAWK 之外，还有什么方法可以测量 RVRD 压缩前后的网络使用情况吗？

几年前，我在一个项目中使用了 TIBCO Rendezvous Cache (rvcache) 和 TIBCO 消息传递框架。它将缓存主题/主题，然后在请求时发送缓存。我目前正在进行的项目正在寻求再次将 TIBCO 用作消息传递系统。我试图解释我多年前使用的 rvcache，但现在我找不到太多关于它的信息。我很好奇是否有人知道它是否仍在使用，或者是否被替换为具有不同名称的新东西。

嗨，我是 Tibco RV 的新手。在阅读了 Tibco Rendezvous Concept 之后，我仍然对传输参数感到困惑：服务、网络、守护进程。

所以从概念上讲，每台机器上只运行一个守护进程。所以在使用 tibrvsend 时：

这是否意味着我正在使用本地主机上的端口 2323 通过守护程序myDaemon（可能在远程）向网络发送消息comeIPAddress？

使用 tibrvlisten 时：

这是否意味着我正在使用任何可用端口、本地主机上的任何可用守护程序来监听来自myDaemon“发布到someIPAddress网络”的端口 2323 的消息？

另一个问题是，《Tibco RV Concept》一书中提到，同一个服务不能绑定到两个网络。它是否仅适用于生产者机器（因为我们没有为侦听器机器指定端口）？所以如果我们这样做会发生错误：

和

同时（连续做应该没问题吧？）

但对于听众：

和

应该没问题？（否则意味着生产者需要知道彼此的端口号以避免冲突）

如果我完全搞砸了这些概念，你能用例子解释一下吗？

我有 2 个 Java 应用程序实例（A 和 B）在同一台机器上运行，其中 B 被阻止activate()回调。

这就是我注册回调的方式：

我每 100 毫秒发送一次心跳，以确保我的应用程序准时。

出于某种原因（例如，GC / 垃圾收集），如果我的活动应用程序“A”延迟发送心跳，我的被动应用程序“B”立即被激活，而“A”仍然处于活动状态，其中“A”上没有调用 deactivate . 在应用程序“A”发送心跳后不久，在应用程序“B”上调用 deactivate。由于两个应用程序同时处于活动状态，这会在几秒钟内产生错误行为。

提到的是随机时间发生的，不可预测。我们的应用程序不能同时发布重复的消息，所以这会产生巨大的影响。

请帮助我解决这个问题。

你们知道一个图表或dable，它可以给出一个简短而简洁但仍然完整且相对最新的现有协议及其细节的视图？（即：ZeroMQ、Rendez-Vous、EMS、...所有这些！:)）。

我已经为 TibcoRV 和账本文件启用了认证消息传递，该文件不断增长导致我的应用程序最终死机。

通过完全控制该框（访问 TibRV Web 界面、分类帐文件本身），是否可以确定哪个 CMName 使用连接到我们的应用程序的客户端未确认消息（即我们正在等待来自的 ACK）？

谢谢

我有一个奇怪的问题，让我们从一段代码开始：

如您所见，我创建了一个 Tibco 侦听器对象，将其订阅到某个远程守护程序，然后将引用移动到我创建的下一个 Tibco 侦听器对象。

我希望垃圾收集器收集除最后一个之外的所有侦听器对象，因为 _listener 引用它。但是，运行结果表明所有侦听器对象都在工作。

所以为什么？仅仅是因为我没有运行我的应用程序足够长的时间，以至于 GC 没有时间收集侦听器对象，还是有一些固有的东西在引用“应该孤立”的侦听器对象？

请赐教！谢谢。

我想知道这里的社区是否知道一种通过类似于 TibcoRV 的“tibrvlisten”的命令行在 ActiveMQ 代理上收听主题的方法

谢谢

我正在 Visual Studio 2010 中开发一个自定义包。这个包可以连接到 oracle DB（读取、写入一些数据）。对于此功能，我需要参考安装的 Oracle.Data.Access.dll（64 位）和 Oracle 客户端。我在C:\oracle\odp.net\bin\4\文件夹下找到它。当我开发控制台应用程序时，一切正常。但是当我尝试在包生成器中验证并保存我的扩展时，我收到了这个错误：

无法从文件 C:...\Oracle.Data.Access.dll 创建程序集。该文件不是有效的 .NET 程序集。

JMS 或消息传递非常适合捆绑不同的应用程序并形成许多 ESB 和 SOA 架构的基础架构。

但是，假设应用程序 A 需要立即响应应用程序 B 上的服务，例如需要订单的供应详细信息或需要立即确认某些更新。从性能的角度来看，消息传递是否是正确的解决方案？通常，客户端将连接到队列上的 MoM - 然后必须空闲的侦听器将拾取消息并转发到服务器端处理器 - 它将处理响应并将其发送回队列或主题和请求客户将遵循相同的过程并拿起它。如果消息大小很大，MoM 也必须将其考虑在内。

让我想知道 Http 是否是访问此类解决方案而不是通过消息传递路由的更好解决方案？我已经看到很多应用程序使用像 AMQ 或 TIBCO Rvd 这样的 MoM 来实际用于即时请求/响应 - 但这是糟糕的设计，还是一些微调或设置使其与 Http 相同。