Re: [VOTE] Release Qpid Dispatch Router 1.19.0 (RC2)

+1 Built against Proton 0.37.0-rc2 Ran two tests : AMQP, 1 sender-receiver pair and 10 sender-receiver pairs. (Routers on separate boxes connected by high-speed link). 0.75 Gbps, and 2.55 Gbps Results similar to yesterday -- slightly better than release 1.18.0 . On Thu, Mar 17, 2022 at 8:35 A

Re: [VOTE] Release Qpid Dispatch Router 1.19.0 (RC1)

Aye! Ran 2-router AMQP tests, 1 sender, and 10-send across high bandwidth link. Both performed better than 1.18 release: +17% for 1-sender, +4.7% for 10-sender. On Wed, Mar 16, 2022 at 11:00 AM Robbie Gemmell wrote: > On Wed, 16 Mar 2022 at 14:02, Ken Giusti wrote: > > > > On Wed, Mar 16, 2022

Re: [VOTE] Release Qpid Dispatch Router 1.18.0 (RC1)

Sorry, I have to withdraw my vote -- I tested the 'freeze' code, not the RC1 code. On Wed, Nov 17, 2021 at 9:53 AM Michael Goulish wrote: > *Aye!* > > Ran my 20 perf tests, testing: > > { Raw AMQP, TCP Adaptor, HTTP over TCP, HTTP Adaptor, HTTP2 Adapter } > X { 1

Re: [VOTE] Release Qpid Dispatch Router 1.18.0 (RC1)

*Aye!* Ran my 20 perf tests, testing: { Raw AMQP, TCP Adaptor, HTTP over TCP, HTTP Adaptor, HTTP2 Adapter } X { 1 Sender, 10 Senders} X { 1 Router, 2 Routers } No serious performance regressions, nothing blew up, no test personnel were maimed or killed. On Tue, Nov 16, 2021 at 4:35 PM Ken Gius

Re: [dispatch-router] 1.17.0-freeze tagged

Ken -- what Proton would be best to use when I am testing this Dispatch release? On Mon, Jul 26, 2021 at 2:20 PM Ken Giusti wrote: > Folks, > > I've tagged the HEAD of the main branch for 1.17.0-freeze today > (commit 608f2674c31dd85f7e5e52170edc7e0ce9f74333). > > We're now in the test/debug pha

[qrd] 24 hour soak test, two routers, with 28,800 attaches.

Sorry, I have not done the lovely graphs yet, but I want to just tell you the upshot. 24 hours of 'hey' testing. 10 parallel senders start up, run for 30 seconds, then quit. Repeat 2880 times. Result: Neither router gained memory after first hour or so. No crashes. Looks stable.

Re: [VOTE] Release Qpid Dispatch Router 1.16.1 (RC1)

Chuck: *ran several non-selftest tests* This seems like awkward wording. How about *"selfless tests"* ? On Tue, Jun 29, 2021 at 9:34 AM Chuck Rolke wrote: > +1 > > * scrutinized commits since 1.16.0 > * check checksum check checks > * built debug build from source using proton 0.34.0 on Fedor

Re: [VOTE] Release Qpid Dispatch Router 1.16.1 (RC1)

+1 Did 24-hour soak test of TCP adapter. 10 'hey' senders talking to nginx. 40 Gbit network between senders and receivers. No crash. Router memory use stabilized after 3 hours, and CPU use was between 250% and 285% the whole time. On Tue, Jun 29, 2021 at 7:30 AM Gordon Sim wrote: > On Mon, Ju

[qdr] Router 1.16.x TCP adapter does well in 24 hour soak test.

Using 'hey' with 10 parallel senders -- nginx on the receiving side -- for 24 hours. No crash, no long-term growth in memory, stable CPU usage. It's beautiful. 40 Gbit/sec network between sender & receiver. Router memory grew rapidly for first 10 minutes, going from 40 to 60 MB. Then continued t

Re: [qdr] latency test results are complete for 1.16.x branch

tponed until further notice. Maybe someday I will find some extra high-speed NICs and cables lying about On Fri, Jun 25, 2021 at 8:45 AM Michael Goulish wrote: > > The upshot: > * Worst-case results across the board have greatly improved. > * HTTP adapter has gotten slight

[qdr] latency test results are complete for 1.16.x branch

The upshot: * Worst-case results across the board have greatly improved. * HTTP adapter has gotten slightly slower in requests per second. Complete results here . Next up -- throughput tests usi

Re: [VOTE] Release Qpid Dispatch Router 1.16.0 (RC1)

+1 I ran 5 tests each of {1-router, 2-router} x {1 sender, 10 senders} -- i.e. 20 tests total -- sending 'hey' HTTP traffic through the router TCP adapter. Performance was significantly better than code from 05 May 1.16.x branch, and Nothing Blew Up. Shippit. On Wed, May 12, 2021 at 1:21 PM Ro

Re: RC1 : What Just Happened?

l of which came from the "response wait" phase. And in third place, at 24.5 msec, we had "response read". On Wed, May 12, 2021 at 2:20 AM Michael Goulish wrote: > > I just decided to redo some of my tests with RC1 so I could cast a vote, > and some weird things happ

In the one ultra-slow measurement of my 'hey' test ...

...earlier today, in which the slowest response took a total of 62.3 msec, the 'hey' tool reports that the long delay came from "DNS+dialup". It reported that the slowest instance of "DNS+dialup" took exactly 62.3 msec.

RC1 : What Just Happened?

I just decided to redo some of my tests with RC1 so I could cast a vote, and some weird things happened. Possibly good, but weird. First, I had to change my PYTHONPATH in one spot to say 2.7 instead of 3.9 as it was before. Is that correct? But second, performance on the test I picked -- 'hey'

[qdr] Two-Router TCP Connection Rate Test

What rate of new connection creation can a two-router network sustain through their TCP adapters? *165 connections per second*, measured at the TCP server. This rate was sustained with *little variation for 100,000 connections*. This took about 603 seconds. The router's memory kept growing occasi

[qdr] two-router TCP soak test success

Now halting the long soak test for two-router TCP traffic. * passed 3.5 days (87 hours) * passed 500,000 connections (100 made, then broken, per minute) * *no memory growth* on either router *for last 45 hours* * *no trend in latency* over the test (1.2 to 2.3 msec during entire test) * passed 30

Re: [qdr] two-router TCP test passes 220 million HTTP requests.

broker was able to 800.000k msg in / 800.000k msg out on a > 12-core xeon e5690 32gb ram , 2x 10gbe lan, rhel 6.x. > Test ran was on 2011, current HW should be at least 2 / 3 times better... > > On Mon, Mar 29, 2021 at 3:59 AM Michael Goulish > wrote: > > > * The test has n

[qdr] TCP soak test shows no long-term memory growth

Now past 250 million http requests -- 70 hours -- and there has been* 0 memory growth in last 27 hours.* *1 MB* memory growth *in last 45 hours.*

[qdr] two-router TCP test passes 220 million HTTP requests.

* The test has now passed 220,000 seconds (2.5 days) with no failure. 1000 requests per second, and a new batch of 100 Hey workers every 60 seconds. * Average response time is not changing. It has been between 1 and 2 msec the whole test. * Router memory does *not* appear to be growing without bo

[qdr] 2-router TCP soak test success

Both routers survive 14 million HTTP-over-TCP test. *1000 requests per second for 4 hours*, no problems except slow memory growth. One router on one box, one on the other. 40 Gbit link between them. On send side: 'hey' load generator doing 100 parallel workers, each at 10 requests per second. Eac

[qdr] Is this a 'Two-Armed Router' ?

I believe I have successfully run a "two-armed" router experiment. Please take a look at my setup and see if I am correct. Two machines, Colossus-Guardian and Brontonomicon. They are connected by two separate pairs of network interface cards. The fast cards are 40 Gbits/sec and have just a crosso

Re: Dispatch Router TCP Latency study...

latency to the point where the with-router case is actually slightly faster along much of the curve, although at higher levels of concurrency the difference is very small. On Mon, Mar 15, 2021 at 12:06 PM Michael Goulish wrote: > I have updated the document to include "4 KB Buffers" in t

Re: Dispatch Router TCP Latency study...

I have updated the document to include "4 KB Buffers" in title, and new graphs for Average Latency, and Slowest Latency. The link I already sent still works for the new version. On Mon, Mar 15, 2021 at 10:51 AM Gordon Sim wrote: > On 15/03/2021 14:06, Michael Goulish wrote: >

Re: Dispatch Router TCP Latency study...

s somewhat worse than slowest case without.Which makes sense... On Mon, Mar 15, 2021 at 6:17 AM Gordon Sim wrote: > On 15/03/2021 09:37, Michael Goulish wrote: > > ...over a 40 Gbit/sec link, using the Golang 'Hey' HTTP load generator, > and > > a simple Go we

Re: Dispatch Router TCP Latency study...

Oops. I should say -- these tests were done with Dispatch Router src/buffer.c BUFFER_SIZE = 4096. Should probably put that in the title... On Mon, Mar 15, 2021 at 5:37 AM Michael Goulish wrote: > ...over a 40 Gbit/sec link, using the Golang 'Hey' HTTP load generator, >

Dispatch Router TCP Latency study...

...over a 40 Gbit/sec link, using the Golang 'Hey' HTTP load generator, and a simple Go webserver, with and without the Dispatch Router in the middle. Document here , because Apache won't let me send images in emai

Re: Dispatch Router TCP throughput test over fast link with 0, 1, and 2 routers

7;d be happy to work with you on that. Please note, however, that I am probably a Lot More Paranoid than most users. I mean --- I don't know if I'm *really* paranoid --- but I'm sure that's what everybody says about me! On Fri, Mar 12, 2021 at 11:01 AM Robbie Gemmell wro

Dispatch Router TCP throughput test over fast link with 0, 1, and 2 routers

Dispatch Router TCP throughput test over a 40 Gbit/sec link, with 0, 1, and 2 routers. = I am including complete setup details below, because I would like some help making sure I did everything right. *Basic idea * Two good-s

The router really does improve upon iperf-only tests.

With large buffers -- like 4 K -- putting the router in between two iperfs on the 40 Gbit/sec link really does improve upon an iperf-only test. I confirmed my suspicion/memory -- the reason is, in the iperf-only test, the receiver goes to 99.7% -- 100.0% CPU. It hits 100% frequently. And it is si

Re: Dispatch Router: Wow. Large message test with different buffer sizes

that I am about to do on AMQP. Once I do the AMQP tests to support that decision I hope to pursue that interesting little inflection point fiercely. On Mon, Feb 15, 2021 at 12:21 PM Robbie Gemmell wrote: > On Sat, 13 Feb 2021 at 16:40, Ted Ross wrote: > > > > On Fri, Feb 12

Re: Router Throughput vs Buffer Size -- 11 data points (2nd try)

cience. > > -Ted > > On Tue, Feb 16, 2021 at 1:53 PM Michael Goulish > wrote: > > > I keep forgetting that I can't include images. > > > > <https://www.dropbox.com/s/b9sbe4cbh3mddo4/buffer_vs_throughput.jpg?dl=0 > > > > Here it is. > >

Router Throughput vs Buffer Size -- 11 data points (2nd try)

I keep forgetting that I can't include images. Here it is. I'm afraid there's not much of any knee in this curve. By the way, CPU was almost unaffec

Router Throughput vs Buffer Size -- 11 data points

I'm afraid there's not much of any knee in this curve. By the way, CPU was almost unaffected. Actually it improved slightly, from 208% at 512 byte buffer, to 195 for buf=2048 to 191 for buf=3072 and above. [image: buffer_vs_throughput.jpg]

Router survives large-message soak test with 4K buffers

*test:* 4K buffer size in buffer.c 10 senders, 10 receivers 10 msec pause after sending each message msg size 200,000 bytes 3 million messages per sender interface: loopback *result:* router CPU and memory usage stable at 114% and 68MB mean latency 2.4 msec, standard deviation 1.4 no problems

Dispatch Router: Wow. Large message test with different buffer sizes

Well, *this* certainly made a difference! I tried this test: *message size:* 20 bytes *client-pairs:* 10 *sender pause between messages:* 10 msec *messages per sender:* 10,000 * credit window:* 1000 *Results:*

Re: Dispatch Router: Changing buffer size in buffer.c blows up AMQP.

*A better test would involve much larger messages, maybe 64K, 128K, or more.* Oh I see -- OK, that will be easy. This is something that needs to be fixed though, I expect. On Fri, Feb 12, 2021 at 12:08 PM Michael Goulish wrote: > A further note. > I just looked at all 100 receivers th

Re: Dispatch Router: Changing buffer size in buffer.c blows up AMQP.

at 11:14 AM Michael Goulish wrote: > Sorry -- I didn't realize this list would remove the image of my graph. > > Can everyone see this? > <https://www.dropbox.com/s/4t1xbp46y57mfgn/messages_vs_time.jpg?dl=0> > > On Fri, Feb 12, 2021 at 7:51 AM Chuck Rolke wro

Re: Dispatch Router: Changing buffer size in buffer.c blows up AMQP.

the image > to that. > > - Original Message ----- > > From: "Michael Goulish" > > To: users@qpid.apache.org > > Sent: Friday, February 12, 2021 2:43:40 AM > > Subject: Re: Dispatch Router: Changing buffer size in buffer.c blows up > AMQP. > >

Re: Dispatch Router: Changing buffer size in buffer.c blows up AMQP.

rever. I guess Something Interesting happened at about 28 seconds! Maybe what I need ... is a reading from "qdstat -m" just before and after that inflection point !?!?? On Thu, Feb 11, 2021 at 5:37 PM Ted Ross wrote: > On Thu, Feb 11, 2021 at 2:08 PM Michael Goulish >

Dispatch Router: Changing buffer size in buffer.c blows up AMQP.

OK, so in the file Dispatch Router file src/buffer.c I changed this: size_t BUFFER_SIZE = 512; to this: size_t BUFFER_SIZE = 4096; Gordon tells me that's like 8 times bigger. It makes a terrific difference in throughput in the TCP adapter, and if you limit the sender to the t

Re: [VOTE] Release Qpid Dispatch Router 1.15.0 (RC1)

+1 Tested TCP adapter for 1 hour at 600 Mbits/sec between two boxes -- total 253 GBytes -- using iperf3 as TCP client and server -- normal router shutdown. On Mon, Feb 8, 2021 at 11:43 AM Chuck Rolke wrote: > +1 > > * downloaded and checked sha512 > * built debug build using proton master@537d

Re: [VOTE] Release Qpid Dispatch Router 1.12.0 (RC1)

+1 It has now completed 120 million messages without problem in the following test: * single router * 250 receivers, 250 senders, 250 addresses * senders in 5 groups, each throttled to send messages at different intervals: {13, 17, 19, 23, 29} msec. * router has *64 worker threads* (machi

Re: [VOTE] Release Qpid Dispatch Router 1.10.0 (RC2)

*+ 1* I did a 2-million link test, i.e. 1 million in, 1 million out, spread evenly over 100 connections -- on a single router, coming from a single client -- using Gordon's python client made for this purpose -- and nothing blew up or melted down. And it did not use an exorbitant amount of memory

Re: [VOTE] Release Qpid Dispatch Router 1.9.0 (RC2)

+1 Two large-scale tests done, with no trouble. Test 1 5 routers linear network (A...E) 500 senders on router A, 500 receivers on router E 1 unique address per client-pair distribution : closest senders throttled to 10 messages per second non-pre-settled, 100 byte payload mes

Re: [VOTE] Release Qpid Dispatch Router 1.9.0 (RC1)

May I vote DELAY? Could you please not conclude this vote until you receive my vote? I am seeing something that I don't understand with a large multicast test, and I would like to cast my vote only after I have a chance to talk to Ken Giusti about it. Unfortunately I am out today seeing a doctor

Re: [VOTE] Release Qpid Dispatch Router 1.8.0 (RC1)

n Tue, Jun 11, 2019 at 11:58 AM Michael Goulish > wrote: > > > Of course I will not change my vote based on a suggestion ( from me and > > Gordon ) that the failure I am seeing might be caused by a missing > > package. > > > > What I will do is start looking into th

Re: [VOTE] Release Qpid Dispatch Router 1.8.0 (RC1)

Of course I will not change my vote based on a suggestion ( from me and Gordon ) that the failure I am seeing might be caused by a missing package. What I will do is start looking into this to see if that is indeed the case. And then we will make a change that detects and warns about that case. An

Re: [VOTE] Release Qpid Dispatch Router 1.8.0 (RC1)

should detect those & throw a warning so I have some way to fix. On Tue, Jun 11, 2019 at 8:12 AM Michael Goulish wrote: > > * -1* > > > I built against latest released proton ( 0.28.0 ) and I am running on a > new clean-install of Fedora 30. > > I have two test fail

Re: [VOTE] Release Qpid Dispatch Router 1.8.0 (RC1)

* -1* I built against latest released proton ( 0.28.0 ) and I am running on a new clean-install of Fedora 30. I have two test failures. I imagine that the 100% authz failure is because I do not have something installed, but there were no warnings from cmake. Here's the output: 97% tests

Re: [VOTE] Release Qpid Dispatch Router 1.6.0 (RC2)

+1 I used the 1.6.0 rc2 code in my Mercury testing system, and ran 7 Mercury scripts involving different router topologies and numbers of clients and addresses. My machine began to shake and emit smoke and electrical arcs. There were severe space-time distortion effects which caused significant

Re: [VOTE] Release Qpid Dispatch Router 1.5.0 (RC1)

+1 I used this release, with proton 0.26, in my testing system with 3 interior routers, one edge router, 1 receiver, 1000 senders, and a sender getting killed every second. Nothing blew up. On Thu, Dec 20, 2018 at 11:14 AM Robbie Gemmell wrote: > On Wed, 19 Dec 2018 at 22:00, Ganesh Murthy

Re: [VOTE] Release Qpid Dispatch Router 1.4.1 (RC2)

Don't say "I'm very sorry!" Say *"Yee Hah!"* On Wed, Oct 24, 2018 at 6:39 PM Gordon Sim wrote: > On 23/10/18 15:58, Gordon Sim wrote: > > On 23/10/18 15:42, Ganesh Murthy wrote: > >> Hello All, > >> > >> Please cast your vote on this thread to release RC2 as the > >> official Qpid Di

Re: [VOTE] Release Qpid Dispatch Router 1.4.1 (RC2)

vote ++ I ran my message-priority test, showing higher-priority messages having lower latency. Worked! Shippit. On Wed, Oct 24, 2018 at 3:43 PM Ernest Allen wrote: > +1 > > Built router and console > Ran system tests > Started router and console > > > -- Forwarded message - >

Re: [VOTE] Release Qpid Dispatch Router 1.3.0 (RC1)

+2 ( I didn't vote last time. ) I have been using this code in testing for my priority-messaging code, both with my changes applied and without. Nothing weird has happened. On Fri, Aug 10, 2018 at 7:00 AM, Robbie Gemmell wrote: > On 7 August 2018 at 20:07, Ganesh Murthy wrote: > > Hello All,

Re: [VOTE] Release Qpid Dispatch Router 1.1.0 (RC6)

+1 I ran my new latency tests (meant to simulate a real customer usage pattern) on this release as well as the previous release (and corresponding versions of proton.) No problems with the new release. I may be seeing a latency slow-down of a few percent, but that is not alarming & seems likely t

Re: Proposed Feature Removal from Dispatch Router

You mean your rules to be applied exclusively, and in that order, right? i.e. if ( anybody rejected ) { disposition = rejected } *else* if ( anybody accepted ) { disposition = accepted } On Mon, Apr 16, 2018 at 10:24 AM, Ken Giusti wrote: > To reply to my own question: > > IMHO when send

Re: [VOTE] Release Qpid Dispatch Router 1.0.1 (RC1)

+1 did throughput and latency tests and got good results. On Tue, Feb 20, 2018 at 3:27 PM, Ted Ross wrote: > Please vote on this thread to release qpid-dispatch 1.0.1-rc1 as the > official 1.0.1. > > The release can be found here: > > https://dist.apache.org/repos/dist/dev/qpid/dispatch/1.

Re: Qpid Dispatch Router 1.0.0 Release Candidate

I just got done testing the Dispatch 1.0.0-rc1 code by doing a 100-iteration run of my distribution unit test suite. Altogether, 25 tests in there -- including one not yet checked in. zero failures out of 2500 test-runs ---> mick says 'Good to go!" so Good to go! On Wed, Oct 18, 2017

Re: [VOTE] Qpid Dispatch Router 0.6.0 (RC4)

+1 I am using RC4 code now in my testing -- it is behaving happily, as before. - Original Message - This is the vote thread to approve RC4 as the final Dispatch Router 0.6.0. Given that this is a significant release in terms of features and functionality, I think we should get it rel

Re: Invalid signature on qpid releases

/0.34/qpid-cpp-0.34.tar.gz.sha1 should be: d89668759c3d28a2dd762ba607e889da98169754 qpid-cpp-0.34.tar.gz was: d89668759c3d28a2dd762ba607e889da98169754 qpid-cpp-0.34.tar.gz result: good } - Michael Goulish

Re: [VOTE] Release Qpid Proton 0.12.0

+1 Testing done: I used it with all of my performance tests: * point-to-point communication with C and CPP clients. * many CPP senders and receivers intermediated by a router The CPP clients exercise the proton::handler event interface. - Original Message - The artifacts propo

Re: [VOTE] Approve Qpid Dispatch 0.4-rc2 as the final 0.4 release

+1 I've been using it today with proton 0.9. - Original Message - Here's the vote thread for Qpid Dispatch 0.4 (rc2) containing the fix for the build problem Alan found in rc1. http://people.apache.org/~tross/qpid-dispatch-0.4rc2/ Please vote either to approve this candidate as

Re: [VOTE] Approve Qpid Dispatch 0.4-rc1 as the final 0.4 release

Nihil Obstat. Imprimatur. +1 tested with my zillion-link-route-to-a-broker test on F20. - Original Message - For folks who have tested the release candidate for Qpid Dispatch Router at http://people.apache.org/~tross/qpid-dispatch-0.4rc1/ Please vote either to approve

Re: What is x-amqp-to?

- Original Message - > On Tue, 2015-01-27 at 09:44 -0500, Michael Goulish wrote: > > I use this field in my 'topologist' gadget that reads topology > > information from a network of qdrouters. > > > > I only have a connection to router A, but I am

Re: What is x-amqp-to?

I use this field in my 'topologist' gadget that reads topology information from a network of qdrouters. I only have a connection to router A, but I am able to make topo requests of the other routers (after I learn their names) by setting the x-amqp-to field to a value like "amqp:/_topo/0/QDR.B"

Re: [VOTE] Approve Qpid Dispatch 0.3-rc3 as the final 0.3 release

dispatch_0_3 ++ ; // ship it! I am using this candidate with my Topologist client -- sending management queries to get all topology info for the network. And -- it's working! - Original Message - For folks who have tested the release candidate for Qpid Dispatch Router at

Re: Welcome Ernie Allen as a Qpid committer

It's about time! I knew the committal hearing would go well. - Original Message - The Qpid PMC have voted to grant commit rights to Ernie Allen in recognition of his contributions to the project. Welcome Ernie, and thank you for your continued support for Apache Qpid! --Gordon. ---

Re: Proton revision 1627945 barfs on cmake -DCMAKE_BUILD_TYPE=Debug ..

Sorry about that! ...fixed now, by making it static. in future, i will test the default build and the debug build. - Original Message - On 09/29/2014 12:01 PM, Andrew Stitcher wrote: > On Sat, 2014-09-27 at 16:18 +0100, Fraser Adams wrote: >> I just updated to r1627945 and when I do >>

Re: [VOTE] Release Qpid 0.28

+1 Used it in my latency testing. - Original Message - If you favor releasing the 0.28 RC2 bits as 0.28 GA, vote +1. If you have reason to think RC2 is not ready for release, vote -1. Thanks! Justin - To unsubscribe,

Re: dispatch router handles one million addresses

- Original Message - > On 05/05/2014 02:30 PM, Michael Goulish wrote: > > > > > > I just had a successful test of the dispatch router > > handling one million unique addresses. > > > > There were 3 boxes, one for senders, one for receivers, > &

big improvement in memory usage for proton address scale-up

In my original testing for address scale-up with a Proton Messenger based client, I was measuring a memory cost of 115 KB per subscribed address in the client. Now, after Rafi's recent changes, I am seeing a better than 7x improvement, to just under 16 KB per subscribed address. The downside, o

Re: dispatch router handles one million addresses

- > On 05/05/2014 02:30 PM, Michael Goulish wrote: > > > > > > I just had a successful test of the dispatch router > > handling one million unique addresses. > > > > There were 3 boxes, one for senders, one for receivers, > > and one in the middle for a

dispatch router handles one million addresses

I just had a successful test of the dispatch router handling one million unique addresses. There were 3 boxes, one for senders, one for receivers, and one in the middle for a single router. I had 20 senders, each sending to 50,000 unique addresses. These were qpid-messaging based. On the oth

Re: dispatch router perf tests (was Re: [VOTE] Dispatch Router release 0.2)

- Original Message - > On 04/10/2014 10:53 AM, Michael Goulish wrote: > > Also did 40 million-message load-test > > 3 separate boxes: > >* 1 box for 40 senders > >* 1 box for 2-router network > >* 1 box for 40 receivers. > >* mess

Re: [VOTE] Dispatch Router release 0.2

(sorry, am I late? I was abducted. Missing time experience. ) my vote: Nihil Obstat -- Imprimatur ( +1 ) I tested startup of 2-router network, 100 times with no problem Also did 40 million-message load-test 3 separate boxes: * 1 box for 40 senders * 1 box for 2-router network

Heartbleed OpenSSL vuln -- effects on Qpid

The recently-discovered "Heartbleed" security vulnerability in OpenSSL may affect some users of qpid. What is *not* affected: * The qpid c++ broker does not use OpenSSL internally. It uses NSS. What may be affected: * The native python qpid.messaging client. It uses OpenSSL "

Can we remove cluster tools?

We still have a couple of cluster-related python tools on trunk, although there hasn't been any cluster *code* on trunk for some time. They are: ./qpid/tools/src/py/qpid-cluster-store ./qpid/tools/src/py/qpid-cluster Is there any reason they should stay ? In fact, now that I have unleashed the