On 12/16/2010 03:22 PM, Rafael Schloming wrote:
On 12/15/2010 01:14 PM, Gordon Sim wrote:
On 12/15/2010 05:52 PM, Ted Ross wrote:
Keeping it simple, I would like to be able to create a connection with
reconnect enabled, a session, a sender (with a capacity) and be able to
produce up to
On 12/17/2010 10:17 AM, Alan Conway wrote:
On 12/16/2010 03:22 PM, Rafael Schloming wrote:
On 12/15/2010 01:14 PM, Gordon Sim wrote:
On 12/15/2010 05:52 PM, Ted Ross wrote:
Keeping it simple, I would like to be able to create a connection with
reconnect enabled, a session, a sender (with a
On Fri, 17 Dec 2010, Rafael Schloming wrote:
On 12/17/2010 10:17 AM, Alan Conway wrote:
On 12/16/2010 03:22 PM, Rafael Schloming wrote:
On 12/15/2010 01:14 PM, Gordon Sim wrote:
On 12/15/2010 05:52 PM, Ted Ross wrote:
Keeping it simple, I would like to be able to create a connection with
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
On 12/15/2010 01:14 PM, Gordon Sim wrote:
On 12/15/2010 05:52 PM, Ted Ross wrote:
Keeping it simple, I would like to be able to create a connection with
reconnect enabled, a session, a sender (with a capacity) and be able to
produce up to capacity messages with the connection never having been
On Thu, 16 Dec 2010, Rafael Schloming wrote:
On 12/15/2010 01:14 PM, Gordon Sim wrote:
On 12/15/2010 05:52 PM, Ted Ross wrote:
Keeping it simple, I would like to be able to create a connection with
reconnect enabled, a session, a sender (with a capacity) and be able to
produce up to capacity
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.
case. Are
you looking for more than that?
-Chuck
- Daniel Lundin d...@eintr.org wrote:
From: Daniel Lundin d...@eintr.org
To: dev@qpid.apache.org
Sent: Wednesday, December 15, 2010 9:35:32 AM GMT -05:00 US/Canada Eastern
Subject: Re: A criticism of the new messaging API
Agreed
of the new messaging API
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
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
to the initial connection failure
case. Are you looking for more than that?
-Chuck
- Daniel Lundin d...@eintr.org wrote:
From: Daniel Lundin d...@eintr.org
To: dev@qpid.apache.org
Sent: Wednesday, December 15, 2010 9:35:32 AM GMT -05:00 US/Canada
Eastern
Subject: Re: A criticism of the new
On 12/15/2010 05:52 PM, Ted Ross wrote:
Keeping it simple, I would like to be able to create a connection with
reconnect enabled, a session, a sender (with a capacity) and be able to
produce up to capacity messages with the connection never having been
established.
Right, I see that as
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
13 matches
Mail list logo
