On 12/15/2010 11:28 AM, Chuck Rolke wrote:
So, then, what would be the rest of the new client-side behavior?
? Can I queue, say, a million messages locally?
? Can I manipulate the local queue to give undelivered messages some priority?
? Will there be alternate connections to try?
? Are the queued messages persistent with a local on-disk store?
Are you trying to be a "broker" and not a "client"?
Maybe you can refactor your app to have a client and a broker on the local
system. Now your client can be connected to localhost while the broker does
what brokers do.
I think client side queuing (even including things like durability and
priority) is a valid use case that is distinct from a collocated broker.
A broker is by definition an intermediary, and when a broker is involved
there are three independent entities, the producer, the broker, and the
consumer.
With a client that does local queuing (i.e. embeds a broker), there is a
forced shared fate between the client application and the broker. There
is no such thing as the broker continuing on without the client or vice
versa, and that can simplify not only deployment, but coding as well.
The distinction between sync and async can essentially vanish since the
application and the queuing components are in the same process and can
assume perfect communication.
Granted you can probably get a fair way towards addressing the local
queuing use case with a collocated broker, but it's not necessarily an
ideal fit.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
