我有一个 Windows服务,使用生产者/消费者队列模型与多个工作线程处理队列中的任务.这些任务可以很长时间运行,如果不是几个小时,按照很多分钟的顺序,不要涉及循环.

我的问题是处理服务停止以优雅地结束对这些工作线程的处理的最佳方式.我已经读过另一个SO question,使用thread.Abort()是坏的设计的标志,但似乎服务OnStop()方法只有在服务终止之前完成有限的时间.我可以在ThreadAbortException的catch中进行足够的清理(没有不一致状态的危险),所以调用thread.Abort()在工作线程上似乎对我来说很好.是吗？什么是替代品？

的确,应该避免中止.最好给他们一些时间优雅地退出 – 也许在超时后可能会考虑中止他们 – 但最终,服务停止可以通过杀死进程来做到这一点.

我会尝试在我的队列中发出一个“冲洗和退出”的信号 – 很像“关闭”方法here,但是在完成时有一些信号.

如果你诉诸中止 – 认为这个过程是致命的.尽快杀死它

我们使用NServiceBus.Host.exe主机进程运行基于NServiceBus的服务.

在过去几个月中,Windows服务突然停止了两次生产,在应用程序事件日志中留下了以下事件：

Application: NServiceBus.Host.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: system.invalidOperationException
Stack:
at System.Transactions.TransactionState.ChangeStatePromotedPhase0(System.Transactions.InternalTransaction)
at System.Transactions.Phase0VolatileDemultiplexer.InternalPrepare()
at System.Transactions.VolatileDemultiplexer.PoolablePrepare(System.Object)
at System.Transactions.Oletx.OletxVolatileEnlistment.Prepare(System.Transactions.Oletx.OletxVolatileEnlistmentContainer)
at System.Transactions.Oletx.OletxPhase0VolatileEnlistmentContainer.Phase0Request(Boolean)
at System.Transactions.Oletx.OletxTransactionManager.ShimNotificationCallback(System.Object,Boolean)
at System.Threading._ThreadPoolWaitOrTimerCallback.PerformWaitOrTimerCallback(System.Object,Boolean)

我们在网络不稳定几分钟的时间段内遇到此错误(例如,针对数据库的大量超时,这些在我们的log4net日志文件中可见)

关于什么在这里失败的任何想法？

我们在log4net日志文件中看不到任何致命错误.

版本：

> Windows Server 2008 R2
> .NET Framework 4.5.2
> NServiceBus 4.7.5
> NHibernate 3.3.3.4001(用于传奇,订阅和超时持久性)
> sql Server 2012

看来你看到的行为与NHibernate如何处理 TransactionCompleted事件有关.这个问题也是某种方式 related to this question.

AdoNetWithdistributedTransactionFactory在TransactionCompleted事件上注册匿名委托.使用ThreadPool.QueueUserWorkItem在后台线程上触发此事件.如果该操作因数据库服务器的连接问题而引发异常(i.ex.由于网络分区),则此异常将作为AppDomain上的未观察异常引发. UnhandledExceptions会拆除AppDomain,因此也会拆除NServiceBus.Host.

最好的解决方法是在当前AppDomain上注册UnhandledException处理程序,如下所示

AppDomain.CurrentDomain.UnhandledException += OnUnhandledException

private static void OnUnhandledException(object sender,UnhandledExceptionEventArgs e)
{
    LogManager.GetLogger(typeof(AppDomain)).Fatal(“Unhandled exception”,e.ExceptionObject as Exception);
}

更多信息see

当这解决了中间问题时,找到与NHibernate结合的数据库服务器连接问题的根本原因是有意义的

我正在使用 Windows服务.工作正常当我尝试从services.msc停止服务时,会引发以下错误：

Windows Could not stop the xxx service on Local Computer.
The service did not return an error. This Could be an internal Windows error or an internal service error.
If the problem persists,contact your system administrator.

如果我再次尝试停止它,它需要很多时间,然后抛出错误如下：

Windows Could not stop the xxx service on Local Computer.
Error 1061: The service cannot accept control messages at this time.

此时,服务已停止.但是如果我尝试重新安装该服务,它会引发另一个错误：

Windows Could not stop the xxx service on Local Computer.
Error 1001: The specified service is marked for deletion.

在关闭services.msc之后,它可以让我重新安装服务,再次,事情开始工作正常.

在OnStop()中,我做了一些冗长的操作,需要时间才能完成.

有什么想法可以让整个事情顺利进行吗？

– 编辑 –

这是我的OnStop方法的样子：

protected override void OnStop()
{
    base.OnStop();
    //Some lengthy operation      
}

Windows服务在onstart和onstop事件中具有默认超时.通常,如果您在任何这些事件中执行耗时的操作,则会启动一个新线程,并让操作在后台执行.

通常,Windows服务中的OnStart以及OnStop事件用于启动进程,耗时的进程将执行它在子线程中的执行.

希望这将解决您的问题..

假设您有一个多线程 Windows服务,它执行许多不同的操作,这需要花费相当多的时间,例如从不同的数据存储中提取数据,解析所述数据,将其发布到外部服务器等.可以在不同的层中执行操作,例如,应用程序层,存储库层或服务层.

在此Windows服务的生命周期中的某个时刻,您可能希望通过services.msc关闭它或重新启动它,但是如果您无法在服务的时间跨度内停止所有操作并终止Windows服务中的所有线程. msc期望用stop程序完成,它会挂起,你必须从任务管理器中删除它.

由于上面提到的问题,我的问题如下：如何实现处理Windows服务关闭的故障安全方法？我有一个挥发性布尔值作为关闭信号,由我的服务基类中的OnStop()启用,并且应该优雅地停止我的主循环,但如果在某个其他层中有一个操作,这是不值得的是时候做任何操作了.

应如何处理？我目前处于亏损状态,需要一些创造性的投入.

我将使用CancellationTokenSource并将取消令牌从OnStop方法传播到所有层,并在那里启动所有线程和任务.它在框架中,所以如果你关心它,它不会破坏你的松散耦合(我的意思是,无论你在哪里使用线程/任务,你也有’CancellationToken’可用.

这意味着您需要调整异步方法以考虑取消令牌.

您还应该知道ServiceBase.RequestAdditionalTime.如果无法在适当的时候取消所有任务,您可以申请延长期.

或者,也许您可​​以探索IsBackground替代方案.当进程即将退出时,CLR会停止Windows服务中启用了此功能的所有线程：

A thread is either a background thread or a foreground thread. Background threads are identical to foreground threads,except that background threads do not prevent a process from terminating. Once all foreground threads belonging to a process have terminated,the common language runtime ends the process. Any remaining background threads are stopped and do not complete.