Return-Path: Delivered-To: apmail-incubator-qpid-dev-archive@locus.apache.org Received: (qmail 37109 invoked from network); 2 May 2007 15:39:04 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 2 May 2007 15:39:04 -0000 Received: (qmail 76227 invoked by uid 500); 2 May 2007 15:39:10 -0000 Delivered-To: apmail-incubator-qpid-dev-archive@incubator.apache.org Received: (qmail 76190 invoked by uid 500); 2 May 2007 15:39:10 -0000 Mailing-List: contact qpid-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: qpid-dev@incubator.apache.org Delivered-To: mailing list qpid-dev@incubator.apache.org Received: (qmail 76180 invoked by uid 99); 2 May 2007 15:39:10 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 May 2007 08:39:10 -0700 X-ASF-Spam-Status: No, hits=2.9 required=10.0 tests=HTML_10_20,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of rupertlssmith@googlemail.com designates 64.233.162.225 as permitted sender) Received: from [64.233.162.225] (HELO nz-out-0506.google.com) (64.233.162.225) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 May 2007 08:39:03 -0700 Received: by nz-out-0506.google.com with SMTP id j2so187973nzf for ; Wed, 02 May 2007 08:38:42 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=googlemail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=gZMs7RQYI1v0x7OafOm+zcKdRh13Y3v0DXWP3MkHY0OuYJaaItZywitytbwOgafMHauaaYfiddG1q/pcrxtBDPVYdSHKTMzLmvdLU91dTH04OYOe1DKPyW3icAlq8S2hbYhSgGf5heyCB4bb6yfnvCSVhCvHvo5HL1I4ejAHMX4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=igBMkhq1mSZ8t0hVnEl8iw/IBQ4G4G8Xqkqe7Q+yOGQl4oyc00Juk8bfduRM96IfXTOXCsDdAZzwG2zSEnsHSTDh/VIT/8NR+IG49ozZF5q25x9HonFOxMbWyTPMYAraap9OI1Dn7qdWUyfo2xeRM6T+gms4/EhUCIbUK8WeKVM= Received: by 10.115.55.1 with SMTP id h1mr249367wak.1178120321895; Wed, 02 May 2007 08:38:41 -0700 (PDT) Received: by 10.114.158.16 with HTTP; Wed, 2 May 2007 08:38:41 -0700 (PDT) Message-ID: Date: Wed, 2 May 2007 16:38:41 +0100 From: "Rupert Smith" To: qpid-dev@incubator.apache.org Subject: Re: C++ M2 JIRAs In-Reply-To: <46388372.7060300@redhat.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_10824_16248894.1178120321787" References: <1177356048.32369.20.camel@localhost.localdomain> <4635AF72.3040409@redhat.com> <46386171.4090306@redhat.com> <4638734D.9020404@redhat.com> <46388372.7060300@redhat.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_10824_16248894.1178120321787 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Your point about trying to make the coordinator not care too much about the what the clients are doing is valid, and worth pursuing for the purpose of making the coordinator abstract enough to be re-usable for different kinds of tests. I think the coordinator as a whole does need to be aware of the roles it assigns to test clients to ensure that it assigns receiver roles before starting senders. This behaviour has been encapsulated in the CoordinatingTestCase class. The purpose of CoordinatingTestCase is to coordinate a two participant sender/receiver test. I may pull an interface out of it add another implementation the purpose of which is to coordinate a multi-client performance test. This will consist of a group of 'senders' (which probably also consume their own messages), spread over a set of test machines, and the coordinator will be used to to run a distributed test using the test machines to try and provide a better simulation of broker load with a large number of connections. One limit of the current performance tests is that they only run on a single client machine, limiting their scalability. Performance tests have been run up to 1000 connections, but with that many threads on the client machine, the overhead impacts the results obtained. Should be able to do distributed performance testing with the current design by only changing the coordinator to introduce a new kind of test case, without making any changes to existing interop test clients. On 02/05/07, Gordon Sim wrote: > > Rupert Smith wrote: > > Ok, lets just leave things as they are then. Seems more important to > just > > get the code written at the moment. I'll add those clarifications. > > Well, if we want to make the changes at some point, now would be the > best time before more code is in place. The question is whether they > actually simplify things or whether they just represent my preference. > However, I can live with whats there now. > ------=_Part_10824_16248894.1178120321787--