'NoneType' object has no attribute 'body_size'

[hannuvisti]

My start_consuming loop has started crashing to this occasionally. I get the above error message and immediately afterwards an exception BodyTooLongError. The program works most of the time and crashes to this about once a day. The program in question opens a channel, connects to an exchange and subscribes to 2-3 routing keys.

This is Pika 0.10.0 on Ubuntu 16.04.

'NoneType' object has no attribute 'body_size'

Traceback (most recent call last):
  File "./foo.py", line 585, in <module>
    channel.start_consuming()
  File "/usr/local/lib/python2.7/dist-packages/pika/adapters/blocking_connection.py", line 1681, in start_consuming
    self.connection.process_data_events(time_limit=None)
  File "/usr/local/lib/python2.7/dist-packages/pika/adapters/blocking_connection.py", line 647, in process_data_events
    self._flush_output(common_terminator)
  File "/usr/local/lib/python2.7/dist-packages/pika/adapters/blocking_connection.py", line 410, in _flush_output
    self._impl.ioloop.poll()
  File "/usr/local/lib/python2.7/dist-packages/pika/adapters/select_connection.py", line 602, in poll
    self._process_fd_events(fd_event_map, write_only)
  File "/usr/local/lib/python2.7/dist-packages/pika/adapters/select_connection.py", line 443, in _process_fd_events
    handler(fileno, events, write_only=write_only)
  File "/usr/local/lib/python2.7/dist-packages/pika/adapters/base_connection.py", line 364, in _handle_events
    self._handle_read()
  File "/usr/local/lib/python2.7/dist-packages/pika/adapters/base_connection.py", line 415, in _handle_read
    self._on_data_available(data)
  File "/usr/local/lib/python2.7/dist-packages/pika/connection.py", line 1347, in _on_data_available
    self._process_frame(frame_value)
  File "/usr/local/lib/python2.7/dist-packages/pika/connection.py", line 1427, in _process_frame
    self._deliver_frame_to_channel(frame_value)
  File "/usr/local/lib/python2.7/dist-packages/pika/connection.py", line 1028, in _deliver_frame_to_channel
    return self._channels[value.channel_number]._handle_content_frame(value)
  File "/usr/local/lib/python2.7/dist-packages/pika/channel.py", line 890, in _handle_content_frame
    response = self.frame_dispatcher.process(frame_value)
  File "/usr/local/lib/python2.7/dist-packages/pika/channel.py", line 1216, in process
    return self._handle_body_frame(frame_value)
  File "/usr/local/lib/python2.7/dist-packages/pika/channel.py", line 1246, in _handle_body_frame
    self._header_frame.body_size)
pika.exceptions.BodyTooLongError: (180, 90)

[lukebakken]

I get the above error message

Where / how do you get that error message?

Could you please provide more details on how to reproduce this? Providing code that reproduces this issue reliably would help us diagnose and fix this issue quickly.

[hannuvisti]

Can I email you instead of posting the code here?

The code may be unusable without the publisher code, but most errors have occurred overnight when there is no activity on any of the channels, so it might be worthwhile just running the receiver and seeing what happens.

[lukebakken]

What would be most helpful is a complete set of code that reproduces the issue - both sending and receiving. People have limited time to spend on Pika support so anything that can be done to shorten the diagnosis process is greatly appreciated.

[hannuvisti]

I'll see what I can do but this will be next week. I need to sanitise the code first to remove any proprietary elements while keeping it still fully functional. This is also a part of a larger production system, with an external configuration server containing routing keys to be listened to, and I need to import this part to publisher and subscriber with static data.

I will let you know if I manage to actually do all that.

I understand your resources are limited, thanks for replying so quickly. In my particular case, I have built a mechanism to restart the listener as soon as it exits for any reason. It will do. I just wanted to report this as I use Pika a lot and this is the only time I have encountered any stability issues.

[lukebakken]

Thanks! No hurry at all. I'll see what I can figure out on my end as well when I have time.

[vitaly-krugl]

@lukebakken, two additional items that would help greatly is if the user provided both of the following:

1. Complete DEBUG-level pika logs leading up to and including the failure.
2. WireShark AMQP log of the problem

[vitaly-krugl]

Also, a very common problem is when users use the same pika connection from more than one thread. Sometimes they are not even aware that their app is accessing the same connection (or channels from the same connection instance) from more than one thread.

[hannuvisti]

This may actually be a threading issue. I thought each thread had its own Pika connection but it appears one of them is sharing with the main thread.

Feel free to close this, the explanation seems plausible.

[vitaly-krugl]

Thanks for the update @hannuvisti !