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:dev-subscr...@qpid.apache.org
