activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Davies <rajdav...@gmail.com>
Subject Re: Slow sending of messages
Date Wed, 17 Feb 2010 15:06:15 GMT
Can you try increasing the cache size for KahaDB - to 10000 ?  - see http://activemq.apache.org/kahadb.html

cheers,

Rob
On 17 Feb 2010, at 14:39, Maarten_D wrote:

>
> No problem:
>
> <beans
>  xmlns="http://www.springframework.org/schema/beans"
>  xmlns:amq="http://activemq.apache.org/schema/core"
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>  xsi:schemaLocation="http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
>  http://activemq.apache.org/schema/core
> http://activemq.apache.org/schema/core/activemq-core.xsd
> http://mortbay.com/schemas/jetty/1.0
>  http://jetty.mortbay.org/jetty.xsd">
>
>  <!-- Allows us to use system properties as variables in this  
> configuration
> file -->
>  <bean
> class 
> = 
> "org 
> .springframework.beans.factory.config.PropertyPlaceholderConfigurer">
>    <property name="location" value="file:/var/amq/ 
> broker.properties" />
>  </bean>
>
>  <!--
>
> ******************************************************************************************************************
>  ** ActiveMQ broker
>
> ******************************************************************************************************************
>  -->
>  <broker id="broker" useJmx="true" brokerName="broker" start="true"
>          xmlns="http://activemq.apache.org/schema/core"
>          dataDirectory="/var/amq" advisorySupport="false"
>          persistenceAdapter="#store">
>
>    <destinationPolicy>
>      <policyMap>
>        <policyEntries>
>          <policyEntry queue=">" memoryLimit="64 mb"
> producerFlowControl="false" />
>          <policyEntry topic=">" memoryLimit="64 mb"
> producerFlowControl="true" />
>        </policyEntries>
>      </policyMap>
>    </destinationPolicy>
>
>    <managementContext>
>      <managementContext useMBeanServer="true"
>                         jmxDomainName="org.apache.activemq"
>                         createMBeanServer="true"
>                         createConnector="false"
>                         connectorPort="1100"
>                         connectorPath="/jmxrmi"/>
>    </managementContext>
>
>    <persistenceAdapter id="store">
>      <kahaDB enableJournalDiskSyncs="false"
>              journalMaxFileLength="32mb"
>              enableIndexWriteAsync="true"
>              directory="/var/amq/broker"
>              indexWriteBatchSize="1000" />
>    </persistenceAdapter>
>
>    <systemUsage>
>      <systemUsage>
>        <memoryUsage>
>          <memoryUsage limit="512 mb" />
>        </memoryUsage>
>      </systemUsage>
>    </systemUsage>
>
>    <transportConnectors>
>      <transportConnector name="cearchive" uri="tcp://0.0.0.0:61616" />
>    </transportConnectors>
>  </broker>
>
>  <!-- Here we start an embedded webserver for the admin console -->
>  <jetty xmlns="http://mortbay.com/schemas/jetty/1.0">
>    <connectors>
>      <nioConnector port="8161"/>
>    </connectors>
>    <handlers>
>      <webAppContext contextPath="/admin"
> resourceBase="${activemq.base}/webapps/admin" logUrlOnStart="true"/>
>    </handlers>
>  </jetty>
> </beans>
>
>
>
> rajdavies wrote:
>>
>> can you send your broker config ?
>> On 17 Feb 2010, at 12:38, Maarten_D wrote:
>>
>>>
>>> The topics and queues are filled using a Spring JMSTemplate that has
>>> it's own
>>> connection factory, and dequeuing is done by message listeners that
>>> all have
>>> their own connection. So everything should have its own connection,
>>> let
>>> alone session.
>>>
>>> I'll do another run on debug and see what it turns up.
>>>
>>>
>>> Adrian A wrote:
>>>>
>>>> you are running separate sessions for each of those dequeue/enqueue
>>>> stats?
>>>>
>>>> in my flow control tests even when one particular session was hung
>>>> other
>>>> sessions to the same broker was fine, just when I overwhelmed
>>>> broker and
>>>> GC / disk checkpointing occurred that it got really bad.
>>>>
>>>> have you turned on debugging as that although verbose is a wealth  
>>>> of
>>>> information!
>>>>
>>>>
>>>>
>>>> Maarten_D wrote:
>>>>>
>>>>> Hi Adrian, thanks for your response.
>>>>>
>>>>> I'm currently running tests where I have a very fast producer  
>>>>> and a
>>>>> relatively slow consumer. The producer publishes persistent
>>>>> messages to a
>>>>> topic, where the enqueue and dequeue count diverge fairly rapidly
>>>>> to a
>>>>> difference of around 80,000 messages. The producer then gets
>>>>> whacked and
>>>>> the enqueue graph in visualvm completely levels off. This is more
>>>>> or less
>>>>> expected, as I've turned on producerFlowControl for topics.
>>>>> However, the
>>>>> entire broker stalls. I have several queues that are filled and
>>>>> emptied
>>>>> at the same time as the topic, and their dequeue/enqueue stats
>>>>> flatline
>>>>> as well, even though flow control shouldn't apply to them. Thats
>>>>> why I
>>>>> was interested to find out if you'd discovered some kind of fresh
>>>>> angle.
>>>>> Regards,
>>>>> Maarten
>>>>>
>>>>
>>>>
>>>
>>> -- 
>>> View this message in context:
>>> http://old.nabble.com/Slow-sending-of-messages-tp26849964p27623064.html
>>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>>
>>
>> Rob Davies
>> http://twitter.com/rajdavies
>> I work here: http://fusesource.com
>> My Blog: http://rajdavies.blogspot.com/
>> I'm writing this: http://www.manning.com/snyder/
>>
>>
>>
>>
>>
>>
>>
>
> -- 
> View this message in context: http://old.nabble.com/Slow-sending-of-messages-tp26849964p27624666.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

Rob Davies
http://twitter.com/rajdavies
I work here: http://fusesource.com
My Blog: http://rajdavies.blogspot.com/
I'm writing this: http://www.manning.com/snyder/






Mime
View raw message