+1
The reconnect feature is major improvement over the original API but it
only works *after* a connection has been successfully established. It's
very useful for an application to start without being able to
immediately establish a connection to the broker.
-Ted
On 12/14/2010 06:25 PM, Justin Ross wrote:
I've recently spent some time using the new API. I'm a big fan, but I
have a problem.
My app involves multiple long-lived server components in occasional
communication. In general, the components should start and keep
running whether or not the broker they use to communicate is up.
The API does a good job of recovering from dropped connections, but it
doesn't really support a model where disconnection is normal and
expected. It makes it hard for me to forget about the operational
details of communication. See QPID-2978 and QPID-2937.
To take a strong position (and therefore solicit strong feedback!):
The API has a connection bias, and it's a poor fit for distributed
apps like mine. It would be better to make local queuing primary and
connection state secondary.
Justin
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
