You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Rob Davies (JIRA)" <ji...@apache.org> on 2007/11/22 08:03:27 UTC
[jira] Resolved: (AMQ-1148) Fast producer, slow consumer hangs
after a few messages when using VMPendingSubscriberMessageStoragePolicy
[ https://issues.apache.org/activemq/browse/AMQ-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rob Davies resolved AMQ-1148.
-----------------------------
Resolution: Fixed
Just test this again - and it does hang. However - the default prefetch size is about 32k for a topic - and given the size of the messages is 2k results in 65mb of messages being passed to the consumer before the broker will wait to dispatch more. This results in out of memory errors and causes the InactivityMonitor in the consumer thread to barf, and the transport thinks its lost connection to the broker. The fix is to set the pretech limit lower for topics and then it works -e.g.
ActiveMQConnectionFactory cf=new ActiveMQConnectionFactory(bindAddress);
Properties props=new Properties();
props.setProperty("prefetchPolicy.topicPrefetch",""+100);
cf.setProperties(props);
> Fast producer, slow consumer hangs after a few messages when using VMPendingSubscriberMessageStoragePolicy
> ----------------------------------------------------------------------------------------------------------
>
> Key: AMQ-1148
> URL: https://issues.apache.org/activemq/browse/AMQ-1148
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.0.0
> Environment: Sun JDK 1.6.0 on Windows XP SP2 with VM arguments -Xms384m -Xmx512m
> Reporter: Albert Strasheim
> Assignee: Rob Davies
> Fix For: 5.0.0
>
> Attachments: SlowConsumerTest.java, SlowConsumerTest.java
>
>
> Following from this discussion:
> http://www.nabble.com/Fast-producer%2C-slow-consumer-with-spooling-to-disk--tf3123868.html
> Rob Davies implemented VMPendingSubscriberMessageStoragePolicy which, if I understand correctly, should cause a fast producer to block if a slow consumer can't keep up.
> However, when running the attached test case, the system seems to hang before the consumers have received much more than 5 messages. When it hangs probably depends on the heap size.
> I get this:
> 2007-02-02 13:44:23,281 [main ] INFO BrokerService - ActiveMQ null JMS Message Broker (localhost) is starting
> 2007-02-02 13:44:23,281 [main ] INFO BrokerService - For help or more information please see: http://incubator.apache.org/activemq/
> 2007-02-02 13:44:25,312 [main ] INFO JDBCPersistenceAdapter - Database driver recognized: [apache_derby_embedded_jdbc_driver]
> 2007-02-02 13:44:26,500 [main ] INFO DefaultDatabaseLocker - Attempting to acquire the exclusive lock to become the Master broker
> 2007-02-02 13:44:26,531 [main ] INFO DefaultDatabaseLocker - Becoming the master on dataSource: org.apache.derby.jdbc.EmbeddedDataSource@1372656
> 2007-02-02 13:44:26,593 [main ] INFO JournalPersistenceAdapter - Journal Recovery Started from: Active Journal: using 2 x 20.0 Megs at: C:\home\albert\work5\activemq\activemq-core\activemq-data\localhost\journal
> 2007-02-02 13:44:26,671 [main ] INFO JournalPersistenceAdapter - Journal Recovered: 0 message(s) in transactions recovered.
> 2007-02-02 13:44:26,859 [main ] INFO BrokerService - Using Persistence Adapter: JournalPersistenceAdapator(JDBCPersistenceAdaptor(org.apache.derby.jdbc.EmbeddedDataSource@1372656))
> 2007-02-02 13:44:26,906 [main ] INFO JournalPersistenceAdapter - Journal deleted:
> 2007-02-02 13:44:29,296 [main ] WARN DefaultJDBCAdapter - Could not create JDBC tables; they could already exist. Failure was: CREATE TABLE ACTIVEMQ_LOCK( ID BIGINT NOT NULL, TIME BIGINT, BROKER_NAME VARCHAR(250), PRIMARY KEY (ID) ) Message: Table/View 'ACTIVEMQ_LOCK' already exists in Schema 'APP'. SQLState: X0Y32 Vendor code: 30000
> 2007-02-02 13:44:29,343 [main ] WARN DefaultJDBCAdapter - Could not create JDBC tables; they could already exist. Failure was: INSERT INTO ACTIVEMQ_LOCK(ID) VALUES (1) Message: The statement was aborted because it would have caused a duplicate key value in a unique or primary key constraint or unique index identified by 'SQL070130113001540' defined on 'ACTIVEMQ_LOCK'. SQLState: 23505 Vendor code: 30000
> 2007-02-02 13:44:29,484 [main ] INFO TransportServerThreadSupport - Listening for connections at: tcp://ratbert:60706
> 2007-02-02 13:44:29,515 [main ] INFO TransportConnector - Connector tcp://ratbert:60706 Started
> 2007-02-02 13:44:29,515 [main ] INFO BrokerService - ActiveMQ JMS Message Broker (localhost, ID:ratbert-2177-1170416663296-1:0) started
> 2007-02-02 13:44:29,578 [JMX connector ] INFO ManagementContext - JMX consoles can connect to service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi
> 2007-02-02 13:44:29,625 [/127.0.0.1:2181] INFO KahaStore - Kaha Store successfully deleted data directory activemq-data\localhost\tmp_storage
> GOT A MESSAGE BEING SLOW
> GOT A MESSAGE BEING SLOW
> GOT A MESSAGE BEING SLOW
> GOT A MESSAGE BEING SLOW
> GOT A MESSAGE BEING SLOW
> GOT A MESSAGE BEING SLOW
> GOT A MESSAGE BEING SLOW
> GOT A MESSAGE BEING SLOW
> GOT A MESSAGE BEING SLOW
> before it hangs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.