Return-Path: 
 <issues-return-76250-apmail-maven-issues-archive=maven.apache.org@maven.apache.org>
X-Original-To: apmail-maven-issues-archive@minotaur.apache.org
Delivered-To: apmail-maven-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 B6F8E98C0
	for <apmail-maven-issues-archive@minotaur.apache.org>;
 Wed, 25 Jan 2012 10:36:35 +0000 (UTC)
Received: (qmail 39057 invoked by uid 500); 25 Jan 2012 10:36:35 -0000
Delivered-To: apmail-maven-issues-archive@maven.apache.org
Received: (qmail 38957 invoked by uid 500); 25 Jan 2012 10:36:34 -0000
Mailing-List: contact issues-help@maven.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:issues-help@maven.apache.org>
List-Unsubscribe: <mailto:issues-unsubscribe@maven.apache.org>
List-Post: <mailto:issues@maven.apache.org>
List-Id: <issues.maven.apache.org>
Reply-To: dev@maven.apache.org
Delivered-To: mailing list issues@maven.apache.org
Received: (qmail 38949 invoked by uid 99); 25 Jan 2012 10:36:34 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Jan 2012 10:36:34 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=5.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: local policy)
Received: from [63.246.24.159] (HELO codehaus01.managed.contegix.com)
 (63.246.24.159)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Jan 2012 10:36:28 +0000
Received: from codehaus01.managed.contegix.com (localhost.localdomain
 [127.0.0.1])
	by codehaus01.managed.contegix.com (Postfix) with ESMTP id E0F49B0641
	for <issues@maven.apache.org>; Wed, 25 Jan 2012 04:36:07 -0600 (CST)
Date: Wed, 25 Jan 2012 04:36:07 -0600 (CST)
From: "Alexey Yudichev (JIRA)" <jira@codehaus.org>
To: issues@maven.apache.org
Message-ID: 
 <1455037286.25145.1327487767922.JavaMail.j2ee-jira@codehaus01.managed.contegix.com>
In-Reply-To: 
 <845604281.3826.1322319640056.JavaMail.j2ee-jira@codehaus01-new.managed.contegix.com>
Subject: [jira] (SUREFIRE-799) Allow test parallelisation when
 forkMode=always
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 22cf62d5d84cf5bea94eb3b65e0ebd09
X-Virus-Checked: Checked by ClamAV on apache.org


    [ https://jira.codehaus.org/browse/SUREFIRE-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289606#comment-289606 ] 

Alexey Yudichev edited comment on SUREFIRE-799 at 1/25/12 4:35 AM:
-------------------------------------------------------------------

Thanks nkeywal, one question if you don't mind. I want surefire to fork X JVMs and then spread the tests across them evenly without re-launching new JVM for every test. Looks like this:{code:xml}
<configuration>
    <forkMode>perthread</forkMode>
    <threadCount>2</threadCount>
</configuration>{code}
runs at most 2 JVMs but still launches new JVM instance for every test. Is it possible to reuse JVMs? Our integration tests are heavy to initialise and their initialisation is statically defined, so to avoid re-initialisation there should be JVM reuse.

                
      was (Author: ylexus):
    Thanks nkeywal, one question if you don't mind. I want surefire to fork X JVMs and then spread the tests across them evenly without re-launching new JVM for every test. Look like this:{code:xml}
<configuration>
    <forkMode>perthread</forkMode>
    <threadCount>2</threadCount>
</configuration>{code}
runs at most 2 JVMs but still launches new JVM instance for every test. Is it possible to reuse JVMs? Our integration tests are heavy to initialise and their initialisation is statically defined, so to avoid re-initialisation there should be JVM reuse.

                  
> Allow test parallelisation when forkMode=always
> -----------------------------------------------
>
>                 Key: SUREFIRE-799
>                 URL: https://jira.codehaus.org/browse/SUREFIRE-799
>             Project: Maven Surefire
>          Issue Type: New Feature
>          Components: process forking
>    Affects Versions: 2.10
>         Environment: all
>            Reporter: nkeywal
>            Assignee: Kristian Rosenvold
>             Fix For: 2.12
>
>         Attachments: surefire_799_212_trunk.patch, surefire_799.v2.patch
>
>
> Surefire already allows:
> - forking
> - parallelization within a JVM
> Mixing both features would mean forking multiple JVM instead of only one.
> It would allow to parallelize tests that need to be executed in a separate JVM (i.e.: with forkMode=always). Usually these tests take longer than the simple ones. In our case, 40% of the tests are executed in 4 minutes, the other 60% need two hours. So it's obviously more interesting to parallelize the former, but these ones need to fork.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira