RequestAdditionalTime() 的安全开销是多少？答案

【问题标题】：What is a safe overhead for RequestAdditionalTime()?RequestAdditionalTime() 的安全开销是多少？
【发布时间】：2015-05-02 15:03:17
【问题描述】：

我有一个 Windows 服务，它在单独的线程上生成一组子活动，并且只有在所有这些活动都成功完成后才会终止。我事先不知道在收到停止信号后终止活动可能需要多长时间。在 OnStop() 期间，我会间隔等待该停止信号，并一直请求额外的时间，只要系统愿意授予它。

这是基本结构：

class MyService : ServiceBase
{
    private CancellationTokenSource stopAllActivities;
    private CountdownEvent runningActivities;

    protected override void OnStart(string[] args)
    {
        // ... start a set of activities that signal runningActivities
        //       when they stop
        // ... initialize runningActivities to the number of activities
    }

    protected override void OnStop()
    {
        stopAllActivities.Cancel();

        while (!runningActivities.Wait(10000))
        {
            RequestAdditionalTime(15000); // NOTE: 5000 added for overhead
        }
    }
}

我应该在RequestAdditionalTime 调用中添加多少“开销”？我担心请求是累积的，而不是基于每个RequestAdditionalTime 调用的时间点。如果是这种情况，增加开销可能会导致系统最终拒绝该请求，因为它在未来太远了。但是，如果我不增加任何开销，那么我的服务可能会在它有机会请求下一个额外时间块之前终止。

【问题讨论】：

标签： c# windows-services

【解决方案1】：

This post 并不完全令人鼓舞：

MSDN 文档没有提到这一点，但看起来 RequestAdditionalTime 中指定的值实际上并不是“额外”时间。相反，它会替换 ServicesPipeTimeout 中的值。更糟糕的是，任何大于两分钟（120000 毫秒）的值都会被忽略，即限制为两分钟。

我希望不是这样，但我将其发布为最坏情况的答案。

更新：该帖子的作者非常友好地对我的评论发表了非常详细的回复，我在下面复制了该回复。

拉斯，简短的回答是否定的。

我想说的是，我现在意识到应该将 Windows 服务设计为在请求时快速启动和终止处理。

作为开发人员，我们倾向于专注于处理的实现，然后将其打包并作为 Windows 服务交付。

但是，这确实不是设计 Windows 服务的正确方法。服务必须能够快速响应启动和停止请求，不仅是在管理员从服务控制台发出请求时，而且在操作系统请求启动作为其启动处理的一部分或因为它正在关闭而停止时,

考虑当 Windows 配置为在 UPS 发出电源故障信号时关闭时会发生什么。服务响应“我需要再等几分钟……”是不合适的。

即使在执行长时间运行的处理任务时，也可以编写能够快速响应以停止请求的服务。通常，一个长时间运行的进程将包含数据的批处理，并且该处理应检查是否已在确保数据一致性的最小工作单元级别请求停止。

例如，我发现停止超时的第一个服务是一个涉及远程服务器上通知队列处理的问题。该处理从队列中检索通知，调用 Web 服务以检索与通知主题相关的数据，然后写入数据文件以供另一个应用程序处理。

我将处理实现为对单个方法的计时器驱动调用。一旦调用该方法，它不会返回，直到队列中的所有通知都已处理完毕。我意识到这对于 Windows 服务来说是一个错误，因为有时队列中可能会有数以万计的通知，并且处理可能需要几分钟时间。

该方法每秒能够处理 50 条通知。所以，我应该做的是在处理每个通知之前检查是否已请求停止。这将允许该方法在完成通知处理但在开始处理下一个通知之前返回。这将确保服务快速响应停止请求，并且在服务重新启动时，任何待处理的通知都会排队等待处理。

【讨论】：