[jira] [Assigned] (QPID-4053) Performance Test Framework: QueueDelete can timeout if test ends when too many unprocessed messages remain on test queue
[
https://issues.apache.org/jira/browse/QPID-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall reassigned QPID-4053:
Assignee: Philip Harvey
Performance Test Framework: QueueDelete can timeout if test ends when too
many unprocessed messages remain on test queue
Key: QPID-4053
URL: https://issues.apache.org/jira/browse/QPID-4053
Project: Qpid
Issue Type: Bug
Components: Java Performance Tests
Affects Versions: 0.17
Reporter: Keith Wall
Assignee: Philip Harvey
There is a problem in the new Performance Test Framework. If a test
utilising the maxiumumDuration feature completes with too many messages left
on a queue (as would be the case where number of producers out-number
consumers), the QueueDelete command issued by the framework can apparently
fail owing to a timeout exception. The command does in fact complete
successfully server side, it is just the client gives up awaiting the
response. This can cause a spurious test failure.
I see this with VaryingNumberOfParticipants.json when maximumDuration is set
to 100seconds.
{code}
org.apache.qpid.AMQTimeoutException: Server did not respond in a timely
fashion [error code 408: Request Timeout]
at
org.apache.qpid.client.util.BlockingWaiter.block(BlockingWaiter.java:177)
at
org.apache.qpid.client.protocol.BlockingMethodFrameListener.blockForFrame(BlockingMethodFrameListener.java:122)
at
org.apache.qpid.client.protocol.AMQProtocolHandler.writeCommandFrameAndWaitForReply(AMQProtocolHandler.java:656)
at
org.apache.qpid.client.protocol.AMQProtocolHandler.syncWrite(AMQProtocolHandler.java:677)
at
org.apache.qpid.client.protocol.AMQProtocolHandler.syncWrite(AMQProtocolHandler.java:671)
at
org.apache.qpid.client.AMQSession_0_8.sendQueueDelete(AMQSession_0_8.java:429)
at
org.apache.qpid.disttest.jms.QpidQueueCreator.deleteQueue(QpidQueueCreator.java:88)
at
org.apache.qpid.disttest.jms.QpidQueueCreator.deleteQueues(QpidQueueCreator.java:55)
at
org.apache.qpid.disttest.jms.ControllerJmsDelegate.deleteQueues(ControllerJmsDelegate.java:198)
at
org.apache.qpid.disttest.controller.TestRunner.deleteQueues(TestRunner.java:232)
at
org.apache.qpid.disttest.controller.TestRunner.runParts(TestRunner.java:139)
at
org.apache.qpid.disttest.controller.TestRunner.run(TestRunner.java:103)
at
org.apache.qpid.disttest.controller.Controller.runAllTests(Controller.java:172)
at
org.apache.qpid.disttest.ControllerRunner.runTest(ControllerRunner.java:120)
at
org.apache.qpid.disttest.ControllerRunner.runTests(ControllerRunner.java:105)
at
org.apache.qpid.disttest.ControllerRunner.runController(ControllerRunner.java:80)
at
org.apache.qpid.disttest.ControllerRunner.main(ControllerRunner.java:69)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-4055) [Java Broker] Update optional BDB store to use latest version of BDB
Rob Godfrey created QPID-4055: - Summary: [Java Broker] Update optional BDB store to use latest version of BDB Key: QPID-4055 URL: https://issues.apache.org/jira/browse/QPID-4055 Project: Qpid Issue Type: Bug Components: Java Broker, Java Broker BDB Store Reporter: Rob Godfrey Fix For: 0.17 BDB JE 5.0.55 has been released and addresses an issue that we have seen with regards to HA replication. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-4056) HAClusterManagementTest.testRemoveNodeFromGroup fails occasionally on Apache CI
Keith Wall created QPID-4056:
Summary: HAClusterManagementTest.testRemoveNodeFromGroup fails
occasionally on Apache CI
Key: QPID-4056
URL: https://issues.apache.org/jira/browse/QPID-4056
Project: Qpid
Issue Type: Bug
Components: Java Broker BDB Store, Java Tests
Affects Versions: 0.17
Reporter: Keith Wall
Assignee: Keith Wall
Build 302 showed the following failure for the new test:
https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Java-Java-BDB-TestMatrix/302/
Unexpected number of data rows before test expected:3 but was:4
{code}
Stacktrace
junit.framework.AssertionFailedError: Unexpected number of data rows before
test expected:3 but was:4
at
org.apache.qpid.server.store.berkeleydb.HAClusterManagementTest.testRemoveNodeFromGroup(HAClusterManagementTest.java:163)
at
org.apache.qpid.test.utils.QpidBrokerTestCase.runBare(QpidBrokerTestCase.java:237)
at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:139)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-4049) Linux C++ broker crashes when Windows client connects SSL with expired certificate
[ https://issues.apache.org/jira/browse/QPID-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim reassigned QPID-4049: Assignee: Andrew Stitcher Linux C++ broker crashes when Windows client connects SSL with expired certificate -- Key: QPID-4049 URL: https://issues.apache.org/jira/browse/QPID-4049 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.16 Environment: Linux Reporter: Steve Huston Assignee: Andrew Stitcher Fix For: 0.17 Testing Windows client - Linux broker SSL connections. The SSL cert is expired and this results in the following on Linux: 2012-06-08 17:08:12 error Error reading socket: Encountered end of file [-5938] 2012-06-08 17:08:14 error Connection 192.168.10.4:5671-192.168.10.40:60748 No protocol received closing Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x40a00940 (LWP 15265)] 0x2c0d9164 in qpid::sys::ssl::ProtocolTimeoutTask::fire() () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/ssl.so (gdb) where #0 0x2c0d9164 in qpid::sys::ssl::ProtocolTimeoutTask::fire() () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/ssl.so #1 0x2b51c7bc in qpid::sys::TimerTask::fireTask() () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/libqpidcommon.so.2.0.0 #2 0x2b51c952 in qpid::sys::Timer::fire(boost::intrusive_ptrqpid::sys::TimerTask) () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/libqpidcommon.so.2.0.0 #3 0x2b51d22d in qpid::sys::Timer::run() () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/libqpidcommon.so.2.0.0 #4 0x2b4a9e74 in qpid::sys::(anonymous namespace)::runRunnable(void*) () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/libqpidcommon.so.2.0.0 #5 0x00318f60677d in start_thread () from /lib64/libpthread.so.0 #6 0x00318eed325d in clone () from /lib64/libc.so.6 (gdb) On Windows, this error looks like: 2012-06-08 17:07:06 notice SSL negotiation failed to smokey:5671: The received certificate has expired. 2012-06-08 17:07:06 warning Connect failed: The received certificate has expired . (..\..\..\..\cpp\src\qpid\client\windows\SslConnector.cpp:111) 2012-06-08 17:07:06 warning Connection [192.168.10.40:60748-smokey:5671] closed Connection [192.168.10.40:60748-smokey:5671] closed E:\ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-4049) Linux C++ broker crashes when Windows client connects SSL with expired certificate
[ https://issues.apache.org/jira/browse/QPID-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated QPID-4049: - Priority: Critical (was: Major) Fix Version/s: 0.17 Linux C++ broker crashes when Windows client connects SSL with expired certificate -- Key: QPID-4049 URL: https://issues.apache.org/jira/browse/QPID-4049 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.16 Environment: Linux Reporter: Steve Huston Assignee: Andrew Stitcher Priority: Critical Fix For: 0.17 Testing Windows client - Linux broker SSL connections. The SSL cert is expired and this results in the following on Linux: 2012-06-08 17:08:12 error Error reading socket: Encountered end of file [-5938] 2012-06-08 17:08:14 error Connection 192.168.10.4:5671-192.168.10.40:60748 No protocol received closing Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x40a00940 (LWP 15265)] 0x2c0d9164 in qpid::sys::ssl::ProtocolTimeoutTask::fire() () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/ssl.so (gdb) where #0 0x2c0d9164 in qpid::sys::ssl::ProtocolTimeoutTask::fire() () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/ssl.so #1 0x2b51c7bc in qpid::sys::TimerTask::fireTask() () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/libqpidcommon.so.2.0.0 #2 0x2b51c952 in qpid::sys::Timer::fire(boost::intrusive_ptrqpid::sys::TimerTask) () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/libqpidcommon.so.2.0.0 #3 0x2b51d22d in qpid::sys::Timer::run() () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/libqpidcommon.so.2.0.0 #4 0x2b4a9e74 in qpid::sys::(anonymous namespace)::runRunnable(void*) () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/libqpidcommon.so.2.0.0 #5 0x00318f60677d in start_thread () from /lib64/libpthread.so.0 #6 0x00318eed325d in clone () from /lib64/libc.so.6 (gdb) On Windows, this error looks like: 2012-06-08 17:07:06 notice SSL negotiation failed to smokey:5671: The received certificate has expired. 2012-06-08 17:07:06 warning Connect failed: The received certificate has expired . (..\..\..\..\cpp\src\qpid\client\windows\SslConnector.cpp:111) 2012-06-08 17:07:06 warning Connection [192.168.10.40:60748-smokey:5671] closed Connection [192.168.10.40:60748-smokey:5671] closed E:\ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-4057) Deadlock during AMQProtocolEngine.closeChannel (0-8...0-9-1)
Keith Wall created QPID-4057:
Summary: Deadlock during AMQProtocolEngine.closeChannel
(0-8...0-9-1)
Key: QPID-4057
URL: https://issues.apache.org/jira/browse/QPID-4057
Project: Qpid
Issue Type: Bug
Components: Java Broker
Reporter: Keith Wall
Fix For: 0.17
I encountered this deadlock today whilst running
SynchReceiveTest.testTwoConsumersInterleaved.
{code}
012-06-12 13:06:22
Full thread dump Java HotSpot(TM) 64-Bit Server VM (20.0-b11 mixed mode):
Attach Listener daemon prio=10 tid=0x498ac000 nid=0x3c83 waiting on
condition [0x]
java.lang.Thread.State: RUNNABLE
pool-3-thread-66 prio=10 tid=0x498ab800 nid=0x3c10 waiting on
condition [0x44d8]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0xe128a6f0 (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
pool-3-thread-65 prio=10 tid=0x4975e000 nid=0x3c0e waiting on
condition [0x44b7e000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0xe128a6f0 (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
pool-3-thread-64 prio=10 tid=0x49ecb800 nid=0x3c0c waiting on
condition [0x43b6e000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0xe128a6f0 (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
pool-3-thread-63 prio=10 tid=0x4afff000 nid=0x3c0b waiting on
condition [0x44073000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0xe128a6f0 (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
pool-3-thread-62 prio=10 tid=0x49905800 nid=0x3c0a waiting on
condition [0x43d7]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0xe128a6f0 (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
IoReceiver - /127.0.0.1:60022 daemon prio=10
[jira] [Assigned] (QPID-4057) Deadlock during AMQProtocolEngine.closeChannel (0-8...0-9-1)
[
https://issues.apache.org/jira/browse/QPID-4057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall reassigned QPID-4057:
Assignee: Keith Wall
Deadlock during AMQProtocolEngine.closeChannel (0-8...0-9-1)
Key: QPID-4057
URL: https://issues.apache.org/jira/browse/QPID-4057
Project: Qpid
Issue Type: Bug
Components: Java Broker
Reporter: Keith Wall
Assignee: Keith Wall
Fix For: 0.17
I encountered this deadlock today whilst running
SynchReceiveTest.testTwoConsumersInterleaved.
{code}
012-06-12 13:06:22
Full thread dump Java HotSpot(TM) 64-Bit Server VM (20.0-b11 mixed mode):
Attach Listener daemon prio=10 tid=0x498ac000 nid=0x3c83 waiting on
condition [0x]
java.lang.Thread.State: RUNNABLE
pool-3-thread-66 prio=10 tid=0x498ab800 nid=0x3c10 waiting on
condition [0x44d8]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0xe128a6f0 (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
pool-3-thread-65 prio=10 tid=0x4975e000 nid=0x3c0e waiting on
condition [0x44b7e000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0xe128a6f0 (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
pool-3-thread-64 prio=10 tid=0x49ecb800 nid=0x3c0c waiting on
condition [0x43b6e000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0xe128a6f0 (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
pool-3-thread-63 prio=10 tid=0x4afff000 nid=0x3c0b waiting on
condition [0x44073000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0xe128a6f0 (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
pool-3-thread-62 prio=10 tid=0x49905800 nid=0x3c0a waiting on
condition [0x43d7]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0xe128a6f0 (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at
Re: intrusive_ptr::reset new?
Sorry, Steve - my bad. The older boost doesn't have the reset() member. I'll fix it - a simple assignment to zero should be equivalent. -K - Original Message - There's currently a build error in qpid/broker/MessageDeque.cpp that boost::intrusive_ptr has no member reset() - is reset() a new feature? Google trolling suggests so… my error is happening on stock RHEL 5, which has Boost 1.33 -Steve - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-4057) Deadlock during AMQProtocolEngine.closeChannel (0-8...0-9-1)
[
https://issues.apache.org/jira/browse/QPID-4057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13293648#comment-13293648
]
Robbie Gemmell edited comment on QPID-4057 at 6/12/12 2:11 PM:
---
comment-then-run before I go out again...
This deadlock isnt possible on trunk as AMQProtocolEngine#received() isnt
synchronised (which seems to be the problem from the stacks), so I assume it
happened on the config etc branch? If so, might want to ask Rob why 'we'
synchronised it and if we can reverse it :)
was (Author: gemmellr):
comment-then-run before I go out again...
This deadlock isnt possible on trunk as AMQProtocolEngine#received() isnt
synchronised (which seems to be the problem from below stacks), so I assume it
happened on the config etc branch? If so, might want to ask Rob why 'we'
synchronised it and if we can reverse it :)
Deadlock during AMQProtocolEngine.closeChannel (0-8...0-9-1)
Key: QPID-4057
URL: https://issues.apache.org/jira/browse/QPID-4057
Project: Qpid
Issue Type: Bug
Components: Java Broker
Reporter: Keith Wall
Assignee: Keith Wall
Fix For: 0.17
I encountered this deadlock today whilst running
SynchReceiveTest.testTwoConsumersInterleaved.
{code}
012-06-12 13:06:22
Full thread dump Java HotSpot(TM) 64-Bit Server VM (20.0-b11 mixed mode):
Attach Listener daemon prio=10 tid=0x498ac000 nid=0x3c83 waiting on
condition [0x]
java.lang.Thread.State: RUNNABLE
pool-3-thread-66 prio=10 tid=0x498ab800 nid=0x3c10 waiting on
condition [0x44d8]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0xe128a6f0 (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
pool-3-thread-65 prio=10 tid=0x4975e000 nid=0x3c0e waiting on
condition [0x44b7e000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0xe128a6f0 (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
pool-3-thread-64 prio=10 tid=0x49ecb800 nid=0x3c0c waiting on
condition [0x43b6e000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0xe128a6f0 (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
pool-3-thread-63 prio=10 tid=0x4afff000 nid=0x3c0b waiting on
condition [0x44073000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0xe128a6f0 (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at
[jira] [Commented] (QPID-4057) Deadlock during AMQProtocolEngine.closeChannel (0-8...0-9-1)
[
https://issues.apache.org/jira/browse/QPID-4057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13293648#comment-13293648
]
Robbie Gemmell commented on QPID-4057:
--
comment-then-run before I go out again...
This deadlock isnt possible on trunk as AMQProtocolEngine#received() isnt
synchronised (which seems to be the problem from below stacks), so I assume it
happened on the config etc branch? If so, might want to ask Rob why 'we'
synchronised it and if we can reverse it :)
Deadlock during AMQProtocolEngine.closeChannel (0-8...0-9-1)
Key: QPID-4057
URL: https://issues.apache.org/jira/browse/QPID-4057
Project: Qpid
Issue Type: Bug
Components: Java Broker
Reporter: Keith Wall
Assignee: Keith Wall
Fix For: 0.17
I encountered this deadlock today whilst running
SynchReceiveTest.testTwoConsumersInterleaved.
{code}
012-06-12 13:06:22
Full thread dump Java HotSpot(TM) 64-Bit Server VM (20.0-b11 mixed mode):
Attach Listener daemon prio=10 tid=0x498ac000 nid=0x3c83 waiting on
condition [0x]
java.lang.Thread.State: RUNNABLE
pool-3-thread-66 prio=10 tid=0x498ab800 nid=0x3c10 waiting on
condition [0x44d8]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0xe128a6f0 (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
pool-3-thread-65 prio=10 tid=0x4975e000 nid=0x3c0e waiting on
condition [0x44b7e000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0xe128a6f0 (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
pool-3-thread-64 prio=10 tid=0x49ecb800 nid=0x3c0c waiting on
condition [0x43b6e000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0xe128a6f0 (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
pool-3-thread-63 prio=10 tid=0x4afff000 nid=0x3c0b waiting on
condition [0x44073000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0xe128a6f0 (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
pool-3-thread-62 prio=10 tid=0x49905800 nid=0x3c0a waiting on
condition [0x43d7]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for
[jira] [Commented] (QPID-4057) Deadlock during AMQProtocolEngine.closeChannel (0-8...0-9-1)
[
https://issues.apache.org/jira/browse/QPID-4057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13293656#comment-13293656
]
Rob Godfrey commented on QPID-4057:
---
So, I have absolutely no recollection of this :-)
It seems to be in the initial check in of the config code branch... There's no
reason that I can think of why the locking requirements would have changed at
this point (or subsequently).
Deadlock during AMQProtocolEngine.closeChannel (0-8...0-9-1)
Key: QPID-4057
URL: https://issues.apache.org/jira/browse/QPID-4057
Project: Qpid
Issue Type: Bug
Components: Java Broker
Reporter: Keith Wall
Assignee: Keith Wall
Fix For: 0.17
I encountered this deadlock today whilst running
SynchReceiveTest.testTwoConsumersInterleaved.
{code}
012-06-12 13:06:22
Full thread dump Java HotSpot(TM) 64-Bit Server VM (20.0-b11 mixed mode):
Attach Listener daemon prio=10 tid=0x498ac000 nid=0x3c83 waiting on
condition [0x]
java.lang.Thread.State: RUNNABLE
pool-3-thread-66 prio=10 tid=0x498ab800 nid=0x3c10 waiting on
condition [0x44d8]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0xe128a6f0 (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
pool-3-thread-65 prio=10 tid=0x4975e000 nid=0x3c0e waiting on
condition [0x44b7e000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0xe128a6f0 (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
pool-3-thread-64 prio=10 tid=0x49ecb800 nid=0x3c0c waiting on
condition [0x43b6e000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0xe128a6f0 (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
pool-3-thread-63 prio=10 tid=0x4afff000 nid=0x3c0b waiting on
condition [0x44073000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0xe128a6f0 (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
pool-3-thread-62 prio=10 tid=0x49905800 nid=0x3c0a waiting on
condition [0x43d7]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0xe128a6f0 (a
Re: 0.18 release update - upcoming dates
I'd like to get the patch for QPID-3914 included. I should be able to get it in this week or next. -Steve On Jun 11, 2012, at 10:49 PM, jr...@redhat.com wrote: Hi, folks. The time for 0.18 alpha is rapidly approaching, and beta soon after. I've adjusted the dates to allow a little more time for development, since this warning comes rather late. 0.18 alpha, 18 June Deadline for major features and disruptive changes 0.18 beta, 2 JulyWe branch for release, and 0.19 opens Contact me if there's something you'd like to get in for 0.18, and we can figure out where it fits. Thanks, Justin - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4049) Linux C++ broker crashes when Windows client connects SSL with expired certificate
[ https://issues.apache.org/jira/browse/QPID-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated QPID-4049: -- Affects Version/s: (was: 0.16) 0.17 Linux C++ broker crashes when Windows client connects SSL with expired certificate -- Key: QPID-4049 URL: https://issues.apache.org/jira/browse/QPID-4049 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.17 Environment: Linux Reporter: Steve Huston Assignee: Andrew Stitcher Priority: Critical Fix For: 0.17 Testing Windows client - Linux broker SSL connections. The SSL cert is expired and this results in the following on Linux: 2012-06-08 17:08:12 error Error reading socket: Encountered end of file [-5938] 2012-06-08 17:08:14 error Connection 192.168.10.4:5671-192.168.10.40:60748 No protocol received closing Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x40a00940 (LWP 15265)] 0x2c0d9164 in qpid::sys::ssl::ProtocolTimeoutTask::fire() () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/ssl.so (gdb) where #0 0x2c0d9164 in qpid::sys::ssl::ProtocolTimeoutTask::fire() () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/ssl.so #1 0x2b51c7bc in qpid::sys::TimerTask::fireTask() () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/libqpidcommon.so.2.0.0 #2 0x2b51c952 in qpid::sys::Timer::fire(boost::intrusive_ptrqpid::sys::TimerTask) () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/libqpidcommon.so.2.0.0 #3 0x2b51d22d in qpid::sys::Timer::run() () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/libqpidcommon.so.2.0.0 #4 0x2b4a9e74 in qpid::sys::(anonymous namespace)::runRunnable(void*) () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/libqpidcommon.so.2.0.0 #5 0x00318f60677d in start_thread () from /lib64/libpthread.so.0 #6 0x00318eed325d in clone () from /lib64/libc.so.6 (gdb) On Windows, this error looks like: 2012-06-08 17:07:06 notice SSL negotiation failed to smokey:5671: The received certificate has expired. 2012-06-08 17:07:06 warning Connect failed: The received certificate has expired . (..\..\..\..\cpp\src\qpid\client\windows\SslConnector.cpp:111) 2012-06-08 17:07:06 warning Connection [192.168.10.40:60748-smokey:5671] closed Connection [192.168.10.40:60748-smokey:5671] closed E:\ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-4049) Linux C++ broker crashes when Windows client connects SSL with expired certificate
[ https://issues.apache.org/jira/browse/QPID-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13293695#comment-13293695 ] Andrew Stitcher commented on QPID-4049: --- Aargh, this looks like yet another place where we've fixed a bug only in one set of cut-and-paste code. Alan fixed this bug for TCP in r1343397, but didn't fix the ssl code. Linux C++ broker crashes when Windows client connects SSL with expired certificate -- Key: QPID-4049 URL: https://issues.apache.org/jira/browse/QPID-4049 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.17 Environment: Linux Reporter: Steve Huston Assignee: Andrew Stitcher Priority: Critical Fix For: 0.17 Testing Windows client - Linux broker SSL connections. The SSL cert is expired and this results in the following on Linux: 2012-06-08 17:08:12 error Error reading socket: Encountered end of file [-5938] 2012-06-08 17:08:14 error Connection 192.168.10.4:5671-192.168.10.40:60748 No protocol received closing Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x40a00940 (LWP 15265)] 0x2c0d9164 in qpid::sys::ssl::ProtocolTimeoutTask::fire() () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/ssl.so (gdb) where #0 0x2c0d9164 in qpid::sys::ssl::ProtocolTimeoutTask::fire() () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/ssl.so #1 0x2b51c7bc in qpid::sys::TimerTask::fireTask() () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/libqpidcommon.so.2.0.0 #2 0x2b51c952 in qpid::sys::Timer::fire(boost::intrusive_ptrqpid::sys::TimerTask) () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/libqpidcommon.so.2.0.0 #3 0x2b51d22d in qpid::sys::Timer::run() () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/libqpidcommon.so.2.0.0 #4 0x2b4a9e74 in qpid::sys::(anonymous namespace)::runRunnable(void*) () from /qpidbuilds/trunk/qpid/cpp/rhel5/src/libqpidcommon.so.2.0.0 #5 0x00318f60677d in start_thread () from /lib64/libpthread.so.0 #6 0x00318eed325d in clone () from /lib64/libc.so.6 (gdb) On Windows, this error looks like: 2012-06-08 17:07:06 notice SSL negotiation failed to smokey:5671: The received certificate has expired. 2012-06-08 17:07:06 warning Connect failed: The received certificate has expired . (..\..\..\..\cpp\src\qpid\client\windows\SslConnector.cpp:111) 2012-06-08 17:07:06 warning Connection [192.168.10.40:60748-smokey:5671] closed Connection [192.168.10.40:60748-smokey:5671] closed E:\ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-4059) qpid-printevents refactored to use the lighter-weight management library
Ted Ross created QPID-4059: -- Summary: qpid-printevents refactored to use the lighter-weight management library Key: QPID-4059 URL: https://issues.apache.org/jira/browse/QPID-4059 Project: Qpid Issue Type: Improvement Components: Python Tools Reporter: Ted Ross Assignee: Ted Ross Fix For: 0.17 Refactor qpid-printevents to use the lightweight qpidtoollibs library rather than the full-featured QMF library. This improves performance, reduces overhead, and allows downstream packages to require fewer dependencies. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-4060) qpid-stat - Improve the help text to clarify use of the different display modes
Ted Ross created QPID-4060: -- Summary: qpid-stat - Improve the help text to clarify use of the different display modes Key: QPID-4060 URL: https://issues.apache.org/jira/browse/QPID-4060 Project: Qpid Issue Type: Improvement Components: Python Tools Reporter: Ted Ross Assignee: Ted Ross Priority: Minor Fix For: 0.17 Improve the help text for qpid-stat to more clearly describe the different sets of data that can be displayed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-4062) Java system tests sometimes fail due to JMX port already initialised
Philip Harvey created QPID-4062:
---
Summary: Java system tests sometimes fail due to JMX port already
initialised
Key: QPID-4062
URL: https://issues.apache.org/jira/browse/QPID-4062
Project: Qpid
Issue Type: Bug
Components: Java Tests
Affects Versions: 0.16
Reporter: Philip Harvey
Assignee: Philip Harvey
Priority: Minor
Fix For: 0.17
I'm often seeing errors such as this:
{noformat}
java.rmi.server.ExportException: Port already in use: 18999; nested exception
is:
java.net.BindException: Address already in use
at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:310)
at
sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:218)
at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:393)
at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:129)
at
sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:190)
at sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:92)
at sun.rmi.registry.RegistryImpl.init(RegistryImpl.java:68)
at
java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:222)
at
org.apache.qpid.server.management.JMXManagedObjectRegistry.start(JMXManagedObjectRegistry.java:215)
at
org.apache.qpid.server.registry.ApplicationRegistry.initialise(ApplicationRegistry.java:311)
at
org.apache.qpid.server.registry.ApplicationRegistry.initialise(ApplicationRegistry.java:202)
at org.apache.qpid.server.Broker.startupImpl(Broker.java:123)
at org.apache.qpid.server.Broker.startup(Broker.java:97)
at
org.apache.qpid.test.utils.QpidBrokerTestCase.startBroker(QpidBrokerTestCase.java:394)
at
org.apache.qpid.test.utils.QpidBrokerTestCase.startBroker(QpidBrokerTestCase.java:354)
at
org.apache.qpid.test.utils.QpidBrokerTestCase.startBroker(QpidBrokerTestCase.java:349)
at
org.apache.qpid.test.utils.QpidBrokerTestCase.setUp(QpidBrokerTestCase.java:295)
at
org.apache.qpid.management.jmx.MessageStatisticsTestCase.setUp(MessageStatisticsTestCase.java:61)
at
org.apache.qpid.test.utils.QpidBrokerTestCase.runBare(QpidBrokerTestCase.java:237)
at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:139)
Caused by: java.net.BindException: Address already in use
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:365)
at java.net.ServerSocket.bind(ServerSocket.java:319)
at java.net.ServerSocket.init(ServerSocket.java:185)
at java.net.ServerSocket.init(ServerSocket.java:97)
at
sun.rmi.transport.proxy.RMIDirectSocketFactory.createServerSocket(RMIDirectSocketFactory.java:27)
at
sun.rmi.transport.proxy.RMIMasterSocketFactory.createServerSocket(RMIMasterSocketFactory.java:333)
at
sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:649)
at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:299)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-4062) Java system tests sometimes fail due to JMX port already initialised
[
https://issues.apache.org/jira/browse/QPID-4062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Harvey reassigned QPID-4062:
---
Assignee: Rob Godfrey (was: Philip Harvey)
Rob - I've attached a patch. Please review and commit if you're happy.
Java system tests sometimes fail due to JMX port already initialised
Key: QPID-4062
URL: https://issues.apache.org/jira/browse/QPID-4062
Project: Qpid
Issue Type: Bug
Components: Java Tests
Affects Versions: 0.16
Reporter: Philip Harvey
Assignee: Rob Godfrey
Priority: Minor
Fix For: 0.17
Attachments:
0001-QPID-4062-when-shutting-down-broker-at-end-of-test-w.patch
I'm often seeing errors such as this:
{noformat}
java.rmi.server.ExportException: Port already in use: 18999; nested exception
is:
java.net.BindException: Address already in use
at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:310)
at
sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:218)
at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:393)
at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:129)
at
sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:190)
at sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:92)
at sun.rmi.registry.RegistryImpl.init(RegistryImpl.java:68)
at
java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:222)
at
org.apache.qpid.server.management.JMXManagedObjectRegistry.start(JMXManagedObjectRegistry.java:215)
at
org.apache.qpid.server.registry.ApplicationRegistry.initialise(ApplicationRegistry.java:311)
at
org.apache.qpid.server.registry.ApplicationRegistry.initialise(ApplicationRegistry.java:202)
at org.apache.qpid.server.Broker.startupImpl(Broker.java:123)
at org.apache.qpid.server.Broker.startup(Broker.java:97)
at
org.apache.qpid.test.utils.QpidBrokerTestCase.startBroker(QpidBrokerTestCase.java:394)
at
org.apache.qpid.test.utils.QpidBrokerTestCase.startBroker(QpidBrokerTestCase.java:354)
at
org.apache.qpid.test.utils.QpidBrokerTestCase.startBroker(QpidBrokerTestCase.java:349)
at
org.apache.qpid.test.utils.QpidBrokerTestCase.setUp(QpidBrokerTestCase.java:295)
at
org.apache.qpid.management.jmx.MessageStatisticsTestCase.setUp(MessageStatisticsTestCase.java:61)
at
org.apache.qpid.test.utils.QpidBrokerTestCase.runBare(QpidBrokerTestCase.java:237)
at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:139)
Caused by: java.net.BindException: Address already in use
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:365)
at java.net.ServerSocket.bind(ServerSocket.java:319)
at java.net.ServerSocket.init(ServerSocket.java:185)
at java.net.ServerSocket.init(ServerSocket.java:97)
at
sun.rmi.transport.proxy.RMIDirectSocketFactory.createServerSocket(RMIDirectSocketFactory.java:27)
at
sun.rmi.transport.proxy.RMIMasterSocketFactory.createServerSocket(RMIMasterSocketFactory.java:333)
at
sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:649)
at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:299)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-4062) Java system tests sometimes fail due to JMX port already initialised
[
https://issues.apache.org/jira/browse/QPID-4062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Harvey updated QPID-4062:
Attachment: 0001-QPID-4062-when-shutting-down-broker-at-end-of-test-w.patch
attached patch
Java system tests sometimes fail due to JMX port already initialised
Key: QPID-4062
URL: https://issues.apache.org/jira/browse/QPID-4062
Project: Qpid
Issue Type: Bug
Components: Java Tests
Affects Versions: 0.16
Reporter: Philip Harvey
Assignee: Philip Harvey
Priority: Minor
Fix For: 0.17
Attachments:
0001-QPID-4062-when-shutting-down-broker-at-end-of-test-w.patch
I'm often seeing errors such as this:
{noformat}
java.rmi.server.ExportException: Port already in use: 18999; nested exception
is:
java.net.BindException: Address already in use
at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:310)
at
sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:218)
at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:393)
at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:129)
at
sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:190)
at sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:92)
at sun.rmi.registry.RegistryImpl.init(RegistryImpl.java:68)
at
java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:222)
at
org.apache.qpid.server.management.JMXManagedObjectRegistry.start(JMXManagedObjectRegistry.java:215)
at
org.apache.qpid.server.registry.ApplicationRegistry.initialise(ApplicationRegistry.java:311)
at
org.apache.qpid.server.registry.ApplicationRegistry.initialise(ApplicationRegistry.java:202)
at org.apache.qpid.server.Broker.startupImpl(Broker.java:123)
at org.apache.qpid.server.Broker.startup(Broker.java:97)
at
org.apache.qpid.test.utils.QpidBrokerTestCase.startBroker(QpidBrokerTestCase.java:394)
at
org.apache.qpid.test.utils.QpidBrokerTestCase.startBroker(QpidBrokerTestCase.java:354)
at
org.apache.qpid.test.utils.QpidBrokerTestCase.startBroker(QpidBrokerTestCase.java:349)
at
org.apache.qpid.test.utils.QpidBrokerTestCase.setUp(QpidBrokerTestCase.java:295)
at
org.apache.qpid.management.jmx.MessageStatisticsTestCase.setUp(MessageStatisticsTestCase.java:61)
at
org.apache.qpid.test.utils.QpidBrokerTestCase.runBare(QpidBrokerTestCase.java:237)
at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:139)
Caused by: java.net.BindException: Address already in use
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:365)
at java.net.ServerSocket.bind(ServerSocket.java:319)
at java.net.ServerSocket.init(ServerSocket.java:185)
at java.net.ServerSocket.init(ServerSocket.java:97)
at
sun.rmi.transport.proxy.RMIDirectSocketFactory.createServerSocket(RMIDirectSocketFactory.java:27)
at
sun.rmi.transport.proxy.RMIMasterSocketFactory.createServerSocket(RMIMasterSocketFactory.java:333)
at
sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:649)
at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:299)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-4062) Java system tests sometimes fail due to JMX port already initialised
[
https://issues.apache.org/jira/browse/QPID-4062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Godfrey updated QPID-4062:
--
Status: Ready To Review (was: In Progress)
Java system tests sometimes fail due to JMX port already initialised
Key: QPID-4062
URL: https://issues.apache.org/jira/browse/QPID-4062
Project: Qpid
Issue Type: Bug
Components: Java Tests
Affects Versions: 0.16
Reporter: Philip Harvey
Assignee: Rob Godfrey
Priority: Minor
Fix For: 0.17
Attachments:
0001-QPID-4062-when-shutting-down-broker-at-end-of-test-w.patch
I'm often seeing errors such as this:
{noformat}
java.rmi.server.ExportException: Port already in use: 18999; nested exception
is:
java.net.BindException: Address already in use
at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:310)
at
sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:218)
at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:393)
at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:129)
at
sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:190)
at sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:92)
at sun.rmi.registry.RegistryImpl.init(RegistryImpl.java:68)
at
java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:222)
at
org.apache.qpid.server.management.JMXManagedObjectRegistry.start(JMXManagedObjectRegistry.java:215)
at
org.apache.qpid.server.registry.ApplicationRegistry.initialise(ApplicationRegistry.java:311)
at
org.apache.qpid.server.registry.ApplicationRegistry.initialise(ApplicationRegistry.java:202)
at org.apache.qpid.server.Broker.startupImpl(Broker.java:123)
at org.apache.qpid.server.Broker.startup(Broker.java:97)
at
org.apache.qpid.test.utils.QpidBrokerTestCase.startBroker(QpidBrokerTestCase.java:394)
at
org.apache.qpid.test.utils.QpidBrokerTestCase.startBroker(QpidBrokerTestCase.java:354)
at
org.apache.qpid.test.utils.QpidBrokerTestCase.startBroker(QpidBrokerTestCase.java:349)
at
org.apache.qpid.test.utils.QpidBrokerTestCase.setUp(QpidBrokerTestCase.java:295)
at
org.apache.qpid.management.jmx.MessageStatisticsTestCase.setUp(MessageStatisticsTestCase.java:61)
at
org.apache.qpid.test.utils.QpidBrokerTestCase.runBare(QpidBrokerTestCase.java:237)
at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:139)
Caused by: java.net.BindException: Address already in use
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:365)
at java.net.ServerSocket.bind(ServerSocket.java:319)
at java.net.ServerSocket.init(ServerSocket.java:185)
at java.net.ServerSocket.init(ServerSocket.java:97)
at
sun.rmi.transport.proxy.RMIDirectSocketFactory.createServerSocket(RMIDirectSocketFactory.java:27)
at
sun.rmi.transport.proxy.RMIMasterSocketFactory.createServerSocket(RMIMasterSocketFactory.java:333)
at
sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:649)
at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:299)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-4062) Java system tests sometimes fail due to JMX port already initialised
[
https://issues.apache.org/jira/browse/QPID-4062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Godfrey resolved QPID-4062.
---
Resolution: Fixed
Java system tests sometimes fail due to JMX port already initialised
Key: QPID-4062
URL: https://issues.apache.org/jira/browse/QPID-4062
Project: Qpid
Issue Type: Bug
Components: Java Tests
Affects Versions: 0.16
Reporter: Philip Harvey
Assignee: Rob Godfrey
Priority: Minor
Fix For: 0.17
Attachments:
0001-QPID-4062-when-shutting-down-broker-at-end-of-test-w.patch
I'm often seeing errors such as this:
{noformat}
java.rmi.server.ExportException: Port already in use: 18999; nested exception
is:
java.net.BindException: Address already in use
at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:310)
at
sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:218)
at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:393)
at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:129)
at
sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:190)
at sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:92)
at sun.rmi.registry.RegistryImpl.init(RegistryImpl.java:68)
at
java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:222)
at
org.apache.qpid.server.management.JMXManagedObjectRegistry.start(JMXManagedObjectRegistry.java:215)
at
org.apache.qpid.server.registry.ApplicationRegistry.initialise(ApplicationRegistry.java:311)
at
org.apache.qpid.server.registry.ApplicationRegistry.initialise(ApplicationRegistry.java:202)
at org.apache.qpid.server.Broker.startupImpl(Broker.java:123)
at org.apache.qpid.server.Broker.startup(Broker.java:97)
at
org.apache.qpid.test.utils.QpidBrokerTestCase.startBroker(QpidBrokerTestCase.java:394)
at
org.apache.qpid.test.utils.QpidBrokerTestCase.startBroker(QpidBrokerTestCase.java:354)
at
org.apache.qpid.test.utils.QpidBrokerTestCase.startBroker(QpidBrokerTestCase.java:349)
at
org.apache.qpid.test.utils.QpidBrokerTestCase.setUp(QpidBrokerTestCase.java:295)
at
org.apache.qpid.management.jmx.MessageStatisticsTestCase.setUp(MessageStatisticsTestCase.java:61)
at
org.apache.qpid.test.utils.QpidBrokerTestCase.runBare(QpidBrokerTestCase.java:237)
at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:139)
Caused by: java.net.BindException: Address already in use
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:365)
at java.net.ServerSocket.bind(ServerSocket.java:319)
at java.net.ServerSocket.init(ServerSocket.java:185)
at java.net.ServerSocket.init(ServerSocket.java:97)
at
sun.rmi.transport.proxy.RMIDirectSocketFactory.createServerSocket(RMIDirectSocketFactory.java:27)
at
sun.rmi.transport.proxy.RMIMasterSocketFactory.createServerSocket(RMIMasterSocketFactory.java:333)
at
sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:649)
at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:299)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-4063) Allow user to assign the name of the source queue when creating an exchange or dynamic route.
Ken Giusti created QPID-4063: Summary: Allow user to assign the name of the source queue when creating an exchange or dynamic route. Key: QPID-4063 URL: https://issues.apache.org/jira/browse/QPID-4063 Project: Qpid Issue Type: New Feature Components: C++ Broker Affects Versions: 0.17 Reporter: Ken Giusti Assignee: Ken Giusti Priority: Trivial When a federation route is created - either an exchange or a dynamic route - a dedicated queue is created on the source broker. This queue is used to hold messages that are forwarded to the remote broker. This queue is created by federation, and assigned a (somewhat) randomized name. It should be possible - as an option - to allow the user to specify the name for that queue. This would be useful for a couple of reasons... 1) Monitoring the state of the queue would be easier if it had a meaningful name. 2) Power Users could specify an existing queue, which could then be used as a target for messages that should be forwarded over the federation, 3) Allow several routes share the same queue (if msg ordering need not be preserved) to fan out work across a federation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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
