Please publish amqp_client 3.13.x

[ono]

Is your feature request related to a problem? Please describe.

amqp_client hasn't been updated since 3.12.14.

https://hex.pm/packages/amqp_client

Describe the solution you'd like

Could you release 3.13.3 for the library, please?

rabbit_common seems to be up to date: https://hex.pm/packages/rabbit_common

Describe alternatives you've considered

No response

Additional context

No response

[michaelklishin]

We don't know we would be able to do that due to very significant infrastructure changes our team has to make on top of working on 4.x. We have to move release infrastructure that includes this client.

However, there are good news: you don't need Erlang AMQP 0-9-1 client 3.13.x to use it with RabbitMQ 3.13.x. In fact, the client hasn't changed in any meaningful way and it still supports RabbitMQ versions from 2.0 to 3.13 (obviously older versions can differ in behavior, e.g. queue.delete won't be idempotent with some really old ones).

[lucacorti]

I'ts great to know 3.12.4 is compatible with rabbitmq server 3.13. The issue I'm facing with this is on the client side. rabbit_common 3.12.14, that amqp_client 3.12.14 depends on, does not build on OTP 27, so it prevents upgrading erlang for client applications depending on amqp_client.

[ono]

@lucacorti I have shared a workaround here to compile with OTP 27.

Of course, it is not ideal and straightforward. Many users would get confused 😢 But I hope it helps.

[mkuratczyk]

I'm not sure if that the problem or a part of the problem, but v3.13.x is now compatible with OTP27. It's still not supported to run RabbitMQ on OTP27 (or at least highly discouraged due to the performance regressions) but it can be compiled.

#11623

[lucacorti]

@mkuratczyk Issues are popping up mostly because the amqp library is used as a dependency in third party clients that depend on amqp_client and indirectly on rabbit_common. Is amqp_client also not supported on OTP 27 or is it just RabbitMQ?

[mkuratczyk]

We don't have a separate separate policy for the client but starting with the next version, 3.13.x should compile using OTP27 (since the PR I mentioned above was merged after 3.13.4 was released) and the client will most likely work just fine.

The regressions we see are mostly around Erlang processes that deal with large amounts of data (and therefore memory), especially in the range of 65-100B. I haven't tried to benchmark the client for such scenario, but even if prone to this issue, it'd probably require a sustained high throughput of such messages, so many client users wouldn't notice this anyway.