[rabbitmq-discuss] [help] [beginner] what are the semantics of channels? (was testing with pika)

[Alistair Bayley]

On 29 February 2012 23:28, Simon MacMullen <simon at rabbitmq.com> wrote:
>>
>> Pika (is this better posted to the pika mailing list?):
> Maybe?

Well, the pika mailing list looks a bit dead, so I was hoping I'd get
better mileage here. The pika FAQ recommends posting here.


>> 4.  why doesn't basic_ack do what I expect?
> That sounds like somehow the ack is malformed somehow (wrong ack tag?) and

Turns out it was because I had enabled transactions on the channel,
and was not commiting the ack. My mistake.


> The server is not swallowing the message without responding; it's stopped
> accepting messages altogether, and will (eventually) send confirms for
> everything it's accepted. However, in this scenario you're presumably
> hammering the server with messages, and in that case there can be lots of
> messages waiting in the OS TCP buffers - RabbitMQ hasn't seen them at all.
>
> It's not clear what else RabbitMQ could do in this situation - for
> guaranteed delivery you need to treat the message as the producer's
> responsibility until you see the confirm or tx.commit-ok.

A nack or reject would be nice; then the client can decide to retry
later or discard. I can see that I should implement a timeout on the
client.

I've done some more testing with the server in this situation as best
I can; I've simulated it by setting the high-water-mark to 0. The test
creates two channels, and two queues:
 - in channel 1 we publish a message to queue 2, and then get from
queue 1 (queue 1 is always empty)
 - in channel 2 we get from queue 2

When the server has breached the high-water-mark, both gets wait
indefinitely for a response from the server. Is this what I should
expect? I was hoping that consumer channels would still be responsive,
but it looks like the entire connection is blocked.

Some other variations:
 - no publish i.e. all we do is get from empty queues: the server is responsive.
 - publish on channel 1 to queue 2, get in channel 2 from queue 2
(i.e. no get in channel 1, so channel 1 is pure producer, channel 2 is
pure consumer): hangs/waits after Basic.Get.
 - 3rd channel that gets from empty queue 3: hangs/waits after Basic.Get.
 - a separate connection that gets from queue 2 is ok; it receives a
Basic.GetEmpty.


Also, when the client shuts down, the channels are closed on the
client (channel close callback is invoked with code 200), but they
remain on the server, causing a resource leak. From tcpdump I can see
the client sending Channel.Close frames, but it does not get back
Channel.Close-Ok from the server, which is what happens in the normal
case (where the server is not throttling clients).

Alistair