On Dec 17, 2007, at 10:33 PM, James Mansion wrote:
Hellweek wrote:
When performing the test with C# consumers the CPP producers fail.
The CPP consumers do not fail with C# producers.
Perhaps the server should send one flow control message and require
that the client
ACK it specifically before sending another, to avoid spamming
clients that don't
understand the optional facility.
Well, we don't spam clients who don't understand flow control
The original poster suggested that there were problems with the
broker as well:
1. ... a slow client can bring the producer down and in some cases
can bring the broker down. A miss-behaved producer or client should
never ever take the broker down
2. A Producer that producers more then 200 messages per sec locks up
the Broker when the Broker has only one client connected.
(me: 200/sec??? That' doesn't seem much to me, unless they are very
large indeed. One should look to saturate GBit ethernet on a
smallish box and scale up to use a big slug of 10GBit too. Like
this http://www.29west.com/products/lbm/messaging-performance-
lbm.php (OK, that might be a bit specialised). Or http://www.openamq.org/performance.html.)
ActiveMQ performance is extremely good - its also been in the field
along time so its capable of handling a lot of edge cases.
Much of the post was about symptoms which suggest a buggy producer
implementation: but is it really as simple as that?
I think so - as the Java client works as expected.
James
cheers,
Rob
http://open.iona.com/ -Enterprise Open Integration
http://rajdavies.blogspot.com/
