Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Not A Problem
-
5.6.0
-
None
-
OS: RHEL 5.5
Startup options: -Xmx2G -Xms2G -XX:MaxPermSize=512M -Dorg.apache.activemq.UseDedicatedTaskRunner=true -Djava.util.logging.config.file=logging.properties -Dcom.sun.management.jmxremote -Dactivemq.classpath=/opt/activemq/conf; -Dactivemq.home=/opt/activemq -Dactivemq.base=/opt/activemq -Dactivemq.conf=/opt/activemq/conf -Dactivemq.data=/opt/activemq/data -Djava.io.tmpdir=/opt/activemq/tmp
Config file: activemq.xml attachedOS: RHEL 5.5 Startup options: -Xmx2G -Xms2G -XX:MaxPermSize=512M -Dorg.apache.activemq.UseDedicatedTaskRunner=true -Djava.util.logging.config.file=logging.properties -Dcom.sun.management.jmxremote -Dactivemq.classpath=/opt/activemq/conf; -Dactivemq.home=/opt/activemq -Dactivemq.base=/opt/activemq -Dactivemq.conf=/opt/activemq/conf -Dactivemq.data=/opt/activemq/data -Djava.io.tmpdir=/opt/activemq/tmp Config file: activemq.xml attached
Description
When running a single transaction that produces 300,000 text messages, ActiveMQ runs into all sorts of memory problems. The log output is attached. We were using a simple Java JMS client class to produce the 300,000 messages in a single transaction. Each message's text payload was a random string of 10,000 bytes.
This is a production scenario that we have that's killing our broker. We isolated it down to its most basic pieces to try to test where the breakdown was occuring, which led us to this.