You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Colin MacNaughton (JIRA)" <ji...@apache.org> on 2009/09/21 21:53:52 UTC
[jira] Created: (AMQ-2400) Default settings lead to paging and high
latency for non persistent pub/sub
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
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.
[jira] Resolved: (AMQ-2400) Default settings lead to paging and
high latency for non persistent pub/sub
Posted by "Dejan Bosanac (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dejan Bosanac resolved AMQ-2400.
--------------------------------
Resolution: Fixed
Fix Version/s: 5.3.0
Now that we have producer flow control works nicely and log messages when the "hang" occurs, I included this change in the default config.
> 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
> Fix For: 5.3.0
>
>
> 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.
[jira] Assigned: (AMQ-2400) Default settings lead to paging and
high latency for non persistent pub/sub
Posted by "Dejan Bosanac (JIRA)" <ji...@apache.org>.
[ 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.