-
Notifications
You must be signed in to change notification settings - Fork 581
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
QueueDeclare - when a TimeoutException occurs, subsequent commands cause a series of NotSupportedException: pipelining of requests forbidden #402
Comments
Thank you for your time. Team RabbitMQ uses GitHub issues for specific actionable items engineers can work on. GitHub issues are not used for questions, investigations, root cause analysis, discussions of potential issues, etc (as defined by this team). We get at least a dozen of questions through various venues every single day, often light on details. Please post this to rabbitmq-users. Thank you. |
In most cases making sure the channel is closed and opening a new one will be an acceptable workaround. Network slowdowns and similar conditions that will trigger a continuation timeout in practice are also likely kick off connection recovery which has other limitations for publishers. |
Hi, i'm facing the same problem. The only solution is to create a new IModel? What if the timeout occurs when publishing a message or confirming a message? Do we have to close the channel and create it again? Why an error in one operation should affect other operations? This behaviour should be documented because as a user of this library I don't expect this strange behaviour |
You might consider creating multiple channels: for topology operations and for publishing. The same was done in EasyNetQ (EasyNetQ/EasyNetQ#1063) years ago, and I didn't hear any complaints about that. |
Hi, thanks for your answer. In my case I already have different channels for consumig and publishing. In my publishing client I don't define queues. My question is if this exception can occur when sending messages or confirming them, or if it only happens in topology operations. If this happens only in topology operations it is safe to dispose the channel and create a new one? I don't use autorecovery My client consumer application lifecycle is: In a loop:
Regards |
@pabermod in this case it would be great for you to open a new issue in this repo, with code to reproduce this issue. |
Description: In a production environment with 12 Windows clients and one RabbitMQ server, occasionally a TimeoutException will occur. The TimeoutException is followed by several System.NotSupportedExceptions.
The System.NotSupportedException message is "Pipelining of requests forbidden". It seems that the TimeoutException doesn't clear the channel of the current command. The subsequent
commands that are sent through the channel end up with the pipelining error.
RabbitMQ version: 3.6.15
Erlang version: 20.1
RabbitMQ plugin information via
rabbitmq-plugins list
:amqp_client 3.6.15
cowboy 1.0.4
cowlib 1.0.2
rabbitmq_management 3.6.15
rabbitmq_management_agent 3.6.15
rabbitmq_web_dispatch 3.6.15
Client library version (for all libraries used): 5.0.1
Operating system, version, and patch level: Windows Server 2008 R2 Datacenter SP1 and
Windows 10 [Version 10.0.16299.125]. It is reproducible on both versions.
Output of rabbitmqctl status:
This is the stack trace of the TimeoutException followed by a Pipelining error:
The text was updated successfully, but these errors were encountered: