[jira] [Commented] (QPID-7546) [Java Broker] Allow the system tests to be run using the Qpid JMS client for AMQP 1.0 testing
[ https://issues.apache.org/jira/browse/QPID-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15837413#comment-15837413 ] ASF subversion and git services commented on QPID-7546: --- Commit 1780153 from [~k-wall] in branch 'java/trunk' [ https://svn.apache.org/r1780153 ] QPID-7546: [System Tests] Reclassify some excluded failures > [Java Broker] Allow the system tests to be run using the Qpid JMS client for > AMQP 1.0 testing > - > > Key: QPID-7546 > URL: https://issues.apache.org/jira/browse/QPID-7546 > Project: Qpid > Issue Type: Test > Components: Java Tests >Reporter: Rob Godfrey >Assignee: Rob Godfrey > Attachments: > 0001-QPID-7546-Allow-overriding-of-jms-spec-artifact-in-o.patch > > > Currently the system tests use the JMS client for AMQP 0-8/9/10 and so the > AMQP 1.0 protocol implementation does not get as thoroughly tested. > We should aim to move all the system tests such that they can be run with > either client -- 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-7638) Add ability to run JMS 2.0 TCK
[ https://issues.apache.org/jira/browse/QPID-7638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15837429#comment-15837429 ] ASF subversion and git services commented on QPID-7638: --- Commit 1780155 from oru...@apache.org in branch 'java/trunk' [ https://svn.apache.org/r1780155 ] QPID-7638: Add ability to run JMS 2.0 TCK > Add ability to run JMS 2.0 TCK > -- > > Key: QPID-7638 > URL: https://issues.apache.org/jira/browse/QPID-7638 > Project: Qpid > Issue Type: Task > Components: Java Broker >Reporter: Alex Rudyy >Assignee: Alex Rudyy > Fix For: qpid-java-7.0 > > Attachments: add-ability-to-run-tck2.diff > > > We need the ability to run the TCK 2.0 against the Java Broker. -- 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-7638) Add ability to run JMS 2.0 TCK
[ https://issues.apache.org/jira/browse/QPID-7638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7638: - Status: Reviewable (was: In Progress) > Add ability to run JMS 2.0 TCK > -- > > Key: QPID-7638 > URL: https://issues.apache.org/jira/browse/QPID-7638 > Project: Qpid > Issue Type: Task > Components: Java Broker >Reporter: Alex Rudyy >Assignee: Alex Rudyy > Fix For: qpid-java-7.0 > > Attachments: add-ability-to-run-tck2.diff > > > We need the ability to run the TCK 2.0 against the Java Broker. -- 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-7638) Add ability to run JMS 2.0 TCK
[ https://issues.apache.org/jira/browse/QPID-7638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy reassigned QPID-7638: Assignee: Keith Wall (was: Alex Rudyy) Keith, Please review the changes > Add ability to run JMS 2.0 TCK > -- > > Key: QPID-7638 > URL: https://issues.apache.org/jira/browse/QPID-7638 > Project: Qpid > Issue Type: Task > Components: Java Broker >Reporter: Alex Rudyy >Assignee: Keith Wall > Fix For: qpid-java-7.0 > > Attachments: add-ability-to-run-tck2.diff > > > We need the ability to run the TCK 2.0 against the Java Broker. -- 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] (QPID-7639) [AMQP 1.0] Implement large transaction guard (i.e. honour connection.maxUncommittedInMemorySize)
Keith Wall created QPID-7639: Summary: [AMQP 1.0] Implement large transaction guard (i.e. honour connection.maxUncommittedInMemorySize) Key: QPID-7639 URL: https://issues.apache.org/jira/browse/QPID-7639 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Keith Wall Fix For: qpid-java-7.0 The AMQP 1.0 layer does not have the ability to detect a large incoming transaction and warn and flow the messages to disk if limits are breached. We should add it as this an important safe guard, We are probably missing implementation here: org.apache.qpid.server.protocol.v1_0.NodeReceivingDestination#send -- 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-624) Add Atomic operations support on Solaris
Adel Boutros created DISPATCH-624: - Summary: Add Atomic operations support on Solaris Key: DISPATCH-624 URL: https://issues.apache.org/jira/browse/DISPATCH-624 Project: Qpid Dispatch Issue Type: Bug Affects Versions: 0.7.0 Reporter: Adel Boutros Full details here: http://qpid.2158936.n2.nabble.com/Dispatch-Router-0-7-0-SOLARIS-Unit-tests-failing-tp7658341.html -- 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-624) Add Atomic operations support on Solaris
[ https://issues.apache.org/jira/browse/DISPATCH-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adel Boutros updated DISPATCH-624: -- Attachment: 0001-Add-Atomic-operations-for-Solaris.patch > Add Atomic operations support on Solaris > > > Key: DISPATCH-624 > URL: https://issues.apache.org/jira/browse/DISPATCH-624 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Adel Boutros > Attachments: 0001-Add-Atomic-operations-for-Solaris.patch > > > Full details here: > http://qpid.2158936.n2.nabble.com/Dispatch-Router-0-7-0-SOLARIS-Unit-tests-failing-tp7658341.html -- 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-624) Add Atomic operations support on Solaris
[ https://issues.apache.org/jira/browse/DISPATCH-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adel Boutros updated DISPATCH-624: -- Description: Full details here: http://qpid.2158936.n2.nabble.com/Dispatch-Router-0-7-0-SOLARIS-Unit-tests-failing-tp7658341.html *Methods added inspired from:* https://www.ibm.com/support/knowledgecenter/SSGH2K_13.1.0/com.ibm.xlc131.aix.doc/compiler_ref/bif_gcc_atomic_fetch_sub.html https://www.ibm.com/support/knowledgecenter/SSGH2K_13.1.0/com.ibm.xlc131.aix.doc/compiler_ref/bif_gcc_atomic_fetch_add.html http://docs.oracle.com/cd/E19253-01/816-5168/atomic-ops-3c/index.html was:Full details here: http://qpid.2158936.n2.nabble.com/Dispatch-Router-0-7-0-SOLARIS-Unit-tests-failing-tp7658341.html > Add Atomic operations support on Solaris > > > Key: DISPATCH-624 > URL: https://issues.apache.org/jira/browse/DISPATCH-624 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Adel Boutros > Attachments: 0001-Add-Atomic-operations-for-Solaris.patch > > > Full details here: > http://qpid.2158936.n2.nabble.com/Dispatch-Router-0-7-0-SOLARIS-Unit-tests-failing-tp7658341.html > *Methods added inspired from:* > https://www.ibm.com/support/knowledgecenter/SSGH2K_13.1.0/com.ibm.xlc131.aix.doc/compiler_ref/bif_gcc_atomic_fetch_sub.html > https://www.ibm.com/support/knowledgecenter/SSGH2K_13.1.0/com.ibm.xlc131.aix.doc/compiler_ref/bif_gcc_atomic_fetch_add.html > http://docs.oracle.com/cd/E19253-01/816-5168/atomic-ops-3c/index.html -- 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-7638) Add ability to run JMS 2.0 TCK
[ https://issues.apache.org/jira/browse/QPID-7638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15837639#comment-15837639 ] ASF subversion and git services commented on QPID-7638: --- Commit 1780176 from oru...@apache.org in branch 'java/trunk' [ https://svn.apache.org/r1780176 ] QPID-7638: Move all steps required to run jms 2.0 tck into a separate profile > Add ability to run JMS 2.0 TCK > -- > > Key: QPID-7638 > URL: https://issues.apache.org/jira/browse/QPID-7638 > Project: Qpid > Issue Type: Task > Components: Java Broker >Reporter: Alex Rudyy >Assignee: Keith Wall > Fix For: qpid-java-7.0 > > Attachments: add-ability-to-run-tck2.diff > > > We need the ability to run the TCK 2.0 against the Java Broker. -- 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-7625) [AMQP 1.0] Enforce DeleteOnClose temporary queues are not deleted in response to JMS TemporaryQueue#delete
[ https://issues.apache.org/jira/browse/QPID-7625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7625: - Summary: [AMQP 1.0] Enforce DeleteOnClose temporary queues are not deleted in response to JMS TemporaryQueue#delete (was: AMQP 1.0 temporary queues are not deleted in response to JMS TemporaryQueue#delete) > [AMQP 1.0] Enforce DeleteOnClose temporary queues are not deleted in response > to JMS TemporaryQueue#delete > -- > > Key: QPID-7625 > URL: https://issues.apache.org/jira/browse/QPID-7625 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Keith Wall > Fix For: qpid-java-7.0 > > > As shown by system test > {{TemporaryQueueTest#testExplictTemporaryQueueDeletion}}. When the > application calls {{TemporaryQueue#delete()}} the temporary queue ought to be > deleted immediately. This currently does not happen. > The following describes how sending links with certain properties are used to > establish temporary queues. > https://www.oasis-open.org/committees/download.php/56418/amqp-bindmap-jms-v1.0-wd06.pdf > The Qpid JMS Client correctly sends the detach in response to the {{#delete}} > call, but it appears that the broker's AMQP 1.0 protocol layer does not > organise itself to act upon the {{expiryPolicy=link-detach}} once the link is > detached. > The temporary queue _is_ deleted once the connection closes. > The attach establishing the temporary queue looks like this: > {noformat} > Attach{name=qpid-jms:temp-queue-creator:ID:d591b0c0-169d-4895-a227-e1e18c9709ab:1:1,handle=0,role=sender,sndSettleMode=unsettled,rcvSettleMode=first,source=Source{},target=Target{durable=none,expiryPolicy=link-detach,timeout=0,dynamic=true,dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},capabilities=[temporary-queue]},incompleteUnsettled=false,initialDeliveryCount=0} > {noformat} > The detach sent by the client: > {noformat} > 017-01-17 12:22:24,665 DEBUG [IO-/127.0.0.1:62572] o.a.q.s.p.frame > RECV[/127.0.0.1:62572|0] : Detach{handle=0,closed=true} > {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-7625) [AMQP 1.0] Enforce lifetime-policy DeleteOnClose
[ https://issues.apache.org/jira/browse/QPID-7625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7625: - Summary: [AMQP 1.0] Enforce lifetime-policy DeleteOnClose (was: [AMQP 1.0] Enforce DeleteOnClose temporary queues are not deleted in response to JMS TemporaryQueue#delete) > [AMQP 1.0] Enforce lifetime-policy DeleteOnClose > - > > Key: QPID-7625 > URL: https://issues.apache.org/jira/browse/QPID-7625 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Keith Wall > Fix For: qpid-java-7.0 > > > As shown by system test > {{TemporaryQueueTest#testExplictTemporaryQueueDeletion}}. When the > application calls {{TemporaryQueue#delete()}} the temporary queue ought to be > deleted immediately. This currently does not happen. > The following describes how sending links with certain properties are used to > establish temporary queues. > https://www.oasis-open.org/committees/download.php/56418/amqp-bindmap-jms-v1.0-wd06.pdf > The Qpid JMS Client correctly sends the detach in response to the {{#delete}} > call, but it appears that the broker's AMQP 1.0 protocol layer does not > organise itself to act upon the {{expiryPolicy=link-detach}} once the link is > detached. > The temporary queue _is_ deleted once the connection closes. > The attach establishing the temporary queue looks like this: > {noformat} > Attach{name=qpid-jms:temp-queue-creator:ID:d591b0c0-169d-4895-a227-e1e18c9709ab:1:1,handle=0,role=sender,sndSettleMode=unsettled,rcvSettleMode=first,source=Source{},target=Target{durable=none,expiryPolicy=link-detach,timeout=0,dynamic=true,dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},capabilities=[temporary-queue]},incompleteUnsettled=false,initialDeliveryCount=0} > {noformat} > The detach sent by the client: > {noformat} > 017-01-17 12:22:24,665 DEBUG [IO-/127.0.0.1:62572] o.a.q.s.p.frame > RECV[/127.0.0.1:62572|0] : Detach{handle=0,closed=true} > {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-7609) JMS 2.0 systests module
[ https://issues.apache.org/jira/browse/QPID-7609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7609: - Status: Reviewable (was: In Progress) > JMS 2.0 systests module > --- > > Key: QPID-7609 > URL: https://issues.apache.org/jira/browse/QPID-7609 > Project: Qpid > Issue Type: Improvement > Components: Java Tests >Reporter: Keith Wall >Assignee: Keith Wall > Fix For: qpid-java-7.0 > > Attachments: > 0001-QPID-7609-Java-System-Tests-Add-a-JMS-2.0-systest-mo.patch > > > We need the ability to test JMS 2.0 features end to end against the Java > Broker. We will have a separate module that will be activated only on the > 1.0 AMQP test profiles. It will contain tests written in terms of JMS 2.0 > API. AMQP Management will be used to perform any setup. -- 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-7568) [Java Broker] [AMQP 1.0] support Delayed Delivery with the JMS 2.0 client
[ https://issues.apache.org/jira/browse/QPID-7568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall resolved QPID-7568. -- Resolution: Fixed > [Java Broker] [AMQP 1.0] support Delayed Delivery with the JMS 2.0 client > - > > Key: QPID-7568 > URL: https://issues.apache.org/jira/browse/QPID-7568 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Robbie Gemmell >Assignee: Keith Wall > Fix For: qpid-java-7.0 > > > QPID-7255 added a form of delayed delivery support for the Java broker and > AMQP 0-X JMS client, with a qpid specific annotation in the case of AMQP 1.0. > The AMQP 1.0 JMS client will also support this via addition of support for > JMS 2.0 (QPIDJMS-207), but with some differences than in QPID-7255, and it > would be good for the Java broker to support this too. > The JMS 2.0 client can detect server support for the functionality in two > ways: > - by the server offering a "DELAYED_DELIVERY" connection capability > - or, if the connection capability wasn't offered, by setting a desired > capability of "DELAYED_DELIVERY" on the sending link attach and inspecting if > it is offered in the response. > If support for delivery delay was identified, when sending a message with a > producer configured with a delivery delay, the message will carry a > MessageAnnotation with _"x-opt-delivery-time"_ symbol key and long value > representing the time at which the message can be delivered to receivers as > the number of milliseconds since the epoch. If support was not identified, > the send will fail in order to reflect that the requested delay/delivery-time > can't be satisfied. -- 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] (QPID-7640) Migrate qpid-java svn to git
Keith Wall created QPID-7640: Summary: Migrate qpid-java svn to git Key: QPID-7640 URL: https://issues.apache.org/jira/browse/QPID-7640 Project: Qpid Issue Type: Task Components: Java Broker, Java Client Reporter: Keith Wall Fix For: Future The Qpid Broker for Java and the 0-x Qpid JMS Client are the last two components that use SVN. We should migrate from to GIT. This will simplify the 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-7640) Migrate qpid-java svn to git
[ https://issues.apache.org/jira/browse/QPID-7640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15837723#comment-15837723 ] Keith Wall commented on QPID-7640: -- When we do this, we will need to rework the qpidversion.properties as it includes the SVN revision number. > Migrate qpid-java svn to git > - > > Key: QPID-7640 > URL: https://issues.apache.org/jira/browse/QPID-7640 > Project: Qpid > Issue Type: Task > Components: Java Broker, Java Client >Reporter: Keith Wall > Fix For: Future > > > The Qpid Broker for Java and the 0-x Qpid JMS Client are the last two > components that use SVN. We should migrate from to GIT. This will simplify > the 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-7622) Separate Qpid Broker for Java and 0-x JMS Client in source tree
[ https://issues.apache.org/jira/browse/QPID-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15837725#comment-15837725 ] Keith Wall commented on QPID-7622: -- We need to remember qpidversion.properties. Both Broker and Client both load this file from the classpath. At very least we need to ensure that they reference unique resources. > Separate Qpid Broker for Java and 0-x JMS Client in source tree > --- > > Key: QPID-7622 > URL: https://issues.apache.org/jira/browse/QPID-7622 > Project: Qpid > Issue Type: Improvement > Components: Java Broker, Java Client >Reporter: Keith Wall > Fix For: qpid-java-7.0 > > > As discussed here: > http://qpid.2158936.n2.nabble.com/DISCUSS-Drop-the-AMQP-0-x-client-from-the-Qpid-for-Java-7-0-release-td7657770.html > The proposal is to move the code and documentation that comprises the 0-x > client to its own SVN root: > https://svn.apache.org/repos/asf/qpid/qpid-jms-amqp-0-x > The Java Broker and integration tests suites will remain at: > https://svn.apache.org/repos/asf/qpid/qpid-java > Maven dependencies will be used to pull in the appropriate 0-x client for > integration testing purposes (as we already do with the Qpid JMS Client). > The {{qpid-common}} module (and maven release artefact) will be eliminated. > * Classes that the Broker requires will be moved into the class hierarchy of > the existing plugin modules {{amqp-0-10-protocol}} and {{amqp-0-8-protocol}} > e.g. {{org/apache/qpid/server/protocol/vx_y}}.* > * Code that the 0-x client requires will be moved into the class hierarchy of > the client {{org/apache/qpid/client}}. > This will allow the Broker and 0-x Client to co-exist in the same JVM without > class loading collision. Class movements will be organised in such a way to > preserve SVN history. -- 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-7622) Separate Qpid Broker for Java and 0-x JMS Client in source tree
[ https://issues.apache.org/jira/browse/QPID-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15837725#comment-15837725 ] Keith Wall edited comment on QPID-7622 at 1/25/17 1:46 PM: --- We need to remember qpidversion.properties. Both Broker and Client both load this file from the classpath. At very least we must ensure that they reference unique resource names so that a new Broker can be co-located with an older client without the risk that one consumes the others {{qpidversion.properties}}. This might be the moment to switch to: maven-jar-plugins addDefaultImplementationEntries buildnumber-maven-plugin and do away with qpidversion.properties altogether. was (Author: k-wall): We need to remember qpidversion.properties. Both Broker and Client both load this file from the classpath. At very least we need to ensure that they reference unique resources. > Separate Qpid Broker for Java and 0-x JMS Client in source tree > --- > > Key: QPID-7622 > URL: https://issues.apache.org/jira/browse/QPID-7622 > Project: Qpid > Issue Type: Improvement > Components: Java Broker, Java Client >Reporter: Keith Wall > Fix For: qpid-java-7.0 > > > As discussed here: > http://qpid.2158936.n2.nabble.com/DISCUSS-Drop-the-AMQP-0-x-client-from-the-Qpid-for-Java-7-0-release-td7657770.html > The proposal is to move the code and documentation that comprises the 0-x > client to its own SVN root: > https://svn.apache.org/repos/asf/qpid/qpid-jms-amqp-0-x > The Java Broker and integration tests suites will remain at: > https://svn.apache.org/repos/asf/qpid/qpid-java > Maven dependencies will be used to pull in the appropriate 0-x client for > integration testing purposes (as we already do with the Qpid JMS Client). > The {{qpid-common}} module (and maven release artefact) will be eliminated. > * Classes that the Broker requires will be moved into the class hierarchy of > the existing plugin modules {{amqp-0-10-protocol}} and {{amqp-0-8-protocol}} > e.g. {{org/apache/qpid/server/protocol/vx_y}}.* > * Code that the 0-x client requires will be moved into the class hierarchy of > the client {{org/apache/qpid/client}}. > This will allow the Broker and 0-x Client to co-exist in the same JVM without > class loading collision. Class movements will be organised in such a way to > preserve SVN history. -- 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-7402) [Java Broker] https in default config
[ https://issues.apache.org/jira/browse/QPID-7402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7402: - Fix Version/s: (was: Future) qpid-java-7.0 > [Java Broker] https in default config > - > > Key: QPID-7402 > URL: https://issues.apache.org/jira/browse/QPID-7402 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Lorenz Quack > Fix For: qpid-java-7.0 > > > Currently the broker ships with a default config that has a plain HTTP port > configured. > Since basic auth over HTTP is disabled by default there is no way to remotely > configure the broker out of the box. > I suggest to modify the default config to add a authprovider with self-signed > certificate and either replace the existing HTTP port or add a new HTTPS port. -- 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] (QPID-7641) SCRAM SASL should verify the server-final message
Keith Wall created QPID-7641: Summary: SCRAM SASL should verify the server-final message Key: QPID-7641 URL: https://issues.apache.org/jira/browse/QPID-7641 Project: Qpid Issue Type: Improvement Components: Java Client Reporter: Keith Wall Fix For: qpid-java-7.0 QPID-7282 addressed the issue that the Java Broker was not sending the server-final message in the SCRAM-* SASL exchange, however this omission was not causing the clients to fail, since they blindly accept the server's acceptance of their credentials. Clients implementing SCRAM-* or similar protocols which include a client verification step, should perform the verification of the server and fail or warn (to be configured by a system property) if the verification does not occur or it fails. -- 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] [Moved] (QPIDJMS-260) SCRAM SASL should verify the server-final message
[ https://issues.apache.org/jira/browse/QPIDJMS-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall moved QPID-7641 to QPIDJMS-260: -- Fix Version/s: (was: qpid-java-7.0) Component/s: (was: Java Client) qpid-jms-client Workflow: classic default workflow (was: QPid Workflow) Key: QPIDJMS-260 (was: QPID-7641) Project: Qpid JMS (was: Qpid) > SCRAM SASL should verify the server-final message > - > > Key: QPIDJMS-260 > URL: https://issues.apache.org/jira/browse/QPIDJMS-260 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Reporter: Keith Wall > > QPID-7282 addressed the issue that the Java Broker was not sending the > server-final message in the SCRAM-* SASL exchange, however this omission was > not causing the clients to fail, since they blindly accept the server's > acceptance of their credentials. > Clients implementing SCRAM-* or similar protocols which include a client > verification step, should perform the verification of the server and fail or > warn (to be configured by a system property) if the verification does not > occur or it fails. -- 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-7402) [Java Broker] https in default config
[ https://issues.apache.org/jira/browse/QPID-7402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15837818#comment-15837818 ] Keith Wall commented on QPID-7402: -- Is the use case for development? If so, I think we should add a alternative initial-config that defines a self signed certificate and two ports: HTTP serving both PLAIN/TLS and AMQP serving both PLAIN/TLS. I think separately there should be a 'production' initial config that defines only TLS are refers to key material via system properties. > [Java Broker] https in default config > - > > Key: QPID-7402 > URL: https://issues.apache.org/jira/browse/QPID-7402 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Lorenz Quack > Fix For: qpid-java-7.0 > > > Currently the broker ships with a default config that has a plain HTTP port > configured. > Since basic auth over HTTP is disabled by default there is no way to remotely > configure the broker out of the box. > I suggest to modify the default config to add a authprovider with self-signed > certificate and either replace the existing HTTP port or add a new HTTPS port. -- 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] (QPID-7642) [Java Broker] Create binding operations on exchanges should fail when invalid selector is provided as part of binding arguments
Alex Rudyy created QPID-7642: Summary: [Java Broker] Create binding operations on exchanges should fail when invalid selector is provided as part of binding arguments Key: QPID-7642 URL: https://issues.apache.org/jira/browse/QPID-7642 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: qpid-java-6.1.1, qpid-java-6.0.6, qpid-java-6.1, qpid-java-6.0.5, qpid-java-6.0.4, qpid-java-6.0.3, qpid-java-6.0.2, qpid-java-6.0.1, qpid-java-6.0, 0.32 Reporter: Alex Rudyy Fix For: qpid-java-7.0 When create binding operation is invoked with invalid selector provided as part of binding arguments , the current exchange implementations react differently on this error condition: * fanout and direct exchanges create binding successfully without a selector * topic exchange throws ConnectionScopeRuntimeException * header exchange create "x-exclude-all" filter The current behavior is inconsistent and not valid. The caller needs to be notified about error condition by throwing a special exception which is not ConnectionScopeRuntimeException. -- 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 ] Lorenz Quack reassigned QPID-7586: -- Assignee: Lorenz Quack > [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: Lorenz Quack > 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] [Commented] (QPID-7621) Target Java 8+, i.e. drop support for Java 7
[ https://issues.apache.org/jira/browse/QPID-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15837919#comment-15837919 ] Keith Wall commented on QPID-7621: -- This will be just a modification to the Maven POMs and documentation. There is also reflective code in SSLUtil which can be eliminated in favour of a normal method call. > Target Java 8+, i.e. drop support for Java 7 > > > Key: QPID-7621 > URL: https://issues.apache.org/jira/browse/QPID-7621 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall > Fix For: qpid-java-7.0 > > > Begin targeting Java 8 for the Qpid Broker for Java, i.e requiring Java 8+ to > build or use the broker, dropping support for Java 7. > As discussed on the mailing lists: > https://lists.apache.org/thread.html/00b8f739bd5a653ebb1ce096566fdaf35b0c8cfe749b2ba81bf7c38c@%3Cusers.qpid.apache.org%3E -- 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-7642) [Java Broker] Create binding operations on exchanges should fail when invalid selector is provided as part of binding arguments
[ https://issues.apache.org/jira/browse/QPID-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15837957#comment-15837957 ] ASF subversion and git services commented on QPID-7642: --- Commit 1780223 from oru...@apache.org in branch 'java/trunk' [ https://svn.apache.org/r1780223 ] QPID-7642: Validate subscription filters on receiving attach > [Java Broker] Create binding operations on exchanges should fail when invalid > selector is provided as part of binding arguments > --- > > Key: QPID-7642 > URL: https://issues.apache.org/jira/browse/QPID-7642 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: 0.32, qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2, > qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5, qpid-java-6.1, > qpid-java-6.0.6, qpid-java-6.1.1 >Reporter: Alex Rudyy > Fix For: qpid-java-7.0 > > > When create binding operation is invoked with invalid selector provided as > part of binding arguments , the current exchange implementations react > differently on this error condition: > * fanout and direct exchanges create binding successfully without a selector > * topic exchange throws ConnectionScopeRuntimeException > * header exchange create "x-exclude-all" filter > The current behavior is inconsistent and not valid. The caller needs to be > notified about error condition by throwing a special exception which is not > ConnectionScopeRuntimeException. -- 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-proton-j issue #1: Memory leak with delayed settlement
Github user gemmellr commented on the issue: https://github.com/apache/qpid-proton-j/pull/1 I am in a F2F meeting (or travelling to/from it) all this week so I probably won't get a chance to look closely until next week, but I took a skim of this. I can see from the changes that the issue is more subtle than the JIRA description actually indicates, so it would be useful to update that to be a bit clearer on the actual issue. E.g, settlement is effectively an explicit 'I am forgetting this delivery' step, so it is expected to retain deliveries when as yet unsettled. Retaining deliveries in memory that have been settled (and that fact actually processed by the Transport) would not, and the changes suggest there is scope for that to occur. As an aside, we don't intend to do any 0.16.x releases, 0.17.0 will be the next release (fairly soon) for both proton[-c] and proton-j to cement their new independence, so changes for this will go on master. Robbie --- 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] [Created] (DISPATCH-625) qdrouterd crashes if it can't find the python library
Alan Conway created DISPATCH-625: Summary: qdrouterd crashes if it can't find the python library Key: DISPATCH-625 URL: https://issues.apache.org/jira/browse/DISPATCH-625 Project: Qpid Dispatch Issue Type: Bug Components: Container Affects Versions: 0.7.0 Reporter: Alan Conway Assignee: Alan Conway The router crashes if it can't find python library because the order of initialization has changed in main.c and the log source used to report the missingn python lib is not yet initialized. -- 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-1393) Memory leak with delayed settlement
[ https://issues.apache.org/jira/browse/PROTON-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Kamke updated PROTON-1393: --- Description: {{DeliveryImpl}} manages several doubly linked lists (of links, work and transportWork). However it does not function properly if removal is done out of order. It leaves object references in the next/previous pointers which on a large scale inhibit the system from garbage collecting these object, namely the {{DeliveryImpl}} object graph. In practice this was discovered when message consumers delay settlement of messages until after a period of time elapses (i.e. some async work is done in another thread). This causes out of order settlement to occur, leaving object references. Eventually the JVM will run out of memory and the process will crash. The heap can be examined to discover a large number of {{settled}} {{DeliveryImpl}}(s) which are holding references to themselves. was: {{DeliveryImpl}} manages several doubly linked lists (of links, work and transportWork). However it does not function properly if removal is done out of order. It leaves object references in the next/previous pointers which on a large scale inhibit the system from garbage collecting these object, namely the {{DeliveryImpl}} object graph. In practice this was discovered when message consumers delay settlement of messages until after a period of time elapses (i.e. some async work is done in another thread). This causes out of order settlement to occur, leaving object references. Eventually the JVM will run out of memory and the process will crash. The heap can be examined to discover a large number of {{settled}} {{DeliveryImpl}} s which are holding references to themselves. > Memory leak with delayed settlement > --- > > Key: PROTON-1393 > URL: https://issues.apache.org/jira/browse/PROTON-1393 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.16.0 >Reporter: Jonathan Kamke > > {{DeliveryImpl}} manages several doubly linked lists (of links, work and > transportWork). However it does not function properly if removal is done out > of order. It leaves object references in the next/previous pointers which on > a large scale inhibit the system from garbage collecting these object, namely > the {{DeliveryImpl}} object graph. > In practice this was discovered when message consumers delay settlement of > messages until after a period of time elapses (i.e. some async work is done > in another thread). This causes out of order settlement to occur, leaving > object references. Eventually the JVM will run out of memory and the process > will crash. The heap can be examined to discover a large number of > {{settled}} {{DeliveryImpl}}(s) which are holding references to themselves. -- 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-1393) Memory leak with delayed settlement
[ https://issues.apache.org/jira/browse/PROTON-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Kamke updated PROTON-1393: --- Description: {{DeliveryImpl}} manages several doubly linked lists (of links, work and transportWork). However it does not function properly if removal is done out of order. It leaves object references in the next/previous pointers which on a large scale inhibit the system from garbage collecting these object, namely the {{DeliveryImpl}} object graph. In practice this was discovered when message consumers delay settlement of messages until after a period of time elapses (i.e. some async work is done in another thread). This causes out of order settlement to occur, leaving object references. Eventually the JVM will run out of memory and the process will crash. The heap can be examined to discover a large number of {{settled}} {{DeliveryImpl}} s which are holding references to themselves. was: {{DeliveryImpl}} manages several doubly linked lists (of links, work and transportWork). However it does not function properly if removal is done out of order. It leaves object references in the next/previous pointers which on a large scale inhibit the system from garbage collecting these object, namely the {{DeliveryImpl}} object graph. In practice this was discovered when message consumers delay settlement of messages until after a period of time elapses (i.e. some async work is done in another thread). This causes out of order settlement to occur, leaving object references. Eventually the JVM will run out of memory and the process will crash. The heap can be examined to discover a large number of {{settled}} {{DeliveryImpl}}s which are holding references to themselves. > Memory leak with delayed settlement > --- > > Key: PROTON-1393 > URL: https://issues.apache.org/jira/browse/PROTON-1393 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.16.0 >Reporter: Jonathan Kamke > > {{DeliveryImpl}} manages several doubly linked lists (of links, work and > transportWork). However it does not function properly if removal is done out > of order. It leaves object references in the next/previous pointers which on > a large scale inhibit the system from garbage collecting these object, namely > the {{DeliveryImpl}} object graph. > In practice this was discovered when message consumers delay settlement of > messages until after a period of time elapses (i.e. some async work is done > in another thread). This causes out of order settlement to occur, leaving > object references. Eventually the JVM will run out of memory and the process > will crash. The heap can be examined to discover a large number of > {{settled}} {{DeliveryImpl}} s which are holding references to themselves. -- 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-1393) Memory leak with delayed settlement
[ https://issues.apache.org/jira/browse/PROTON-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Kamke updated PROTON-1393: --- Description: {{DeliveryImpl}} manages several doubly linked lists (of links, work and transportWork). However it does not function properly if removal is done out of order. It leaves object references in the next/previous pointers which on a large scale inhibit the system from garbage collecting these object, namely the {{DeliveryImpl}} object graph. In practice this was discovered when message consumers delay settlement of messages until after a period of time elapses (i.e. some async work is done in another thread). This causes out of order settlement to occur, leaving object references. Eventually the JVM will run out of memory and the process will crash. The heap can be examined to discover a large number of {{settled}} {{DeliveryImpl}}s which are holding references to themselves. was:If message consumers delay settlement of messages until after a period of time elapses (i.e. some work is done), then the number of {{DeliveryImpl}}(s) in the heap will rise. Eventually the JVM will run out of memory and the process will crash. > Memory leak with delayed settlement > --- > > Key: PROTON-1393 > URL: https://issues.apache.org/jira/browse/PROTON-1393 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.16.0 >Reporter: Jonathan Kamke > > {{DeliveryImpl}} manages several doubly linked lists (of links, work and > transportWork). However it does not function properly if removal is done out > of order. It leaves object references in the next/previous pointers which on > a large scale inhibit the system from garbage collecting these object, namely > the {{DeliveryImpl}} object graph. > In practice this was discovered when message consumers delay settlement of > messages until after a period of time elapses (i.e. some async work is done > in another thread). This causes out of order settlement to occur, leaving > object references. Eventually the JVM will run out of memory and the process > will crash. The heap can be examined to discover a large number of > {{settled}} {{DeliveryImpl}}s which are holding references to themselves. -- 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-7634) [Java Broker,amqp 1.0] Broker does not respond to Flow command with drain=true if queue is empty and prefetch is 0
[ https://issues.apache.org/jira/browse/QPID-7634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7634: - Description: When AMQP 1.0 client sends the Flow command with drain=true and queue is empty the Broker does not respond if prefetch is 0. The following snippet reproduces the issue {code} Connection connection = factory.createConnection(username, password); connection.start(); Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE); MessageConsumer messageConsumer = session.createConsumer(queue); TextMessage receivedMessage = (TextMessage) messageConsumer.receiveNoWait(); // <-- times out {code} The broker logs {noformat} 2017-01-24 11:05:56,471 DEBUG [IO-/127.0.0.1:51108] (o.a.q.s.p.frame) - RECV[/127.0.0.1:51108|1] : Attach{name=qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,handle=1,role=receiver,sndSettleMode=unsettled,rcvSettleMode=first,source=Source{address=queue,durable=none,expiryPolicy=link-detach,timeout=0,dynamic=false,defaultOutcome=Modified{deliveryFailed=true},outcomes=[amqp:accepted:list, amqp:rejected:list, amqp:released:list, amqp:modified:list],capabilities=[queue, global]},target=Target{}} 2017-01-24 11:05:56,474 DEBUG [VirtualHostNode-default-Config] (o.a.q.s.c.u.TaskExecutorImpl) - Performing Task['add consumer' on 'queue' with arguments 'target=ConsumerTarget_1_0[linkSession=[con:7(admin@/127.0.0.1:51108/default)/ch:1] ], consumerName=qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue, optionSet=[ACQUIRES, SEES_REQUEUES]'] 2017-01-24 11:05:56,475 DEBUG [VirtualHostNode-default-Config] (o.a.q.s.m.AbstractConfiguredObject) - authorise returned DEFER 2017-01-24 11:05:56,475 DEBUG [VirtualHostNode-default-Config] (o.a.q.s.m.AbstractConfiguredObject) - authorise returned DEFER, returing default: ALLOWED 2017-01-24 11:05:56,475 DEBUG [VirtualHostNode-default-Config] (o.a.q.s.c.u.TaskExecutorImpl) - Performing Task['open' on 'Consumer[id=164b1b27-176a-42a3-a5dc-613d97bc58b2, name=7|1|qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue, type=Consumer]'] 2017-01-24 11:05:56,475 DEBUG [VirtualHostNode-default-Config] (o.a.q.s.c.u.TaskExecutorImpl) - Task['open' on 'Consumer[id=164b1b27-176a-42a3-a5dc-613d97bc58b2, name=7|1|qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue, type=Consumer]'] performed successfully with result: null 2017-01-24 11:05:56,476 INFO [VirtualHostNode-default-Config] (q.m.s.create) - [con:7(admin@/127.0.0.1:51108/default)/ch:1] [sub:7(vh(/default)/qu(queue)] SUB-1001 : Create 2017-01-24 11:05:56,476 DEBUG [VirtualHostNode-default-Config] (o.a.q.s.c.u.TaskExecutorImpl) - Task['add consumer' on 'queue' with arguments 'target=ConsumerTarget_1_0[linkSession=[con:7(admin@/127.0.0.1:51108/default)/ch:1] ], consumerName=qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue, optionSet=[ACQUIRES, SEES_REQUEUES]'] performed successfully with result: Consumer[id=164b1b27-176a-42a3-a5dc-613d97bc58b2, name=7|1|qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue, type=Consumer] 2017-01-24 11:05:56,477 DEBUG [IO-/127.0.0.1:51108] (o.a.q.s.p.frame) - SEND[/127.0.0.1:51108|1] : Attach{name=qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,handle=1,role=sender,sndSettleMode=unsettled,rcvSettleMode=first,source=Source{address=queue,durable=none,expiryPolicy=link-detach,timeout=0,dynamic=false,defaultOutcome=Modified{deliveryFailed=true},outcomes=[amqp:accepted:list, amqp:rejected:list, amqp:released:list, amqp:modified:list],capabilities=[queue]},target=Target{},initialDeliveryCount=0,offeredCapabilities=[SHARED-SUBS],properties={}} 2017-01-24 11:05:56,477 DEBUG [IO-/127.0.0.1:51108] (o.a.q.s.t.NonBlockingConnection) - Written 251 bytes 2017-01-24 11:05:56,477 DEBUG [IO-/127.0.0.1:51108] (o.a.q.s.t.NonBlockingConnection) - Read 0 byte(s) 2017-01-24 11:05:56,487 DEBUG [IO-/127.0.0.1:51108] (o.a.q.s.t.NonBlockingConnection) - Read 34 byte(s) 2017-01-24 11:05:56,487 DEBUG [IO-/127.0.0.1:51108] (o.a.q.s.p.frame) - RECV[/127.0.0.1:51108|1] : Flow{nextIncomingId=0,incomingWindow=2047,nextOutgoingId=1,outgoingWindow=2147483647,handle=1,deliveryCount=0,linkCredit=1,drain=true} 2017-01-24 11:05:56,487 DEBUG [IO-/127.0.0.1:51108] (o.a.q.s.t.NonBlockingConnection) - Read 0 byte(s) 2017-01-24 11:05:58,162 DEBUG [IO-/127.0.0.1:51108] (o.a.q.s.t.NonBlockingConnection) - Read 0 byte(s) ... {noformat} Relevant part of the spec: http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-flow-control bq. If the sender's drain flag is set and there are no available messages, the sender MUST advance its delivery-count until link-credit is zero, and send its updated flow state to the receiver. was: When AMQP 1.0 client sends the Flow command with drain=true and queue is empty the Broker
[jira] [Commented] (QPID-7635) [Java Broker] If ANONYMOUS-RELAY finds the destination it should defer the delivery outcome to the destination
[ https://issues.apache.org/jira/browse/QPID-7635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15838256#comment-15838256 ] Keith Wall commented on QPID-7635: -- Can some more information be added to this JIRA please to help me understand the background and the current behaviour? > [Java Broker] If ANONYMOUS-RELAY finds the destination it should defer the > delivery outcome to the destination > -- > > Key: QPID-7635 > URL: https://issues.apache.org/jira/browse/QPID-7635 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-7.0 >Reporter: Alex Rudyy > Fix For: qpid-java-7.0 > > > On publishing message using ANONYMOUS-RELAY when message is delivered to > queue with binding having filters not accepting the message the delivery > outcome is determined by anonymous relay (currently REJECTED) instead of > queue or exchange. If ANONYMOUS-RELAY finds the destination it should defer > the delivery outcome to the destination. -- 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-proton-j pull request #2: Delivery link leak
GitHub user jkamke opened a pull request: https://github.com/apache/qpid-proton-j/pull/2 Delivery link leak Supersedes apache/qpid-proton-j/pull/1 for https://issues.apache.org/jira/browse/PROTON-1393 You can merge this pull request into a Git repository by running: $ git pull https://github.com/jkamke/qpid-proton-j delivery-link-leak Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-proton-j/pull/2.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2 commit 3c315a31548aa8ce2570b61eda3cfecf783b4f72 Author: Robert Gemmell Date: 2016-12-08T15:37:59Z PROTON-1374: update versions for 0.16.0 (RC1) commit b942d5636479b3ba51a842ee2734171e5722a9bd Author: Robert Gemmell Date: 2016-12-08T17:33:40Z PROTON-1374: bump versions to 0.16.1-SNAPSHOT commit 059322cb19c77514f58c62fa7dbd580faf70cf7a Author: JK Date: 2017-01-19T17:15:08Z fix memory leak by cleaning up references and removing links safely commit 45009610ef8af0d558cd0a1adf1797525db2522c Author: JK Date: 2017-01-20T02:31:12Z test for memory leak commit 41151a52dbd30cfe0d5471fb7bfe1502305578a4 Author: JK Date: 2017-01-20T02:32:48Z attribution for verifier commit 541d1974cc938ac64ffb9583ab8351dcd8072fab Author: JK Date: 2017-01-25T18:22:41Z Fixes #1 and addresses https://issues.apache.org/jira/browse/PROTON-1393 against master --- 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] (PROTON-1393) Memory leak with delayed settlement
[ https://issues.apache.org/jira/browse/PROTON-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15838322#comment-15838322 ] ASF GitHub Bot commented on PROTON-1393: GitHub user jkamke opened a pull request: https://github.com/apache/qpid-proton-j/pull/2 Delivery link leak Supersedes apache/qpid-proton-j/pull/1 for https://issues.apache.org/jira/browse/PROTON-1393 You can merge this pull request into a Git repository by running: $ git pull https://github.com/jkamke/qpid-proton-j delivery-link-leak Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-proton-j/pull/2.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2 commit 3c315a31548aa8ce2570b61eda3cfecf783b4f72 Author: Robert Gemmell Date: 2016-12-08T15:37:59Z PROTON-1374: update versions for 0.16.0 (RC1) commit b942d5636479b3ba51a842ee2734171e5722a9bd Author: Robert Gemmell Date: 2016-12-08T17:33:40Z PROTON-1374: bump versions to 0.16.1-SNAPSHOT commit 059322cb19c77514f58c62fa7dbd580faf70cf7a Author: JK Date: 2017-01-19T17:15:08Z fix memory leak by cleaning up references and removing links safely commit 45009610ef8af0d558cd0a1adf1797525db2522c Author: JK Date: 2017-01-20T02:31:12Z test for memory leak commit 41151a52dbd30cfe0d5471fb7bfe1502305578a4 Author: JK Date: 2017-01-20T02:32:48Z attribution for verifier commit 541d1974cc938ac64ffb9583ab8351dcd8072fab Author: JK Date: 2017-01-25T18:22:41Z Fixes #1 and addresses https://issues.apache.org/jira/browse/PROTON-1393 against master > Memory leak with delayed settlement > --- > > Key: PROTON-1393 > URL: https://issues.apache.org/jira/browse/PROTON-1393 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.16.0 >Reporter: Jonathan Kamke > > {{DeliveryImpl}} manages several doubly linked lists (of links, work and > transportWork). However it does not function properly if removal is done out > of order. It leaves object references in the next/previous pointers which on > a large scale inhibit the system from garbage collecting these object, namely > the {{DeliveryImpl}} object graph. > In practice this was discovered when message consumers delay settlement of > messages until after a period of time elapses (i.e. some async work is done > in another thread). This causes out of order settlement to occur, leaving > object references. Eventually the JVM will run out of memory and the process > will crash. The heap can be examined to discover a large number of > {{settled}} {{DeliveryImpl}}(s) which are holding references to themselves. -- 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-proton-j pull request #1: Memory leak with delayed settlement
Github user jkamke closed the pull request at: https://github.com/apache/qpid-proton-j/pull/1 --- 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-proton-j issue #1: Memory leak with delayed settlement
Github user jkamke commented on the issue: https://github.com/apache/qpid-proton-j/pull/1 Thanks @gemmellr. Closing in favor of master based changes in apache/qpid-proton-j/issues/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
[jira] [Commented] (PROTON-1393) Memory leak with delayed settlement
[ https://issues.apache.org/jira/browse/PROTON-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15838330#comment-15838330 ] ASF GitHub Bot commented on PROTON-1393: Github user jkamke closed the pull request at: https://github.com/apache/qpid-proton-j/pull/1 > Memory leak with delayed settlement > --- > > Key: PROTON-1393 > URL: https://issues.apache.org/jira/browse/PROTON-1393 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.16.0 >Reporter: Jonathan Kamke > > {{DeliveryImpl}} manages several doubly linked lists (of links, work and > transportWork). However it does not function properly if removal is done out > of order. It leaves object references in the next/previous pointers which on > a large scale inhibit the system from garbage collecting these object, namely > the {{DeliveryImpl}} object graph. > In practice this was discovered when message consumers delay settlement of > messages until after a period of time elapses (i.e. some async work is done > in another thread). This causes out of order settlement to occur, leaving > object references. Eventually the JVM will run out of memory and the process > will crash. The heap can be examined to discover a large number of > {{settled}} {{DeliveryImpl}}(s) which are holding references to themselves. -- 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