qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aidan Skinner" <ai...@apache.org>
Subject Re: Producer flow control
Date Fri, 27 Jun 2008 08:51:58 GMT
On Thu, Jun 26, 2008 at 10:23 PM, Rafael Schloming <rafaels@redhat.com> wrote:

> Why throw an exception by default? I'd think you would want a configurable
> timeout, i.e. by default you block for n seconds, and when the time is up
> throw an exception.

JMS API compatability more than anything else, there is no send(int) :/

Having a configurable timeout rather than blocking is a good idea
though, I'll amend the design so that you specify a system property
with the timeout, if that's not default (0) then it blocks for N
milliseconds and then throws, or -1 to block forever?

> What should the client expect when an exception is thrown, did the message
> go through or not?

That the message did not go through, I'll document this.

> Why stop the producer *after* putting the message on the queue? Is it really
> that expensive to check whether the queue is too large *before* putting the
> message on? In general this seems backwards, e.g. if a client were to
> publish a single message to a queue that is full, and then move on to other
> unfull queues, you could end up blocking the client for no reason.

It's not really because of the cost of the check, it's because there's
no PublishOK in 0-8/0-9 to signal success outside of a transaction.

> Are the limits going to be byte based, message based, or both?

Both

> How do you intend to block the producer?

Check if the connection is flowed, if it is then wait on a flow
semaphore that gets signaled when the connection is reflowed.

- Aidan
-- 
Apache Qpid - World Domination through Advanced Message Queueing
http://cwiki.apache.org/qpid

Mime
View raw message