标签: long-running-processes

我们正在实现一个REST API,它将启动多个长时间运行的后端任务.我一直在阅读RESTful Web Services Cookbook,建议使用指向正在处理的任务的Content-Location标头返回HTTP 202/Accepted.(例如http://www.example.org/orders/tasks/1234),让客户端轮询此URI以获取有关长时间运行任务的更新.

我们的想法是让REST API立即将消息发布到队列,后台工作者角色从队列中获取消息并使用队列启动多个后端任务.我用这种方法看到的问题是如何为任务分配一个唯一的ID,然后让客户端通过向Content-Location URI发出GET来请求任务的状态.

如果REST API立即发布到队列,那么它可以生成GUID并将其作为添加到队列的消息的属性附加,但是获取请求的状态变得很尴尬.

另一个选择是让REST API立即向数据库添加一个条目(假设一个订单,带有一个新的订单ID),具有初始状态,然后在队列中放入一条消息以启动后台任务,然后将更新该数据库记录.API将在Content-Location标头的URI中返回此新订单ID,以供客户端在检查任务状态时使用.

以某种方式首先添加数据库条目,然后将消息添加到队列似乎是向后的,但仅将请求添加到队列使得难以跟踪进度.

推荐的方法是什么？

非常感谢您的见解.

我有一个"高精度"计时器类,我需要能够启动,停止和暂停/恢复.为此,我将在互联网上找到的几个不同的例子捆绑在一起,但我不确定我是否正在使用asnyc/await正确的任务.

这是我的相关代码:

//based on http://haukcode.wordpress.com/2013/01/29/high-precision-timer-in-netc/
public class HighPrecisionTimer : IDisposable
{
    Task _task;
    CancellationTokenSource _cancelSource;

    //based on http://blogs.msdn.com/b/pfxteam/archive/2013/01/13/cooperatively-pausing-async-methods.aspx
    PauseTokenSource _pauseSource;

    Stopwatch _watch;
    Stopwatch Watch { get { return _watch ?? (_watch = Stopwatch.StartNew()); } }

    public bool IsPaused
    {
        get { return _pauseSource != null && _pauseSource.IsPaused; }
        private set
        {
            if (value)
            {
                _pauseSource = new PauseTokenSource();
            }
            else
            {
                _pauseSource.IsPaused = false;
            }
        }
    }

    public bool IsRunning { get { return !IsPaused && _task != null && …

我需要运行一个可能需要数小时才能从Django视图完成的过程.我不需要知道状态或与之通信,但我需要该视图在启动过程后立即重定向.

我已经尝试使用subprocess.Popen内一个新的使用它threading.Thread,multiprocessing.Process.但是,父进程一直挂起,直到子进程终止.几乎完成它的唯一方法是使用fork.显然这并不好,因为它会留下一个僵尸进程,直到父终止.

这就是我在使用fork时要做的事情:

if os.fork() == 0:
    subprocess.Popen(["/usr/bin/python", script_path, "-v"])
else:
    return HttpResponseRedirect(reverse('view_to_redirect'))

那么,有没有办法从Django视图运行完全独立的进程,伤亡最小？或者我做错了什么？

我正在寻找一种方法来限制mysql服务器上查询的最大运行时间.我认为这可以通过my.cnf配置文件完成,但无法在文档中找到任何相关内容.有谁知道这可以做到吗？谢谢.

我有一个应用程序A,我希望能够在配置文件中调用用户指定的任意其他进程.

批处理脚本B是用户希望由A调用的一个这样的过程.B设置一些环境变量,显示一些消息并调用编译器C来完成一些工作.

Windows是否为任意进程提供了一种标准的方式来彻底终止？假设A在控制台中运行并接收CTRL + C. 它可以传递给B和C吗？假设A在窗口中运行并且用户试图关闭窗口,它可以取消B和C吗？

TerminateProcess是一个选项,但不是一个很好的选项.如果A在B上使用TerminateProcess,则C继续运行.如果C长时间运行,这可能会导致令人讨厌的问题,因为我们可能会启动另一个C实例来操作相同的文件,而C的第一个实例仍在秘密工作.此外,TerminateProcess不会导致干净的退出.

GenerateConsoleCtrlEvent听起来不错,并且可以在控制台中运行所有内容时工作,但文档说您只能将CTRL + C发送到您自己的控制台,因此如果A在窗口中运行则无济于事.

在Windows上是否有任何等效的SIGINT？我很想找到像这样的文章:http://www.cons.org/cracauer/sigint.html for Windows.

在不需要数据库且无需对此应用程序之外的任何内容进行 IO 的应用程序中，在 Azure 应用服务和 .NET Core 3.1 中长时间运行计算的合适解决方案是什么？这是一个计算任务。

具体来说，以下是不可靠的，需要一个解决方案。

[Route("service")]
[HttpPost]
public Outbound Post(Inbound inbound)
{
    Debug.Assert(inbound.Message.Equals("Hello server."));
    Outbound outbound = new Outbound();
    long Billion = 1000000000;
    for (long i = 0; i < 33 * Billion; i++) // 230 seconds
        ;
    outbound.Message = String.Format("The server processed inbound object.");
    return outbound;
}

这有时会返回一个空对象HttpClient（未显示）。较小的工作量总是会成功。例如，30 亿次迭代总是成功的。一个更大的数字会很好，特别是 2400 亿是一个要求。

我认为在 2020 年，带有 .NET Core 的 Azure 应用服务的一个合理目标可能是在 8 个子线程的帮助下将父线程数提高到 2400 亿，因此每个子线程数达到 300 亿，父线程划分 8 M 字节入站对象转换为入站到每个子项的较小对象。每个子进程收到一个 1 M …

我有一个asp.net(mvc)网站.作为函数的一部分,我将不得不支持一些长时间运行的操作,例如:

从用户启动:用户可以将(xml)文件上传到服务器.在服务器上我需要提取文件,做一些操作(插入数据库)等...这可能需要一分钟到十分钟(甚至更多 - 取决于文件大小).当然我不希望在导入运行时阻止请求,但我想将用户重定向到某个进度页面,在那里他将有机会观察状态,错误甚至取消导入.

此操作不会经常使用,但可能会发生两个用户同时尝试导入数据的情况.并行运行导入会很不错.一开始我想在iis中创建一个新线程(控制器动作)并在新线程中运行导入.但我不确定这是不是一个好主意(在Web服务器上创建工作线程).我应该使用Windows服务还是其他任何方法？

从系统启动: - 我将不得不定期使用新数据更新lucene索引. - 我将不得不发送大量电子邮件(将来).

我应该将其作为网站中的工作实现并通过Quartz.net运行工作,还是应该创建Windows服务？

在运行网站"工作"时,最佳做法是什么？

谢谢!

我有一个javascript需要大约2秒钟来执行(复杂的优化算法).我想在函数的开头将某个范围设置为"working ...".我发现直到函数结束时,跨度才会改变.

如何强制DOM更改传播？或者我应该一起解决这个问题？

我通过onclick按钮调用该功能.

功能如下:

function optimize() {
    $('#status').text('working...');
    // calculate for 2 seconds
    $('#status').text('done!');
}

我有一个需要从数据库中选择作业并需要处理它的Windows服务.

在这里,每项工作都是一个扫描过程,大约需要10分钟才能完成.

我是任务并行库的新手.我已经按以下方式实现了示例逻辑:

Queue queue = new Queue();

for (int i = 0; i < 10000; i++)
{
    queue.Enqueue(i);
}

for (int i = 0; i < 100; i++)
{
    Task.Factory.StartNew((Object data ) =>
    {
        var Objdata = (Queue)data;
        Console.WriteLine(Objdata.Dequeue());
        Console.WriteLine(
            "The current thread is " + Thread.CurrentThread.ManagedThreadId);
    }, queue, TaskCreationOptions.LongRunning);
}

Console.ReadLine();

但是,这创造了很多线程.由于循环重复100次,因此创建了100个线程.

创建那么多并行线程是正确的方法吗？

有没有办法将线程数限制为10(并发级别)？

我有一个 Google Cloud PubSub 主题，它有时会收到数千条消息，有时会收到零条消息。这些消息代表的任务每个可能需要一个小时以上。我最好能够为此使用 Cloud Run，因为它可以很好地满足需求，如果发布了 1000 条消息，我希望有 100 个 Cloud Run 实例启动。这些 Run 实例通过推送订阅启动。问题是 PubSub 有 600 秒的确认超时。这意味着为了让 Cloud Run 处理这些消息，它们必须在 600 秒内完成。如果没有，PubSub 超时，然后再次发送，导致任务重新启动，直到第一个任务最终确认它（这会导致同一个任务多次运行）。Cloud Run 通过返回 2** HTTP 状态代码来确认消息。该文件指出

当 Cloud Run 上运行的应用完成处理请求时，容器实例对 CPU 的访问将被禁用或受到严重限制。因此，您不应启动在请求处理程序范围之外运行的后台线程或例程。

那么是否有可能通过代码确认 PubSub 请求并继续处理，而无需 Google Cloud Run 移交资源？还是有我不知道的更好的解决方案？

因为这些过程是代码/资源密集型的，所以我觉得 Cloud Functions 是不够的。我看过https://cloud.google.com/solutions/using-cloud-pub-sub-long-running-tasks和https://cloud.google.com/blog/products/gcp/how-google -cloud-pubsub-supports-long-running-workloads。但这些都没有回答我的问题。我看过谷歌云任务，这可能是什么？但是项目的其余部分是围绕 PubSub/Run/Functions 构建的，所以我最好坚持下去。

这个项目是用 Python 编写的。所以最好我想像这样编写我的 Google Cloud Run 任务：

@app.route('/', methods=['POST'])
def index():
    """Endpoint for Google Cloud PubSub messages"""
    pubsub_message = request.get_json()
    logger.info(f'Received PubSub pubsub_message {pubsub_message}')
    if …