错误后恢复资源
我目前正在构建一个应用程序，该应用程序通过基本的 Web 服务接收数千条小消息，这些消息被发布到消息队列 (RabbitMQ)。该应用程序使用 StructureMap 作为其容器来利用依赖注入。
我有一个单独的工作应用程序，它使用消息队列并将消息保存到数据库（SQL Server）。
我已将 SQL 连接和 RabbitMQ 连接实现为单例（线程本地）。
在理想的情况下，这一切都工作正常，但如果 SQL Server 或 RabbitMQ 连接中断，我需要重新打开它，或者可能处置并重新创建/重新连接资源。
我编写了一个基本类来充当工厂，在返回资源之前，检查它是否已连接/打开/工作，如果没有，则处理它并重新创建它 - 我不确定这是否是“最佳实践”或者我是否正在尝试解决一个已经解决的问题。
任何人都可以提供关于如何实现长时间运行的任务的建议，这些任务执行许多小任务（在我的例子中是单个 INSERT 语句），不需要每个任务的对象实例化，但可以从错误（例如丢失的连接）中正常恢复？
RabbitMQ 连接似乎很昂贵，并且在高工作负载期间我可以很快用完句柄，因此我想重用相同的连接（每个线程）。
I'm currently in the process of building an application that receives thousands of small messages through a basic web service, the messages are published to a message queue (RabbitMQ). The application makes use of Dependancy Injection using StructureMap as its container.
I have a separate worker application that consumes the message queue and persists the messages to a database (SQL Server).
I have implemented the SQL Connection and RabbitMQ connections as singletons (Thread Local).
In an ideal world, this all works fine but if SQL Server or RabbitMQ connection is broken I need to reopen it, or potentially dispose and recreate/reconnect the resources.
I wrote a basic class to act as a factory that before it returns a resource, checks it is connected/open/working and if not, dispose it and recreate it - I'm not sure if this is "best practice" or if I'm trying to solve a problem that has already been solved.
Can anyone offer suggestions on how I could implement long running tasks that do a lot of small tasks (in my case a single INSERT statement) that don't require object instantiation for each task, but can gracefully recover from errors such as dropped connections?
RabbitMQ connections seem to be expensive and during high work loads I can quickly run out of handles so I'd like to reuse the same connection (per thread).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
适用于 Windows Azure 的企业库 5.0 集成包 包含暂时性故障块处理。它允许您指定出现错误时的重试行为。
它在设计时就考虑到了 Windows Azure，但我相信根据它提供的功能编写自定义策略会很容易。
The Enterprise Library 5.0 Integration Pack for Windows Azure contains a block for transient fault handling. It allows you to specify retry behavior in case of errors.
It was designed with Windows Azure in mind but I'm sure it would be easy to write a custom policy based on what it offers you.
您可以为具有连接池的 RabbitMQ 创建一个连接工厂。它将负责分配任务的连接。您应该检查连接是否正常。如果没有，则启动一个新线程来关闭/清理连接，然后将其返回到线程池。同时向用户返回一个正常运行的连接。
这听起来很复杂，但它是处理难以初始化的资源的模式。
You can make a connection factory for RabbitMQ that has a connection pool. It would be responsible for handing out connections to tasks. You should check to see that the connections are ok. If not, start a new thread that closes/cleans the connection then returns it to the thread pool. Meanwhile return a functioning connection to the user.
It sounds complicated but it's the pattern for working with hard to initialize resources.