activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Voliva (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMQ-3931) Memory problems with large transactions
Date Tue, 17 Jul 2012 20:30:35 GMT

    [ https://issues.apache.org/jira/browse/AMQ-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13416568#comment-13416568
] 

Robert Voliva commented on AMQ-3931:
------------------------------------

Thanks Fengming, I went through all that documentation and did make some changes.  What we're
still seeing is that when producing even 100,000 messages in a single transaction, they all
seem to be kept in memory until (presumably) the transaction is committed.  I have verified
that producing the same number of messages in multiple transactions, it behaves as expected,
and doesn't kill the broker.  It is able to GC periodically and things hum along great.

This seems to all be related to producing that many messages in one transaction.
                
> 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
>         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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message