Return-Path: X-Original-To: apmail-drill-issues-archive@minotaur.apache.org Delivered-To: apmail-drill-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 53D6C18497 for ; Thu, 14 May 2015 23:19:01 +0000 (UTC) Received: (qmail 35666 invoked by uid 500); 14 May 2015 23:19:01 -0000 Delivered-To: apmail-drill-issues-archive@drill.apache.org Received: (qmail 35639 invoked by uid 500); 14 May 2015 23:19:01 -0000 Mailing-List: contact issues-help@drill.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@drill.apache.org Delivered-To: mailing list issues@drill.apache.org Received: (qmail 35629 invoked by uid 99); 14 May 2015 23:19:01 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 May 2015 23:19:01 +0000 Date: Thu, 14 May 2015 23:19:01 +0000 (UTC) From: "Daniel Barclay (Drill) (JIRA)" To: issues@drill.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Comment Edited] (DRILL-2039) use forks-per-CPU units in forkCount MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/DRILL-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14544584#comment-14544584 ] Daniel Barclay (Drill) edited comment on DRILL-2039 at 5/14/15 11:18 PM: ------------------------------------------------------------------------- > The default value of 4 has been working decently for a while No, actually it hasn't. It has chronically been causing problems for multiple developers here. Why don't we have the known-reliable value of "1" in the checked-in version, and let people who want to optimize run time risk problems on their own machines? Since they consciously changed forkCount, if they run into problems because of that forkCount setting, they're likely to recognize the problem easily. Right now, people who want to optimize run time risk causing problems on _other_ people's machines (by having the non-unity value of forkCount checked in). Those other people, not having consciously set forkCount, aren't going to easily recognize that timeouts on their machines are because of the forkCount setting. was (Author: dsbos): > The default value of 4 has been working decently for a while No, actually it hasn't. It has chronically been causing problems for multiple developers here. Why don't we have the known-reliable value of "1" in the checked-in version, and let people who want to optimize run time risk problems on their own machines? Since they consciously changed forkCount, if they run into problems because of that forkCount setting, they're likely to recognize the problem easily. Right now, people who want to optimize run time risk causing problems on _other_ peoples machines (by having the non-unity value of forkCount checked in). Those other people, not having consciously set forkCount, aren't going to easily recognize that timeouts on their machines are because of the forkCount setting. > use forks-per-CPU units in forkCount > ------------------------------------ > > Key: DRILL-2039 > URL: https://issues.apache.org/jira/browse/DRILL-2039 > Project: Apache Drill > Issue Type: Improvement > Components: Tools, Build & Test > Reporter: Daniel Barclay (Drill) > Assignee: Hanifi Gunes > Priority: Minor > Fix For: 0.9.0 > > Attachments: DRILL-2039.1.patch.txt, DRILL-2039.2.patch > > > Can Surefire's fork count be set using units of forks per CPU instead of the absolute number of forks (i.e., {{1C}} instead of {{4}})? > That would let developers with more powerful machines still run tests in parallel while letting others avoid or reduce test timeout errors without the risk of forgetting to re-edit pom.xml after every switch to a different git branch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)