Modification to allow for empty message bodies.

[armyofevilrobots]

If we receive a message with no body (and no body_target length), we
should accept the fact and return an empty body rather than throwing
an exception about the frame.

This is a fix (hopefully) for both #30 and #48.

And I waffled on handling the final case, of receiving a payload with a declared zero length and a non-zero length body , but I don't think the logic further up will ever do that, so left it out of the patch for simplicity.

[allardhoeve]

Any news?

[armyofevilrobots]

I don't have commit rights to this repo, so I can only suggest the solution and/or put in the pull request :(
Anybody from celery get a chance to peek at this?

[ask]

Weird, didn't see this pull when releasing the new version, it looks ok to me but I'm not sure about using C++ style comments (//) as we may be compiling with c89.

[allardhoeve]

Can you please release this as 0.6.2?

[armyofevilrobots]

ping^ It would be nice to no longer need to pull from a private repo with the custom built packages.

[mislam55]

@ask could you please release a new version with the fix? I am having the same problem. Thanks!

[LordNoteworthy]

@armyofevilrobots I have celery 3.1.18 (Cipater)
Im still getting this exception:

[2015-10-17 14:54:20,666: ERROR/MainProcess] Task celery.chord_unlock[d08edb6c-ee7b-4171-9e99-4be85e53dbda] raised unexpected: ConnectionError('Bad frame read',)
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/celery/app/trace.py", line 218, in trace_task
R = retval = fun(_args, *_kwargs)
File "/usr/lib/python2.7/dist-packages/celery/app/trace.py", line 398, in protected_call
return self.run(_args, *_kwargs)
File "/usr/lib/python2.7/dist-packages/celery/app/builtins.py", line 95, in unlock_chord
if deps.ready():
File "/usr/lib/python2.7/dist-packages/celery/result.py", line 419, in ready
return all(result.ready() for result in self.results)
File "/usr/lib/python2.7/dist-packages/celery/result.py", line 419, in
return all(result.ready() for result in self.results)
File "/usr/lib/python2.7/dist-packages/celery/result.py", line 205, in ready
return self.state in self.backend.READY_STATES
File "/usr/lib/python2.7/dist-packages/celery/result.py", line 314, in state
return self.backend.get_status(self.id)
File "/usr/lib/python2.7/dist-packages/celery/backends/base.py", line 226, in get_status
return self.get_task_meta(task_id)['status']
File "/usr/lib/python2.7/dist-packages/celery/backends/amqp.py", line 170, in get_task_meta
accept=self.accept, no_ack=False,
File "/usr/lib/python2.7/dist-packages/kombu/entity.py", line 570, in get
message = self.channel.basic_get(queue=self.name, no_ack=no_ack)
File "/usr/local/lib/python2.7/dist-packages/librabbitmq/init.py", line 67, in basic_get
frame = self.connection._basic_get(self.channel_id, queue, no_ack)
ConnectionError: Bad frame read

[derek-virtustream]

Yep, I actually had this bite me the other day when I accidentally pulled from pypi instead of my local patched checkout. I don't think 1.6.1 has this patch, and 1.6.2 isn't out last time I checked.
Sorry, I am actually doing most of my AMQP work in clojure now, not really tracking this repo closely.

[LordNoteworthy]

Thank you so much, I cloned from 1.6 branch and it's OK now :)

[kowalski]

I got struck by the same error :( Does anyone know when it's planned to release a version including this fix ?

[derek-virtustream]

I just finished an open-source project audit/review on my (internal) project that uses librabbitmq, and we're migrating away because of this issue. I realize that this bug may not impact the parent project, but we cannot continue recommending a custom build of librabbitmq for our users.

I am not trying to be one of those ungrateful users that expects free support, nor am I trying to give anybody here a bad time. I understand that you have to pick your battles when working on a project. I merely wanted to suggest that wrapping a 1.6.2 would fix a few issues that are marked as closed, and obviously keep biting people (see the tracked bugs at the top of this one).

I have migrated my codebase to http://rabbitpy.readthedocs.io/en/latest/ and I am quite happy with that library, if anybody else is looking for an alternative to this library.

[alexlopes]

@derek-virtustream since you commented here are you doing well with rabbitpy? Bad experiences?

[derek-virtustream]

Funny that you ask. I just migrated back again to Pika.

We originally moved away from Pika because I found it's blocking connector a bit hokey (and it had some issues when running under Eventlet), and because it's licensing at the time was problematic (MPLV1). We've since dropped Eventlet entirely due to some reliability/stability problems, and now that the license for Pika has moved to a 3-clause BSD, I've just finished porting our code back to that.

I used RabbitPy for a while, but it's limited in the binary formats it supports for outgoing message headers, and we had a hard dependency on an external tool that required incoming boolean values (or it would reject messages). We had to either add that binary type header functionality to RabbitPy, or switch libs again, which is what triggered all of the above^.

[auvipy]

did you tried py-amqp?