.Net Client: ContinuationTimeout for IModel operations

[Dev Imagicle]

Hello,

I need to understand  how ContinuationTimeout works and if it is safe to use a Model instance after a timeout exception is thrown.

I wrote down a sample code where I set a very short ContinuationTimeout in order to get TimeoutExceptions from the model operations. My code catches TimeoutExecption and then makes a new BasicGet request.

model.ContinuationTimeout = TimeSpan.FromMilliseconds(50);

do

{

try

{

var basicGetResult = model.BasicGet("ha_TestQ", true);

if (null != basicGetResult)

{

Log("Message received");

}

}

catch (TimeoutException)

{                                        

Log($"*** TIMEOUT ***");

}

catch (NotSupportedException ex)

{

Log($"ERROR: {ex.Message}");                    

}

Thread.Sleep(5);

} while(true);

Sample output:

Message received

Message received

Message received

Message received

Message received

*** TIMEOUT ***

ERROR: Pipelining of requests forbidden

ERROR: Pipelining of requests forbidden

ERROR: Pipelining of requests forbidden

ERROR: Pipelining of requests forbidden

ERROR: Pipelining of requests forbidden

ERROR: Pipelining of requests forbidden

Message received

Message received

After the TimeoutException the model seems to be busy and the subsequent BasicGet operations get a NotSupportedException with message "Pipelining of requests forbidden".

After a while, BasicGet operations succed and the Model seems to be working well.

My questions are:

1. Is it safe to use the model instance after the first TimeoutException? Or should I close it and instantiate a new one?

2. Is the operation which thrown the exception aborted?

3. When the Model throws NotSupportedException, is it waiting for the previous operation to complete or it requires some time to abort the timed out operation?

Thanks,

Rik

[Michael Klishin]

1. In practice it's not. You cannot know whether subsequent operations will succeed.

2. Yes, it is considered to have failed by the client.

3. It will discard all further server responses. I haven't looked at that area of the code recently but my guess is that unsupported pipelining

    is considered to be an unrecoverable error, therefore the client will quite quickly close its TCP socket. Server logs can clarify this.

I highly recommend using IModel#BasicConsume over BasicGet. BasicGet is polling and BasicConsume is "push", which

largely avoids the problems above wen it comes to message delivery to consumers.

See http://www.rabbitmq.com/confirms.html as well as it covers acknowledgements, a very important topic to consider when IModel#BasicConsume

is adopted :)

[Dev Imagicle]

Hi Michael,

Thank you for your reply. I agree points 1 and 2, but as for point 3, it isn't an unrecoverable exception, and server does not report any error when the clients gets this error, so, I belive I can reuse the channel.

In my test I invoked the BasicGet operation, however the channel may throw the same exception invoking other operations such as ExchangeDeclare, QueueDeclare or QueueBind.

That said, do you suggest to close the channel and reopen a new one even though the exception looks like a recoverable error?

Ric

[Michael Klishin]

There is no single sentence answer. It really depends on what the root cause of the timeout is.

If your connection is experiencing issues but the heartbeat mechanism [1]

hasn't detected it yet, opening a new channel won't work (and will also timeout).

Specifically for basic.get you can probably re-try on the same channel a few times.

1. http://www.rabbitmq.com/heartbeats.html

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-users+unsubscribe@googlegroups.com.
To post to this group, send email to rabbitmq-users@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

MK

Staff Software Engineer, Pivotal/RabbitMQ