From issues-return-13185-archive-asf-public=cust-asf.ponee.io@jmeter.apache.org Sun Aug 19 14:48:28 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id ED161180656 for ; Sun, 19 Aug 2018 14:48:27 +0200 (CEST) Received: (qmail 99724 invoked by uid 500); 19 Aug 2018 12:48:27 -0000 Mailing-List: contact issues-help@jmeter.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: issues@jmeter.apache.org Delivered-To: mailing list issues@jmeter.apache.org Received: (qmail 99713 invoked by uid 99); 19 Aug 2018 12:48:27 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 19 Aug 2018 12:48:27 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 8E8FB1A1196 for ; Sun, 19 Aug 2018 12:48:26 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -10.301 X-Spam-Level: X-Spam-Status: No, score=-10.301 tagged_above=-999 required=6.31 tests=[ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id 1RgDkQH-yQ-N for ; Sun, 19 Aug 2018 12:48:26 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id B28C05F3EC for ; Sun, 19 Aug 2018 12:48:25 +0000 (UTC) Received: from asf-bz1-us-mid.priv.apache.org (nat1-us-mid.apache.org [23.253.172.122]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTPS id 38A29E00CB for ; Sun, 19 Aug 2018 12:48:25 +0000 (UTC) Received: by asf-bz1-us-mid.priv.apache.org (ASF Mail Server at asf-bz1-us-mid.priv.apache.org, from userid 33) id 6578061330; Sun, 19 Aug 2018 12:48:24 +0000 (UTC) From: bugzilla@apache.org To: issues@jmeter.apache.org Subject: [Bug 62637] New: Synchronizing Timer set by threads is stuck when adding duration Date: Sun, 19 Aug 2018 12:48:23 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: JMeter X-Bugzilla-Component: Main X-Bugzilla-Version: 4.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: orimarko@gmail.com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: issues@jmeter.apache.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter target_milestone attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bz.apache.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 https://bz.apache.org/bugzilla/show_bug.cgi?id=3D62637 Bug ID: 62637 Summary: Synchronizing Timer set by threads is stuck when adding duration Product: JMeter Version: 4.0 Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: Main Assignee: issues@jmeter.apache.org Reporter: orimarko@gmail.com Target Milestone: --- Created attachment 36099 --> https://bz.apache.org/bugzilla/attachment.cgi?id=3D36099&action=3Dedit jmx reproducer When I'm using Synchronizing Timer set by threads (Number of Simultaneous U= sers to Group by) it works well except when using with Thread group's duration, When it's used together the test hang, probably because of Synchronizing is= sue, as documented: If timeout in milliseconds is set to 0 and number of threads never reaches "Number of Simultaneous Users to Group by" then Test will pause infinitely. Only a forced stop will stop it. Setting Timeout in milliseconds is an opti= on to consider in this case. Also Runtime Controller isn't a valid replacement for limiting the duration, Is there other way to limit test duration, but still use some kind of Synchronization of threads? Can I add a hook using JSR233 Sampler when test duration over and stop all threads? I'm thinking of using Precise Throughput Timer, but it seems over complicat= ed for this specific requirement. I can make test no hang if I put a value in Timeout in milliseconds with va= lue higher than expected in a normal flow, as 10 seconds, 10000, and then after= 10 seconds the test stops, but I'm not sure it fixes the issue completely. --=20 You are receiving this mail because: You are the assignee for the bug.=