From dev-return-2923-apmail-jmeter-dev-archive=jmeter.apache.org@jmeter.apache.org Fri Jan 3 14:45:35 2014 Return-Path: X-Original-To: apmail-jmeter-dev-archive@minotaur.apache.org Delivered-To: apmail-jmeter-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 8D6801069A for ; Fri, 3 Jan 2014 14:45:35 +0000 (UTC) Received: (qmail 84353 invoked by uid 500); 3 Jan 2014 14:45:33 -0000 Delivered-To: apmail-jmeter-dev-archive@jmeter.apache.org Received: (qmail 82962 invoked by uid 500); 3 Jan 2014 14:45:32 -0000 Mailing-List: contact dev-help@jmeter.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jmeter.apache.org Delivered-To: mailing list dev@jmeter.apache.org Received: (qmail 82806 invoked by uid 99); 3 Jan 2014 14:45:31 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Jan 2014 14:45:31 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of philippe.mouawad@gmail.com designates 209.85.213.181 as permitted sender) Received: from [209.85.213.181] (HELO mail-ig0-f181.google.com) (209.85.213.181) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Jan 2014 14:45:26 +0000 Received: by mail-ig0-f181.google.com with SMTP id k19so1212951igc.2 for ; Fri, 03 Jan 2014 06:45:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=BkypcEn2UYf8WlIE2Tq5Za1r2PhhI73x5OBTUI7R5Jc=; b=tZzq8daIanQxrchzfmlci8jXNMZSihzw1EymMIvk+e+eKBSMC9quWFghPYv8ws9wOx yb9d5P/j1HvRWl++/SFv+d8ZtukZyJYb6cv+0kcMXlWL0k4KtsBs0vTdZa7q7XSuFmqh rbrI4AzGNXTYmXDb0Rc6hJOHoxnz9wXx0Cw/z9ZCPvWYa+NH9KNaGAOPk+YBHcJGmmum oSPiVj5kShmFS0wxo87yR9KdpgbdmaxcarouM5G94jB9mqsj9fMrXG9L34tF6kpGCWGf kv4OhAkDEKfVRR6c38jXhOkA28cQYGe7kAFryNGtsypf3C1aXh1Fw3mzp1YziC2FLhKR z8mQ== MIME-Version: 1.0 X-Received: by 10.42.70.144 with SMTP id f16mr374003icj.53.1388760306204; Fri, 03 Jan 2014 06:45:06 -0800 (PST) Received: by 10.43.64.212 with HTTP; Fri, 3 Jan 2014 06:45:06 -0800 (PST) In-Reply-To: References: Date: Fri, 3 Jan 2014 15:45:06 +0100 Message-ID: Subject: Re: [Bug 55932] Create a Graphite Listener From: Philippe Mouawad To: "dev@jmeter.apache.org" Content-Type: multipart/alternative; boundary=90e6ba1efd44bac3fc04ef11f4c9 X-Virus-Checked: Checked by ClamAV on apache.org --90e6ba1efd44bac3fc04ef11f4c9 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jan 3, 2014 at 3:33 PM, sebb wrote: > On 3 January 2014 13:47, Philippe Mouawad > wrote: > > Hello Sebb, > > As requested although I don't see why it cannot be in bugzilla,if it were > > the history of discussion could be found more easily. > > Because discussion may take a while and Bugzilla is not good for that. > We can add links to the mail thread with any followup, once decisions are > made. > > > Regards > > Philippe > > On Fri, Jan 3, 2014 at 1:57 PM, wrote: > > > >> https://issues.apache.org/bugzilla/show_bug.cgi?id=55932 > >> > >> --- Comment #6 from Sebb --- > >> I have been having a look at the implementation. > >> > >> I don't really see that it needs Commons Math; we aleady have > >> StatCalculator > >> which handles percentiles and more. > >> > > Ok I can change this. > > > >> > >> Likewise, does it really need Commons Pool? > >> It seems wrong to have to have 2 separate pools of SocketOutputStream > >> instances. > >> > > Can you clarify ? > > There is an executor pool (max size : 1 for now) and a > > > > socketOutputStreamPool in GraphiteMetricsManager. > > Sorry, that was wrong. > > There's a socketOutputStreamPool in PickleMetricsManager only > I thought I had spotted another in SocketOutputStreamPoolFactory but > that is just the implementation. > > > > > How many of these would there be? > >> > > > > Currently it is true we could use only one socket and keep it open. > > > > > >> > >> Also, DescriptiveStatistics is not thread-safe (nor is StatCalculator). > >> > > It is not a problem, as DescriptiveStatistics is accessed synchronously. > > Only write accesses are synchronised. > But read needs to be synchronised as well to ensure safe publication. > > >> > >> If we do implement something like this, I think the data processing > needs > >> either to be carefully synchronised, or the raw data should be sent to a > >> separate singleton background thread. > >> > > > > I think it is carefully synchronized in the patch. If not please point me > > to where you see an issue. > > See above. > > If it used a background thread with a suitable queuing mechanism, > there would be no need to synch the data collection, and the > processing would not slow the main thread. > So you mean we publish the SampleResult in a queue and a thread handles computation ? Do you intend to implement a kind of RingBuffer , something like this : https://github.com/LMAX-Exchange/disruptor or much simpler ? And is there another thread to send ? Could you propose a patch change ? > > What happens currently if the backend socket stalls or runs slowly? > It will only affect the publication . The run method will be executed while the other one is still running , so we could send same statistics twice, good catch. > > Also, decoupling in this way would make it easier to provide > implementations, as they would not need to be thread-safe. > > > > >> > >> Follow-ups to the dev list please. > >> > >> -- > >> You are receiving this mail because: > >> You are the assignee for the bug. > >> > > > > > > > > -- > > Cordialement. > > Philippe Mouawad. > -- Cordialement. Philippe Mouawad. --90e6ba1efd44bac3fc04ef11f4c9--