Re: Producer Flow Control active but server still facing OOM issues

Hi Tim, Thanks for the follow up. I haven't touch this issue for a week. I will need to study this further. I will get back to you once I'm done. For now, this: > How big of a heap did you try? 4G > Are you able to share the test driver you were using so someone could try to reproduce and then

Re: Producer Flow Control active but server still facing OOM issues

I just read your last response more closely and realized you said you had tried larger -Xmx values with no difference. How big of a heap did you try? Are you able to share the test driver you were using so someone could try to reproduce and then analyze the OOM behavior you were seeing? If not,

Re: Producer Flow Control active but server still facing OOM issues

512 MB isn't very much memory for an ActiveMQ broker. I'm used to seeing more like 2 GB, 4 GB, sometimes more when people describe how big their heap is. If 512 MB works with Postgres, and you're good with using Postgres, that's fine, but the general consensus is that KahaDB has had more testing

Re: Producer Flow Control active but server still facing OOM issues

Hi Tim, Thanks for your time. I managed to make the Broker very stable after moving away from KahaDB and Limiting the number of active connections at one time. This is what I think happened. * KahaDB competes with the broker for JVM resources. It does not matter how much of memory I reserve with

Re: Producer Flow Control active but server still facing OOM issues

This is only a partial answer (I'll try to get time this weekend to answer the parts I don't have time for now), but I want to get you something to start with. On Feb 15, 2018 5:03 AM, "Thiago Veronezi" wrote: Hi, ActiveMQ community, I'm actively working on a documentation

Producer Flow Control active but server still facing OOM issues

Hi, ActiveMQ community, I'm actively working on a documentation for "out of memory" protection on ActiveMQ. Recently I was working on this POC project where I stressed a default broker configuration with 1.000.000 messages with 20KB payload each, where each message took 1 second to be consumed.