activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dejan Bosanac (JIRA)" <j...@apache.org>
Subject [jira] Assigned: (AMQ-2400) Default settings lead to paging and high latency for non persistent pub/sub
Date Tue, 22 Sep 2009 08:18:52 GMT

     [ https://issues.apache.org/activemq/browse/AMQ-2400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Dejan Bosanac reassigned AMQ-2400:
----------------------------------

    Assignee: Dejan Bosanac

> Default settings lead to paging and high latency for non persistent pub/sub
> ---------------------------------------------------------------------------
>
>                 Key: AMQ-2400
>                 URL: https://issues.apache.org/activemq/browse/AMQ-2400
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.3.0
>         Environment: N/A
>            Reporter: Colin MacNaughton
>            Assignee: Dejan Bosanac
>
> The current default config doesn't enable a memoryLimit or flow control for topics which
consequently leads to high latency and lower throughput. 
> I ended up tweaking the default config to limit destination sizes and enable flow control
as follows:
> <destinationPolicy>
>  <policyMap>
>    <policyEntries>
>      <policyEntry topic=">" producerFlowControl="true" memoryLimit="1mb">  
                   
>        <pendingSubscriberPolicy>
>          <vmCursor/>
>        </pendingSubscriberPolicy>
>      </policyEntry>
>      <policyEntry queue=">" producerFlowControl="true" memoryLimit="1mb"/>
>    </policyEntries>
>  </policyMap>
> </destinationPolicy>
> The current default config was resulting in really high latencies in non persistent pub
sub tests (> 2 minutes!). With the new settings throughput doubled and average latency
dropped to 3 seconds. 
> However, it seems like there is some resistance to enabling flow control by default:
http://issues.apache.org/activemq/browse/AMQ-2318, as naïve users might erroneously interpret
this as a hang. 
> A possible compromise appropriate for the 5.3.0 release time frame would be to log a
warning the first time flow control is triggered for a destination, to assist naive users
in troubleshooting producer pauses. 
> More long term, it might be worth introucing a more sophisticated mechanism for when
we page to disk like only do so when there are no consumers connected. A policy similar to
this is already being pursued in the amq 6.0 prototype.  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message