We're using it in several enterprise class projects over several product lines. Unfortunately we primarily deploy only on Windows platforms, which are treated as something of a second class citizen in the current (*nix dominated) developer community. Our biggest problems were broker fault tolerance and the ability to run the brokers as a Windows service (we submitted a patch to enable this feature.) While the C++ client does contain a rudimentary failover capability, it does not have automatic failover recovery when a failed broker comes back online, so service "splits" are possible (and common) in a long running system with less than perfect connectivity or incomplete uptime (active clients switch to the second broker and stay there, new clients connect to the first broker and don't know about each other.) Because of the way Boost was used to hide the internal implementation, we ended up having to write a complete wrapper to implement application transparent broker recovery. In the Linux broker deployments this problem does not exist due to good support for federation and clustering, but these features are built on OpenAIS, which is a *nix only solution and implemented in such a way as to be very difficult to port to Windows. The documentation is poor and incomplete, but slowly getting better. All that said, it works very well, and I would probably pick it again had I an opportunity to choose again knowing what I know now...
Kerry On Mon, Oct 24, 2011 at 12:58 PM, Vijay Devadhar <[email protected]>wrote: > Hi QPID users, > > Are you using QPID in production? What sort of lessons have you learnt > with use of > apache QPID in production? We are evaluating QPID and would love to learn > from your > experiences. Please share if you can spare a few minutes. > > Thanks, > Vijay >
