On 25/02/16 16:22, Alexander N. Moibenko wrote:
Thanks for reply Gordon, I am considering this issue as a bug. This is what happened to me: I selected and use AMQP because it was announced as a reliable way of communication without any restriction on the message size. Well, there may be a restriction but I could not find it in documentation. Indeed there should be no restriction as it uses TCP/IP and I believe it fragments and defragments messages inside. So all worked for me well before I was requested by site security to stop using unsecured transfer. I configured GSSAPI authentication, tested it (not thinking about message size limitations) and installed in production. And here it began. Now I had to back out to anonymous and ask site security for exemption.
Another workaround is simply to set the sasl_max_ssf to 0. That way you still use kerberos for authentication, but don't encrypt the messages.
I looked at AMQP 0.34 and still see a lot of hadrcoded 65535 all over the code.
In some places that will be appropriate as the protocol (v 0-10) has a fixed limit.
The sasl max buffer size is a different case though. The issue there is less that it is hardcoded and more that I think it my be an invalid value.
Can this issue be addressed in development? I probably can change all these hardcoded values and recompile, but it will require a lot of unexpected effort and still will be not good to run in production.
Yes, I agree it is a bug and should be fixed. If you can test whether reducing that value fixes your issue, that would speed up resolution. In any case, raise a JIRA for this and I'll try to have a look at it asap.
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
