[
https://issues.apache.org/jira/browse/AMQ-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13458617#comment-13458617
]
Claus Ibsen commented on AMQ-3931:
----------------------------------
See also this ticket. KahaDB has a special option for overflow to disk for TX
https://issues.apache.org/jira/browse/AMQ-3374
> Memory problems with large transactions
> ---------------------------------------
>
> Key: AMQ-3931
> URL: https://issues.apache.org/jira/browse/AMQ-3931
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.6.0
> Environment: 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 attached
> Reporter: Robert Voliva
> Assignee: Claus Ibsen
> Fix For: 5.7.0
>
> Attachments: activemq_log_output.txt, gbsmq.xml
>
>
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
