[jira] [Created] (QPID-5118) [JMS] Deadlock when closing a consumer and calling JMS operatons inside onMessage() on AMQP 0-8/0-9/0-9-1 connection
Philip Harvey created QPID-5118:
---
Summary: [JMS] Deadlock when closing a consumer and calling JMS
operatons inside onMessage() on AMQP 0-8/0-9/0-9-1 connection
Key: QPID-5118
URL: https://issues.apache.org/jira/browse/QPID-5118
Project: Qpid
Issue Type: Bug
Components: Java Client
Affects Versions: 0.22
Reporter: Philip Harvey
I have run the java systests with the [JCarder|http://jcarder.org/] agent
attached. When using AMQP 0-9, JCarder detected a potential deadlock when the
following are done concurrently:
* Close a consumer from an application thread.
* Call one of the JMS operations inside MessageListener.onMessage() that uses
AMQConnectionDelegate_8_0.executeRetrySupport(..).
Here is a sketch of the deadlock scenario:
{noformat}
Thread: Dispatcher-1-Conn-600
AMQSession$Dispatcher.dispatchMessage()
lock AMQSession.this._messageDeliveryLock
...
myMessageListener.onMessage()
execute failover-aware operation eg
createQueue, createProducer etc
AMQConnectionDelegate_8_0.executeRetrySupport
lock
AMQConnection.getFailoverMutex()
Thread: main
BasicMessageConsumer.close()
lock AMQSession.getFailoverMutex()
lock AMQSession._messageDeliveryLock
{noformat}
Interestingly, AMQConnectionDelegate_0_10.executeRetrySupport(..) does not
acquire the failover mutex (I have no idea if it _should_) so is not
susceptible to this deadlock.
I've attached the GraphViz .dot file that JCarder generated when it detected
this problem.
Note that this problem is similar to QPID-4574 so might be fixed by a single
commit.
--
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-5118) [JMS] Deadlock when closing a consumer and calling JMS operatons inside onMessage() on AMQP 0-8/0-9/0-9-1 connection
[
https://issues.apache.org/jira/browse/QPID-5118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Harvey updated QPID-5118:
Attachment: jcarder_result_3.dot
JCarder-generated file showing this potential deadlock.
[JMS] Deadlock when closing a consumer and calling JMS operatons inside
onMessage() on AMQP 0-8/0-9/0-9-1 connection
Key: QPID-5118
URL: https://issues.apache.org/jira/browse/QPID-5118
Project: Qpid
Issue Type: Bug
Components: Java Client
Affects Versions: 0.22
Reporter: Philip Harvey
Attachments: jcarder_result_3.dot
I have run the java systests with the [JCarder|http://jcarder.org/] agent
attached. When using AMQP 0-9, JCarder detected a potential deadlock when the
following are done concurrently:
* Close a consumer from an application thread.
* Call one of the JMS operations inside MessageListener.onMessage() that uses
AMQConnectionDelegate_8_0.executeRetrySupport(..).
Here is a sketch of the deadlock scenario:
{noformat}
Thread: Dispatcher-1-Conn-600
AMQSession$Dispatcher.dispatchMessage()
lock AMQSession.this._messageDeliveryLock
...
myMessageListener.onMessage()
execute failover-aware operation eg
createQueue, createProducer etc
AMQConnectionDelegate_8_0.executeRetrySupport
lock
AMQConnection.getFailoverMutex()
Thread: main
BasicMessageConsumer.close()
lock AMQSession.getFailoverMutex()
lock AMQSession._messageDeliveryLock
{noformat}
Interestingly, AMQConnectionDelegate_0_10.executeRetrySupport(..) does not
acquire the failover mutex (I have no idea if it _should_) so is not
susceptible to this deadlock.
I've attached the GraphViz .dot file that JCarder generated when it detected
this problem.
Note that this problem is similar to QPID-4574 so might be fixed by a single
commit.
--
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-5119) Java client - 3-thread deadlock on pre-AMQP-0-10 connection involving messageDeliveryLock, failover mutex and sessionCreationLock
Philip Harvey created QPID-5119:
---
Summary: Java client - 3-thread deadlock on pre-AMQP-0-10
connection involving messageDeliveryLock, failover mutex and sessionCreationLock
Key: QPID-5119
URL: https://issues.apache.org/jira/browse/QPID-5119
Project: Qpid
Issue Type: Bug
Components: Java Client
Affects Versions: 0.22
Reporter: Philip Harvey
I have run the java systests with the [JCarder|http://jcarder.org/] agent
attached. When using AMQP 0-9, JCarder detected a potential deadlock when the
following are done concurrently:
* Close a consumer from an application thread.
* Call Connection.createSession from an application thread.
* Call Connection.createSession inside MessageListener.onMessage().
Here is a sketch of the deadlock scenario:
{noformat}
Dispatcher-1-Conn-780
AMQSession$Dispatcher.dispatchMessage()
lock AMQSession.this._messageDeliveryLock
AMQConnection.createSession()
lock AMQConnection._sessionCreationLock BLOCKED
BY applicationThread1
applicationThread1
AMQConnection.createSession
lock AMQConnection._sessionCreationLock
...
AMQConnectionDelegate_8_0.executeRetrySupport
lock AMQConnection.getFailoverMutex()
BLOCKED BY applicationThread2
applicationThread2
BasicMessageConsumer.close()
lock AMQSession.getFailoverMutex()
lock AMQSession._messageDeliveryLock BLOCKED BY
Dispatcher-1-Conn-780
{noformat}
Interestingly, AMQConnectionDelegate_0_10.executeRetrySupport(..) does not
acquire the failover mutex (I have no idea if it _should_) so is not
susceptible to this deadlock.
I've attached the GraphViz .dot file that JCarder generated when it detected
this problem.
Note that this problem is similar to QPID-4574 and QPID-5118 so might be fixed
by a single commit.
--
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-5119) Java client - 3-thread deadlock on pre-AMQP-0-10 connection involving messageDeliveryLock, failover mutex and sessionCreationLock
[
https://issues.apache.org/jira/browse/QPID-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Harvey updated QPID-5119:
Attachment: jcarder_result_4.dot
Java client - 3-thread deadlock on pre-AMQP-0-10 connection involving
messageDeliveryLock, failover mutex and sessionCreationLock
-
Key: QPID-5119
URL: https://issues.apache.org/jira/browse/QPID-5119
Project: Qpid
Issue Type: Bug
Components: Java Client
Affects Versions: 0.22
Reporter: Philip Harvey
Attachments: jcarder_result_4.dot
I have run the java systests with the [JCarder|http://jcarder.org/] agent
attached. When using AMQP 0-9, JCarder detected a potential deadlock when the
following are done concurrently:
* Close a consumer from an application thread.
* Call Connection.createSession from an application thread.
* Call Connection.createSession inside MessageListener.onMessage().
Here is a sketch of the deadlock scenario:
{noformat}
Dispatcher-1-Conn-780
AMQSession$Dispatcher.dispatchMessage()
lock AMQSession.this._messageDeliveryLock
AMQConnection.createSession()
lock AMQConnection._sessionCreationLock BLOCKED
BY applicationThread1
applicationThread1
AMQConnection.createSession
lock AMQConnection._sessionCreationLock
...
AMQConnectionDelegate_8_0.executeRetrySupport
lock AMQConnection.getFailoverMutex()
BLOCKED BY applicationThread2
applicationThread2
BasicMessageConsumer.close()
lock AMQSession.getFailoverMutex()
lock AMQSession._messageDeliveryLock BLOCKED BY
Dispatcher-1-Conn-780
{noformat}
Interestingly, AMQConnectionDelegate_0_10.executeRetrySupport(..) does not
acquire the failover mutex (I have no idea if it _should_) so is not
susceptible to this deadlock.
I've attached the GraphViz .dot file that JCarder generated when it detected
this problem.
Note that this problem is similar to QPID-4574 and QPID-5118 so might be
fixed by a single commit.
--
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-5119) [JMS] 3-thread deadlock on pre-AMQP-0-10 connection involving messageDeliveryLock, failover mutex and sessionCreationLock
[
https://issues.apache.org/jira/browse/QPID-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Harvey updated QPID-5119:
Summary: [JMS] 3-thread deadlock on pre-AMQP-0-10 connection involving
messageDeliveryLock, failover mutex and sessionCreationLock (was: Java client
- 3-thread deadlock on pre-AMQP-0-10 connection involving messageDeliveryLock,
failover mutex and sessionCreationLock)
[JMS] 3-thread deadlock on pre-AMQP-0-10 connection involving
messageDeliveryLock, failover mutex and sessionCreationLock
-
Key: QPID-5119
URL: https://issues.apache.org/jira/browse/QPID-5119
Project: Qpid
Issue Type: Bug
Components: Java Client
Affects Versions: 0.22
Reporter: Philip Harvey
Attachments: jcarder_result_4.dot
I have run the java systests with the [JCarder|http://jcarder.org/] agent
attached. When using AMQP 0-9, JCarder detected a potential deadlock when the
following are done concurrently:
* Close a consumer from an application thread.
* Call Connection.createSession from an application thread.
* Call Connection.createSession inside MessageListener.onMessage().
Here is a sketch of the deadlock scenario:
{noformat}
Dispatcher-1-Conn-780
AMQSession$Dispatcher.dispatchMessage()
lock AMQSession.this._messageDeliveryLock
AMQConnection.createSession()
lock AMQConnection._sessionCreationLock BLOCKED
BY applicationThread1
applicationThread1
AMQConnection.createSession
lock AMQConnection._sessionCreationLock
...
AMQConnectionDelegate_8_0.executeRetrySupport
lock AMQConnection.getFailoverMutex()
BLOCKED BY applicationThread2
applicationThread2
BasicMessageConsumer.close()
lock AMQSession.getFailoverMutex()
lock AMQSession._messageDeliveryLock BLOCKED BY
Dispatcher-1-Conn-780
{noformat}
Interestingly, AMQConnectionDelegate_0_10.executeRetrySupport(..) does not
acquire the failover mutex (I have no idea if it _should_) so is not
susceptible to this deadlock.
I've attached the GraphViz .dot file that JCarder generated when it detected
this problem.
Note that this problem is similar to QPID-4574 and QPID-5118 so might be
fixed by a single commit.
--
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-4574) [JMS] Deadlock involving _failoverMutex and _messageDeliveryLock
[
https://issues.apache.org/jira/browse/QPID-4574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13760261#comment-13760261
]
Philip Harvey commented on QPID-4574:
-
Note that this flagged as a potential deadlock when you run the systests with
the JCarder agent attached. I recommend that we run JCarder against the
systests again to help check the correctness of the fix.
[JMS] Deadlock involving _failoverMutex and _messageDeliveryLock
Key: QPID-4574
URL: https://issues.apache.org/jira/browse/QPID-4574
Project: Qpid
Issue Type: Bug
Components: Java Client
Affects Versions: 0.14, 0.16, 0.18, 0.20
Reporter: Rajith Attapattu
Assignee: Rajith Attapattu
Labels: deadlock
Fix For: Future
Attachments: Test_00782235.java
This deadlock can manifest when a you have a producer sending messages inside
an onMessage() call, while another thread is either closing the session or
the consumer.
Sending a message inside onMessage() is a common enough pattern, and is used
by intermediaries like Message Bridges, ESB's etc..
Here is an example stack trace, showing deadlock occuring when closing the
consumer:
{noformat}
Dispatcher-0-Conn-1:
at
org.apache.qpid.client.BasicMessageProducer.send(BasicMessageProducer.java:309)
- waiting to lock 0xecfd15a8 (a java.lang.Object)
at Test_00782235$1.onMessage(Test_00782235.java:29)
at
org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:751)
at
org.apache.qpid.client.BasicMessageConsumer_0_10.notifyMessage(BasicMessageConsumer_0_10.java:141)
at
org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:725)
at
org.apache.qpid.client.BasicMessageConsumer_0_10.notifyMessage(BasicMessageConsumer_0_10.java:186)
at
org.apache.qpid.client.BasicMessageConsumer_0_10.notifyMessage(BasicMessageConsumer_0_10.java:54)
at
org.apache.qpid.client.AMQSession$Dispatcher.notifyConsumer(AMQSession.java:3479)
at
org.apache.qpid.client.AMQSession$Dispatcher.dispatchMessage(AMQSession.java:3418)
- locked 0xecfd16c8 (a java.lang.Object)
- locked 0xecfd16d8 (a java.lang.Object)
at
org.apache.qpid.client.AMQSession$Dispatcher.access$1000(AMQSession.java:3205)
at org.apache.qpid.client.AMQSession.dispatch(AMQSession.java:3198)
at
org.apache.qpid.client.message.UnprocessedMessage.dispatch(UnprocessedMessage.java:54)
at
org.apache.qpid.client.AMQSession$Dispatcher.run(AMQSession.java:3341)
at java.lang.Thread.run(Thread.java:679)
main:
at
org.apache.qpid.client.BasicMessageConsumer.close(BasicMessageConsumer.java:598)
- waiting to lock 0xecfd16c8 (a java.lang.Object)
- locked 0xecfd15a8 (a java.lang.Object)
at
org.apache.qpid.client.BasicMessageConsumer.close(BasicMessageConsumer.java:558)
at Test_00782235.init(Test_00782235.java:62)
at Test_00782235.main(Test_00782235.java:12)
{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-4574) [JMS] Deadlock involving _failoverMutex and _messageDeliveryLock
[
https://issues.apache.org/jira/browse/QPID-4574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13759158#comment-13759158
]
Philip Harvey commented on QPID-4574:
-
Slightly modified the description to make the deadlock scenario more explicit
without requiring the casual reader to go the review board.
[JMS] Deadlock involving _failoverMutex and _messageDeliveryLock
Key: QPID-4574
URL: https://issues.apache.org/jira/browse/QPID-4574
Project: Qpid
Issue Type: Bug
Components: Java Client
Affects Versions: 0.14, 0.16, 0.18, 0.20
Reporter: Rajith Attapattu
Assignee: Rajith Attapattu
Labels: deadlock
Fix For: Future
Attachments: Test_00782235.java
This deadlock can manifest when a you have a producer sending messages inside
an onMessage() call, while another thread is either closing the session or
the consumer.
Sending a message inside onMessage() is a common enough pattern, and is used
by intermediaries like Message Bridges, ESB's etc..
Here is an example stack trace, showing deadlock occuring when closing the
consumer:
{noformat}
Dispatcher-0-Conn-1:
at
org.apache.qpid.client.BasicMessageProducer.send(BasicMessageProducer.java:309)
- waiting to lock 0xecfd15a8 (a java.lang.Object)
at Test_00782235$1.onMessage(Test_00782235.java:29)
at
org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:751)
at
org.apache.qpid.client.BasicMessageConsumer_0_10.notifyMessage(BasicMessageConsumer_0_10.java:141)
at
org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:725)
at
org.apache.qpid.client.BasicMessageConsumer_0_10.notifyMessage(BasicMessageConsumer_0_10.java:186)
at
org.apache.qpid.client.BasicMessageConsumer_0_10.notifyMessage(BasicMessageConsumer_0_10.java:54)
at
org.apache.qpid.client.AMQSession$Dispatcher.notifyConsumer(AMQSession.java:3479)
at
org.apache.qpid.client.AMQSession$Dispatcher.dispatchMessage(AMQSession.java:3418)
- locked 0xecfd16c8 (a java.lang.Object)
- locked 0xecfd16d8 (a java.lang.Object)
at
org.apache.qpid.client.AMQSession$Dispatcher.access$1000(AMQSession.java:3205)
at org.apache.qpid.client.AMQSession.dispatch(AMQSession.java:3198)
at
org.apache.qpid.client.message.UnprocessedMessage.dispatch(UnprocessedMessage.java:54)
at
org.apache.qpid.client.AMQSession$Dispatcher.run(AMQSession.java:3341)
at java.lang.Thread.run(Thread.java:679)
main:
at
org.apache.qpid.client.BasicMessageConsumer.close(BasicMessageConsumer.java:598)
- waiting to lock 0xecfd16c8 (a java.lang.Object)
- locked 0xecfd15a8 (a java.lang.Object)
at
org.apache.qpid.client.BasicMessageConsumer.close(BasicMessageConsumer.java:558)
at Test_00782235.init(Test_00782235.java:62)
at Test_00782235.main(Test_00782235.java:12)
{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-4574) [JMS] Deadlock involving _failoverMutex and _messageDeliveryLock
[
https://issues.apache.org/jira/browse/QPID-4574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Harvey updated QPID-4574:
Description:
This deadlock can manifest when a you have a producer sending messages inside
an onMessage() call.
This is a common enough pattern, and is used by intermediaries like Message
Bridges, ESB's etc..
{noformat}
Dispatcher-0-Conn-1:
at
org.apache.qpid.client.BasicMessageProducer.send(BasicMessageProducer.java:309)
- waiting to lock 0xecfd15a8 (a java.lang.Object)
at Test_00782235$1.onMessage(Test_00782235.java:29)
at
org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:751)
at
org.apache.qpid.client.BasicMessageConsumer_0_10.notifyMessage(BasicMessageConsumer_0_10.java:141)
at
org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:725)
at
org.apache.qpid.client.BasicMessageConsumer_0_10.notifyMessage(BasicMessageConsumer_0_10.java:186)
at
org.apache.qpid.client.BasicMessageConsumer_0_10.notifyMessage(BasicMessageConsumer_0_10.java:54)
at
org.apache.qpid.client.AMQSession$Dispatcher.notifyConsumer(AMQSession.java:3479)
at
org.apache.qpid.client.AMQSession$Dispatcher.dispatchMessage(AMQSession.java:3418)
- locked 0xecfd16c8 (a java.lang.Object)
- locked 0xecfd16d8 (a java.lang.Object)
at
org.apache.qpid.client.AMQSession$Dispatcher.access$1000(AMQSession.java:3205)
at org.apache.qpid.client.AMQSession.dispatch(AMQSession.java:3198)
at
org.apache.qpid.client.message.UnprocessedMessage.dispatch(UnprocessedMessage.java:54)
at
org.apache.qpid.client.AMQSession$Dispatcher.run(AMQSession.java:3341)
at java.lang.Thread.run(Thread.java:679)
main:
at
org.apache.qpid.client.BasicMessageConsumer.close(BasicMessageConsumer.java:598)
- waiting to lock 0xecfd16c8 (a java.lang.Object)
- locked 0xecfd15a8 (a java.lang.Object)
at
org.apache.qpid.client.BasicMessageConsumer.close(BasicMessageConsumer.java:558)
at Test_00782235.init(Test_00782235.java:62)
at Test_00782235.main(Test_00782235.java:12)
{noformat}
was:
This deadlock can manifest when a you have a producer sending messages inside
an onMessage() call.
This is a common enough pattern, and is used by intermediaries like Message
Bridges, ESB's etc..
Dispatcher-0-Conn-1:
at
org.apache.qpid.client.BasicMessageProducer.send(BasicMessageProducer.java:309)
- waiting to lock 0xecfd15a8 (a java.lang.Object)
at Test_00782235$1.onMessage(Test_00782235.java:29)
at
org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:751)
at
org.apache.qpid.client.BasicMessageConsumer_0_10.notifyMessage(BasicMessageConsumer_0_10.java:141)
at
org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:725)
at
org.apache.qpid.client.BasicMessageConsumer_0_10.notifyMessage(BasicMessageConsumer_0_10.java:186)
at
org.apache.qpid.client.BasicMessageConsumer_0_10.notifyMessage(BasicMessageConsumer_0_10.java:54)
at
org.apache.qpid.client.AMQSession$Dispatcher.notifyConsumer(AMQSession.java:3479)
at
org.apache.qpid.client.AMQSession$Dispatcher.dispatchMessage(AMQSession.java:3418)
- locked 0xecfd16c8 (a java.lang.Object)
- locked 0xecfd16d8 (a java.lang.Object)
at
org.apache.qpid.client.AMQSession$Dispatcher.access$1000(AMQSession.java:3205)
at org.apache.qpid.client.AMQSession.dispatch(AMQSession.java:3198)
at
org.apache.qpid.client.message.UnprocessedMessage.dispatch(UnprocessedMessage.java:54)
at
org.apache.qpid.client.AMQSession$Dispatcher.run(AMQSession.java:3341)
at java.lang.Thread.run(Thread.java:679)
main:
at
org.apache.qpid.client.BasicMessageConsumer.close(BasicMessageConsumer.java:598)
- waiting to lock 0xecfd16c8 (a java.lang.Object)
- locked 0xecfd15a8 (a java.lang.Object)
at
org.apache.qpid.client.BasicMessageConsumer.close(BasicMessageConsumer.java:558)
at Test_00782235.init(Test_00782235.java:62)
at Test_00782235.main(Test_00782235.java:12)
[JMS] Deadlock involving _failoverMutex and _messageDeliveryLock
Key: QPID-4574
URL: https://issues.apache.org/jira/browse/QPID-4574
Project: Qpid
Issue Type: Bug
Components: Java Client
Affects Versions: 0.14, 0.16, 0.18, 0.20
Reporter: Rajith Attapattu
Assignee: Rajith Attapattu
Labels: deadlock
Fix For: Future
Attachments: Test_00782235.java
This
[jira] [Updated] (QPID-3216) Deadlock between _lock (in AMQSession#DisptcherThread) and _messageDeliveryLock (in AMQSession.java)
[
https://issues.apache.org/jira/browse/QPID-3216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Harvey updated QPID-3216:
Description:
As per the following thread dump you can clearly see the deadlock between
_lock (in AMQSession#DisptcherThread) and _messageDeliveryLock (in
AMQSession.java)
This is another regression and I am working to identify the rev that caused it
and possibly understand the circumstances surrounding the change.
dispatcher thread already obtained _lock in dispatchMessage method.
dispatcher thread waiting to take _messageDeliveryLock in the same method.
main thread has already obtained _messageDeliveryLock in AMQSession.close
method.
main thread waiting to take _lock in DispatcherThread.rejectPending method.
{noformat}
Found one Java-level deadlock:
=
Dispatcher-Channel-0:
waiting to lock monitor 0x002ac1e6f0b8 (object 0x002a9f040448, a
java.lang.Object),
which is held by main
main:
waiting to lock monitor 0x002ac1e6f010 (object 0x002a9f03ba40, a
java.lang.Object),
which is held by Dispatcher-Channel-0
Java stack information for the threads listed above:
===
Dispatcher-Channel-0:
at
org.apache.qpid.client.AMQSession$Dispatcher.dispatchMessage(AMQSession.java:3315)
- waiting to lock0x002a9f040448 (a java.lang.Object)
- locked0x002a9f03ba40 (a java.lang.Object)
at
org.apache.qpid.client.AMQSession$Dispatcher.access$900(AMQSession.java:3096)
at org.apache.qpid.client.AMQSession.dispatch(AMQSession.java:3089)
at
org.apache.qpid.client.message.UnprocessedMessage.dispatch(UnprocessedMessage.java:55)
at org.apache.qpid.client.AMQSession$Dispatcher.run(AMQSession.java:3243)
at java.lang.Thread.run(Thread.java:619)
main:
at
org.apache.qpid.client.AMQSession$Dispatcher.rejectPending(AMQSession.java:3122)
- waiting to lock0x002a9f03ba40 (a java.lang.Object)
at
org.apache.qpid.client.AMQSession.confirmConsumerCancelled(AMQSession.java:897)
at
org.apache.qpid.client.BasicMessageConsumer_0_10.sendCancel(BasicMessageConsumer_0_10.java:189)
at
org.apache.qpid.client.BasicMessageConsumer.close(BasicMessageConsumer.java:573)
- locked0x002a9ef30aa0 (a java.lang.Object)
at org.apache.qpid.client.AMQSession.closeConsumers(AMQSession.java:2464)
at
org.apache.qpid.client.AMQSession.closeProducersAndConsumers(AMQSession.java:2514)
at org.apache.qpid.client.AMQSession.close(AMQSession.java:731)
- locked0x002a9f040448 (a java.lang.Object)
- locked0x002a9ef30aa0 (a java.lang.Object)
at org.apache.qpid.client.AMQSession.close(AMQSession.java:708)
at
org.apache.qpid.client.AMQConnection.closeAllSessions(AMQConnection.java:1003)
at org.apache.qpid.client.AMQConnection.doClose(AMQConnection.java:897)
- locked0x002a9ef30aa0 (a java.lang.Object)
- locked0x002a9ef30ab0 (a java.lang.Object)
at org.apache.qpid.client.AMQConnection.doClose(AMQConnection.java:886)
- locked0x002a9f040448 (a java.lang.Object)
- locked0x002a9ef30ab0 (a java.lang.Object)
at org.apache.qpid.client.AMQConnection.close(AMQConnection.java:870)
at org.apache.qpid.client.AMQConnection.close(AMQConnection.java:861)
at org.apache.qpid.client.AMQConnection.close(AMQConnection.java:856)
at
org.apache.qpid.test.utils.QpidBrokerTestCase.tearDown(QpidBrokerTestCase.java:1118)
at junit.framework.TestCase.runBare(TestCase.java:130)
at
org.apache.qpid.test.utils.QpidBrokerTestCase.runBare(QpidBrokerTestCase.java:234)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:120)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:297)
at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:672)
at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:546)
{noformat}
was:
As per the following thread dump you can clearly see the deadlock between
_lock (in AMQSession#DisptcherThread) and _messageDeliveryLock (in
AMQSession.java)
This is another regression and I am working to identify the rev that caused it
and possibly understand the circumstances surrounding the change.
dispatcher thread already obtained _lock in dispatchMessage method.
dispatcher thread waiting to take _messageDeliveryLock in the same method.
main thread has
[jira] [Updated] (QPID-4574) [JMS] Deadlock involving _failoverMutex and _messageDeliveryLock
[
https://issues.apache.org/jira/browse/QPID-4574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Harvey updated QPID-4574:
Description:
This deadlock can manifest when a you have a producer sending messages inside
an onMessage() call, while another thread is either closing the session or the
consumer.
Sending a message inside onMessage() is a common enough pattern, and is used by
intermediaries like Message Bridges, ESB's etc..
Here is an example stack trace, showing deadlock occuring when closing the
consumer:
{noformat}
Dispatcher-0-Conn-1:
at
org.apache.qpid.client.BasicMessageProducer.send(BasicMessageProducer.java:309)
- waiting to lock 0xecfd15a8 (a java.lang.Object)
at Test_00782235$1.onMessage(Test_00782235.java:29)
at
org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:751)
at
org.apache.qpid.client.BasicMessageConsumer_0_10.notifyMessage(BasicMessageConsumer_0_10.java:141)
at
org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:725)
at
org.apache.qpid.client.BasicMessageConsumer_0_10.notifyMessage(BasicMessageConsumer_0_10.java:186)
at
org.apache.qpid.client.BasicMessageConsumer_0_10.notifyMessage(BasicMessageConsumer_0_10.java:54)
at
org.apache.qpid.client.AMQSession$Dispatcher.notifyConsumer(AMQSession.java:3479)
at
org.apache.qpid.client.AMQSession$Dispatcher.dispatchMessage(AMQSession.java:3418)
- locked 0xecfd16c8 (a java.lang.Object)
- locked 0xecfd16d8 (a java.lang.Object)
at
org.apache.qpid.client.AMQSession$Dispatcher.access$1000(AMQSession.java:3205)
at org.apache.qpid.client.AMQSession.dispatch(AMQSession.java:3198)
at
org.apache.qpid.client.message.UnprocessedMessage.dispatch(UnprocessedMessage.java:54)
at
org.apache.qpid.client.AMQSession$Dispatcher.run(AMQSession.java:3341)
at java.lang.Thread.run(Thread.java:679)
main:
at
org.apache.qpid.client.BasicMessageConsumer.close(BasicMessageConsumer.java:598)
- waiting to lock 0xecfd16c8 (a java.lang.Object)
- locked 0xecfd15a8 (a java.lang.Object)
at
org.apache.qpid.client.BasicMessageConsumer.close(BasicMessageConsumer.java:558)
at Test_00782235.init(Test_00782235.java:62)
at Test_00782235.main(Test_00782235.java:12)
{noformat}
was:
This deadlock can manifest when a you have a producer sending messages inside
an onMessage() call.
This is a common enough pattern, and is used by intermediaries like Message
Bridges, ESB's etc..
{noformat}
Dispatcher-0-Conn-1:
at
org.apache.qpid.client.BasicMessageProducer.send(BasicMessageProducer.java:309)
- waiting to lock 0xecfd15a8 (a java.lang.Object)
at Test_00782235$1.onMessage(Test_00782235.java:29)
at
org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:751)
at
org.apache.qpid.client.BasicMessageConsumer_0_10.notifyMessage(BasicMessageConsumer_0_10.java:141)
at
org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:725)
at
org.apache.qpid.client.BasicMessageConsumer_0_10.notifyMessage(BasicMessageConsumer_0_10.java:186)
at
org.apache.qpid.client.BasicMessageConsumer_0_10.notifyMessage(BasicMessageConsumer_0_10.java:54)
at
org.apache.qpid.client.AMQSession$Dispatcher.notifyConsumer(AMQSession.java:3479)
at
org.apache.qpid.client.AMQSession$Dispatcher.dispatchMessage(AMQSession.java:3418)
- locked 0xecfd16c8 (a java.lang.Object)
- locked 0xecfd16d8 (a java.lang.Object)
at
org.apache.qpid.client.AMQSession$Dispatcher.access$1000(AMQSession.java:3205)
at org.apache.qpid.client.AMQSession.dispatch(AMQSession.java:3198)
at
org.apache.qpid.client.message.UnprocessedMessage.dispatch(UnprocessedMessage.java:54)
at
org.apache.qpid.client.AMQSession$Dispatcher.run(AMQSession.java:3341)
at java.lang.Thread.run(Thread.java:679)
main:
at
org.apache.qpid.client.BasicMessageConsumer.close(BasicMessageConsumer.java:598)
- waiting to lock 0xecfd16c8 (a java.lang.Object)
- locked 0xecfd15a8 (a java.lang.Object)
at
org.apache.qpid.client.BasicMessageConsumer.close(BasicMessageConsumer.java:558)
at Test_00782235.init(Test_00782235.java:62)
at Test_00782235.main(Test_00782235.java:12)
{noformat}
[JMS] Deadlock involving _failoverMutex and _messageDeliveryLock
Key: QPID-4574
URL: https://issues.apache.org/jira/browse/QPID-4574
Project: Qpid
Issue Type: Bug
Components: Java Client
Affects Versions: 0.14,
[jira] [Updated] (QPID-4276) Java client - deadlock on concurrent close of consumer and connection
[
https://issues.apache.org/jira/browse/QPID-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Harvey updated QPID-4276:
Description:
We have observed a deadlock on the Java client when the following are done
concurrently:
* An application thread closes a consumer
* The corresponding JMS connection is closed inside onMessage()
See attached stack trace for details.
We think this locking bug was introduced when fixing QPID-3911.
See thread dump excerpt below:
{noformat}
Found one Java-level deadlock:
=
Thread-11-Consumer_0:
waiting to lock monitor 0x4342b4c0 (object 0xed1e6a40, a
java.lang.Object),
which is held by Dispatcher-1-Conn-1
Dispatcher-1-Conn-1:
waiting to lock monitor 0x4342b568 (object 0xed060c48, a
java.lang.Object),
which is held by Thread-11-Consumer_0
Java stack information for the threads listed above:
===
Thread-11-Consumer_0:
at
org.apache.qpid.client.BasicMessageConsumer.close(BasicMessageConsumer.java:598)
- waiting to lock 0xed1e6a40 (a java.lang.Object)
- locked 0xed060c48 (a java.lang.Object)
at
org.apache.qpid.client.BasicMessageConsumer.close(BasicMessageConsumer.java:558)
at
org.apache.qpid.disttest.jms.ClientJmsDelegate.closeTestConsumer(ClientJmsDelegate.java:612)
at
org.apache.qpid.disttest.client.ConsumerParticipant.releaseResources(ConsumerParticipant.java:244)
at
org.apache.qpid.disttest.client.ParticipantExecutor$ParticipantRunnable.runParticipantAndSendResults(ParticipantExecutor.java:112)
at
org.apache.qpid.disttest.client.ParticipantExecutor$ParticipantRunnable.run(ParticipantExecutor.java:84)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Dispatcher-1-Conn-1:
at org.apache.qpid.client.AMQConnection.doClose(AMQConnection.java:857)
- waiting to lock 0xed060c48 (a java.lang.Object)
- locked 0xed060c58 (a java.lang.Object)
at org.apache.qpid.client.AMQConnection.doClose(AMQConnection.java:848)
- locked 0xed0bedd8 (a java.lang.Object)
- locked 0xed060c58 (a java.lang.Object)
at org.apache.qpid.client.AMQConnection.doClose(AMQConnection.java:848)
- locked 0xed1e6a40 (a java.lang.Object)
- locked 0xed060c58 (a java.lang.Object)
at org.apache.qpid.client.AMQConnection.close(AMQConnection.java:832)
at org.apache.qpid.client.AMQConnection.close(AMQConnection.java:823)
at org.apache.qpid.client.AMQConnection.close(AMQConnection.java:818)
at
org.apache.qpid.disttest.jms.ClientJmsDelegate.tearDownTest(ClientJmsDelegate.java:574)
at org.apache.qpid.disttest.client.Client.tearDownTest(Client.java:179)
at
org.apache.qpid.disttest.client.ClientCommandVisitor.visit(ClientCommandVisitor.java:90)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.qpid.disttest.Visitor.invokeVisitMethod(Visitor.java:61)
at org.apache.qpid.disttest.Visitor.visit(Visitor.java:39)
at org.apache.qpid.disttest.message.Command.accept(Command.java:48)
at
org.apache.qpid.disttest.client.Client.processInstruction(Client.java:113)
at
org.apache.qpid.disttest.jms.ClientJmsDelegate$1.onMessage(ClientJmsDelegate.java:122)
at
org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:751)
at
org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:725)
at
org.apache.qpid.client.AMQSession$Dispatcher.notifyConsumer(AMQSession.java:3479)
at
org.apache.qpid.client.AMQSession$Dispatcher.dispatchMessage(AMQSession.java:3418)
- locked 0xed1a30f0 (a java.lang.Object)
- locked 0xed186400 (a java.lang.Object)
at
org.apache.qpid.client.AMQSession$Dispatcher.access$1000(AMQSession.java:3205)
at org.apache.qpid.client.AMQSession.dispatch(AMQSession.java:3198)
at
org.apache.qpid.client.message.UnprocessedMessage.dispatch(UnprocessedMessage.java:54)
at
org.apache.qpid.client.AMQSession$Dispatcher.run(AMQSession.java:3341)
at java.lang.Thread.run(Thread.java:662)
Found 1 deadlock.
{noformat}
was:
We have observed a deadlock on the Java client when a consumer and its
connection are simultaneously closed.
See attached
[jira] [Created] (QPID-5117) Java client deadlocks if connection is closed while onMessage() is creating a session
Philip Harvey created QPID-5117:
---
Summary: Java client deadlocks if connection is closed while
onMessage() is creating a session
Key: QPID-5117
URL: https://issues.apache.org/jira/browse/QPID-5117
Project: Qpid
Issue Type: Bug
Components: Java Client
Affects Versions: 0.22
Reporter: Philip Harvey
Attachments: jcarder_result_2.dot
I have run the java systests with the [JCarder|http://jcarder.org/] agent
attached. JCarder detected a potential deadlock when the following are done
concurrently:
* Application thread closes a connection
* A MessageListener creates a new session on that connection inside onMessage().
Here is a sketch of the wrongly-ordered locking:
{noformat}
Thread main
AMQConnection.close()
AMQConnection.doClose()
lock AMQConnection._sessionCreationLock
lock AMQSession.getMessageDeliveryLock()
Thread Dispatcher-1-Conn-780
AMQSession$Dispatcher.dispatchMessage()
lock AMQSession.this._messageDeliveryLock
myMessageListener.onMessage()
AMQConnection.createSession()
lock AMQConnection._sessionCreationLock
{noformat}
I've attached JCarder's GraphViz-format .dot file which represents this
slightly more comprehensively.
--
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-5117) Java client deadlocks if connection is closed while onMessage() is creating a session
[
https://issues.apache.org/jira/browse/QPID-5117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Harvey updated QPID-5117:
Attachment: jcarder_result_2.dot
attached JCarder's output representing this potential deadlock.
Java client deadlocks if connection is closed while onMessage() is creating a
session
-
Key: QPID-5117
URL: https://issues.apache.org/jira/browse/QPID-5117
Project: Qpid
Issue Type: Bug
Components: Java Client
Affects Versions: 0.22
Reporter: Philip Harvey
Attachments: jcarder_result_2.dot
I have run the java systests with the [JCarder|http://jcarder.org/] agent
attached. JCarder detected a potential deadlock when the following are done
concurrently:
* Application thread closes a connection
* A MessageListener creates a new session on that connection inside
onMessage().
Here is a sketch of the wrongly-ordered locking:
{noformat}
Thread main
AMQConnection.close()
AMQConnection.doClose()
lock AMQConnection._sessionCreationLock
lock AMQSession.getMessageDeliveryLock()
Thread Dispatcher-1-Conn-780
AMQSession$Dispatcher.dispatchMessage()
lock AMQSession.this._messageDeliveryLock
myMessageListener.onMessage()
AMQConnection.createSession()
lock AMQConnection._sessionCreationLock
{noformat}
I've attached JCarder's GraphViz-format .dot file which represents this
slightly more comprehensively.
--
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] (QPIDJMS-4) Add findbugs configuration
Philip Harvey created QPIDJMS-4: --- Summary: Add findbugs configuration Key: QPIDJMS-4 URL: https://issues.apache.org/jira/browse/QPIDJMS-4 Project: Qpid JMS Issue Type: Improvement Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor This is being done as a quick way for us to keep track of code quality. We might remove this config if we set up integration with https://analysis.apache.org/. -- 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-5050) Clients calling Connection#stop() from within an ExceptionListener have potential for deadlock
[
https://issues.apache.org/jira/browse/QPID-5050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13741143#comment-13741143
]
Philip Harvey commented on QPID-5050:
-
The patch looks fine on the whole. Some non-essential things I'd change:
* The comment on testExceptionListenerStopsConnection_IsAllowed (and arguably
the name) is misleading because you actually expect connection.stop() to throw
an exception. Similarly, the test should fail if this exception is not thrown.
* As discussed, neither of us are certain whether it would be appropriate to
commit the rather specific testExceptionListenerConnectionStopDeadlock test.
** I'm actually happy either way, with a slight preference for committing it
(it does at least test that you can do JMS work inside both the message
listener and the exception listener without anything blowing up, whether as a
deadlock or not).
Clients calling Connection#stop() from within an ExceptionListener have
potential for deadlock
--
Key: QPID-5050
URL: https://issues.apache.org/jira/browse/QPID-5050
Project: Qpid
Issue Type: Bug
Components: Java Client
Affects Versions: 0.8, 0.10, 0.12, 0.14, 0.16, 0.18, 0.20, 0.22
Reporter: Keith Wall
Assignee: Philip Harvey
Attachments:
0001-QPID-5050-Move-invocation-of-ExceptionListener-to-af.patch
A deadlock possibility exists for client applications calling Connection#stop
within an application owned ExceptionListener.
Unfortunately a common messaging framework (Spring), installs such a
ExceptionListener.
In a recent support call, such a deadlock had occurred between the dispatcher
thread (whose onMessage was in the process of creating a session) and a
pooled thread bouncing a message back to the application. (The bounced
messages is returned to the application via the exception listener).
The deadlock involves the Dispatcher._lock and AMQConnection._failoverMutex.
The deadlock was reproduced with a system test (attached to Jira) and
deadlock captured with jstack -l pid (output below).
{noformat}
Dispatcher-1-Conn-4 pool-8-thread-1
+ acquires c888 (Dispatcher#_lock)+ acquires ca68
(AMQConnection#_failoverMutex)
+ tries to acquire ca68 + tries to acquire c888
{noformat}
{noformat}
Found one Java-level deadlock:
=
pool-8-thread-1:
waiting to lock monitor 0x5b0d3560 (object 0xf70bc888, a
java.lang.Object),
which is held by Dispatcher-1-Conn-4
Dispatcher-1-Conn-4:
waiting to lock monitor 0x5b187308 (object 0xf70bca68, a
java.lang.Object),
which is held by pool-8-thread-1
Java stack information for the threads listed above:
===
pool-8-thread-1:
at
org.apache.qpid.client.AMQSession$Dispatcher.setConnectionStopped(AMQSession.java:3276)
- waiting to lock 0xf70bc888 (a java.lang.Object)
at org.apache.qpid.client.AMQSession.stop(AMQSession.java:2382)
at org.apache.qpid.client.AMQConnection.stop(AMQConnection.java:835)
at
org.apache.qpid.test.unit.client.connection.ExceptionListenerTest$4.onException(ExceptionListenerTest.java:206)
at
org.apache.qpid.client.AMQConnection.exceptionReceived(AMQConnection.java:1329)
- locked 0xf70bca68 (a java.lang.Object)
at
org.apache.qpid.client.AMQSession_0_8$4.run(AMQSession_0_8.java:600)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Dispatcher-1-Conn-4:
at
org.apache.qpid.client.AMQConnectionDelegate_8_0.executeRetrySupport(AMQConnectionDelegate_8_0.java:333)
- waiting to lock 0xf70bca68 (a java.lang.Object)
at
org.apache.qpid.client.AMQConnection.executeRetrySupport(AMQConnection.java:624)
at
org.apache.qpid.client.failover.FailoverRetrySupport.execute(FailoverRetrySupport.java:102)
at
org.apache.qpid.client.AMQSession.createProducerImpl(AMQSession.java:2600)
at
org.apache.qpid.client.AMQSession.createProducer(AMQSession.java:1176)
at
org.apache.qpid.client.AMQSession.createProducer(AMQSession.java:98)
at
org.apache.qpid.test.unit.client.connection.ExceptionListenerTest$5.onMessage(ExceptionListenerTest.java:229)
at
org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:744)
at
org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:718)
at
[jira] [Assigned] (QPID-5050) Clients calling Connection#stop() from within an ExceptionListener have potential for deadlock
[
https://issues.apache.org/jira/browse/QPID-5050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Harvey reassigned QPID-5050:
---
Assignee: Keith Wall (was: Philip Harvey)
Reviewed - see previous comment
Clients calling Connection#stop() from within an ExceptionListener have
potential for deadlock
--
Key: QPID-5050
URL: https://issues.apache.org/jira/browse/QPID-5050
Project: Qpid
Issue Type: Bug
Components: Java Client
Affects Versions: 0.8, 0.10, 0.12, 0.14, 0.16, 0.18, 0.20, 0.22
Reporter: Keith Wall
Assignee: Keith Wall
Attachments:
0001-QPID-5050-Move-invocation-of-ExceptionListener-to-af.patch
A deadlock possibility exists for client applications calling Connection#stop
within an application owned ExceptionListener.
Unfortunately a common messaging framework (Spring), installs such a
ExceptionListener.
In a recent support call, such a deadlock had occurred between the dispatcher
thread (whose onMessage was in the process of creating a session) and a
pooled thread bouncing a message back to the application. (The bounced
messages is returned to the application via the exception listener).
The deadlock involves the Dispatcher._lock and AMQConnection._failoverMutex.
The deadlock was reproduced with a system test (attached to Jira) and
deadlock captured with jstack -l pid (output below).
{noformat}
Dispatcher-1-Conn-4 pool-8-thread-1
+ acquires c888 (Dispatcher#_lock)+ acquires ca68
(AMQConnection#_failoverMutex)
+ tries to acquire ca68 + tries to acquire c888
{noformat}
{noformat}
Found one Java-level deadlock:
=
pool-8-thread-1:
waiting to lock monitor 0x5b0d3560 (object 0xf70bc888, a
java.lang.Object),
which is held by Dispatcher-1-Conn-4
Dispatcher-1-Conn-4:
waiting to lock monitor 0x5b187308 (object 0xf70bca68, a
java.lang.Object),
which is held by pool-8-thread-1
Java stack information for the threads listed above:
===
pool-8-thread-1:
at
org.apache.qpid.client.AMQSession$Dispatcher.setConnectionStopped(AMQSession.java:3276)
- waiting to lock 0xf70bc888 (a java.lang.Object)
at org.apache.qpid.client.AMQSession.stop(AMQSession.java:2382)
at org.apache.qpid.client.AMQConnection.stop(AMQConnection.java:835)
at
org.apache.qpid.test.unit.client.connection.ExceptionListenerTest$4.onException(ExceptionListenerTest.java:206)
at
org.apache.qpid.client.AMQConnection.exceptionReceived(AMQConnection.java:1329)
- locked 0xf70bca68 (a java.lang.Object)
at
org.apache.qpid.client.AMQSession_0_8$4.run(AMQSession_0_8.java:600)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Dispatcher-1-Conn-4:
at
org.apache.qpid.client.AMQConnectionDelegate_8_0.executeRetrySupport(AMQConnectionDelegate_8_0.java:333)
- waiting to lock 0xf70bca68 (a java.lang.Object)
at
org.apache.qpid.client.AMQConnection.executeRetrySupport(AMQConnection.java:624)
at
org.apache.qpid.client.failover.FailoverRetrySupport.execute(FailoverRetrySupport.java:102)
at
org.apache.qpid.client.AMQSession.createProducerImpl(AMQSession.java:2600)
at
org.apache.qpid.client.AMQSession.createProducer(AMQSession.java:1176)
at
org.apache.qpid.client.AMQSession.createProducer(AMQSession.java:98)
at
org.apache.qpid.test.unit.client.connection.ExceptionListenerTest$5.onMessage(ExceptionListenerTest.java:229)
at
org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:744)
at
org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:718)
at
org.apache.qpid.client.AMQSession$Dispatcher.notifyConsumer(AMQSession.java:3388)
at
org.apache.qpid.client.AMQSession$Dispatcher.dispatchMessage(AMQSession.java:3327)
- locked 0xf71747e0 (a java.lang.Object)
- locked 0xf70bc888 (a java.lang.Object)
at
org.apache.qpid.client.AMQSession$Dispatcher.access$900(AMQSession.java:3114)
at org.apache.qpid.client.AMQSession.dispatch(AMQSession.java:3107)
at
org.apache.qpid.client.message.UnprocessedMessage.dispatch(UnprocessedMessage.java:54)
at
org.apache.qpid.client.AMQSession$Dispatcher.run(AMQSession.java:3250)
at java.lang.Thread.run(Thread.java:662)
[jira] [Resolved] (QPIDJMS-3) Implement AMQP peer for use in integration tests
[ https://issues.apache.org/jira/browse/QPIDJMS-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey resolved QPIDJMS-3. - Resolution: Fixed Implement AMQP peer for use in integration tests Key: QPIDJMS-3 URL: https://issues.apache.org/jira/browse/QPIDJMS-3 Project: Qpid JMS Issue Type: Improvement Reporter: Philip Harvey Assignee: Philip Harvey Attachments: 0001-NO-JIRA-added-findbugs-configuration-for-use-when-ru.patch, 0002-NO-JIRA-added-skeleton-implementation-of-mock-broker.patch, QPIDJMS-3.patch The test peer is an alternative to running the JMS tests against, for example, an actual Qpid broker. -- 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] (QPIDJMS-3) Implement AMQP peer for use in integration tests
Philip Harvey created QPIDJMS-3: --- Summary: Implement AMQP peer for use in integration tests Key: QPIDJMS-3 URL: https://issues.apache.org/jira/browse/QPIDJMS-3 Project: Qpid JMS Issue Type: Improvement Reporter: Philip Harvey Assignee: Philip Harvey The test peer is an alternative to running the JMS tests against, for example, an actual Qpid broker. -- 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] (QPIDJMS-3) Implement AMQP peer for use in integration tests
[ https://issues.apache.org/jira/browse/QPIDJMS-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated QPIDJMS-3: Attachment: 0002-NO-JIRA-added-skeleton-implementation-of-mock-broker.patch 0001-NO-JIRA-added-findbugs-configuration-for-use-when-ru.patch Added work-in-progress two patches. The first one (findbugs-related) is only necessary as a starting point for the second patch - it should not actually be committed under this Jira. Implement AMQP peer for use in integration tests Key: QPIDJMS-3 URL: https://issues.apache.org/jira/browse/QPIDJMS-3 Project: Qpid JMS Issue Type: Improvement Reporter: Philip Harvey Assignee: Philip Harvey Attachments: 0001-NO-JIRA-added-findbugs-configuration-for-use-when-ru.patch, 0002-NO-JIRA-added-skeleton-implementation-of-mock-broker.patch The test peer is an alternative to running the JMS tests against, for example, an actual Qpid broker. -- 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-4827) Java Performance Tests visualisation should allow more chart properties to contain system property placeholders
[
https://issues.apache.org/jira/browse/QPID-4827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Harvey updated QPID-4827:
Fix Version/s: 0.24
Java Performance Tests visualisation should allow more chart properties to
contain system property placeholders
---
Key: QPID-4827
URL: https://issues.apache.org/jira/browse/QPID-4827
Project: Qpid
Issue Type: Improvement
Components: Java Performance Tests
Reporter: Philip Harvey
Assignee: Philip Harvey
Priority: Minor
Fix For: 0.24
Currently in the chartdef file only the CSV directory can contain a system
property placeholder but we would like most settings to allow them. This will
allow, for example, the series legend to contain a value from a system
property such as ${baselineName}.
--
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-4827) Java Performance Tests visualisation should allow more chart properties to contain system property placeholders
[
https://issues.apache.org/jira/browse/QPID-4827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Harvey resolved QPID-4827.
-
Resolution: Fixed
Committed in http://svn.apache.org/repos/asf/qpid/trunk@1480995
Java Performance Tests visualisation should allow more chart properties to
contain system property placeholders
---
Key: QPID-4827
URL: https://issues.apache.org/jira/browse/QPID-4827
Project: Qpid
Issue Type: Improvement
Components: Java Performance Tests
Reporter: Philip Harvey
Assignee: Philip Harvey
Priority: Minor
Fix For: 0.24
Currently in the chartdef file only the CSV directory can contain a system
property placeholder but we would like most settings to allow them. This will
allow, for example, the series legend to contain a value from a system
property such as ${baselineName}.
--
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] [Assigned] (QPID-4989) Java performance tests - add documentation
[ https://issues.apache.org/jira/browse/QPID-4989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey reassigned QPID-4989: --- Assignee: Philip Harvey (was: Robbie Gemmell) Java performance tests - add documentation -- Key: QPID-4989 URL: https://issues.apache.org/jira/browse/QPID-4989 Project: Qpid Issue Type: Task Components: Documentation, Java Performance Tests Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor Attachments: 0001-QPID-4989-moved-Java-perf-test-README-into-a-docbook.patch The Java performance tests in java/perftests have a brief README file but would benefit from better documentation so the tests could be run by people other than the authors of the framework. -- 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-4989) Java performance tests - add documentation
[ https://issues.apache.org/jira/browse/QPID-4989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey resolved QPID-4989. - Resolution: Fixed Fix Version/s: 0.25 I checked the patch again, satisfied myself that it's ok, and committed it. Java performance tests - add documentation -- Key: QPID-4989 URL: https://issues.apache.org/jira/browse/QPID-4989 Project: Qpid Issue Type: Task Components: Documentation, Java Performance Tests Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor Fix For: 0.25 Attachments: 0001-QPID-4989-moved-Java-perf-test-README-into-a-docbook.patch The Java performance tests in java/perftests have a brief README file but would benefit from better documentation so the tests could be run by people other than the authors of the framework. -- 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-4989) Java performance tests - add documentation
Philip Harvey created QPID-4989: --- Summary: Java performance tests - add documentation Key: QPID-4989 URL: https://issues.apache.org/jira/browse/QPID-4989 Project: Qpid Issue Type: Task Components: Documentation, Java Performance Tests Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor The Java performance tests in java/perftests have a brief README file but would benefit from better documentation so the tests could be run by people other than the authors of the framework. -- 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] [Assigned] (QPID-4989) Java performance tests - add documentation
[ https://issues.apache.org/jira/browse/QPID-4989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey reassigned QPID-4989: --- Assignee: Robbie Gemmell (was: Philip Harvey) Hi Robbie, would you mind sanity checking the new perftest documentation for me please? Java performance tests - add documentation -- Key: QPID-4989 URL: https://issues.apache.org/jira/browse/QPID-4989 Project: Qpid Issue Type: Task Components: Documentation, Java Performance Tests Reporter: Philip Harvey Assignee: Robbie Gemmell Priority: Minor Attachments: 0001-QPID-4989-moved-Java-perf-test-README-into-a-docbook.patch The Java performance tests in java/perftests have a brief README file but would benefit from better documentation so the tests could be run by people other than the authors of the framework. -- 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-4989) Java performance tests - add documentation
[ https://issues.apache.org/jira/browse/QPID-4989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated QPID-4989: Attachment: 0001-QPID-4989-moved-Java-perf-test-README-into-a-docbook.patch Java performance tests - add documentation -- Key: QPID-4989 URL: https://issues.apache.org/jira/browse/QPID-4989 Project: Qpid Issue Type: Task Components: Documentation, Java Performance Tests Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor Attachments: 0001-QPID-4989-moved-Java-perf-test-README-into-a-docbook.patch The Java performance tests in java/perftests have a brief README file but would benefit from better documentation so the tests could be run by people other than the authors of the framework. -- 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-4989) Java performance tests - add documentation
[ https://issues.apache.org/jira/browse/QPID-4989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated QPID-4989: Status: Ready To Review (was: In Progress) Java performance tests - add documentation -- Key: QPID-4989 URL: https://issues.apache.org/jira/browse/QPID-4989 Project: Qpid Issue Type: Task Components: Documentation, Java Performance Tests Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor Attachments: 0001-QPID-4989-moved-Java-perf-test-README-into-a-docbook.patch The Java performance tests in java/perftests have a brief README file but would benefit from better documentation so the tests could be run by people other than the authors of the framework. -- 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-4958) Java Performance Tests - race condition client registration detection causes tests to hang
[
https://issues.apache.org/jira/browse/QPID-4958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Harvey resolved QPID-4958.
-
Resolution: Fixed
Fix Version/s: 0.23
Java Performance Tests - race condition client registration detection causes
tests to hang
--
Key: QPID-4958
URL: https://issues.apache.org/jira/browse/QPID-4958
Project: Qpid
Issue Type: Bug
Components: Java Performance Tests
Affects Versions: 0.22
Reporter: Philip Harvey
Assignee: Philip Harvey
Fix For: 0.23
Attachments:
0001-QPID-4958-fixed-race-condition-in-ClientRegistry-tha.patch
Occasionally various tests in ControllerAndClientTest fail with errors such
as:
{noformat}
main 2013-06-25 14:39:25,539 ERROR [qpid.disttest.controller.TestRunner]
Couldn't run test
org.apache.qpid.disttest.DistributedTestException: After 3ms ... Timed
out waiting for command responses ... Expecting 10 more responses.
at
org.apache.qpid.disttest.controller.TestRunner.awaitLatch(TestRunner.java:293)
at
org.apache.qpid.disttest.controller.TestRunner.awaitCommandResponses(TestRunner.java:183)
at
org.apache.qpid.disttest.controller.TestRunner.runParts(TestRunner.java:130)
at org.apache.qpid.disttest.controller.TestRunner.run(TestRunner.java:103)
at
org.apache.qpid.disttest.controller.Controller.runAllTests(Controller.java:171)
at
org.apache.qpid.systest.disttest.controllerandclient.ControllerAndClientTest.runTestsForTwoClients(ControllerAndClientTest.java:195)
at
org.apache.qpid.systest.disttest.controllerandclient.ControllerAndClientTest.testProducerAndThreeConsumersInSeparateClients(ControllerAndClientTest.java:136)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
{noformat}
The relevant test log excerpts are shown below.
{noformat}
main 2013-06-25 14:38:35,357 INFO [qpid.disttest.controller.Controller]
Awaiting client registrations
...
908 Dispatcher-1-Conn-2 2013-06-25 14:38:35,448 INFO
[qpid.disttest.controller.ClientRegistry] Client registered:
63a95928-7d12-48ad-9326-133da9a0ddb6
...
920 Dispatcher-1-Conn-2 2013-06-25 14:38:35,450 INFO
[qpid.disttest.controller.ClientRegistry] Client registered:
2510ce56-20d4-43a2-84db-193a87b1cfec
...
{noformat}
Client thread timing out after the 5 seconds set by the JUnit test:
{noformat}
997 2510ce56-20d4-43a2-84db-193a87b1cfec-thread 2013-06-25 14:38:40,423 DEBUG
[apache.qpid.client.AMQSession] Closing session:
org.apache.qpid.client.AMQSes sion_0_8@5e111b5c
{noformat}
Controller sends test set-up commands, 20 seconds after Awaiting client
registrations. This happens to be the length of the client registration
time-out, suggesting that the await client registrations code didn't notice
that client registrations.
{noformat}
1080 main 2013-06-25 14:38:55,476 DEBUG [qpid.disttest.controller.TestRunner]
About to send 10 command(s)
{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-4958) Java Performance Tests - race condition client registration detection causes tests to hang
Philip Harvey created QPID-4958:
---
Summary: Java Performance Tests - race condition client
registration detection causes tests to hang
Key: QPID-4958
URL: https://issues.apache.org/jira/browse/QPID-4958
Project: Qpid
Issue Type: Bug
Components: Java Performance Tests
Affects Versions: 0.22
Reporter: Philip Harvey
Assignee: Philip Harvey
Occasionally various tests in ControllerAndClientTest fail with errors such as:
{noformat}
main 2013-06-25 14:39:25,539 ERROR [qpid.disttest.controller.TestRunner]
Couldn't run test
org.apache.qpid.disttest.DistributedTestException: After 3ms ... Timed out
waiting for command responses ... Expecting 10 more responses.
at
org.apache.qpid.disttest.controller.TestRunner.awaitLatch(TestRunner.java:293)
at
org.apache.qpid.disttest.controller.TestRunner.awaitCommandResponses(TestRunner.java:183)
at
org.apache.qpid.disttest.controller.TestRunner.runParts(TestRunner.java:130)
at org.apache.qpid.disttest.controller.TestRunner.run(TestRunner.java:103)
at
org.apache.qpid.disttest.controller.Controller.runAllTests(Controller.java:171)
at
org.apache.qpid.systest.disttest.controllerandclient.ControllerAndClientTest.runTestsForTwoClients(ControllerAndClientTest.java:195)
at
org.apache.qpid.systest.disttest.controllerandclient.ControllerAndClientTest.testProducerAndThreeConsumersInSeparateClients(ControllerAndClientTest.java:136)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
{noformat}
The relevant test log excerpts are shown below.
{noformat}
main 2013-06-25 14:38:35,357 INFO [qpid.disttest.controller.Controller]
Awaiting client registrations
...
908 Dispatcher-1-Conn-2 2013-06-25 14:38:35,448 INFO
[qpid.disttest.controller.ClientRegistry] Client registered:
63a95928-7d12-48ad-9326-133da9a0ddb6
...
920 Dispatcher-1-Conn-2 2013-06-25 14:38:35,450 INFO
[qpid.disttest.controller.ClientRegistry] Client registered:
2510ce56-20d4-43a2-84db-193a87b1cfec
...
{noformat}
Client thread timing out after the 5 seconds set by the JUnit test:
{noformat}
997 2510ce56-20d4-43a2-84db-193a87b1cfec-thread 2013-06-25 14:38:40,423 DEBUG
[apache.qpid.client.AMQSession] Closing session: org.apache.qpid.client.AMQSes
sion_0_8@5e111b5c
{noformat}
Controller sends test set-up commands, 20 seconds after Awaiting client
registrations. This happens to be the length of the client registration
time-out, suggesting that the await client registrations code didn't notice
that client registrations.
{noformat}
1080 main 2013-06-25 14:38:55,476 DEBUG [qpid.disttest.controller.TestRunner]
About to send 10 command(s)
{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-4870) Java Broker: expose the total payload of unacknowledged messages on each connection
Philip Harvey created QPID-4870: --- Summary: Java Broker: expose the total payload of unacknowledged messages on each connection Key: QPID-4870 URL: https://issues.apache.org/jira/browse/QPID-4870 Project: Qpid Issue Type: Improvement Reporter: Philip Harvey This would be useful for monitoring purposes. If this value sharply increases it is often sign of an impending problem, e.g. a badly behaved consumer causing message to build up on a queue. -- 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-4836) Add design guidelines to project etiquette html page
[ https://issues.apache.org/jira/browse/QPID-4836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13656885#comment-13656885 ] Philip Harvey commented on QPID-4836: - Thanks Justin, I've edited that wiki page. I renamed it too (see below) - hope that doesn't cause too much disruption to your changes. https://cwiki.apache.org/confluence/display/qpid/Qpid+Project+Developers%27+Guide Add design guidelines to project etiquette html page Key: QPID-4836 URL: https://issues.apache.org/jira/browse/QPID-4836 Project: Qpid Issue Type: Task Components: Documentation Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor Attachments: QPID-4836-design-guidelines.patch On a number of occasions, I've been involved in Qpid changes that have required rework because certain aspects of the design were not considered early on. To mitigate this, I'd like to add a Design Checklist to the Qpid web site that we can all refer to, either when designing features or reviewing other people's changes. I'd like to re-purpose http://qpid.apache.org/qpid_project_etiquette_guide.html to include this information, probably renaming it to something like Qpid Project Developers Guide. -- 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] [Assigned] (QPID-4836) Add design guidelines to project etiquette html page
[ https://issues.apache.org/jira/browse/QPID-4836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey reassigned QPID-4836: --- Assignee: Justin Ross (was: Philip Harvey) Add design guidelines to project etiquette html page Key: QPID-4836 URL: https://issues.apache.org/jira/browse/QPID-4836 Project: Qpid Issue Type: Task Components: Documentation Reporter: Philip Harvey Assignee: Justin Ross Priority: Minor Attachments: QPID-4836-design-guidelines.patch On a number of occasions, I've been involved in Qpid changes that have required rework because certain aspects of the design were not considered early on. To mitigate this, I'd like to add a Design Checklist to the Qpid web site that we can all refer to, either when designing features or reviewing other people's changes. I'd like to re-purpose http://qpid.apache.org/qpid_project_etiquette_guide.html to include this information, probably renaming it to something like Qpid Project Developers Guide. -- 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-4836) Add design guidelines to project etiquette html page
[ https://issues.apache.org/jira/browse/QPID-4836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated QPID-4836: Status: Ready To Review (was: In Progress) Add design guidelines to project etiquette html page Key: QPID-4836 URL: https://issues.apache.org/jira/browse/QPID-4836 Project: Qpid Issue Type: Task Components: Documentation Reporter: Philip Harvey Assignee: Justin Ross Priority: Minor Attachments: QPID-4836-design-guidelines.patch On a number of occasions, I've been involved in Qpid changes that have required rework because certain aspects of the design were not considered early on. To mitigate this, I'd like to add a Design Checklist to the Qpid web site that we can all refer to, either when designing features or reviewing other people's changes. I'd like to re-purpose http://qpid.apache.org/qpid_project_etiquette_guide.html to include this information, probably renaming it to something like Qpid Project Developers Guide. -- 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-4836) Add design guidelines to project etiquette html page
Philip Harvey created QPID-4836: --- Summary: Add design guidelines to project etiquette html page Key: QPID-4836 URL: https://issues.apache.org/jira/browse/QPID-4836 Project: Qpid Issue Type: Task Components: Documentation Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor On a number of occasions, I've been involved in Qpid changes that have required rework because certain aspects of the design were not considered early on. To mitigate this, I'd like to add a Design Checklist to the Qpid web site that we can all refer to, either when designing features or reviewing other people's changes. I'd like to re-purpose http://qpid.apache.org/qpid_project_etiquette_guide.html to include this information, probably renaming it to something like Qpid Project Developers Guide. -- 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-4836) Add design guidelines to project etiquette html page
[ https://issues.apache.org/jira/browse/QPID-4836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated QPID-4836: Attachment: QPID-4836-design-guidelines.patch attached patch for review Add design guidelines to project etiquette html page Key: QPID-4836 URL: https://issues.apache.org/jira/browse/QPID-4836 Project: Qpid Issue Type: Task Components: Documentation Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor Attachments: QPID-4836-design-guidelines.patch On a number of occasions, I've been involved in Qpid changes that have required rework because certain aspects of the design were not considered early on. To mitigate this, I'd like to add a Design Checklist to the Qpid web site that we can all refer to, either when designing features or reviewing other people's changes. I'd like to re-purpose http://qpid.apache.org/qpid_project_etiquette_guide.html to include this information, probably renaming it to something like Qpid Project Developers Guide. -- 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-4827) Java Performance Tests visualisation should allow more chart properties to contain system property placeholders
Philip Harvey created QPID-4827:
---
Summary: Java Performance Tests visualisation should allow more
chart properties to contain system property placeholders
Key: QPID-4827
URL: https://issues.apache.org/jira/browse/QPID-4827
Project: Qpid
Issue Type: Improvement
Components: Java Performance Tests
Reporter: Philip Harvey
Assignee: Philip Harvey
Priority: Minor
Currently in the chartdef file only the CSV directory can contain a system
property placeholder but we would like most settings to allow them. This will
allow, for example, the series legend to contain a value from a system property
such as ${baselineName}.
--
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-4817) Add message grouping to Java Broker book
Philip Harvey created QPID-4817: --- Summary: Add message grouping to Java Broker book Key: QPID-4817 URL: https://issues.apache.org/jira/browse/QPID-4817 Project: Qpid Issue Type: Improvement Components: Documentation Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor This feature was added to the Java broker in QPID-3720. -- 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-4817) Add message grouping to Java Broker book
[ https://issues.apache.org/jira/browse/QPID-4817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated QPID-4817: Status: Ready To Review (was: In Progress) Add message grouping to Java Broker book Key: QPID-4817 URL: https://issues.apache.org/jira/browse/QPID-4817 Project: Qpid Issue Type: Improvement Components: Documentation Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor This feature was added to the Java broker in QPID-3720. -- 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] [Assigned] (QPID-4817) Add message grouping to Java Broker book
[ https://issues.apache.org/jira/browse/QPID-4817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey reassigned QPID-4817: --- Assignee: Keith Wall (was: Philip Harvey) Please could you review my changes (r1480196). Thanks. Add message grouping to Java Broker book Key: QPID-4817 URL: https://issues.apache.org/jira/browse/QPID-4817 Project: Qpid Issue Type: Improvement Components: Documentation Reporter: Philip Harvey Assignee: Keith Wall Priority: Minor This feature was added to the Java broker in QPID-3720. -- 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] [Assigned] (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 reassigned QPID-4731:
---
Assignee: Philip Harvey
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] [Created] (QPID-4656) Java Performance Tests - add documentation
Philip Harvey created QPID-4656: --- Summary: Java Performance Tests - add documentation Key: QPID-4656 URL: https://issues.apache.org/jira/browse/QPID-4656 Project: Qpid Issue Type: Improvement Components: Java Performance Tests Affects Versions: 0.20 Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor It is not self-evident how to use the JMS performance test framework in the java/perftests folder so we should add brief documentation to help people get started. -- 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-4656) Java Performance Tests - add documentation
[ https://issues.apache.org/jira/browse/QPID-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated QPID-4656: Attachment: 0001-QPID-4656-added-perftests-documentation.patch uploaded patch for review Java Performance Tests - add documentation -- Key: QPID-4656 URL: https://issues.apache.org/jira/browse/QPID-4656 Project: Qpid Issue Type: Improvement Components: Java Performance Tests Affects Versions: 0.20 Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor Attachments: 0001-QPID-4656-added-perftests-documentation.patch It is not self-evident how to use the JMS performance test framework in the java/perftests folder so we should add brief documentation to help people get started. -- 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] [Assigned] (QPID-4656) Java Performance Tests - add documentation
[ https://issues.apache.org/jira/browse/QPID-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey reassigned QPID-4656: --- Assignee: Keith Wall (was: Philip Harvey) please could you take a look before I commit this Java Performance Tests - add documentation -- Key: QPID-4656 URL: https://issues.apache.org/jira/browse/QPID-4656 Project: Qpid Issue Type: Improvement Components: Java Performance Tests Affects Versions: 0.20 Reporter: Philip Harvey Assignee: Keith Wall Priority: Minor Attachments: 0001-QPID-4656-added-perftests-documentation.patch It is not self-evident how to use the JMS performance test framework in the java/perftests folder so we should add brief documentation to help people get started. -- 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-4656) Java Performance Tests - add documentation
[ https://issues.apache.org/jira/browse/QPID-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13605210#comment-13605210 ] Philip Harvey commented on QPID-4656: - committed in r1457805. Java Performance Tests - add documentation -- Key: QPID-4656 URL: https://issues.apache.org/jira/browse/QPID-4656 Project: Qpid Issue Type: Improvement Components: Java Performance Tests Affects Versions: 0.20 Reporter: Philip Harvey Assignee: Keith Wall Priority: Minor Attachments: 0001-QPID-4656-added-perftests-documentation.patch It is not self-evident how to use the JMS performance test framework in the java/perftests folder so we should add brief documentation to help people get started. -- 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-4656) Java Performance Tests - add documentation
[ https://issues.apache.org/jira/browse/QPID-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated QPID-4656: Status: Ready To Review (was: In Progress) Java Performance Tests - add documentation -- Key: QPID-4656 URL: https://issues.apache.org/jira/browse/QPID-4656 Project: Qpid Issue Type: Improvement Components: Java Performance Tests Affects Versions: 0.20 Reporter: Philip Harvey Assignee: Keith Wall Priority: Minor Attachments: 0001-QPID-4656-added-perftests-documentation.patch It is not self-evident how to use the JMS performance test framework in the java/perftests folder so we should add brief documentation to help people get started. -- 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-4656) Java Performance Tests - add documentation
[ https://issues.apache.org/jira/browse/QPID-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey resolved QPID-4656. - Resolution: Fixed Fix Version/s: 0.21 Reviewed by Keith. Documentation change only. Java Performance Tests - add documentation -- Key: QPID-4656 URL: https://issues.apache.org/jira/browse/QPID-4656 Project: Qpid Issue Type: Improvement Components: Java Performance Tests Affects Versions: 0.20 Reporter: Philip Harvey Assignee: Keith Wall Priority: Minor Fix For: 0.21 Attachments: 0001-QPID-4656-added-perftests-documentation.patch It is not self-evident how to use the JMS performance test framework in the java/perftests folder so we should add brief documentation to help people get started. -- 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-4605) Java Performance Test and Visualisation unit tests should subclass QpidTestCase, not TestCase
Philip Harvey created QPID-4605: --- Summary: Java Performance Test and Visualisation unit tests should subclass QpidTestCase, not TestCase Key: QPID-4605 URL: https://issues.apache.org/jira/browse/QPID-4605 Project: Qpid Issue Type: Improvement Components: Java Performance Tests Affects Versions: 0.20 Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor Java Performance Test and Visualisation unit tests should subclass QpidTestCase, not TestCase, primarily because QpidTestCase logs the test name at the start and end of each test, thereby allowing you to identify which test each line of logging came from. -- 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-4606) CLONE - Java Performance Test and Visualisation unit test timeouts insufficient for slow CI servers
Philip Harvey created QPID-4606: --- Summary: CLONE - Java Performance Test and Visualisation unit test timeouts insufficient for slow CI servers Key: QPID-4606 URL: https://issues.apache.org/jira/browse/QPID-4606 Project: Qpid Issue Type: Improvement Components: Java Performance Tests Affects Versions: 0.20 Reporter: Philip Harvey Assignee: Keith Wall Priority: Minor Java Performance Test and Visualisation unit tests should subclass QpidTestCase, not TestCase, primarily because QpidTestCase logs the test name at the start and end of each test, thereby allowing you to identify which test each line of logging came from. -- 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] [Assigned] (QPID-4605) Java Performance Test and Visualisation unit tests should subclass QpidTestCase, not TestCase
[ https://issues.apache.org/jira/browse/QPID-4605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey reassigned QPID-4605: --- Assignee: Keith Wall (was: Philip Harvey) Hi Keith, pls could you review this change Java Performance Test and Visualisation unit tests should subclass QpidTestCase, not TestCase - Key: QPID-4605 URL: https://issues.apache.org/jira/browse/QPID-4605 Project: Qpid Issue Type: Improvement Components: Java Performance Tests Affects Versions: 0.20 Reporter: Philip Harvey Assignee: Keith Wall Priority: Minor Java Performance Test and Visualisation unit tests should subclass QpidTestCase, not TestCase, primarily because QpidTestCase logs the test name at the start and end of each test, thereby allowing you to identify which test each line of logging came from. -- 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-4606) CLONE - Java Performance Test and Visualisation unit test timeouts insufficient for slow CI servers
[ https://issues.apache.org/jira/browse/QPID-4606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated QPID-4606: Description: Java Performance Test and Visualisation unit tests sometimes fail because of timeouts. These appear to be simply caused by slow CI servers. (was: Java Performance Test and Visualisation unit tests should subclass QpidTestCase, not TestCase, primarily because QpidTestCase logs the test name at the start and end of each test, thereby allowing you to identify which test each line of logging came from.) CLONE - Java Performance Test and Visualisation unit test timeouts insufficient for slow CI servers --- Key: QPID-4606 URL: https://issues.apache.org/jira/browse/QPID-4606 Project: Qpid Issue Type: Improvement Components: Java Performance Tests Affects Versions: 0.20 Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor Java Performance Test and Visualisation unit tests sometimes fail because of timeouts. These appear to be simply caused by slow CI servers. -- 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-4606) CLONE - Java Performance Test unit test timeouts insufficient for slow CI servers
[ https://issues.apache.org/jira/browse/QPID-4606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated QPID-4606: Status: Ready To Review (was: In Progress) CLONE - Java Performance Test unit test timeouts insufficient for slow CI servers - Key: QPID-4606 URL: https://issues.apache.org/jira/browse/QPID-4606 Project: Qpid Issue Type: Improvement Components: Java Performance Tests Affects Versions: 0.20 Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor Java Performance Test and Visualisation unit tests sometimes fail because of timeouts. These appear to be simply caused by slow CI servers. -- 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] [Assigned] (QPID-4606) CLONE - Java Performance Test unit test timeouts insufficient for slow CI servers
[ https://issues.apache.org/jira/browse/QPID-4606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey reassigned QPID-4606: --- Assignee: Keith Wall (was: Philip Harvey) please could you review. Thanks. CLONE - Java Performance Test unit test timeouts insufficient for slow CI servers - Key: QPID-4606 URL: https://issues.apache.org/jira/browse/QPID-4606 Project: Qpid Issue Type: Improvement Components: Java Performance Tests Affects Versions: 0.20 Reporter: Philip Harvey Assignee: Keith Wall Priority: Minor Java Performance Test and Visualisation unit tests sometimes fail because of timeouts. These appear to be simply caused by slow CI servers. -- 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-4606) Java Performance Test and Visualisation unit test timeouts insufficient for slow CI servers
[ https://issues.apache.org/jira/browse/QPID-4606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated QPID-4606: Summary: Java Performance Test and Visualisation unit test timeouts insufficient for slow CI servers (was: CLONE - Java Performance Test unit test timeouts insufficient for slow CI servers) Java Performance Test and Visualisation unit test timeouts insufficient for slow CI servers --- Key: QPID-4606 URL: https://issues.apache.org/jira/browse/QPID-4606 Project: Qpid Issue Type: Improvement Components: Java Performance Tests Affects Versions: 0.20 Reporter: Philip Harvey Assignee: Keith Wall Priority: Minor Java Performance Test and Visualisation unit tests sometimes fail because of timeouts. These appear to be simply caused by slow CI servers. -- 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-4597) Java broker performance tests should support visualisation of time series data
Philip Harvey created QPID-4597: --- Summary: Java broker performance tests should support visualisation of time series data Key: QPID-4597 URL: https://issues.apache.org/jira/browse/QPID-4597 Project: Qpid Issue Type: Improvement Components: Java Performance Tests Affects Versions: 0.20 Reporter: Philip Harvey Assignee: Keith Wall Priority: Minor Fix For: 0.21 We should allow perftest results to be written to a database to facilitate analysis, eg charting how our performance has varied over time -- 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] [Assigned] (QPID-4597) Java broker performance tests should support visualisation of time series data
[ https://issues.apache.org/jira/browse/QPID-4597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey reassigned QPID-4597: --- Assignee: Philip Harvey (was: Keith Wall) Java broker performance tests should support visualisation of time series data -- Key: QPID-4597 URL: https://issues.apache.org/jira/browse/QPID-4597 Project: Qpid Issue Type: Improvement Components: Java Performance Tests Affects Versions: 0.20 Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor Fix For: 0.21 We should allow perftest results to be written to a database to facilitate analysis, eg charting how our performance has varied over time -- 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] [Assigned] (QPID-4597) Java broker performance tests should support visualisation of time series data
[ https://issues.apache.org/jira/browse/QPID-4597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey reassigned QPID-4597: --- Assignee: Keith Wall (was: Philip Harvey) Hi Keith, please could you take a look at this change when you get a chance. It's committed in revision 1449342. Thanks. Java broker performance tests should support visualisation of time series data -- Key: QPID-4597 URL: https://issues.apache.org/jira/browse/QPID-4597 Project: Qpid Issue Type: Improvement Components: Java Performance Tests Affects Versions: 0.20 Reporter: Philip Harvey Assignee: Keith Wall Priority: Minor Fix For: 0.21 We should allow perftest results to be written to a database to facilitate analysis, eg charting how our performance has varied over time -- 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-4597) Java broker performance tests should support visualisation of time series data
[ https://issues.apache.org/jira/browse/QPID-4597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated QPID-4597: Status: Ready To Review (was: In Progress) Java broker performance tests should support visualisation of time series data -- Key: QPID-4597 URL: https://issues.apache.org/jira/browse/QPID-4597 Project: Qpid Issue Type: Improvement Components: Java Performance Tests Affects Versions: 0.20 Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor Fix For: 0.21 We should allow perftest results to be written to a database to facilitate analysis, eg charting how our performance has varied over time -- 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-4533) Java broker performance tests should support writing results to database
[ https://issues.apache.org/jira/browse/QPID-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13574453#comment-13574453 ] Philip Harvey commented on QPID-4533: - The committed code has broken the ability of Jdbc[Csv]SeriesBuilder to build series using the series directory. This is commonly used for reading baseline data so needs to be fixed. I will address this bug in the next few days. Java broker performance tests should support writing results to database Key: QPID-4533 URL: https://issues.apache.org/jira/browse/QPID-4533 Project: Qpid Issue Type: Improvement Components: Java Performance Tests Affects Versions: 0.20 Reporter: Philip Harvey Assignee: Keith Wall Priority: Minor Fix For: 0.21 Attachments: 0002-QPID-4533-Modified-perftests-to-support-writing-resu.patch, timeseries.chartdef We should allow perftest results to be written to a database to facilitate analysis, eg charting how our performance has varied over time -- 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-4533) Java broker performance tests should support writing results to database
[ https://issues.apache.org/jira/browse/QPID-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13575098#comment-13575098 ] Philip Harvey commented on QPID-4533: - The aforementioned bug is now fixed. Committed in revision 1444335. Java broker performance tests should support writing results to database Key: QPID-4533 URL: https://issues.apache.org/jira/browse/QPID-4533 Project: Qpid Issue Type: Improvement Components: Java Performance Tests Affects Versions: 0.20 Reporter: Philip Harvey Assignee: Keith Wall Priority: Minor Fix For: 0.21 Attachments: 0002-QPID-4533-Modified-perftests-to-support-writing-resu.patch, timeseries.chartdef We should allow perftest results to be written to a database to facilitate analysis, eg charting how our performance has varied over time -- 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-4533) Java broker performance tests should support writing results to database
[ https://issues.apache.org/jira/browse/QPID-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13566318#comment-13566318 ] Philip Harvey commented on QPID-4533: - Thanks for reviewing this Keith. I've incorporated your comments and committed them. Regarding constraining the growth of the database, I intend that we'll cron some SQL scripts to remove old entries. If this proves inadequate or cumbersome we can implement something more automated. Java broker performance tests should support writing results to database Key: QPID-4533 URL: https://issues.apache.org/jira/browse/QPID-4533 Project: Qpid Issue Type: Improvement Components: Java Performance Tests Affects Versions: 0.20 Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor Attachments: 0002-QPID-4533-Modified-perftests-to-support-writing-resu.patch, timeseries.chartdef We should allow perftest results to be written to a database to facilitate analysis, eg charting how our performance has varied over time -- 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-4533) Java broker performance tests should support writing results to database
[ https://issues.apache.org/jira/browse/QPID-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated QPID-4533: Status: Ready To Review (was: In Progress) Java broker performance tests should support writing results to database Key: QPID-4533 URL: https://issues.apache.org/jira/browse/QPID-4533 Project: Qpid Issue Type: Improvement Components: Java Performance Tests Affects Versions: 0.20 Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor Attachments: 0002-QPID-4533-Modified-perftests-to-support-writing-resu.patch, timeseries.chartdef We should allow perftest results to be written to a database to facilitate analysis, eg charting how our performance has varied over time -- 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-4533) Java broker performance tests should support writing results to database
[ https://issues.apache.org/jira/browse/QPID-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey resolved QPID-4533. - Resolution: Fixed Fix Version/s: 0.21 Already reviewed by Keith. Java broker performance tests should support writing results to database Key: QPID-4533 URL: https://issues.apache.org/jira/browse/QPID-4533 Project: Qpid Issue Type: Improvement Components: Java Performance Tests Affects Versions: 0.20 Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor Fix For: 0.21 Attachments: 0002-QPID-4533-Modified-perftests-to-support-writing-resu.patch, timeseries.chartdef We should allow perftest results to be written to a database to facilitate analysis, eg charting how our performance has varied over time -- 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] [Reopened] (QPID-4533) Java broker performance tests should support writing results to database
[ https://issues.apache.org/jira/browse/QPID-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey reopened QPID-4533: - I now realise that one of the unit tests is timezone-specific. Java broker performance tests should support writing results to database Key: QPID-4533 URL: https://issues.apache.org/jira/browse/QPID-4533 Project: Qpid Issue Type: Improvement Components: Java Performance Tests Affects Versions: 0.20 Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor Fix For: 0.21 Attachments: 0002-QPID-4533-Modified-perftests-to-support-writing-resu.patch, timeseries.chartdef We should allow perftest results to be written to a database to facilitate analysis, eg charting how our performance has varied over time -- 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-4533) Java broker performance tests should support writing results to database
[ https://issues.apache.org/jira/browse/QPID-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated QPID-4533: Status: Ready To Review (was: In Progress) Java broker performance tests should support writing results to database Key: QPID-4533 URL: https://issues.apache.org/jira/browse/QPID-4533 Project: Qpid Issue Type: Improvement Components: Java Performance Tests Affects Versions: 0.20 Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor Fix For: 0.21 Attachments: 0002-QPID-4533-Modified-perftests-to-support-writing-resu.patch, timeseries.chartdef We should allow perftest results to be written to a database to facilitate analysis, eg charting how our performance has varied over time -- 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] [Assigned] (QPID-4533) Java broker performance tests should support writing results to database
[ https://issues.apache.org/jira/browse/QPID-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey reassigned QPID-4533: --- Assignee: Keith Wall (was: Philip Harvey) Fixed timezone bug. Please could you review? Java broker performance tests should support writing results to database Key: QPID-4533 URL: https://issues.apache.org/jira/browse/QPID-4533 Project: Qpid Issue Type: Improvement Components: Java Performance Tests Affects Versions: 0.20 Reporter: Philip Harvey Assignee: Keith Wall Priority: Minor Fix For: 0.21 Attachments: 0002-QPID-4533-Modified-perftests-to-support-writing-resu.patch, timeseries.chartdef We should allow perftest results to be written to a database to facilitate analysis, eg charting how our performance has varied over time -- 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-4471) Add docbook for producer transaction timeout feature of Java Broker.
[ https://issues.apache.org/jira/browse/QPID-4471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey resolved QPID-4471. - Resolution: Fixed Looks good. Apologies for the delay reviewing this change. Add docbook for producer transaction timeout feature of Java Broker. Key: QPID-4471 URL: https://issues.apache.org/jira/browse/QPID-4471 Project: Qpid Issue Type: Improvement Components: Documentation, Java Broker Reporter: Keith Wall Assignee: Philip Harvey Fix For: 0.21 Add docbook for producer transaction timeout feature of Java Broker. The content is based on existing wiki page https://cwiki.apache.org/qpid/qpid-java-broker-transaction-timeouts.html (which will be marked as deprecated) -- 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-4533) Java broker performance tests should support writing results to database
[ https://issues.apache.org/jira/browse/QPID-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated QPID-4533: Attachment: 0002-QPID-4533-Modified-perftests-to-support-writing-resu.patch Attached patch for review. I will attach instructions on how to manually test the database persistence in a separate comment. Java broker performance tests should support writing results to database Key: QPID-4533 URL: https://issues.apache.org/jira/browse/QPID-4533 Project: Qpid Issue Type: Improvement Components: Java Performance Tests Affects Versions: 0.20 Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor Attachments: 0002-QPID-4533-Modified-perftests-to-support-writing-resu.patch We should allow perftest results to be written to a database to facilitate analysis, eg charting how our performance has varied over time -- 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-4533) Java broker performance tests should support writing results to database
[ https://issues.apache.org/jira/browse/QPID-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated QPID-4533: Attachment: timeseries.chartdef Attached chartdef that can be used for manually testing graphs generated from the Derby database. Java broker performance tests should support writing results to database Key: QPID-4533 URL: https://issues.apache.org/jira/browse/QPID-4533 Project: Qpid Issue Type: Improvement Components: Java Performance Tests Affects Versions: 0.20 Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor Attachments: 0002-QPID-4533-Modified-perftests-to-support-writing-resu.patch, timeseries.chartdef We should allow perftest results to be written to a database to facilitate analysis, eg charting how our performance has varied over time -- 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] [Assigned] (QPID-4533) Java broker performance tests should support writing results to database
[ https://issues.apache.org/jira/browse/QPID-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey reassigned QPID-4533: --- Assignee: Keith Wall (was: Philip Harvey) Hi Keith, Please can you review this change. Here is an easy way to manually test: - Run the perf tests using the new script in perftests/etc/run-perftests.sh, which writes results to a Derby DB in the current directory - Run the visualisation tool against those results using the (somewhat meaningless) timeseries.chartdef file attached to this Jira, by executing script perftests/etc/visualisation.sh. You will need to edit the script to uncomment the JDBC variables and to provide the location of the timeseries.chartdef file. I intend to add subsequently add useful timeseries chart definitions under a separate Jira. Java broker performance tests should support writing results to database Key: QPID-4533 URL: https://issues.apache.org/jira/browse/QPID-4533 Project: Qpid Issue Type: Improvement Components: Java Performance Tests Affects Versions: 0.20 Reporter: Philip Harvey Assignee: Keith Wall Priority: Minor Attachments: 0002-QPID-4533-Modified-perftests-to-support-writing-resu.patch, timeseries.chartdef We should allow perftest results to be written to a database to facilitate analysis, eg charting how our performance has varied over time -- 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-4533) Java broker performance tests should support writing results to database
[ https://issues.apache.org/jira/browse/QPID-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated QPID-4533: Attachment: (was: 0002-QPID-4533-Modified-perftests-to-support-writing-resu.patch) Java broker performance tests should support writing results to database Key: QPID-4533 URL: https://issues.apache.org/jira/browse/QPID-4533 Project: Qpid Issue Type: Improvement Components: Java Performance Tests Affects Versions: 0.20 Reporter: Philip Harvey Assignee: Keith Wall Priority: Minor Attachments: 0002-QPID-4533-Modified-perftests-to-support-writing-resu.patch, timeseries.chartdef We should allow perftest results to be written to a database to facilitate analysis, eg charting how our performance has varied over time -- 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-4533) Java broker performance tests should support writing results to database
[ https://issues.apache.org/jira/browse/QPID-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated QPID-4533: Attachment: 0002-QPID-4533-Modified-perftests-to-support-writing-resu.patch attached patch Java broker performance tests should support writing results to database Key: QPID-4533 URL: https://issues.apache.org/jira/browse/QPID-4533 Project: Qpid Issue Type: Improvement Components: Java Performance Tests Affects Versions: 0.20 Reporter: Philip Harvey Assignee: Keith Wall Priority: Minor Attachments: 0002-QPID-4533-Modified-perftests-to-support-writing-resu.patch, timeseries.chartdef We should allow perftest results to be written to a database to facilitate analysis, eg charting how our performance has varied over time -- 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] [Assigned] (QPID-4432) AMQStateManager logger might generate unexpected amount of logs during failover
[
https://issues.apache.org/jira/browse/QPID-4432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Harvey reassigned QPID-4432:
---
Assignee: Philip Harvey
AMQStateManager logger might generate unexpected amount of logs during
failover
Key: QPID-4432
URL: https://issues.apache.org/jira/browse/QPID-4432
Project: Qpid
Issue Type: Bug
Components: Java Client
Affects Versions: 0.6, 0.8, 0.10, 0.12, 0.14, 0.16, 0.18
Reporter: Alex Rudyy
Assignee: Philip Harvey
Priority: Minor
In certain situation during the failover the logging from AMQStateManager
might generate massive logs:
{code}
for (StateWaiter waiter : _waiters)
{
_logger.error(Notifying Waiters( + _waiters + ) for error: +
error.getMessage());
waiter.error(error);
}
{code}
1) the repeated logging of collection of all waiters for each of them is not
really required
2) the log level should be debug, as we are logging the exception in callers
with INFO log level
3) it looks like all logging from AMQStateManager should have a debug log
level
--
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-4432) AMQStateManager logger might generate unexpected amount of logs during failover
[
https://issues.apache.org/jira/browse/QPID-4432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Harvey updated QPID-4432:
Status: Ready To Review (was: In Progress)
AMQStateManager logger might generate unexpected amount of logs during
failover
Key: QPID-4432
URL: https://issues.apache.org/jira/browse/QPID-4432
Project: Qpid
Issue Type: Bug
Components: Java Client
Affects Versions: 0.6, 0.8, 0.10, 0.12, 0.14, 0.16, 0.18
Reporter: Alex Rudyy
Assignee: Philip Harvey
Priority: Minor
In certain situation during the failover the logging from AMQStateManager
might generate massive logs:
{code}
for (StateWaiter waiter : _waiters)
{
_logger.error(Notifying Waiters( + _waiters + ) for error: +
error.getMessage());
waiter.error(error);
}
{code}
1) the repeated logging of collection of all waiters for each of them is not
really required
2) the log level should be debug, as we are logging the exception in callers
with INFO log level
3) it looks like all logging from AMQStateManager should have a debug log
level
--
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] [Assigned] (QPID-4432) AMQStateManager logger might generate unexpected amount of logs during failover
[
https://issues.apache.org/jira/browse/QPID-4432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Harvey reassigned QPID-4432:
---
Assignee: Alex Rudyy (was: Philip Harvey)
Committed change in revision 1433911. Please can you review.
AMQStateManager logger might generate unexpected amount of logs during
failover
Key: QPID-4432
URL: https://issues.apache.org/jira/browse/QPID-4432
Project: Qpid
Issue Type: Bug
Components: Java Client
Affects Versions: 0.6, 0.8, 0.10, 0.12, 0.14, 0.16, 0.18
Reporter: Alex Rudyy
Assignee: Alex Rudyy
Priority: Minor
In certain situation during the failover the logging from AMQStateManager
might generate massive logs:
{code}
for (StateWaiter waiter : _waiters)
{
_logger.error(Notifying Waiters( + _waiters + ) for error: +
error.getMessage());
waiter.error(error);
}
{code}
1) the repeated logging of collection of all waiters for each of them is not
really required
2) the log level should be debug, as we are logging the exception in callers
with INFO log level
3) it looks like all logging from AMQStateManager should have a debug log
level
--
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-4533) Java broker performance tests should support writing results to database
Philip Harvey created QPID-4533: --- Summary: Java broker performance tests should support writing results to database Key: QPID-4533 URL: https://issues.apache.org/jira/browse/QPID-4533 Project: Qpid Issue Type: Improvement Components: Java Performance Tests Affects Versions: 0.20 Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor We should allow perftest results to be written to a database to facilitate analysis, eg charting how our performance has varied over time -- 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-3025) Upgrade Java test framework to JUnit 4
[
https://issues.apache.org/jira/browse/QPID-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13546646#comment-13546646
]
Philip Harvey commented on QPID-3025:
-
I've paused this upgrade while the config refactoring work is in progress on
the config refactoring branch for QPID-4390
(https://svn.apache.org/repos/asf/qpid/branches/java-broker-config-qpid-4390/).
I looked into how we could use JUnit 4's Categories runner to replace our test
filtering logic, but have run into problems. In case anyone's interested, here
is a summary:
The vanilla usage of the org.junit.experimental.categories.Categories runner is
to write a dedicated suite like so:
{noformat}
@RunWith(Categories.class)
@IncludeCategory(SlowTests.class)
@SuiteClasses( { A.class, B.class })
// Note that Categories is a kind of Suite
public static class SlowTestSuite {
}
{noformat}
It's obviously undesireable to enumerate all the test classes. The most common
way round this is to use the ClasspathSuite library
(http://johanneslink.net/projects/cpsuite.jsp), as described on Stack Overflow
[here|http://stackoverflow.com/questions/2176570/how-to-run-all-tests-belonging-to-a-certain-category-in-junit-4/2176791#2176791]
Unfortunately ClasspathSuite is GPL 2.0 licensed, so cannot be used by Qpid.
The only alternative therefore seems to be that we write our own ClassPathSuite
equivalent, i.e. something that searches the classpath for all the classes with
@Test annotations. This is not particularly hard but it is frustrating that we
need reinvent the wheel in this manner. A good starting point is the example
code
[here|http://linsolas.free.fr/wordpress/index.php/2011/02/how-to-categorize-junit-tests-with-maven/].
Upgrade Java test framework to JUnit 4
--
Key: QPID-3025
URL: https://issues.apache.org/jira/browse/QPID-3025
Project: Qpid
Issue Type: Improvement
Components: Java Tests
Reporter: Andrew Kennedy
Assignee: Philip Harvey
Priority: Minor
Attachments: 0001-QPID-3025-WIP-junit4-upgrade.patch
We use JUnit 3.8 currently, and should move to using a more recent version.
JUnit 4.4 includes support for annotations and other useful test features
that will allow us to control our unit and system tests and test profiles
better and easier. This update must still be able to run the existing 3.8
tests, and must also preserve the current exclusion mechanism
(profile.excludes property) but should also support all JUnit 4 features.
This is possible by transferring some functionality from QpidTestCase to a
custom JUnit runner class, and annotating QpidTestCase to use this new test
runner.
See also QPID-2639 which updated the QpidTestCase and modified all other test
cases to inherit from 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] [Updated] (QPID-3569) Refactor TransactionTimeout
[ https://issues.apache.org/jira/browse/QPID-3569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated QPID-3569: Attachment: 0001-QPID-3569-Refactor-TransactionTimeout.patch I reviewed all the code changes and it all looks good to me. I'm attaching a modified patch that just adds some missing @Override annotations and fixes minor formatting. I think this patch can be committed. Refactor TransactionTimeout --- Key: QPID-3569 URL: https://issues.apache.org/jira/browse/QPID-3569 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Keith Wall Assignee: Philip Harvey Attachments: 0001-QPID-3569-Refactor-TransactionTimeout.patch, 0001-QPID-3569-Refactor-TransactionTimeout.patch, 0001-QPID-3569-Refactor-TransactionTimeout.patch, 0001-QPID-3569-Refactor-TransactionTimeout.patch The Transaction Timeout feature of the Java Broker relies heavily on system tests. It would be better if its implementation were refactored to allow more of its functionality to be tested by unit tests and a reduced number of system tests. -- 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] [Assigned] (QPID-4517) Java Broker: default log4j configuration outputs line numbers, which is a performance drag
[
https://issues.apache.org/jira/browse/QPID-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Harvey reassigned QPID-4517:
---
Assignee: Robbie Gemmell (was: Philip Harvey)
changes committed - please can you hit the Accept button if you're happy
Java Broker: default log4j configuration outputs line numbers, which is a
performance drag
--
Key: QPID-4517
URL: https://issues.apache.org/jira/browse/QPID-4517
Project: Qpid
Issue Type: Improvement
Components: Java Broker
Affects Versions: 0.20
Reporter: Philip Harvey
Assignee: Robbie Gemmell
Priority: Minor
Attachments:
0001-QPID-4517-modify-broker-log4j-configuration-to-use-l.patch,
QPID-4517-logging-perf-tests.tar.gz
By default we produce this sort of logging:
{noformat}
2012-12-20 09:52:51,490 INFO [main] (AbstractConfiguration.java:124) -
Tag:'path'
{noformat}
Including line numbers is slow, as described by the log4j documentation
(http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/PatternLayout.html):
WARNING Generating caller location information is extremely slow and should
be avoided unless execution speed is not an issue.
--
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-3569) Refactor TransactionTimeout
[
https://issues.apache.org/jira/browse/QPID-3569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13542738#comment-13542738
]
Philip Harvey commented on QPID-3569:
-
My initial thoughts are:
- TransactionTimeoutHelper.check still has quite a lot of duplication, i.e. for
the open and idle paths. Would the current refactoring be a good opportunity to
resolve this duplication? If so, could we change:
{noformat}
final long transactionStartTime = _transaction.getTransactionStartTime();
final long transactionUpdateTime = _transaction.getTransactionUpdateTime();
if (transactionUpdateTime 0 transactionStartTime 0)
{
// do idle and open logic
}
{noformat}
to:
{noformat}
final long transactionStartTime = _transaction.getTransactionStartTime();
if (transactionUpdateTime 0)
{
// do idle logic
}
final long transactionUpdateTime = _transaction.getTransactionUpdateTime();
if(transactionStartTime 0)
{
// do open logic
}
{noformat}
- The calls to logIfNecessary in the check(..) method have incorrect indentation
- Do the getTransactionUpdateTime() implementations need an @Override
annotation?
Refactor TransactionTimeout
---
Key: QPID-3569
URL: https://issues.apache.org/jira/browse/QPID-3569
Project: Qpid
Issue Type: Improvement
Components: Java Broker
Reporter: Keith Wall
Assignee: Philip Harvey
Attachments: 0001-QPID-3569-Refactor-TransactionTimeout.patch
The Transaction Timeout feature of the Java Broker relies heavily on system
tests. It would be better if its implementation were refactored to allow
more of its functionality to be tested by unit tests and a reduced number of
system tests.
--
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] [Assigned] (QPID-3569) Refactor TransactionTimeout
[ https://issues.apache.org/jira/browse/QPID-3569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey reassigned QPID-3569: --- Assignee: Keith Wall (was: Philip Harvey) added initial review comments... let's discuss these before I do a detailed sweep of the other changes. Refactor TransactionTimeout --- Key: QPID-3569 URL: https://issues.apache.org/jira/browse/QPID-3569 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Keith Wall Assignee: Keith Wall Attachments: 0001-QPID-3569-Refactor-TransactionTimeout.patch The Transaction Timeout feature of the Java Broker relies heavily on system tests. It would be better if its implementation were refactored to allow more of its functionality to be tested by unit tests and a reduced number of system tests. -- 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-4517) Java Broker: default log4j configuration outputs line numbers, which is a performance drag
[
https://issues.apache.org/jira/browse/QPID-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13541401#comment-13541401
]
Philip Harvey commented on QPID-4517:
-
I tested this log format change using a persistent store, with one producer and
one consumer and a transaction batch size of one, again with logger
org.apache.qpid set to DEBUG. I found that it still causes a significant
performance improvement - throughput doubled on my laptop.
My laptop is a cheap dual core machine with an SSD drive, so it probably
exaggerates the impact of this change, due to its fast IO and slow processor.
Nevertheless, these results suggest to me that typical production deployments
would see a significant performance increase when using DEBUG logging.
When the log level is INFO or above, there is, as expected, no measurable
performance improvement.
The scenario I have in mind is when a production support team want to switch on
DEBUG logging for a few minutes to help pin down the source of a performance
problem, and obviously want to minimise the impact of this logging. It is
frustrating when support teams are so fearful of the performance impact of
debug-level logging that they resist enabling it, even if it would help solve a
problem.
Regarding line numbers... on the whole, our log messages are sufficiently
descriptive to allow us to locate the line of code that produced them, without
requiring file names and line numbers. In my short time working on Qpid, I've
never had to resort to using line numbers (in fact, they can be positively
misleading in cases where we've written our own centralised logging functions).
Any logging that is untraceable without an explicit file name and line number
is obviously inadequate and should be fixed.
My view is that the performance increase of this change offsets the lack of
line numbers in the log file. However, I accept that this is a trade-off so
won't push this change if the majority disagree with me.
Java Broker: default log4j configuration outputs line numbers, which is a
performance drag
--
Key: QPID-4517
URL: https://issues.apache.org/jira/browse/QPID-4517
Project: Qpid
Issue Type: Improvement
Components: Java Broker
Affects Versions: 0.20
Reporter: Philip Harvey
Assignee: Philip Harvey
Priority: Minor
Attachments:
0001-QPID-4517-modify-broker-log4j-configuration-to-use-l.patch
By default we produce this sort of logging:
{noformat}
2012-12-20 09:52:51,490 INFO [main] (AbstractConfiguration.java:124) -
Tag:'path'
{noformat}
Including line numbers is slow, as described by the log4j documentation
(http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/PatternLayout.html):
WARNING Generating caller location information is extremely slow and should
be avoided unless execution speed is not an issue.
--
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-4517) Java Broker: default log4j configuration outputs line numbers, which is a performance drag
[
https://issues.apache.org/jira/browse/QPID-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Harvey updated QPID-4517:
Attachment: QPID-4517-logging-perf-tests.tar.gz
Attached perf test config and results corresponding to my the comments I added
a few minutes ago.
Java Broker: default log4j configuration outputs line numbers, which is a
performance drag
--
Key: QPID-4517
URL: https://issues.apache.org/jira/browse/QPID-4517
Project: Qpid
Issue Type: Improvement
Components: Java Broker
Affects Versions: 0.20
Reporter: Philip Harvey
Assignee: Philip Harvey
Priority: Minor
Attachments:
0001-QPID-4517-modify-broker-log4j-configuration-to-use-l.patch,
QPID-4517-logging-perf-tests.tar.gz
By default we produce this sort of logging:
{noformat}
2012-12-20 09:52:51,490 INFO [main] (AbstractConfiguration.java:124) -
Tag:'path'
{noformat}
Including line numbers is slow, as described by the log4j documentation
(http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/PatternLayout.html):
WARNING Generating caller location information is extremely slow and should
be avoided unless execution speed is not an issue.
--
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-4515) Java Broker: improve logging, especially for diagnosis of transactional messaging performance
[ https://issues.apache.org/jira/browse/QPID-4515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated QPID-4515: Status: Ready To Review (was: In Progress) Java Broker: improve logging, especially for diagnosis of transactional messaging performance - Key: QPID-4515 URL: https://issues.apache.org/jira/browse/QPID-4515 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor I've recently been involved in a number of support issues where we were diagnosing performance problems. We were trying to find out at which point in the message flow a delay was occurring, and identified a number of areas where debug logging should be added or improved to facilitate this. We particularly want to track: # The points when frames are received and sent by the broker, including in AMQP 0-8/0-9/0-9-1 environments. # How long BDB commits are taking. # How long post-commit actions are taking -- 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] [Assigned] (QPID-4515) Java Broker: improve logging, especially for diagnosis of transactional messaging performance
[ https://issues.apache.org/jira/browse/QPID-4515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey reassigned QPID-4515: --- Assignee: Keith Wall (was: Philip Harvey) pls review Java Broker: improve logging, especially for diagnosis of transactional messaging performance - Key: QPID-4515 URL: https://issues.apache.org/jira/browse/QPID-4515 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Philip Harvey Assignee: Keith Wall Priority: Minor I've recently been involved in a number of support issues where we were diagnosing performance problems. We were trying to find out at which point in the message flow a delay was occurring, and identified a number of areas where debug logging should be added or improved to facilitate this. We particularly want to track: # The points when frames are received and sent by the broker, including in AMQP 0-8/0-9/0-9-1 environments. # How long BDB commits are taking. # How long post-commit actions are taking -- 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-4515) Java Broker: improve logging, especially for diagnosis of transactional messaging performance
[ https://issues.apache.org/jira/browse/QPID-4515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated QPID-4515: Fix Version/s: 0.21 Java Broker: improve logging, especially for diagnosis of transactional messaging performance - Key: QPID-4515 URL: https://issues.apache.org/jira/browse/QPID-4515 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Philip Harvey Assignee: Keith Wall Priority: Minor Fix For: 0.21 I've recently been involved in a number of support issues where we were diagnosing performance problems. We were trying to find out at which point in the message flow a delay was occurring, and identified a number of areas where debug logging should be added or improved to facilitate this. We particularly want to track: # The points when frames are received and sent by the broker, including in AMQP 0-8/0-9/0-9-1 environments. # How long BDB commits are taking. # How long post-commit actions are taking -- 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-4515) Java Broker: improve logging, especially for diagnosis of transactional messaging performance
[ https://issues.apache.org/jira/browse/QPID-4515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated QPID-4515: Affects Version/s: 0.20 Java Broker: improve logging, especially for diagnosis of transactional messaging performance - Key: QPID-4515 URL: https://issues.apache.org/jira/browse/QPID-4515 Project: Qpid Issue Type: Improvement Components: Java Broker Affects Versions: 0.20 Reporter: Philip Harvey Assignee: Keith Wall Priority: Minor Fix For: 0.21 I've recently been involved in a number of support issues where we were diagnosing performance problems. We were trying to find out at which point in the message flow a delay was occurring, and identified a number of areas where debug logging should be added or improved to facilitate this. We particularly want to track: # The points when frames are received and sent by the broker, including in AMQP 0-8/0-9/0-9-1 environments. # How long BDB commits are taking. # How long post-commit actions are taking -- 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-4515) Java Broker: improve logging, especially for diagnosis of transactional messaging performance
[
https://issues.apache.org/jira/browse/QPID-4515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13536901#comment-13536901
]
Philip Harvey edited comment on QPID-4515 at 12/20/12 10:07 AM:
Committed changes. Some examples of the new logging for an AMQP 0-9-1 session
are pasted below. Please can you review.
Note that frame receipt/dispatch is now logged using the same RECV and SEND
keywords as for AMQP 0-10 sessions, for the sake of consistency.
{noformat}
2012-12-20 09:54:29,994 DEBUG [IoReceiver - /127.0.0.1:44157]
(AMQProtocolEngine.java:312) - RECV: Frame channelId: 1, bodyFrame:
[TxCommitBodyImpl: ]
...
...
2012-12-20 09:54:29,997 DEBUG [IoReceiver - /127.0.0.1:44157]
(AMQProtocolEngine.java:350) - Frame handled in 3 ms. Frame: Frame channelId:
1, bodyFrame: [Tx
CommitBodyImpl: ]
2012-12-20 09:54:29,997 DEBUG [IoReceiver - /127.0.0.1:44157]
(AMQChannel.java:1588) - sync() called on channel 1(479724676)
2012-12-20 09:54:30,211 DEBUG [Commit-Thread-test]
(CommitThreadWrapper.java:227) - flushLog completed in 214 ms
2012-12-20 09:54:30,212 DEBUG [IoReceiver - /127.0.0.1:44157]
(CommitThreadWrapper.java:149) - waitForCompletion returning after 215 ms for
transaction Tran
saction id=23
2012-12-20 09:54:30,212 DEBUG [IoReceiver - /127.0.0.1:44157]
(LocalTransaction.java:389) - Beginning 2 post transaction actions
2012-12-20 09:54:30,214 DEBUG [IoReceiver - /127.0.0.1:44157]
(LocalTransaction.java:399) - Completed post transaction actions
2012-12-20 09:54:30,214 DEBUG [IoReceiver - /127.0.0.1:44157]
(AMQProtocolEngine.java:558) - SEND: Frame channelId: 1, bodyFrame:
[TxCommitOkBodyImpl: ]
...
...
2012-12-20 10:05:25,936 DEBUG [pool-3-thread-4] (AMQProtocolEngine.java:558) -
SEND: [CompositeAMQBodyBlock methodBody=[EncodedDeliveryBody underlyingBody: [
BasicDeliverBodyImpl: consumerTag=1, deliveryTag=1, redelivered=false,
exchange=amq.direct, routingKey=queue1]],
headerBody=ContentHeaderBody{classId=60, wei
ght=0, bodySize=40, properties=reply-to = null,propertyFlags =
47568,ApplicationID = null,ClusterID = null,UserId = guest,JMSMessageID =
ID:527719f8-383f-36e
6-a4b1-6f68adb27d25,JMSCorrelationID = null,JMSDeliveryMode = 2,JMSExpiration =
0,JMSPriority = 4,JMSTimestamp = 1355997256727,JMSType = null}, contentBody=o
rg.apache.qpid.server.output.ProtocolOutputConverterImpl$MessageContentSourceBody@9ffdf86,
channel=1]
{noformat}
was (Author: philharveyonline):
pls review
Java Broker: improve logging, especially for diagnosis of transactional
messaging performance
-
Key: QPID-4515
URL: https://issues.apache.org/jira/browse/QPID-4515
Project: Qpid
Issue Type: Improvement
Components: Java Broker
Reporter: Philip Harvey
Assignee: Keith Wall
Priority: Minor
I've recently been involved in a number of support issues where we were
diagnosing performance problems.
We were trying to find out at which point in the message flow a delay was
occurring, and identified a number of areas where debug logging should be
added or improved to facilitate this.
We particularly want to track:
# The points when frames are received and sent by the broker, including in
AMQP 0-8/0-9/0-9-1 environments.
# How long BDB commits are taking.
# How long post-commit actions are taking
--
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-4517) Java Broker: default log4j configuration outputs line numbers, which is a performance drag
Philip Harvey created QPID-4517:
---
Summary: Java Broker: default log4j configuration outputs line
numbers, which is a performance drag
Key: QPID-4517
URL: https://issues.apache.org/jira/browse/QPID-4517
Project: Qpid
Issue Type: Improvement
Components: Java Broker
Affects Versions: 0.20
Reporter: Philip Harvey
Assignee: Philip Harvey
Priority: Minor
By default we produce this sort of logging:
{noformat}
2012-12-20 09:52:51,490 INFO [main] (AbstractConfiguration.java:124) -
Tag:'path'
{noformat}
Including line numbers is slow, as described by the log4j documentation
(http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/PatternLayout.html):
WARNING Generating caller location information is extremely slow and should be
avoided unless execution speed is not an issue.
--
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-4517) Java Broker: default log4j configuration outputs line numbers, which is a performance drag
[
https://issues.apache.org/jira/browse/QPID-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Harvey updated QPID-4517:
Attachment: 0001-QPID-4517-modify-broker-log4j-configuration-to-use-l.patch
attached patch
Java Broker: default log4j configuration outputs line numbers, which is a
performance drag
--
Key: QPID-4517
URL: https://issues.apache.org/jira/browse/QPID-4517
Project: Qpid
Issue Type: Improvement
Components: Java Broker
Affects Versions: 0.20
Reporter: Philip Harvey
Assignee: Philip Harvey
Priority: Minor
Attachments:
0001-QPID-4517-modify-broker-log4j-configuration-to-use-l.patch
By default we produce this sort of logging:
{noformat}
2012-12-20 09:52:51,490 INFO [main] (AbstractConfiguration.java:124) -
Tag:'path'
{noformat}
Including line numbers is slow, as described by the log4j documentation
(http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/PatternLayout.html):
WARNING Generating caller location information is extremely slow and should
be avoided unless execution speed is not an issue.
--
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-4517) Java Broker: default log4j configuration outputs line numbers, which is a performance drag
[
https://issues.apache.org/jira/browse/QPID-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Harvey updated QPID-4517:
Status: Ready To Review (was: In Progress)
Java Broker: default log4j configuration outputs line numbers, which is a
performance drag
--
Key: QPID-4517
URL: https://issues.apache.org/jira/browse/QPID-4517
Project: Qpid
Issue Type: Improvement
Components: Java Broker
Affects Versions: 0.20
Reporter: Philip Harvey
Assignee: Philip Harvey
Priority: Minor
Attachments:
0001-QPID-4517-modify-broker-log4j-configuration-to-use-l.patch
By default we produce this sort of logging:
{noformat}
2012-12-20 09:52:51,490 INFO [main] (AbstractConfiguration.java:124) -
Tag:'path'
{noformat}
Including line numbers is slow, as described by the log4j documentation
(http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/PatternLayout.html):
WARNING Generating caller location information is extremely slow and should
be avoided unless execution speed is not an issue.
--
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] [Assigned] (QPID-4517) Java Broker: default log4j configuration outputs line numbers, which is a performance drag
[
https://issues.apache.org/jira/browse/QPID-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Harvey reassigned QPID-4517:
---
Assignee: Robbie Gemmell (was: Philip Harvey)
Robbie - what do you think about this change?
Informal testing showed a x2 throughput improvement when using transient
messages and with DEBUG logging enabled.
Obviously in most production deployments the speed-up will be much smaller.
Java Broker: default log4j configuration outputs line numbers, which is a
performance drag
--
Key: QPID-4517
URL: https://issues.apache.org/jira/browse/QPID-4517
Project: Qpid
Issue Type: Improvement
Components: Java Broker
Affects Versions: 0.20
Reporter: Philip Harvey
Assignee: Robbie Gemmell
Priority: Minor
Attachments:
0001-QPID-4517-modify-broker-log4j-configuration-to-use-l.patch
By default we produce this sort of logging:
{noformat}
2012-12-20 09:52:51,490 INFO [main] (AbstractConfiguration.java:124) -
Tag:'path'
{noformat}
Including line numbers is slow, as described by the log4j documentation
(http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/PatternLayout.html):
WARNING Generating caller location information is extremely slow and should
be avoided unless execution speed is not an issue.
--
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-4503) Producer transaction timeout detection feature may produce spurious open/idle alerts and close client connections/sessions without good cause
[
https://issues.apache.org/jira/browse/QPID-4503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Harvey resolved QPID-4503.
-
Resolution: Fixed
reviewed the code - looks good.
Producer transaction timeout detection feature may produce spurious open/idle
alerts and close client connections/sessions without good cause
-
Key: QPID-4503
URL: https://issues.apache.org/jira/browse/QPID-4503
Project: Qpid
Issue Type: Bug
Components: Java Broker
Affects Versions: 0.12, 0.14, 0.16, 0.18, 0.20
Reporter: Keith Wall
Assignee: Philip Harvey
Fix For: 0.21
Attachments: QPID-4503_repro.tar.bz2
There is a race condition in AMQChannel#checkTransactionStatus (and
ServerSession#checkTransactionStatus) which can lead to spurious open/idle
alerts and needlessly closed client connections (0-8..0-9-1) or client
sessions (0-10).
When the defect manifests, the alert generated incorrectly identifies the
transaction as being open since Jan 1, 1970. eg. 1,355,281,641,112 ms
e.g.
{noformat}
[con:11(guest@/127.0.0.1:47276/test)/ch:2] CHN-1007 : Open Transaction :
1,355,281,641,112 ms
{noformat}
This defect affects only users who have configured the transaction timeout
feature (as described
http://qpid.apache.org/books/trunk/AMQP-Messaging-Broker-Java-Book/html/Java-Broker-Runtime-Producer-Transaction-Timeout.html).
--
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-4515) Java Broker: improve logging, especially for diagnosis of transactional messaging performance
Philip Harvey created QPID-4515: --- Summary: Java Broker: improve logging, especially for diagnosis of transactional messaging performance Key: QPID-4515 URL: https://issues.apache.org/jira/browse/QPID-4515 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor I've recently been involved in a number of support issues where we were diagnosing performance problems. We were trying to find out at which point in the message flow a delay was occurring, and identified a number of areas where debug logging should be added or improved to facilitate this. We particularly want to track: # The points when frames are received and sent by the broker, including in AMQP 0-8/0-9/0-9-1 environments. # How long BDB commits are taking. # How long post-commit actions are taking -- 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-4438) Java broker would be easier to support if it reported a better summary of usage
Philip Harvey created QPID-4438: --- Summary: Java broker would be easier to support if it reported a better summary of usage Key: QPID-4438 URL: https://issues.apache.org/jira/browse/QPID-4438 Project: Qpid Issue Type: Improvement Components: Java Broker Affects Versions: 0.18 Reporter: Philip Harvey Priority: Minor I help other Qpid users to diagnose Qpid problems. In order to do this, I usually want to find out how they are using Qpid. For example: * How many connections, sessions, consumers currently exist * How many of each have been created and deleted in the last minute, hour and day * Possibly some aggregation by client id, IP address or “parent object” (eg show number of sessions created on each connection during the sample period) Discovering this is sometimes easy but is often hard, and in some cases I am inadvertently misled by users. I would like Qpid to report these statistics, both in a verbose from via a management interface, and a more concise form that is logged periodically. -- 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] [Assigned] (QPID-4422) Python Client (0-8..0-9) should allow instance client property to be passed in order to allow re-subscribing to durable subscriptions
[ https://issues.apache.org/jira/browse/QPID-4422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey reassigned QPID-4422: --- Assignee: Keith Wall (was: Philip Harvey) please could you apply the replace-tabs patch Python Client (0-8..0-9) should allow instance client property to be passed in order to allow re-subscribing to durable subscriptions --- Key: QPID-4422 URL: https://issues.apache.org/jira/browse/QPID-4422 Project: Qpid Issue Type: Bug Components: Python Client Affects Versions: 0.14, 0.16, 0.18 Reporter: Keith Wall Assignee: Keith Wall Fix For: 0.19 Attachments: 0001-QPID-4422-removed-tabs-from-the-new-test.patch In order reconnect to an exclusive queue, the client must reconnect with the same clientid. In the Python 0-8 and 0-9 client code, this is currently impossible as it does not allow the instance client property to be passed to the broker when performing the connection.start, and so the Broker assigns a random one. This makes it impossible for the Python client users to use exclusive queues, which are integral to using durable subscriptions properly. The 0-10 code does not have this problem. The Python client (0-8..0-9 code paths) should be changed to allow the user to pass the client_properties, thus allowing them to specify the instance. We should also take this opportunity to pass the client version number. -- 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-4422) Python Client (0-8..0-9) should allow instance client property to be passed in order to allow re-subscribing to durable subscriptions
[ https://issues.apache.org/jira/browse/QPID-4422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated QPID-4422: Attachment: 0001-QPID-4422-removed-tabs-from-the-new-test.patch The changes look functionally good but contain some tabs. These are removed in this patch. Python Client (0-8..0-9) should allow instance client property to be passed in order to allow re-subscribing to durable subscriptions --- Key: QPID-4422 URL: https://issues.apache.org/jira/browse/QPID-4422 Project: Qpid Issue Type: Bug Components: Python Client Affects Versions: 0.14, 0.16, 0.18 Reporter: Keith Wall Assignee: Philip Harvey Fix For: 0.19 Attachments: 0001-QPID-4422-removed-tabs-from-the-new-test.patch In order reconnect to an exclusive queue, the client must reconnect with the same clientid. In the Python 0-8 and 0-9 client code, this is currently impossible as it does not allow the instance client property to be passed to the broker when performing the connection.start, and so the Broker assigns a random one. This makes it impossible for the Python client users to use exclusive queues, which are integral to using durable subscriptions properly. The 0-10 code does not have this problem. The Python client (0-8..0-9 code paths) should be changed to allow the user to pass the client_properties, thus allowing them to specify the instance. We should also take this opportunity to pass the client version number. -- 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-4289) [Java Client 0-8/0-9.x] Failover functionality sometimes does not restore the connection
[ https://issues.apache.org/jira/browse/QPID-4289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey resolved QPID-4289. - Resolution: Fixed I reviewed the changes Robbie made in the light of QPID-4344. All looks good. [Java Client 0-8/0-9.x] Failover functionality sometimes does not restore the connection Key: QPID-4289 URL: https://issues.apache.org/jira/browse/QPID-4289 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.16, 0.18, 0.19 Reporter: Alex Rudyy Assignee: Philip Harvey Fix For: 0.19 Attachments: 0001-QPID-4289-Fix-failover-issues.patch Failover functionality on 0-8/0-9.x java client does not restore the connection in the following scenarios: * when on initial establishing of the connectivity the connection object is marked as closed after not being able to connect to the first brokers from the broker list but at the end it manages to connect to the one of the following brokers from the broker list * there is a racing condition between waking up the connection state waiter and closing the phisical connection on receiving ConnectionClose command from the broker. As result, waiters are notified, new connection is created and closed afterwards. * on killing the broker when no IOException is thrown from socket input/output streams but instead -1 is returned by read operation, the failover starts but IoSender thread is left running. As result, on multiple reconnection attempts the thread resources can be exhausted and that can potentially result in OOME. -- 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-3025) Upgrade Java test framework to JUnit 4
[ https://issues.apache.org/jira/browse/QPID-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13489359#comment-13489359 ] Philip Harvey edited comment on QPID-3025 at 11/4/12 5:02 AM: -- Work-in-progress JUnit4 upgrade, attached to give others early visibility of what's involved in this upgrade. I've not done much sanity-checking of this change yet. I intend to replace the test filtering logic in QpidTestCase with a Junit Runner implementation. This will probably extend the bundled Categories Runner and its accompanying Filter implementation to add our properties file-driven test exclusion logic. was (Author: philharveyonline): Work-in-progress JUnit4 upgrade, attached to give others early visibility of what's involved in this upgrade. I've not done much sanity-checking of this change yet. Upgrade Java test framework to JUnit 4 -- Key: QPID-3025 URL: https://issues.apache.org/jira/browse/QPID-3025 Project: Qpid Issue Type: Improvement Components: Java Tests Reporter: Andrew Kennedy Assignee: Philip Harvey Priority: Minor Attachments: 0001-QPID-3025-WIP-junit4-upgrade.patch We use JUnit 3.8 currently, and should move to using a more recent version. JUnit 4.4 includes support for annotations and other useful test features that will allow us to control our unit and system tests and test profiles better and easier. This update must still be able to run the existing 3.8 tests, and must also preserve the current exclusion mechanism (profile.excludes property) but should also support all JUnit 4 features. This is possible by transferring some functionality from QpidTestCase to a custom JUnit runner class, and annotating QpidTestCase to use this new test runner. See also QPID-2639 which updated the QpidTestCase and modified all other test cases to inherit from 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
