On Thu, Jun 26, 2008 at 10:23 PM, Rafael Schloming <[EMAIL PROTECTED]> 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
