[jira] [Commented] (QPID-7311) [Java Broker] SiteSpecificTrustStore does not provide helpful error messages when protocol is missing
[
https://issues.apache.org/jira/browse/QPID-7311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15800612#comment-15800612
]
ASF subversion and git services commented on QPID-7311:
---
Commit 1777426 from [~k-wall] in branch 'java/trunk'
[ https://svn.apache.org/r1777426 ]
QPID-7311: [Java Broker] [SiteSpecificTrustStore] Validate URL on creation
> [Java Broker] SiteSpecificTrustStore does not provide helpful error messages
> when protocol is missing
> -
>
> Key: QPID-7311
> URL: https://issues.apache.org/jira/browse/QPID-7311
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Lorenz Quack
>Priority: Minor
> Fix For: qpid-java-7.0
>
>
> Currently, when creating a {{SiteSpecificTrustStore}} and the protocol is not
> specified in the URL the object will be created but put into ERRORED state.
> No indication as to what is wrong is given. Furthermore the URL is not
> editable rendering the newly created object utterly useless.
> On the Broker side a MalformedURLException is logged at INFO level giving the
> helpful information "no protocol".
> On the broker side we do not need a full stack trace.
> On the client side a error message would be preferable to creating an ERRORED
> object.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-242) Creation of consumer, producer or session hangs when connection is in a process of re-establishing by failover
[
https://issues.apache.org/jira/browse/QPIDJMS-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15799703#comment-15799703
]
ASF subversion and git services commented on QPIDJMS-242:
-
Commit e7692d9d06d24e9660bcf4f90d8175fdd136ad66 in qpid-jms's branch
refs/heads/master from [~tabish121]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=e7692d9 ]
QPIDJMS-242 Creating a JMS resource can hang during failover reconnect
During failover the recovery attempts to recreate JMS resources that
were previously opened but recovers some resources that are still in the
process of being created lead to a double create effect on recover that
leads to the initial create call to hang. Need to track state of the
JMS resources so that the failover recover can skip any tracked
instances that are either not yet opened or have already been closed.
> Creation of consumer, producer or session hangs when connection is in a
> process of re-establishing by failover
> --
>
> Key: QPIDJMS-242
> URL: https://issues.apache.org/jira/browse/QPIDJMS-242
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.11.1, 0.20.0
> Environment: Qpid Broker 7.0.0-SNAPSHOT
>Reporter: Alex Rudyy
>Assignee: Timothy Bish
> Attachments: ConsumerCreationHangsOnFailover.java,
> broker-log.snippet.txt, thread-dump.txt
>
>
> The creation of consumer (Session#createConsumer) hangs if invoked when
> underlying connection is being re-established by failover process. Even when
> failover successfully restores the connectivity, the invoked method
> createConsumer does not return. I see the following in the stack trace:
> {noformat}
> "main" prio=10 tid=0x7f2524009800 nid=0x3d5d waiting on condition
> [0x7f252b0e4000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0007ad360b30> (a
> java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
> at
> org.apache.qpid.jms.provider.ProviderFuture.sync(ProviderFuture.java:97)
> at
> org.apache.qpid.jms.JmsConnection.createResource(JmsConnection.java:601)
> at
> org.apache.qpid.jms.JmsConnection.createResource(JmsConnection.java:590)
> at
> org.apache.qpid.jms.JmsMessageConsumer.(JmsMessageConsumer.java:114)
> at
> org.apache.qpid.jms.JmsMessageConsumer.(JmsMessageConsumer.java:72)
> at org.apache.qpid.jms.JmsSession.createConsumer(JmsSession.java:387)
> at org.apache.qpid.jms.JmsSession.createConsumer(JmsSession.java:375)
> at org.apache.qpid.jms.JmsSession.createConsumer(JmsSession.java:367)
> at org.apache.qpid.jms.example.Test2.main(Test2.java:65)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> {noformat}
> The consumer is created successfully on broker side. Broker even sends the
> messages through.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDJMS-242) Creation of consumer, producer or session hangs when connection is in a process of re-establishing by failover
[
https://issues.apache.org/jira/browse/QPIDJMS-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish updated QPIDJMS-242:
-
Summary: Creation of consumer, producer or session hangs when connection is
in a process of re-establishing by failover (was: Creation of consumer hangs
when connection is in a process of re-establishing by failover)
> Creation of consumer, producer or session hangs when connection is in a
> process of re-establishing by failover
> --
>
> Key: QPIDJMS-242
> URL: https://issues.apache.org/jira/browse/QPIDJMS-242
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.11.1, 0.20.0
> Environment: Qpid Broker 7.0.0-SNAPSHOT
>Reporter: Alex Rudyy
>Assignee: Timothy Bish
> Attachments: ConsumerCreationHangsOnFailover.java,
> broker-log.snippet.txt, thread-dump.txt
>
>
> The creation of consumer (Session#createConsumer) hangs if invoked when
> underlying connection is being re-established by failover process. Even when
> failover successfully restores the connectivity, the invoked method
> createConsumer does not return. I see the following in the stack trace:
> {noformat}
> "main" prio=10 tid=0x7f2524009800 nid=0x3d5d waiting on condition
> [0x7f252b0e4000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0007ad360b30> (a
> java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
> at
> org.apache.qpid.jms.provider.ProviderFuture.sync(ProviderFuture.java:97)
> at
> org.apache.qpid.jms.JmsConnection.createResource(JmsConnection.java:601)
> at
> org.apache.qpid.jms.JmsConnection.createResource(JmsConnection.java:590)
> at
> org.apache.qpid.jms.JmsMessageConsumer.(JmsMessageConsumer.java:114)
> at
> org.apache.qpid.jms.JmsMessageConsumer.(JmsMessageConsumer.java:72)
> at org.apache.qpid.jms.JmsSession.createConsumer(JmsSession.java:387)
> at org.apache.qpid.jms.JmsSession.createConsumer(JmsSession.java:375)
> at org.apache.qpid.jms.JmsSession.createConsumer(JmsSession.java:367)
> at org.apache.qpid.jms.example.Test2.main(Test2.java:65)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> {noformat}
> The consumer is created successfully on broker side. Broker even sends the
> messages through.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-603) address resource leak
[ https://issues.apache.org/jira/browse/DISPATCH-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohan Mars updated DISPATCH-603: Attachment: test-app-address-leak.tar > address resource leak > - > > Key: DISPATCH-603 > URL: https://issues.apache.org/jira/browse/DISPATCH-603 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.7.0 > Environment: Centos 7, JDK 8 >Reporter: Rohan Mars >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > Attachments: test-app-address-leak.tar > > > A multi-node router mesh will leak addresses, causing a memory increase. > The test case attached can reproduce the problem. > The addresses that are leaked are temporary reply addresses. > See the README for instructions on how to run. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-603) address resource leak
[ https://issues.apache.org/jira/browse/DISPATCH-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohan Mars updated DISPATCH-603: Attachment: (was: test-app-address-leak.tar) > address resource leak > - > > Key: DISPATCH-603 > URL: https://issues.apache.org/jira/browse/DISPATCH-603 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.7.0 > Environment: Centos 7, JDK 8 >Reporter: Rohan Mars >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > > A multi-node router mesh will leak addresses, causing a memory increase. > The test case attached can reproduce the problem. > The addresses that are leaked are temporary reply addresses. > See the README for instructions on how to run. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-603) address resource leak
[ https://issues.apache.org/jira/browse/DISPATCH-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohan Mars updated DISPATCH-603: Attachment: test-app-address-leak.tar > address resource leak > - > > Key: DISPATCH-603 > URL: https://issues.apache.org/jira/browse/DISPATCH-603 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.7.0 > Environment: Centos 7, JDK 8 >Reporter: Rohan Mars >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > Attachments: test-app-address-leak.tar > > > A multi-node router mesh will leak addresses, causing a memory increase. > The test case attached can reproduce the problem. > The addresses that are leaked are temporary reply addresses. > See the README for instructions on how to run. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-603) address resource leak
[ https://issues.apache.org/jira/browse/DISPATCH-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohan Mars updated DISPATCH-603: Attachment: (was: test-app-address-leak.tar) > address resource leak > - > > Key: DISPATCH-603 > URL: https://issues.apache.org/jira/browse/DISPATCH-603 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.7.0 > Environment: Centos 7, JDK 8 >Reporter: Rohan Mars >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > Attachments: test-app-address-leak.tar > > > A multi-node router mesh will leak addresses, causing a memory increase. > The test case attached can reproduce the problem. > The addresses that are leaked are temporary reply addresses. > See the README for instructions on how to run. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-209) Three+ router test is needed in the system test suite.
[ https://issues.apache.org/jira/browse/DISPATCH-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15799592#comment-15799592 ] ASF GitHub Bot commented on DISPATCH-209: - Github user ted-ross commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/134#discussion_r94681419 --- Diff: tests/system_tests_three_routers.py --- @@ -220,6 +225,70 @@ def run(self): Container(self).run() +class DynamicRequestResponseTest(MessagingHandler): +def __init__(self, address1, address2): +super(DynamicRequestResponseTest, self).__init__(prefetch=0) +self.address1 = address1 +self.address2 = address2 +self.dest = "closest.dynamicRequestResponse" +self.error = None +self.sender = None +self.server_receiver = None +self.client_receiver = None +self.n_expected = 10 +self.n_sent = 0 +self.n_received = 0 +self.n_accepted = 0 + +def timeout(self): +self.error = "Timeout Expired %d messages received." % self.n_received +self.client_connection.close() +self.server_connection.close() + +def on_released(self, event): +self.n_sent -= 1 +time.sleep(0.1) + +def on_start(self, event): +self.timer = event.reactor.schedule(5, Timeout(self)) +self.client_connection = event.container.connect(self.address1) +self.server_connection = event.container.connect(self.address2) +self.server_receiver = event.container.create_receiver(self.server_connection, self.dest) +self.client_receiver = event.container.create_receiver(self.client_connection, None, dynamic=True) +self.server_receiver.flow(self.n_expected) +self.client_receiver.flow(self.n_expected) +self.sender = event.container.create_sender(self.client_connection, None) + +def on_sendable(self, event): +if self.n_sent < self.n_expected: +# We send to server, and ask it to reply to client. +request = Message(body=self.n_sent, address=self.dest, reply_to=self.client_receiver.remote_source.address) +event.sender.send(request) +self.n_sent += 1 + +def on_accepted(self, event): +self.n_accepted += 1 + +def on_message(self, event): + +# Receiver gets a message and replies to client. +if event.receiver == self.server_receiver : +self.sender.send ( Message(address=event.message.reply_to, body="Reply hazy, try again later.") ) --- End diff -- The server is sending its responses on the client's sender! > Three+ router test is needed in the system test suite. > -- > > Key: DISPATCH-209 > URL: https://issues.apache.org/jira/browse/DISPATCH-209 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Tests >Reporter: Ted Ross >Assignee: michael goulish > > There have arisen some issues that would have been caught had there been a > three-router test in the regression suite. This test should be added. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-209) Three+ router test is needed in the system test suite.
[ https://issues.apache.org/jira/browse/DISPATCH-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15799589#comment-15799589 ] ASF GitHub Bot commented on DISPATCH-209: - Github user ted-ross commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/134#discussion_r94648607 --- Diff: tests/system_tests_three_routers.py --- @@ -220,6 +225,70 @@ def run(self): Container(self).run() +class DynamicRequestResponseTest(MessagingHandler): +def __init__(self, address1, address2): +super(DynamicRequestResponseTest, self).__init__(prefetch=0) +self.address1 = address1 +self.address2 = address2 +self.dest = "closest.dynamicRequestResponse" +self.error = None +self.sender = None +self.server_receiver = None +self.client_receiver = None +self.n_expected = 10 +self.n_sent = 0 +self.n_received = 0 +self.n_accepted = 0 + +def timeout(self): +self.error = "Timeout Expired %d messages received." % self.n_received +self.client_connection.close() +self.server_connection.close() + +def on_released(self, event): +self.n_sent -= 1 +time.sleep(0.1) + +def on_start(self, event): +self.timer = event.reactor.schedule(5, Timeout(self)) +self.client_connection = event.container.connect(self.address1) +self.server_connection = event.container.connect(self.address2) +self.server_receiver = event.container.create_receiver(self.server_connection, self.dest) +self.client_receiver = event.container.create_receiver(self.client_connection, None, dynamic=True) +self.server_receiver.flow(self.n_expected) +self.client_receiver.flow(self.n_expected) +self.sender = event.container.create_sender(self.client_connection, None) + +def on_sendable(self, event): +if self.n_sent < self.n_expected: +# We send to server, and ask it to reply to client. +request = Message(body=self.n_sent, address=self.dest, reply_to=self.client_receiver.remote_source.address) --- End diff -- There's a race condition here. What if you get credit on the sender before the dynamic receiver is fully attached? > Three+ router test is needed in the system test suite. > -- > > Key: DISPATCH-209 > URL: https://issues.apache.org/jira/browse/DISPATCH-209 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Tests >Reporter: Ted Ross >Assignee: michael goulish > > There have arisen some issues that would have been caught had there been a > three-router test in the regression suite. This test should be added. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-209) Three+ router test is needed in the system test suite.
[ https://issues.apache.org/jira/browse/DISPATCH-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15799591#comment-15799591 ] ASF GitHub Bot commented on DISPATCH-209: - Github user ted-ross commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/134#discussion_r94648343 --- Diff: tests/system_tests_three_routers.py --- @@ -220,6 +225,70 @@ def run(self): Container(self).run() +class DynamicRequestResponseTest(MessagingHandler): +def __init__(self, address1, address2): +super(DynamicRequestResponseTest, self).__init__(prefetch=0) +self.address1 = address1 +self.address2 = address2 +self.dest = "closest.dynamicRequestResponse" +self.error = None +self.sender = None +self.server_receiver = None +self.client_receiver = None +self.n_expected = 10 +self.n_sent = 0 +self.n_received = 0 +self.n_accepted = 0 + +def timeout(self): +self.error = "Timeout Expired %d messages received." % self.n_received --- End diff -- You should include all of the counters here. If the test times out, you'll want as much information as you can get. > Three+ router test is needed in the system test suite. > -- > > Key: DISPATCH-209 > URL: https://issues.apache.org/jira/browse/DISPATCH-209 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Tests >Reporter: Ted Ross >Assignee: michael goulish > > There have arisen some issues that would have been caught had there been a > three-router test in the regression suite. This test should be added. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-209) Three+ router test is needed in the system test suite.
[ https://issues.apache.org/jira/browse/DISPATCH-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15799590#comment-15799590 ] ASF GitHub Bot commented on DISPATCH-209: - Github user ted-ross commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/134#discussion_r94648211 --- Diff: tests/system_tests_three_routers.py --- @@ -90,6 +90,11 @@ def test_02_anonymous_sender(self): test.run() self.assertEqual(None, test.error) +def test_03_dynamic_request_response(self): --- End diff -- You can get multiple tests in one here just by replicating this test with different router addresses. For example, you could have three tests: 0->0, 0->1, 0->2. > Three+ router test is needed in the system test suite. > -- > > Key: DISPATCH-209 > URL: https://issues.apache.org/jira/browse/DISPATCH-209 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Tests >Reporter: Ted Ross >Assignee: michael goulish > > There have arisen some issues that would have been caught had there been a > three-router test in the regression suite. This test should be added. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #134: DISPATCH-209 : dynamic request response tes...
Github user ted-ross commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/134#discussion_r94648607 --- Diff: tests/system_tests_three_routers.py --- @@ -220,6 +225,70 @@ def run(self): Container(self).run() +class DynamicRequestResponseTest(MessagingHandler): +def __init__(self, address1, address2): +super(DynamicRequestResponseTest, self).__init__(prefetch=0) +self.address1 = address1 +self.address2 = address2 +self.dest = "closest.dynamicRequestResponse" +self.error = None +self.sender = None +self.server_receiver = None +self.client_receiver = None +self.n_expected = 10 +self.n_sent = 0 +self.n_received = 0 +self.n_accepted = 0 + +def timeout(self): +self.error = "Timeout Expired %d messages received." % self.n_received +self.client_connection.close() +self.server_connection.close() + +def on_released(self, event): +self.n_sent -= 1 +time.sleep(0.1) + +def on_start(self, event): +self.timer = event.reactor.schedule(5, Timeout(self)) +self.client_connection = event.container.connect(self.address1) +self.server_connection = event.container.connect(self.address2) +self.server_receiver = event.container.create_receiver(self.server_connection, self.dest) +self.client_receiver = event.container.create_receiver(self.client_connection, None, dynamic=True) +self.server_receiver.flow(self.n_expected) +self.client_receiver.flow(self.n_expected) +self.sender = event.container.create_sender(self.client_connection, None) + +def on_sendable(self, event): +if self.n_sent < self.n_expected: +# We send to server, and ask it to reply to client. +request = Message(body=self.n_sent, address=self.dest, reply_to=self.client_receiver.remote_source.address) --- End diff -- There's a race condition here. What if you get credit on the sender before the dynamic receiver is fully attached? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #134: DISPATCH-209 : dynamic request response tes...
Github user ted-ross commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/134#discussion_r94648343 --- Diff: tests/system_tests_three_routers.py --- @@ -220,6 +225,70 @@ def run(self): Container(self).run() +class DynamicRequestResponseTest(MessagingHandler): +def __init__(self, address1, address2): +super(DynamicRequestResponseTest, self).__init__(prefetch=0) +self.address1 = address1 +self.address2 = address2 +self.dest = "closest.dynamicRequestResponse" +self.error = None +self.sender = None +self.server_receiver = None +self.client_receiver = None +self.n_expected = 10 +self.n_sent = 0 +self.n_received = 0 +self.n_accepted = 0 + +def timeout(self): +self.error = "Timeout Expired %d messages received." % self.n_received --- End diff -- You should include all of the counters here. If the test times out, you'll want as much information as you can get. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #134: DISPATCH-209 : dynamic request response tes...
Github user ted-ross commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/134#discussion_r94648211 --- Diff: tests/system_tests_three_routers.py --- @@ -90,6 +90,11 @@ def test_02_anonymous_sender(self): test.run() self.assertEqual(None, test.error) +def test_03_dynamic_request_response(self): --- End diff -- You can get multiple tests in one here just by replicating this test with different router addresses. For example, you could have three tests: 0->0, 0->1, 0->2. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #134: DISPATCH-209 : dynamic request response tes...
Github user ted-ross commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/134#discussion_r94681419 --- Diff: tests/system_tests_three_routers.py --- @@ -220,6 +225,70 @@ def run(self): Container(self).run() +class DynamicRequestResponseTest(MessagingHandler): +def __init__(self, address1, address2): +super(DynamicRequestResponseTest, self).__init__(prefetch=0) +self.address1 = address1 +self.address2 = address2 +self.dest = "closest.dynamicRequestResponse" +self.error = None +self.sender = None +self.server_receiver = None +self.client_receiver = None +self.n_expected = 10 +self.n_sent = 0 +self.n_received = 0 +self.n_accepted = 0 + +def timeout(self): +self.error = "Timeout Expired %d messages received." % self.n_received +self.client_connection.close() +self.server_connection.close() + +def on_released(self, event): +self.n_sent -= 1 +time.sleep(0.1) + +def on_start(self, event): +self.timer = event.reactor.schedule(5, Timeout(self)) +self.client_connection = event.container.connect(self.address1) +self.server_connection = event.container.connect(self.address2) +self.server_receiver = event.container.create_receiver(self.server_connection, self.dest) +self.client_receiver = event.container.create_receiver(self.client_connection, None, dynamic=True) +self.server_receiver.flow(self.n_expected) +self.client_receiver.flow(self.n_expected) +self.sender = event.container.create_sender(self.client_connection, None) + +def on_sendable(self, event): +if self.n_sent < self.n_expected: +# We send to server, and ask it to reply to client. +request = Message(body=self.n_sent, address=self.dest, reply_to=self.client_receiver.remote_source.address) +event.sender.send(request) +self.n_sent += 1 + +def on_accepted(self, event): +self.n_accepted += 1 + +def on_message(self, event): + +# Receiver gets a message and replies to client. +if event.receiver == self.server_receiver : +self.sender.send ( Message(address=event.message.reply_to, body="Reply hazy, try again later.") ) --- End diff -- The server is sending its responses on the client's sender! --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-596) error is lost from rejected state in relayed disposition
[
https://issues.apache.org/jira/browse/DISPATCH-596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15799564#comment-15799564
]
ASF subversion and git services commented on DISPATCH-596:
--
Commit 29f4195fa41d133d384ebfe812e67b0c171321b3 in qpid-dispatch's branch
refs/heads/master from [~ganeshmurthy]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=29f4195 ]
DISPATCH-596 - Additional fix for qdr_error_t objects being leaked
> error is lost from rejected state in relayed disposition
>
>
> Key: DISPATCH-596
> URL: https://issues.apache.org/jira/browse/DISPATCH-596
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 0.7.0
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
> Attachments: reject.py
>
>
> {noformat}
> [0x55d7cde663a0]: -> SASL
> [0x55d7cde663a0]: <- SASL
> [0x55d7cde663a0]:0 <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]]
> [0x55d7cde663a0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS,
> initial-response=b"anonymous@localhost.localdomain"]
> [0x55d7cde663a0]:0 <- @sasl-outcome(68) [code=0]
> [0x55d7cde663a0]: -> AMQP
> [0x55d7cde663a0]:0 -> @open(16)
> [container-id="4308de22-4121-49bc-bac4-8ee05bf1504e", hostname="localhost",
> channel-max=32767]
> [0x55d7cde663a0]:0 -> @begin(17) [next-outgoing-id=0,
> incoming-window=2147483647, outgoing-window=2147483647]
> [0x55d7cde663a0]:0 -> @attach(18)
> [name="4308de22-4121-49bc-bac4-8ee05bf1504e-examples", handle=0, role=true,
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="examples",
> durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0,
> timeout=0, dynamic=false], initial-delivery-count=0]
> [0x55d7cde663a0]:0 -> @attach(18)
> [name="4308de22-4121-49bc-bac4-8ee05bf1504e-examples", handle=1, role=false,
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0,
> timeout=0, dynamic=false], target=@target(41) [address="examples", durable=0,
> timeout=0, dynamic=false], initial-delivery-count=0]
> [0x55d7cde663a0]:0 -> @flow(19) [incoming-window=2147483647,
> next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0,
> link-credit=10, drain=false]
> [0x55d7cde663a0]: <- AMQP
> [0x55d7cde663a0]:0 <- @open(16) [container-id="Router.A",
> max-frame-size=16384, channel-max=32767, idle-time-out=8000,
> offered-capabilities=:"ANONYMOUS-RELAY",
> properties={:product="qpid-dispatch-router", :version="0.8.0"}]
> [0x55d7cde663a0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=0,
> incoming-window=100, outgoing-window=2147483647]
> [0x55d7cde663a0]:0 <- @attach(18)
> [name="4308de22-4121-49bc-bac4-8ee05bf1504e-examples", handle=0, role=false,
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="examples",
> durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0,
> timeout=0, dynamic=false], initial-delivery-count=0]
> [0x55d7cde663a0]:0 <- @attach(18)
> [name="4308de22-4121-49bc-bac4-8ee05bf1504e-examples", handle=1, role=true,
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0,
> timeout=0, dynamic=false], target=@target(41) [address="examples", durable=0,
> timeout=0, dynamic=false], initial-delivery-count=0]
> [0x55d7cde663a0]:0 <- @flow(19) [next-incoming-id=0, incoming-window=100,
> next-outgoing-id=0, outgoing-window=2147483647, handle=1, delivery-count=0,
> link-credit=250, drain=false]
> [0x55d7cde663a0]:0 -> @transfer(20) [handle=1, delivery-id=0,
> delivery-tag=b"1", message-format=0, settled=false, more=false] (78)
> "\x00Sp\xd0\x00\x00\x00\x0b\x00\x00\x00\x05BP\x04@BR\x00\x00Ss\xd0\x00\x00\x00"\x00\x00\x00\x0d\x83\x00\x00\x00\x00\x00\x00\x00\x00\x83\x00\x00\x00\x00\x00\x00\x00\x00@R\x00@\x00Sw\xa1\x0cHello
> World!"
> [0x55d7cde663a0]:0 <- @transfer(20) [handle=0, delivery-id=0,
> delivery-tag=b"\x07\x00\x00\x00\x00\x00\x00\x00", message-format=0,
> settled=false, more=false] (78)
> "\x00Sp\xd0\x00\x00\x00\x0b\x00\x00\x00\x05BP\x04@BR\x00\x00Ss\xd0\x00\x00\x00"\x00\x00\x00\x0d\x83\x00\x00\x00\x00\x00\x00\x00\x00\x83\x00\x00\x00\x00\x00\x00\x00\x00@R\x00@\x00Sw\xa1\x0cHello
> World!"
> Rejecting delivery: Hello World!
> [0x55d7cde663a0]:0 -> @disposition(21) [role=true, first=0, last=0,
> settled=true, state=@rejected(37) [error=@error(29)
> [condition=:"amqp:internal-error", description="you were out of luck this
> time!"]]]
> receiver sends disposition with rejected containing and error...
> [0x55d7cde663a0]:0 <- @flow(19) [next-incoming-id=1, incoming-window=100,
> next-outgoing-id=1, outgoing-window=2147483647, handle=1, delivery-count=1,
> link-credit=250, drain=false]
> [0x55d7cde663a0]:0 <- @disposition(21) [role=true, first=0, last=0,
> se
[jira] [Assigned] (DISPATCH-603) address resource leak
[ https://issues.apache.org/jira/browse/DISPATCH-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy reassigned DISPATCH-603: -- Assignee: Ganesh Murthy > address resource leak > - > > Key: DISPATCH-603 > URL: https://issues.apache.org/jira/browse/DISPATCH-603 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.7.0 > Environment: Centos 7, JDK 8 >Reporter: Rohan Mars >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > Attachments: test-app-address-leak.tar > > > A multi-node router mesh will leak addresses, causing a memory increase. > The test case attached can reproduce the problem. > The addresses that are leaked are temporary reply addresses. > See the README for instructions on how to run. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1380) Cyrus SASL accesses strings that have been freed
[ https://issues.apache.org/jira/browse/PROTON-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-1380. - Resolution: Fixed Fix Version/s: 0.17.0 > Cyrus SASL accesses strings that have been freed > > > Key: PROTON-1380 > URL: https://issues.apache.org/jira/browse/PROTON-1380 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.16.0 >Reporter: Ted Ross >Assignee: Andrew Stitcher >Priority: Blocker > Fix For: 0.17.0 > > > If a proton-c user calls pn_sasl_config_name or pn_sasl_config_path, the > literal defaults are replaced with allocated duplicates of the supplied name > or path. When the user's transport is eventually freed, these allocated > strings are also freed (in pn_sasl_free). > Cyrus SASL retains a global pointer to this freed string and references it > the next time a transport is created. Since the SASL initialization only > occurs once per process, the strings are not refreshed and the SASL library > continues to refer to the freed string. > There does not appear to be a workaround available for this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1380) Cyrus SASL accesses strings that have been freed
[ https://issues.apache.org/jira/browse/PROTON-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15799155#comment-15799155 ] ASF subversion and git services commented on PROTON-1380: - Commit 440131e0efabc14df338125b6df0b0e88527614e in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=440131e ] PROTON-1380: Avoid freeing strings we pass to cyrus before cyrus finishes using them. > Cyrus SASL accesses strings that have been freed > > > Key: PROTON-1380 > URL: https://issues.apache.org/jira/browse/PROTON-1380 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.16.0 >Reporter: Ted Ross >Assignee: Andrew Stitcher >Priority: Blocker > > If a proton-c user calls pn_sasl_config_name or pn_sasl_config_path, the > literal defaults are replaced with allocated duplicates of the supplied name > or path. When the user's transport is eventually freed, these allocated > strings are also freed (in pn_sasl_free). > Cyrus SASL retains a global pointer to this freed string and references it > the next time a transport is created. Since the SASL initialization only > occurs once per process, the strings are not refreshed and the SASL library > continues to refer to the freed string. > There does not appear to be a workaround available for this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-603) address resource leak
[ https://issues.apache.org/jira/browse/DISPATCH-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohan Mars updated DISPATCH-603: Description: A multi-node router mesh will leak addresses, causing a memory increase. The test case attached can reproduce the problem. The addresses that are leaked are temporary reply address. See the README for instructions on how to run. was: A multi-node router mesh will leak addresses, causing a memory increase. The test case attached can reproduce the problem. The addresses that are leaked are temporary reply queues. See the README for instructions on how to run. > address resource leak > - > > Key: DISPATCH-603 > URL: https://issues.apache.org/jira/browse/DISPATCH-603 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.7.0 > Environment: Centos 7, JDK 8 >Reporter: Rohan Mars > Fix For: 0.8.0 > > Attachments: test-app-address-leak.tar > > > A multi-node router mesh will leak addresses, causing a memory increase. > The test case attached can reproduce the problem. > The addresses that are leaked are temporary reply address. > See the README for instructions on how to run. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-603) address resource leak
[ https://issues.apache.org/jira/browse/DISPATCH-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohan Mars updated DISPATCH-603: Description: A multi-node router mesh will leak addresses, causing a memory increase. The test case attached can reproduce the problem. The addresses that are leaked are temporary reply addresses. See the README for instructions on how to run. was: A multi-node router mesh will leak addresses, causing a memory increase. The test case attached can reproduce the problem. The addresses that are leaked are temporary reply address. See the README for instructions on how to run. > address resource leak > - > > Key: DISPATCH-603 > URL: https://issues.apache.org/jira/browse/DISPATCH-603 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.7.0 > Environment: Centos 7, JDK 8 >Reporter: Rohan Mars > Fix For: 0.8.0 > > Attachments: test-app-address-leak.tar > > > A multi-node router mesh will leak addresses, causing a memory increase. > The test case attached can reproduce the problem. > The addresses that are leaked are temporary reply addresses. > See the README for instructions on how to run. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-603) address resource leak
[ https://issues.apache.org/jira/browse/DISPATCH-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohan Mars updated DISPATCH-603: Description: A multi-node router mesh will leak addresses, causing a memory increase. The test case attached can reproduce the problem. The addresses that are leaked are temporary reply queues. See the README for instructions on how to run. was: A multi-node router mesh will leak address, causing a memory increase using a send/recv setup that constantly creates new addresses. The test case attached can reproduce the problem. The addresses that are leaked are temporary reply queues. See the README for instructions on how to run. > address resource leak > - > > Key: DISPATCH-603 > URL: https://issues.apache.org/jira/browse/DISPATCH-603 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.7.0 > Environment: Centos 7, JDK 8 >Reporter: Rohan Mars > Fix For: 0.8.0 > > Attachments: test-app-address-leak.tar > > > A multi-node router mesh will leak addresses, causing a memory increase. > The test case attached can reproduce the problem. > The addresses that are leaked are temporary reply queues. > See the README for instructions on how to run. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-603) address resource leak
[ https://issues.apache.org/jira/browse/DISPATCH-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohan Mars updated DISPATCH-603: Attachment: test-app-address-leak.tar > address resource leak > - > > Key: DISPATCH-603 > URL: https://issues.apache.org/jira/browse/DISPATCH-603 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.7.0 > Environment: Centos 7, JDK 8 >Reporter: Rohan Mars > Fix For: 0.8.0 > > Attachments: test-app-address-leak.tar > > > A multi-node router mesh will leak address, causing a memory increase using a > send/recv setup that constantly creates new addresses. > The test case attached can reproduce the problem. > The addresses that are leaked are temporary reply queues. > See the README for instructions on how to run. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-603) address resource leak
Rohan Mars created DISPATCH-603: --- Summary: address resource leak Key: DISPATCH-603 URL: https://issues.apache.org/jira/browse/DISPATCH-603 Project: Qpid Dispatch Issue Type: Bug Components: Routing Engine Affects Versions: 0.7.0 Environment: Centos 7, JDK 8 Reporter: Rohan Mars Fix For: 0.8.0 Attachments: test-app-address-leak.tar A multi-node router mesh will leak address, causing a memory increase using a send/recv setup that constantly creates new addresses. The test case attached can reproduce the problem. The addresses that are leaked are temporary reply queues. See the README for instructions on how to run. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1380) Cyrus SASL accesses strings that have been freed
[ https://issues.apache.org/jira/browse/PROTON-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15798977#comment-15798977 ] Andrew Stitcher commented on PROTON-1380: - Yep, looks like we need to copy these strings again before giving them to cyrus. Possibly keeping a static buffer to hold them, might avoid possible warnings from valgrind (but sizing the buffer may be tricky). > Cyrus SASL accesses strings that have been freed > > > Key: PROTON-1380 > URL: https://issues.apache.org/jira/browse/PROTON-1380 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.16.0 >Reporter: Ted Ross >Assignee: Andrew Stitcher >Priority: Blocker > > If a proton-c user calls pn_sasl_config_name or pn_sasl_config_path, the > literal defaults are replaced with allocated duplicates of the supplied name > or path. When the user's transport is eventually freed, these allocated > strings are also freed (in pn_sasl_free). > Cyrus SASL retains a global pointer to this freed string and references it > the next time a transport is created. Since the SASL initialization only > occurs once per process, the strings are not refreshed and the SASL library > continues to refer to the freed string. > There does not appear to be a workaround available for this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-601) Valgrind errors in dispatch tests
[
https://issues.apache.org/jira/browse/DISPATCH-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross resolved DISPATCH-601.
---
Resolution: Fixed
> Valgrind errors in dispatch tests
> -
>
> Key: DISPATCH-601
> URL: https://issues.apache.org/jira/browse/DISPATCH-601
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Routing Engine
>Reporter: Alan Conway
>Assignee: Ted Ross
> Fix For: 0.8.0
>
> Attachments: dispatch-valgrind-err.txt
>
>
> There are several valgrind erros appearing in the dispatch tests. Full test
> output will be attached but the errors are all similar to this:
> {code}
> ==18019== Invalid read of size 1
> ==18019==at 0x4C30CAB: strcpy (vg_replace_strmem.c:506)
> ==18019==by 0x69DDFFD: strcpy (string3.h:110)
> ==18019==by 0x69DDFFD: _sasl_strdup (common.c:183)
> ==18019==by 0x69E55A4: sasl_server_new (server.c:1076)
> ==18019==by 0x50DD88F: pni_init_server (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50DC1F8: pni_sasl_start_server_if_needed.part.2 (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50DC7BE: pn_output_write_sasl (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50DEBBA: process_output_ssl (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50DA35C: pn_transport_pending (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x4E6EDA9: connector_process (driver.c:770)
> ==18019==by 0x4E6EC3A: qdpn_connector_process (driver.c:730)
> ==18019==by 0x4E907B3: process_connector (server.c:679)
> ==18019==by 0x4E91321: thread_run (server.c:957)
> ==18019== Address 0x11be7331 is 1 bytes inside a block of size 17 free'd
> ==18019==at 0x4C2ED4A: free (vg_replace_malloc.c:530)
> ==18019==by 0x50DCA0E: pn_sasl_free (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50D58BF: pn_transport_finalize (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50C7BF8: pn_class_decref (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50D406F: pn_event_finalize_cast (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50C7BF8: pn_class_decref (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50D437C: pn_collector_pop (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50D43AE: pn_collector_next (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50D440F: pn_collector_release (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50D4438: pn_collector_free (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x4E8E6C2: free_qd_connection (server.c:100)
> ==18019==by 0x4E9152B: thread_run (server.c:984)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-601) Valgrind errors in dispatch tests
[
https://issues.apache.org/jira/browse/DISPATCH-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15798928#comment-15798928
]
Ted Ross commented on DISPATCH-601:
---
All of the Dispatch-Side issues are fixed on this. The SASL issues won't be
addressed until PROTON-1380 is resolved.
> Valgrind errors in dispatch tests
> -
>
> Key: DISPATCH-601
> URL: https://issues.apache.org/jira/browse/DISPATCH-601
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Routing Engine
>Reporter: Alan Conway
>Assignee: Ted Ross
> Fix For: 0.8.0
>
> Attachments: dispatch-valgrind-err.txt
>
>
> There are several valgrind erros appearing in the dispatch tests. Full test
> output will be attached but the errors are all similar to this:
> {code}
> ==18019== Invalid read of size 1
> ==18019==at 0x4C30CAB: strcpy (vg_replace_strmem.c:506)
> ==18019==by 0x69DDFFD: strcpy (string3.h:110)
> ==18019==by 0x69DDFFD: _sasl_strdup (common.c:183)
> ==18019==by 0x69E55A4: sasl_server_new (server.c:1076)
> ==18019==by 0x50DD88F: pni_init_server (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50DC1F8: pni_sasl_start_server_if_needed.part.2 (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50DC7BE: pn_output_write_sasl (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50DEBBA: process_output_ssl (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50DA35C: pn_transport_pending (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x4E6EDA9: connector_process (driver.c:770)
> ==18019==by 0x4E6EC3A: qdpn_connector_process (driver.c:730)
> ==18019==by 0x4E907B3: process_connector (server.c:679)
> ==18019==by 0x4E91321: thread_run (server.c:957)
> ==18019== Address 0x11be7331 is 1 bytes inside a block of size 17 free'd
> ==18019==at 0x4C2ED4A: free (vg_replace_malloc.c:530)
> ==18019==by 0x50DCA0E: pn_sasl_free (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50D58BF: pn_transport_finalize (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50C7BF8: pn_class_decref (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50D406F: pn_event_finalize_cast (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50C7BF8: pn_class_decref (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50D437C: pn_collector_pop (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50D43AE: pn_collector_next (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50D440F: pn_collector_release (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50D4438: pn_collector_free (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x4E8E6C2: free_qd_connection (server.c:100)
> ==18019==by 0x4E9152B: thread_run (server.c:984)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-601) Valgrind errors in dispatch tests
[
https://issues.apache.org/jira/browse/DISPATCH-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15798913#comment-15798913
]
ASF subversion and git services commented on DISPATCH-601:
--
Commit f27b0107858f0a384ce19789ca97ec83c8d78804 in qpid-dispatch's branch
refs/heads/master from [~tr...@redhat.com]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=f27b010 ]
DISPATCH-601 - Fixed a use-of-uninitialized-data defect found by Valgrind.
> Valgrind errors in dispatch tests
> -
>
> Key: DISPATCH-601
> URL: https://issues.apache.org/jira/browse/DISPATCH-601
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Routing Engine
>Reporter: Alan Conway
>Assignee: Ted Ross
> Fix For: 0.8.0
>
> Attachments: dispatch-valgrind-err.txt
>
>
> There are several valgrind erros appearing in the dispatch tests. Full test
> output will be attached but the errors are all similar to this:
> {code}
> ==18019== Invalid read of size 1
> ==18019==at 0x4C30CAB: strcpy (vg_replace_strmem.c:506)
> ==18019==by 0x69DDFFD: strcpy (string3.h:110)
> ==18019==by 0x69DDFFD: _sasl_strdup (common.c:183)
> ==18019==by 0x69E55A4: sasl_server_new (server.c:1076)
> ==18019==by 0x50DD88F: pni_init_server (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50DC1F8: pni_sasl_start_server_if_needed.part.2 (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50DC7BE: pn_output_write_sasl (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50DEBBA: process_output_ssl (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50DA35C: pn_transport_pending (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x4E6EDA9: connector_process (driver.c:770)
> ==18019==by 0x4E6EC3A: qdpn_connector_process (driver.c:730)
> ==18019==by 0x4E907B3: process_connector (server.c:679)
> ==18019==by 0x4E91321: thread_run (server.c:957)
> ==18019== Address 0x11be7331 is 1 bytes inside a block of size 17 free'd
> ==18019==at 0x4C2ED4A: free (vg_replace_malloc.c:530)
> ==18019==by 0x50DCA0E: pn_sasl_free (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50D58BF: pn_transport_finalize (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50C7BF8: pn_class_decref (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50D406F: pn_event_finalize_cast (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50C7BF8: pn_class_decref (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50D437C: pn_collector_pop (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50D43AE: pn_collector_next (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50D440F: pn_collector_release (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50D4438: pn_collector_free (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x4E8E6C2: free_qd_connection (server.c:100)
> ==18019==by 0x4E9152B: thread_run (server.c:984)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-601) Valgrind errors in dispatch tests
[
https://issues.apache.org/jira/browse/DISPATCH-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15798914#comment-15798914
]
ASF subversion and git services commented on DISPATCH-601:
--
Commit fcc370e7d8e3ac62d3bd7f057bbbfdfc38de in qpid-dispatch's branch
refs/heads/master from [~tr...@redhat.com]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=fcc370e ]
DISPATCH-601 - Increased timeout and removed one test under valgrind
> Valgrind errors in dispatch tests
> -
>
> Key: DISPATCH-601
> URL: https://issues.apache.org/jira/browse/DISPATCH-601
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Routing Engine
>Reporter: Alan Conway
>Assignee: Ted Ross
> Fix For: 0.8.0
>
> Attachments: dispatch-valgrind-err.txt
>
>
> There are several valgrind erros appearing in the dispatch tests. Full test
> output will be attached but the errors are all similar to this:
> {code}
> ==18019== Invalid read of size 1
> ==18019==at 0x4C30CAB: strcpy (vg_replace_strmem.c:506)
> ==18019==by 0x69DDFFD: strcpy (string3.h:110)
> ==18019==by 0x69DDFFD: _sasl_strdup (common.c:183)
> ==18019==by 0x69E55A4: sasl_server_new (server.c:1076)
> ==18019==by 0x50DD88F: pni_init_server (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50DC1F8: pni_sasl_start_server_if_needed.part.2 (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50DC7BE: pn_output_write_sasl (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50DEBBA: process_output_ssl (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50DA35C: pn_transport_pending (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x4E6EDA9: connector_process (driver.c:770)
> ==18019==by 0x4E6EC3A: qdpn_connector_process (driver.c:730)
> ==18019==by 0x4E907B3: process_connector (server.c:679)
> ==18019==by 0x4E91321: thread_run (server.c:957)
> ==18019== Address 0x11be7331 is 1 bytes inside a block of size 17 free'd
> ==18019==at 0x4C2ED4A: free (vg_replace_malloc.c:530)
> ==18019==by 0x50DCA0E: pn_sasl_free (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50D58BF: pn_transport_finalize (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50C7BF8: pn_class_decref (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50D406F: pn_event_finalize_cast (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50C7BF8: pn_class_decref (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50D437C: pn_collector_pop (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50D43AE: pn_collector_next (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50D440F: pn_collector_release (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50D4438: pn_collector_free (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x4E8E6C2: free_qd_connection (server.c:100)
> ==18019==by 0x4E9152B: thread_run (server.c:984)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7531) [Java Broker] Tidy up AMQP 1.0 implementation
[ https://issues.apache.org/jira/browse/QPID-7531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15798879#comment-15798879 ] Keith Wall commented on QPID-7531: -- There are approximately 250 TODOs in the AMQP 1.0 protocol module. Many are related to error handling within the described type constructors (unexpected values, class cast exceptions etc). Others relate to the handling of unexpected states. > [Java Broker] Tidy up AMQP 1.0 implementation > - > > Key: QPID-7531 > URL: https://issues.apache.org/jira/browse/QPID-7531 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > Fix For: qpid-java-7.0 > > > The initial implementation of AMQP 1.0 in the broker came about through > importing initial prototyping code used in the creation of the protocol > standard and grafting it into the broker code. > Since this is now the only place the libraries are used we can tidy up the > joins between the initial AMQP implementation and the broker. We should also > look to remove (implement) TODOs and generally improve the code -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7531) [Java Broker] Tidy up AMQP 1.0 implementation
[ https://issues.apache.org/jira/browse/QPID-7531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7531: - Fix Version/s: qpid-java-7.0 > [Java Broker] Tidy up AMQP 1.0 implementation > - > > Key: QPID-7531 > URL: https://issues.apache.org/jira/browse/QPID-7531 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > Fix For: qpid-java-7.0 > > > The initial implementation of AMQP 1.0 in the broker came about through > importing initial prototyping code used in the creation of the protocol > standard and grafting it into the broker code. > Since this is now the only place the libraries are used we can tidy up the > joins between the initial AMQP implementation and the broker. We should also > look to remove (implement) TODOs and generally improve the code -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-7605) [Java Broker] [AMQP1.0] Container id uniqueness
[ https://issues.apache.org/jira/browse/QPID-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15798831#comment-15798831 ] Robbie Gemmell edited comment on QPID-7605 at 1/4/17 5:37 PM: -- Of course, reading through all the comments again, and thinking back more on some of the details around the ClientID thing, I think actually the intent was just that servers could always send the "amqp:connection-establishment-failed" property during 'open failure', with that alone being enough to indicate whats going on. The property map is already there, and just looking at it is a simpler client(/peer/server) change than needing to set a desired capability and inspect if its supported on the reply frame and then check the container-id. That we happened to have the capability bits for JMS for the ClientID check was due to that being a specific added reason to provoke the failure. Hehe yes, you'll need to give them a mail I think (I renamed and recreated my account...then had to mail to get the old one removed as you couldnt do that yourself :P) was (Author: gemmellr): Of course, reading through all the comments again, and thinking back more on some of the details around the ClientID thing, I think actually the intent was just that servers could always send the "amqp:connection-establishment-failed" property during 'open failure', with that alone being enough to indicate whats going on. he property map is already there, and just looking at it is a simpler client(/peer/server) change than needing to set a desired capability and inspect if its supported on the reply frame and then check the container-id. That we happened to have the capability bits for JMS for the ClientID check was due to that being a specific added reason to provoke the failure. Hehe yes, you'll need to give them a mail I think (I renamed and recreated my account...then had to mail to get the old one removed as you couldnt do that yourself :P) > [Java Broker] [AMQP1.0] Container id uniqueness > --- > > Key: QPID-7605 > URL: https://issues.apache.org/jira/browse/QPID-7605 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall > Fix For: qpid-java-7.0 > > > The AMQP 1.0 protocol layer implementation must ensure that the AMQP Open > performative container-id is unique amongst existing established connections. > As the JMS client id maps to the container-id, so this will fulfil the JMS > requirement. > https://docs.oracle.com/javaee/7/api/javax/jms/Connection.html#setClientID-java.lang.String- > Note that the Qpid JMS Client requires the Close performative with an Error > containing a hint to generate to correct JMS exception. How will the Qpid > Broker know to do this? > org.apache.qpid.jms.integration.FailedConnectionsIntegrationTest#testConnectWithInvalidClientIdThrowsICIDEWhenInvalidContainerHintPresent -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7605) [Java Broker] [AMQP1.0] Container id uniqueness
[ https://issues.apache.org/jira/browse/QPID-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15798831#comment-15798831 ] Robbie Gemmell commented on QPID-7605: -- Of course, reading through all the comments again, and thinking back more on some of the details around the ClientID thing, I think actually the intent was just that servers could always send the "amqp:connection-establishment-failed" property during 'open failure', with that alone being enough to indicate whats going on. he property map is already there, and just looking at it is a simpler client(/peer/server) change than needing to set a desired capability and inspect if its supported on the reply frame and then check the container-id. That we happened to have the capability bits for JMS for the ClientID check was due to that being a specific added reason to provoke the failure. Hehe yes, you'll need to give them a mail I think (I renamed and recreated my account...then had to mail to get the old one removed as you couldnt do that yourself :P) > [Java Broker] [AMQP1.0] Container id uniqueness > --- > > Key: QPID-7605 > URL: https://issues.apache.org/jira/browse/QPID-7605 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall > Fix For: qpid-java-7.0 > > > The AMQP 1.0 protocol layer implementation must ensure that the AMQP Open > performative container-id is unique amongst existing established connections. > As the JMS client id maps to the container-id, so this will fulfil the JMS > requirement. > https://docs.oracle.com/javaee/7/api/javax/jms/Connection.html#setClientID-java.lang.String- > Note that the Qpid JMS Client requires the Close performative with an Error > containing a hint to generate to correct JMS exception. How will the Qpid > Broker know to do this? > org.apache.qpid.jms.integration.FailedConnectionsIntegrationTest#testConnectWithInvalidClientIdThrowsICIDEWhenInvalidContainerHintPresent -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7603) [AMQP 1.0] Maximum Delivery Count/Dead-lettering
[
https://issues.apache.org/jira/browse/QPID-7603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7603:
-
Description:
Placeholder for Maximum Delivery Count/Dead-lettering support.
The current implementation in the Broker is incomplete. I notice the following
areas. There may be more.
* The protocol layer needs to trigger the MessageInstance#routeToAlternate
* Handling of the {{Rejected}} outcome is absent.
http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-rejected
* Implement handling of default outcomes.
* AMQP 1.0 Conversion layer should set Header#setDeliveryCount()
* I note that the AMQP 0-8..0-10 protocol layers use the
MessageInstance#deliveryCount differently to the AMQP 1.0 protocol layer.
This will need some care to ensure that protocol's play nicely together.
Also verify:
* Behaviour when the session is rolled back or the recovered.
* Behaviour when the session or connection is closed.
* Behaviour when the connection is abruptly dropped.
was:
Placeholder for Maximum Delivery Count/Dead-lettering support.
The current implementation in the Broker is incomplete. I notice the following
areas. There may be more.
* The protocol layer needs to trigger the MessageInstance#routeToAlternate
* Handling of the {{Rejected}} outcome is absent.
http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-rejected
* Implement handling of default outcomes.
* AMQP 1.0 Conversion layer should set Header#setDeliveryCount()
* I note that the AMQP 0-8..0-10 protocol layers use the
MessageInstance#deliveryCount differently to the AMQP 1.0 protocol layer.
This will need some care to ensure that protocol's play nicely together.
> [AMQP 1.0] Maximum Delivery Count/Dead-lettering
>
>
> Key: QPID-7603
> URL: https://issues.apache.org/jira/browse/QPID-7603
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-7.0
>
>
> Placeholder for Maximum Delivery Count/Dead-lettering support.
> The current implementation in the Broker is incomplete. I notice the
> following areas. There may be more.
> * The protocol layer needs to trigger the MessageInstance#routeToAlternate
> * Handling of the {{Rejected}} outcome is absent.
> http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-rejected
> * Implement handling of default outcomes.
> * AMQP 1.0 Conversion layer should set Header#setDeliveryCount()
> * I note that the AMQP 0-8..0-10 protocol layers use the
> MessageInstance#deliveryCount differently to the AMQP 1.0 protocol layer.
> This will need some care to ensure that protocol's play nicely together.
> Also verify:
> * Behaviour when the session is rolled back or the recovered.
> * Behaviour when the session or connection is closed.
> * Behaviour when the connection is abruptly dropped.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7605) [Java Broker] [AMQP1.0] Container id uniqueness
[ https://issues.apache.org/jira/browse/QPID-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15798781#comment-15798781 ] Rob Godfrey commented on QPID-7605: --- Yeah - I can't see how the id of the container which you can't connect to would be useful... if the remote container-id is useful to the client one would assume that they would know the association between it and the connection details anyway... and if they don't I'm not sure how not discovering it when they fail to open helps anyway :-) Anyway, this discussion probably needs to move somewhere else... though I probably don't have access to the OASIS TC right now > [Java Broker] [AMQP1.0] Container id uniqueness > --- > > Key: QPID-7605 > URL: https://issues.apache.org/jira/browse/QPID-7605 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall > Fix For: qpid-java-7.0 > > > The AMQP 1.0 protocol layer implementation must ensure that the AMQP Open > performative container-id is unique amongst existing established connections. > As the JMS client id maps to the container-id, so this will fulfil the JMS > requirement. > https://docs.oracle.com/javaee/7/api/javax/jms/Connection.html#setClientID-java.lang.String- > Note that the Qpid JMS Client requires the Close performative with an Error > containing a hint to generate to correct JMS exception. How will the Qpid > Broker know to do this? > org.apache.qpid.jms.integration.FailedConnectionsIntegrationTest#testConnectWithInvalidClientIdThrowsICIDEWhenInvalidContainerHintPresent -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-7605) [Java Broker] [AMQP1.0] Container id uniqueness
[
https://issues.apache.org/jira/browse/QPID-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15798738#comment-15798738
]
Robbie Gemmell edited comment on QPID-7605 at 1/4/17 5:04 PM:
--
{quote}
So the info map is on the close... my comments were focussed on the open...
{quote}
Yep, just checking you din't mean using a special container-id in the response
would be conveying the same detail we added the close error info map for.
Rather it would only be signalling the 'close is about to arrive' behaviour,
and the fact both bits reference the container-id here is unrelated.
{quote}
Given that we do not originally call out that the empty string should be
treated as a special "I'm sorry Dave, I'm afraid I can't do that" meaning I'm
hesitant about saying that that in itself should be enough to call out the fact
that the connection is going to immediately close... What we could say though
is that we define a connection capability "EMPTY_CONTAINER_ID_ON_OPEN_FAILS" or
something such that if the capability is present and the container-id is not
empty the the initiator can be assured that the connection is not about to
immediately close... and if the capability is there and the container-id is the
empty string then it knows that the connection is about to close.
{quote}
Yes, thats why we went with the property originally to convey the impending
close, as the container-id behaviour had no definition around it like that in
the original spec.We also thought it could be used to the same end in any
similar behaviour-specific mechanisms to the ClientID scenario. Making it an
even more general mechanism like this isn't something I'd considered before,
but that also makes sense. The only issue would be if anyone wanted the actual
container-id of the remote peer to help govern their subsequent behaviour in
some way, not sure how likely that is.
was (Author: gemmellr):
{quote}
So the info map is on the close... my comments were focussed on the open...
{quote}
Yep, just checking you din't mean using a special container-id in the response
would be conveying the same detail we added the close error info map for.
Rather it would only be signalling the 'close is about to arrive' behaviour,
and the fact both bits reference the container-id here is unrelated.
{quote}
Given that we do not originally call out that the empty string should be
treated as a special "I'm sorry Dave, I'm afraid I can't do that" meaning I'm
hesitant about saying that that in itself should be enough to call out the fact
that the connection is going to immediately close... What we could say though
is that we define a connection capability "EMPTY_CONTAINER_ID_ON_OPEN_FAILS" or
something such that if the capability is present and the container-id is not
null the the initiator can be assured that the connection is not about to
immediately close... and if the capability is there and the container-id is the
empty string then it knows that the connection is about to close.
{quote}
Yes, thats why we went with the property originally to convey the impending
close, as the container-id behaviour had no definition around it like that in
the original spec.We also thought it could be used to the same end in any
similar behaviour-specific mechanisms to the ClientID scenario. Making it an
even more general mechanism like this isn't something I'd considered before,
but that also makes sense.
I see you've edited this already :)
> [Java Broker] [AMQP1.0] Container id uniqueness
> ---
>
> Key: QPID-7605
> URL: https://issues.apache.org/jira/browse/QPID-7605
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-7.0
>
>
> The AMQP 1.0 protocol layer implementation must ensure that the AMQP Open
> performative container-id is unique amongst existing established connections.
> As the JMS client id maps to the container-id, so this will fulfil the JMS
> requirement.
> https://docs.oracle.com/javaee/7/api/javax/jms/Connection.html#setClientID-java.lang.String-
> Note that the Qpid JMS Client requires the Close performative with an Error
> containing a hint to generate to correct JMS exception. How will the Qpid
> Broker know to do this?
> org.apache.qpid.jms.integration.FailedConnectionsIntegrationTest#testConnectWithInvalidClientIdThrowsICIDEWhenInvalidContainerHintPresent
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7605) [Java Broker] [AMQP1.0] Container id uniqueness
[
https://issues.apache.org/jira/browse/QPID-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15798738#comment-15798738
]
Robbie Gemmell commented on QPID-7605:
--
{quote}
So the info map is on the close... my comments were focussed on the open...
{quote}
Yep, just checking you din't mean using a special container-id in the response
would be conveying the same detail we added the close error info map for.
Rather it would only be signalling the 'close is about to arrive' behaviour,
and the fact both bits reference the container-id here is unrelated.
{quote}
Given that we do not originally call out that the empty string should be
treated as a special "I'm sorry Dave, I'm afraid I can't do that" meaning I'm
hesitant about saying that that in itself should be enough to call out the fact
that the connection is going to immediately close... What we could say though
is that we define a connection capability "EMPTY_CONTAINER_ID_ON_OPEN_FAILS" or
something such that if the capability is present and the container-id is not
null the the initiator can be assured that the connection is not about to
immediately close... and if the capability is there and the container-id is the
empty string then it knows that the connection is about to close.
{quote}
Yes, thats why we went with the property originally to convey the impending
close, as the container-id behaviour had no definition around it like that in
the original spec.We also thought it could be used to the same end in any
similar behaviour-specific mechanisms to the ClientID scenario. Making it an
even more general mechanism like this isn't something I'd considered before,
but that also makes sense.
I see you've edited this already :)
> [Java Broker] [AMQP1.0] Container id uniqueness
> ---
>
> Key: QPID-7605
> URL: https://issues.apache.org/jira/browse/QPID-7605
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-7.0
>
>
> The AMQP 1.0 protocol layer implementation must ensure that the AMQP Open
> performative container-id is unique amongst existing established connections.
> As the JMS client id maps to the container-id, so this will fulfil the JMS
> requirement.
> https://docs.oracle.com/javaee/7/api/javax/jms/Connection.html#setClientID-java.lang.String-
> Note that the Qpid JMS Client requires the Close performative with an Error
> containing a hint to generate to correct JMS exception. How will the Qpid
> Broker know to do this?
> org.apache.qpid.jms.integration.FailedConnectionsIntegrationTest#testConnectWithInvalidClientIdThrowsICIDEWhenInvalidContainerHintPresent
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-7605) [Java Broker] [AMQP1.0] Container id uniqueness
[ https://issues.apache.org/jira/browse/QPID-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15798703#comment-15798703 ] Rob Godfrey edited comment on QPID-7605 at 1/4/17 4:54 PM: --- So the info map is on the close... my comments were focussed on the open... Given that we do not originally call out that the empty string should be treated as a special "I'm sorry Dave, I'm afraid I can't do that" meaning I'm hesitant about saying that that in itself should be enough to call out the fact that the connection is going to immediately close... What we could say though is that we define a connection capability "EMPTY_CONTAINER_ID_ON_OPEN_FAILS" or something such that if the capability is present and the container-id is not empty the the initiator can be assured that the connection is not about to immediately close... and if the capability is there and the container-id is the empty string then it knows that the connection is about to close. And yes - this would need to be some sort of note from the TC was (Author: rgodfrey): So the info map is on the close... my comments were focussed on the open... Given that we do not originally call out that the empty string should be treated as a special "I'm sorry Dave, I'm afraid I can't do that" meaning I'm hesitant about saying that that in itself should be enough to call out the fact that the connection is going to immediately close... What we could say though is that we define a connection capability "EMPTY_CONTAINER_ID_ON_OPEN_FAILS" or something such that if the capability is present and the container-id is not null the the initiator can be assured that the connection is not about to immediately close... and if the capability is there and the container-id is the empty string then it knows that the connection is about to close. And yes - this would need to be some sort of note from the TC > [Java Broker] [AMQP1.0] Container id uniqueness > --- > > Key: QPID-7605 > URL: https://issues.apache.org/jira/browse/QPID-7605 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall > Fix For: qpid-java-7.0 > > > The AMQP 1.0 protocol layer implementation must ensure that the AMQP Open > performative container-id is unique amongst existing established connections. > As the JMS client id maps to the container-id, so this will fulfil the JMS > requirement. > https://docs.oracle.com/javaee/7/api/javax/jms/Connection.html#setClientID-java.lang.String- > Note that the Qpid JMS Client requires the Close performative with an Error > containing a hint to generate to correct JMS exception. How will the Qpid > Broker know to do this? > org.apache.qpid.jms.integration.FailedConnectionsIntegrationTest#testConnectWithInvalidClientIdThrowsICIDEWhenInvalidContainerHintPresent -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7601) [Java Broker] Allow annotations to define ManagedAttributeValueTypes as abstract, some methods as derived
[ https://issues.apache.org/jira/browse/QPID-7601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7601: - Status: Reviewable (was: In Progress) > [Java Broker] Allow annotations to define ManagedAttributeValueTypes as > abstract, some methods as derived > - > > Key: QPID-7601 > URL: https://issues.apache.org/jira/browse/QPID-7601 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > Fix For: qpid-java-7.0 > > > ManagedAttributeValueTypes may form a type hierarchy, however there is no way > for a value to be resolved to a particular instance class. > A type can be marked as abstract meaning that it cannot itself be > instantiated from an input value (i.e. it cannot be used as a managed > attribute, or the input to an operation). An abstract type can be used as an > output value (e.g. as a return value from an operation, or as a derived > attribute). > Further we should allow ManagedAttributeTypes to themselves have derived > attributes. These attributes should be returned from query methods, but not > persisted, and values for these attributes should be ignored when present in > input data. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7605) [Java Broker] [AMQP1.0] Container id uniqueness
[ https://issues.apache.org/jira/browse/QPID-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15798703#comment-15798703 ] Rob Godfrey commented on QPID-7605: --- So the info map is on the close... my comments were focussed on the open... Given that we do not originally call out that the empty string should be treated as a special "I'm sorry Dave, I'm afraid I can't do that" meaning I'm hesitant about saying that that in itself should be enough to call out the fact that the connection is going to immediately close... What we could say though is that we define a connection capability "EMPTY_CONTAINER_ID_ON_OPEN_FAILS" or something such that if the capability is present and the container-id is not null the the initiator can be assured that the connection is not about to immediately close... and if the capability is there and the container-id is the empty string then it knows that the connection is about to close. And yes - this would need to be some sort of note from the TC > [Java Broker] [AMQP1.0] Container id uniqueness > --- > > Key: QPID-7605 > URL: https://issues.apache.org/jira/browse/QPID-7605 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall > Fix For: qpid-java-7.0 > > > The AMQP 1.0 protocol layer implementation must ensure that the AMQP Open > performative container-id is unique amongst existing established connections. > As the JMS client id maps to the container-id, so this will fulfil the JMS > requirement. > https://docs.oracle.com/javaee/7/api/javax/jms/Connection.html#setClientID-java.lang.String- > Note that the Qpid JMS Client requires the Close performative with an Error > containing a hint to generate to correct JMS exception. How will the Qpid > Broker know to do this? > org.apache.qpid.jms.integration.FailedConnectionsIntegrationTest#testConnectWithInvalidClientIdThrowsICIDEWhenInvalidContainerHintPresent -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7586) [Java Broker] [AMQP 1.0] Simplify the AMQP codec so that it always assumes that the buffer it is writing into is large enough
[ https://issues.apache.org/jira/browse/QPID-7586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7586: - Status: Reviewable (was: In Progress) > [Java Broker] [AMQP 1.0] Simplify the AMQP codec so that it always assumes > that the buffer it is writing into is large enough > - > > Key: QPID-7586 > URL: https://issues.apache.org/jira/browse/QPID-7586 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Keith Wall > Fix For: qpid-java-7.0 > > > The way the codec is used, we always allocate enough space for the entire > value to be written. We can simplify the codec by separating the operation > to get the required buffer size from the implementation of writing to the > buffer -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7586) [Java Broker] [AMQP 1.0] Simplify the AMQP codec so that it always assumes that the buffer it is writing into is large enough
[ https://issues.apache.org/jira/browse/QPID-7586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7586: - Assignee: (was: Keith Wall) > [Java Broker] [AMQP 1.0] Simplify the AMQP codec so that it always assumes > that the buffer it is writing into is large enough > - > > Key: QPID-7586 > URL: https://issues.apache.org/jira/browse/QPID-7586 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey > Fix For: qpid-java-7.0 > > > The way the codec is used, we always allocate enough space for the entire > value to be written. We can simplify the codec by separating the operation > to get the required buffer size from the implementation of writing to the > buffer -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-7586) [Java Broker] [AMQP 1.0] Simplify the AMQP codec so that it always assumes that the buffer it is writing into is large enough
[ https://issues.apache.org/jira/browse/QPID-7586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall reassigned QPID-7586: Assignee: Keith Wall > [Java Broker] [AMQP 1.0] Simplify the AMQP codec so that it always assumes > that the buffer it is writing into is large enough > - > > Key: QPID-7586 > URL: https://issues.apache.org/jira/browse/QPID-7586 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Keith Wall > Fix For: qpid-java-7.0 > > > The way the codec is used, we always allocate enough space for the entire > value to be written. We can simplify the codec by separating the operation > to get the required buffer size from the implementation of writing to the > buffer -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7593) Ending an AMQP1.0 connection with consumer leaks the connection, session and objects related to the consumer
[
https://issues.apache.org/jira/browse/QPID-7593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall resolved QPID-7593.
--
Resolution: Fixed
Rob and I paired on this change.
> Ending an AMQP1.0 connection with consumer leaks the connection, session and
> objects related to the consumer
>
>
> Key: QPID-7593
> URL: https://issues.apache.org/jira/browse/QPID-7593
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-7.0
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-7.0
>
> Attachments: Screen Shot 2016-12-20 at 08.16.37.png
>
>
> If I run the following code, jvisualvm shows that the object that underlies
> the AMQP1.0 Connection, Session and Consumer are leaked.
> The GC root is the QueueConsumerNodeList associated with the
> Queue/QueueConsumerManager. The node the tail and is in the deleted state
> and will be eventually scavenged (once new consumers join the queue). This
> is common with the other protocols and I believe this aspect is as designed.
> However, I think the fact that the Connections/Session/ConsumerTarget remains
> referenced is a defect. It shows us that the ConsumerTarget_1.0
> (org/apache/qpid/server/consumer/AbstractConsumerTarget.java:284) is not
> being closed. Other protocols don't show this same defect.
> {code:java}
> Properties properties = new Properties();
> properties.load(resourceAsStream);
> Context context = new InitialContext(properties);
> ConnectionFactory connectionFactory = (ConnectionFactory)
> context.lookup("qpidConnectionfactory");
> Connection connection = connectionFactory.createConnection();
> connection.start();
> Session session = connection.createSession(false,
> Session.AUTO_ACKNOWLEDGE);
> Destination destination = (Destination) context.lookup("myqueue");
> MessageConsumer messageConsumer =
> session.createConsumer(destination);
> if (true) System.exit(1);
> {code}
> I expect this defect does not appear in release versions of the product.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-7597) Expose the bound (i.e. listening) port number on Port model object
[
https://issues.apache.org/jira/browse/QPID-7597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall reassigned QPID-7597:
Assignee: Keith Wall
> Expose the bound (i.e. listening) port number on Port model object
> --
>
> Key: QPID-7597
> URL: https://issues.apache.org/jira/browse/QPID-7597
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-7.0
>
>
> When a HTTP or AMQP Port is configured to dynamically assign its own port
> number (with {{port}} = 0), the caller needs means to discover which port
> number has been chosen for a newly created port.
> Add a derived attribute {{Port#boundPort}} to expose it.
> When a dynamically allocated port number is not in use, {{boundPort}} will
> simply reflect the same value as {{port}}.
> This will be useful when the Broker is embedded and when Ports are
> dynamically created through HTTP or AMQP management.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7597) Expose the bound (i.e. listening) port number on Port model object
[
https://issues.apache.org/jira/browse/QPID-7597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7597:
-
Status: Reviewable (was: In Progress)
> Expose the bound (i.e. listening) port number on Port model object
> --
>
> Key: QPID-7597
> URL: https://issues.apache.org/jira/browse/QPID-7597
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-7.0
>
>
> When a HTTP or AMQP Port is configured to dynamically assign its own port
> number (with {{port}} = 0), the caller needs means to discover which port
> number has been chosen for a newly created port.
> Add a derived attribute {{Port#boundPort}} to expose it.
> When a dynamically allocated port number is not in use, {{boundPort}} will
> simply reflect the same value as {{port}}.
> This will be useful when the Broker is embedded and when Ports are
> dynamically created through HTTP or AMQP management.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1381) Compiler errors: dereferencing pointer to incomplete type DH {aka struct dh_st}
[
https://issues.apache.org/jira/browse/PROTON-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Volker Diels-Grabsch updated PROTON-1381:
-
Description:
Proton-C doesn't build with GCC 6.2.1 and OpenSSL 1.1.0c. The error message is:
{code:borderStyle=solid}
[ 51%] Building C object proton-c/CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o
/.../proton-c/src/ssl/openssl.c: In function ‘get_dh2048’:
/.../proton-c/src/ssl/openssl.c:406:5: error: dereferencing pointer to
incomplete type ‘DH {aka struct dh_st}’
dh->p=BN_bin2bn(dh2048_p,sizeof(dh2048_p),NULL);
^~
proton-c/CMakeFiles/qpid-proton.dir/build.make:1102: recipe for target
'proton-c/CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o' failed
{code}
The attached patch fixes this issue for 0.14.0 and also works for 0.16.0.
was:
Proton-C doesn't build with GCC 6.2.1 and OpenSSL 1.1.0c. The error message is:
{quote}
{{[ 51%] Building C object
proton-c/CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o}}
{{/.../proton-c/src/ssl/openssl.c: In function ‘get_dh2048’:}}
{{/.../proton-c/src/ssl/openssl.c:406:5: error: dereferencing pointer to
incomplete type ‘DH {aka struct dh_st}’}}
{{ dh->p=BN_bin2bn(dh2048_p,sizeof(dh2048_p),NULL);}}
{{ ^~}}
{{proton-c/CMakeFiles/qpid-proton.dir/build.make:1102: recipe for target
'proton-c/CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o' failed}}
{quote}
The attached patch fixes this issue for 0.14.0 and also works for 0.16.0.
> Compiler errors: dereferencing pointer to incomplete type DH {aka struct
> dh_st}
> ---
>
> Key: PROTON-1381
> URL: https://issues.apache.org/jira/browse/PROTON-1381
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.14.0, 0.16.0
> Environment: GCC 6.2.1, OpenSSL 1.1.0c
>Reporter: Volker Diels-Grabsch
>Priority: Blocker
> Labels: build, patch
> Attachments:
> qpid-proton-0.14.0-fix-dereferencing-pointer-to-incomplete-type.patch
>
>
> Proton-C doesn't build with GCC 6.2.1 and OpenSSL 1.1.0c. The error message
> is:
> {code:borderStyle=solid}
> [ 51%] Building C object
> proton-c/CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o
> /.../proton-c/src/ssl/openssl.c: In function ‘get_dh2048’:
> /.../proton-c/src/ssl/openssl.c:406:5: error: dereferencing pointer to
> incomplete type ‘DH {aka struct dh_st}’
>dh->p=BN_bin2bn(dh2048_p,sizeof(dh2048_p),NULL);
> ^~
> proton-c/CMakeFiles/qpid-proton.dir/build.make:1102: recipe for target
> 'proton-c/CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o' failed
> {code}
> The attached patch fixes this issue for 0.14.0 and also works for 0.16.0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1381) Compiler errors: dereferencing pointer to incomplete type DH {aka struct dh_st}
[
https://issues.apache.org/jira/browse/PROTON-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Volker Diels-Grabsch updated PROTON-1381:
-
Description:
Proton-C doesn't build with GCC 6.2.1 and OpenSSL 1.1.0c. The error message is:
{quote}
{{[ 51%] Building C object
proton-c/CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o}}
{{/.../proton-c/src/ssl/openssl.c: In function ‘get_dh2048’:}}
{{/.../proton-c/src/ssl/openssl.c:406:5: error: dereferencing pointer to
incomplete type ‘DH {aka struct dh_st}’}}
{{ dh->p=BN_bin2bn(dh2048_p,sizeof(dh2048_p),NULL);}}
{{ ^~}}
{{proton-c/CMakeFiles/qpid-proton.dir/build.make:1102: recipe for target
'proton-c/CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o' failed}}
{quote}
The attached patch fixes this issue for 0.14.0 and also works for 0.16.0.
was:
Proton-C doesn't build with GCC 6.2.1 and OpenSSL 1.1.0c. The error message is:
{quote}
[ 51%] Building C object proton-c/CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o
/.../proton-c/src/ssl/openssl.c: In function ‘get_dh2048’:
/.../proton-c/src/ssl/openssl.c:406:5: error: dereferencing pointer to
incomplete type ‘DH {aka struct dh_st}’
dh->p=BN_bin2bn(dh2048_p,sizeof(dh2048_p),NULL);
^~
proton-c/CMakeFiles/qpid-proton.dir/build.make:1102: recipe for target
'proton-c/CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o' failed
{quote}
The attached patch fixes this issue for 0.14.0 and also works for 0.16.0.
> Compiler errors: dereferencing pointer to incomplete type DH {aka struct
> dh_st}
> ---
>
> Key: PROTON-1381
> URL: https://issues.apache.org/jira/browse/PROTON-1381
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.14.0, 0.16.0
> Environment: GCC 6.2.1, OpenSSL 1.1.0c
>Reporter: Volker Diels-Grabsch
>Priority: Blocker
> Labels: build, patch
> Attachments:
> qpid-proton-0.14.0-fix-dereferencing-pointer-to-incomplete-type.patch
>
>
> Proton-C doesn't build with GCC 6.2.1 and OpenSSL 1.1.0c. The error message
> is:
> {quote}
> {{[ 51%] Building C object
> proton-c/CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o}}
> {{/.../proton-c/src/ssl/openssl.c: In function ‘get_dh2048’:}}
> {{/.../proton-c/src/ssl/openssl.c:406:5: error: dereferencing pointer to
> incomplete type ‘DH {aka struct dh_st}’}}
> {{ dh->p=BN_bin2bn(dh2048_p,sizeof(dh2048_p),NULL);}}
> {{ ^~}}
> {{proton-c/CMakeFiles/qpid-proton.dir/build.make:1102: recipe for target
> 'proton-c/CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o' failed}}
> {quote}
> The attached patch fixes this issue for 0.14.0 and also works for 0.16.0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-601) Valgrind errors in dispatch tests
[
https://issues.apache.org/jira/browse/DISPATCH-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15798667#comment-15798667
]
Ted Ross commented on DISPATCH-601:
---
One class of failures is caused by this bug in Proton-C.
> Valgrind errors in dispatch tests
> -
>
> Key: DISPATCH-601
> URL: https://issues.apache.org/jira/browse/DISPATCH-601
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Routing Engine
>Reporter: Alan Conway
>Assignee: Ted Ross
> Fix For: 0.8.0
>
> Attachments: dispatch-valgrind-err.txt
>
>
> There are several valgrind erros appearing in the dispatch tests. Full test
> output will be attached but the errors are all similar to this:
> {code}
> ==18019== Invalid read of size 1
> ==18019==at 0x4C30CAB: strcpy (vg_replace_strmem.c:506)
> ==18019==by 0x69DDFFD: strcpy (string3.h:110)
> ==18019==by 0x69DDFFD: _sasl_strdup (common.c:183)
> ==18019==by 0x69E55A4: sasl_server_new (server.c:1076)
> ==18019==by 0x50DD88F: pni_init_server (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50DC1F8: pni_sasl_start_server_if_needed.part.2 (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50DC7BE: pn_output_write_sasl (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50DEBBA: process_output_ssl (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50DA35C: pn_transport_pending (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x4E6EDA9: connector_process (driver.c:770)
> ==18019==by 0x4E6EC3A: qdpn_connector_process (driver.c:730)
> ==18019==by 0x4E907B3: process_connector (server.c:679)
> ==18019==by 0x4E91321: thread_run (server.c:957)
> ==18019== Address 0x11be7331 is 1 bytes inside a block of size 17 free'd
> ==18019==at 0x4C2ED4A: free (vg_replace_malloc.c:530)
> ==18019==by 0x50DCA0E: pn_sasl_free (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50D58BF: pn_transport_finalize (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50C7BF8: pn_class_decref (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50D406F: pn_event_finalize_cast (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50C7BF8: pn_class_decref (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50D437C: pn_collector_pop (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50D43AE: pn_collector_next (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50D440F: pn_collector_release (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x50D4438: pn_collector_free (in
> /usr/local/lib64/libqpid-proton.so.10.0.0)
> ==18019==by 0x4E8E6C2: free_qd_connection (server.c:100)
> ==18019==by 0x4E9152B: thread_run (server.c:984)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1381) Compiler errors: dereferencing pointer to incomplete type DH {aka struct dh_st}
Volker Diels-Grabsch created PROTON-1381:
Summary: Compiler errors: dereferencing pointer to incomplete type
DH {aka struct dh_st}
Key: PROTON-1381
URL: https://issues.apache.org/jira/browse/PROTON-1381
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.16.0, 0.14.0
Environment: GCC 6.2.1, OpenSSL 1.1.0c
Reporter: Volker Diels-Grabsch
Priority: Blocker
Attachments:
qpid-proton-0.14.0-fix-dereferencing-pointer-to-incomplete-type.patch
Proton-C doesn't build with GCC 6.2.1 and OpenSSL 1.1.0c. The error message is:
{quote}
[ 51%] Building C object proton-c/CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o
/.../proton-c/src/ssl/openssl.c: In function ‘get_dh2048’:
/.../proton-c/src/ssl/openssl.c:406:5: error: dereferencing pointer to
incomplete type ‘DH {aka struct dh_st}’
dh->p=BN_bin2bn(dh2048_p,sizeof(dh2048_p),NULL);
^~
proton-c/CMakeFiles/qpid-proton.dir/build.make:1102: recipe for target
'proton-c/CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o' failed
{quote}
The attached patch fixes this issue for 0.14.0 and also works for 0.16.0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1380) Cyrus SASL accesses strings that have been freed
[ https://issues.apache.org/jira/browse/PROTON-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1380: Assignee: Andrew Stitcher > Cyrus SASL accesses strings that have been freed > > > Key: PROTON-1380 > URL: https://issues.apache.org/jira/browse/PROTON-1380 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.16.0 >Reporter: Ted Ross >Assignee: Andrew Stitcher >Priority: Blocker > > If a proton-c user calls pn_sasl_config_name or pn_sasl_config_path, the > literal defaults are replaced with allocated duplicates of the supplied name > or path. When the user's transport is eventually freed, these allocated > strings are also freed (in pn_sasl_free). > Cyrus SASL retains a global pointer to this freed string and references it > the next time a transport is created. Since the SASL initialization only > occurs once per process, the strings are not refreshed and the SASL library > continues to refer to the freed string. > There does not appear to be a workaround available for this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7605) [Java Broker] [AMQP1.0] Container id uniqueness
[ https://issues.apache.org/jira/browse/QPID-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15798660#comment-15798660 ] Robbie Gemmell commented on QPID-7605: -- That would seem reasonable to me. Do you mean in addition to or instead of using the info map? Expanding my previous comment a bit further, I think we actually used the 'invalid field' error specifically and the error info map entry was then essentially adding detail around which field was being considered at the time, since it could apply to a other scenarios preventing connection too. To clairfy, where were you thinking we would say this, some sort of committee note around the core protocol? Originally I think we were intending the whole 'informing of pending open failure' thing could be covered elsewhere and just referenced in the JMS mapping. > [Java Broker] [AMQP1.0] Container id uniqueness > --- > > Key: QPID-7605 > URL: https://issues.apache.org/jira/browse/QPID-7605 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall > Fix For: qpid-java-7.0 > > > The AMQP 1.0 protocol layer implementation must ensure that the AMQP Open > performative container-id is unique amongst existing established connections. > As the JMS client id maps to the container-id, so this will fulfil the JMS > requirement. > https://docs.oracle.com/javaee/7/api/javax/jms/Connection.html#setClientID-java.lang.String- > Note that the Qpid JMS Client requires the Close performative with an Error > containing a hint to generate to correct JMS exception. How will the Qpid > Broker know to do this? > org.apache.qpid.jms.integration.FailedConnectionsIntegrationTest#testConnectWithInvalidClientIdThrowsICIDEWhenInvalidContainerHintPresent -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1380) Cyrus SASL accesses strings that have been freed
Ted Ross created PROTON-1380: Summary: Cyrus SASL accesses strings that have been freed Key: PROTON-1380 URL: https://issues.apache.org/jira/browse/PROTON-1380 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.16.0 Reporter: Ted Ross Priority: Blocker If a proton-c user calls pn_sasl_config_name or pn_sasl_config_path, the literal defaults are replaced with allocated duplicates of the supplied name or path. When the user's transport is eventually freed, these allocated strings are also freed (in pn_sasl_free). Cyrus SASL retains a global pointer to this freed string and references it the next time a transport is created. Since the SASL initialization only occurs once per process, the strings are not refreshed and the SASL library continues to refer to the freed string. There does not appear to be a workaround available for this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7219) [Java Broker, WMC] Do not poll data when previous poll has not yet completed
[ https://issues.apache.org/jira/browse/QPID-7219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7219: - Fix Version/s: Future > [Java Broker, WMC] Do not poll data when previous poll has not yet completed > > > Key: QPID-7219 > URL: https://issues.apache.org/jira/browse/QPID-7219 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Lorenz Quack >Priority: Minor > Fix For: Future > > > Currently the WMC updates itself every 5 seconds by polling data from the > broker. This happens even if the request takes longer than 5 seconds. > We should not poll while an update is in progress. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7194) Give client an ordered preferences to drive AMQP protocol selection
[ https://issues.apache.org/jira/browse/QPID-7194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall resolved QPID-7194. -- Resolution: Won't Fix Legacy Client is no longer a priority. > Give client an ordered preferences to drive AMQP protocol selection > --- > > Key: QPID-7194 > URL: https://issues.apache.org/jira/browse/QPID-7194 > Project: Qpid > Issue Type: Improvement > Components: Java Client >Reporter: Keith Wall >Priority: Minor > > Give the client an optional configuration parameter (system property and/or > connection url property), that allows it to drive AMQP selection by an > ordered preference list. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7194) Give client an ordered preferences to drive AMQP protocol selection
[ https://issues.apache.org/jira/browse/QPID-7194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7194: - Fix Version/s: (was: qpid-java-7.0) > Give client an ordered preferences to drive AMQP protocol selection > --- > > Key: QPID-7194 > URL: https://issues.apache.org/jira/browse/QPID-7194 > Project: Qpid > Issue Type: Improvement > Components: Java Client >Reporter: Keith Wall >Priority: Minor > > Give the client an optional configuration parameter (system property and/or > connection url property), that allows it to drive AMQP selection by an > ordered preference list. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7436) Improve the speed at which large queues can be cleared
[
https://issues.apache.org/jira/browse/QPID-7436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7436:
-
Fix Version/s: (was: qpid-java-7.0)
Future
> Improve the speed at which large queues can be cleared
> --
>
> Key: QPID-7436
> URL: https://issues.apache.org/jira/browse/QPID-7436
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Keith Wall
> Fix For: Future
>
> Attachments: bdb_cursor_dequeue_message_instances.patch
>
>
> Currently clearing a large queue takes a considerable length of time. This
> can increase the recovery time of an application trying to recover from a
> production incident.
> The store should have the ability to perform something analogous to a
> database {{TRUNCATE TABLE}} to quickly remove all entries on a queue. It may
> be necessary to temporarily suspend enqueues to a queue whilst the operation
> is ongoing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-7405) [Java Client] Improve application-side detectability of Producer side FlowControl
[ https://issues.apache.org/jira/browse/QPID-7405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall closed QPID-7405. Resolution: Won't Fix Closing as Won't Fix as Legacy Client is no longer a priority. > [Java Client] Improve application-side detectability of Producer side > FlowControl > - > > Key: QPID-7405 > URL: https://issues.apache.org/jira/browse/QPID-7405 > Project: Qpid > Issue Type: Improvement > Components: Java Client >Reporter: Lorenz Quack > Fix For: Future > > > If the broker enforces producer side flow control which then causes a timeout > the application code currently only sees a JMSException with no way (except > for error message parsing) to detect the cause of the exception. > We should consider improving the detectability of flow control so that > application code can customise the handling of different timeout causes. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-7388) [0-10] Client may not respond with a SessionDetached in response to ExecutionException being closed by peer
[
https://issues.apache.org/jira/browse/QPID-7388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall closed QPID-7388.
Resolution: Won't Fix
> [0-10] Client may not respond with a SessionDetached in response to
> ExecutionException being closed by peer
> ---
>
> Key: QPID-7388
> URL: https://issues.apache.org/jira/browse/QPID-7388
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
>Affects Versions: qpid-java-6.1
>Reporter: Keith Wall
>Priority: Minor
> Fix For: Future
>
> Attachments:
> TEST-org.apache.qpid.test.unit.transacted.TransactionTimeoutTest.testProducerOpenCommitTwice.txt
>
>
> {{TransactionTimeoutTest}} failed
> https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Java-Java-MMS-TestMatrix/3241/jdk=JDK%201.7%20(latest),label=ubuntu,profile=java-mms.0-10/artifact/trunk/systests/target/surefire-reports/java-mms.0-10/TEST-org.apache.qpid.test.unit.transacted.TransactionTimeoutTest.testProducerOpenCommitTwice.txt
> in the following manner:
> {noformat}
> org.apache.qpid.test.unit.transacted.TransactionTimeoutTest.testProducerOpenCommitTwice
> Failing for the past 1 build (Since Failed#3241 )
> Took 1 min 3 sec.
> Error Message
> Should have caught exception in listener
> Stacktrace
> junit.framework.AssertionFailedError: Should have caught exception in listener
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.TestCase.assertTrue(TestCase.java:192)
> at
> org.apache.qpid.test.unit.transacted.TransactionTimeoutTestCase.check(TransactionTimeoutTestCase.java:214)
> at
> org.apache.qpid.test.unit.transacted.TransactionTimeoutTest.testProducerOpenCommitTwice(TransactionTimeoutTest.java:214)
> {noformat}
> Examination of the logs (attached), show that the Broker sent an
> {{ExecutionException(errorCode=RESOURCE_LIMIT_EXCEEDED, description=Open
> transaction timed out)}} and then followed with other session commands
> including a {{SessionDetatch}}. The client failed to report the exception to
> the application (test) by way of a JMSException from the {{#commit()}} call.
> It also hung, seemingly trying to close the session itself. The problem
> suggests a client side race, but I have not investigated further.
> Perhaps the Broker change - QPID-7374 - has somehow brought this defect out?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7322) [Java Broker] Add ability to specify Qpid vendor specific or deployment specific properties file in addition to Qpid instance properties file which can be specified with c
[ https://issues.apache.org/jira/browse/QPID-7322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7322: - Fix Version/s: qpid-java-7.0 > [Java Broker] Add ability to specify Qpid vendor specific or deployment > specific properties file in addition to Qpid instance properties file which > can be specified with command line arguments -props > --- > > Key: QPID-7322 > URL: https://issues.apache.org/jira/browse/QPID-7322 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Alex Rudyy > Fix For: qpid-java-7.0 > > > Currently broker properties can be specified in the following ways: > * environment variables > * JVM system properties > * using command line argument ' -prop' and specifying key value pair > * using command line argument '-props' to specify a path to a properties file > * system.properties file in classpath if command line argument ' -props ' is > not set > * context variables on the configured objects > In some cases when Qpid distribution is deployed into specific environments a > properties file with environment specific settings needs to be provided and > bundled with Qpid distribution. For example, some of AMQP protocols or > configured objects implementations can be disabled in such properties file. > At the moment, such settings can be put system.properties file on the > classpath. However, if user will specify a path to properties file with > command line option -props, the settings in system.properties file will not > be applied. We need a mechanism to provide a Qpid environment deployment > properties file in addition to instance specific properties file specified > with command line argument '-props'. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7321) [Java Broker] Annotation processing on partial builds can produce incorrect META-INF/services files
[ https://issues.apache.org/jira/browse/QPID-7321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7321: - Priority: Minor (was: Major) > [Java Broker] Annotation processing on partial builds can produce incorrect > META-INF/services files > --- > > Key: QPID-7321 > URL: https://issues.apache.org/jira/browse/QPID-7321 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Priority: Minor > Fix For: qpid-java-7.0 > > > The annotation processors which generate META-INF/services files work from > the list of classes passed to them by the compiler. In the case of partial > compilations (where only modified files are compiled) this can lead to the > services files containing only the modified classes rather than all the > available implementations. > Changes should be made to the annotation processor so that where there is an > existing services file we do not remove listings of classes that have not > been updated -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7321) [Java Broker] Annotation processing on partial builds can produce incorrect META-INF/services files
[ https://issues.apache.org/jira/browse/QPID-7321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7321: - Fix Version/s: qpid-java-7.0 > [Java Broker] Annotation processing on partial builds can produce incorrect > META-INF/services files > --- > > Key: QPID-7321 > URL: https://issues.apache.org/jira/browse/QPID-7321 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey > Fix For: qpid-java-7.0 > > > The annotation processors which generate META-INF/services files work from > the list of classes passed to them by the compiler. In the case of partial > compilations (where only modified files are compiled) this can lead to the > services files containing only the modified classes rather than all the > available implementations. > Changes should be made to the annotation processor so that where there is an > existing services file we do not remove listings of classes that have not > been updated -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7218) [Java Broker, WMC] Use queries to drive most parts of the WMC
[ https://issues.apache.org/jira/browse/QPID-7218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7218: - Fix Version/s: (was: qpid-java-7.0) Future > [Java Broker, WMC] Use queries to drive most parts of the WMC > - > > Key: QPID-7218 > URL: https://issues.apache.org/jira/browse/QPID-7218 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Lorenz Quack > Fix For: Future > > > Parts of the WMC can and should be driven by queries. > Amongst others, this has the advantage that queries support sorting and > pagination. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7212) [Java Broker, WMC] Transmit actual instead of effective context variables by default
[ https://issues.apache.org/jira/browse/QPID-7212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7212: - Fix Version/s: Future > [Java Broker, WMC] Transmit actual instead of effective context variables by > default > > > Key: QPID-7212 > URL: https://issues.apache.org/jira/browse/QPID-7212 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Lorenz Quack > Fix For: qpid-java-7.0 > > > Of course there needs to be a way to get the effective values as well. > This should be done in v7 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7315) Give sessions and consumers a descriptive name
[ https://issues.apache.org/jira/browse/QPID-7315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7315: - Fix Version/s: (was: Future) qpid-java-7.0 > Give sessions and consumers a descriptive name > -- > > Key: QPID-7315 > URL: https://issues.apache.org/jira/browse/QPID-7315 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall >Priority: Minor > Fix For: qpid-java-7.0 > > > Sessions and consumers are named internally by the Broker on creation with an > incrementing integer value scoped to the owning connection or session > respectively. The name is meaningless to the end-user. > Session names should embed the connection name, and Consumer names should > embed the Session name. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7316) WMC should permit the navigation from a consumer on a queue back to the connection
[ https://issues.apache.org/jira/browse/QPID-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7316: - Fix Version/s: (was: Future) qpid-java-7.0 > WMC should permit the navigation from a consumer on a queue back to the > connection > --- > > Key: QPID-7316 > URL: https://issues.apache.org/jira/browse/QPID-7316 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall > Fix For: qpid-java-7.0 > > > From the WMC, the operator should be able to navigate from the consumer > attached to the queue back to the connection that formed it. This will help > the operator better understand message flow within an application. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7296) Use connection property to determine if message delay (notValidBefore) is supported or not
[ https://issues.apache.org/jira/browse/QPID-7296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7296: - Priority: Minor (was: Major) > Use connection property to determine if message delay (notValidBefore) is > supported or not > -- > > Key: QPID-7296 > URL: https://issues.apache.org/jira/browse/QPID-7296 > Project: Qpid > Issue Type: Improvement > Components: Java Broker, Java Client >Reporter: Keith Wall >Priority: Minor > Fix For: Future > > > QPID-7255 introduced support of message delays. > Make the Broker provide a connection property that reveals that it supports > the notValidBefore feature. Make clients detect this feature and warn if the > application tries to make use of the address options. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7296) Use connection property to determine if message delay (notValidBefore) is supported or not
[ https://issues.apache.org/jira/browse/QPID-7296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7296: - Fix Version/s: (was: qpid-java-7.0) Future > Use connection property to determine if message delay (notValidBefore) is > supported or not > -- > > Key: QPID-7296 > URL: https://issues.apache.org/jira/browse/QPID-7296 > Project: Qpid > Issue Type: Improvement > Components: Java Broker, Java Client >Reporter: Keith Wall > Fix For: Future > > > QPID-7255 introduced support of message delays. > Make the Broker provide a connection property that reveals that it supports > the notValidBefore feature. Make clients detect this feature and warn if the > application tries to make use of the address options. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7295) [Java Broker] [0-10] duplicate SessionCompleted commands sent to client peer
[
https://issues.apache.org/jira/browse/QPID-7295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7295:
-
Fix Version/s: Future
> [Java Broker] [0-10] duplicate SessionCompleted commands sent to client peer
>
>
> Key: QPID-7295
> URL: https://issues.apache.org/jira/browse/QPID-7295
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.1
>Reporter: Keith Wall
>Priority: Minor
> Fix For: Future
>
>
> Running Hello against the Java Broker, I notice that the Java Broker sends
> duplicate {{SessionCompleted}} commands containing the same range-set. The
> Java Client seems to ignore the duplicate, but bandwidth is wasted all the
> same.
> Extract from the Broker log whilst running Hello. Notice two
> SessionCompleted(0,14) at the end of the log.
> {noformat}
> 2016-06-07 18:33:29,864 DEBUG [IO-/127.0.0.1:58682] (o.a.q.t.Connection) -
> RECV: [conn:63046a90] ch=0 SessionCompleted(commands=[0, 2])
> 2016-06-07 18:33:29,864 DEBUG [IO-/127.0.0.1:58682] (o.a.q.t.Session) -
> ssn:"ac0415af-bd52-44ea-9d8a-3501f3636bd8" complete(0, 2)
> 2016-06-07 18:33:29,864 DEBUG [IO-/127.0.0.1:58682] (o.a.q.t.Session) -
> ssn:"ac0415af-bd52-44ea-9d8a-3501f3636bd8" commands remaining: 1
> 2016-06-07 18:33:29,865 DEBUG [IO-/127.0.0.1:58682] (o.a.q.t.Connection) -
> RECV: [conn:63046a90] ch=0 MessageAccept(transfers=[2, 2])
> 2016-06-07 18:33:29,865 DEBUG [IO-/127.0.0.1:58682] (o.a.q.t.Session) -
> identify: ch=0, commandId=13
> 2016-06-07 18:33:29,867 DEBUG [IO-/127.0.0.1:58682]
> (o.a.q.s.s.d.DerbyMessageStore) - REMOVE called on message: 2
> 2016-06-07 18:33:29,867 DEBUG [IO-/127.0.0.1:58682] (o.a.q.t.Session) -
> ssn:"ac0415af-bd52-44ea-9d8a-3501f3636bd8" ch=0 processed([13,13]) 12 12
> 2016-06-07 18:33:29,867 DEBUG [IO-/127.0.0.1:58682] (o.a.q.t.Session) -
> ssn:"ac0415af-bd52-44ea-9d8a-3501f3636bd8" processed: {[0,
> 12]}
> 2016-06-07 18:33:29,868 DEBUG [IO-/127.0.0.1:58682]
> (o.a.q.s.t.NonBlockingConnection) - Read 18 byte(s)
> 2016-06-07 18:33:29,868 DEBUG [IO-/127.0.0.1:58682] (o.a.q.t.Connection) -
> RECV: [conn:63046a90] ch=0 [S] ExecutionSync()
> 2016-06-07 18:33:29,868 DEBUG [IO-/127.0.0.1:58682] (o.a.q.t.Session) -
> identify: ch=0, commandId=14
> 2016-06-07 18:33:29,868 DEBUG [IO-/127.0.0.1:58682] (o.a.q.t.Session) -
> ssn:"ac0415af-bd52-44ea-9d8a-3501f3636bd8" synced to 14
> 2016-06-07 18:33:29,868 DEBUG [IO-/127.0.0.1:58682] (o.a.q.t.Session) -
> ssn:"ac0415af-bd52-44ea-9d8a-3501f3636bd8" ch=0 processed([14,14]) 14 13
> 2016-06-07 18:33:29,868 DEBUG [IO-/127.0.0.1:58682] (o.a.q.t.Session) -
> ssn:"ac0415af-bd52-44ea-9d8a-3501f3636bd8" processed: {[0,
> 13]}
> 2016-06-07 18:33:29,868 DEBUG [IO-/127.0.0.1:58682] (o.a.q.t.Connection) -
> SEND: [conn:63046a90] ch=0 SessionCompleted(commands={[0,
> 14]})
> 2016-06-07 18:33:29,868 DEBUG [IO-/127.0.0.1:58682] (o.a.q.t.Connection) -
> FLUSH: [conn:63046a90]
> 2016-06-07 18:33:29,868 DEBUG [IO-/127.0.0.1:58682] (o.a.q.t.Connection) -
> SEND: [conn:63046a90] ch=0 SessionCompleted(commands={[0,
> 14]})
> 2016-06-07 18:33:29,868 DEBUG [IO-/127.0.0.1:58682] (o.a.q.t.Connection) -
> FLUSH: [conn:63046a90]
> 2016-06-07 18:33:29,868 DEBUG [IO-/127.0.0.1:58682]
> (o.a.q.s.t.NonBlockingConnection) - Written 52 bytes
> 2016-06-07 18:33:29,869 DEBUG [IO-/127.0.0.1:58682]
> (o.a.q.s.t.NonBlockingConnection) - Read 0 byte(s)
> 2016-06-07 18:33:29,871 DEBUG [IO-/127.0.0.1:58682]
> (o.a.q.s.t.NonBlockingConnection) - Read 74 byte(s)
> 2016-06-07 18:33:29,871 DEBUG [IO-/127.0.0.1:58682] (o.a.q.t.Connection) -
> RECV: [conn:63046a90] ch=0 SessionRequestTimeout(timeout=0)
> 2016-06-07 18:33:29,871 DEBUG [IO-/127.0.0.1:58682] (o.a.q.t.Connection) -
> SEND: [conn:63046a90] ch=0 SessionTimeout(timeout=0)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7212) [Java Broker, WMC] Transmit actual instead of effective context variables by default
[ https://issues.apache.org/jira/browse/QPID-7212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7212: - Fix Version/s: (was: Future) qpid-java-7.0 > [Java Broker, WMC] Transmit actual instead of effective context variables by > default > > > Key: QPID-7212 > URL: https://issues.apache.org/jira/browse/QPID-7212 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Lorenz Quack > Fix For: qpid-java-7.0 > > > Of course there needs to be a way to get the effective values as well. > This should be done in v7 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7200) Derived attributes should be capable of describing their domain of legal values
[ https://issues.apache.org/jira/browse/QPID-7200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7200: - Labels: Model (was: ) > Derived attributes should be capable of describing their domain of legal > values > --- > > Key: QPID-7200 > URL: https://issues.apache.org/jira/browse/QPID-7200 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall > Labels: Model > Fix For: Future > > > The metadata of the model should be enriched to include the domain of derived > attributes. For derived attributes that are of an enumerated type, this > information should be populated automatically, unless otherwise overridden. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7200) Derived attributes should be capable of describing their domain of legal values
[ https://issues.apache.org/jira/browse/QPID-7200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7200: - Fix Version/s: Future > Derived attributes should be capable of describing their domain of legal > values > --- > > Key: QPID-7200 > URL: https://issues.apache.org/jira/browse/QPID-7200 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall > Fix For: Future > > > The metadata of the model should be enriched to include the domain of derived > attributes. For derived attributes that are of an enumerated type, this > information should be populated automatically, unless otherwise overridden. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7172) HTTP Management threads are blocked by potentially long running operations
[ https://issues.apache.org/jira/browse/QPID-7172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7172: - Fix Version/s: Future > HTTP Management threads are blocked by potentially long running operations > -- > > Key: QPID-7172 > URL: https://issues.apache.org/jira/browse/QPID-7172 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Keith Wall > Fix For: Future > > > As an operator of the Broker using the Web Management Console, I can initiate > operations such as purge queue. These operations may be long running. > When issuing a long running operation the user ought to get visual feedback > that it is in progress. Later the user should be able to return and find out > if the task is finished and get the result. > Currently the operator may believe that the operation is 'stuck', and try the > operation again, or get a colleague to do the same. > Internally within the Java Broker, the web thread is blocked awaiting the > operation on the configuration thread. If many such operations are in flight > (or the operator retries an operation in belief it is stuck), the web tier > may become slow or unresponsive. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7164) Python test qpid_tests.broker_0_10.new_api.GeneralTests.test_qpid_3481_acquired_to_alt_exchange fails against Java Broker
[
https://issues.apache.org/jira/browse/QPID-7164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7164:
-
Fix Version/s: Future
> Python test
> qpid_tests.broker_0_10.new_api.GeneralTests.test_qpid_3481_acquired_to_alt_exchange
> fails against Java Broker
> -
>
> Key: QPID-7164
> URL: https://issues.apache.org/jira/browse/QPID-7164
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker, Python Test Suite
>Reporter: Keith Wall
> Fix For: Future
>
>
> The following Python test is currently failing against the Java Broker.
> This is related to the routing of messages to the alternate exchanges.
> {noformat}
> Error during test: Traceback (most recent call last):
> File "qpid-python-test", line 340, in run
> phase()
> File
> "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/trunk/qpid/tests/src/py/qpid_tests/broker_0_10/new_api.py",
> line 85, in test_qpid_3481_acquired_to_alt_exchange
> self.assertEqual(rx_alt.available(), 5, "All 5 messages should have
> been routed to the alt_exchange")
> File
> "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/trunk/qpid/tests/src/py/qpid_tests/broker_0_10/new_api.py",
> line 39, in assertEqual
> assert None
> AssertionError
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7141) [Java Broker] Make sure all data in the ApiDocs are correctly escaped/encoded
[ https://issues.apache.org/jira/browse/QPID-7141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7141: - Fix Version/s: qpid-java-7.0 > [Java Broker] Make sure all data in the ApiDocs are correctly escaped/encoded > - > > Key: QPID-7141 > URL: https://issues.apache.org/jira/browse/QPID-7141 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Lorenz Quack > Fix For: qpid-java-7.0 > > > The content of the /apidocs html page is derived from the broker which is not > aware of html semantics. > We have to make sure the strings coming from the broker are correctly encoded > before putting them in the HTML DOM. > OWASP has some information about correct escaping/encoding for different > scenarios: > https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7141) [Java Broker] Make sure all data in the ApiDocs are correctly escaped/encoded
[ https://issues.apache.org/jira/browse/QPID-7141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7141: - Priority: Minor (was: Major) > [Java Broker] Make sure all data in the ApiDocs are correctly escaped/encoded > - > > Key: QPID-7141 > URL: https://issues.apache.org/jira/browse/QPID-7141 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Lorenz Quack >Priority: Minor > Fix For: qpid-java-7.0 > > > The content of the /apidocs html page is derived from the broker which is not > aware of html semantics. > We have to make sure the strings coming from the broker are correctly encoded > before putting them in the HTML DOM. > OWASP has some information about correct escaping/encoding for different > scenarios: > https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7140) [Java Broker] Add the ability to auto generate documentation from metadata for REST services other than operations on configured objects
[ https://issues.apache.org/jira/browse/QPID-7140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7140: - Fix Version/s: Future > [Java Broker] Add the ability to auto generate documentation from metadata > for REST services other than operations on configured objects > > > Key: QPID-7140 > URL: https://issues.apache.org/jira/browse/QPID-7140 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey > Fix For: Future > > > Currently we generate documentation from the meta data associated with > configured objects - however the broker also offers other services (such as > the query servlet) which should include documentation. > We need to introduce a way to add documentation for these services into the > the code and to present this through our API docs. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7138) [Java Broker] Broker should detect duplicate IDs in configured objects
[ https://issues.apache.org/jira/browse/QPID-7138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7138: - Priority: Minor (was: Major) > [Java Broker] Broker should detect duplicate IDs in configured objects > -- > > Key: QPID-7138 > URL: https://issues.apache.org/jira/browse/QPID-7138 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Affects Versions: 0.28, 0.30, 0.32, qpid-java-6.0, qpid-java-6.0.1 >Reporter: Alex Rudyy >Priority: Minor > Fix For: qpid-java-7.0 > > > Currently UUID uniqueness is enforced only amongst immediate siblings. This > means that, say, a virtual host with queue with UUID A would reject a second > queue with the same UUID A. Currently if a second virtual host had a queue > with same UUID A, this would be allowed. This presents a problem for clients > (including the Web Management Console) that expect UUID to be universally > unique. > Change ACO so that object UUID are universally so.The validatation would > need to be applied as new objects are created, as the Broker starts up and as > Virtualhosts are recovered. This latter may or may not be at start-up time. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7104) [Java Broker] Creating multiple state transition methods on a ConfiguredObject should cause an error
[ https://issues.apache.org/jira/browse/QPID-7104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7104: - Priority: Minor (was: Major) > [Java Broker] Creating multiple state transition methods on a > ConfiguredObject should cause an error > > > Key: QPID-7104 > URL: https://issues.apache.org/jira/browse/QPID-7104 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: 0.32, qpid-java-6.0 >Reporter: Lorenz Quack >Priority: Minor > Fix For: qpid-java-7.0 > > > Currently nothing prevents one from annotating several methods with the same > @StateTransition. However, the behaviour is not well defined. > Ideally, we would catch this during compile-time. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7099) [Java Broker] Generate standalone static copy of the REST API docs
[ https://issues.apache.org/jira/browse/QPID-7099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7099: - Fix Version/s: Future > [Java Broker] Generate standalone static copy of the REST API docs > -- > > Key: QPID-7099 > URL: https://issues.apache.org/jira/browse/QPID-7099 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey > Fix For: Future > > > Currently api docs for the REST API are generated dynamically by a servlet in > the broker. It would be helpful to be able to also produce these as static > content that can be presented on the Qpid web site. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7576) Metadata loaded twice for recovered message
[
https://issues.apache.org/jira/browse/QPID-7576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15798522#comment-15798522
]
Alex Rudyy commented on QPID-7576:
--
Lorenz,
I reviewed the changes committed under revision
[r1775480|https://svn.apache.org/r1775480] and here are my review comments:
* {{AbstractServerMessageImpl}}; It appears that after implemented changes
field _handle cannot be null. IMHO, it make sense to add an explicit check into
constructor for {{AbstractServerMessageImpl}} to validate that handle is not
null and throw {{ServerScopeRuntimeException}} if it is the case. The comments
at lines 112-113 seem redundant. The null check is redundant as well.
* Taking that method {{getContentSize()}} is added into {{StoredMessage}}, it
would make sense to call it instead of
{{StoredMessage.getMetaData().getContentSize()}} where appropriate. I attached
a patch with the suggested changes
(0001-QPID-7576-Call-StoredMessage-getContentSize-where-ap.patch).
* {{AbstractConsumerTarget}}; The change made in send method look good but it
seems that returned value is never used. I am wondering whether we really need
to return the value from this method. If signature of method in
{{ConsumerTarget}} is changed to return void, the implemented change in
{{AbstractConsumerTarget#send}} would not be necessary.
> Metadata loaded twice for recovered message
> ---
>
> Key: QPID-7576
> URL: https://issues.apache.org/jira/browse/QPID-7576
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-7.0
>Reporter: Keith Wall
> Fix For: qpid-java-7.0
>
> Attachments:
> 0001-QPID-7576-Call-StoredMessage-getContentSize-where-ap.patch,
> 0001-QPID-7576-Java-Broker-Avoid-double-loading-of-metada.patch
>
>
> For recovered messages (and possibly messages that have been flown to disk),
> the metadata is evacuated from memory unnecessarily and then immediately
> reloaded.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7098) [Java Broker] Improve the presentation of the Broker API docs
[ https://issues.apache.org/jira/browse/QPID-7098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7098: - Fix Version/s: Future > [Java Broker] Improve the presentation of the Broker API docs > - > > Key: QPID-7098 > URL: https://issues.apache.org/jira/browse/QPID-7098 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey > Fix For: Future > > > The api docs are generated by servlets within the broker, their presentation > leaves something to be desired. > Potentially the servlet should also respect the accept type of the client to > allow for generation of docs in HTML or in JSON or other forms. For HTML > forms the presentation should potentially be separated out into css -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-6931) [Java Broker] Harden the use of Jetty against DoS attacks
[ https://issues.apache.org/jira/browse/QPID-6931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15798517#comment-15798517 ] Keith Wall commented on QPID-6931: -- We will want to upgrade the version of Jetty used before spending time on this JIRA. > [Java Broker] Harden the use of Jetty against DoS attacks > - > > Key: QPID-6931 > URL: https://issues.apache.org/jira/browse/QPID-6931 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Lorenz Quack > Fix For: Future > > > Currently Jetty seems open to potential Denial of Service (DoS) attacks. > According to [this email > thread|https://dev.eclipse.org/mhonarc/lists/jetty-users/msg04338.html] on > the jetty user mailing list our current approach of limiting the number of > jetty thread and number of connections is not sufficient and it is suggested > to use the [QoS > Filter|http://www.eclipse.org/jetty/documentation/current/qos-filter.html] > instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-6931) [Java Broker] Harden the use of Jetty against DoS attacks
[ https://issues.apache.org/jira/browse/QPID-6931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-6931: - Fix Version/s: Future > [Java Broker] Harden the use of Jetty against DoS attacks > - > > Key: QPID-6931 > URL: https://issues.apache.org/jira/browse/QPID-6931 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Lorenz Quack > Fix For: Future > > > Currently Jetty seems open to potential Denial of Service (DoS) attacks. > According to [this email > thread|https://dev.eclipse.org/mhonarc/lists/jetty-users/msg04338.html] on > the jetty user mailing list our current approach of limiting the number of > jetty thread and number of connections is not sufficient and it is suggested > to use the [QoS > Filter|http://www.eclipse.org/jetty/documentation/current/qos-filter.html] > instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7605) [Java Broker] [AMQP1.0] Container id uniqueness
[ https://issues.apache.org/jira/browse/QPID-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15798509#comment-15798509 ] Rob Godfrey commented on QPID-7605: --- This is probably not a discussion to be having in the comments section of this JIRA... but I wonder if we should say something like the "in the case that the peer cannot successfully establish a connection preconditions implied by the open frame it received, it should send its own open with the container-id set to the zero length string, and a symbol keyed boolean property of "amqp:connection-establishment-failed" with value true" the empty container id would be somewhat analogous to the null source > [Java Broker] [AMQP1.0] Container id uniqueness > --- > > Key: QPID-7605 > URL: https://issues.apache.org/jira/browse/QPID-7605 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall > Fix For: qpid-java-7.0 > > > The AMQP 1.0 protocol layer implementation must ensure that the AMQP Open > performative container-id is unique amongst existing established connections. > As the JMS client id maps to the container-id, so this will fulfil the JMS > requirement. > https://docs.oracle.com/javaee/7/api/javax/jms/Connection.html#setClientID-java.lang.String- > Note that the Qpid JMS Client requires the Close performative with an Error > containing a hint to generate to correct JMS exception. How will the Qpid > Broker know to do this? > org.apache.qpid.jms.integration.FailedConnectionsIntegrationTest#testConnectWithInvalidClientIdThrowsICIDEWhenInvalidContainerHintPresent -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7576) Metadata loaded twice for recovered message
[ https://issues.apache.org/jira/browse/QPID-7576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7576: - Attachment: 0001-QPID-7576-Call-StoredMessage-getContentSize-where-ap.patch > Metadata loaded twice for recovered message > --- > > Key: QPID-7576 > URL: https://issues.apache.org/jira/browse/QPID-7576 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-7.0 >Reporter: Keith Wall > Fix For: qpid-java-7.0 > > Attachments: > 0001-QPID-7576-Call-StoredMessage-getContentSize-where-ap.patch, > 0001-QPID-7576-Java-Broker-Avoid-double-loading-of-metada.patch > > > For recovered messages (and possibly messages that have been flown to disk), > the metadata is evacuated from memory unnecessarily and then immediately > reloaded. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7471) [Java Broker] MessageConverter should respect mimeType
[ https://issues.apache.org/jira/browse/QPID-7471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7471: - Fix Version/s: (was: qpid-java-6.1) > [Java Broker] MessageConverter should respect mimeType > -- > > Key: QPID-7471 > URL: https://issues.apache.org/jira/browse/QPID-7471 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Lorenz Quack >Assignee: Keith Wall > Fix For: qpid-java-7.0 > > > When converting from ManageableMessage to InternalMessage the mimeType gets > lost -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7462) [Java Broker] Add experimental "pull" consumers to the broker
[ https://issues.apache.org/jira/browse/QPID-7462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7462: - Fix Version/s: (was: qpid-java-7.0) > [Java Broker] Add experimental "pull" consumers to the broker > - > > Key: QPID-7462 > URL: https://issues.apache.org/jira/browse/QPID-7462 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Keith Wall > Fix For: qpid-java-6.1 > > Attachments: QPID-7462.patch, QPID-7462_6.0.x_updated.patch > > > As per > [this|http://qpid.2158936.n2.nabble.com/Qpid-broker-6-0-4-performance-issues-tp7652036.html] > thread on the users list, our eventual goal is the elimination of the queue > runners and moving to a model where the connection threads pull messages from > the queues. In particular this allows multi-queue consumers to act in a > "fair" manner between the multiple queues the consumer is associated with -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7478) Add managed operation to reset statistics
[ https://issues.apache.org/jira/browse/QPID-7478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7478: - Fix Version/s: (was: qpid-java-7.0) > Add managed operation to reset statistics > - > > Key: QPID-7478 > URL: https://issues.apache.org/jira/browse/QPID-7478 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall >Assignee: Keith Wall >Priority: Minor > Fix For: qpid-java-6.1 > > > As an operator, until the removal of the JMX management interface, I could > reset the statistics of the Broker, or Virtualhost. With the removal of the > JMX management interface this ability has been lost. > Implement resetStatistics as a ManagedOperation instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7479) [Java Broker] Memory estimation formula fails to account for objects that comprise a persistent messages
[ https://issues.apache.org/jira/browse/QPID-7479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7479: - Fix Version/s: (was: qpid-java-7.0) > [Java Broker] Memory estimation formula fails to account for objects that > comprise a persistent messages > > > Key: QPID-7479 > URL: https://issues.apache.org/jira/browse/QPID-7479 > Project: Qpid > Issue Type: Bug > Components: Documentation, Java Broker >Reporter: Keith Wall >Assignee: Keith Wall > Fix For: qpid-java-6.1 > > > Memory estimation formula fails to account for objects that comprise a > persistent messages. It should also assume a TLS message, as TLS messages > use an additional buffer for the application data. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-3953) [Java AMQP 1.0] When unsubscribing a durable subscription, it should be resumed with durability NONE, expiry LINK_DETACH
[ https://issues.apache.org/jira/browse/QPID-3953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15798465#comment-15798465 ] Robbie Gemmell commented on QPID-3953: -- Is there is anything to actually do here? The old JMS client tweaked the linked durability and expiry while unsubscribing, but since then we've taken to simply reattaching and then closing the link. > [Java AMQP 1.0] When unsubscribing a durable subscription, it should be > resumed with durability NONE, expiry LINK_DETACH > > > Key: QPID-3953 > URL: https://issues.apache.org/jira/browse/QPID-3953 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: 0.17 >Reporter: Rob Godfrey >Priority: Minor > Fix For: qpid-java-7.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7588) [Python Client 0-8..0-91] The received message ocasionally might not be dispatched into the application queue in timely manner
[
https://issues.apache.org/jira/browse/QPID-7588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell resolved QPID-7588.
--
Resolution: Fixed
> [Python Client 0-8..0-91] The received message ocasionally might not be
> dispatched into the application queue in timely manner
> --
>
> Key: QPID-7588
> URL: https://issues.apache.org/jira/browse/QPID-7588
> Project: Qpid
> Issue Type: Bug
> Components: Python Test Suite
>Affects Versions: qpid-python-1.35.0
>Reporter: Alex Rudyy
>Assignee: Keith Wall
> Fix For: qpid-python-1.36.0
>
> Attachments:
> qpid_tests.broker_0_9.echo.EchoTests.test_largest_single_frame_message.broker.log,
> qpid_tests.broker_0_9.echo.EchoTests.test_largest_single_frame_message.log
>
>
> The python test
> {{qpid_tests.broker_0_9.echo.EchoTests.test_largest_single_frame_message}}
> for 0.9 AMQP protocol fails occasionally with the following stack trace:
> {noformat}
> qpid_tests.broker_0_9.echo.EchoTests.test_largest_single_frame_message (from
> (TEST-python_pre1.0.xml))
> Failing for the past 1 build (Since Failed#1256 )
> Took 14 sec.
> Stacktrace
> Error during test: Traceback (most recent call last):
> File
> "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/site-packages/bin/qpid-python-test",
> line 340, in run
> phase()
> File
> "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/site-packages/lib/python2.7/site-packages/qpid_tests/broker_0_9/echo.py",
> line 45, in test_largest_single_frame_message
> self.echo_message(body)
> File
> "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/site-packages/lib/python2.7/site-packages/qpid_tests/broker_0_9/echo.py",
> line 61, in echo_message
> msg = consumer.get(timeout=1)
> File
> "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/site-packages/lib/python2.7/site-packages/qpid/queue.py",
> line 51, in get
> result = BaseQueue.get(self, block, timeout)
> File "/usr/lib/python2.7/Queue.py", line 176, in get
> raise Empty
> Empty
> {noformat}
> The client and broker logs have records of the message being received by the
> client in timely manner (It took 3millisecond to deliver the message).
> However, the received message was not put into the client queue and test
> failed.
> It is unclear at the moment whether it is an issue with threads or a bug in
> client code. More investigation is required.
> The issue might cause sporadic timeouts in applications using 0.8...0.91
> python API.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7588) [Python Client 0-8..0-91] The received message ocasionally might not be dispatched into the application queue in timely manner
[
https://issues.apache.org/jira/browse/QPID-7588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated QPID-7588:
-
Fix Version/s: (was: qpid-cpp-1.35.1)
qpid-python-1.36.0
Updating fix-version .
> [Python Client 0-8..0-91] The received message ocasionally might not be
> dispatched into the application queue in timely manner
> --
>
> Key: QPID-7588
> URL: https://issues.apache.org/jira/browse/QPID-7588
> Project: Qpid
> Issue Type: Bug
> Components: Python Test Suite
>Affects Versions: qpid-python-1.35.0
>Reporter: Alex Rudyy
>Assignee: Keith Wall
> Fix For: qpid-python-1.36.0
>
> Attachments:
> qpid_tests.broker_0_9.echo.EchoTests.test_largest_single_frame_message.broker.log,
> qpid_tests.broker_0_9.echo.EchoTests.test_largest_single_frame_message.log
>
>
> The python test
> {{qpid_tests.broker_0_9.echo.EchoTests.test_largest_single_frame_message}}
> for 0.9 AMQP protocol fails occasionally with the following stack trace:
> {noformat}
> qpid_tests.broker_0_9.echo.EchoTests.test_largest_single_frame_message (from
> (TEST-python_pre1.0.xml))
> Failing for the past 1 build (Since Failed#1256 )
> Took 14 sec.
> Stacktrace
> Error during test: Traceback (most recent call last):
> File
> "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/site-packages/bin/qpid-python-test",
> line 340, in run
> phase()
> File
> "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/site-packages/lib/python2.7/site-packages/qpid_tests/broker_0_9/echo.py",
> line 45, in test_largest_single_frame_message
> self.echo_message(body)
> File
> "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/site-packages/lib/python2.7/site-packages/qpid_tests/broker_0_9/echo.py",
> line 61, in echo_message
> msg = consumer.get(timeout=1)
> File
> "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/site-packages/lib/python2.7/site-packages/qpid/queue.py",
> line 51, in get
> result = BaseQueue.get(self, block, timeout)
> File "/usr/lib/python2.7/Queue.py", line 176, in get
> raise Empty
> Empty
> {noformat}
> The client and broker logs have records of the message being received by the
> client in timely manner (It took 3millisecond to deliver the message).
> However, the received message was not put into the client queue and test
> failed.
> It is unclear at the moment whether it is an issue with threads or a bug in
> client code. More investigation is required.
> The issue might cause sporadic timeouts in applications using 0.8...0.91
> python API.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7605) [Java Broker] [AMQP1.0] Container id uniqueness
[ https://issues.apache.org/jira/browse/QPID-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15798421#comment-15798421 ] Robbie Gemmell commented on QPID-7605: -- What we are doing for the JMS mapping is for the client to send a 'sole-connection-for-container' connection capability to request that the broker/peer grant exclusive use of the container-id (which would be the ClientID) to the connection, or fail the Open if it cant because another is already using it. The broker signals it is honouring the request by supporting the same capability in its reply Open frame. If the broker fails the connection attempt, it should add an entry to the Close error info map to hint that the container-id was the cause, allowing the client to throw InvalidClientIDException specifically, by adding an symbol key/value of "invalid-field"/"container-id". We also specified it should add a symbol keyed boolean property of "amqp:connection-establishment-failed" as a hint that the Open has failed and a Close will be following immediately with the reason (since the spec has no way to convey that scenario, unlike with Attach/Detach where it does by leaving the source/target as null) > [Java Broker] [AMQP1.0] Container id uniqueness > --- > > Key: QPID-7605 > URL: https://issues.apache.org/jira/browse/QPID-7605 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall > Fix For: qpid-java-7.0 > > > The AMQP 1.0 protocol layer implementation must ensure that the AMQP Open > performative container-id is unique amongst existing established connections. > As the JMS client id maps to the container-id, so this will fulfil the JMS > requirement. > https://docs.oracle.com/javaee/7/api/javax/jms/Connection.html#setClientID-java.lang.String- > Note that the Qpid JMS Client requires the Close performative with an Error > containing a hint to generate to correct JMS exception. How will the Qpid > Broker know to do this? > org.apache.qpid.jms.integration.FailedConnectionsIntegrationTest#testConnectWithInvalidClientIdThrowsICIDEWhenInvalidContainerHintPresent -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Reopened] (QPID-7588) [Python Client 0-8..0-91] The received message ocasionally might not be dispatched into the application queue in timely manner
[
https://issues.apache.org/jira/browse/QPID-7588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell reopened QPID-7588:
--
> [Python Client 0-8..0-91] The received message ocasionally might not be
> dispatched into the application queue in timely manner
> --
>
> Key: QPID-7588
> URL: https://issues.apache.org/jira/browse/QPID-7588
> Project: Qpid
> Issue Type: Bug
> Components: Python Test Suite
>Affects Versions: qpid-python-1.35.0
>Reporter: Alex Rudyy
>Assignee: Keith Wall
> Fix For: qpid-cpp-1.35.1
>
> Attachments:
> qpid_tests.broker_0_9.echo.EchoTests.test_largest_single_frame_message.broker.log,
> qpid_tests.broker_0_9.echo.EchoTests.test_largest_single_frame_message.log
>
>
> The python test
> {{qpid_tests.broker_0_9.echo.EchoTests.test_largest_single_frame_message}}
> for 0.9 AMQP protocol fails occasionally with the following stack trace:
> {noformat}
> qpid_tests.broker_0_9.echo.EchoTests.test_largest_single_frame_message (from
> (TEST-python_pre1.0.xml))
> Failing for the past 1 build (Since Failed#1256 )
> Took 14 sec.
> Stacktrace
> Error during test: Traceback (most recent call last):
> File
> "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/site-packages/bin/qpid-python-test",
> line 340, in run
> phase()
> File
> "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/site-packages/lib/python2.7/site-packages/qpid_tests/broker_0_9/echo.py",
> line 45, in test_largest_single_frame_message
> self.echo_message(body)
> File
> "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/site-packages/lib/python2.7/site-packages/qpid_tests/broker_0_9/echo.py",
> line 61, in echo_message
> msg = consumer.get(timeout=1)
> File
> "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/site-packages/lib/python2.7/site-packages/qpid/queue.py",
> line 51, in get
> result = BaseQueue.get(self, block, timeout)
> File "/usr/lib/python2.7/Queue.py", line 176, in get
> raise Empty
> Empty
> {noformat}
> The client and broker logs have records of the message being received by the
> client in timely manner (It took 3millisecond to deliver the message).
> However, the received message was not put into the client queue and test
> failed.
> It is unclear at the moment whether it is an issue with threads or a bug in
> client code. More investigation is required.
> The issue might cause sporadic timeouts in applications using 0.8...0.91
> python API.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7588) [Python Client 0-8..0-91] The received message ocasionally might not be dispatched into the application queue in timely manner
[
https://issues.apache.org/jira/browse/QPID-7588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack resolved QPID-7588.
Resolution: Fixed
looks good to me
> [Python Client 0-8..0-91] The received message ocasionally might not be
> dispatched into the application queue in timely manner
> --
>
> Key: QPID-7588
> URL: https://issues.apache.org/jira/browse/QPID-7588
> Project: Qpid
> Issue Type: Bug
> Components: Python Test Suite
>Affects Versions: qpid-python-1.35.0
>Reporter: Alex Rudyy
>Assignee: Keith Wall
> Attachments:
> qpid_tests.broker_0_9.echo.EchoTests.test_largest_single_frame_message.broker.log,
> qpid_tests.broker_0_9.echo.EchoTests.test_largest_single_frame_message.log
>
>
> The python test
> {{qpid_tests.broker_0_9.echo.EchoTests.test_largest_single_frame_message}}
> for 0.9 AMQP protocol fails occasionally with the following stack trace:
> {noformat}
> qpid_tests.broker_0_9.echo.EchoTests.test_largest_single_frame_message (from
> (TEST-python_pre1.0.xml))
> Failing for the past 1 build (Since Failed#1256 )
> Took 14 sec.
> Stacktrace
> Error during test: Traceback (most recent call last):
> File
> "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/site-packages/bin/qpid-python-test",
> line 340, in run
> phase()
> File
> "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/site-packages/lib/python2.7/site-packages/qpid_tests/broker_0_9/echo.py",
> line 45, in test_largest_single_frame_message
> self.echo_message(body)
> File
> "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/site-packages/lib/python2.7/site-packages/qpid_tests/broker_0_9/echo.py",
> line 61, in echo_message
> msg = consumer.get(timeout=1)
> File
> "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/site-packages/lib/python2.7/site-packages/qpid/queue.py",
> line 51, in get
> result = BaseQueue.get(self, block, timeout)
> File "/usr/lib/python2.7/Queue.py", line 176, in get
> raise Empty
> Empty
> {noformat}
> The client and broker logs have records of the message being received by the
> client in timely manner (It took 3millisecond to deliver the message).
> However, the received message was not put into the client queue and test
> failed.
> It is unclear at the moment whether it is an issue with threads or a bug in
> client code. More investigation is required.
> The issue might cause sporadic timeouts in applications using 0.8...0.91
> python API.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7467) [Java Broker, WMC] Expose the option TrustStore#in-/excludedVirtualHostNodeMessageSources
[
https://issues.apache.org/jira/browse/QPID-7467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7467:
-
Fix Version/s: qpid-java-7.0
> [Java Broker, WMC] Expose the option
> TrustStore#in-/excludedVirtualHostNodeMessageSources
> -
>
> Key: QPID-7467
> URL: https://issues.apache.org/jira/browse/QPID-7467
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Affects Versions: qpid-java-6.1
>Reporter: Lorenz Quack
> Fix For: qpid-java-7.0
>
>
> Currently, the {{exposedAsMessageSource}} flag on {{TrustStore}} is not
> exposed through the Web Management Console (WMC) making it impossible to
> configure end-to-end encryption solely through the WMC.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7442) Deleting a virtualhost leaves itself and the children in the configuration store
[
https://issues.apache.org/jira/browse/QPID-7442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7442:
-
Priority: Minor (was: Major)
> Deleting a virtualhost leaves itself and the children in the configuration
> store
>
>
> Key: QPID-7442
> URL: https://issues.apache.org/jira/browse/QPID-7442
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-7.0
>
>
> If I create a BDB virtualhostnode (for example) with a ProvidedStore, then
> delete the VH the configuration entries corresponding to the VH are left
> behind in the store.
> * If I immediately restart the Broker, the deleted VH reappears.
> * If I create a new virtualhost in its place (using REST), the creation is
> seemingly successful, but on restart the virtuallhostnode goes into ERROR
> state.
> {noformat}
> 2016-09-29 23:16:27,105 INFO [Broker-Config] (q.m.c.recovery_start) -
> [Broker] [vh(/mybdb)/ms(BDBConfigurationStore)] CFG-1004 : Recovery Start
> 2016-09-29 23:16:27,121 INFO [Broker-Config]
> (o.a.q.s.s.GenericStoreUpgrader) - VirtualHost store has model version 6.1.
> Number of record(s) 10
> 2016-09-29 23:16:27,126 INFO [Broker-Config] (q.m.v.created) - [Broker]
> VHT-1001 : Created : mybdb
> 2016-09-29 23:16:27,129 INFO [Broker-Config] (q.m.v.created) - [Broker]
> VHT-1001 : Created : mybdb
> 2016-09-29 23:16:27,133 ERROR [Broker-Config]
> (o.a.q.s.m.AbstractConfiguredObject) - Failed to open object with name
> 'mybdb'. Object will be put into ERROR state.
> org.apache.qpid.server.model.AbstractConfiguredObject$DuplicateNameException:
> Child of type ProvidedStoreVirtualHostImplWithAccessChecking already exists
> with name of mybdb
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.registerChild(AbstractConfiguredObject.java:2129)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.registerWithParents(AbstractConfiguredObject.java:684)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObjectTypeFactory$GenericUnresolvedConfiguredObject.resolve(AbstractConfiguredObjectTypeFactory.java:139)
> ~[classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObjectTypeFactory$GenericUnresolvedConfiguredObject.resolve(AbstractConfiguredObjectTypeFactory.java:118)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer.resolveObjects(GenericRecoverer.java:188)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer.performRecover(GenericRecoverer.java:91)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer.access$000(GenericRecoverer.java:41)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer$1.execute(GenericRecoverer.java:59)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer$1.execute(GenericRecoverer.java:55)
> ~[classes/:na]
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:240)
> [classes/:na]
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submitWrappedTask(TaskExecutorImpl.java:157)
> [classes/:na]
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.run(TaskExecutorImpl.java:182)
> [classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer.recover(GenericRecoverer.java:54)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.VirtualHostStoreUpgraderAndRecoverer.recover(VirtualHostStoreUpgraderAndRecoverer.java:615)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.VirtualHostStoreUpgraderAndRecoverer.upgradeAndRecover(VirtualHostStoreUpgraderAndRecoverer.java:594)
> ~[classes/:na]
> at
> org.apache.qpid.server.virtualhostnode.AbstractStandardVirtualHostNode.activate(AbstractStandardVirtualHostNode.java:102)
> ~[classes/:na]
> at
> org.apache.qpid.server.virtualhostnode.AbstractVirtualHostNode.doActivate(AbstractVirtualHostNode.java:167)
> ~[classes/:na]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[na:1.8.0_101]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[na:1.8.0_101]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[na:1.8.0_101]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_101]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1482)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1461)
> [classes/:na]
[jira] [Updated] (QPID-7442) Deleting a virtualhost leaves itself and the children in the configuration store
[
https://issues.apache.org/jira/browse/QPID-7442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7442:
-
Fix Version/s: (was: Future)
qpid-java-7.0
> Deleting a virtualhost leaves itself and the children in the configuration
> store
>
>
> Key: QPID-7442
> URL: https://issues.apache.org/jira/browse/QPID-7442
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-7.0
>
>
> If I create a BDB virtualhostnode (for example) with a ProvidedStore, then
> delete the VH the configuration entries corresponding to the VH are left
> behind in the store.
> * If I immediately restart the Broker, the deleted VH reappears.
> * If I create a new virtualhost in its place (using REST), the creation is
> seemingly successful, but on restart the virtuallhostnode goes into ERROR
> state.
> {noformat}
> 2016-09-29 23:16:27,105 INFO [Broker-Config] (q.m.c.recovery_start) -
> [Broker] [vh(/mybdb)/ms(BDBConfigurationStore)] CFG-1004 : Recovery Start
> 2016-09-29 23:16:27,121 INFO [Broker-Config]
> (o.a.q.s.s.GenericStoreUpgrader) - VirtualHost store has model version 6.1.
> Number of record(s) 10
> 2016-09-29 23:16:27,126 INFO [Broker-Config] (q.m.v.created) - [Broker]
> VHT-1001 : Created : mybdb
> 2016-09-29 23:16:27,129 INFO [Broker-Config] (q.m.v.created) - [Broker]
> VHT-1001 : Created : mybdb
> 2016-09-29 23:16:27,133 ERROR [Broker-Config]
> (o.a.q.s.m.AbstractConfiguredObject) - Failed to open object with name
> 'mybdb'. Object will be put into ERROR state.
> org.apache.qpid.server.model.AbstractConfiguredObject$DuplicateNameException:
> Child of type ProvidedStoreVirtualHostImplWithAccessChecking already exists
> with name of mybdb
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.registerChild(AbstractConfiguredObject.java:2129)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.registerWithParents(AbstractConfiguredObject.java:684)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObjectTypeFactory$GenericUnresolvedConfiguredObject.resolve(AbstractConfiguredObjectTypeFactory.java:139)
> ~[classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObjectTypeFactory$GenericUnresolvedConfiguredObject.resolve(AbstractConfiguredObjectTypeFactory.java:118)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer.resolveObjects(GenericRecoverer.java:188)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer.performRecover(GenericRecoverer.java:91)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer.access$000(GenericRecoverer.java:41)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer$1.execute(GenericRecoverer.java:59)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer$1.execute(GenericRecoverer.java:55)
> ~[classes/:na]
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:240)
> [classes/:na]
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submitWrappedTask(TaskExecutorImpl.java:157)
> [classes/:na]
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.run(TaskExecutorImpl.java:182)
> [classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer.recover(GenericRecoverer.java:54)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.VirtualHostStoreUpgraderAndRecoverer.recover(VirtualHostStoreUpgraderAndRecoverer.java:615)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.VirtualHostStoreUpgraderAndRecoverer.upgradeAndRecover(VirtualHostStoreUpgraderAndRecoverer.java:594)
> ~[classes/:na]
> at
> org.apache.qpid.server.virtualhostnode.AbstractStandardVirtualHostNode.activate(AbstractStandardVirtualHostNode.java:102)
> ~[classes/:na]
> at
> org.apache.qpid.server.virtualhostnode.AbstractVirtualHostNode.doActivate(AbstractVirtualHostNode.java:167)
> ~[classes/:na]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[na:1.8.0_101]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[na:1.8.0_101]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[na:1.8.0_101]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_101]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1482)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfigur
[jira] [Updated] (QPID-7467) [Java Broker, WMC] Expose the option TrustStore#in-/excludedVirtualHostNodeMessageSources
[
https://issues.apache.org/jira/browse/QPID-7467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7467:
-
Priority: Minor (was: Major)
> [Java Broker, WMC] Expose the option
> TrustStore#in-/excludedVirtualHostNodeMessageSources
> -
>
> Key: QPID-7467
> URL: https://issues.apache.org/jira/browse/QPID-7467
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Affects Versions: qpid-java-6.1
>Reporter: Lorenz Quack
>Priority: Minor
> Fix For: qpid-java-7.0
>
>
> Currently, the {{exposedAsMessageSource}} flag on {{TrustStore}} is not
> exposed through the Web Management Console (WMC) making it impossible to
> configure end-to-end encryption solely through the WMC.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
