You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After upgrading from version 1.0 to 1.4, I saw that my app was going from 100mo heap to more than 1Go ! (and crashing because the limit I set was xmx 1024). The version upgrade was really the only change in my app.
I found out that the AcknowledgeMode.NONE was the root cause of the heap size grow.
I tracked down the issue and found it was introduced in version 1.2.
=>The ack mode was changed from AUTO to NONE.
It sounds like a spring-rabbit or spring-amqp issue but it impact a lot the camel-spring-amqp component. Maybe it would be safer to change the default ack mode to AUTO while the bug is not fixed on spring side.
If you want to reproduce, just checkout the 1.1.0 tag and change the ack mode from AUTO to NONE, then look at the heap size growing in visualvm when sending a million message.
Regards.
The pull request #25 provides a workaround.
The text was updated successfully, but these errors were encountered:
You are correct - and while pull request #25 was merged in, we should still change AcknowledgeMode.AUTO to be the default. I'm keeping this issue open until we do so.
After upgrading from version 1.0 to 1.4, I saw that my app was going from 100mo heap to more than 1Go ! (and crashing because the limit I set was xmx 1024). The version upgrade was really the only change in my app.
I found out that the AcknowledgeMode.NONE was the root cause of the heap size grow.
I tracked down the issue and found it was introduced in version 1.2.
=>The ack mode was changed from AUTO to NONE.
It sounds like a spring-rabbit or spring-amqp issue but it impact a lot the camel-spring-amqp component. Maybe it would be safer to change the default ack mode to AUTO while the bug is not fixed on spring side.
If you want to reproduce, just checkout the 1.1.0 tag and change the ack mode from AUTO to NONE, then look at the heap size growing in visualvm when sending a million message.
Regards.
The pull request #25 provides a workaround.
The text was updated successfully, but these errors were encountered: