Return-Path: X-Original-To: apmail-river-dev-archive@www.apache.org Delivered-To: apmail-river-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 0F092F68A for ; Sat, 6 Apr 2013 00:43:20 +0000 (UTC) Received: (qmail 20808 invoked by uid 500); 6 Apr 2013 00:43:19 -0000 Delivered-To: apmail-river-dev-archive@river.apache.org Received: (qmail 20784 invoked by uid 500); 6 Apr 2013 00:43:19 -0000 Mailing-List: contact dev-help@river.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@river.apache.org Delivered-To: mailing list dev@river.apache.org Received: (qmail 20776 invoked by uid 99); 6 Apr 2013 00:43:19 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 06 Apr 2013 00:43:19 +0000 X-ASF-Spam-Status: No, hits=4.0 required=5.0 tests=HTML_MESSAGE,MISSING_MIMEOLE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [207.57.65.70] (HELO zeus.net.au) (207.57.65.70) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 06 Apr 2013 00:43:13 +0000 Received: (qmail 17963 invoked by uid 16710); 6 Apr 2013 00:42:50 -0000 Received: from unknown (HELO [10.121.158.191]) ([49.176.71.50]) (envelope-sender ) by 207.57.65.70 (qmail-ldap-1.03) with SMTP for ; 6 Apr 2013 00:42:50 -0000 From: Peter Reply-To: Peter To: dev@river.apache.org Subject: Re: test failure repeatability - TaskManager X-Mailer: Modest 3.1 References: <515B4652.3020503@zeus.net.au> <1365022550.4791.5.camel@Nokia-N900-51-1> <515C98AF.3080805@acm.org> <515C9A1E.3030203@acm.org> In-Reply-To: <515C9A1E.3030203@acm.org> Content-Type: multipart/alternative; boundary="=-yduvexNEX17IjiP2wi1r" X-MSMail-Priority: Normal X-Priority: 3 Date: Sat, 06 Apr 2013 10:28:07 +1000 Message-Id: <1365208087.6614.5.camel@Nokia-N900-51-1> Mime-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org --=-yduvexNEX17IjiP2wi1r Content-Type: text/plain; charset=utf-8 Content-ID: <1365208087.6614.2.camel@Nokia-N900-51-1> Content-Transfer-Encoding: 7bit ----- Original message ----- > One possibility is that some cases may just be "these tasks must not run > in parallel" rather than an actual ordering. > > Also, I'm not sure all ordering constraints that are needed are > necessarily implemented. The whole thing feels messy to me. > Agreed, we should probably consider each case individually, I noticed there's a configuration property that allows a TaskManager instance to be injected on a number of occasions too, which suggests there might be some sharing. Peter. > On 4/3/2013 2:04 PM, Dan Creswell wrote: > > I'm with you. My first step was going to be reviewing where runAfter is > > used, how often etc. I'd first like to be convinced that all the ordering > > constraints are actually required and can't be circumvented/dropped. > > > > On 3 April 2013 22:01, Patricia Shanahan wrote: > > > > > I agree with the idea of understanding the use cases before designing the > > > solution, and with using standard API classes as much as possible. The > > > table I sent you was intended as a first step towards that. > > > > > > I'm not convinced that the right solution is a single TaskManager > > > successor. Different TaskManager instances may have different use cases, > > > and separating them may lead to several simpler solutions, each of which as > > > a narrower set of requirements. > --=-yduvexNEX17IjiP2wi1r--