标签: task-queue

我喜欢新的TaskQueue API.

我有一个关于ETA /倒计时的问题,如果我将它设置为将来执行10分钟的新任务并且它是队列中的唯一项目 - 它将在大约10分钟内执行还是会立即执行？

我正在查看Google App Engine的Java新任务队列API,我很难将其与我的GWT应用程序联系起来.如果我想使用任务队列进行一些异步处理,我该怎么做才能使用GWT.

我看到它的方式是,我必须发送一个服务器请求,然后将提交到任务队列API.如果我正确理解任务队列,我必须创建另一个servlet来从任务队列(作为工作者)进行处理.

我正在寻找两件事:

1. 工人是否会成为Servlet(即延伸HttpServlet)？如果没有,有人可以给我一个"工人"的例子吗？
2. 如果我只是想提交一个要立即执行的异步响应,那么使用任务队列真的有意义吗？似乎GWT的内置RPC机制就足够了.

我每小时在 Google App Engine 中运行数千个任务，即使经过多次重试，其中仍有大约 0.1% 的任务失败。理想情况下，我希望他们停止尝试并退出。然而，由于应用引擎的设计，他们似乎只是一次又一次地尝试。我知道有一个退避时间，它会随着每次不成功的执行而增加，但我希望它们在 n 次完全重试后退出。

我能以某种方式完成这个吗？一个任务可以得到它运行失败的次数吗？

从blobstore中删除所有blob的最佳方法是什么？我正在使用Python.

我有很多blob,我想删除它们.我目前正在做以下事情:

class deleteBlobs(webapp.RequestHandler): 
    def get(self): 
        all = blobstore.BlobInfo.all(); 
        more = (all.count()>0) 
        blobstore.delete(all); 
        if more: 
            taskqueue.add(url='/deleteBlobs',method='GET'); 

这似乎是使用大量的CPU和(据我所知)没有任何用处.

我的一个GAE任务队列请求超出了软内存限制(下面的日志).我对软内存限制的理解是,它允许请求完成,然后在完成后,它关闭实例.

但是,从日志中看,当我达到软内存限制时,执行会停止.我看到内存限制消息后没有更多的日志记录代码,我已经检查了我的状态,看起来看起来不像请求正在完成.我不确定它是否重要,但此请求是在延迟库TaskQueue中执行的.

因此,如果TaskQueue达到软私有内存限制,执行是否会继续,直到请求完成或立即停止？是否可能只记录日志代码？

日志:

2012-04-11 23:45:13.203
Exceeded soft private memory limit with 145.848 MB after servicing 3 requests total
W 2012-04-11 23:45:13.203
After handling this request, the process that handled this request was found to be using too much memory and was terminated. This is likely to cause a new process to be used for the next request to your application. If you see this message frequently, you may have a memory leak in your application.

我需要一个任务队列,以便可以将一些繁重的操作移出uwsgi上下文而不影响用户.由于目前正在使用uwsgi,我认为可以使用uwsgi假脱机程序.我想知道它究竟是如何工作的？假脱机任务是否仍然在其他uwsgi工作程序中执行？如果是,那么服务器仍然会超载,因为其他工作人员将忙于服务假脱机任务.还有更好的选择吗？我正在使用python

我已经用Django编写了一个API,其目的是作为网站后端和我们使用的外部服务之间的桥梁,这样网站就不必处理对外部API的许多请求(CRM,日历事件,电子邮件提供商)等等.).

API主要轮询其他服务,解析结果并将其转发到网站后端.

我最初选择了基于Celery的任务队列,因为在我看来,这是将该处理卸载到另一个实例的正确工具,但我开始认为它并不适合这个目的.

由于网站需要同步响应,我的代码包含很多:

results = my_task.delay().get()

要么

results = chain(fetch_results.s(), parse_results.s()).delay().get()

哪种感觉不适合使用Celery任务.

在拉动数十个请求并并行处理结果(例如定期刷新任务)时效率很高- 但为简单请求(fetch - parse-forward)增加了大量开销,这代表了大部分流量.

我是否应该完全同步这些"简单请求"并保留Celery任务用于特定场景？是否有更符合我的API目的的替代设计(可能涉及asyncio)？

在EBS EC2实例上使用Django,Celery(带有Amazon SQS).

有没有办法禁用失败的任务的重试选项？它不可能在queue.yaml中执行此操作

retry_parameters:
    task_retry_limit: 0

还有其他选项可以禁用重试吗？

我的谷歌App Engine应用程序被添加了大量的延迟任务到任务队列.任务计划每x秒运行一次.如果我正确理解了bucket-size属性b,则高值将阻止延迟任务运行,直到添加了b任务.但是,有一个接近实时的要求,即任务按计划运行.我不希望在达到桶大小之前阻止任务.相反,他们应该尽可能接近他们的预定时间.

为了支持这个用例,我应该使用1的桶大小和500 的速率(这是当前的最大速率)吗？还有哪些方法可以支持这个？谢谢!

我用Java编写了一个servlet代码,用于读取存储在Google Cloud Storage中的文件行.一旦我读完每一行,我就把它传递给预测API.一旦我得到了通过的文本的预测.我将其附加到原始行并将其存储在Google云存储中的其他文件中.

此源文件是一个csv,有超过10,000条记录.因为我正在单独解析它,将其传递给预测API,然后存储回云存储.这需要很多时间.由于App Engine限制为30个部分,因此任务队列也有限制.有人建议我一些选择吗？由于重新启动程序不是一个选项,因为我不能从我停止的地方开始预测.

这是我的代码:

@SuppressWarnings("serial")
public class PredictionWebAppServlet extends HttpServlet {

    private static final String APPLICATION_NAME = "span-test-app";

    static final String MODEL_ID = "span-senti";
    static final String STORAGE_DATA_LOCATION = "/bigdata/training_set/";
    private static HttpTransport httpTransport;
    private static final JsonFactory JSON_FACTORY = JacksonFactory
            .getDefaultInstance();

    public static final String INPUT_BUCKETNAME = "bigdata";
    public static final String INPUT_FILENAME = "abc.csv";

    public static final String OUTPUT_BUCKETNAME = "bigdata";
    public static final String OUTPUT_FILENAME = "def.csv";

    private static Credential authorize() throws Exception {

        Credential …