txamqp-dev team mailing list archive

[Dan Di Spaltro <dan.dispaltro@xxxxxxxxx>]

Esteve,

Thanks for the response, I hope FluidDB is going great!

On Thu, Sep 10, 2009 at 8:57 AM, Esteve Fernandez
<esteve.fernandez@xxxxxxxxx> wrote:
> Hi Dan,
>
> sorry for the slow reply, FluidDB has taken a lot of our time lately.
>
> On Sat, Sep 5, 2009 at 9:23 PM, Dan Di Spaltro <dan.dispaltro@xxxxxxxxx> wrote:
>> Well I think these two issues aren't as related as I thought.  The
>> headers not in content happens when you:
>>
>> * have a publisher, send to a queue.
>> * disconnect the publisher, make sure the queue is still alive aka, no
>> auto_delete
>> * send to the response queue, which no longer exists, and this happens.
>
> Thanks for finding the steps to trigger the error, that's great! We
> have seen this error occurring intermitently, but couldn't isolate it.
> What you're describing makes a lot of sense, and I think the reason is
> that both the client and the server set the immediate flag to True
> when publishing a message.

Exactly.

>
> When the server sends a response to a client that has disconnected
> from the broker, or just deleted its queue (and thus messages become
> unroutable), the server receives a basic_return_, but it's not
> prepared to process it (as it can only handle incoming calls). There
> are some solutions to that:
>
> - remove the immediate flag from the server's transport, the problem
> is that the server will not know if a response has been delivered
> correctly
> - add an empty dictionary as the headers attribute to the Content
> class no matter what (whether there are headers or not)

What I did is have the mandatory flag only be set if you give the
ThriftAMQPClient a thriftClientName (which is the convention that
Terry started right)?  Again this is all in the thrift stuff.

>
>> I do think the command_invalid thing is related to the aforementioned
>> problem.  But I will have to investigate deeper.
>
> Are you yielding all the deferreds (if using inlineCallbacks)? We
> experienced some errors with frames received and sent out of order.
> The other Dan :-) had the same problem we had some weeks ago:

This is mainly happening while using the thrift portion.  It looks
like the thrift portion doesn't use an outgoing queue, correct?  It
looks like the result of the thrift flush calls sendMessage which
calls basic_publish (which requires multiple frames, and could get
interleaved and fail).  I definitely see the work queue and the
outgoing queue, I am just not sure if I am groking the code correctly.

>
> https://lists.launchpad.net/txamqp-dev/msg00006.html
>
> Cheers.
>

Thanks again!  Hope you are doing great.



-- 
Dan Di Spaltro