Hi Robert, On Jan 10, 2008, at 17:14 , Robert Greig wrote:
The only reason for the deviation from the AMQP spec was that the official 0-8 spec had limitations that meant we could not achieve full JMS compliance without some changes. We had other users for whom full JMS compliance was critical.
And I can see why that would make sense from a java perspective. However that actively discouraged us in trying out QPID as a broker.
Also - interesting discussion about performance - I'd be interested in better and less biased comparisons, while I'm still aware that msg/ secand latency is not the only interesting kind of performance in a product like this.What are your performance requirements? What client implementations do you need? Are you interested in road testing Qpid? Our recent M2 release incorporates a huge number of changes and improvements.
Currently my primary performance requirements are stability, ease of installation and use, scalability and support. If you win in those areas, I really don't care if I need to buy machines with 4 times as many cores to achieve the same performance. If I have scalability, hardware is VERY cheap!!! Using my developers time on stuff that doesn't work, are difficult to use or to build are far more expensive.
Thanks for your offer on road testing, which I have to decline. We're fairly busy at the moment, and Rabbit actually works for us right now. However it is very important for me in my choice of AMQP that several implementations do exist - and I do find QPID interesting and will definitely try it out in the future.
Michael
smime.p7s
Description: S/MIME cryptographic signature
