[jira] [Commented] (QPID-4731) Java Broker: topic subscription with selector bug can silently prevent temporary queue deletion
[
https://issues.apache.org/jira/browse/QPID-4731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13633927#comment-13633927
]
Keith Wall commented on QPID-4731:
--
Patch applied at revs 1468815 and 1468816.
Java Broker: topic subscription with selector bug can silently prevent
temporary queue deletion
---
Key: QPID-4731
URL: https://issues.apache.org/jira/browse/QPID-4731
Project: Qpid
Issue Type: Bug
Components: Java Broker
Affects Versions: 0.6, 0.8, 0.10, 0.12, 0.14, 0.16, 0.18, 0.20
Reporter: Philip Harvey
Assignee: Philip Harvey
When JMS selectors are used with topics, the attempt to deregister the topic
subscriber's temporary queue can silently fail. This leaves the queue bound
to the exchange, thereby allowing messages to continue being sent to it.
This is shown in the following log excerpts from a v0.5 Broker:
Initial set-up of topic with selector:
{noformat}
2013-04-02 04:11:51,947 INFO [pool-1-thread-22]
rawloggers.Log4jMessageLogger (Log4jMessageLogger.java:69) - MESSAGE
[con:199(x@/yyy.yyy.yyy.yyy:45309/ZZZ)/ch:1]
[vh(/ZZZ)/qu(tmp_yyy.yyy.yyy.yyy45309_2)] QUE-1001 : Create : Owner: xxx
AutoDelete Transient
2013-04-02 04:11:51,949 INFO [pool-1-thread-22]
rawloggers.Log4jMessageLogger (Log4jMessageLogger.java:69) - MESSAGE
[con:199(x@/yyy.yyy.yyy.yyy:45309/ZZZ)/ch:1]
[vh(/ZZZ)/ex(direct/default)/qu(tmp_yyy.yyy.yyy.yyy45309_2)/rk(tmp_yyy.yyy.yyy.yyy45309_2)]
BND-1001 : Create
2013-04-02 04:11:51,957 INFO [pool-1-thread-23]
rawloggers.Log4jMessageLogger (Log4jMessageLogger.java:69) - MESSAGE
[con:199(x@/yyy.yyy.yyy.yyy:45309/ZZZ)/ch:1]
[vh(/ZZZ)/ex(topic/amq.topic)/qu(tmp_yyy.yyy.yyy.yyy45309_2)/rk(XXX_Topic)]
BND-1001 : Create : Arguments : {x-filter-jms-selector=[LONG_STRING:
XXX_GROUP='x']}
2013-04-02 04:11:51,977 INFO [pool-1-thread-15]
rawloggers.Log4jMessageLogger (Log4jMessageLogger.java:69) - MESSAGE
[con:199(x@/yyy.yyy.yyy.yyy:45309/ZZZ)/ch:1]
[sub:4,117(vh(/ZZZ)/qu(tmp_yyy.yyy.yyy.yyy45309_2)] SUB-1001 : Create :
Arguments : JMSSelector(XXX_GROUP='x')
2013-04-02 14:14:02,663 INFO [pool-1-thread-30] queue.AMQQueueMBean
(AMQQueueMBean.java:336) - QUEUE_DEPTH_ALERT On Queue
tmp_yyy.yyy.yyy.yyy45309_2 - 4137Kb : Maximum queue depth threshold (4136Kb)
breached.
{noformat}
Subsequent topic consumer close:
{noformat}
2013-04-02 23:59:21,538 INFO [pool-1-thread-23]
rawloggers.Log4jMessageLogger (Log4jMessageLogger.java:69) - MESSAGE
[con:199(x@/yyy.yyy.yyy.yyy:45309/ZZZ)]
[sub:4,117(vh(/ZZZ)/qu(tmp_yyy.yyy.yyy.yyy45309_2)] SUB-1002 : Close
2013-04-02 23:59:21,538 INFO [pool-1-thread-23]
rawloggers.Log4jMessageLogger (Log4jMessageLogger.java:69) - MESSAGE
[con:199(x@/yyy.yyy.yyy.yyy:45309/ZZZ)]
[vh(/ZZZ)/ex(topic/amq.topic)/qu(tmp_yyy.yyy.yyy.yyy45309_2)/rk(XXX_Topic)]
BND-1002 : Deleted
2013-04-02 23:59:21,538 INFO [pool-1-thread-23]
rawloggers.Log4jMessageLogger (Log4jMessageLogger.java:69) - MESSAGE
[con:199(x@/yyy.yyy.yyy.yyy:45309/ZZZ)]
[vh(/ZZZ)/ex(direct/default)/qu(tmp_yyy.yyy.yyy.yyy45309_2)/rk(tmp_yyy.yyy.yyy.yyy45309_2)]
BND-1002 : Deleted
2013-04-02 23:59:21,538 INFO [pool-1-thread-23]
rawloggers.Log4jMessageLogger (Log4jMessageLogger.java:69) - MESSAGE
[con:199(x@/yyy.yyy.yyy.yyy:45309/ZZZ)]
[vh(/ZZZ)/qu(tmp_yyy.yyy.yyy.yyy45309_2)] QUE-1002 : Deleted
{noformat}
Queue depth alerts continue even though the queue should have been deleted.
Note that the depth is actually increasing, indicating that message are still
being enqueued.
{noformat}
2013-04-03 05:22:34,463 INFO [pool-1-thread-14] queue.AMQQueueMBean
(AMQQueueMBean.java:336) - QUEUE_DEPTH_ALERT On Queue
tmp_yyy.yyy.yyy.yyy45309_2 - 4136Kb : Maximum queue depth threshold (4136Kb)
breached.
2013-04-03 05:23:08,343 INFO [pool-1-thread-11] queue.AMQQueueMBean
(AMQQueueMBean.java:336) - QUEUE_DEPTH_ALERT On Queue
tmp_yyy.yyy.yyy.yyy45309_2 - 8570Kb : Maximum queue depth threshold (4136Kb)
breached.
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4731) Java Broker: topic subscription with selector bug can silently prevent temporary queue deletion
[
https://issues.apache.org/jira/browse/QPID-4731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13633936#comment-13633936
]
Keith Wall commented on QPID-4731:
--
There were circumstances where this defect could cause a stack trace. For
completeness I will describe this here.
In a scenario where the Broker has no other queues defined, if, following the
failed attempt to deregister the topic subscriber's temporary queue further
messages are enqueued, the following stack trace results and the client's
connection abruptly closed.
This occurs because ReferenceCountingExecutorService has shutdown the
ThreadPoolExecutor (as no-one remains using it). The erroneous enqueue tries
to run a deliverAsync using the shutdown executor. This is rightfully rejected
with the REE.
{noformat}
IoReceiver - /127.0.0.1:54939 2013-04-17 10:43:18,803 ERROR
[qpid.server.protocol.AMQProtocolEngine] Unexpected exception when processing
datablock
java.util.concurrent.RejectedExecutionException
at
java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1768)
at
java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)
at
java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)
at
org.apache.qpid.server.queue.QueueRunner.execute(QueueRunner.java:118)
at
org.apache.qpid.server.queue.SimpleAMQQueue.deliverAsync(SimpleAMQQueue.java:1530)
at
org.apache.qpid.server.queue.SimpleAMQQueue.enqueue(SimpleAMQQueue.java:718)
at
org.apache.qpid.server.AMQChannel$MessageDeliveryAction.postCommit(AMQChannel.java:1190)
at
org.apache.qpid.server.AMQChannel$AsyncCommand.complete(AMQChannel.java:1583)
at org.apache.qpid.server.AMQChannel.sync(AMQChannel.java:1553)
at
org.apache.qpid.server.AMQChannel.receivedComplete(AMQChannel.java:221)
at
org.apache.qpid.server.protocol.AMQProtocolEngine.receiveComplete(AMQProtocolEngine.java:267)
at
org.apache.qpid.server.protocol.AMQProtocolEngine.received(AMQProtocolEngine.java:250)
at
org.apache.qpid.server.protocol.AMQProtocolEngine.received(AMQProtocolEngine.java:81)
at
org.apache.qpid.server.protocol.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:118)
at
org.apache.qpid.server.protocol.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:37)
at
org.apache.qpid.transport.network.io.IoReceiver.run(IoReceiver.java:161)
at java.lang.Thread.run(Thread.java:662)
{noformat}
Java Broker: topic subscription with selector bug can silently prevent
temporary queue deletion
---
Key: QPID-4731
URL: https://issues.apache.org/jira/browse/QPID-4731
Project: Qpid
Issue Type: Bug
Components: Java Broker
Affects Versions: 0.6, 0.8, 0.10, 0.12, 0.14, 0.16, 0.18, 0.20
Reporter: Philip Harvey
Assignee: Philip Harvey
When JMS selectors are used with topics, the attempt to deregister the topic
subscriber's temporary queue can silently fail. This leaves the queue bound
to the exchange, thereby allowing messages to continue being sent to it.
This is shown in the following log excerpts from a v0.5 Broker:
Initial set-up of topic with selector:
{noformat}
2013-04-02 04:11:51,947 INFO [pool-1-thread-22]
rawloggers.Log4jMessageLogger (Log4jMessageLogger.java:69) - MESSAGE
[con:199(x@/yyy.yyy.yyy.yyy:45309/ZZZ)/ch:1]
[vh(/ZZZ)/qu(tmp_yyy.yyy.yyy.yyy45309_2)] QUE-1001 : Create : Owner: xxx
AutoDelete Transient
2013-04-02 04:11:51,949 INFO [pool-1-thread-22]
rawloggers.Log4jMessageLogger (Log4jMessageLogger.java:69) - MESSAGE
[con:199(x@/yyy.yyy.yyy.yyy:45309/ZZZ)/ch:1]
[vh(/ZZZ)/ex(direct/default)/qu(tmp_yyy.yyy.yyy.yyy45309_2)/rk(tmp_yyy.yyy.yyy.yyy45309_2)]
BND-1001 : Create
2013-04-02 04:11:51,957 INFO [pool-1-thread-23]
rawloggers.Log4jMessageLogger (Log4jMessageLogger.java:69) - MESSAGE
[con:199(x@/yyy.yyy.yyy.yyy:45309/ZZZ)/ch:1]
[vh(/ZZZ)/ex(topic/amq.topic)/qu(tmp_yyy.yyy.yyy.yyy45309_2)/rk(XXX_Topic)]
BND-1001 : Create : Arguments : {x-filter-jms-selector=[LONG_STRING:
XXX_GROUP='x']}
2013-04-02 04:11:51,977 INFO [pool-1-thread-15]
rawloggers.Log4jMessageLogger (Log4jMessageLogger.java:69) - MESSAGE
[con:199(x@/yyy.yyy.yyy.yyy:45309/ZZZ)/ch:1]
[sub:4,117(vh(/ZZZ)/qu(tmp_yyy.yyy.yyy.yyy45309_2)] SUB-1001 : Create :
Arguments : JMSSelector(XXX_GROUP='x')
2013-04-02 14:14:02,663 INFO [pool-1-thread-30] queue.AMQQueueMBean
(AMQQueueMBean.java:336) - QUEUE_DEPTH_ALERT On Queue
tmp_yyy.yyy.yyy.yyy45309_2 - 4137Kb : Maximum queue depth threshold (4136Kb)
breached.
{noformat}
Subsequent topic
[jira] [Updated] (QPID-4731) Java Broker: topic subscription with selector bug can silently prevent temporary queue deletion
[
https://issues.apache.org/jira/browse/QPID-4731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-4731:
-
Status: Ready To Review (was: In Progress)
Java Broker: topic subscription with selector bug can silently prevent
temporary queue deletion
---
Key: QPID-4731
URL: https://issues.apache.org/jira/browse/QPID-4731
Project: Qpid
Issue Type: Bug
Components: Java Broker
Affects Versions: 0.6, 0.8, 0.10, 0.12, 0.14, 0.16, 0.18, 0.20
Reporter: Philip Harvey
Assignee: Philip Harvey
When JMS selectors are used with topics, the attempt to deregister the topic
subscriber's temporary queue can silently fail. This leaves the queue bound
to the exchange, thereby allowing messages to continue being sent to it.
This is shown in the following log excerpts from a v0.5 Broker:
Initial set-up of topic with selector:
{noformat}
2013-04-02 04:11:51,947 INFO [pool-1-thread-22]
rawloggers.Log4jMessageLogger (Log4jMessageLogger.java:69) - MESSAGE
[con:199(x@/yyy.yyy.yyy.yyy:45309/ZZZ)/ch:1]
[vh(/ZZZ)/qu(tmp_yyy.yyy.yyy.yyy45309_2)] QUE-1001 : Create : Owner: xxx
AutoDelete Transient
2013-04-02 04:11:51,949 INFO [pool-1-thread-22]
rawloggers.Log4jMessageLogger (Log4jMessageLogger.java:69) - MESSAGE
[con:199(x@/yyy.yyy.yyy.yyy:45309/ZZZ)/ch:1]
[vh(/ZZZ)/ex(direct/default)/qu(tmp_yyy.yyy.yyy.yyy45309_2)/rk(tmp_yyy.yyy.yyy.yyy45309_2)]
BND-1001 : Create
2013-04-02 04:11:51,957 INFO [pool-1-thread-23]
rawloggers.Log4jMessageLogger (Log4jMessageLogger.java:69) - MESSAGE
[con:199(x@/yyy.yyy.yyy.yyy:45309/ZZZ)/ch:1]
[vh(/ZZZ)/ex(topic/amq.topic)/qu(tmp_yyy.yyy.yyy.yyy45309_2)/rk(XXX_Topic)]
BND-1001 : Create : Arguments : {x-filter-jms-selector=[LONG_STRING:
XXX_GROUP='x']}
2013-04-02 04:11:51,977 INFO [pool-1-thread-15]
rawloggers.Log4jMessageLogger (Log4jMessageLogger.java:69) - MESSAGE
[con:199(x@/yyy.yyy.yyy.yyy:45309/ZZZ)/ch:1]
[sub:4,117(vh(/ZZZ)/qu(tmp_yyy.yyy.yyy.yyy45309_2)] SUB-1001 : Create :
Arguments : JMSSelector(XXX_GROUP='x')
2013-04-02 14:14:02,663 INFO [pool-1-thread-30] queue.AMQQueueMBean
(AMQQueueMBean.java:336) - QUEUE_DEPTH_ALERT On Queue
tmp_yyy.yyy.yyy.yyy45309_2 - 4137Kb : Maximum queue depth threshold (4136Kb)
breached.
{noformat}
Subsequent topic consumer close:
{noformat}
2013-04-02 23:59:21,538 INFO [pool-1-thread-23]
rawloggers.Log4jMessageLogger (Log4jMessageLogger.java:69) - MESSAGE
[con:199(x@/yyy.yyy.yyy.yyy:45309/ZZZ)]
[sub:4,117(vh(/ZZZ)/qu(tmp_yyy.yyy.yyy.yyy45309_2)] SUB-1002 : Close
2013-04-02 23:59:21,538 INFO [pool-1-thread-23]
rawloggers.Log4jMessageLogger (Log4jMessageLogger.java:69) - MESSAGE
[con:199(x@/yyy.yyy.yyy.yyy:45309/ZZZ)]
[vh(/ZZZ)/ex(topic/amq.topic)/qu(tmp_yyy.yyy.yyy.yyy45309_2)/rk(XXX_Topic)]
BND-1002 : Deleted
2013-04-02 23:59:21,538 INFO [pool-1-thread-23]
rawloggers.Log4jMessageLogger (Log4jMessageLogger.java:69) - MESSAGE
[con:199(x@/yyy.yyy.yyy.yyy:45309/ZZZ)]
[vh(/ZZZ)/ex(direct/default)/qu(tmp_yyy.yyy.yyy.yyy45309_2)/rk(tmp_yyy.yyy.yyy.yyy45309_2)]
BND-1002 : Deleted
2013-04-02 23:59:21,538 INFO [pool-1-thread-23]
rawloggers.Log4jMessageLogger (Log4jMessageLogger.java:69) - MESSAGE
[con:199(x@/yyy.yyy.yyy.yyy:45309/ZZZ)]
[vh(/ZZZ)/qu(tmp_yyy.yyy.yyy.yyy45309_2)] QUE-1002 : Deleted
{noformat}
Queue depth alerts continue even though the queue should have been deleted.
Note that the depth is actually increasing, indicating that message are still
being enqueued.
{noformat}
2013-04-03 05:22:34,463 INFO [pool-1-thread-14] queue.AMQQueueMBean
(AMQQueueMBean.java:336) - QUEUE_DEPTH_ALERT On Queue
tmp_yyy.yyy.yyy.yyy45309_2 - 4136Kb : Maximum queue depth threshold (4136Kb)
breached.
2013-04-03 05:23:08,343 INFO [pool-1-thread-11] queue.AMQQueueMBean
(AMQQueueMBean.java:336) - QUEUE_DEPTH_ALERT On Queue
tmp_yyy.yyy.yyy.yyy45309_2 - 8570Kb : Maximum queue depth threshold (4136Kb)
breached.
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-4731) Java Broker: topic subscription with selector bug can silently prevent temporary queue deletion
[
https://issues.apache.org/jira/browse/QPID-4731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13633936#comment-13633936
]
Keith Wall edited comment on QPID-4731 at 4/17/13 10:14 AM:
There were circumstances where this defect could cause a stack trace. For
completeness I will describe this here.
In a scenario where the Broker has no other queues defined, if, following the
failed attempt to deregister the topic subscriber's temporary queue further
messages are enqueued, the following stack trace results and the client's
connection is abruptly closed.
This occurs because ReferenceCountingExecutorService has shutdown the
ThreadPoolExecutor (as no-one remains using it). The erroneous enqueue tries
to run a deliverAsync using the shutdown executor. This is rightfully rejected
with the REE.
{noformat}
IoReceiver - /127.0.0.1:54939 2013-04-17 10:43:18,803 ERROR
[qpid.server.protocol.AMQProtocolEngine] Unexpected exception when processing
datablock
java.util.concurrent.RejectedExecutionException
at
java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1768)
at
java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)
at
java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)
at
org.apache.qpid.server.queue.QueueRunner.execute(QueueRunner.java:118)
at
org.apache.qpid.server.queue.SimpleAMQQueue.deliverAsync(SimpleAMQQueue.java:1530)
at
org.apache.qpid.server.queue.SimpleAMQQueue.enqueue(SimpleAMQQueue.java:718)
at
org.apache.qpid.server.AMQChannel$MessageDeliveryAction.postCommit(AMQChannel.java:1190)
at
org.apache.qpid.server.AMQChannel$AsyncCommand.complete(AMQChannel.java:1583)
at org.apache.qpid.server.AMQChannel.sync(AMQChannel.java:1553)
at
org.apache.qpid.server.AMQChannel.receivedComplete(AMQChannel.java:221)
at
org.apache.qpid.server.protocol.AMQProtocolEngine.receiveComplete(AMQProtocolEngine.java:267)
at
org.apache.qpid.server.protocol.AMQProtocolEngine.received(AMQProtocolEngine.java:250)
at
org.apache.qpid.server.protocol.AMQProtocolEngine.received(AMQProtocolEngine.java:81)
at
org.apache.qpid.server.protocol.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:118)
at
org.apache.qpid.server.protocol.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:37)
at
org.apache.qpid.transport.network.io.IoReceiver.run(IoReceiver.java:161)
at java.lang.Thread.run(Thread.java:662)
{noformat}
was (Author: k-wall):
There were circumstances where this defect could cause a stack trace. For
completeness I will describe this here.
In a scenario where the Broker has no other queues defined, if, following the
failed attempt to deregister the topic subscriber's temporary queue further
messages are enqueued, the following stack trace results and the client's
connection abruptly closed.
This occurs because ReferenceCountingExecutorService has shutdown the
ThreadPoolExecutor (as no-one remains using it). The erroneous enqueue tries
to run a deliverAsync using the shutdown executor. This is rightfully rejected
with the REE.
{noformat}
IoReceiver - /127.0.0.1:54939 2013-04-17 10:43:18,803 ERROR
[qpid.server.protocol.AMQProtocolEngine] Unexpected exception when processing
datablock
java.util.concurrent.RejectedExecutionException
at
java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1768)
at
java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)
at
java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)
at
org.apache.qpid.server.queue.QueueRunner.execute(QueueRunner.java:118)
at
org.apache.qpid.server.queue.SimpleAMQQueue.deliverAsync(SimpleAMQQueue.java:1530)
at
org.apache.qpid.server.queue.SimpleAMQQueue.enqueue(SimpleAMQQueue.java:718)
at
org.apache.qpid.server.AMQChannel$MessageDeliveryAction.postCommit(AMQChannel.java:1190)
at
org.apache.qpid.server.AMQChannel$AsyncCommand.complete(AMQChannel.java:1583)
at org.apache.qpid.server.AMQChannel.sync(AMQChannel.java:1553)
at
org.apache.qpid.server.AMQChannel.receivedComplete(AMQChannel.java:221)
at
org.apache.qpid.server.protocol.AMQProtocolEngine.receiveComplete(AMQProtocolEngine.java:267)
at
org.apache.qpid.server.protocol.AMQProtocolEngine.received(AMQProtocolEngine.java:250)
at
org.apache.qpid.server.protocol.AMQProtocolEngine.received(AMQProtocolEngine.java:81)
at
org.apache.qpid.server.protocol.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:118)
at
[jira] [Comment Edited] (QPID-4731) Java Broker: topic subscription with selector bug can silently prevent temporary queue deletion
[
https://issues.apache.org/jira/browse/QPID-4731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13633936#comment-13633936
]
Keith Wall edited comment on QPID-4731 at 4/17/13 10:21 AM:
There were circumstances where this defect could cause a stack trace. For
completeness I will describe this here.
In a scenario where the Broker has no other queues defined, if, following the
failed attempt to deregister the topic subscriber's temporary queue further
messages are enqueued, the following stack trace results and the client's
connection is abruptly closed.
This occurs because ReferenceCountingExecutorService has shutdown the
ThreadPoolExecutor (as no-one remains using it). The erroneous enqueue tries
to run a deliverAsync using the shutdown executor. This is rightfully rejected
with the REE.
There is no further work required to address this aspect - the changes made for
this Jira and QPID-3997 (the belt and braces) are sufficient.
{noformat}
IoReceiver - /127.0.0.1:54939 2013-04-17 10:43:18,803 ERROR
[qpid.server.protocol.AMQProtocolEngine] Unexpected exception when processing
datablock
java.util.concurrent.RejectedExecutionException
at
java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1768)
at
java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)
at
java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)
at
org.apache.qpid.server.queue.QueueRunner.execute(QueueRunner.java:118)
at
org.apache.qpid.server.queue.SimpleAMQQueue.deliverAsync(SimpleAMQQueue.java:1530)
at
org.apache.qpid.server.queue.SimpleAMQQueue.enqueue(SimpleAMQQueue.java:718)
at
org.apache.qpid.server.AMQChannel$MessageDeliveryAction.postCommit(AMQChannel.java:1190)
at
org.apache.qpid.server.AMQChannel$AsyncCommand.complete(AMQChannel.java:1583)
at org.apache.qpid.server.AMQChannel.sync(AMQChannel.java:1553)
at
org.apache.qpid.server.AMQChannel.receivedComplete(AMQChannel.java:221)
at
org.apache.qpid.server.protocol.AMQProtocolEngine.receiveComplete(AMQProtocolEngine.java:267)
at
org.apache.qpid.server.protocol.AMQProtocolEngine.received(AMQProtocolEngine.java:250)
at
org.apache.qpid.server.protocol.AMQProtocolEngine.received(AMQProtocolEngine.java:81)
at
org.apache.qpid.server.protocol.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:118)
at
org.apache.qpid.server.protocol.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:37)
at
org.apache.qpid.transport.network.io.IoReceiver.run(IoReceiver.java:161)
at java.lang.Thread.run(Thread.java:662)
{noformat}
was (Author: k-wall):
There were circumstances where this defect could cause a stack trace. For
completeness I will describe this here.
In a scenario where the Broker has no other queues defined, if, following the
failed attempt to deregister the topic subscriber's temporary queue further
messages are enqueued, the following stack trace results and the client's
connection is abruptly closed.
This occurs because ReferenceCountingExecutorService has shutdown the
ThreadPoolExecutor (as no-one remains using it). The erroneous enqueue tries
to run a deliverAsync using the shutdown executor. This is rightfully rejected
with the REE.
{noformat}
IoReceiver - /127.0.0.1:54939 2013-04-17 10:43:18,803 ERROR
[qpid.server.protocol.AMQProtocolEngine] Unexpected exception when processing
datablock
java.util.concurrent.RejectedExecutionException
at
java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1768)
at
java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)
at
java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)
at
org.apache.qpid.server.queue.QueueRunner.execute(QueueRunner.java:118)
at
org.apache.qpid.server.queue.SimpleAMQQueue.deliverAsync(SimpleAMQQueue.java:1530)
at
org.apache.qpid.server.queue.SimpleAMQQueue.enqueue(SimpleAMQQueue.java:718)
at
org.apache.qpid.server.AMQChannel$MessageDeliveryAction.postCommit(AMQChannel.java:1190)
at
org.apache.qpid.server.AMQChannel$AsyncCommand.complete(AMQChannel.java:1583)
at org.apache.qpid.server.AMQChannel.sync(AMQChannel.java:1553)
at
org.apache.qpid.server.AMQChannel.receivedComplete(AMQChannel.java:221)
at
org.apache.qpid.server.protocol.AMQProtocolEngine.receiveComplete(AMQProtocolEngine.java:267)
at
org.apache.qpid.server.protocol.AMQProtocolEngine.received(AMQProtocolEngine.java:250)
at
org.apache.qpid.server.protocol.AMQProtocolEngine.received(AMQProtocolEngine.java:81)
at
[jira] [Comment Edited] (QPID-4731) Java Broker: topic subscription with selector bug can silently prevent temporary queue deletion
[
https://issues.apache.org/jira/browse/QPID-4731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13633936#comment-13633936
]
Keith Wall edited comment on QPID-4731 at 4/17/13 10:21 AM:
There were circumstances where this defect could cause a stack trace. For
completeness I will describe this here.
In a scenario where the Broker has no other queues defined, if, following the
failed attempt to deregister the topic subscriber's temporary queue further
messages are enqueued, the following stack trace results and the client's
connection is abruptly closed.
This occurs because ReferenceCountingExecutorService has shutdown the
ThreadPoolExecutor (as no-one remains using it). The erroneous enqueue tries
to run a deliverAsync using the shutdown executor. This is rightfully rejected
with the REE.
There is no further work required to address this aspect. The changes made for
this Jira and QPID-3997 (the belt and braces) are sufficient.
{noformat}
IoReceiver - /127.0.0.1:54939 2013-04-17 10:43:18,803 ERROR
[qpid.server.protocol.AMQProtocolEngine] Unexpected exception when processing
datablock
java.util.concurrent.RejectedExecutionException
at
java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1768)
at
java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)
at
java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)
at
org.apache.qpid.server.queue.QueueRunner.execute(QueueRunner.java:118)
at
org.apache.qpid.server.queue.SimpleAMQQueue.deliverAsync(SimpleAMQQueue.java:1530)
at
org.apache.qpid.server.queue.SimpleAMQQueue.enqueue(SimpleAMQQueue.java:718)
at
org.apache.qpid.server.AMQChannel$MessageDeliveryAction.postCommit(AMQChannel.java:1190)
at
org.apache.qpid.server.AMQChannel$AsyncCommand.complete(AMQChannel.java:1583)
at org.apache.qpid.server.AMQChannel.sync(AMQChannel.java:1553)
at
org.apache.qpid.server.AMQChannel.receivedComplete(AMQChannel.java:221)
at
org.apache.qpid.server.protocol.AMQProtocolEngine.receiveComplete(AMQProtocolEngine.java:267)
at
org.apache.qpid.server.protocol.AMQProtocolEngine.received(AMQProtocolEngine.java:250)
at
org.apache.qpid.server.protocol.AMQProtocolEngine.received(AMQProtocolEngine.java:81)
at
org.apache.qpid.server.protocol.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:118)
at
org.apache.qpid.server.protocol.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:37)
at
org.apache.qpid.transport.network.io.IoReceiver.run(IoReceiver.java:161)
at java.lang.Thread.run(Thread.java:662)
{noformat}
was (Author: k-wall):
There were circumstances where this defect could cause a stack trace. For
completeness I will describe this here.
In a scenario where the Broker has no other queues defined, if, following the
failed attempt to deregister the topic subscriber's temporary queue further
messages are enqueued, the following stack trace results and the client's
connection is abruptly closed.
This occurs because ReferenceCountingExecutorService has shutdown the
ThreadPoolExecutor (as no-one remains using it). The erroneous enqueue tries
to run a deliverAsync using the shutdown executor. This is rightfully rejected
with the REE.
There is no further work required to address this aspect - the changes made for
this Jira and QPID-3997 (the belt and braces) are sufficient.
{noformat}
IoReceiver - /127.0.0.1:54939 2013-04-17 10:43:18,803 ERROR
[qpid.server.protocol.AMQProtocolEngine] Unexpected exception when processing
datablock
java.util.concurrent.RejectedExecutionException
at
java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1768)
at
java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)
at
java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)
at
org.apache.qpid.server.queue.QueueRunner.execute(QueueRunner.java:118)
at
org.apache.qpid.server.queue.SimpleAMQQueue.deliverAsync(SimpleAMQQueue.java:1530)
at
org.apache.qpid.server.queue.SimpleAMQQueue.enqueue(SimpleAMQQueue.java:718)
at
org.apache.qpid.server.AMQChannel$MessageDeliveryAction.postCommit(AMQChannel.java:1190)
at
org.apache.qpid.server.AMQChannel$AsyncCommand.complete(AMQChannel.java:1583)
at org.apache.qpid.server.AMQChannel.sync(AMQChannel.java:1553)
at
org.apache.qpid.server.AMQChannel.receivedComplete(AMQChannel.java:221)
at
org.apache.qpid.server.protocol.AMQProtocolEngine.receiveComplete(AMQProtocolEngine.java:267)
at
org.apache.qpid.server.protocol.AMQProtocolEngine.received(AMQProtocolEngine.java:250)
[jira] [Comment Edited] (QPID-4731) Java Broker: topic subscription with selector bug can silently prevent temporary queue deletion
[
https://issues.apache.org/jira/browse/QPID-4731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13633936#comment-13633936
]
Keith Wall edited comment on QPID-4731 at 4/17/13 10:24 AM:
There were circumstances where this defect could cause a stack trace. For
completeness I will describe this here.
In a scenario where the Broker has no other queues defined, if, following the
failed attempt to deregister the topic subscriber's temporary queue further
messages are enqueued, the following stack trace results and the client's
connection is abruptly closed.
This occurs because ReferenceCountingExecutorService has shutdown the
ThreadPoolExecutor (as no acquisitions remain). The erroneous enqueue tries to
run a deliverAsync using the shutdown executor. This is rightfully rejected
with the REE.
There is no further work required to address this aspect. The changes made for
this Jira and QPID-3997 (the belt and braces change to guard against enqueues
to deleted queues) are sufficient.
{noformat}
IoReceiver - /127.0.0.1:54939 2013-04-17 10:43:18,803 ERROR
[qpid.server.protocol.AMQProtocolEngine] Unexpected exception when processing
datablock
java.util.concurrent.RejectedExecutionException
at
java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1768)
at
java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)
at
java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)
at
org.apache.qpid.server.queue.QueueRunner.execute(QueueRunner.java:118)
at
org.apache.qpid.server.queue.SimpleAMQQueue.deliverAsync(SimpleAMQQueue.java:1530)
at
org.apache.qpid.server.queue.SimpleAMQQueue.enqueue(SimpleAMQQueue.java:718)
at
org.apache.qpid.server.AMQChannel$MessageDeliveryAction.postCommit(AMQChannel.java:1190)
at
org.apache.qpid.server.AMQChannel$AsyncCommand.complete(AMQChannel.java:1583)
at org.apache.qpid.server.AMQChannel.sync(AMQChannel.java:1553)
at
org.apache.qpid.server.AMQChannel.receivedComplete(AMQChannel.java:221)
at
org.apache.qpid.server.protocol.AMQProtocolEngine.receiveComplete(AMQProtocolEngine.java:267)
at
org.apache.qpid.server.protocol.AMQProtocolEngine.received(AMQProtocolEngine.java:250)
at
org.apache.qpid.server.protocol.AMQProtocolEngine.received(AMQProtocolEngine.java:81)
at
org.apache.qpid.server.protocol.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:118)
at
org.apache.qpid.server.protocol.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:37)
at
org.apache.qpid.transport.network.io.IoReceiver.run(IoReceiver.java:161)
at java.lang.Thread.run(Thread.java:662)
{noformat}
was (Author: k-wall):
There were circumstances where this defect could cause a stack trace. For
completeness I will describe this here.
In a scenario where the Broker has no other queues defined, if, following the
failed attempt to deregister the topic subscriber's temporary queue further
messages are enqueued, the following stack trace results and the client's
connection is abruptly closed.
This occurs because ReferenceCountingExecutorService has shutdown the
ThreadPoolExecutor (as no-one remains using it). The erroneous enqueue tries
to run a deliverAsync using the shutdown executor. This is rightfully rejected
with the REE.
There is no further work required to address this aspect. The changes made for
this Jira and QPID-3997 (the belt and braces) are sufficient.
{noformat}
IoReceiver - /127.0.0.1:54939 2013-04-17 10:43:18,803 ERROR
[qpid.server.protocol.AMQProtocolEngine] Unexpected exception when processing
datablock
java.util.concurrent.RejectedExecutionException
at
java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1768)
at
java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)
at
java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)
at
org.apache.qpid.server.queue.QueueRunner.execute(QueueRunner.java:118)
at
org.apache.qpid.server.queue.SimpleAMQQueue.deliverAsync(SimpleAMQQueue.java:1530)
at
org.apache.qpid.server.queue.SimpleAMQQueue.enqueue(SimpleAMQQueue.java:718)
at
org.apache.qpid.server.AMQChannel$MessageDeliveryAction.postCommit(AMQChannel.java:1190)
at
org.apache.qpid.server.AMQChannel$AsyncCommand.complete(AMQChannel.java:1583)
at org.apache.qpid.server.AMQChannel.sync(AMQChannel.java:1553)
at
org.apache.qpid.server.AMQChannel.receivedComplete(AMQChannel.java:221)
at
org.apache.qpid.server.protocol.AMQProtocolEngine.receiveComplete(AMQProtocolEngine.java:267)
at
[jira] [Created] (QPID-4746) [Java Broker] add an overriding management-mode authentication provider to restrict access to specific management mode user
Robbie Gemmell created QPID-4746: Summary: [Java Broker] add an overriding management-mode authentication provider to restrict access to specific management mode user Key: QPID-4746 URL: https://issues.apache.org/jira/browse/QPID-4746 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.22 QPID-4594 added a command line option to start the broker in a specific management-mode, where the AMQP ports are disabled and the management ports can be chosen from the command line if necessary, in order to allow an administrator to configure the broker via the management interfaces in isolation of regular usage. To make this mode fully effective, the regular authentication providers configured for each port will be overridden with a management-mode specific authentication provider which will permit only the user 'mm_admin' to connect, with a randomly generated password (with option to set if necessary) details emitted to the console at startup. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-4731) Java Broker: topic subscription with selector bug can silently prevent temporary queue deletion
[
https://issues.apache.org/jira/browse/QPID-4731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Harvey resolved QPID-4731.
-
Resolution: Fixed
Fix Version/s: 0.21
Java Broker: topic subscription with selector bug can silently prevent
temporary queue deletion
---
Key: QPID-4731
URL: https://issues.apache.org/jira/browse/QPID-4731
Project: Qpid
Issue Type: Bug
Components: Java Broker
Affects Versions: 0.6, 0.8, 0.10, 0.12, 0.14, 0.16, 0.18, 0.20
Reporter: Philip Harvey
Assignee: Philip Harvey
Fix For: 0.21
When JMS selectors are used with topics, the attempt to deregister the topic
subscriber's temporary queue can silently fail. This leaves the queue bound
to the exchange, thereby allowing messages to continue being sent to it.
This is shown in the following log excerpts from a v0.5 Broker:
Initial set-up of topic with selector:
{noformat}
2013-04-02 04:11:51,947 INFO [pool-1-thread-22]
rawloggers.Log4jMessageLogger (Log4jMessageLogger.java:69) - MESSAGE
[con:199(x@/yyy.yyy.yyy.yyy:45309/ZZZ)/ch:1]
[vh(/ZZZ)/qu(tmp_yyy.yyy.yyy.yyy45309_2)] QUE-1001 : Create : Owner: xxx
AutoDelete Transient
2013-04-02 04:11:51,949 INFO [pool-1-thread-22]
rawloggers.Log4jMessageLogger (Log4jMessageLogger.java:69) - MESSAGE
[con:199(x@/yyy.yyy.yyy.yyy:45309/ZZZ)/ch:1]
[vh(/ZZZ)/ex(direct/default)/qu(tmp_yyy.yyy.yyy.yyy45309_2)/rk(tmp_yyy.yyy.yyy.yyy45309_2)]
BND-1001 : Create
2013-04-02 04:11:51,957 INFO [pool-1-thread-23]
rawloggers.Log4jMessageLogger (Log4jMessageLogger.java:69) - MESSAGE
[con:199(x@/yyy.yyy.yyy.yyy:45309/ZZZ)/ch:1]
[vh(/ZZZ)/ex(topic/amq.topic)/qu(tmp_yyy.yyy.yyy.yyy45309_2)/rk(XXX_Topic)]
BND-1001 : Create : Arguments : {x-filter-jms-selector=[LONG_STRING:
XXX_GROUP='x']}
2013-04-02 04:11:51,977 INFO [pool-1-thread-15]
rawloggers.Log4jMessageLogger (Log4jMessageLogger.java:69) - MESSAGE
[con:199(x@/yyy.yyy.yyy.yyy:45309/ZZZ)/ch:1]
[sub:4,117(vh(/ZZZ)/qu(tmp_yyy.yyy.yyy.yyy45309_2)] SUB-1001 : Create :
Arguments : JMSSelector(XXX_GROUP='x')
2013-04-02 14:14:02,663 INFO [pool-1-thread-30] queue.AMQQueueMBean
(AMQQueueMBean.java:336) - QUEUE_DEPTH_ALERT On Queue
tmp_yyy.yyy.yyy.yyy45309_2 - 4137Kb : Maximum queue depth threshold (4136Kb)
breached.
{noformat}
Subsequent topic consumer close:
{noformat}
2013-04-02 23:59:21,538 INFO [pool-1-thread-23]
rawloggers.Log4jMessageLogger (Log4jMessageLogger.java:69) - MESSAGE
[con:199(x@/yyy.yyy.yyy.yyy:45309/ZZZ)]
[sub:4,117(vh(/ZZZ)/qu(tmp_yyy.yyy.yyy.yyy45309_2)] SUB-1002 : Close
2013-04-02 23:59:21,538 INFO [pool-1-thread-23]
rawloggers.Log4jMessageLogger (Log4jMessageLogger.java:69) - MESSAGE
[con:199(x@/yyy.yyy.yyy.yyy:45309/ZZZ)]
[vh(/ZZZ)/ex(topic/amq.topic)/qu(tmp_yyy.yyy.yyy.yyy45309_2)/rk(XXX_Topic)]
BND-1002 : Deleted
2013-04-02 23:59:21,538 INFO [pool-1-thread-23]
rawloggers.Log4jMessageLogger (Log4jMessageLogger.java:69) - MESSAGE
[con:199(x@/yyy.yyy.yyy.yyy:45309/ZZZ)]
[vh(/ZZZ)/ex(direct/default)/qu(tmp_yyy.yyy.yyy.yyy45309_2)/rk(tmp_yyy.yyy.yyy.yyy45309_2)]
BND-1002 : Deleted
2013-04-02 23:59:21,538 INFO [pool-1-thread-23]
rawloggers.Log4jMessageLogger (Log4jMessageLogger.java:69) - MESSAGE
[con:199(x@/yyy.yyy.yyy.yyy:45309/ZZZ)]
[vh(/ZZZ)/qu(tmp_yyy.yyy.yyy.yyy45309_2)] QUE-1002 : Deleted
{noformat}
Queue depth alerts continue even though the queue should have been deleted.
Note that the depth is actually increasing, indicating that message are still
being enqueued.
{noformat}
2013-04-03 05:22:34,463 INFO [pool-1-thread-14] queue.AMQQueueMBean
(AMQQueueMBean.java:336) - QUEUE_DEPTH_ALERT On Queue
tmp_yyy.yyy.yyy.yyy45309_2 - 4136Kb : Maximum queue depth threshold (4136Kb)
breached.
2013-04-03 05:23:08,343 INFO [pool-1-thread-11] queue.AMQQueueMBean
(AMQQueueMBean.java:336) - QUEUE_DEPTH_ALERT On Queue
tmp_yyy.yyy.yyy.yyy45309_2 - 8570Kb : Maximum queue depth threshold (4136Kb)
breached.
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4731) Java Broker: topic subscription with selector bug can silently prevent temporary queue deletion
[
https://issues.apache.org/jira/browse/QPID-4731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Harvey updated QPID-4731:
Fix Version/s: (was: 0.21)
0.23
Java Broker: topic subscription with selector bug can silently prevent
temporary queue deletion
---
Key: QPID-4731
URL: https://issues.apache.org/jira/browse/QPID-4731
Project: Qpid
Issue Type: Bug
Components: Java Broker
Affects Versions: 0.6, 0.8, 0.10, 0.12, 0.14, 0.16, 0.18, 0.20
Reporter: Philip Harvey
Assignee: Philip Harvey
Fix For: 0.23
When JMS selectors are used with topics, the attempt to deregister the topic
subscriber's temporary queue can silently fail. This leaves the queue bound
to the exchange, thereby allowing messages to continue being sent to it.
This is shown in the following log excerpts from a v0.5 Broker:
Initial set-up of topic with selector:
{noformat}
2013-04-02 04:11:51,947 INFO [pool-1-thread-22]
rawloggers.Log4jMessageLogger (Log4jMessageLogger.java:69) - MESSAGE
[con:199(x@/yyy.yyy.yyy.yyy:45309/ZZZ)/ch:1]
[vh(/ZZZ)/qu(tmp_yyy.yyy.yyy.yyy45309_2)] QUE-1001 : Create : Owner: xxx
AutoDelete Transient
2013-04-02 04:11:51,949 INFO [pool-1-thread-22]
rawloggers.Log4jMessageLogger (Log4jMessageLogger.java:69) - MESSAGE
[con:199(x@/yyy.yyy.yyy.yyy:45309/ZZZ)/ch:1]
[vh(/ZZZ)/ex(direct/default)/qu(tmp_yyy.yyy.yyy.yyy45309_2)/rk(tmp_yyy.yyy.yyy.yyy45309_2)]
BND-1001 : Create
2013-04-02 04:11:51,957 INFO [pool-1-thread-23]
rawloggers.Log4jMessageLogger (Log4jMessageLogger.java:69) - MESSAGE
[con:199(x@/yyy.yyy.yyy.yyy:45309/ZZZ)/ch:1]
[vh(/ZZZ)/ex(topic/amq.topic)/qu(tmp_yyy.yyy.yyy.yyy45309_2)/rk(XXX_Topic)]
BND-1001 : Create : Arguments : {x-filter-jms-selector=[LONG_STRING:
XXX_GROUP='x']}
2013-04-02 04:11:51,977 INFO [pool-1-thread-15]
rawloggers.Log4jMessageLogger (Log4jMessageLogger.java:69) - MESSAGE
[con:199(x@/yyy.yyy.yyy.yyy:45309/ZZZ)/ch:1]
[sub:4,117(vh(/ZZZ)/qu(tmp_yyy.yyy.yyy.yyy45309_2)] SUB-1001 : Create :
Arguments : JMSSelector(XXX_GROUP='x')
2013-04-02 14:14:02,663 INFO [pool-1-thread-30] queue.AMQQueueMBean
(AMQQueueMBean.java:336) - QUEUE_DEPTH_ALERT On Queue
tmp_yyy.yyy.yyy.yyy45309_2 - 4137Kb : Maximum queue depth threshold (4136Kb)
breached.
{noformat}
Subsequent topic consumer close:
{noformat}
2013-04-02 23:59:21,538 INFO [pool-1-thread-23]
rawloggers.Log4jMessageLogger (Log4jMessageLogger.java:69) - MESSAGE
[con:199(x@/yyy.yyy.yyy.yyy:45309/ZZZ)]
[sub:4,117(vh(/ZZZ)/qu(tmp_yyy.yyy.yyy.yyy45309_2)] SUB-1002 : Close
2013-04-02 23:59:21,538 INFO [pool-1-thread-23]
rawloggers.Log4jMessageLogger (Log4jMessageLogger.java:69) - MESSAGE
[con:199(x@/yyy.yyy.yyy.yyy:45309/ZZZ)]
[vh(/ZZZ)/ex(topic/amq.topic)/qu(tmp_yyy.yyy.yyy.yyy45309_2)/rk(XXX_Topic)]
BND-1002 : Deleted
2013-04-02 23:59:21,538 INFO [pool-1-thread-23]
rawloggers.Log4jMessageLogger (Log4jMessageLogger.java:69) - MESSAGE
[con:199(x@/yyy.yyy.yyy.yyy:45309/ZZZ)]
[vh(/ZZZ)/ex(direct/default)/qu(tmp_yyy.yyy.yyy.yyy45309_2)/rk(tmp_yyy.yyy.yyy.yyy45309_2)]
BND-1002 : Deleted
2013-04-02 23:59:21,538 INFO [pool-1-thread-23]
rawloggers.Log4jMessageLogger (Log4jMessageLogger.java:69) - MESSAGE
[con:199(x@/yyy.yyy.yyy.yyy:45309/ZZZ)]
[vh(/ZZZ)/qu(tmp_yyy.yyy.yyy.yyy45309_2)] QUE-1002 : Deleted
{noformat}
Queue depth alerts continue even though the queue should have been deleted.
Note that the depth is actually increasing, indicating that message are still
being enqueued.
{noformat}
2013-04-03 05:22:34,463 INFO [pool-1-thread-14] queue.AMQQueueMBean
(AMQQueueMBean.java:336) - QUEUE_DEPTH_ALERT On Queue
tmp_yyy.yyy.yyy.yyy45309_2 - 4136Kb : Maximum queue depth threshold (4136Kb)
breached.
2013-04-03 05:23:08,343 INFO [pool-1-thread-11] queue.AMQQueueMBean
(AMQQueueMBean.java:336) - QUEUE_DEPTH_ALERT On Queue
tmp_yyy.yyy.yyy.yyy45309_2 - 8570Kb : Maximum queue depth threshold (4136Kb)
breached.
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-4747) [Java Broker] make specifying the authentication provider mandatory on ports that use them and remove the defaultAuthenticationProvider attribute on the broker
Robbie Gemmell created QPID-4747: Summary: [Java Broker] make specifying the authentication provider mandatory on ports that use them and remove the defaultAuthenticationProvider attribute on the broker Key: QPID-4747 URL: https://issues.apache.org/jira/browse/QPID-4747 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.22 Make specifying the authentication provider mandatory on each port type that requires it and remove the defaultAuthenticationProvider attribute on the broker. The AMQP, JMX, HTTP ports are authenticated but the RMI registry port used to advertise the JMX connector isn't and cant make use of an authentication provider. The defaultAuthenticationProvider attribute makes this unclear, and uses some fairly ugly wiring up code at broker startup to make work, it should be removed and the currently optional per-port authenticationProvider attribute made mandatory on the port types that require it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4747) [Java Broker] make specifying the authentication provider mandatory on ports that use them and remove the defaultAuthenticationProvider attribute on the broker
[ https://issues.apache.org/jira/browse/QPID-4747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13633951#comment-13633951 ] Robbie Gemmell commented on QPID-4747: -- Change committed by Alex, worked on by both of us, reviewed by both of us: http://svn.apache.org/r1468830 Leaving JIRA open until merged to 0.22 branch [Java Broker] make specifying the authentication provider mandatory on ports that use them and remove the defaultAuthenticationProvider attribute on the broker --- Key: QPID-4747 URL: https://issues.apache.org/jira/browse/QPID-4747 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.22 Make specifying the authentication provider mandatory on each port type that requires it and remove the defaultAuthenticationProvider attribute on the broker. The AMQP, JMX, HTTP ports are authenticated but the RMI registry port used to advertise the JMX connector isn't and cant make use of an authentication provider. The defaultAuthenticationProvider attribute makes this unclear, and uses some fairly ugly wiring up code at broker startup to make work, it should be removed and the currently optional per-port authenticationProvider attribute made mandatory on the port types that require it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4746) [Java Broker] add an overriding management-mode authentication provider to restrict access to specific management mode user
[ https://issues.apache.org/jira/browse/QPID-4746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13633952#comment-13633952 ] Robbie Gemmell commented on QPID-4746: -- Change committed by Alex, worked on by both of us, reviewed by both of us: http://svn.apache.org/r1468830 Leaving JIRA open until merged to 0.22 branch [Java Broker] add an overriding management-mode authentication provider to restrict access to specific management mode user --- Key: QPID-4746 URL: https://issues.apache.org/jira/browse/QPID-4746 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.22 QPID-4594 added a command line option to start the broker in a specific management-mode, where the AMQP ports are disabled and the management ports can be chosen from the command line if necessary, in order to allow an administrator to configure the broker via the management interfaces in isolation of regular usage. To make this mode fully effective, the regular authentication providers configured for each port will be overridden with a management-mode specific authentication provider which will permit only the user 'mm_admin' to connect, with a randomly generated password (with option to set if necessary) details emitted to the console at startup. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Request for 0.22
https://issues.apache.org/jira/browse/QPID-4733 It's been reviewed and on trunk for 7 days now so should have been thru the various CI systems. Cheers Alan - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4733) Fix cmake installation of init scripts
[ https://issues.apache.org/jira/browse/QPID-4733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13634046#comment-13634046 ] Justin Ross commented on QPID-4733: --- Reviewed by Darryl. Approved for 0.22. Fix cmake installation of init scripts -- Key: QPID-4733 URL: https://issues.apache.org/jira/browse/QPID-4733 Project: Qpid Issue Type: Bug Reporter: Alan Conway Assignee: Alan Conway The cmake build does not correctly substitute and install the init scripts qpidd and qpidd-primary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-4736) Legacy store Recovery found log entries at wrong severity
[ https://issues.apache.org/jira/browse/QPID-4736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved QPID-4736. --- Resolution: Fixed Fix Version/s: 0.23 Fixed at Committed revision 1469054. Legacy store Recovery found log entries at wrong severity --- Key: QPID-4736 URL: https://issues.apache.org/jira/browse/QPID-4736 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.20 Reporter: Chuck Rolke Assignee: Chuck Rolke Priority: Minor Fix For: 0.23 These logs should have lower severity (recommending info), as they occur when number of files or file size differs from default. And it is normal to provision a journal with non-default parameters, thus info level is more appropriate than warning. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Review Request: QPID-4748: Consistent handling of durations in broker configuration, allowing sub-second intervals.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10595/ --- Review request for qpid, Andrew Stitcher and Gordon Sim. Description --- QPID-4748: Consistent handling of durations in broker configuration, allowing sub-second intervals. Allow intervals to be expressed as: 10 - value in seconds, backward compatible. 10s - value in seconds 10ms - value in milliseconds 10us - value in microseconds 10ns - value in nanoseconds This addresses bug QPID-4748. https://issues.apache.org/jira/browse/QPID-4748 Diffs - /trunk/qpid/cpp/include/qpid/sys/Time.h 1468953 /trunk/qpid/cpp/src/qpid/broker/Broker.h 1468953 /trunk/qpid/cpp/src/qpid/broker/Broker.cpp 1468953 /trunk/qpid/cpp/src/qpid/broker/ConnectionHandler.cpp 1468953 /trunk/qpid/cpp/src/qpid/ha/StatusCheck.h 1468953 /trunk/qpid/cpp/src/qpid/ha/StatusCheck.cpp 1468953 /trunk/qpid/cpp/src/qpid/sys/posix/Time.cpp 1468953 /trunk/qpid/cpp/src/tests/TimerTest.cpp 1468953 Diff: https://reviews.apache.org/r/10595/diff/ Testing --- Thanks, Alan Conway
