You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Justin Ross <jr...@redhat.com> on 2010/12/15 00:25:11 UTC
A criticism of the new messaging API
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-subscribe@qpid.apache.org
Re: A criticism of the new messaging API
Posted by Gordon Sim <gs...@redhat.com>.
On 12/15/2010 02:31 PM, Ted Ross wrote:
> The reconnect feature is major improvement over the original API but it
> only works *after* a connection has been successfully established.
That's not quite true, though I know what you mean.
The issue is that there are operations that will fail if not connected,
e.g. creation of senders or receivers. These operations may not succeed
- there may be no such queue for example when a connection is finally
established, or you may not have sufficient permission to publish to it
or receive from it.
I think the use case here is really one of more general asynchronous
usage. In that context I do think it is worth examining further. A key
part of that would be how error conditions are signalled.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: A criticism of the new messaging API
Posted by Daniel Lundin <dl...@eintr.org>.
Agreed. Initial failure shouldn't be a special case. It's just a
regular failure.
/d
On Wed, Dec 15, 2010 at 3:31 PM, Ted Ross <tr...@redhat.com> wrote:
> +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:dev-subscribe@qpid.apache.org
>>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: A criticism of the new messaging API
Posted by Ted Ross <tr...@redhat.com>.
+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:dev-subscribe@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org