BlockingChannel.queue_declare hanging on non-string queue parameters
See original GitHub issueUnder Python 3.6.4 and Pika 0.11.2, the BlockingChannel.queue_declare
method hangs when setting its queue
parameter to a value that is not of str
type (e.g., int
, bool
, list
, dict
, tuple
, NoneType
).
Input:
$ python3 <<EOF
import pika
with pika.BlockingConnection() as connection:
channel = connection.channel()
channel.queue_declare(queue=[1, 2, 3])
EOF
Issue Analytics
- State:
- Created 6 years ago
- Comments:10 (10 by maintainers)
Top Results From Across the Web
BlockingConnection — pika 1.2.1 documentation
To prevent recursion/reentrancy, the blocking connection and channel implementations queue asynchronously-delivered events received in nested context (e.g., ...
Read more >Blocking connection hanging on basic_consume when using ...
I've created a little library to bind some processing function to a rabbitMQ queue and then perform that processing once something is placed ......
Read more >RabbitMQ tutorial - Work Queues
In this one we'll create a Work Queue that will be used to distribute ... Change the class name and add command line...
Read more >rabbitmq client hangs while trying to declare queue
Declaration of queues is currently in my postconstruct of beans. I can't speak to the hang but you should NEVER interact with the...
Read more >Channel (RabbitMQ Java Client 4.12.0 API)
Map) but sets nowait parameter to true and returns void (as there will be no response from the server). AMQP.Queue.DeclareOk, queueDeclare(). Actively declare...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@lukebakken: Okay, so this now makes sense - the
finally:
block in the originalBlockingConnection
example andpika.BlockingConnection()
as context manager in this new example will deadlock (trying to auto-close the channel) on the erroneously blocked channel that resulted from the assertion error and prevent the exception from bubbling up.And although the asynchronous connection example doesn’t hang since it simply doesn’t do anything that interferes with the processing of that exception, the channel state would still be messed up - in particular, I expect
self._blocking
to remain set and the redundant callbacks to continue to be registered.