C# 的 TIBCO EMS 故障转移重新连接 (TIBCO.EMS.dll)

TIBCO EMS Failover reconnect for C# (TIBCO.EMS.dll)

提问by ScottCher

We have a TIBCO EMS solution that uses built-in server failover in a 2-4 server environment. If the TIBCO admins fail-over services from one EMS server to another, connections are supposed to be transfered to the new server automatically at the EMS service level. For our C# applications using the EMS service, this is not happening - our user connections are not being transfered to the new server after failover and we're not sure why.

我们有一个 TIBCO EMS 解决方案，它在 2-4 个服务器环境中使用内置服务器故障转移。如果 TIBCO 管理从一台 EMS 服务器到另一台的故障转移服务，则连接应该在 EMS 服务级别自动转移到新服务器。对于我们使用 EMS 服务的 C# 应用程序，这不会发生 - 我们的用户连接在故障转移后没有转移到新服务器，我们不确定为什么。

Our application connection to EMS at startup only so if the TIBCO admins failover after users have started our application, they users need to restart the app in order to reconnect to the new server (our EMS connection uses a server string including all 4 production EMS servers - if the first attempt fails, it moves to the next server in the string and tries again).

我们的应用程序仅在启动时连接到 EMS，因此如果 TIBCO 管理员在用户启动我们的应用程序后进行故障转移，他们的用户需要重新启动应用程序才能重新连接到新服务器（我们的 EMS 连接使用的服务器字符串包括所有 4 个生产 EMS 服务器- 如果第一次尝试失败，它将移动到字符串中的下一个服务器并再次尝试）。

I'm looking for an automated approach that will attempt to reconnect to EMS periodically if it detects that the connection is dead but I'm not sure how best to do that.

我正在寻找一种自动化方法，如果它检测到连接已断开，它将尝试定期重新连接到 EMS，但我不确定如何最好地做到这一点。

Any ideas? We are using TIBCO.EMS.dll version 4.4.2 and .Net 2.x (SmartClient app)

有任何想法吗？我们使用的是 TIBCO.EMS.dll 版本 4.4.2 和 .Net 2.x（SmartClient 应用程序）

Any help would be appreciated.

任何帮助，将不胜感激。

采纳答案by Anthony Mastrean

This post should sum up my current comments and explain my approach in more detail...

这篇文章应该总结我目前的评论并更详细地解释我的方法......

The TIBCO 'ConnectionFactory' and 'Connection' types are heavyweight, thread-safe types. TIBCO suggests that you maintain the use of oneConnectionFactory (per server configured factory) and oneConnection per factory.

TIBCO 'ConnectionFactory' 和 'Connection' 类型是重量级的线程安全类型。TIBCO 建议您保持使用一个ConnectionFactory（每个服务器配置的工厂）和每个工厂一个Connection。

The server also appearsto be responsible for in-place 'Connection' failover and re-connection, so let's confirm it's doing its job and then lean on that feature.

服务器似乎还负责就地“连接”故障转移和重新连接，所以让我们确认它正在完成它的工作，然后依靠该功能。

Creating a client side solution is going to be slightly more involved than fixing a server or client setup problem. All sessions you have created from a failed connection need to be re-created (not to mention producers, consumers, and destinations). There are no "reconnect" or "refresh" methods on either type. The sessions do not maintain a reference to their parent connection either.

创建客户端解决方案比修复服务器或客户端设置问题要稍微复杂一些。您从失败的连接创建的所有会话都需要重新创建（更不用说生产者、消费者和目的地）。两种类型都没有“重新连接”或“刷新”方法。会话也不维护对其父连接的引用。

You will have to manage a lookup of connection/session objects and go nuts re-initializing everyone! or implement some sort of session failure event handler that can get the new connection and reconnect them.

您将不得不管理连接/会话对象的查找并疯狂地重新初始化每个人！或者实现某种会话失败事件处理程序，可以获取新连接并重新连接它们。

So, for now, let's dig in and see if the client is setup to receive failover notification (tib ems users guide pg 292). And make sure the raised exception is caught, contains the failover URL, and is being handled properly.

所以，现在，让我们深入了解客户端是否设置为接收故障转移通知（tib ems 用户指南第 292 页）。并确保引发的异常被捕获，包含故障转移 URL，并且被正确处理。

回答by TheSoftwareJedi

Client applications may receive notification of a failover by setting the tibco.tibjms.ft.switch.exception system property

客户端应用程序可以通过设置 tibco.tibjms.ft.switch.exception 系统属性来接收故障转移通知

Perhaps the library needs that to work?

也许图书馆需要它来工作？

回答by ScottCher

First off, yes, I am answering my own question. Its important to note, however, that without ajmastrean, I would be nowhere. thank you so much!

首先，是的，我正在回答我自己的问题。然而，重要的是要注意，如果没有 ajmastrean，我将一事无成。太感谢了！

ONE: ConnectionFactory.SetReconnAttemptCount, SetReconnAttemptDelay, SetReconnAttemptTimeout should be set appropriately. I think the default values re-try too quickly (on the order of 1/2 second between retries). Our EMS servers can take a long time to failover because of network storage, etc - so 5 retries at 1/2s intervals is nowhere near long enough.

一：ConnectionFactory.SetReconnAttemptCount、SetReconnAttemptDelay、SetReconnAttemptTimeout 应适当设置。我认为默认值重试太快（重试之间的间隔为 1/2 秒）。由于网络存储等原因，我们的 EMS 服务器可能需要很长时间才能进行故障转移 - 因此以 1/2 秒的间隔重试 5 次远远不够。

TWO: I believe its important to enable the client-server and server-client heartbeats. Wasn't able to verify but without those in place, the client might not get the notification that the server is offline or switching in failover mode. This, of course, is a server side setting for EMS.

二：我认为启用客户端-服务器和服务器-客户端心跳很重要。无法验证，但如果没有这些，客户端可能无法收到服务器脱机或切换到故障转移模式的通知。当然，这是 EMS 的服务器端设置。

THREE: you can watch for failover event by setting Tibems.SetExceptionOnFTSwitch(true); and then wiring up a exception event handler. When in a single-server environment, you will see a "Connection has been terminated" message. However, if you are in a fault-tolerant multi-server environment, you will see this: "Connection has performed fault-tolerant switch to ". You don't strictly need this notification, but it can be useful (especially in testing).

三：您可以通过设置 Tibems.SetExceptionOnFTSwitch(true) 来监视故障转移事件；然后连接一个异常事件处理程序。在单服务器环境中，您将看到“连接已终止”消息。但是，如果您处于容错多服务器环境中，则会看到：“连接已执行容错切换到”。您并不严格需要此通知，但它可能很有用（尤其是在测试中）。

FOUR: Apparently not clear in the EMS documentation, connection reconnect will NOT work in a single-server environment. You need to be in a multi-server, fault tolerant environment. There is a trick, however. You can put the same server in the connection list twice - strange I know, but it works and it enables the built-in reconnect logic to work.

四：EMS文档中显然没有明确，连接重新连接在单服务器环境中不起作用。您需要处于多服务器容错环境中。然而，有一个技巧。您可以将同一台服务器放入连接列表两次 - 我知道这很奇怪，但它可以工作，并且可以使内置的重新连接逻辑工作。

some code:

一些代码：

private void initEMS()
{
    Tibems.SetExceptionOnFTSwitch(true);
    _ConnectionFactory = new TIBCO.EMS.TopicConnectionFactory(<server>);
    _ConnectionFactory.SetReconnAttemptCount(30);       // 30retries
    _ConnectionFactory.SetReconnAttemptDelay(120000);   // 2minutes
    _ConnectionFactory.SetReconnAttemptTimeout(2000);   // 2seconds
_Connection = _ConnectionFactory.CreateTopicConnectionM(<username>, <password>);
    _Connection.ExceptionHandler += new EMSExceptionHandler(_Connection_ExceptionHandler);
}
private void _Connection_ExceptionHandler(object sender, EMSExceptionEventArgs args)
{
    EMSException e = args.Exception;
    // args.Exception = "Connection has been terminated" -- single server failure
    // args.Exception = "Connection has performed fault-tolerant switch to <server url>" -- fault-tolerant multi-server
    MessageBox.Show(e.ToString());
}