Closed thedrow closed 5 years ago
Yes, it's expecting a longstr. There's no reason why the username and password could also be a shortstr.
@thedrow short strings are supported in attribute tables, just were not expected by the authentication mechanism. https://github.com/thedrow/rabbitmq-server/commit/5e97011b9869a0ff579290df6e3bf8ab315b5c6e looks reasonable. Please submit a PR?
Yes, I'm working on it. I have to stress I don't know any Erlang at all.
No worries. You thinking is on point, we are fine with tweaking the small details on your behalf.
Can you please post a script that we can use to reproduce?
You can close that commit I linked to.
Run pip install tox tox-docker
and then tox -e 3.7-integration-rabbitmq -- -k test_connect
.
I tried the following:
hypothesis
tox -e 3.7-integration-rabbitmq -- -k test_connect
It outputs
collecting ...
t/integration/test_integration.py::test_connection.test_connect ✓ 10% █
t/integration/test_integration.py::test_connection.test_connect_no_capabilities ✓ 20% ██
t/integration/test_integration.py::test_connection.test_connect_missing_capabilities ✓ 30% ███
t/integration/test_integration.py::test_connection.test_connection_close ✓ 40% ████
t/integration/test_integration.py::test_connection.test_connection_closed_by_broker ✓ 50% █████
t/integration/test_integration.py::test_channel.test_connection_methods[method0-_on_blocked] ✓ 60% ██████
t/integration/test_integration.py::test_channel.test_connection_methods[method1-_on_unblocked] ✓ 70% ███████
t/integration/test_integration.py::test_channel.test_connection_methods[method2-_on_secure] ✓ 80% ████████
t/integration/test_integration.py::test_channel.test_connection_methods[method3-_on_close_ok] ✓ 90% █████████
t/integration/test_rmq.py::test_connect ✓ 100% ██████████
Results (0.34s):
10 passed
31 deselected
3.7-integration-rabbitmq docker: remove 'ed1914501a' (forced)
3.7-integration-rabbitmq run-test-post: commands[0] | ./rabbitmq_logs.sh
ERROR: InvocationError for command could not find executable './rabbitmq_logs.sh'
___________________________________________________________________________________________________________________________________ summary ____________________________________________________________________________________________________________________________________
ERROR: 3.7-integration-rabbitmq: commands failed
What I am not sure about is why do the tests pass? Do they already use the patched version? Also, is there a way to prevent the container from being force removed so that I can inspect the logs manually?
I'd be happy to run the tests without Docker against a local RabbitMQ node, in fact, that would be the easiest way to compare e.g. 3.7.13 with the patched version. Is there a document that describes how to do that?
Not sure what happened to my comment :( Running tests locally on 3.7 and 2.7 with Tox suggests that they also pass with a 3.7.13 node running locally.
So I suspect there is no failing test case on that branch just yet? Any chance I can run a basic script that assumes that the library is on PYTHONPATH
?
#!/usr/bin/env python3
from amqp.connection import Connection
c = Connection()
c.connect()
c.close()
also succeeds. Getting closer.
I tried https://github.com/celery/py-amqp/commit/6c627986c312cdb7575ab0616a63f56cf40c0be7 and discovered that it assumes that s
type designator is implemented exact as in the spec. Sadly that's not the case.
From https://www.rabbitmq.com/amqp-0-9-1-errata.html:
A1, A2: Notice how the types CONFLICT here. In Qpid and Rabbit,
's' means a signed 16-bit integer; in 0-9-1, it means a
short string.
So there are no short strings in RabbitMQ?
There are. When in doubt, please consult Java client, .NET client, Ruby's amq-protocol and Pika. With all respect to the Rust client mentioned in one of the issues, it is not a reference or even a mature implementation.
Both don't implement shortstr inside tables...
FWIW this is the first time I recall someone bring this up since 2010 or so :)
I'm trying to improve the existing implementation. I'll take the errata in mind. I think we should introduce a symbol for shortstr somehow. Shell I open an issue about it?
@thedrow I don't know if Qpid has implemented it since then but I don't see a reason to have short strings and long strings separately. They are not encoded meaningfully different on the wire. I kind of doubt the team would bother updating a half a dozen client libraries we maintain just to implement this feature. Unfortunately the spec has ambiguities and unfortunate decisions. We've corrected some problems that keep coming up. This one is not it.
Idk, it saves some bytes on the wire :) What about integers? It seems like the clients you wrote don't use all the types. Why is that?
If we encode strings as S
and short strings as, say, s
(or W
or whatever), how does that save any bytes on the wire?
@thedrow this is not a discussion venue. Please post your questions to the mailing list.
To answer this last one: not all types make sense for all clients. Dynamically typed languages generally don't have a way to represent unsigned types. Some statically typed languages don't have the same fine grained types as, say, C. So the types Java client does implement is what Java can represent and hopefully some other types that it is most likely to deal with.
See https://github.com/streadway/amqp/issues/391 where a user of a client that's capable of representing more types than most decided to basically not bother. The benefit is not worth the revision of every reasonably popular client. In case someone cares enough they can review every client we have a tutorial for and document the gaps with some recommendations. In some cases it won't be an easy decisions, e.g. does a JavaScript user ever care about 32-bit floats?
According to the 4.2.1 in the spec shortstr is supported inside tables. However, when I add the following code to the table serialization: https://github.com/celery/py-amqp/pull/264/commits/6c627986c312cdb7575ab0616a63f56cf40c0be7
Authentication fails with the following message:
This is what I'm serializing/deserializing:
With str everything works normally. Other AMQP clients have disabled it from the get go.
I'm positive this is a bug in RabbitMQ.