Art, inline - > Gary - remember the idea of "feedback flow control"? I still think that is > a better approach to PFC in spite of being told that ActiveMQ doesn't want > large changes of that nature. And how about approaches to solving temporary > destination race conditions across a network of brokers? I know it can be > solved and am working now toward that end. > That is all good. Everything can be solved. The difficulty is satisfying all of the usecases embodied in 4k of tests.
> Gary - I ask for information showing what problem needs to be solved and you > reply, "you can look around yourself," and give a reference to one benchmark > that appears to cost $1800. That's not a helpful, nor a convincing, > argument. I am getting a strong vibe from you, and I truly hope you find a > next step that satisfies you. > Please explain the vibe thing? It costs nothing to read the documentation[1] around specjms and the results are detailed and public. Try maxing out a disk with activemq or try and saturate a network in a throughput test. When I wrote "you will have to do your own investigation to be sure" this is the sort of thing I am referring to. When I mention the scalability limitations, this is in no way an attack on activemq, it is a reflection of reality based on my experience of pushing activemq 5.x to the max in many dimensions. Granted, many users don't need any more scalability than 5.x currently has and that is great. However there are many other use cases where being able to max out hardware is a necessity. In any event, this is a purely technical discussion. Until there is a release of activemq6 folks have nothing concrete to validate. [1] https://www.spec.org/jms2007/docs/DesignDocument.html
