Return-Path: X-Original-To: apmail-incubator-allura-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-allura-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 72B7810B6F for ; Tue, 3 Dec 2013 18:31:20 +0000 (UTC) Received: (qmail 13185 invoked by uid 500); 3 Dec 2013 18:31:20 -0000 Delivered-To: apmail-incubator-allura-dev-archive@incubator.apache.org Received: (qmail 13154 invoked by uid 500); 3 Dec 2013 18:31:20 -0000 Mailing-List: contact allura-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: allura-dev@incubator.apache.org Delivered-To: mailing list allura-dev@incubator.apache.org Received: (qmail 13146 invoked by uid 99); 3 Dec 2013 18:31:20 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Dec 2013 18:31:20 +0000 X-ASF-Spam-Status: No, hits=-0.1 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of noreply@sourceforge.net designates 216.34.181.60 as permitted sender) Received: from [216.34.181.60] (HELO smtp.ch3.sourceforge.com) (216.34.181.60) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Dec 2013 18:31:14 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.com; s=x; h=Date:References:In-Reply-To:Message-ID:Subject:Reply-To:From:To:MIME-Version:Content-Type; bh=TFJwPLqiCXJMucg2mNt7K/UmcXtf50PhetmkYOD92kk=; b=dL/knT18IXWE9fesQOw5jbA3+0mKIO4X7mnwlw4PraFySvjiiZFQgfKDhpKSTlF16UOlSBIeo2cJe9XCGmq/UP5xbjCwcU/BYk6K0ou/3CR3vF0nP/daPgCAS4RbXxQbcy6ph18N/dvp1SF/sAoq+9RXN/Tv7frke1CJ63mgIFs=; Received: from localhost ([127.0.0.1] helo=sfs-alluradaemon-2.v29.ch3.sourceforge.com) by sfs-alluradaemon-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VnukH-0007Lg-GR for allura-dev@incubator.apache.org; Tue, 03 Dec 2013 18:30:53 +0000 Content-Type: multipart/related; boundary="===============3803508621401091545==" MIME-Version: 1.0 To: allura-dev@incubator.apache.org From: "Dave Brondsema" Reply-To: "[allura:tickets] " <4397@tickets.allura.p.re.sf.net> Subject: [allura:tickets] #4397 Run timeline aggregations in the background with taskd Message-ID:

In-Reply-To: <4fdb77fe1be1ce660b000074.tickets@allura.p.sourceforge.net> References: <4fdb77fe1be1ce660b000074.tickets@allura.p.sourceforge.net> Date: Tue, 03 Dec 2013 18:30:53 +0000 X-Virus-Checked: Checked by ClamAV on apache.org --===============3803508621401091545== Content-Type: multipart/alternative; boundary="===============1273991441274252776==" MIME-Version: 1.0 --===============1273991441274252776== MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit - **Size**: 2 --> 4 --- ** [tickets:#4397] Run timeline aggregations in the background with taskd** **Status:** open **Labels:** v2 activitystreams **Created:** Fri Jun 15, 2012 05:59 PM UTC by Tim Van Steenburgh **Last Updated:** Tue Dec 03, 2013 06:29 PM UTC **Owner:** nobody Once the volume ramps up, we probably won't want to be doing timeline aggregations on demand if we can help it. Find good spots to fire off aggregations in the background using taskd, so that when an activitystream page is requested, the cached timeline can just be pulled from mongo w/o doing an aggregation. For users, a good spot to do this might be on login. For projects, not sure...needs more thought. Do we need to worry about two aggregations for the same node running at the same time? --- Sent from sourceforge.net because allura-dev@incubator.apache.org is subscribed to https://sourceforge.net/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. --===============1273991441274252776== MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
  • Size: 2 --> 4

[tickets:#4397] Run timeline aggregations in the background with taskd

Status: open
Labels: v2 activitystreams
Created: Fri Jun 15, 2012 05:59 PM UTC by Tim Van Steenburgh
Last Updated: Tue Dec 03, 2013 06:29 PM UTC
Owner: nobody

Once the volume ramps up, we probably won't want to be doing timeline aggregations on demand if we can help it. Find good spots to fire off aggregations in the background using taskd, so that when an activitystream page is requested, the cached timeline can just be pulled from mongo w/o doing an aggregation.

For users, a good spot to do this might be on login. For projects, not sure...needs more thought.

Do we need to worry about two aggregations for the same node running at the same time?


Sent from sourceforge.net because allura-dev@incubator.apache.org is subscribed to https://sourceforge.net/p/allura/tickets/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

--===============1273991441274252776==-- --===============3803508621401091545==--