[jira] [Updated] (AMQ-5397) Using authorization plugin with MQTT causes ClassCastException on client reconnect.
[
https://issues.apache.org/jira/browse/AMQ-5397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Tytgat updated AMQ-5397:
--
Priority: Critical (was: Major)
Using authorization plugin with MQTT causes ClassCastException on client
reconnect.
Key: AMQ-5397
URL: https://issues.apache.org/jira/browse/AMQ-5397
Project: ActiveMQ
Issue Type: Bug
Components: Connector, MQTT
Affects Versions: 5.10.0
Reporter: Christian Tytgat
Priority: Critical
We have the following setup:
MQTT client (reproducible with at least mosquitto and fusesource) with
cleanSession = false and QOS = 1 (important!)
AMQ with authentication/authorization plugin
{noformat}
plugins
statisticsBrokerPlugin/
simpleAuthenticationPlugin
users
authenticationUser username=${activemq.username}
password=${activemq.password} groups=admins,everyone/
authenticationUser username=mcollective password=secret
groups=mcollective,admins,everyone/
/users
/simpleAuthenticationPlugin
authorizationPlugin
map
authorizationMap
authorizationEntries
authorizationEntry queue= write=admins read=admins
admin=admins /
authorizationEntry topic= write=admins read=admins
admin=admins /
authorizationEntry topic=mcollective.
write=mcollective read=mcollective admin=mcollective /
authorizationEntry queue=mcollective.
write=mcollective read=mcollective admin=mcollective /
authorizationEntry topic=ActiveMQ.Advisory.
read=everyone write=everyone admin=everyone/
/authorizationEntries
/authorizationMap
/map
/authorizationPlugin
/plugins
{noformat}
No problem to connect for the first time, but when reconnecting with the same
client ID, the connection fails each time:
{noformat}
2014-10-16 11:20:41,120 [MQ NIO Worker 3] WARN Transport - Transport
Connection to: tcp://10.0.2.2:49479 failed:
org.apache.activemq.transport.mqtt.MQTTProtocolException: Error recovering
retained messages for m2mbox.macbookx.schedule:
org.apache.activemq.security.AuthorizationDestinationFilter cannot be cast to
org.apache.activemq.broker.region.Topic
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Jenkins build is back to stable : ActiveMQ ยป ActiveMQ :: AMQP #1534
See https://builds.apache.org/job/ActiveMQ/org.apache.activemq$activemq-amqp/1534/changes
[jira] [Updated] (AMQ-4584) Allow configuration of a discarding dead letter strategy
[
https://issues.apache.org/jira/browse/AMQ-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Tully updated AMQ-4584:
Description:
If you don't wish to retain non delivered or expired persistent messages then
it should be possible to easily disable the use of the dlq.
the discarding plugin will purge it, but that is not ideal.
Preferable is something like:
{code}destinationPolicy
policyMap
policyEntries
policyEntry queue= ..
deadLetterStrategydiscarding//deadLetterStrategy
...{code}
was:
If you don't wish to retain non delivered or expired persistent messages then
it should be possible to easily disable the use of the dlq.
the discarding plugin will purge it, but that is not ideal.
Preferable is something like:
{code}destinationPolicy
policyMap
policyEntries
policyEntry queue= deadLetterStrategy=discarding /
...{code}
Allow configuration of a discarding dead letter strategy
Key: AMQ-4584
URL: https://issues.apache.org/jira/browse/AMQ-4584
Project: ActiveMQ
Issue Type: Improvement
Components: Broker
Affects Versions: 5.8.0
Reporter: Gary Tully
Assignee: Timothy Bish
Priority: Minor
Fix For: 5.9.0
Attachments: AMQ4584Patch.txt
If you don't wish to retain non delivered or expired persistent messages then
it should be possible to easily disable the use of the dlq.
the discarding plugin will purge it, but that is not ideal.
Preferable is something like:
{code}destinationPolicy
policyMap
policyEntries
policyEntry queue= ..
deadLetterStrategydiscarding//deadLetterStrategy
...{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-5397) Using authorization plugin with MQTT causes ClassCastException on client reconnect.
[
https://issues.apache.org/jira/browse/AMQ-5397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14173791#comment-14173791
]
Timothy Bish commented on AMQ-5397:
---
You might want to try out the 5.11-SNAPSHOT builds and see if the problem is
still there. If so it would be great if you could create a test case for this,
possibly add one to MQTTAuthTest.java in the activemq-mqtt project.
Using authorization plugin with MQTT causes ClassCastException on client
reconnect.
Key: AMQ-5397
URL: https://issues.apache.org/jira/browse/AMQ-5397
Project: ActiveMQ
Issue Type: Bug
Components: Connector, MQTT
Affects Versions: 5.10.0
Reporter: Christian Tytgat
Priority: Critical
We have the following setup:
MQTT client (reproducible with at least mosquitto and fusesource) with
cleanSession = false and QOS = 1 (important!)
AMQ with authentication/authorization plugin
{noformat}
plugins
statisticsBrokerPlugin/
simpleAuthenticationPlugin
users
authenticationUser username=${activemq.username}
password=${activemq.password} groups=admins,everyone/
authenticationUser username=mcollective password=secret
groups=mcollective,admins,everyone/
/users
/simpleAuthenticationPlugin
authorizationPlugin
map
authorizationMap
authorizationEntries
authorizationEntry queue= write=admins read=admins
admin=admins /
authorizationEntry topic= write=admins read=admins
admin=admins /
authorizationEntry topic=mcollective.
write=mcollective read=mcollective admin=mcollective /
authorizationEntry queue=mcollective.
write=mcollective read=mcollective admin=mcollective /
authorizationEntry topic=ActiveMQ.Advisory.
read=everyone write=everyone admin=everyone/
/authorizationEntries
/authorizationMap
/map
/authorizationPlugin
/plugins
{noformat}
No problem to connect for the first time, but when reconnecting with the same
client ID, the connection fails each time:
{noformat}
2014-10-16 11:20:41,120 [MQ NIO Worker 3] WARN Transport - Transport
Connection to: tcp://10.0.2.2:49479 failed:
org.apache.activemq.transport.mqtt.MQTTProtocolException: Error recovering
retained messages for m2mbox.macbookx.schedule:
org.apache.activemq.security.AuthorizationDestinationFilter cannot be cast to
org.apache.activemq.broker.region.Topic
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-4940) Update the version of Jetty used
[ https://issues.apache.org/jira/browse/AMQ-4940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14173793#comment-14173793 ] Timothy Bish commented on AMQ-4940: --- I don't think anyone would object to such a contribution. It probably wouldn't make it into a 5.11 release but could go into a later one. Update the version of Jetty used Key: AMQ-4940 URL: https://issues.apache.org/jira/browse/AMQ-4940 Project: ActiveMQ Issue Type: Improvement Environment: activemq-5.10-20131214.063224-32 Reporter: Lionel Cons When trying the latest 5.10 snapshot, I was surprised to see a quite old version of Jetty: 2013-12-16 14:41:10,665 [WrapperSimpleAppMain] INFO Server - jetty-7.6.9.v20130131 Why is ActiveMQ using Jetty 7 instead of Jetty 8 or 9? In any case, could ActiveMQ use a more recent version of Jetty like 7.6.14.v20131031 (if it must stick to Jetty 7)? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-2106) Allow broker to evenly distribute message groups among consumers
[ https://issues.apache.org/jira/browse/AMQ-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14173819#comment-14173819 ] Tamas Cserveny commented on AMQ-2106: - Caveat emptor! using message.setIntProperty(JMSXGroupSeq, -1); will break the order of the messages. Use it carefully! Allow broker to evenly distribute message groups among consumers Key: AMQ-2106 URL: https://issues.apache.org/jira/browse/AMQ-2106 Project: ActiveMQ Issue Type: New Feature Components: Broker Affects Versions: 5.2.0 Reporter: Dejan Bosanac Assignee: Gary Tully Fix For: 5.7.0 Currently the broker will not reassign message groups if new consumers becomes available (or existing ones are removed). We could allow the broker to try reassign the message groups when consumers are added/removed so that we have a even distribution among consumers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5394) Incorrect handling of duplicate update message commands in KahaDB can lead to broker startup errors
[
https://issues.apache.org/jira/browse/AMQ-5394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14173992#comment-14173992
]
Jesse Fugitt commented on AMQ-5394:
---
After further testing, it looks like the metadata.lastUpdate location in KahaDB
is being set incorrectly in more places than just the function that handles
update message (the add message and remove message functions also appear to
have branches where this can happen). A more complete patch will be needed to
catch all the cases where this could occur.
Incorrect handling of duplicate update message commands in KahaDB can lead to
broker startup errors
---
Key: AMQ-5394
URL: https://issues.apache.org/jira/browse/AMQ-5394
Project: ActiveMQ
Issue Type: Bug
Components: Message Store
Affects Versions: 5.10.0
Reporter: Jesse Fugitt
Attachments: AMQ5394.patch
When using the new (in 5.10) persistJMSRedelivered option to make sure all
duplicates are marked as redelivered (the activemq.xml config file used
policyEntry queue= persistJMSRedelivered=true/policyEntry), we
occasionally had a broker fail to start up with the following error:
2014-10-07 17:31:15,117 | ERROR | Looking for key 7 but not found in fileMap:
{8=db-8.log number = 8 , length = 9132256} |
org.apache.activemq.store.kahadb.disk.journal.Journal | main
2014-10-07 17:31:15,117 | ERROR | Failed to start Apache ActiveMQ ([broker0,
null], java.io.IOException: Could not locate data file
/local/temp/apache-activemq-5.10.0/data/kahadb/db-7.log) |
org.apache.activemq.broker.BrokerService | main
The root cause seems to be when KahaDB processes a duplicate update message
command or if it processes an update message command after the message has
been removed from kahadb. The code in KahaDB logs a warning when this occurs
from the following else statement and then updates the metadata location and
then exits the function as shown below:
...
} else {
LOG.warn(Non existent message update attempt rejected.
Destination: {}://{}, Message id: {}, command.getDestination().getType(),
command.getDestination().getName(), command.getMessageId());
}
metadata.lastUpdate = location;
...
It turns out that the metadata.lastUpdate = location; line should not run if
we took the else branch above so the simple fix is to move that line up into
the if block so that it will not run after the log warning. Once we did
that, we no longer see the broker startup errors. Note that this log warning
does not always lead to a broker startup error as it is also related to
writing at the end of a transaction log file or the checkpoint timer interval
so it is not simple to reproduce but we have not see the startup error once
the metadata.lastUpdate line was moved to the correct location.
A patch will be provided to show the change.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (AMQ-5394) Incorrect handling of duplicate update message commands in KahaDB can lead to broker startup errors
[
https://issues.apache.org/jira/browse/AMQ-5394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse Fugitt updated AMQ-5394:
--
Comment: was deleted
(was: Patch to fix update message command in KahaDB that incorrects sets
metadata lastUpdate location.)
Incorrect handling of duplicate update message commands in KahaDB can lead to
broker startup errors
---
Key: AMQ-5394
URL: https://issues.apache.org/jira/browse/AMQ-5394
Project: ActiveMQ
Issue Type: Bug
Components: Message Store
Affects Versions: 5.10.0
Reporter: Jesse Fugitt
Attachments: AMQ5394.patch
When using the new (in 5.10) persistJMSRedelivered option to make sure all
duplicates are marked as redelivered (the activemq.xml config file used
policyEntry queue= persistJMSRedelivered=true/policyEntry), we
occasionally had a broker fail to start up with the following error:
2014-10-07 17:31:15,117 | ERROR | Looking for key 7 but not found in fileMap:
{8=db-8.log number = 8 , length = 9132256} |
org.apache.activemq.store.kahadb.disk.journal.Journal | main
2014-10-07 17:31:15,117 | ERROR | Failed to start Apache ActiveMQ ([broker0,
null], java.io.IOException: Could not locate data file
/local/temp/apache-activemq-5.10.0/data/kahadb/db-7.log) |
org.apache.activemq.broker.BrokerService | main
The root cause seems to be when KahaDB processes a duplicate update message
command or if it processes an update message command after the message has
been removed from kahadb. The code in KahaDB logs a warning when this occurs
from the following else statement and then updates the metadata location and
then exits the function as shown below:
...
} else {
LOG.warn(Non existent message update attempt rejected.
Destination: {}://{}, Message id: {}, command.getDestination().getType(),
command.getDestination().getName(), command.getMessageId());
}
metadata.lastUpdate = location;
...
It turns out that the metadata.lastUpdate = location; line should not run if
we took the else branch above so the simple fix is to move that line up into
the if block so that it will not run after the log warning. Once we did
that, we no longer see the broker startup errors. Note that this log warning
does not always lead to a broker startup error as it is also related to
writing at the end of a transaction log file or the checkpoint timer interval
so it is not simple to reproduce but we have not see the startup error once
the metadata.lastUpdate line was moved to the correct location.
A patch will be provided to show the change.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-5394) Incorrect handling of duplicate update message commands in KahaDB can lead to broker startup errors
[
https://issues.apache.org/jira/browse/AMQ-5394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse Fugitt updated AMQ-5394:
--
Attachment: AMQ5394.patch
Updated patch to fix add/update/remove message command in KahaDB that
incorrectly sets metadata lastUpdate location in places.
Incorrect handling of duplicate update message commands in KahaDB can lead to
broker startup errors
---
Key: AMQ-5394
URL: https://issues.apache.org/jira/browse/AMQ-5394
Project: ActiveMQ
Issue Type: Bug
Components: Message Store
Affects Versions: 5.10.0
Reporter: Jesse Fugitt
Attachments: AMQ5394.patch, AMQ5394.patch
When using the new (in 5.10) persistJMSRedelivered option to make sure all
duplicates are marked as redelivered (the activemq.xml config file used
policyEntry queue= persistJMSRedelivered=true/policyEntry), we
occasionally had a broker fail to start up with the following error:
2014-10-07 17:31:15,117 | ERROR | Looking for key 7 but not found in fileMap:
{8=db-8.log number = 8 , length = 9132256} |
org.apache.activemq.store.kahadb.disk.journal.Journal | main
2014-10-07 17:31:15,117 | ERROR | Failed to start Apache ActiveMQ ([broker0,
null], java.io.IOException: Could not locate data file
/local/temp/apache-activemq-5.10.0/data/kahadb/db-7.log) |
org.apache.activemq.broker.BrokerService | main
The root cause seems to be when KahaDB processes a duplicate update message
command or if it processes an update message command after the message has
been removed from kahadb. The code in KahaDB logs a warning when this occurs
from the following else statement and then updates the metadata location and
then exits the function as shown below:
...
} else {
LOG.warn(Non existent message update attempt rejected.
Destination: {}://{}, Message id: {}, command.getDestination().getType(),
command.getDestination().getName(), command.getMessageId());
}
metadata.lastUpdate = location;
...
It turns out that the metadata.lastUpdate = location; line should not run if
we took the else branch above so the simple fix is to move that line up into
the if block so that it will not run after the log warning. Once we did
that, we no longer see the broker startup errors. Note that this log warning
does not always lead to a broker startup error as it is also related to
writing at the end of a transaction log file or the checkpoint timer interval
so it is not simple to reproduce but we have not see the startup error once
the metadata.lastUpdate line was moved to the correct location.
A patch will be provided to show the change.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-5396) Linkstealing causes deadlock when old client disconnects before link stealing adds the connection
[ https://issues.apache.org/jira/browse/AMQ-5396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai updated AMQ-5396: - Attachment: linkstealing-deadlock.patch Linkstealing causes deadlock when old client disconnects before link stealing adds the connection - Key: AMQ-5396 URL: https://issues.apache.org/jira/browse/AMQ-5396 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.11.0 Reporter: Sai Attachments: linkstealing-deadlock.patch During link stealing in progress if the old client(or connection) issues a disconnect can cause a deadlock due the order in which the locks are obtained on RegionBroker.addConnection and TransportConnection.processRemoveConneciton. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5396) Linkstealing causes deadlock when old client disconnects before link stealing adds the connection
[ https://issues.apache.org/jira/browse/AMQ-5396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai updated AMQ-5396: - Attachment: (was: regionbroker-deadlock.patch) Linkstealing causes deadlock when old client disconnects before link stealing adds the connection - Key: AMQ-5396 URL: https://issues.apache.org/jira/browse/AMQ-5396 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.11.0 Reporter: Sai Attachments: linkstealing-deadlock.patch During link stealing in progress if the old client(or connection) issues a disconnect can cause a deadlock due the order in which the locks are obtained on RegionBroker.addConnection and TransportConnection.processRemoveConneciton. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5396) Linkstealing causes deadlock when old client disconnects before link stealing adds the connection
[ https://issues.apache.org/jira/browse/AMQ-5396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai updated AMQ-5396: - Attachment: jstack.txt Linkstealing causes deadlock when old client disconnects before link stealing adds the connection - Key: AMQ-5396 URL: https://issues.apache.org/jira/browse/AMQ-5396 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.11.0 Reporter: Sai Attachments: jstack.txt, linkstealing-deadlock.patch During link stealing in progress if the old client(or connection) issues a disconnect can cause a deadlock due the order in which the locks are obtained on RegionBroker.addConnection and TransportConnection.processRemoveConneciton. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5396) Linkstealing causes deadlock when old client disconnects before link stealing adds the connection
[ https://issues.apache.org/jira/browse/AMQ-5396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14174543#comment-14174543 ] Sai commented on AMQ-5396: -- attached the jstack which shows the deadlock Linkstealing causes deadlock when old client disconnects before link stealing adds the connection - Key: AMQ-5396 URL: https://issues.apache.org/jira/browse/AMQ-5396 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.11.0 Reporter: Sai Attachments: jstack.txt, linkstealing-deadlock.patch During link stealing in progress if the old client(or connection) issues a disconnect can cause a deadlock due the order in which the locks are obtained on RegionBroker.addConnection and TransportConnection.processRemoveConneciton. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-5398) How do I configure a automatic expiration for DLQ
Gopal Chakravarthy created AMQ-5398:
---
Summary: How do I configure a automatic expiration for DLQ
Key: AMQ-5398
URL: https://issues.apache.org/jira/browse/AMQ-5398
Project: ActiveMQ
Issue Type: Task
Components: activemq-pool
Affects Versions: 5.3.2
Environment: RHEL 5.3
Reporter: Gopal Chakravarthy
For the dead letter queue ActiveMQ.DLQ, I would like to configure a policy
whereby messages in DLQ get deleted after they have resided in DLQ for 5 days.
I couldnt see how to do it in the documentation.
My current activemq.xml configuration file is below...how do I modify it for
autoexpiring my DLQ messages after 5 days...
!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the License); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an AS IS BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
--
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;
!-- Allows us to use system properties as variables in this configuration
file --
bean
class=org.springframework.beans.factory.config.PropertyPlaceholderConfigurer
property name=locations
valuefile:${activemq.base}/conf/credentials.properties/value
/property
/bean
!--
The broker element is used to configure the ActiveMQ broker.
--
broker xmlns=http://activemq.apache.org/schema/core;
brokerName=localhost dataDirectory=${activemq.base}/data
destroyApplicationContextOnStop=true
!--
For better performances use VM cursor and small memory
limit.
For more information, see:
http://activemq.apache.org/message-cursors.html
Also, if your producer is hanging, it's probably due to producer
flow control.
For more information, see:
http://activemq.apache.org/producer-flow-control.html
--
destinationPolicy
policyMap
policyEntries
policyEntry topic= producerFlowControl=false
memoryLimit=1mb useCache=false
pendingSubscriberPolicy
vmCursor /
/pendingSubscriberPolicy
/policyEntry
policyEntry queue= producerFlowControl=false
memoryLimit=1mb useCache=false
!-- Use VM cursor for better latency
For more information, see:
http://activemq.apache.org/message-cursors.html
pendingQueuePolicy
vmQueueCursor/
/pendingQueuePolicy
--
dispatchPolicy
roundRobinDispatchPolicy /
/dispatchPolicy
/policyEntry
/policyEntries
/policyMap
/destinationPolicy
!--
The managementContext is used to configure how ActiveMQ is exposed
in
JMX. By default, ActiveMQ uses the MBean server that is started by
the JVM. For more information, see:
http://activemq.apache.org/jmx.html
--
managementContext
managementContext createConnector=false/
/managementContext
!--
Configure message persistence for the broker. The default
persistence
mechanism is the KahaDB store (identified by the kahaDB tag).
For more information, see:
http://activemq.apache.org/persistence.html
--
persistenceAdapter
kahaDB directory=${activemq.base}/data/kahadb
ignoreMissingJournalfiles=true
checkForCorruptJournalFiles=true
checksumJournalFiles=true
journalMaxFileLength=64mb /
/persistenceAdapter
!--
The systemUsage controls the maximum amount of space the broker will
use before slowing down producers. For more information, see:
[jira] [Commented] (AMQ-5398) How do I configure a automatic expiration for DLQ
[
https://issues.apache.org/jira/browse/AMQ-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14174558#comment-14174558
]
Gopal Chakravarthy commented on AMQ-5398:
-
What is the impact of making the following change
broker xmlns=http://activemq.apache.org/schema/core; brokerName=localhost
dataDirectory=${activemq.base}/data destroyApplicationContextOnStop=true
plugins
discardingDLQBrokerPlugin dropAll=true
dropTemporaryTopics=true dropTemporaryQueues=true /
/plugins
/broker
What I really want is to put a policy whereby messages in DLQ older than 5
days are automatically deleted.
How do I configure a automatic expiration for DLQ
--
Key: AMQ-5398
URL: https://issues.apache.org/jira/browse/AMQ-5398
Project: ActiveMQ
Issue Type: Task
Components: activemq-pool
Affects Versions: 5.3.2
Environment: RHEL 5.3
Reporter: Gopal Chakravarthy
For the dead letter queue ActiveMQ.DLQ, I would like to configure a policy
whereby messages in DLQ get deleted after they have resided in DLQ for 5 days.
I couldnt see how to do it in the documentation.
My current activemq.xml configuration file is below...how do I modify it for
autoexpiring my DLQ messages after 5 days...
!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the License); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an AS IS BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
--
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;
!-- Allows us to use system properties as variables in this
configuration file --
bean
class=org.springframework.beans.factory.config.PropertyPlaceholderConfigurer
property name=locations
valuefile:${activemq.base}/conf/credentials.properties/value
/property
/bean
!--
The broker element is used to configure the ActiveMQ broker.
--
broker xmlns=http://activemq.apache.org/schema/core;
brokerName=localhost dataDirectory=${activemq.base}/data
destroyApplicationContextOnStop=true
!--
For better performances use VM cursor and small
memory limit.
For more information, see:
http://activemq.apache.org/message-cursors.html
Also, if your producer is hanging, it's probably due to
producer flow control.
For more information, see:
http://activemq.apache.org/producer-flow-control.html
--
destinationPolicy
policyMap
policyEntries
policyEntry topic= producerFlowControl=false
memoryLimit=1mb useCache=false
pendingSubscriberPolicy
vmCursor /
/pendingSubscriberPolicy
/policyEntry
policyEntry queue= producerFlowControl=false
memoryLimit=1mb useCache=false
!-- Use VM cursor for better latency
For more information, see:
http://activemq.apache.org/message-cursors.html
pendingQueuePolicy
vmQueueCursor/
/pendingQueuePolicy
--
dispatchPolicy
roundRobinDispatchPolicy /
/dispatchPolicy
/policyEntry
/policyEntries
/policyMap
/destinationPolicy
!--
The managementContext is used to configure how ActiveMQ is
exposed in
JMX. By default, ActiveMQ uses the MBean server that is started by
the JVM. For more information, see:
http://activemq.apache.org/jmx.html
--
managementContext
managementContext createConnector=false/
/managementContext
!--
[jira] [Closed] (AMQ-5398) How do I configure a automatic expiration for DLQ
[
https://issues.apache.org/jira/browse/AMQ-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish closed AMQ-5398.
-
Resolution: Invalid
Questions should be posted to the users list.
How do I configure a automatic expiration for DLQ
--
Key: AMQ-5398
URL: https://issues.apache.org/jira/browse/AMQ-5398
Project: ActiveMQ
Issue Type: Task
Components: activemq-pool
Affects Versions: 5.3.2
Environment: RHEL 5.3
Reporter: Gopal Chakravarthy
For the dead letter queue ActiveMQ.DLQ, I would like to configure a policy
whereby messages in DLQ get deleted after they have resided in DLQ for 5 days.
I couldnt see how to do it in the documentation.
My current activemq.xml configuration file is below...how do I modify it for
autoexpiring my DLQ messages after 5 days...
!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the License); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an AS IS BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
--
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;
!-- Allows us to use system properties as variables in this
configuration file --
bean
class=org.springframework.beans.factory.config.PropertyPlaceholderConfigurer
property name=locations
valuefile:${activemq.base}/conf/credentials.properties/value
/property
/bean
!--
The broker element is used to configure the ActiveMQ broker.
--
broker xmlns=http://activemq.apache.org/schema/core;
brokerName=localhost dataDirectory=${activemq.base}/data
destroyApplicationContextOnStop=true
!--
For better performances use VM cursor and small
memory limit.
For more information, see:
http://activemq.apache.org/message-cursors.html
Also, if your producer is hanging, it's probably due to
producer flow control.
For more information, see:
http://activemq.apache.org/producer-flow-control.html
--
destinationPolicy
policyMap
policyEntries
policyEntry topic= producerFlowControl=false
memoryLimit=1mb useCache=false
pendingSubscriberPolicy
vmCursor /
/pendingSubscriberPolicy
/policyEntry
policyEntry queue= producerFlowControl=false
memoryLimit=1mb useCache=false
!-- Use VM cursor for better latency
For more information, see:
http://activemq.apache.org/message-cursors.html
pendingQueuePolicy
vmQueueCursor/
/pendingQueuePolicy
--
dispatchPolicy
roundRobinDispatchPolicy /
/dispatchPolicy
/policyEntry
/policyEntries
/policyMap
/destinationPolicy
!--
The managementContext is used to configure how ActiveMQ is
exposed in
JMX. By default, ActiveMQ uses the MBean server that is started by
the JVM. For more information, see:
http://activemq.apache.org/jmx.html
--
managementContext
managementContext createConnector=false/
/managementContext
!--
Configure message persistence for the broker. The default
persistence
mechanism is the KahaDB store (identified by the kahaDB tag).
For more information, see:
http://activemq.apache.org/persistence.html
--
persistenceAdapter
kahaDB directory=${activemq.base}/data/kahadb
ignoreMissingJournalfiles=true
checkForCorruptJournalFiles=true
[jira] [Updated] (AMQ-5396) Linkstealing causes deadlock when old client disconnects before link stealing adds the connection
[ https://issues.apache.org/jira/browse/AMQ-5396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai updated AMQ-5396: - Attachment: (was: jstack.txt) Linkstealing causes deadlock when old client disconnects before link stealing adds the connection - Key: AMQ-5396 URL: https://issues.apache.org/jira/browse/AMQ-5396 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.11.0 Reporter: Sai Attachments: linkstealing-deadlock.patch During link stealing in progress if the old client(or connection) issues a disconnect can cause a deadlock due the order in which the locks are obtained on RegionBroker.addConnection and TransportConnection.processRemoveConneciton. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5396) Linkstealing causes deadlock when old client disconnects before link stealing adds the connection
[ https://issues.apache.org/jira/browse/AMQ-5396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai updated AMQ-5396: - Attachment: jstack.txt Linkstealing causes deadlock when old client disconnects before link stealing adds the connection - Key: AMQ-5396 URL: https://issues.apache.org/jira/browse/AMQ-5396 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.11.0 Reporter: Sai Attachments: linkstealing-deadlock.patch During link stealing in progress if the old client(or connection) issues a disconnect can cause a deadlock due the order in which the locks are obtained on RegionBroker.addConnection and TransportConnection.processRemoveConneciton. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5396) Linkstealing causes deadlock when old client disconnects before link stealing adds the connection
[ https://issues.apache.org/jira/browse/AMQ-5396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai updated AMQ-5396: - Attachment: (was: jstack.txt) Linkstealing causes deadlock when old client disconnects before link stealing adds the connection - Key: AMQ-5396 URL: https://issues.apache.org/jira/browse/AMQ-5396 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.11.0 Reporter: Sai Attachments: linkstealing-deadlock.patch During link stealing in progress if the old client(or connection) issues a disconnect can cause a deadlock due the order in which the locks are obtained on RegionBroker.addConnection and TransportConnection.processRemoveConneciton. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5396) Linkstealing causes deadlock when old client disconnects before link stealing adds the connection
[ https://issues.apache.org/jira/browse/AMQ-5396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai updated AMQ-5396: - Attachment: jstack.txt Linkstealing causes deadlock when old client disconnects before link stealing adds the connection - Key: AMQ-5396 URL: https://issues.apache.org/jira/browse/AMQ-5396 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.11.0 Reporter: Sai Attachments: jstack.txt, linkstealing-deadlock.patch During link stealing in progress if the old client(or connection) issues a disconnect can cause a deadlock due the order in which the locks are obtained on RegionBroker.addConnection and TransportConnection.processRemoveConneciton. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
