[jira] [Commented] (QPID-8158) [Broker-J] [System Tests] Refactor BDB HA system tests

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-8158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434744#comment-16434744
 ] 

ASF subversion and git services commented on QPID-8158:
---

Commit c82574b9a651dde1c8f07428212e0312a63e685d in qpid-broker-j's branch 
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=c82574b ]

QPID-8158: [Broker-J] [System Tests] Simplify GroupBrokerAdmin


> [Broker-J] [System Tests] Refactor BDB HA system tests
> --
>
> Key: QPID-8158
> URL: https://issues.apache.org/jira/browse/QPID-8158
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J, Java Tests
>Reporter: Alex Rudyy
>Priority: Major
>
> Currently BDB HA system tests are extended from {{QpidBrokerTestCase}}. They 
> need to be refactored to run with {{QpidTestRunner}}  similar to other system 
> tests.
> The BDB HA nodes  should be started as spawn brokers using special  
> {{BrokerAdmin}} allowing to start broker in a separate JVM.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-8158) [Broker-J] [System Tests] Refactor BDB HA system tests

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-8158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434743#comment-16434743
 ] 

ASF subversion and git services commented on QPID-8158:
---

Commit ebf33b385942232b0f5b75444f05dc70dc59 in qpid-broker-j's branch 
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=ebf33b3 ]

QPID-8158: [Broker-J] [System Tests] Fix MultiNodeTest


> [Broker-J] [System Tests] Refactor BDB HA system tests
> --
>
> Key: QPID-8158
> URL: https://issues.apache.org/jira/browse/QPID-8158
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J, Java Tests
>Reporter: Alex Rudyy
>Priority: Major
>
> Currently BDB HA system tests are extended from {{QpidBrokerTestCase}}. They 
> need to be refactored to run with {{QpidTestRunner}}  similar to other system 
> tests.
> The BDB HA nodes  should be started as spawn brokers using special  
> {{BrokerAdmin}} allowing to start broker in a separate JVM.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (DISPATCH-962) links established to 'unavailable' addresses are not refused correctly

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434676#comment-16434676
 ] 

ASF subversion and git services commented on DISPATCH-962:
--

Commit 9411270f301bde9197c1f55b387f2980a6d63aa5 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=9411270 ]

DISPATCH-962 - Ensure that link termini are not present when an attach is 
rejected.


> links established to 'unavailable' addresses are not refused correctly
> --
>
> Key: DISPATCH-962
> URL: https://issues.apache.org/jira/browse/DISPATCH-962
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 1.0.0, 1.0.1, 1.1.0
>Reporter: Robbie Gemmell
>Assignee: Ted Ross
>Priority: Major
> Fix For: 1.1.0
>
>
> When setting an address as unavailable (via defaultDistribution: unavailable 
> from DISPATCH-803) the router doesn't refuse the links to it in the manner 
> the spec indicates it should.
> To indicate a link is being refused, the spec describes that the attach 
> response should contain a null target/source as appropriate, essentially 
> indicating to the peer that the detach will follow due to the error, 
> [http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp315568],
>  Figure 2.33: Refusing a Link.
> Currently this does not happen, e.g:
> Creating a sending link, response attach with non-null Target:
> {noformat}
> [750316387:1] -> 
> Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
>  handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
> source=Source{address='ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, distributionMode=null, filter=null, 
> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list, 
> amqp:released:list, amqp:modified:list], capabilities=null}, 
> target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=null, offeredCapabilities=null, 
> desiredCapabilities=[DELAYED_DELIVERY], properties=null}
> [750316387:1] <- 
> Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
>  handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST, 
> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
> filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, 
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, 
> properties=null}
> {noformat}
> Creating a receiving link, response attach with non-null Source:
> {noformat}
> [59324032:1] -> 
> Attach{name='qpid-jms:receiver:ID:30b1b1c9-316b-4be1-9944-15b5822a6500:1:1:1:queue',
>  handle=0, role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
> source=Source{address='queue', durable=NONE, expiryPolicy=LINK_DETACH, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
> filter=null, defaultOutcome=Modified{deliveryFailed=true, 
> undeliverableHere=null, messageAnnotations=null}, 
> outcomes=[amqp:accepted:list, amqp:rejected:list, amqp:released:list, 
> amqp:modified:list], capabilities=[queue]}, target=Target{address='null', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, capabilities=null}, unsettled=null, 
> incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null, 
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [59324032:1] <- 
> Attach{name='qpid-jms:receiver:ID:30b1b1c9-316b-4be1-9944-15b5822a6500:1:1:1:queue',
>  handle=0, role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST, 
> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
> filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, 
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, 
> 

[jira] [Resolved] (DISPATCH-962) links established to 'unavailable' addresses are not refused correctly

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DISPATCH-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross resolved DISPATCH-962.
---
Resolution: Fixed

> links established to 'unavailable' addresses are not refused correctly
> --
>
> Key: DISPATCH-962
> URL: https://issues.apache.org/jira/browse/DISPATCH-962
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 1.0.0, 1.0.1, 1.1.0
>Reporter: Robbie Gemmell
>Assignee: Ted Ross
>Priority: Major
> Fix For: 1.1.0
>
>
> When setting an address as unavailable (via defaultDistribution: unavailable 
> from DISPATCH-803) the router doesn't refuse the links to it in the manner 
> the spec indicates it should.
> To indicate a link is being refused, the spec describes that the attach 
> response should contain a null target/source as appropriate, essentially 
> indicating to the peer that the detach will follow due to the error, 
> [http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp315568],
>  Figure 2.33: Refusing a Link.
> Currently this does not happen, e.g:
> Creating a sending link, response attach with non-null Target:
> {noformat}
> [750316387:1] -> 
> Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
>  handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
> source=Source{address='ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, distributionMode=null, filter=null, 
> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list, 
> amqp:released:list, amqp:modified:list], capabilities=null}, 
> target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=null, offeredCapabilities=null, 
> desiredCapabilities=[DELAYED_DELIVERY], properties=null}
> [750316387:1] <- 
> Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
>  handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST, 
> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
> filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, 
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, 
> properties=null}
> {noformat}
> Creating a receiving link, response attach with non-null Source:
> {noformat}
> [59324032:1] -> 
> Attach{name='qpid-jms:receiver:ID:30b1b1c9-316b-4be1-9944-15b5822a6500:1:1:1:queue',
>  handle=0, role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
> source=Source{address='queue', durable=NONE, expiryPolicy=LINK_DETACH, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
> filter=null, defaultOutcome=Modified{deliveryFailed=true, 
> undeliverableHere=null, messageAnnotations=null}, 
> outcomes=[amqp:accepted:list, amqp:rejected:list, amqp:released:list, 
> amqp:modified:list], capabilities=[queue]}, target=Target{address='null', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, capabilities=null}, unsettled=null, 
> incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null, 
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [59324032:1] <- 
> Attach{name='qpid-jms:receiver:ID:30b1b1c9-316b-4be1-9944-15b5822a6500:1:1:1:queue',
>  handle=0, role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST, 
> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
> filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, 
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, 
> properties=null}
> {noformat}
> The links are detached after this, but the non-null terminus removes the hint 
> to the peer that it is coming.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional 

[jira] [Updated] (DISPATCH-962) links established to 'unavailable' addresses are not refused correctly

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DISPATCH-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated DISPATCH-962:
--
Component/s: Container

> links established to 'unavailable' addresses are not refused correctly
> --
>
> Key: DISPATCH-962
> URL: https://issues.apache.org/jira/browse/DISPATCH-962
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 1.0.0, 1.0.1, 1.1.0
>Reporter: Robbie Gemmell
>Assignee: Ted Ross
>Priority: Major
> Fix For: 1.1.0
>
>
> When setting an address as unavailable (via defaultDistribution: unavailable 
> from DISPATCH-803) the router doesn't refuse the links to it in the manner 
> the spec indicates it should.
> To indicate a link is being refused, the spec describes that the attach 
> response should contain a null target/source as appropriate, essentially 
> indicating to the peer that the detach will follow due to the error, 
> [http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp315568],
>  Figure 2.33: Refusing a Link.
> Currently this does not happen, e.g:
> Creating a sending link, response attach with non-null Target:
> {noformat}
> [750316387:1] -> 
> Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
>  handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
> source=Source{address='ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, distributionMode=null, filter=null, 
> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list, 
> amqp:released:list, amqp:modified:list], capabilities=null}, 
> target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=null, offeredCapabilities=null, 
> desiredCapabilities=[DELAYED_DELIVERY], properties=null}
> [750316387:1] <- 
> Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
>  handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST, 
> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
> filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, 
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, 
> properties=null}
> {noformat}
> Creating a receiving link, response attach with non-null Source:
> {noformat}
> [59324032:1] -> 
> Attach{name='qpid-jms:receiver:ID:30b1b1c9-316b-4be1-9944-15b5822a6500:1:1:1:queue',
>  handle=0, role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
> source=Source{address='queue', durable=NONE, expiryPolicy=LINK_DETACH, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
> filter=null, defaultOutcome=Modified{deliveryFailed=true, 
> undeliverableHere=null, messageAnnotations=null}, 
> outcomes=[amqp:accepted:list, amqp:rejected:list, amqp:released:list, 
> amqp:modified:list], capabilities=[queue]}, target=Target{address='null', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, capabilities=null}, unsettled=null, 
> incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null, 
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [59324032:1] <- 
> Attach{name='qpid-jms:receiver:ID:30b1b1c9-316b-4be1-9944-15b5822a6500:1:1:1:queue',
>  handle=0, role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST, 
> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
> filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, 
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, 
> properties=null}
> {noformat}
> The links are detached after this, but the non-null terminus removes the hint 
> to the peer that it is coming.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For 

[jira] [Updated] (DISPATCH-962) links established to 'unavailable' addresses are not refused correctly

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DISPATCH-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated DISPATCH-962:
--
Fix Version/s: 1.1.0

> links established to 'unavailable' addresses are not refused correctly
> --
>
> Key: DISPATCH-962
> URL: https://issues.apache.org/jira/browse/DISPATCH-962
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 1.0.0, 1.0.1, 1.1.0
>Reporter: Robbie Gemmell
>Assignee: Ted Ross
>Priority: Major
> Fix For: 1.1.0
>
>
> When setting an address as unavailable (via defaultDistribution: unavailable 
> from DISPATCH-803) the router doesn't refuse the links to it in the manner 
> the spec indicates it should.
> To indicate a link is being refused, the spec describes that the attach 
> response should contain a null target/source as appropriate, essentially 
> indicating to the peer that the detach will follow due to the error, 
> [http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp315568],
>  Figure 2.33: Refusing a Link.
> Currently this does not happen, e.g:
> Creating a sending link, response attach with non-null Target:
> {noformat}
> [750316387:1] -> 
> Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
>  handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
> source=Source{address='ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, distributionMode=null, filter=null, 
> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list, 
> amqp:released:list, amqp:modified:list], capabilities=null}, 
> target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=null, offeredCapabilities=null, 
> desiredCapabilities=[DELAYED_DELIVERY], properties=null}
> [750316387:1] <- 
> Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
>  handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST, 
> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
> filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, 
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, 
> properties=null}
> {noformat}
> Creating a receiving link, response attach with non-null Source:
> {noformat}
> [59324032:1] -> 
> Attach{name='qpid-jms:receiver:ID:30b1b1c9-316b-4be1-9944-15b5822a6500:1:1:1:queue',
>  handle=0, role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
> source=Source{address='queue', durable=NONE, expiryPolicy=LINK_DETACH, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
> filter=null, defaultOutcome=Modified{deliveryFailed=true, 
> undeliverableHere=null, messageAnnotations=null}, 
> outcomes=[amqp:accepted:list, amqp:rejected:list, amqp:released:list, 
> amqp:modified:list], capabilities=[queue]}, target=Target{address='null', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, capabilities=null}, unsettled=null, 
> incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null, 
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [59324032:1] <- 
> Attach{name='qpid-jms:receiver:ID:30b1b1c9-316b-4be1-9944-15b5822a6500:1:1:1:queue',
>  handle=0, role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST, 
> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
> filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, 
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, 
> properties=null}
> {noformat}
> The links are detached after this, but the non-null terminus removes the hint 
> to the peer that it is coming.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional 

[jira] [Assigned] (DISPATCH-962) links established to 'unavailable' addresses are not refused correctly

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DISPATCH-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross reassigned DISPATCH-962:
-

Assignee: Ted Ross  (was: Ganesh Murthy)

> links established to 'unavailable' addresses are not refused correctly
> --
>
> Key: DISPATCH-962
> URL: https://issues.apache.org/jira/browse/DISPATCH-962
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 1.0.0, 1.0.1, 1.1.0
>Reporter: Robbie Gemmell
>Assignee: Ted Ross
>Priority: Major
>
> When setting an address as unavailable (via defaultDistribution: unavailable 
> from DISPATCH-803) the router doesn't refuse the links to it in the manner 
> the spec indicates it should.
> To indicate a link is being refused, the spec describes that the attach 
> response should contain a null target/source as appropriate, essentially 
> indicating to the peer that the detach will follow due to the error, 
> [http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp315568],
>  Figure 2.33: Refusing a Link.
> Currently this does not happen, e.g:
> Creating a sending link, response attach with non-null Target:
> {noformat}
> [750316387:1] -> 
> Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
>  handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
> source=Source{address='ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, distributionMode=null, filter=null, 
> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list, 
> amqp:released:list, amqp:modified:list], capabilities=null}, 
> target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=null, offeredCapabilities=null, 
> desiredCapabilities=[DELAYED_DELIVERY], properties=null}
> [750316387:1] <- 
> Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
>  handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST, 
> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
> filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, 
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, 
> properties=null}
> {noformat}
> Creating a receiving link, response attach with non-null Source:
> {noformat}
> [59324032:1] -> 
> Attach{name='qpid-jms:receiver:ID:30b1b1c9-316b-4be1-9944-15b5822a6500:1:1:1:queue',
>  handle=0, role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
> source=Source{address='queue', durable=NONE, expiryPolicy=LINK_DETACH, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
> filter=null, defaultOutcome=Modified{deliveryFailed=true, 
> undeliverableHere=null, messageAnnotations=null}, 
> outcomes=[amqp:accepted:list, amqp:rejected:list, amqp:released:list, 
> amqp:modified:list], capabilities=[queue]}, target=Target{address='null', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, capabilities=null}, unsettled=null, 
> incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null, 
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [59324032:1] <- 
> Attach{name='qpid-jms:receiver:ID:30b1b1c9-316b-4be1-9944-15b5822a6500:1:1:1:queue',
>  handle=0, role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST, 
> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
> filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, 
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, 
> properties=null}
> {noformat}
> The links are detached after this, but the non-null terminus removes the hint 
> to the peer that it is coming.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: 

[jira] [Commented] (DISPATCH-962) links established to 'unavailable' addresses are not refused correctly

[Robbie Gemmell (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434658#comment-16434658
 ] 

Robbie Gemmell commented on DISPATCH-962:
-

As I say, I was mistakenly remembering the earliest change. It was a bug in 
proton which meant peers receiving attaches couldn't distinguish between the 
null address in a target or there not being a target. Somehow as a result, 
dispatch and qpidd were both sending a null target back when links attached to 
the anonymous relay, rather than a target with null address. Gordon changed 
proton so the two could be distinguished, and then the servers started sending 
back a target with null address as expected.

 

DISPATCH-802 is a case where Ganesh made a link be refused with null target. I 
believe there was another case but don't see it.

> links established to 'unavailable' addresses are not refused correctly
> --
>
> Key: DISPATCH-962
> URL: https://issues.apache.org/jira/browse/DISPATCH-962
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 1.0.0, 1.0.1, 1.1.0
>Reporter: Robbie Gemmell
>Assignee: Ganesh Murthy
>Priority: Major
>
> When setting an address as unavailable (via defaultDistribution: unavailable 
> from DISPATCH-803) the router doesn't refuse the links to it in the manner 
> the spec indicates it should.
> To indicate a link is being refused, the spec describes that the attach 
> response should contain a null target/source as appropriate, essentially 
> indicating to the peer that the detach will follow due to the error, 
> [http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp315568],
>  Figure 2.33: Refusing a Link.
> Currently this does not happen, e.g:
> Creating a sending link, response attach with non-null Target:
> {noformat}
> [750316387:1] -> 
> Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
>  handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
> source=Source{address='ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, distributionMode=null, filter=null, 
> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list, 
> amqp:released:list, amqp:modified:list], capabilities=null}, 
> target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=null, offeredCapabilities=null, 
> desiredCapabilities=[DELAYED_DELIVERY], properties=null}
> [750316387:1] <- 
> Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
>  handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST, 
> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
> filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, 
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, 
> properties=null}
> {noformat}
> Creating a receiving link, response attach with non-null Source:
> {noformat}
> [59324032:1] -> 
> Attach{name='qpid-jms:receiver:ID:30b1b1c9-316b-4be1-9944-15b5822a6500:1:1:1:queue',
>  handle=0, role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
> source=Source{address='queue', durable=NONE, expiryPolicy=LINK_DETACH, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
> filter=null, defaultOutcome=Modified{deliveryFailed=true, 
> undeliverableHere=null, messageAnnotations=null}, 
> outcomes=[amqp:accepted:list, amqp:rejected:list, amqp:released:list, 
> amqp:modified:list], capabilities=[queue]}, target=Target{address='null', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, capabilities=null}, unsettled=null, 
> incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null, 
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [59324032:1] <- 
> Attach{name='qpid-jms:receiver:ID:30b1b1c9-316b-4be1-9944-15b5822a6500:1:1:1:queue',
>  handle=0, role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST, 
> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
> filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, 
> 

[jira] [Commented] (DISPATCH-962) links established to 'unavailable' addresses are not refused correctly

[Ted Ross (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434653#comment-16434653
 ] 

Ted Ross commented on DISPATCH-962:
---

Hang on... I may have found the hook that's needed.  If so, this can be a 
Dispatch fix.

 

> links established to 'unavailable' addresses are not refused correctly
> --
>
> Key: DISPATCH-962
> URL: https://issues.apache.org/jira/browse/DISPATCH-962
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 1.0.0, 1.0.1, 1.1.0
>Reporter: Robbie Gemmell
>Assignee: Ganesh Murthy
>Priority: Major
>
> When setting an address as unavailable (via defaultDistribution: unavailable 
> from DISPATCH-803) the router doesn't refuse the links to it in the manner 
> the spec indicates it should.
> To indicate a link is being refused, the spec describes that the attach 
> response should contain a null target/source as appropriate, essentially 
> indicating to the peer that the detach will follow due to the error, 
> [http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp315568],
>  Figure 2.33: Refusing a Link.
> Currently this does not happen, e.g:
> Creating a sending link, response attach with non-null Target:
> {noformat}
> [750316387:1] -> 
> Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
>  handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
> source=Source{address='ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, distributionMode=null, filter=null, 
> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list, 
> amqp:released:list, amqp:modified:list], capabilities=null}, 
> target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=null, offeredCapabilities=null, 
> desiredCapabilities=[DELAYED_DELIVERY], properties=null}
> [750316387:1] <- 
> Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
>  handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST, 
> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
> filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, 
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, 
> properties=null}
> {noformat}
> Creating a receiving link, response attach with non-null Source:
> {noformat}
> [59324032:1] -> 
> Attach{name='qpid-jms:receiver:ID:30b1b1c9-316b-4be1-9944-15b5822a6500:1:1:1:queue',
>  handle=0, role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
> source=Source{address='queue', durable=NONE, expiryPolicy=LINK_DETACH, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
> filter=null, defaultOutcome=Modified{deliveryFailed=true, 
> undeliverableHere=null, messageAnnotations=null}, 
> outcomes=[amqp:accepted:list, amqp:rejected:list, amqp:released:list, 
> amqp:modified:list], capabilities=[queue]}, target=Target{address='null', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, capabilities=null}, unsettled=null, 
> incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null, 
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [59324032:1] <- 
> Attach{name='qpid-jms:receiver:ID:30b1b1c9-316b-4be1-9944-15b5822a6500:1:1:1:queue',
>  handle=0, role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST, 
> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
> filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, 
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, 
> properties=null}
> {noformat}
> The links are detached after this, but the non-null terminus removes the hint 
> to the peer that it is coming.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, 

[jira] [Comment Edited] (DISPATCH-962) links established to 'unavailable' addresses are not refused correctly

[Ted Ross (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434647#comment-16434647
 ] 

Ted Ross edited comment on DISPATCH-962 at 4/11/18 10:15 PM:
-

_it seems Dispatch can ensure the correct behaviour occurs for its clients._

I don't believe this is the case.  The Proton API provides access by pointer to 
the always-existing {remote_}{target|source} for a link.  There is no provision 
in the API to nullify these pointers or to otherwise indicate that the source 
or target should not be present.

Do you have a reference to Gordon's null source/target fix?



was (Author: tedross):
I don't believe this is the case.  The Proton API provides access by pointer to 
the always-existing {remote_}{target|source} for a link.  There is no provision 
in the API to nullify these pointers or to otherwise indicate that the source 
or target should not be present.

Do you have a reference to Gordon's null source/target fix?


> links established to 'unavailable' addresses are not refused correctly
> --
>
> Key: DISPATCH-962
> URL: https://issues.apache.org/jira/browse/DISPATCH-962
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 1.0.0, 1.0.1, 1.1.0
>Reporter: Robbie Gemmell
>Assignee: Ganesh Murthy
>Priority: Major
>
> When setting an address as unavailable (via defaultDistribution: unavailable 
> from DISPATCH-803) the router doesn't refuse the links to it in the manner 
> the spec indicates it should.
> To indicate a link is being refused, the spec describes that the attach 
> response should contain a null target/source as appropriate, essentially 
> indicating to the peer that the detach will follow due to the error, 
> [http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp315568],
>  Figure 2.33: Refusing a Link.
> Currently this does not happen, e.g:
> Creating a sending link, response attach with non-null Target:
> {noformat}
> [750316387:1] -> 
> Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
>  handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
> source=Source{address='ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, distributionMode=null, filter=null, 
> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list, 
> amqp:released:list, amqp:modified:list], capabilities=null}, 
> target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=null, offeredCapabilities=null, 
> desiredCapabilities=[DELAYED_DELIVERY], properties=null}
> [750316387:1] <- 
> Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
>  handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST, 
> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
> filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, 
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, 
> properties=null}
> {noformat}
> Creating a receiving link, response attach with non-null Source:
> {noformat}
> [59324032:1] -> 
> Attach{name='qpid-jms:receiver:ID:30b1b1c9-316b-4be1-9944-15b5822a6500:1:1:1:queue',
>  handle=0, role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
> source=Source{address='queue', durable=NONE, expiryPolicy=LINK_DETACH, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
> filter=null, defaultOutcome=Modified{deliveryFailed=true, 
> undeliverableHere=null, messageAnnotations=null}, 
> outcomes=[amqp:accepted:list, amqp:rejected:list, amqp:released:list, 
> amqp:modified:list], capabilities=[queue]}, target=Target{address='null', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, capabilities=null}, unsettled=null, 
> incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null, 
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [59324032:1] <- 
> Attach{name='qpid-jms:receiver:ID:30b1b1c9-316b-4be1-9944-15b5822a6500:1:1:1:queue',
>  handle=0, role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST, 
> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> 

[jira] [Commented] (DISPATCH-962) links established to 'unavailable' addresses are not refused correctly

[Ted Ross (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434647#comment-16434647
 ] 

Ted Ross commented on DISPATCH-962:
---

I don't believe this is the case.  The Proton API provides access by pointer to 
the always-existing {remote_}{target|source} for a link.  There is no provision 
in the API to nullify these pointers or to otherwise indicate that the source 
or target should not be present.

Do you have a reference to Gordon's null source/target fix?


> links established to 'unavailable' addresses are not refused correctly
> --
>
> Key: DISPATCH-962
> URL: https://issues.apache.org/jira/browse/DISPATCH-962
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 1.0.0, 1.0.1, 1.1.0
>Reporter: Robbie Gemmell
>Assignee: Ganesh Murthy
>Priority: Major
>
> When setting an address as unavailable (via defaultDistribution: unavailable 
> from DISPATCH-803) the router doesn't refuse the links to it in the manner 
> the spec indicates it should.
> To indicate a link is being refused, the spec describes that the attach 
> response should contain a null target/source as appropriate, essentially 
> indicating to the peer that the detach will follow due to the error, 
> [http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp315568],
>  Figure 2.33: Refusing a Link.
> Currently this does not happen, e.g:
> Creating a sending link, response attach with non-null Target:
> {noformat}
> [750316387:1] -> 
> Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
>  handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
> source=Source{address='ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, distributionMode=null, filter=null, 
> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list, 
> amqp:released:list, amqp:modified:list], capabilities=null}, 
> target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=null, offeredCapabilities=null, 
> desiredCapabilities=[DELAYED_DELIVERY], properties=null}
> [750316387:1] <- 
> Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
>  handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST, 
> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
> filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, 
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, 
> properties=null}
> {noformat}
> Creating a receiving link, response attach with non-null Source:
> {noformat}
> [59324032:1] -> 
> Attach{name='qpid-jms:receiver:ID:30b1b1c9-316b-4be1-9944-15b5822a6500:1:1:1:queue',
>  handle=0, role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
> source=Source{address='queue', durable=NONE, expiryPolicy=LINK_DETACH, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
> filter=null, defaultOutcome=Modified{deliveryFailed=true, 
> undeliverableHere=null, messageAnnotations=null}, 
> outcomes=[amqp:accepted:list, amqp:rejected:list, amqp:released:list, 
> amqp:modified:list], capabilities=[queue]}, target=Target{address='null', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, capabilities=null}, unsettled=null, 
> incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null, 
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [59324032:1] <- 
> Attach{name='qpid-jms:receiver:ID:30b1b1c9-316b-4be1-9944-15b5822a6500:1:1:1:queue',
>  handle=0, role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST, 
> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
> filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, 
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, 
> properties=null}
> {noformat}
> The links are 

[jira] [Commented] (DISPATCH-962) links established to 'unavailable' addresses are not refused correctly

[Robbie Gemmell (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434642#comment-16434642
 ] 

Robbie Gemmell commented on DISPATCH-962:
-

Upon checking, the first thing I recalled reporting was actually different, and 
more like the reverse of this case; Dispatch wasn't setting a target at all in 
a case where it should have (with the address not set, as seen here) while 
senders attached to the anonymous relay. That issue was the one Gordon fixed 
with a change to Proton via PROTON-1042.

> links established to 'unavailable' addresses are not refused correctly
> --
>
> Key: DISPATCH-962
> URL: https://issues.apache.org/jira/browse/DISPATCH-962
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 1.0.0, 1.0.1, 1.1.0
>Reporter: Robbie Gemmell
>Assignee: Ganesh Murthy
>Priority: Major
>
> When setting an address as unavailable (via defaultDistribution: unavailable 
> from DISPATCH-803) the router doesn't refuse the links to it in the manner 
> the spec indicates it should.
> To indicate a link is being refused, the spec describes that the attach 
> response should contain a null target/source as appropriate, essentially 
> indicating to the peer that the detach will follow due to the error, 
> [http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp315568],
>  Figure 2.33: Refusing a Link.
> Currently this does not happen, e.g:
> Creating a sending link, response attach with non-null Target:
> {noformat}
> [750316387:1] -> 
> Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
>  handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
> source=Source{address='ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, distributionMode=null, filter=null, 
> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list, 
> amqp:released:list, amqp:modified:list], capabilities=null}, 
> target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=null, offeredCapabilities=null, 
> desiredCapabilities=[DELAYED_DELIVERY], properties=null}
> [750316387:1] <- 
> Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
>  handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST, 
> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
> filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, 
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, 
> properties=null}
> {noformat}
> Creating a receiving link, response attach with non-null Source:
> {noformat}
> [59324032:1] -> 
> Attach{name='qpid-jms:receiver:ID:30b1b1c9-316b-4be1-9944-15b5822a6500:1:1:1:queue',
>  handle=0, role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
> source=Source{address='queue', durable=NONE, expiryPolicy=LINK_DETACH, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
> filter=null, defaultOutcome=Modified{deliveryFailed=true, 
> undeliverableHere=null, messageAnnotations=null}, 
> outcomes=[amqp:accepted:list, amqp:rejected:list, amqp:released:list, 
> amqp:modified:list], capabilities=[queue]}, target=Target{address='null', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, capabilities=null}, unsettled=null, 
> incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null, 
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [59324032:1] <- 
> Attach{name='qpid-jms:receiver:ID:30b1b1c9-316b-4be1-9944-15b5822a6500:1:1:1:queue',
>  handle=0, role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST, 
> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
> filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, 
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, 
> properties=null}
> 

[jira] [Commented] (DISPATCH-962) links established to 'unavailable' addresses are not refused correctly

[Robbie Gemmell (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434629#comment-16434629
 ] 

Robbie Gemmell commented on DISPATCH-962:
-

The presence of address='null' will just be part of proton-j's string 
representation of the source object, it isnt jumping through hoops to avoid 
printing "address=..." if null (not-set) is the value of the address field, but 
rather showing the current value (in Java terms) of the field, and so the 
string rep presumably cant differentiate between string "null" and 
address-not-set null.

I am arguing that the source (for consumers) or target (for producers) should 
not be present in the returned attach when refusing the link, per the the spec 
this is how its indicated that no terminus exists and the link is going to be 
detached.

I have made similar reports a few times before against Dispatch. I believe the 
first of those was handled through a change within proton by Gordon around 
setting a null source/target, but the others were handled with changes in 
Dispatch. Maybe there is still some related proton-c behaviour that can be 
improved, but it seems Dispatch can ensure the correct behaviour occurs for its 
clients.

> links established to 'unavailable' addresses are not refused correctly
> --
>
> Key: DISPATCH-962
> URL: https://issues.apache.org/jira/browse/DISPATCH-962
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 1.0.0, 1.0.1, 1.1.0
>Reporter: Robbie Gemmell
>Assignee: Ganesh Murthy
>Priority: Major
>
> When setting an address as unavailable (via defaultDistribution: unavailable 
> from DISPATCH-803) the router doesn't refuse the links to it in the manner 
> the spec indicates it should.
> To indicate a link is being refused, the spec describes that the attach 
> response should contain a null target/source as appropriate, essentially 
> indicating to the peer that the detach will follow due to the error, 
> [http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp315568],
>  Figure 2.33: Refusing a Link.
> Currently this does not happen, e.g:
> Creating a sending link, response attach with non-null Target:
> {noformat}
> [750316387:1] -> 
> Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
>  handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
> source=Source{address='ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, distributionMode=null, filter=null, 
> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list, 
> amqp:released:list, amqp:modified:list], capabilities=null}, 
> target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=null, offeredCapabilities=null, 
> desiredCapabilities=[DELAYED_DELIVERY], properties=null}
> [750316387:1] <- 
> Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
>  handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST, 
> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
> filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, 
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, 
> properties=null}
> {noformat}
> Creating a receiving link, response attach with non-null Source:
> {noformat}
> [59324032:1] -> 
> Attach{name='qpid-jms:receiver:ID:30b1b1c9-316b-4be1-9944-15b5822a6500:1:1:1:queue',
>  handle=0, role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
> source=Source{address='queue', durable=NONE, expiryPolicy=LINK_DETACH, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
> filter=null, defaultOutcome=Modified{deliveryFailed=true, 
> undeliverableHere=null, messageAnnotations=null}, 
> outcomes=[amqp:accepted:list, amqp:rejected:list, amqp:released:list, 
> amqp:modified:list], capabilities=[queue]}, target=Target{address='null', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, capabilities=null}, unsettled=null, 
> incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null, 
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [59324032:1] <- 
> 

[jira] [Commented] (QPID-8160) [Broker-J] [AMQP 1.0] AccessControlException when creating sending link reported as amqp:internal-error rather than amqp:unauthorised-access

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-8160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434609#comment-16434609
 ] 

ASF subversion and git services commented on QPID-8160:
---

Commit 0ec8be159935b6f84675845965b184f1cfa3e8aa in qpid-broker-j's branch 
refs/heads/master from [~k-wall]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=0ec8be1 ]

QPID-8160: [Broker-J] Ensure that AccessControlException during sending link 
creation is reported with an amqp:unauthorized-access


>  [Broker-J] [AMQP 1.0] AccessControlException when creating sending link 
> reported as  amqp:internal-error rather than amqp:unauthorised-access
> --
>
> Key: QPID-8160
> URL: https://issues.apache.org/jira/browse/QPID-8160
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1
>Reporter: Keith Wall
>Priority: Minor
>
> If the Broker tries to create a sending link from a source but the user has 
> insufficient permissions for that source, I expect the {{detach}} to use 
> error {{amqp:unauthorised-access}}. This currently does not happen, the 
> Broker sends {{amqp:amqp:internal-error}} instead.
> {noformat}
> [511142734:1] <- Detach{handle=1, closed=true, 
> error=Error{condition=amqp:internal-error, description='Permission CREATE is 
> denied for : Consumer 
> '4|1|qpid-jms:receiver:ID:2a653090-1dbc-4433-955d-791b52540128:1:1:1:guestqueue'
>  on Queue 'guestqueue'', info=null}}{noformat}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (DISPATCH-962) links established to 'unavailable' addresses are not refused correctly

[Ted Ross (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434586#comment-16434586
 ] 

Ted Ross commented on DISPATCH-962:
---

The traces provided show that the returned attach contains terminus addresses 
of 'null' (as though the address were changed to the string "null").  Is this a 
feature of JMS tracing?  When I tried to reproduce this behavior, I found that 
the address fields in the termini were not present (i.e. truly null).  The 
source/target termini were, however, present.

Are you arguing that the return attaches should not contain any source or 
target termini records in the performative?

Qpid Dispatch uses the Proton-C API as follows:  If an incoming attach is going 
to be rejected, it does not copy the remote termini to the local termini (as it 
would if accepting the link) and closes the link.  It relies on Proton to 
properly issue the empty attach followed by a detach.  The Proton API provides 
no way to nullify a source or target.

If this is indeed a bug, is it not a Proton-C bug?


> links established to 'unavailable' addresses are not refused correctly
> --
>
> Key: DISPATCH-962
> URL: https://issues.apache.org/jira/browse/DISPATCH-962
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 1.0.0, 1.0.1, 1.1.0
>Reporter: Robbie Gemmell
>Assignee: Ganesh Murthy
>Priority: Major
>
> When setting an address as unavailable (via defaultDistribution: unavailable 
> from DISPATCH-803) the router doesn't refuse the links to it in the manner 
> the spec indicates it should.
> To indicate a link is being refused, the spec describes that the attach 
> response should contain a null target/source as appropriate, essentially 
> indicating to the peer that the detach will follow due to the error, 
> [http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp315568],
>  Figure 2.33: Refusing a Link.
> Currently this does not happen, e.g:
> Creating a sending link, response attach with non-null Target:
> {noformat}
> [750316387:1] -> 
> Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
>  handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
> source=Source{address='ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, distributionMode=null, filter=null, 
> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list, 
> amqp:released:list, amqp:modified:list], capabilities=null}, 
> target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=null, offeredCapabilities=null, 
> desiredCapabilities=[DELAYED_DELIVERY], properties=null}
> [750316387:1] <- 
> Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
>  handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST, 
> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
> filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, 
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, 
> properties=null}
> {noformat}
> Creating a receiving link, response attach with non-null Source:
> {noformat}
> [59324032:1] -> 
> Attach{name='qpid-jms:receiver:ID:30b1b1c9-316b-4be1-9944-15b5822a6500:1:1:1:queue',
>  handle=0, role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
> source=Source{address='queue', durable=NONE, expiryPolicy=LINK_DETACH, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
> filter=null, defaultOutcome=Modified{deliveryFailed=true, 
> undeliverableHere=null, messageAnnotations=null}, 
> outcomes=[amqp:accepted:list, amqp:rejected:list, amqp:released:list, 
> amqp:modified:list], capabilities=[queue]}, target=Target{address='null', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, capabilities=null}, unsettled=null, 
> incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null, 
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [59324032:1] <- 
> Attach{name='qpid-jms:receiver:ID:30b1b1c9-316b-4be1-9944-15b5822a6500:1:1:1:queue',
>  handle=0, role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST, 
> 

[jira] [Commented] (QPIDJMS-377) Update testing dependencies (ActiveMQ, MiniKDC and Mockito)

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPIDJMS-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434581#comment-16434581
 ] 

ASF subversion and git services commented on QPIDJMS-377:
-

Commit 4cd717d7252022994f81b35134aad6d1071b07e8 in qpid-jms's branch 
refs/heads/master from [~tabish121]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=4cd717d ]

QPIDJMS-377 Update test dependencies to latest

ActiveMQ, MiniKDC and Mockito also update Jacoco plugin to latest


> Update testing dependencies (ActiveMQ, MiniKDC and Mockito)
> ---
>
> Key: QPIDJMS-377
> URL: https://issues.apache.org/jira/browse/QPIDJMS-377
> Project: Qpid JMS
>  Issue Type: Task
>  Components: qpid-jms-client
>Affects Versions: 0.31.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Trivial
> Fix For: 0.32.0
>
>
> Update test dependencies to latest versions



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (QPIDJMS-377) Update testing dependencies (ActiveMQ, MiniKDC and Mockito)

[Timothy Bish (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPIDJMS-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Bish resolved QPIDJMS-377.
--
Resolution: Fixed

> Update testing dependencies (ActiveMQ, MiniKDC and Mockito)
> ---
>
> Key: QPIDJMS-377
> URL: https://issues.apache.org/jira/browse/QPIDJMS-377
> Project: Qpid JMS
>  Issue Type: Task
>  Components: qpid-jms-client
>Affects Versions: 0.31.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Trivial
> Fix For: 0.32.0
>
>
> Update test dependencies to latest versions



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (QPIDJMS-377) Update testing dependencies (ActiveMQ, MiniKDC and Mockito)

[Timothy Bish (JIRA)]

Timothy Bish created QPIDJMS-377:


 Summary: Update testing dependencies (ActiveMQ, MiniKDC and 
Mockito)
 Key: QPIDJMS-377
 URL: https://issues.apache.org/jira/browse/QPIDJMS-377
 Project: Qpid JMS
  Issue Type: Task
  Components: qpid-jms-client
Affects Versions: 0.31.0
Reporter: Timothy Bish
Assignee: Timothy Bish
 Fix For: 0.32.0


Update test dependencies to latest versions



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-8159) [Broker-J] Upgrade Jackson from 2.9.4 to 2.9.5 (CVE-2018-7489)

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-8159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-8159:
-
Description: 
QPID-8136 upgrade Jackson on master from 2.8.7 to 2.9.4 in response to 
CVE-2017-7525. However it is now known that the blacklist included in 2.9.4 was 
incomplete. This is the subject of CVE-2018-7489.

This problem affects only the master branch.

  was:
QPID-8136 upgrade Jackson on master from 2.8.7 to 2.9.4 in response to 
CVE-2017-7525.  However it is now know that the blacklist include in 2.9.4 was 
incomplete.This is the subject of CVE-2018-7489.

This problem affects only the master branch.



> [Broker-J] Upgrade Jackson from 2.9.4 to 2.9.5 (CVE-2018-7489)
> --
>
> Key: QPID-8159
> URL: https://issues.apache.org/jira/browse/QPID-8159
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Major
>
> QPID-8136 upgrade Jackson on master from 2.8.7 to 2.9.4 in response to 
> CVE-2017-7525. However it is now known that the blacklist included in 2.9.4 
> was incomplete. This is the subject of CVE-2018-7489.
> This problem affects only the master branch.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Closed] (PROTON-1410) Move MessageImpl::TLS to an utility class

[Timothy Bish (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Bish closed PROTON-1410.

Resolution: Won't Fix

> Move MessageImpl::TLS to an utility class
> -
>
> Key: PROTON-1410
> URL: https://issues.apache.org/jira/browse/PROTON-1410
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-j
>Reporter: clebert suconic
>Priority: Major
>
> I have a need to create a special Message on Artemis, that will only parse 
> the Header and send everything else as a byte array.
> Instead of duplicating the TLS logic, I would like to move this to its own 
> class so it could be reused.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (DISPATCH-964) Auto-links are closed with an incorrect error indication

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DISPATCH-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross resolved DISPATCH-964.
---
Resolution: Fixed

> Auto-links are closed with an incorrect error indication
> 
>
> Key: DISPATCH-964
> URL: https://issues.apache.org/jira/browse/DISPATCH-964
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.0.1
>Reporter: Ganesh Murthy
>Assignee: Ted Ross
>Priority: Major
> Fix For: 1.1.0
>
>
> When auto-links are closed as a result of a management delete of an auto-link 
> object, the detach frame carries the error "qd:routed-link-lost".  This is 
> incorrect since these are not even routed links.  These detaches should carry 
> no error.  This defect causes the following symptom:
> There is a test called test_06_manage_autolinks in system_tests_autolinks.py. 
> The test tries to create 5 auto links and delete 5 auto links. Upon deletion 
> it expects 5 detaches to arrive but sometimes receives less than 5 detaches 
> leading to test failure. Upon examining the frame trace, it looks like the 
> test is closing a connection upon receiving a detach with an error. Proton 
> might be closing the connection because it does not know how to handle the 
> error. Here is the frame trace from the test
>  
> {noformat}
> test_06_manage_autolinks (system_tests_autolinks.AutolinkTest) ... 
> [0x55f6d2763de0]:  -> SASL
> [0x55f6d2770dc0]:  -> SASL
> [0x55f6d2763de0]:  <- SASL
> [0x55f6d2763de0]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]]
> [0x55f6d2763de0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, 
> initial-response=b"anonymous@localhost.localdomain"]
> [0x55f6d2770dc0]:  <- SASL
> [0x55f6d2770dc0]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]]
> [0x55f6d2770dc0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, 
> initial-response=b"anonymous@localhost.localdomain"]
> [0x55f6d2763de0]:0 <- @sasl-outcome(68) [code=0]
> [0x55f6d2763de0]:  -> AMQP
> [0x55f6d2763de0]:0 -> @open(16) [container-id="container.new", 
> hostname="0.0.0.0", channel-max=32767]
> [0x55f6d2770dc0]:0 <- @sasl-outcome(68) [code=0]
> [0x55f6d2770dc0]:  -> AMQP
> [0x55f6d2770dc0]:0 -> @open(16) [container-id="container.new", 
> hostname="0.0.0.0", channel-max=32767]
> [0x55f6d2770dc0]:0 -> @begin(17) [next-outgoing-id=0, 
> incoming-window=2147483647, outgoing-window=2147483647]
> [0x55f6d2770dc0]:0 -> @attach(18) 
> [name="container.new-5ffbadef-6b56-44c4-920c-d5536fd65862", handle=0, 
> role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) 
> [durable=0, timeout=0, dynamic=true], target=@target(41) [durable=0, 
> timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0]
> [0x55f6d2770dc0]:0 -> @attach(18) [name="container.new-$management", 
> 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="$management", durable=0, timeout=0, dynamic=false], 
> initial-delivery-count=0, max-message-size=0]
> [0x55f6d2770dc0]:0 -> @flow(19) [incoming-window=2147483647, 
> next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0, 
> link-credit=10, drain=false]
> [0x55f6d2763de0]:  <- AMQP
> [0x55f6d2763de0]:0 <- @open(16) [container-id="QDR", max-frame-size=16384, 
> channel-max=32767, idle-time-out=6, 
> offered-capabilities=:"ANONYMOUS-RELAY", 
> properties={:product="qpid-dispatch-router", :version="1.0.0"}]
> [0x55f6d2770dc0]:  <- AMQP
> [0x55f6d2770dc0]:0 <- @open(16) [container-id="QDR", max-frame-size=16384, 
> channel-max=32767, idle-time-out=6, 
> offered-capabilities=:"ANONYMOUS-RELAY", 
> properties={:product="qpid-dispatch-router", :version="1.0.0"}]
> [0x55f6d2770dc0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=0, 
> incoming-window=2147483647, outgoing-window=2147483647]
> [0x55f6d2770dc0]:0 <- @attach(18) 
> [name="container.new-5ffbadef-6b56-44c4-920c-d5536fd65862", handle=0, 
> role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) 
> [address="amqp:/_topo/0/QDR/temp.MT8K7VE3i2Y8y7_", durable=0, timeout=0, 
> dynamic=true], target=@target(41) [durable=0, timeout=0, dynamic=false], 
> initial-delivery-count=0, max-message-size=0]
> [0x55f6d2770dc0]:0 <- @attach(18) [name="container.new-$management", 
> 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="$management", durable=0, timeout=0, dynamic=false], 
> initial-delivery-count=0, max-message-size=0]
> [0x55f6d2770dc0]:0 <- @flow(19) [next-incoming-id=0, 
> incoming-window=2147483647, next-outgoing-id=0, outgoing-window=2147483647, 
> handle=1, delivery-count=0, 

[jira] [Commented] (DISPATCH-964) Auto-links are closed with an incorrect error indication

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434521#comment-16434521
 ] 

ASF subversion and git services commented on DISPATCH-964:
--

Commit 0ad6e6ff54443bcfaeac7ca5bcbe6081be2c17e7 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=0ad6e6f ]

DISPATCH-964 - Remove the spurious error indication on the closing of 
auto-links.  Add test coverage for this condition.


> Auto-links are closed with an incorrect error indication
> 
>
> Key: DISPATCH-964
> URL: https://issues.apache.org/jira/browse/DISPATCH-964
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.0.1
>Reporter: Ganesh Murthy
>Assignee: Ted Ross
>Priority: Major
> Fix For: 1.1.0
>
>
> When auto-links are closed as a result of a management delete of an auto-link 
> object, the detach frame carries the error "qd:routed-link-lost".  This is 
> incorrect since these are not even routed links.  These detaches should carry 
> no error.  This defect causes the following symptom:
> There is a test called test_06_manage_autolinks in system_tests_autolinks.py. 
> The test tries to create 5 auto links and delete 5 auto links. Upon deletion 
> it expects 5 detaches to arrive but sometimes receives less than 5 detaches 
> leading to test failure. Upon examining the frame trace, it looks like the 
> test is closing a connection upon receiving a detach with an error. Proton 
> might be closing the connection because it does not know how to handle the 
> error. Here is the frame trace from the test
>  
> {noformat}
> test_06_manage_autolinks (system_tests_autolinks.AutolinkTest) ... 
> [0x55f6d2763de0]:  -> SASL
> [0x55f6d2770dc0]:  -> SASL
> [0x55f6d2763de0]:  <- SASL
> [0x55f6d2763de0]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]]
> [0x55f6d2763de0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, 
> initial-response=b"anonymous@localhost.localdomain"]
> [0x55f6d2770dc0]:  <- SASL
> [0x55f6d2770dc0]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]]
> [0x55f6d2770dc0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, 
> initial-response=b"anonymous@localhost.localdomain"]
> [0x55f6d2763de0]:0 <- @sasl-outcome(68) [code=0]
> [0x55f6d2763de0]:  -> AMQP
> [0x55f6d2763de0]:0 -> @open(16) [container-id="container.new", 
> hostname="0.0.0.0", channel-max=32767]
> [0x55f6d2770dc0]:0 <- @sasl-outcome(68) [code=0]
> [0x55f6d2770dc0]:  -> AMQP
> [0x55f6d2770dc0]:0 -> @open(16) [container-id="container.new", 
> hostname="0.0.0.0", channel-max=32767]
> [0x55f6d2770dc0]:0 -> @begin(17) [next-outgoing-id=0, 
> incoming-window=2147483647, outgoing-window=2147483647]
> [0x55f6d2770dc0]:0 -> @attach(18) 
> [name="container.new-5ffbadef-6b56-44c4-920c-d5536fd65862", handle=0, 
> role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) 
> [durable=0, timeout=0, dynamic=true], target=@target(41) [durable=0, 
> timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0]
> [0x55f6d2770dc0]:0 -> @attach(18) [name="container.new-$management", 
> 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="$management", durable=0, timeout=0, dynamic=false], 
> initial-delivery-count=0, max-message-size=0]
> [0x55f6d2770dc0]:0 -> @flow(19) [incoming-window=2147483647, 
> next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0, 
> link-credit=10, drain=false]
> [0x55f6d2763de0]:  <- AMQP
> [0x55f6d2763de0]:0 <- @open(16) [container-id="QDR", max-frame-size=16384, 
> channel-max=32767, idle-time-out=6, 
> offered-capabilities=:"ANONYMOUS-RELAY", 
> properties={:product="qpid-dispatch-router", :version="1.0.0"}]
> [0x55f6d2770dc0]:  <- AMQP
> [0x55f6d2770dc0]:0 <- @open(16) [container-id="QDR", max-frame-size=16384, 
> channel-max=32767, idle-time-out=6, 
> offered-capabilities=:"ANONYMOUS-RELAY", 
> properties={:product="qpid-dispatch-router", :version="1.0.0"}]
> [0x55f6d2770dc0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=0, 
> incoming-window=2147483647, outgoing-window=2147483647]
> [0x55f6d2770dc0]:0 <- @attach(18) 
> [name="container.new-5ffbadef-6b56-44c4-920c-d5536fd65862", handle=0, 
> role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) 
> [address="amqp:/_topo/0/QDR/temp.MT8K7VE3i2Y8y7_", durable=0, timeout=0, 
> dynamic=true], target=@target(41) [durable=0, timeout=0, dynamic=false], 
> initial-delivery-count=0, max-message-size=0]
> [0x55f6d2770dc0]:0 <- @attach(18) [name="container.new-$management", 
> handle=1, role=true, 

[jira] [Resolved] (PROTON-1672) Large deliveries comprising many transfers are handled inefficiently

[Timothy Bish (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Bish resolved PROTON-1672.
--
Resolution: Fixed

> Large deliveries comprising many transfers are handled inefficiently
> 
>
> Key: PROTON-1672
> URL: https://issues.apache.org/jira/browse/PROTON-1672
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: proton-j-0.23.0
>Reporter: Keith Wall
>Assignee: Timothy Bish
>Priority: Major
> Fix For: proton-j-0.27.0
>
> Attachments: JProfiler_PROTON-1672.tiff
>
>
> Running performance tests using Qpid Broker J and Qpid JMS Client (0.26.0) 
> shows that receipt of large messages is very slow in comparison with the send 
> of the same message.   For instance, sending 300MiB bytes message takes 5 
> seconds on my laptop.  The receipt takes 97 seconds.
> Instrumenting the client stack shows an obvious hot-spot in Proton-J.  
> {{org.apache.qpid.proton.engine.impl.TransportSession#handleTransfer}} 
> re-allocates/array copies the entire delivery buffer for ever transfer that 
> comprises it.  This leads to a non-linear loss of performance.   The stack 
> include Proton-J 0.23.0, but is looks like this code is unchanged.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (PROTON-1672) Large deliveries comprising many transfers are handled inefficiently

[Timothy Bish (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Bish updated PROTON-1672:
-
Fix Version/s: proton-j-0.27.0

> Large deliveries comprising many transfers are handled inefficiently
> 
>
> Key: PROTON-1672
> URL: https://issues.apache.org/jira/browse/PROTON-1672
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: proton-j-0.23.0
>Reporter: Keith Wall
>Assignee: Timothy Bish
>Priority: Major
> Fix For: proton-j-0.27.0
>
> Attachments: JProfiler_PROTON-1672.tiff
>
>
> Running performance tests using Qpid Broker J and Qpid JMS Client (0.26.0) 
> shows that receipt of large messages is very slow in comparison with the send 
> of the same message.   For instance, sending 300MiB bytes message takes 5 
> seconds on my laptop.  The receipt takes 97 seconds.
> Instrumenting the client stack shows an obvious hot-spot in Proton-J.  
> {{org.apache.qpid.proton.engine.impl.TransportSession#handleTransfer}} 
> re-allocates/array copies the entire delivery buffer for ever transfer that 
> comprises it.  This leads to a non-linear loss of performance.   The stack 
> include Proton-J 0.23.0, but is looks like this code is unchanged.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1672) Large deliveries comprising many transfers are handled inefficiently

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434486#comment-16434486
 ] 

ASF subversion and git services commented on PROTON-1672:
-

Commit ec5547152fed5a74afbe11bbb33541a2cb149fa4 in qpid-proton-j's branch 
refs/heads/master from [~tabish121]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton-j.git;h=ec55471 ]

PROTON-1672 Handle multi-frame transfer payloads more efficiently

Replace reallocation and consolidation of transfer payloads when
multiple framed transfers are inbound.  Creates a
CompositeReadableBuffer that can be used to house the assembled payload
for use in the decoder. The decoder implementation refactored to handle
ReadableBuffer as the source of bytes as well as ByteBuffer.  Adds
no-copy method variants to the Sender and Receiver API such that clients
or servers can process inbound and outbound deliveries without copying
the payloads when it is known to be safe not to copy.

Adds tests and jacoco reports to validate test coverage.

> Large deliveries comprising many transfers are handled inefficiently
> 
>
> Key: PROTON-1672
> URL: https://issues.apache.org/jira/browse/PROTON-1672
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: proton-j-0.23.0
>Reporter: Keith Wall
>Assignee: Timothy Bish
>Priority: Major
> Attachments: JProfiler_PROTON-1672.tiff
>
>
> Running performance tests using Qpid Broker J and Qpid JMS Client (0.26.0) 
> shows that receipt of large messages is very slow in comparison with the send 
> of the same message.   For instance, sending 300MiB bytes message takes 5 
> seconds on my laptop.  The receipt takes 97 seconds.
> Instrumenting the client stack shows an obvious hot-spot in Proton-J.  
> {{org.apache.qpid.proton.engine.impl.TransportSession#handleTransfer}} 
> re-allocates/array copies the entire delivery buffer for ever transfer that 
> comprises it.  This leads to a non-linear loss of performance.   The stack 
> include Proton-J 0.23.0, but is looks like this code is unchanged.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (DISPATCH-965) Python 3 compatibiliy

[Ken Giusti (JIRA)]

Ken Giusti created DISPATCH-965:
---

 Summary: Python 3 compatibiliy
 Key: DISPATCH-965
 URL: https://issues.apache.org/jira/browse/DISPATCH-965
 Project: Qpid Dispatch
  Issue Type: Improvement
  Components: Routing Engine, Tests, Tools
Affects Versions: 1.0.1
Reporter: Ken Giusti
Assignee: Ken Giusti


All python files in the project should add python 3 support (while remaining 
compatible with python 2.7)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (DISPATCH-154) dispatch-router coredumps when connector address is unresolvable

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434462#comment-16434462
 ] 

ASF GitHub Bot commented on DISPATCH-154:
-

Github user asfgit closed the pull request at:

https://github.com/apache/qpid-dispatch/pull/286


> dispatch-router coredumps when connector address is unresolvable
> 
>
> Key: DISPATCH-154
> URL: https://issues.apache.org/jira/browse/DISPATCH-154
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Reporter: Ted Ross
>Assignee: Ted Ross
>Priority: Major
> Fix For: 0.5
>
>
> If the address of a connector is unresolvable, the router will crash upon 
> resolution failure.  This can be reproduced by adding the following 
> configuration:
> {noformat}
> connector {
> addr: unres.bogus.unreg
> port: amqp
> role: on-demand
> saslMechanisms: ANONYMOUS
> name: bogus
> }
> linkRoutePattern {
> prefix: abc
> connector: bogus
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[GitHub] qpid-dispatch pull request #286: DISPATCH-154 - Added new tests to validate ...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/qpid-dispatch/pull/286


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (DISPATCH-154) dispatch-router coredumps when connector address is unresolvable

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434461#comment-16434461
 ] 

ASF subversion and git services commented on DISPATCH-154:
--

Commit f4aef4f9e497bcfb3e7a590830fb9253d158126a in qpid-dispatch's branch 
refs/heads/master from [~fgiorget]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=f4aef4f ]

DISPATCH-154 - Added new tests to validate unresolvable hostname. This closes 
#286


> dispatch-router coredumps when connector address is unresolvable
> 
>
> Key: DISPATCH-154
> URL: https://issues.apache.org/jira/browse/DISPATCH-154
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Reporter: Ted Ross
>Assignee: Ted Ross
>Priority: Major
> Fix For: 0.5
>
>
> If the address of a connector is unresolvable, the router will crash upon 
> resolution failure.  This can be reproduced by adding the following 
> configuration:
> {noformat}
> connector {
> addr: unres.bogus.unreg
> port: amqp
> role: on-demand
> saslMechanisms: ANONYMOUS
> name: bogus
> }
> linkRoutePattern {
> prefix: abc
> connector: bogus
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (DISPATCH-964) Auto-links are closed with an incorrect error indication

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DISPATCH-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated DISPATCH-964:
--
Fix Version/s: 1.1.0

> Auto-links are closed with an incorrect error indication
> 
>
> Key: DISPATCH-964
> URL: https://issues.apache.org/jira/browse/DISPATCH-964
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.0.1
>Reporter: Ganesh Murthy
>Assignee: Ted Ross
>Priority: Major
> Fix For: 1.1.0
>
>
> When auto-links are closed as a result of a management delete of an auto-link 
> object, the detach frame carries the error "qd:routed-link-lost".  This is 
> incorrect since these are not even routed links.  These detaches should carry 
> no error.  This defect causes the following symptom:
> There is a test called test_06_manage_autolinks in system_tests_autolinks.py. 
> The test tries to create 5 auto links and delete 5 auto links. Upon deletion 
> it expects 5 detaches to arrive but sometimes receives less than 5 detaches 
> leading to test failure. Upon examining the frame trace, it looks like the 
> test is closing a connection upon receiving a detach with an error. Proton 
> might be closing the connection because it does not know how to handle the 
> error. Here is the frame trace from the test
>  
> {noformat}
> test_06_manage_autolinks (system_tests_autolinks.AutolinkTest) ... 
> [0x55f6d2763de0]:  -> SASL
> [0x55f6d2770dc0]:  -> SASL
> [0x55f6d2763de0]:  <- SASL
> [0x55f6d2763de0]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]]
> [0x55f6d2763de0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, 
> initial-response=b"anonymous@localhost.localdomain"]
> [0x55f6d2770dc0]:  <- SASL
> [0x55f6d2770dc0]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]]
> [0x55f6d2770dc0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, 
> initial-response=b"anonymous@localhost.localdomain"]
> [0x55f6d2763de0]:0 <- @sasl-outcome(68) [code=0]
> [0x55f6d2763de0]:  -> AMQP
> [0x55f6d2763de0]:0 -> @open(16) [container-id="container.new", 
> hostname="0.0.0.0", channel-max=32767]
> [0x55f6d2770dc0]:0 <- @sasl-outcome(68) [code=0]
> [0x55f6d2770dc0]:  -> AMQP
> [0x55f6d2770dc0]:0 -> @open(16) [container-id="container.new", 
> hostname="0.0.0.0", channel-max=32767]
> [0x55f6d2770dc0]:0 -> @begin(17) [next-outgoing-id=0, 
> incoming-window=2147483647, outgoing-window=2147483647]
> [0x55f6d2770dc0]:0 -> @attach(18) 
> [name="container.new-5ffbadef-6b56-44c4-920c-d5536fd65862", handle=0, 
> role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) 
> [durable=0, timeout=0, dynamic=true], target=@target(41) [durable=0, 
> timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0]
> [0x55f6d2770dc0]:0 -> @attach(18) [name="container.new-$management", 
> 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="$management", durable=0, timeout=0, dynamic=false], 
> initial-delivery-count=0, max-message-size=0]
> [0x55f6d2770dc0]:0 -> @flow(19) [incoming-window=2147483647, 
> next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0, 
> link-credit=10, drain=false]
> [0x55f6d2763de0]:  <- AMQP
> [0x55f6d2763de0]:0 <- @open(16) [container-id="QDR", max-frame-size=16384, 
> channel-max=32767, idle-time-out=6, 
> offered-capabilities=:"ANONYMOUS-RELAY", 
> properties={:product="qpid-dispatch-router", :version="1.0.0"}]
> [0x55f6d2770dc0]:  <- AMQP
> [0x55f6d2770dc0]:0 <- @open(16) [container-id="QDR", max-frame-size=16384, 
> channel-max=32767, idle-time-out=6, 
> offered-capabilities=:"ANONYMOUS-RELAY", 
> properties={:product="qpid-dispatch-router", :version="1.0.0"}]
> [0x55f6d2770dc0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=0, 
> incoming-window=2147483647, outgoing-window=2147483647]
> [0x55f6d2770dc0]:0 <- @attach(18) 
> [name="container.new-5ffbadef-6b56-44c4-920c-d5536fd65862", handle=0, 
> role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) 
> [address="amqp:/_topo/0/QDR/temp.MT8K7VE3i2Y8y7_", durable=0, timeout=0, 
> dynamic=true], target=@target(41) [durable=0, timeout=0, dynamic=false], 
> initial-delivery-count=0, max-message-size=0]
> [0x55f6d2770dc0]:0 <- @attach(18) [name="container.new-$management", 
> 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="$management", durable=0, timeout=0, dynamic=false], 
> initial-delivery-count=0, max-message-size=0]
> [0x55f6d2770dc0]:0 <- @flow(19) [next-incoming-id=0, 
> incoming-window=2147483647, next-outgoing-id=0, outgoing-window=2147483647, 
> handle=1, 

[jira] [Updated] (DISPATCH-964) Auto-links are closed with an incorrect error indication

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DISPATCH-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated DISPATCH-964:
--
Component/s: (was: Tests)
 Router Node

> Auto-links are closed with an incorrect error indication
> 
>
> Key: DISPATCH-964
> URL: https://issues.apache.org/jira/browse/DISPATCH-964
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.0.1
>Reporter: Ganesh Murthy
>Assignee: Ted Ross
>Priority: Major
> Fix For: 1.1.0
>
>
> When auto-links are closed as a result of a management delete of an auto-link 
> object, the detach frame carries the error "qd:routed-link-lost".  This is 
> incorrect since these are not even routed links.  These detaches should carry 
> no error.  This defect causes the following symptom:
> There is a test called test_06_manage_autolinks in system_tests_autolinks.py. 
> The test tries to create 5 auto links and delete 5 auto links. Upon deletion 
> it expects 5 detaches to arrive but sometimes receives less than 5 detaches 
> leading to test failure. Upon examining the frame trace, it looks like the 
> test is closing a connection upon receiving a detach with an error. Proton 
> might be closing the connection because it does not know how to handle the 
> error. Here is the frame trace from the test
>  
> {noformat}
> test_06_manage_autolinks (system_tests_autolinks.AutolinkTest) ... 
> [0x55f6d2763de0]:  -> SASL
> [0x55f6d2770dc0]:  -> SASL
> [0x55f6d2763de0]:  <- SASL
> [0x55f6d2763de0]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]]
> [0x55f6d2763de0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, 
> initial-response=b"anonymous@localhost.localdomain"]
> [0x55f6d2770dc0]:  <- SASL
> [0x55f6d2770dc0]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]]
> [0x55f6d2770dc0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, 
> initial-response=b"anonymous@localhost.localdomain"]
> [0x55f6d2763de0]:0 <- @sasl-outcome(68) [code=0]
> [0x55f6d2763de0]:  -> AMQP
> [0x55f6d2763de0]:0 -> @open(16) [container-id="container.new", 
> hostname="0.0.0.0", channel-max=32767]
> [0x55f6d2770dc0]:0 <- @sasl-outcome(68) [code=0]
> [0x55f6d2770dc0]:  -> AMQP
> [0x55f6d2770dc0]:0 -> @open(16) [container-id="container.new", 
> hostname="0.0.0.0", channel-max=32767]
> [0x55f6d2770dc0]:0 -> @begin(17) [next-outgoing-id=0, 
> incoming-window=2147483647, outgoing-window=2147483647]
> [0x55f6d2770dc0]:0 -> @attach(18) 
> [name="container.new-5ffbadef-6b56-44c4-920c-d5536fd65862", handle=0, 
> role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) 
> [durable=0, timeout=0, dynamic=true], target=@target(41) [durable=0, 
> timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0]
> [0x55f6d2770dc0]:0 -> @attach(18) [name="container.new-$management", 
> 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="$management", durable=0, timeout=0, dynamic=false], 
> initial-delivery-count=0, max-message-size=0]
> [0x55f6d2770dc0]:0 -> @flow(19) [incoming-window=2147483647, 
> next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0, 
> link-credit=10, drain=false]
> [0x55f6d2763de0]:  <- AMQP
> [0x55f6d2763de0]:0 <- @open(16) [container-id="QDR", max-frame-size=16384, 
> channel-max=32767, idle-time-out=6, 
> offered-capabilities=:"ANONYMOUS-RELAY", 
> properties={:product="qpid-dispatch-router", :version="1.0.0"}]
> [0x55f6d2770dc0]:  <- AMQP
> [0x55f6d2770dc0]:0 <- @open(16) [container-id="QDR", max-frame-size=16384, 
> channel-max=32767, idle-time-out=6, 
> offered-capabilities=:"ANONYMOUS-RELAY", 
> properties={:product="qpid-dispatch-router", :version="1.0.0"}]
> [0x55f6d2770dc0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=0, 
> incoming-window=2147483647, outgoing-window=2147483647]
> [0x55f6d2770dc0]:0 <- @attach(18) 
> [name="container.new-5ffbadef-6b56-44c4-920c-d5536fd65862", handle=0, 
> role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) 
> [address="amqp:/_topo/0/QDR/temp.MT8K7VE3i2Y8y7_", durable=0, timeout=0, 
> dynamic=true], target=@target(41) [durable=0, timeout=0, dynamic=false], 
> initial-delivery-count=0, max-message-size=0]
> [0x55f6d2770dc0]:0 <- @attach(18) [name="container.new-$management", 
> 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="$management", durable=0, timeout=0, dynamic=false], 
> initial-delivery-count=0, max-message-size=0]
> [0x55f6d2770dc0]:0 <- @flow(19) [next-incoming-id=0, 
> incoming-window=2147483647, next-outgoing-id=0, 

[jira] [Updated] (DISPATCH-964) Auto-links are closed with an incorrect error indication

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DISPATCH-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated DISPATCH-964:
--
Description: 
When auto-links are closed as a result of a management delete of an auto-link 
object, the detach frame carries the error "qd:routed-link-lost".  This is 
incorrect since these are not even routed links.  These detaches should carry 
no error.  This defect causes the following symptom:

There is a test called test_06_manage_autolinks in system_tests_autolinks.py. 
The test tries to create 5 auto links and delete 5 auto links. Upon deletion it 
expects 5 detaches to arrive but sometimes receives less than 5 detaches 
leading to test failure. Upon examining the frame trace, it looks like the test 
is closing a connection upon receiving a detach with an error. Proton might be 
closing the connection because it does not know how to handle the error. Here 
is the frame trace from the test

 
{noformat}
test_06_manage_autolinks (system_tests_autolinks.AutolinkTest) ... 
[0x55f6d2763de0]:  -> SASL
[0x55f6d2770dc0]:  -> SASL
[0x55f6d2763de0]:  <- SASL
[0x55f6d2763de0]:0 <- @sasl-mechanisms(64) 
[sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]]
[0x55f6d2763de0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, 
initial-response=b"anonymous@localhost.localdomain"]
[0x55f6d2770dc0]:  <- SASL
[0x55f6d2770dc0]:0 <- @sasl-mechanisms(64) 
[sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]]
[0x55f6d2770dc0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, 
initial-response=b"anonymous@localhost.localdomain"]
[0x55f6d2763de0]:0 <- @sasl-outcome(68) [code=0]
[0x55f6d2763de0]:  -> AMQP
[0x55f6d2763de0]:0 -> @open(16) [container-id="container.new", 
hostname="0.0.0.0", channel-max=32767]
[0x55f6d2770dc0]:0 <- @sasl-outcome(68) [code=0]
[0x55f6d2770dc0]:  -> AMQP
[0x55f6d2770dc0]:0 -> @open(16) [container-id="container.new", 
hostname="0.0.0.0", channel-max=32767]
[0x55f6d2770dc0]:0 -> @begin(17) [next-outgoing-id=0, 
incoming-window=2147483647, outgoing-window=2147483647]
[0x55f6d2770dc0]:0 -> @attach(18) 
[name="container.new-5ffbadef-6b56-44c4-920c-d5536fd65862", handle=0, 
role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, 
timeout=0, dynamic=true], target=@target(41) [durable=0, timeout=0, 
dynamic=false], initial-delivery-count=0, max-message-size=0]
[0x55f6d2770dc0]:0 -> @attach(18) [name="container.new-$management", 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="$management", durable=0, timeout=0, dynamic=false], 
initial-delivery-count=0, max-message-size=0]
[0x55f6d2770dc0]:0 -> @flow(19) [incoming-window=2147483647, 
next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0, 
link-credit=10, drain=false]
[0x55f6d2763de0]:  <- AMQP
[0x55f6d2763de0]:0 <- @open(16) [container-id="QDR", max-frame-size=16384, 
channel-max=32767, idle-time-out=6, 
offered-capabilities=:"ANONYMOUS-RELAY", 
properties={:product="qpid-dispatch-router", :version="1.0.0"}]
[0x55f6d2770dc0]:  <- AMQP
[0x55f6d2770dc0]:0 <- @open(16) [container-id="QDR", max-frame-size=16384, 
channel-max=32767, idle-time-out=6, 
offered-capabilities=:"ANONYMOUS-RELAY", 
properties={:product="qpid-dispatch-router", :version="1.0.0"}]
[0x55f6d2770dc0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=0, 
incoming-window=2147483647, outgoing-window=2147483647]
[0x55f6d2770dc0]:0 <- @attach(18) 
[name="container.new-5ffbadef-6b56-44c4-920c-d5536fd65862", handle=0, 
role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) 
[address="amqp:/_topo/0/QDR/temp.MT8K7VE3i2Y8y7_", durable=0, timeout=0, 
dynamic=true], target=@target(41) [durable=0, timeout=0, dynamic=false], 
initial-delivery-count=0, max-message-size=0]
[0x55f6d2770dc0]:0 <- @attach(18) [name="container.new-$management", 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="$management", 
durable=0, timeout=0, dynamic=false], initial-delivery-count=0, 
max-message-size=0]
[0x55f6d2770dc0]:0 <- @flow(19) [next-incoming-id=0, 
incoming-window=2147483647, next-outgoing-id=0, outgoing-window=2147483647, 
handle=1, delivery-count=0, link-credit=250, drain=false]
[0x55f6d2770dc0]:0 -> @transfer(20) [handle=1, delivery-id=0, 
delivery-tag=b"1", message-format=0] (228) 
"\x00SpE\x00Ss\xd0\x00\x00\x000\x00\x00\x00\x05\xa1:/_topo/0/QDR/temp.MT8K7VE3i2Y8y7_\x00St\xd1\x00\x00\x00Z\x00\x00\x00\x06\xa1\x09operation\xa0\x06CREATE\xa1\x04type\xa0/org.apache.qpid.dispatch.router.config.autoLink\xa1\x04name\xa0\x04AL.0\x00Sw\xd1\x00\x00\x00>\x00\x00\x00\x06\xa0\x09direction\xa0\x03out\xa0\x0bcontainerId\xa0\x0dcontainer.new\xa0\x04addr\xa0\x06node.0"
[0x55f6d2770dc0]:0 -> @transfer(20) [handle=1, delivery-id=1, 
delivery-tag=b"2", message-format=0] (228) 

[jira] [Updated] (DISPATCH-964) Auto-links are closed with an incorrect error indication

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DISPATCH-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated DISPATCH-964:
--
Summary: Auto-links are closed with an incorrect error indication  (was: 
system_tests_autolinks.test_06_manage_autolinks fails intermittently)

> Auto-links are closed with an incorrect error indication
> 
>
> Key: DISPATCH-964
> URL: https://issues.apache.org/jira/browse/DISPATCH-964
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 1.0.1
>Reporter: Ganesh Murthy
>Assignee: Ted Ross
>Priority: Major
>
> There is a test called test_06_manage_autolinks in system_tests_autolinks.py. 
> The test tries to create 5 auto links and delete 5 auto links. Upon deletion 
> it expects 5 detaches to arrive but sometimes receives less than 5 detaches 
> leading to test failure. Upon examining the frame trace, it looks like the 
> test is closing a connection upon receiving a detach with an error. Proton 
> might be closing the connection because it does not know how to handle the 
> error. Here is the frame trace from the test
>  
> {noformat}
> test_06_manage_autolinks (system_tests_autolinks.AutolinkTest) ... 
> [0x55f6d2763de0]:  -> SASL
> [0x55f6d2770dc0]:  -> SASL
> [0x55f6d2763de0]:  <- SASL
> [0x55f6d2763de0]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]]
> [0x55f6d2763de0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, 
> initial-response=b"anonymous@localhost.localdomain"]
> [0x55f6d2770dc0]:  <- SASL
> [0x55f6d2770dc0]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]]
> [0x55f6d2770dc0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, 
> initial-response=b"anonymous@localhost.localdomain"]
> [0x55f6d2763de0]:0 <- @sasl-outcome(68) [code=0]
> [0x55f6d2763de0]:  -> AMQP
> [0x55f6d2763de0]:0 -> @open(16) [container-id="container.new", 
> hostname="0.0.0.0", channel-max=32767]
> [0x55f6d2770dc0]:0 <- @sasl-outcome(68) [code=0]
> [0x55f6d2770dc0]:  -> AMQP
> [0x55f6d2770dc0]:0 -> @open(16) [container-id="container.new", 
> hostname="0.0.0.0", channel-max=32767]
> [0x55f6d2770dc0]:0 -> @begin(17) [next-outgoing-id=0, 
> incoming-window=2147483647, outgoing-window=2147483647]
> [0x55f6d2770dc0]:0 -> @attach(18) 
> [name="container.new-5ffbadef-6b56-44c4-920c-d5536fd65862", handle=0, 
> role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) 
> [durable=0, timeout=0, dynamic=true], target=@target(41) [durable=0, 
> timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0]
> [0x55f6d2770dc0]:0 -> @attach(18) [name="container.new-$management", 
> 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="$management", durable=0, timeout=0, dynamic=false], 
> initial-delivery-count=0, max-message-size=0]
> [0x55f6d2770dc0]:0 -> @flow(19) [incoming-window=2147483647, 
> next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0, 
> link-credit=10, drain=false]
> [0x55f6d2763de0]:  <- AMQP
> [0x55f6d2763de0]:0 <- @open(16) [container-id="QDR", max-frame-size=16384, 
> channel-max=32767, idle-time-out=6, 
> offered-capabilities=:"ANONYMOUS-RELAY", 
> properties={:product="qpid-dispatch-router", :version="1.0.0"}]
> [0x55f6d2770dc0]:  <- AMQP
> [0x55f6d2770dc0]:0 <- @open(16) [container-id="QDR", max-frame-size=16384, 
> channel-max=32767, idle-time-out=6, 
> offered-capabilities=:"ANONYMOUS-RELAY", 
> properties={:product="qpid-dispatch-router", :version="1.0.0"}]
> [0x55f6d2770dc0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=0, 
> incoming-window=2147483647, outgoing-window=2147483647]
> [0x55f6d2770dc0]:0 <- @attach(18) 
> [name="container.new-5ffbadef-6b56-44c4-920c-d5536fd65862", handle=0, 
> role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) 
> [address="amqp:/_topo/0/QDR/temp.MT8K7VE3i2Y8y7_", durable=0, timeout=0, 
> dynamic=true], target=@target(41) [durable=0, timeout=0, dynamic=false], 
> initial-delivery-count=0, max-message-size=0]
> [0x55f6d2770dc0]:0 <- @attach(18) [name="container.new-$management", 
> 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="$management", durable=0, timeout=0, dynamic=false], 
> initial-delivery-count=0, max-message-size=0]
> [0x55f6d2770dc0]:0 <- @flow(19) [next-incoming-id=0, 
> incoming-window=2147483647, next-outgoing-id=0, outgoing-window=2147483647, 
> handle=1, delivery-count=0, link-credit=250, drain=false]
> [0x55f6d2770dc0]:0 -> @transfer(20) [handle=1, delivery-id=0, 
> delivery-tag=b"1", message-format=0] (228) 
> 

[jira] [Issue Comment Deleted] (DISPATCH-963) Router crash during shutdown in system_tests_distribution

[Ganesh Murthy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DISPATCH-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ganesh Murthy updated DISPATCH-963:
---
Comment: was deleted

(was: The failing test output can be seen here - 
http://rhm-x3550-02.rhm.lab.eng.bos.redhat.com:8080/job/dispatch-master/OS=rhel7/323/testReport/projectroot/tests/system_tests_distribution/)

> Router crash during shutdown in system_tests_distribution
> -
>
> Key: DISPATCH-963
> URL: https://issues.apache.org/jira/browse/DISPATCH-963
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Tests
>Affects Versions: 1.0.1
>Reporter: Ganesh Murthy
>Priority: Major
>
> The router crashes during shutdown in system_tests_distribution.py
> Here is the backtrace
>  
> {noformat}
> (gdb) bt
> #0  0x7f361ca5ae40 in pn_ep_decref (endpoint=0x7f35f01c2dd0) at 
> /home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/core/engine.c:447
> #1  0x7f361ca5b58b in pn_ep_decref (endpoint=) at 
> /home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/core/engine.c:445
> #2  0x7f361ca5f588 in pni_transport_unbind_handles 
> (handles=0x7f35f00764a0, reset_state=reset_state@entry=true) at 
> /home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/core/transport.c:748
> #3  0x7f361ca5f666 in pni_transport_unbind_channels (channels=0x9d1ce0) 
> at 
> /home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/core/transport.c:761
> #4  0x7f361ca5f777 in pn_transport_unbind (transport=0xa863d0) at 
> /home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/core/transport.c:795
> #5  0x7f361ca5a63e in pn_connection_driver_release_connection 
> (d=d@entry=0xa86248) at 
> /home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/core/connection_driver.c:81
> #6  0x7f361ca5a679 in pn_connection_driver_destroy (d=d@entry=0xa86248) 
> at 
> /home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/core/connection_driver.c:92
> #7  0x7f361c83a69c in pconnection_final_free (pc=0xa85ca0) at 
> /home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/proactor/epoll.c:827
> #8  0x7f361c83b3ac in pconnection_cleanup (pc=) at 
> /home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/proactor/epoll.c:843
> #9  0x7f361c83db37 in pconnection_forced_shutdown (pc=0xa85ca0) at 
> /home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/proactor/epoll.c:878
> #10 pn_proactor_free (p=0x916fd0) at 
> /home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/proactor/epoll.c:1815
> #11 0x7f361cce7bb5 in qd_server_free (qd_server=0x919190) at 
> /home/gmurthy/opensource/qpid-dispatch/src/server.c:1176
> #12 0x7f361cca878e in qd_dispatch_free (qd=0x6164b0) at 
> /home/gmurthy/opensource/qpid-dispatch/src/dispatch.c:318
> #13 0x00401864 in main_process (config_path=0x7ffcb36d88e2 "B.conf", 
> python_pkgdir=0x7ffcb36d88ec "/home/gmurthy/opensource/qpid-dispatch/python", 
> fd=2) at /home/gmurthy/opensource/qpid-dispatch/router/src/main.c:116
> #14 0x004022b0 in main (argc=5, argv=0x7ffcb36d8158) at 
> /home/gmurthy/opensource/qpid-dispatch/router/src/main.c:360
> (gdb){noformat}
>  
> Running the test under valgrind, it seems that the pn_proactor_free is trying 
> to free already freed link endpoint. Here are two outputs from valgrind
>  
> {noformat}
> Process 3493 error: exit code 42, expected 0
> qdrouterd -c B.conf -I /home/gmurthy/opensource/qpid-dispatch/python
> /home/gmurthy/opensource/qpid-dispatch/build/system_test.dir/system_tests_distribution/DistributionTests/setUpClass/B-2.cmd
> 
> ==3493== Invalid write of size 8
> ==3493==    at 0x50E82B0: pn_link_unbound (engine.c:1202)
> ==3493==    by 0x50EB5D0: pni_transport_unbind_handles (transport.c:746)
> ==3493==    by 0x50EB665: pni_transport_unbind_channels (transport.c:761)
> ==3493==    by 0x50EB776: pn_transport_unbind (transport.c:795)
> ==3493==    by 0x50E663D: pn_connection_driver_release_connection 
> (connection_driver.c:81)
> ==3493==    by 0x50E6678: pn_connection_driver_destroy 
> (connection_driver.c:92)
> ==3493==    by 0x530A69B: pconnection_final_free (epoll.c:827)
> ==3493==    by 0x530DB36: pconnection_forced_shutdown (epoll.c:878)
> ==3493==    by 0x530DB36: pn_proactor_free (epoll.c:1815)
> ==3493==    by 0x4EA5BB4: qd_server_free (server.c:1176)
> ==3493==    by 0x4E6678D: qd_dispatch_free (dispatch.c:318)
> ==3493==    by 0x401863: main_process (main.c:116)
> ==3493==    by 0x4022AF: main (main.c:360)
> ==3493==  Address 0x15c06188 is 376 bytes inside a block of size 488 free'd
> ==3493==    at 0x4C2DD18: free (vg_replace_malloc.c:530)
> ==3493==    by 0x50DD938: pn_class_decref (object.c:101)
> ==3493==    by 0x50EA03F: pn_event_finalize (event.c:226)
> ==3493==    by 0x50EA03F: pn_event_finalize_cast (event.c:271)
> ==3493==    by 

[jira] [Assigned] (DISPATCH-964) system_tests_autolinks.test_06_manage_autolinks fails intermittently

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DISPATCH-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross reassigned DISPATCH-964:
-

Assignee: Ted Ross

> system_tests_autolinks.test_06_manage_autolinks fails intermittently
> 
>
> Key: DISPATCH-964
> URL: https://issues.apache.org/jira/browse/DISPATCH-964
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 1.0.1
>Reporter: Ganesh Murthy
>Assignee: Ted Ross
>Priority: Major
>
> There is a test called test_06_manage_autolinks in system_tests_autolinks.py. 
> The test tries to create 5 auto links and delete 5 auto links. Upon deletion 
> it expects 5 detaches to arrive but sometimes receives less than 5 detaches 
> leading to test failure. Upon examining the frame trace, it looks like the 
> test is closing a connection upon receiving a detach with an error. Proton 
> might be closing the connection because it does not know how to handle the 
> error. Here is the frame trace from the test
>  
> {noformat}
> test_06_manage_autolinks (system_tests_autolinks.AutolinkTest) ... 
> [0x55f6d2763de0]:  -> SASL
> [0x55f6d2770dc0]:  -> SASL
> [0x55f6d2763de0]:  <- SASL
> [0x55f6d2763de0]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]]
> [0x55f6d2763de0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, 
> initial-response=b"anonymous@localhost.localdomain"]
> [0x55f6d2770dc0]:  <- SASL
> [0x55f6d2770dc0]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]]
> [0x55f6d2770dc0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, 
> initial-response=b"anonymous@localhost.localdomain"]
> [0x55f6d2763de0]:0 <- @sasl-outcome(68) [code=0]
> [0x55f6d2763de0]:  -> AMQP
> [0x55f6d2763de0]:0 -> @open(16) [container-id="container.new", 
> hostname="0.0.0.0", channel-max=32767]
> [0x55f6d2770dc0]:0 <- @sasl-outcome(68) [code=0]
> [0x55f6d2770dc0]:  -> AMQP
> [0x55f6d2770dc0]:0 -> @open(16) [container-id="container.new", 
> hostname="0.0.0.0", channel-max=32767]
> [0x55f6d2770dc0]:0 -> @begin(17) [next-outgoing-id=0, 
> incoming-window=2147483647, outgoing-window=2147483647]
> [0x55f6d2770dc0]:0 -> @attach(18) 
> [name="container.new-5ffbadef-6b56-44c4-920c-d5536fd65862", handle=0, 
> role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) 
> [durable=0, timeout=0, dynamic=true], target=@target(41) [durable=0, 
> timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0]
> [0x55f6d2770dc0]:0 -> @attach(18) [name="container.new-$management", 
> 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="$management", durable=0, timeout=0, dynamic=false], 
> initial-delivery-count=0, max-message-size=0]
> [0x55f6d2770dc0]:0 -> @flow(19) [incoming-window=2147483647, 
> next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0, 
> link-credit=10, drain=false]
> [0x55f6d2763de0]:  <- AMQP
> [0x55f6d2763de0]:0 <- @open(16) [container-id="QDR", max-frame-size=16384, 
> channel-max=32767, idle-time-out=6, 
> offered-capabilities=:"ANONYMOUS-RELAY", 
> properties={:product="qpid-dispatch-router", :version="1.0.0"}]
> [0x55f6d2770dc0]:  <- AMQP
> [0x55f6d2770dc0]:0 <- @open(16) [container-id="QDR", max-frame-size=16384, 
> channel-max=32767, idle-time-out=6, 
> offered-capabilities=:"ANONYMOUS-RELAY", 
> properties={:product="qpid-dispatch-router", :version="1.0.0"}]
> [0x55f6d2770dc0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=0, 
> incoming-window=2147483647, outgoing-window=2147483647]
> [0x55f6d2770dc0]:0 <- @attach(18) 
> [name="container.new-5ffbadef-6b56-44c4-920c-d5536fd65862", handle=0, 
> role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) 
> [address="amqp:/_topo/0/QDR/temp.MT8K7VE3i2Y8y7_", durable=0, timeout=0, 
> dynamic=true], target=@target(41) [durable=0, timeout=0, dynamic=false], 
> initial-delivery-count=0, max-message-size=0]
> [0x55f6d2770dc0]:0 <- @attach(18) [name="container.new-$management", 
> 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="$management", durable=0, timeout=0, dynamic=false], 
> initial-delivery-count=0, max-message-size=0]
> [0x55f6d2770dc0]:0 <- @flow(19) [next-incoming-id=0, 
> incoming-window=2147483647, next-outgoing-id=0, outgoing-window=2147483647, 
> handle=1, delivery-count=0, link-credit=250, drain=false]
> [0x55f6d2770dc0]:0 -> @transfer(20) [handle=1, delivery-id=0, 
> delivery-tag=b"1", message-format=0] (228) 
> 

[jira] [Created] (DISPATCH-964) system_tests_autolinks.test_06_manage_autolinks fails intermittently

[Ganesh Murthy (JIRA)]

Ganesh Murthy created DISPATCH-964:
--

 Summary: system_tests_autolinks.test_06_manage_autolinks fails 
intermittently
 Key: DISPATCH-964
 URL: https://issues.apache.org/jira/browse/DISPATCH-964
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Tests
Affects Versions: 1.0.1
Reporter: Ganesh Murthy


There is a test called test_06_manage_autolinks in system_tests_autolinks.py. 
The test tries to create 5 auto links and delete 5 auto links. Upon deletion it 
expects 5 detaches to arrive but sometimes receives less than 5 detaches 
leading to test failure. Upon examining the frame trace, it looks like the test 
is closing a connection upon receiving a detach with an error. Proton might be 
closing the connection because it does not know how to handle the error. Here 
is the frame trace from the test

 
{noformat}
test_06_manage_autolinks (system_tests_autolinks.AutolinkTest) ... 
[0x55f6d2763de0]:  -> SASL
[0x55f6d2770dc0]:  -> SASL
[0x55f6d2763de0]:  <- SASL
[0x55f6d2763de0]:0 <- @sasl-mechanisms(64) 
[sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]]
[0x55f6d2763de0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, 
initial-response=b"anonymous@localhost.localdomain"]
[0x55f6d2770dc0]:  <- SASL
[0x55f6d2770dc0]:0 <- @sasl-mechanisms(64) 
[sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]]
[0x55f6d2770dc0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, 
initial-response=b"anonymous@localhost.localdomain"]
[0x55f6d2763de0]:0 <- @sasl-outcome(68) [code=0]
[0x55f6d2763de0]:  -> AMQP
[0x55f6d2763de0]:0 -> @open(16) [container-id="container.new", 
hostname="0.0.0.0", channel-max=32767]
[0x55f6d2770dc0]:0 <- @sasl-outcome(68) [code=0]
[0x55f6d2770dc0]:  -> AMQP
[0x55f6d2770dc0]:0 -> @open(16) [container-id="container.new", 
hostname="0.0.0.0", channel-max=32767]
[0x55f6d2770dc0]:0 -> @begin(17) [next-outgoing-id=0, 
incoming-window=2147483647, outgoing-window=2147483647]
[0x55f6d2770dc0]:0 -> @attach(18) 
[name="container.new-5ffbadef-6b56-44c4-920c-d5536fd65862", handle=0, 
role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, 
timeout=0, dynamic=true], target=@target(41) [durable=0, timeout=0, 
dynamic=false], initial-delivery-count=0, max-message-size=0]
[0x55f6d2770dc0]:0 -> @attach(18) [name="container.new-$management", 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="$management", durable=0, timeout=0, dynamic=false], 
initial-delivery-count=0, max-message-size=0]
[0x55f6d2770dc0]:0 -> @flow(19) [incoming-window=2147483647, 
next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0, 
link-credit=10, drain=false]
[0x55f6d2763de0]:  <- AMQP
[0x55f6d2763de0]:0 <- @open(16) [container-id="QDR", max-frame-size=16384, 
channel-max=32767, idle-time-out=6, 
offered-capabilities=:"ANONYMOUS-RELAY", 
properties={:product="qpid-dispatch-router", :version="1.0.0"}]
[0x55f6d2770dc0]:  <- AMQP
[0x55f6d2770dc0]:0 <- @open(16) [container-id="QDR", max-frame-size=16384, 
channel-max=32767, idle-time-out=6, 
offered-capabilities=:"ANONYMOUS-RELAY", 
properties={:product="qpid-dispatch-router", :version="1.0.0"}]
[0x55f6d2770dc0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=0, 
incoming-window=2147483647, outgoing-window=2147483647]
[0x55f6d2770dc0]:0 <- @attach(18) 
[name="container.new-5ffbadef-6b56-44c4-920c-d5536fd65862", handle=0, 
role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) 
[address="amqp:/_topo/0/QDR/temp.MT8K7VE3i2Y8y7_", durable=0, timeout=0, 
dynamic=true], target=@target(41) [durable=0, timeout=0, dynamic=false], 
initial-delivery-count=0, max-message-size=0]
[0x55f6d2770dc0]:0 <- @attach(18) [name="container.new-$management", 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="$management", 
durable=0, timeout=0, dynamic=false], initial-delivery-count=0, 
max-message-size=0]
[0x55f6d2770dc0]:0 <- @flow(19) [next-incoming-id=0, 
incoming-window=2147483647, next-outgoing-id=0, outgoing-window=2147483647, 
handle=1, delivery-count=0, link-credit=250, drain=false]
[0x55f6d2770dc0]:0 -> @transfer(20) [handle=1, delivery-id=0, 
delivery-tag=b"1", message-format=0] (228) 
"\x00SpE\x00Ss\xd0\x00\x00\x000\x00\x00\x00\x05\xa1:/_topo/0/QDR/temp.MT8K7VE3i2Y8y7_\x00St\xd1\x00\x00\x00Z\x00\x00\x00\x06\xa1\x09operation\xa0\x06CREATE\xa1\x04type\xa0/org.apache.qpid.dispatch.router.config.autoLink\xa1\x04name\xa0\x04AL.0\x00Sw\xd1\x00\x00\x00>\x00\x00\x00\x06\xa0\x09direction\xa0\x03out\xa0\x0bcontainerId\xa0\x0dcontainer.new\xa0\x04addr\xa0\x06node.0"
[0x55f6d2770dc0]:0 -> @transfer(20) [handle=1, delivery-id=1, 
delivery-tag=b"2", message-format=0] (228) 

[jira] [Closed] (DISPATCH-956) Zero out the memory after calling NEW or new_*

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DISPATCH-956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross closed DISPATCH-956.
-
Resolution: Won't Fix

> Zero out the memory after calling NEW or new_*
> --
>
> Key: DISPATCH-956
> URL: https://issues.apache.org/jira/browse/DISPATCH-956
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 1.0.1
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
>
> Call the ZERO macro after calling NEW() or new_
>  
> This will clear the memory and avoid pointing to some garbage.
>  
> [~chug] found and fixed a problem like this in commit 
> 627aae1ec779da1f3db9ec7f5add55b300a6



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Assigned] (DISPATCH-962) links established to 'unavailable' addresses are not refused correctly

[Ganesh Murthy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DISPATCH-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ganesh Murthy reassigned DISPATCH-962:
--

Assignee: Ganesh Murthy

> links established to 'unavailable' addresses are not refused correctly
> --
>
> Key: DISPATCH-962
> URL: https://issues.apache.org/jira/browse/DISPATCH-962
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 1.0.0, 1.0.1, 1.1.0
>Reporter: Robbie Gemmell
>Assignee: Ganesh Murthy
>Priority: Major
>
> When setting an address as unavailable (via defaultDistribution: unavailable 
> from DISPATCH-803) the router doesn't refuse the links to it in the manner 
> the spec indicates it should.
> To indicate a link is being refused, the spec describes that the attach 
> response should contain a null target/source as appropriate, essentially 
> indicating to the peer that the detach will follow due to the error, 
> [http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp315568],
>  Figure 2.33: Refusing a Link.
> Currently this does not happen, e.g:
> Creating a sending link, response attach with non-null Target:
> {noformat}
> [750316387:1] -> 
> Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
>  handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
> source=Source{address='ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, distributionMode=null, filter=null, 
> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list, 
> amqp:released:list, amqp:modified:list], capabilities=null}, 
> target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=null, offeredCapabilities=null, 
> desiredCapabilities=[DELAYED_DELIVERY], properties=null}
> [750316387:1] <- 
> Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
>  handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST, 
> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
> filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, 
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, 
> properties=null}
> {noformat}
> Creating a receiving link, response attach with non-null Source:
> {noformat}
> [59324032:1] -> 
> Attach{name='qpid-jms:receiver:ID:30b1b1c9-316b-4be1-9944-15b5822a6500:1:1:1:queue',
>  handle=0, role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
> source=Source{address='queue', durable=NONE, expiryPolicy=LINK_DETACH, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
> filter=null, defaultOutcome=Modified{deliveryFailed=true, 
> undeliverableHere=null, messageAnnotations=null}, 
> outcomes=[amqp:accepted:list, amqp:rejected:list, amqp:released:list, 
> amqp:modified:list], capabilities=[queue]}, target=Target{address='null', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, capabilities=null}, unsettled=null, 
> incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null, 
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [59324032:1] <- 
> Attach{name='qpid-jms:receiver:ID:30b1b1c9-316b-4be1-9944-15b5822a6500:1:1:1:queue',
>  handle=0, role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST, 
> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
> filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, 
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, 
> properties=null}
> {noformat}
> The links are detached after this, but the non-null terminus removes the hint 
> to the peer that it is coming.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: 

[jira] [Commented] (DISPATCH-963) Router crash during shutdown in system_tests_distribution

[Ganesh Murthy (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434376#comment-16434376
 ] 

Ganesh Murthy commented on DISPATCH-963:


The failing test output can be seen here - 
http://rhm-x3550-02.rhm.lab.eng.bos.redhat.com:8080/job/dispatch-master/OS=rhel7/323/testReport/projectroot/tests/system_tests_distribution/

> Router crash during shutdown in system_tests_distribution
> -
>
> Key: DISPATCH-963
> URL: https://issues.apache.org/jira/browse/DISPATCH-963
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Tests
>Affects Versions: 1.0.1
>Reporter: Ganesh Murthy
>Priority: Major
>
> The router crashes during shutdown in system_tests_distribution.py
> Here is the backtrace
>  
> {noformat}
> (gdb) bt
> #0  0x7f361ca5ae40 in pn_ep_decref (endpoint=0x7f35f01c2dd0) at 
> /home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/core/engine.c:447
> #1  0x7f361ca5b58b in pn_ep_decref (endpoint=) at 
> /home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/core/engine.c:445
> #2  0x7f361ca5f588 in pni_transport_unbind_handles 
> (handles=0x7f35f00764a0, reset_state=reset_state@entry=true) at 
> /home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/core/transport.c:748
> #3  0x7f361ca5f666 in pni_transport_unbind_channels (channels=0x9d1ce0) 
> at 
> /home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/core/transport.c:761
> #4  0x7f361ca5f777 in pn_transport_unbind (transport=0xa863d0) at 
> /home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/core/transport.c:795
> #5  0x7f361ca5a63e in pn_connection_driver_release_connection 
> (d=d@entry=0xa86248) at 
> /home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/core/connection_driver.c:81
> #6  0x7f361ca5a679 in pn_connection_driver_destroy (d=d@entry=0xa86248) 
> at 
> /home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/core/connection_driver.c:92
> #7  0x7f361c83a69c in pconnection_final_free (pc=0xa85ca0) at 
> /home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/proactor/epoll.c:827
> #8  0x7f361c83b3ac in pconnection_cleanup (pc=) at 
> /home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/proactor/epoll.c:843
> #9  0x7f361c83db37 in pconnection_forced_shutdown (pc=0xa85ca0) at 
> /home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/proactor/epoll.c:878
> #10 pn_proactor_free (p=0x916fd0) at 
> /home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/proactor/epoll.c:1815
> #11 0x7f361cce7bb5 in qd_server_free (qd_server=0x919190) at 
> /home/gmurthy/opensource/qpid-dispatch/src/server.c:1176
> #12 0x7f361cca878e in qd_dispatch_free (qd=0x6164b0) at 
> /home/gmurthy/opensource/qpid-dispatch/src/dispatch.c:318
> #13 0x00401864 in main_process (config_path=0x7ffcb36d88e2 "B.conf", 
> python_pkgdir=0x7ffcb36d88ec "/home/gmurthy/opensource/qpid-dispatch/python", 
> fd=2) at /home/gmurthy/opensource/qpid-dispatch/router/src/main.c:116
> #14 0x004022b0 in main (argc=5, argv=0x7ffcb36d8158) at 
> /home/gmurthy/opensource/qpid-dispatch/router/src/main.c:360
> (gdb){noformat}
>  
> Running the test under valgrind, it seems that the pn_proactor_free is trying 
> to free already freed link endpoint. Here are two outputs from valgrind
>  
> {noformat}
> Process 3493 error: exit code 42, expected 0
> qdrouterd -c B.conf -I /home/gmurthy/opensource/qpid-dispatch/python
> /home/gmurthy/opensource/qpid-dispatch/build/system_test.dir/system_tests_distribution/DistributionTests/setUpClass/B-2.cmd
> 
> ==3493== Invalid write of size 8
> ==3493==    at 0x50E82B0: pn_link_unbound (engine.c:1202)
> ==3493==    by 0x50EB5D0: pni_transport_unbind_handles (transport.c:746)
> ==3493==    by 0x50EB665: pni_transport_unbind_channels (transport.c:761)
> ==3493==    by 0x50EB776: pn_transport_unbind (transport.c:795)
> ==3493==    by 0x50E663D: pn_connection_driver_release_connection 
> (connection_driver.c:81)
> ==3493==    by 0x50E6678: pn_connection_driver_destroy 
> (connection_driver.c:92)
> ==3493==    by 0x530A69B: pconnection_final_free (epoll.c:827)
> ==3493==    by 0x530DB36: pconnection_forced_shutdown (epoll.c:878)
> ==3493==    by 0x530DB36: pn_proactor_free (epoll.c:1815)
> ==3493==    by 0x4EA5BB4: qd_server_free (server.c:1176)
> ==3493==    by 0x4E6678D: qd_dispatch_free (dispatch.c:318)
> ==3493==    by 0x401863: main_process (main.c:116)
> ==3493==    by 0x4022AF: main (main.c:360)
> ==3493==  Address 0x15c06188 is 376 bytes inside a block of size 488 free'd
> ==3493==    at 0x4C2DD18: free (vg_replace_malloc.c:530)
> ==3493==    by 0x50DD938: pn_class_decref (object.c:101)
> ==3493==    by 0x50EA03F: pn_event_finalize (event.c:226)
> ==3493==    by 0x50EA03F: pn_event_finalize_cast (event.c:271)
> ==3493== 

[jira] [Created] (DISPATCH-963) Router crash during shutdown in system_tests_distribution

[Ganesh Murthy (JIRA)]

Ganesh Murthy created DISPATCH-963:
--

 Summary: Router crash during shutdown in system_tests_distribution
 Key: DISPATCH-963
 URL: https://issues.apache.org/jira/browse/DISPATCH-963
 Project: Qpid Dispatch
  Issue Type: Improvement
  Components: Tests
Affects Versions: 1.0.1
Reporter: Ganesh Murthy


The router crashes during shutdown in system_tests_distribution.py

Here is the backtrace

 
{noformat}
(gdb) bt
#0  0x7f361ca5ae40 in pn_ep_decref (endpoint=0x7f35f01c2dd0) at 
/home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/core/engine.c:447
#1  0x7f361ca5b58b in pn_ep_decref (endpoint=) at 
/home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/core/engine.c:445
#2  0x7f361ca5f588 in pni_transport_unbind_handles (handles=0x7f35f00764a0, 
reset_state=reset_state@entry=true) at 
/home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/core/transport.c:748
#3  0x7f361ca5f666 in pni_transport_unbind_channels (channels=0x9d1ce0) at 
/home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/core/transport.c:761
#4  0x7f361ca5f777 in pn_transport_unbind (transport=0xa863d0) at 
/home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/core/transport.c:795
#5  0x7f361ca5a63e in pn_connection_driver_release_connection 
(d=d@entry=0xa86248) at 
/home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/core/connection_driver.c:81
#6  0x7f361ca5a679 in pn_connection_driver_destroy (d=d@entry=0xa86248) at 
/home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/core/connection_driver.c:92
#7  0x7f361c83a69c in pconnection_final_free (pc=0xa85ca0) at 
/home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/proactor/epoll.c:827
#8  0x7f361c83b3ac in pconnection_cleanup (pc=) at 
/home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/proactor/epoll.c:843
#9  0x7f361c83db37 in pconnection_forced_shutdown (pc=0xa85ca0) at 
/home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/proactor/epoll.c:878
#10 pn_proactor_free (p=0x916fd0) at 
/home/gmurthy/opensource/qpid-proton-0.22.0/proton-c/src/proactor/epoll.c:1815
#11 0x7f361cce7bb5 in qd_server_free (qd_server=0x919190) at 
/home/gmurthy/opensource/qpid-dispatch/src/server.c:1176
#12 0x7f361cca878e in qd_dispatch_free (qd=0x6164b0) at 
/home/gmurthy/opensource/qpid-dispatch/src/dispatch.c:318
#13 0x00401864 in main_process (config_path=0x7ffcb36d88e2 "B.conf", 
python_pkgdir=0x7ffcb36d88ec "/home/gmurthy/opensource/qpid-dispatch/python", 
fd=2) at /home/gmurthy/opensource/qpid-dispatch/router/src/main.c:116
#14 0x004022b0 in main (argc=5, argv=0x7ffcb36d8158) at 
/home/gmurthy/opensource/qpid-dispatch/router/src/main.c:360
(gdb){noformat}
 

Running the test under valgrind, it seems that the pn_proactor_free is trying 
to free already freed link endpoint. Here are two outputs from valgrind

 
{noformat}
Process 3493 error: exit code 42, expected 0
qdrouterd -c B.conf -I /home/gmurthy/opensource/qpid-dispatch/python
/home/gmurthy/opensource/qpid-dispatch/build/system_test.dir/system_tests_distribution/DistributionTests/setUpClass/B-2.cmd

==3493== Invalid write of size 8
==3493==    at 0x50E82B0: pn_link_unbound (engine.c:1202)
==3493==    by 0x50EB5D0: pni_transport_unbind_handles (transport.c:746)
==3493==    by 0x50EB665: pni_transport_unbind_channels (transport.c:761)
==3493==    by 0x50EB776: pn_transport_unbind (transport.c:795)
==3493==    by 0x50E663D: pn_connection_driver_release_connection 
(connection_driver.c:81)
==3493==    by 0x50E6678: pn_connection_driver_destroy (connection_driver.c:92)
==3493==    by 0x530A69B: pconnection_final_free (epoll.c:827)
==3493==    by 0x530DB36: pconnection_forced_shutdown (epoll.c:878)
==3493==    by 0x530DB36: pn_proactor_free (epoll.c:1815)
==3493==    by 0x4EA5BB4: qd_server_free (server.c:1176)
==3493==    by 0x4E6678D: qd_dispatch_free (dispatch.c:318)
==3493==    by 0x401863: main_process (main.c:116)
==3493==    by 0x4022AF: main (main.c:360)
==3493==  Address 0x15c06188 is 376 bytes inside a block of size 488 free'd
==3493==    at 0x4C2DD18: free (vg_replace_malloc.c:530)
==3493==    by 0x50DD938: pn_class_decref (object.c:101)
==3493==    by 0x50EA03F: pn_event_finalize (event.c:226)
==3493==    by 0x50EA03F: pn_event_finalize_cast (event.c:271)
==3493==    by 0x50DD928: pn_class_decref (object.c:95)
==3493==    by 0x50EA361: pn_collector_next (event.c:197)
==3493==    by 0x50E6408: batch_next (connection_driver.c:51)
==3493==    by 0x530C544: pconnection_batch_next (epoll.c:884)
==3493==    by 0x4EA50F2: thread_run (server.c:957)
==3493==    by 0x551950A: start_thread (in /usr/lib64/libpthread-2.26.so)
==3493==    by 0x629916E: clone (in /usr/lib64/libc-2.26.so)
==3493==  Block was alloc'd at
==3493==    at 0x4C2EA1E: calloc (vg_replace_malloc.c:711)
==3493==    by 0x50DD811: pn_object_new (object.c:202)
==3493==    

[jira] [Commented] (QPID-8158) [Broker-J] [System Tests] Refactor BDB HA system tests

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-8158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434149#comment-16434149
 ] 

ASF subversion and git services commented on QPID-8158:
---

Commit 768f4fb0961ff82ef49e09062ce19a7176b7d86a in qpid-broker-j's branch 
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=768f4fb ]

QPID-8158: [Broker-J] [System Tests] Remove qpid-systest module including 
QpidBrokerTestCase and its dependecies


> [Broker-J] [System Tests] Refactor BDB HA system tests
> --
>
> Key: QPID-8158
> URL: https://issues.apache.org/jira/browse/QPID-8158
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J, Java Tests
>Reporter: Alex Rudyy
>Priority: Major
>
> Currently BDB HA system tests are extended from {{QpidBrokerTestCase}}. They 
> need to be refactored to run with {{QpidTestRunner}}  similar to other system 
> tests.
> The BDB HA nodes  should be started as spawn brokers using special  
> {{BrokerAdmin}} allowing to start broker in a separate JVM.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-8158) [Broker-J] [System Tests] Refactor BDB HA system tests

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-8158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434148#comment-16434148
 ] 

ASF subversion and git services commented on QPID-8158:
---

Commit 1c38d9e09f0a4e6a0642ad0348989d0581159e85 in qpid-broker-j's branch 
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=1c38d9e ]

QPID-8158: [Broker-J] [System Tests] Stop expanding broker bundle for system 
tests


> [Broker-J] [System Tests] Refactor BDB HA system tests
> --
>
> Key: QPID-8158
> URL: https://issues.apache.org/jira/browse/QPID-8158
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J, Java Tests
>Reporter: Alex Rudyy
>Priority: Major
>
> Currently BDB HA system tests are extended from {{QpidBrokerTestCase}}. They 
> need to be refactored to run with {{QpidTestRunner}}  similar to other system 
> tests.
> The BDB HA nodes  should be started as spawn brokers using special  
> {{BrokerAdmin}} allowing to start broker in a separate JVM.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-8158) [Broker-J] [System Tests] Refactor BDB HA system tests

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-8158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434147#comment-16434147
 ] 

ASF subversion and git services commented on QPID-8158:
---

Commit 3a6893e464ec320a7bf4d8ab988c914be8b8f8d8 in qpid-broker-j's branch 
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=3a6893e ]

QPID-8158: [Broker-J] [System Tests] Refactor remaining system tests extending 
QpidBrokerTestCase


> [Broker-J] [System Tests] Refactor BDB HA system tests
> --
>
> Key: QPID-8158
> URL: https://issues.apache.org/jira/browse/QPID-8158
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J, Java Tests
>Reporter: Alex Rudyy
>Priority: Major
>
> Currently BDB HA system tests are extended from {{QpidBrokerTestCase}}. They 
> need to be refactored to run with {{QpidTestRunner}}  similar to other system 
> tests.
> The BDB HA nodes  should be started as spawn brokers using special  
> {{BrokerAdmin}} allowing to start broker in a separate JVM.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (PROTON-1826) [go] Add Messge.String() method for human-readable message printing

[Alan Conway (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Conway updated PROTON-1826:

Affects Version/s: proton-c-0.22.0

> [go] Add Messge.String() method for human-readable message printing
> ---
>
> Key: PROTON-1826
> URL: https://issues.apache.org/jira/browse/PROTON-1826
> Project: Qpid Proton
>  Issue Type: Improvement
>Affects Versions: proton-c-0.22.0
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
> Fix For: proton-c-0.23.0
>
>
> Use pn_inspect to stringify a message in a String() method



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (PROTON-1826) [go] Add Messge.String() method for human-readable message printing

[Alan Conway (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Conway resolved PROTON-1826.
-
   Resolution: Fixed
Fix Version/s: proton-c-0.23.0

> [go] Add Messge.String() method for human-readable message printing
> ---
>
> Key: PROTON-1826
> URL: https://issues.apache.org/jira/browse/PROTON-1826
> Project: Qpid Proton
>  Issue Type: Improvement
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
> Fix For: proton-c-0.23.0
>
>
> Use pn_inspect to stringify a message in a String() method



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1826) [go] Add Messge.String() method for human-readable message printing

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434113#comment-16434113
 ] 

ASF subversion and git services commented on PROTON-1826:
-

Commit be20a5186790815372f06e9a855955e330863426 in qpid-proton's branch 
refs/heads/master from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=be20a51 ]

PROTON-1826: [go] Add Messge.String() method for human-readable message


> [go] Add Messge.String() method for human-readable message printing
> ---
>
> Key: PROTON-1826
> URL: https://issues.apache.org/jira/browse/PROTON-1826
> Project: Qpid Proton
>  Issue Type: Improvement
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
> Fix For: proton-c-0.23.0
>
>
> Use pn_inspect to stringify a message in a String() method



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (PROTON-1826) [go] Add Messge.String() method for human-readable message printing

[Alan Conway (JIRA)]

Alan Conway created PROTON-1826:
---

 Summary: [go] Add Messge.String() method for human-readable 
message printing
 Key: PROTON-1826
 URL: https://issues.apache.org/jira/browse/PROTON-1826
 Project: Qpid Proton
  Issue Type: Improvement
Reporter: Alan Conway
Assignee: Alan Conway


Use pn_inspect to stringify a message in a String() method



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[GitHub] qpid-proton pull request #141: [windows] build fails if CMAKE_MODULE_PATH is...

[matlo607]

GitHub user matlo607 opened a pull request:

https://github.com/apache/qpid-proton/pull/141

[windows] build fails if CMAKE_MODULE_PATH is not empty, use 
CMAKE_SOURCE_DIR instead



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/matlo607/qpid-proton 
build-windows-python-script-path

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/qpid-proton/pull/141.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 #141


commit 884579dbca93cb32959896776db8839a20534d78
Author: Matthieu Longo 
Date:   2018-04-09T09:33:57Z

[windows] build fails if CMAKE_MODULE_PATH is not empty, use 
CMAKE_SOURCE_DIR instead




---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (DISPATCH-154) dispatch-router coredumps when connector address is unresolvable

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434053#comment-16434053
 ] 

ASF GitHub Bot commented on DISPATCH-154:
-

Github user fgiorgetti commented on the issue:

https://github.com/apache/qpid-dispatch/pull/268
  
Submitting a new PR for this new test following recommendations.


> dispatch-router coredumps when connector address is unresolvable
> 
>
> Key: DISPATCH-154
> URL: https://issues.apache.org/jira/browse/DISPATCH-154
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Reporter: Ted Ross
>Assignee: Ted Ross
>Priority: Major
> Fix For: 0.5
>
>
> If the address of a connector is unresolvable, the router will crash upon 
> resolution failure.  This can be reproduced by adding the following 
> configuration:
> {noformat}
> connector {
> addr: unres.bogus.unreg
> port: amqp
> role: on-demand
> saslMechanisms: ANONYMOUS
> name: bogus
> }
> linkRoutePattern {
> prefix: abc
> connector: bogus
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (DISPATCH-154) dispatch-router coredumps when connector address is unresolvable

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434054#comment-16434054
 ] 

ASF GitHub Bot commented on DISPATCH-154:
-

Github user fgiorgetti closed the pull request at:

https://github.com/apache/qpid-dispatch/pull/268


> dispatch-router coredumps when connector address is unresolvable
> 
>
> Key: DISPATCH-154
> URL: https://issues.apache.org/jira/browse/DISPATCH-154
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Reporter: Ted Ross
>Assignee: Ted Ross
>Priority: Major
> Fix For: 0.5
>
>
> If the address of a connector is unresolvable, the router will crash upon 
> resolution failure.  This can be reproduced by adding the following 
> configuration:
> {noformat}
> connector {
> addr: unres.bogus.unreg
> port: amqp
> role: on-demand
> saslMechanisms: ANONYMOUS
> name: bogus
> }
> linkRoutePattern {
> prefix: abc
> connector: bogus
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[GitHub] qpid-dispatch pull request #268: DISPATCH-154 - Added new test case to ensur...

[fgiorgetti]

Github user fgiorgetti closed the pull request at:

https://github.com/apache/qpid-dispatch/pull/268


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[GitHub] qpid-dispatch issue #268: DISPATCH-154 - Added new test case to ensure route...

[fgiorgetti]

Github user fgiorgetti commented on the issue:

https://github.com/apache/qpid-dispatch/pull/268
  
Submitting a new PR for this new test following recommendations.


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[GitHub] qpid-dispatch pull request #285: DISPATCH-154 - Added new tests to validate ...

[fgiorgetti]

Github user fgiorgetti closed the pull request at:

https://github.com/apache/qpid-dispatch/pull/285


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (DISPATCH-154) dispatch-router coredumps when connector address is unresolvable

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434046#comment-16434046
 ] 

ASF GitHub Bot commented on DISPATCH-154:
-

Github user fgiorgetti closed the pull request at:

https://github.com/apache/qpid-dispatch/pull/285


> dispatch-router coredumps when connector address is unresolvable
> 
>
> Key: DISPATCH-154
> URL: https://issues.apache.org/jira/browse/DISPATCH-154
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Reporter: Ted Ross
>Assignee: Ted Ross
>Priority: Major
> Fix For: 0.5
>
>
> If the address of a connector is unresolvable, the router will crash upon 
> resolution failure.  This can be reproduced by adding the following 
> configuration:
> {noformat}
> connector {
> addr: unres.bogus.unreg
> port: amqp
> role: on-demand
> saslMechanisms: ANONYMOUS
> name: bogus
> }
> linkRoutePattern {
> prefix: abc
> connector: bogus
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (DISPATCH-962) links established to 'unavailable' addresses are not refused correctly

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DISPATCH-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated DISPATCH-962:

Description: 
When setting an address as unavailable (via defaultDistribution: unavailable 
from DISPATCH-803) the router doesn't refuse the links to it in the manner the 
spec indicates it should.

To indicate a link is being refused, the spec describes that the attach 
response should contain a null target/source as appropriate, essentially 
indicating to the peer that the detach will follow due to the error, 
[http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp315568],
 Figure 2.33: Refusing a Link.

Currently this does not happen, e.g:

Creating a sending link, response attach with non-null Target:
{noformat}
[750316387:1] -> 
Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
 handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
source=Source{address='ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1', 
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
dynamicNodeProperties=null, distributionMode=null, filter=null, 
defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list, 
amqp:released:list, amqp:modified:list], capabilities=null}, 
target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END, 
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]}, 
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
maxMessageSize=null, offeredCapabilities=null, 
desiredCapabilities=[DELAYED_DELIVERY], properties=null}
[750316387:1] <- 
Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
 handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST, 
source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, 
timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, 
target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END, 
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, 
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, 
properties=null}
{noformat}
Creating a receiving link, response attach with non-null Source:
{noformat}
[59324032:1] -> 
Attach{name='qpid-jms:receiver:ID:30b1b1c9-316b-4be1-9944-15b5822a6500:1:1:1:queue',
 handle=0, role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
source=Source{address='queue', durable=NONE, expiryPolicy=LINK_DETACH, 
timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
filter=null, defaultOutcome=Modified{deliveryFailed=true, 
undeliverableHere=null, messageAnnotations=null}, outcomes=[amqp:accepted:list, 
amqp:rejected:list, amqp:released:list, amqp:modified:list], 
capabilities=[queue]}, target=Target{address='null', durable=NONE, 
expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, 
capabilities=null}, unsettled=null, incompleteUnsettled=false, 
initialDeliveryCount=null, maxMessageSize=null, offeredCapabilities=null, 
desiredCapabilities=null, properties=null}
[59324032:1] <- 
Attach{name='qpid-jms:receiver:ID:30b1b1c9-316b-4be1-9944-15b5822a6500:1:1:1:queue',
 handle=0, role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST, 
source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, 
timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, 
target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END, 
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, 
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, 
properties=null}
{noformat}
The links are detached after this, but the non-null terminus removes the hint 
to the peer that it is coming.

  was:
When setting an address as unavailable (via defaultDistribution: unavailable 
from DISPATCH-803) the router doesn't refuse the links to it in the manner the 
spec indicates it should.

To indicate a link is being refused, the spec describes that the attach 
response should contain a null target/source as appropriate, essentially 
indicating to the peer that the detach will follow due to the error, 
[http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp315568],
 Figure 2.33: Refusing a Link.

Currently this does not happen, e.g:

Creating a sending link, response attach with non-null Target:
{noformat}
[750316387:1] -> 
Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
 handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 

[jira] [Commented] (QPIDJMS-376) notify the ExceptionListner when a consumer with a MessageListener remotely closes

[Robbie Gemmell (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPIDJMS-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434028#comment-16434028
 ] 

Robbie Gemmell commented on QPIDJMS-376:


DISPATCH-962 raised for what I think will be the related server behaviour seen 
here.

> notify the ExceptionListner when a consumer with a MessageListener remotely 
> closes
> --
>
> Key: QPIDJMS-376
> URL: https://issues.apache.org/jira/browse/QPIDJMS-376
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.31.0
> Environment: AMQP Server: Enmasse 0.17.1
> Enmasse Address Type: anycast
>Reporter: Daniel Maier
>Priority: Major
> Fix For: 0.32.0
>
> Attachments: clientlogs.txt
>
>
> When I create a consumer to an address that just does not exist, I expected 
> to get some exception or that the client retries the operation. But there 
> seems not even to be a log message which indicates a failure.
> Is this intended behavior or is this a bug? A more general description is: If 
> AMQP server closes the receiver link, qpid jms client does not notify the 
> user anyhow or does not re-establish the link.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (DISPATCH-962) links established to 'unavailable' addresses are not refused correctly

[Robbie Gemmell (JIRA)]

Robbie Gemmell created DISPATCH-962:
---

 Summary: links established to 'unavailable' addresses are not 
refused correctly
 Key: DISPATCH-962
 URL: https://issues.apache.org/jira/browse/DISPATCH-962
 Project: Qpid Dispatch
  Issue Type: Bug
Affects Versions: 1.0.1, 1.0.0, 1.1.0
Reporter: Robbie Gemmell


When setting an address as unavailable (via defaultDistribution: unavailable 
from DISPATCH-803) the router doesn't refuse the links to it in the manner the 
spec indicates it should.

To indicate a link is being refused, the spec describes that the attach 
response should contain a null target/source as appropriate, essentially 
indicating to the peer that the detach will follow due to the error, 
[http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp315568],
 Figure 2.33: Refusing a Link.

Currently this does not happen, e.g:

Creating a sending link, response attach with non-null Target:
{noformat}
[750316387:1] -> 
Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
 handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
source=Source{address='ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1', 
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
dynamicNodeProperties=null, distributionMode=null, filter=null, 
defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list, 
amqp:released:list, amqp:modified:list], capabilities=null}, 
target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END, 
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]}, 
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
maxMessageSize=null, offeredCapabilities=null, 
desiredCapabilities=[DELAYED_DELIVERY], properties=null}
[750316387:1] <- 
Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
 handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST, 
source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, 
timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, 
target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END, 
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, 
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, 
properties=null}
{noformat}
Creating a receiving link, response attach with non-null Source:
{noformat}
[59324032:1] -> 
Attach{name='qpid-jms:receiver:ID:30b1b1c9-316b-4be1-9944-15b5822a6500:1:1:1:queue',
 handle=0, role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
source=Source{address='queue', durable=NONE, expiryPolicy=LINK_DETACH, 
timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
filter=null, defaultOutcome=Modified{deliveryFailed=true, 
undeliverableHere=null, messageAnnotations=null}, outcomes=[amqp:accepted:list, 
amqp:rejected:list, amqp:released:list, amqp:modified:list], 
capabilities=[queue]}, target=Target{address='null', durable=NONE, 
expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null, 
capabilities=null}, unsettled=null, incompleteUnsettled=false, 
initialDeliveryCount=null, maxMessageSize=null, offeredCapabilities=null, 
desiredCapabilities=null, properties=null}
[59324032:1] <- 
Attach{name='qpid-jms:receiver:ID:30b1b1c9-316b-4be1-9944-15b5822a6500:1:1:1:queue',
 handle=0, role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST, 
source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END, 
timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null, 
filter=null, defaultOutcome=null, outcomes=null, capabilities=null}, 
target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END, 
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, 
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, 
properties=null}
{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-8160) [Broker-J] [AMQP 1.0] AccessControlException when creating sending link reported as amqp:internal-error rather than amqp:unauthorised-access

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-8160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-8160:
-
Description: 
If the Broker tries to create a sending link from a source but the user has 
insufficient permissions for that source, I expect the {{detach}} to use error 
{{amqp:unauthorised-access}}. This currently does not happen, the Broker sends 
{{amqp:amqp:internal-error}} instead.
{noformat}
[511142734:1] <- Detach{handle=1, closed=true, 
error=Error{condition=amqp:internal-error, description='Permission CREATE is 
denied for : Consumer 
'4|1|qpid-jms:receiver:ID:2a653090-1dbc-4433-955d-791b52540128:1:1:1:guestqueue'
 on Queue 'guestqueue'', info=null}}{noformat}
 

  was:
If the Broker tries to create a sending link from a source but the user has 
insufficient permissions for that source, I expect the {{detach }}to use error 
{{amqp:unauthorised-access}}. This currently does not happen, the Broker sends 
\{{amqp:amqp:internal-error }}instead.
{noformat}
[511142734:1] <- Detach{handle=1, closed=true, 
error=Error{condition=amqp:internal-error, description='Permission CREATE is 
denied for : Consumer 
'4|1|qpid-jms:receiver:ID:2a653090-1dbc-4433-955d-791b52540128:1:1:1:guestqueue'
 on Queue 'guestqueue'', info=null}}{noformat}
 


>  [Broker-J] [AMQP 1.0] AccessControlException when creating sending link 
> reported as  amqp:internal-error rather than amqp:unauthorised-access
> --
>
> Key: QPID-8160
> URL: https://issues.apache.org/jira/browse/QPID-8160
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1
>Reporter: Keith Wall
>Priority: Minor
>
> If the Broker tries to create a sending link from a source but the user has 
> insufficient permissions for that source, I expect the {{detach}} to use 
> error {{amqp:unauthorised-access}}. This currently does not happen, the 
> Broker sends {{amqp:amqp:internal-error}} instead.
> {noformat}
> [511142734:1] <- Detach{handle=1, closed=true, 
> error=Error{condition=amqp:internal-error, description='Permission CREATE is 
> denied for : Consumer 
> '4|1|qpid-jms:receiver:ID:2a653090-1dbc-4433-955d-791b52540128:1:1:1:guestqueue'
>  on Queue 'guestqueue'', info=null}}{noformat}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-8160) [Broker-J] [AMQP 1.0] AccessControlException when creating sending link reported as amqp:internal-error rather than amqp:unauthorised-access

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-8160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-8160:
-
Description: 
If the Broker tries to create a sending link from a source but the user has 
insufficient permissions for that source, I expect the {{detach }}to use error 
{{amqp:unauthorised-access}}. This currently does not happen, the Broker sends 
\{{amqp:amqp:internal-error }}instead.
{noformat}
[511142734:1] <- Detach{handle=1, closed=true, 
error=Error{condition=amqp:internal-error, description='Permission CREATE is 
denied for : Consumer 
'4|1|qpid-jms:receiver:ID:2a653090-1dbc-4433-955d-791b52540128:1:1:1:guestqueue'
 on Queue 'guestqueue'', info=null}}{noformat}
 

  was:
If the Broker tries to create a sending link from a source but the user has 
insufficient permissions for that queue, I expect the {{detach }}to use error 
{{amqp:unauthorised-access}}. This currently does not happen, the Broker sends 
\{{amqp:amqp:internal-error }}instead.
{noformat}
[511142734:1] <- Detach{handle=1, closed=true, 
error=Error{condition=amqp:internal-error, description='Permission CREATE is 
denied for : Consumer 
'4|1|qpid-jms:receiver:ID:2a653090-1dbc-4433-955d-791b52540128:1:1:1:guestqueue'
 on Queue 'guestqueue'', info=null}}{noformat}
 


>  [Broker-J] [AMQP 1.0] AccessControlException when creating sending link 
> reported as  amqp:internal-error rather than amqp:unauthorised-access
> --
>
> Key: QPID-8160
> URL: https://issues.apache.org/jira/browse/QPID-8160
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1
>Reporter: Keith Wall
>Priority: Minor
>
> If the Broker tries to create a sending link from a source but the user has 
> insufficient permissions for that source, I expect the {{detach }}to use 
> error {{amqp:unauthorised-access}}. This currently does not happen, the 
> Broker sends \{{amqp:amqp:internal-error }}instead.
> {noformat}
> [511142734:1] <- Detach{handle=1, closed=true, 
> error=Error{condition=amqp:internal-error, description='Permission CREATE is 
> denied for : Consumer 
> '4|1|qpid-jms:receiver:ID:2a653090-1dbc-4433-955d-791b52540128:1:1:1:guestqueue'
>  on Queue 'guestqueue'', info=null}}{noformat}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-8160) [Broker-J] [AMQP 1.0] AccessControlException when creating sending link reported as amqp:internal-error rather than amqp:unauthorised-access

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-8160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-8160:
-
Priority: Minor  (was: Major)

>  [Broker-J] [AMQP 1.0] AccessControlException when creating sending link 
> reported as  amqp:internal-error rather than amqp:unauthorised-access
> --
>
> Key: QPID-8160
> URL: https://issues.apache.org/jira/browse/QPID-8160
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1
>Reporter: Keith Wall
>Priority: Minor
>
> If the Broker tries to create a sending link to a target but the user has 
> insufficient permissions, I expect the {{detach }}to use error 
> {{amqp:unauthorised-access}}. This currently does not happen, the Broker 
> sends {{amqp:amqp:internal-error }}instead.
> {noformat}
> [511142734:1] <- Detach{handle=1, closed=true, 
> error=Error{condition=amqp:internal-error, description='Permission CREATE is 
> denied for : Consumer 
> '4|1|qpid-jms:receiver:ID:2a653090-1dbc-4433-955d-791b52540128:1:1:1:guestqueue'
>  on Queue 'guestqueue'', info=null}}{noformat}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-8160) [Broker-J] [AMQP 1.0] AccessControlException when creating sending link reported as amqp:internal-error rather than amqp:unauthorised-access

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-8160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-8160:
-
Affects Version/s: qpid-java-broker-7.1

>  [Broker-J] [AMQP 1.0] AccessControlException when creating sending link 
> reported as  amqp:internal-error rather than amqp:unauthorised-access
> --
>
> Key: QPID-8160
> URL: https://issues.apache.org/jira/browse/QPID-8160
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1
>Reporter: Keith Wall
>Priority: Major
>
> If the Broker tries to create a sending link to a target but the user has 
> insufficient permissions, I expect the {{detach }}to use error 
> {{amqp:unauthorised-access}}. This currently does not happen, the Broker 
> sends {{amqp:amqp:internal-error }}instead.
> {noformat}
> [511142734:1] <- Detach{handle=1, closed=true, 
> error=Error{condition=amqp:internal-error, description='Permission CREATE is 
> denied for : Consumer 
> '4|1|qpid-jms:receiver:ID:2a653090-1dbc-4433-955d-791b52540128:1:1:1:guestqueue'
>  on Queue 'guestqueue'', info=null}}{noformat}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-8160) [Broker-J] [AMQP 1.0] AccessControlException when creating sending link reported as amqp:internal-error rather than amqp:unauthorised-access

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-8160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-8160:
-
Description: 
If the Broker tries to create a sending link from a source but the user has 
insufficient permissions for that queue, I expect the {{detach }}to use error 
{{amqp:unauthorised-access}}. This currently does not happen, the Broker sends 
\{{amqp:amqp:internal-error }}instead.
{noformat}
[511142734:1] <- Detach{handle=1, closed=true, 
error=Error{condition=amqp:internal-error, description='Permission CREATE is 
denied for : Consumer 
'4|1|qpid-jms:receiver:ID:2a653090-1dbc-4433-955d-791b52540128:1:1:1:guestqueue'
 on Queue 'guestqueue'', info=null}}{noformat}
 

  was:
If the Broker tries to create a sending link to a target but the user has 
insufficient permissions, I expect the {{detach }}to use error 
{{amqp:unauthorised-access}}. This currently does not happen, the Broker sends 
{{amqp:amqp:internal-error }}instead.
{noformat}
[511142734:1] <- Detach{handle=1, closed=true, 
error=Error{condition=amqp:internal-error, description='Permission CREATE is 
denied for : Consumer 
'4|1|qpid-jms:receiver:ID:2a653090-1dbc-4433-955d-791b52540128:1:1:1:guestqueue'
 on Queue 'guestqueue'', info=null}}{noformat}
 


>  [Broker-J] [AMQP 1.0] AccessControlException when creating sending link 
> reported as  amqp:internal-error rather than amqp:unauthorised-access
> --
>
> Key: QPID-8160
> URL: https://issues.apache.org/jira/browse/QPID-8160
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1
>Reporter: Keith Wall
>Priority: Minor
>
> If the Broker tries to create a sending link from a source but the user has 
> insufficient permissions for that queue, I expect the {{detach }}to use error 
> {{amqp:unauthorised-access}}. This currently does not happen, the Broker 
> sends \{{amqp:amqp:internal-error }}instead.
> {noformat}
> [511142734:1] <- Detach{handle=1, closed=true, 
> error=Error{condition=amqp:internal-error, description='Permission CREATE is 
> denied for : Consumer 
> '4|1|qpid-jms:receiver:ID:2a653090-1dbc-4433-955d-791b52540128:1:1:1:guestqueue'
>  on Queue 'guestqueue'', info=null}}{noformat}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (QPID-8160) [Broker-J] [AMQP 1.0] AccessControlException when creating sending link reported as amqp:internal-error rather than amqp:unauthorised-access

[Keith Wall (JIRA)]

Keith Wall created QPID-8160:


 Summary:  [Broker-J] [AMQP 1.0] AccessControlException when 
creating sending link reported as  amqp:internal-error rather than 
amqp:unauthorised-access
 Key: QPID-8160
 URL: https://issues.apache.org/jira/browse/QPID-8160
 Project: Qpid
  Issue Type: Bug
  Components: Broker-J
Reporter: Keith Wall


If the Broker tries to create a sending link to a target but the user has 
insufficient permissions, I expect the {{detach }}to use error 
{{amqp:unauthorised-access}}. This currently does not happen, the Broker sends 
{{amqp:amqp:internal-error }}instead.
{noformat}
[511142734:1] <- Detach{handle=1, closed=true, 
error=Error{condition=amqp:internal-error, description='Permission CREATE is 
denied for : Consumer 
'4|1|qpid-jms:receiver:ID:2a653090-1dbc-4433-955d-791b52540128:1:1:1:guestqueue'
 on Queue 'guestqueue'', info=null}}{noformat}
 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (DISPATCH-961) Replace connection attribute in autoLink and linkRoute with listener and connector

[Ganesh Murthy (JIRA)]

Ganesh Murthy created DISPATCH-961:
--

 Summary: Replace connection attribute in autoLink and linkRoute 
with listener and connector
 Key: DISPATCH-961
 URL: https://issues.apache.org/jira/browse/DISPATCH-961
 Project: Qpid Dispatch
  Issue Type: Improvement
  Components: Container
Affects Versions: 1.0.1
Reporter: Ganesh Murthy
Assignee: Ganesh Murthy


At present, there is an attribute called connection in linkRoute and autoLink 
entities. This connection can reference either the connector or listener name. 
To make this more clear deprecate connection and introduce two new attributes 
called connector and listener in its place. Only one of containerId or 
connector or listener can be specified.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (DISPATCH-918) Improve router config consistency and metadata

[Ganesh Murthy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DISPATCH-918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ganesh Murthy resolved DISPATCH-918.

Resolution: Fixed

> Improve router config consistency and metadata
> --
>
> Key: DISPATCH-918
> URL: https://issues.apache.org/jira/browse/DISPATCH-918
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Management Agent
>Reporter: Justin Ross
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.1.0
>
>
> Proposed changes from review.  The items marked PRIO1 are more important.  
> All changes must be backward-compatible.
> [https://docs.google.com/spreadsheets/d/14ugjxlc-ETYZXwN9eWD-D1YWrRAfydj9EJNmyUaZrD0/edit?usp=sharing]
> This also includes flags we'd like to get added to the metadata so we can 
> generate better docs from it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (QPIDJMS-376) notify the ExceptionListner when a consumer with a MessageListener remotely closes

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPIDJMS-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell resolved QPIDJMS-376.

Resolution: Fixed

The exception listener is now fired for remotely closed consumers with message 
listeners.

> notify the ExceptionListner when a consumer with a MessageListener remotely 
> closes
> --
>
> Key: QPIDJMS-376
> URL: https://issues.apache.org/jira/browse/QPIDJMS-376
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.31.0
> Environment: AMQP Server: Enmasse 0.17.1
> Enmasse Address Type: anycast
>Reporter: Daniel Maier
>Priority: Major
> Fix For: 0.32.0
>
> Attachments: clientlogs.txt
>
>
> When I create a consumer to an address that just does not exist, I expected 
> to get some exception or that the client retries the operation. But there 
> seems not even to be a log message which indicates a failure.
> Is this intended behavior or is this a bug? A more general description is: If 
> AMQP server closes the receiver link, qpid jms client does not notify the 
> user anyhow or does not re-establish the link.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPIDJMS-376) notify the ExceptionListner when a consumer with a MessageListener remotely closes

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPIDJMS-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433834#comment-16433834
 ] 

ASF subversion and git services commented on QPIDJMS-376:
-

Commit a307df8bcb24f29760cb68c51f92f420396c1c3a in qpid-jms's branch 
refs/heads/master from [~gemmellr]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=a307df8 ]

QPIDJMS-376: add related test (and verify exception listener isnt called for 
regular close) and restore timeout on an existing test


> notify the ExceptionListner when a consumer with a MessageListener remotely 
> closes
> --
>
> Key: QPIDJMS-376
> URL: https://issues.apache.org/jira/browse/QPIDJMS-376
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.31.0
> Environment: AMQP Server: Enmasse 0.17.1
> Enmasse Address Type: anycast
>Reporter: Daniel Maier
>Priority: Major
> Fix For: 0.32.0
>
> Attachments: clientlogs.txt
>
>
> When I create a consumer to an address that just does not exist, I expected 
> to get some exception or that the client retries the operation. But there 
> seems not even to be a log message which indicates a failure.
> Is this intended behavior or is this a bug? A more general description is: If 
> AMQP server closes the receiver link, qpid jms client does not notify the 
> user anyhow or does not re-establish the link.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (DISPATCH-154) dispatch-router coredumps when connector address is unresolvable

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433791#comment-16433791
 ] 

ASF GitHub Bot commented on DISPATCH-154:
-

Github user fgiorgetti commented on the issue:

https://github.com/apache/qpid-dispatch/pull/285
  
Yes I see that as well, but it happens before the connection is 
established. Right after that I am seeing the error below:

2018-04-11 08:47:15.086037 -0300 CONN_MGR (info) Configured Connector: 
unresolvable.host.name:amqp proto=any, role=normal 
(/home/fgiorget/git/qpid-dispatch-fgiorgetti/src/connection_manager.c:623)
2018-04-11 08:47:15.194168 -0300 SERVER (info) Connection to 
unresolvable.host.name:amqp failed: **proton:io Name or service not known** - 
connect to  unresolvable.host.name:5672 
(/home/fgiorget/git/qpid-dispatch-fgiorgetti/src/server.c:921)

I will investigate further and report back if in case I find something new.


> dispatch-router coredumps when connector address is unresolvable
> 
>
> Key: DISPATCH-154
> URL: https://issues.apache.org/jira/browse/DISPATCH-154
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Reporter: Ted Ross
>Assignee: Ted Ross
>Priority: Major
> Fix For: 0.5
>
>
> If the address of a connector is unresolvable, the router will crash upon 
> resolution failure.  This can be reproduced by adding the following 
> configuration:
> {noformat}
> connector {
> addr: unres.bogus.unreg
> port: amqp
> role: on-demand
> saslMechanisms: ANONYMOUS
> name: bogus
> }
> linkRoutePattern {
> prefix: abc
> connector: bogus
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[GitHub] qpid-dispatch issue #285: DISPATCH-154 - Added new tests to validate unresol...

[fgiorgetti]

Github user fgiorgetti commented on the issue:

https://github.com/apache/qpid-dispatch/pull/285
  
Yes I see that as well, but it happens before the connection is 
established. Right after that I am seeing the error below:

2018-04-11 08:47:15.086037 -0300 CONN_MGR (info) Configured Connector: 
unresolvable.host.name:amqp proto=any, role=normal 
(/home/fgiorget/git/qpid-dispatch-fgiorgetti/src/connection_manager.c:623)
2018-04-11 08:47:15.194168 -0300 SERVER (info) Connection to 
unresolvable.host.name:amqp failed: **proton:io Name or service not known** - 
connect to  unresolvable.host.name:5672 
(/home/fgiorget/git/qpid-dispatch-fgiorgetti/src/server.c:921)

I will investigate further and report back if in case I find something new.


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPIDJMS-376) notify the ExceptionListner when a consumer with a MessageListener remotely closes

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPIDJMS-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433757#comment-16433757
 ] 

ASF subversion and git services commented on QPIDJMS-376:
-

Commit da0d4e50a43a51abd51a13a9996b116d851d2f62 in qpid-jms's branch 
refs/heads/master from [~gemmellr]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=da0d4e5 ]

QPIDJMS-376: fix tests to avoid sporadic/erroneous failures due to races


> notify the ExceptionListner when a consumer with a MessageListener remotely 
> closes
> --
>
> Key: QPIDJMS-376
> URL: https://issues.apache.org/jira/browse/QPIDJMS-376
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.31.0
> Environment: AMQP Server: Enmasse 0.17.1
> Enmasse Address Type: anycast
>Reporter: Daniel Maier
>Priority: Major
> Fix For: 0.32.0
>
> Attachments: clientlogs.txt
>
>
> When I create a consumer to an address that just does not exist, I expected 
> to get some exception or that the client retries the operation. But there 
> seems not even to be a log message which indicates a failure.
> Is this intended behavior or is this a bug? A more general description is: If 
> AMQP server closes the receiver link, qpid jms client does not notify the 
> user anyhow or does not re-establish the link.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (QPID-8159) [Broker-J] Upgrade Jackson from 2.9.4 to 2.9.5 (CVE-2018-7489)

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-8159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall resolved QPID-8159.
--
Resolution: Fixed

> [Broker-J] Upgrade Jackson from 2.9.4 to 2.9.5 (CVE-2018-7489)
> --
>
> Key: QPID-8159
> URL: https://issues.apache.org/jira/browse/QPID-8159
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Major
>
> QPID-8136 upgrade Jackson on master from 2.8.7 to 2.9.4 in response to 
> CVE-2017-7525.  However it is now know that the blacklist include in 2.9.4 
> was incomplete.This is the subject of CVE-2018-7489.
> This problem affects only the master branch.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Assigned] (QPID-8159) [Broker-J] Upgrade Jackson from 2.9.4 to 2.9.5 (CVE-2018-7489)

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-8159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall reassigned QPID-8159:


Assignee: Keith Wall

> [Broker-J] Upgrade Jackson from 2.9.4 to 2.9.5 (CVE-2018-7489)
> --
>
> Key: QPID-8159
> URL: https://issues.apache.org/jira/browse/QPID-8159
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Major
>
> QPID-8136 upgrade Jackson on master from 2.8.7 to 2.9.4 in response to 
> CVE-2017-7525.  However it is now know that the blacklist include in 2.9.4 
> was incomplete.This is the subject of CVE-2018-7489.
> This problem affects only the master branch.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-8159) [Broker-J] Upgrade Jackson from 2.9.4 to 2.9.5 (CVE-2018-7489)

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-8159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433724#comment-16433724
 ] 

ASF subversion and git services commented on QPID-8159:
---

Commit 7f0219c937a6dd54c7acffed6fff03ae3c473821 in qpid-broker-j's branch 
refs/heads/master from [~k-wall]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=7f0219c ]

QPID-8159: Upgrade Jackson from 2.9.4 to 2.9.5


> [Broker-J] Upgrade Jackson from 2.9.4 to 2.9.5 (CVE-2018-7489)
> --
>
> Key: QPID-8159
> URL: https://issues.apache.org/jira/browse/QPID-8159
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0
>Reporter: Keith Wall
>Priority: Major
>
> QPID-8136 upgrade Jackson on master from 2.8.7 to 2.9.4 in response to 
> CVE-2017-7525.  However it is now know that the blacklist include in 2.9.4 
> was incomplete.This is the subject of CVE-2018-7489.
> This problem affects only the master branch.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Closed] (PROTON-1523) [proton c] API unclear how incoming_capacity and max_frame work

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell closed PROTON-1523.
--
Resolution: Done

Closing this out and considering it as part of PROTON-636 doc updates. 
PROTON-636 removes the confusing default capacity and as part of that enables 
disabling 'capacity handling' when frame size is set if desired.

> [proton c] API unclear how incoming_capacity and max_frame work
> ---
>
> Key: PROTON-1523
> URL: https://issues.apache.org/jira/browse/PROTON-1523
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.17.0
>Reporter: Chuck Rolke
>Priority: Major
>
> Two settings are available to throttle incoming traffic. These operate in 
> units of bytes:
> * pn_transport_set_max_frame
> * pn_session_set_incoming_capacity
> Suppose a user sets a max_frame to 1 Mbyte and incoming_capacity to 2 Mbytes. 
> How many 200-byte hello-world messages might a user expect to be able to 
> receive before the local incoming-window closes? 10,000? The answer turns out 
> to be 2.
> The logical disconnect is that the user interface incoming_capacity operates 
> in bytes but the AMQP protocol over the wire operates with an Incoming-Window 
> in frames. In the user's case the API assumes full frames and sets  
> Incoming-Window = (incoming_capacity / max_frame), or 2. When the sending 
> peer sends 200-byte messages the actual incoming capacity is 400 bytes and 
> not 2Mbytes.
> The rules (AFAICT) are:
> {noformat}
>   IF (max_size is specified)
> incoming_window = incoming_capacity / max_size
>   ELSE
> incoming_window = 2147473647
>   ENDIF
> {noformat}
> Noting:
> * Incoming capacity is achieved only if the peer sends max_size frames.
> * If max_frame is not set then the incoming_capacity setting is ignored.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1523) [proton c] API unclear how incoming_capacity and max_frame work

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433709#comment-16433709
 ] 

ASF subversion and git services commented on PROTON-1523:
-

Commit d58bd7154558a3be3a68dfee71f08c7d76bad958 in qpid-proton's branch 
refs/heads/master from [~gemmellr]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=d58bd71 ]

PROTON-636, PROTON-1809, PROTON-1523: update session capacity api doc to 
clarify its behaviour


> [proton c] API unclear how incoming_capacity and max_frame work
> ---
>
> Key: PROTON-1523
> URL: https://issues.apache.org/jira/browse/PROTON-1523
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.17.0
>Reporter: Chuck Rolke
>Priority: Major
>
> Two settings are available to throttle incoming traffic. These operate in 
> units of bytes:
> * pn_transport_set_max_frame
> * pn_session_set_incoming_capacity
> Suppose a user sets a max_frame to 1 Mbyte and incoming_capacity to 2 Mbytes. 
> How many 200-byte hello-world messages might a user expect to be able to 
> receive before the local incoming-window closes? 10,000? The answer turns out 
> to be 2.
> The logical disconnect is that the user interface incoming_capacity operates 
> in bytes but the AMQP protocol over the wire operates with an Incoming-Window 
> in frames. In the user's case the API assumes full frames and sets  
> Incoming-Window = (incoming_capacity / max_frame), or 2. When the sending 
> peer sends 200-byte messages the actual incoming capacity is 400 bytes and 
> not 2Mbytes.
> The rules (AFAICT) are:
> {noformat}
>   IF (max_size is specified)
> incoming_window = incoming_capacity / max_size
>   ELSE
> incoming_window = 2147473647
>   ENDIF
> {noformat}
> Noting:
> * Incoming capacity is achieved only if the peer sends max_size frames.
> * If max_frame is not set then the incoming_capacity setting is ignored.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1809) [python, ruby] Unable to receive messages when max-frame-size is set to more than 2^20

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433708#comment-16433708
 ] 

ASF subversion and git services commented on PROTON-1809:
-

Commit d58bd7154558a3be3a68dfee71f08c7d76bad958 in qpid-proton's branch 
refs/heads/master from [~gemmellr]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=d58bd71 ]

PROTON-636, PROTON-1809, PROTON-1523: update session capacity api doc to 
clarify its behaviour


> [python, ruby] Unable to receive messages when max-frame-size is set to more 
> than 2^20
> --
>
> Key: PROTON-1809
> URL: https://issues.apache.org/jira/browse/PROTON-1809
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding, ruby-binding
>Affects Versions: proton-c-0.22.0
> Environment: RHEL 7 x86_64
>Reporter: Radim Kubis
>Assignee: Alan Conway
>Priority: Minor
> Fix For: proton-c-0.23.0
>
>
> *Python:*
> {code:java}
>   def on_session_init(self, event):
>  event.transport._set_max_frame_size(VALUE)
> {code}
> I noticed that the receiver is not able to receive messages when the value 
> for max-frame-size is larger than 2^20 (1048576) bytes (remote_max_frame_size 
> is 4294967295). I'm not really sure if that is expected. This may be 
> reproduced when adding the code above ie.: to simple_recv.py.
> Note: This is not a good use case as setting the max-frame-size in 
> on_session_init is really too late. But given that it is too late to set the 
> max-frame-size, I would expect it won't have any effect on the client.
>  
> *Ruby:*
> From [https://github.com/rh-messaging/cli-proton-ruby] 
> [cli-proton-ruby|https://github.com/rh-messaging/cli-proton-ruby]
> {{cli-proton-ruby-receiver -b  -c  --log-msgs dict 
> --conn-max-frame-size 1048577}}
> Receiver is stuck.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-636) remove confusing default for session capacity and allow disabling it

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433707#comment-16433707
 ] 

ASF subversion and git services commented on PROTON-636:


Commit d58bd7154558a3be3a68dfee71f08c7d76bad958 in qpid-proton's branch 
refs/heads/master from [~gemmellr]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=d58bd71 ]

PROTON-636, PROTON-1809, PROTON-1523: update session capacity api doc to 
clarify its behaviour


> remove confusing default for session capacity and allow disabling it
> 
>
> Key: PROTON-636
> URL: https://issues.apache.org/jira/browse/PROTON-636
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Reporter: Rafael H. Schloming
>Assignee: Alan Conway
>Priority: Minor
>  Labels: framing
> Fix For: proton-c-0.23.0
>
>
> Original title: setting a 1MB frame size results in an undesirably small 
> session window)
> Description, from PROTON-1739:
> The session has a default 'incoming capacity' of 1MB, which actually has no 
> effect by default and leads to unexpected behaviour while changing other 
> configuration. It should be removed.
> The value is used when the engine decides what incoming session window to set 
> on Flow frames, but only if a specific frame size is configured for the 
> transport, which it isn't by default. If a specific frame size is set, then 
> any session capacity really needs to be set based on it in order to be 
> appropriate, the default being fixed as it is leads to unexpectedly low 
> window sizes in many cases which will impact performance in unexpected ways. 
> Its confusing that setting frame size results in completely different 
> behaviour than before for another thing (window size) which perhaps hasn't 
> been configured at all, and the existing behaviour is also such that you cant 
> turn it off.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-8159) [Broker-J] Upgrade Jackson from 2.9.4 to 2.9.5 (CVE-2018-7489)

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-8159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-8159:
-
Description: 
QPID-8136 upgrade Jackson on master from 2.8.7 to 2.9.4 in response to 
CVE-2017-7525.  However it is now know that the blacklist include in 2.9.4 was 
incomplete.This is the subject of CVE-2018-7489.

This problem affects only the master branch.


  was:
QPID-8136 upgrade Jackson on master from 2.8.7 to 2.9.4 in response to 
CVE-2017-7525.  However it is now know that the blacklist include in 2.9.4 was 
incomplete.This is the subject of CVE-2018-7489.



> [Broker-J] Upgrade Jackson from 2.9.4 to 2.9.5 (CVE-2018-7489)
> --
>
> Key: QPID-8159
> URL: https://issues.apache.org/jira/browse/QPID-8159
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0
>Reporter: Keith Wall
>Priority: Major
>
> QPID-8136 upgrade Jackson on master from 2.8.7 to 2.9.4 in response to 
> CVE-2017-7525.  However it is now know that the blacklist include in 2.9.4 
> was incomplete.This is the subject of CVE-2018-7489.
> This problem affects only the master branch.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (QPID-8159) [Broker-J] Upgrade Jackson from 2.9.4 to 2.9.5 (CVE-2018-7489)

[Keith Wall (JIRA)]

Keith Wall created QPID-8159:


 Summary: [Broker-J] Upgrade Jackson from 2.9.4 to 2.9.5 
(CVE-2018-7489)
 Key: QPID-8159
 URL: https://issues.apache.org/jira/browse/QPID-8159
 Project: Qpid
  Issue Type: Improvement
  Components: Broker-J
Affects Versions: qpid-java-broker-7.1.0
Reporter: Keith Wall


QPID-8136 upgrade Jackson on master from 2.8.7 to 2.9.4 in response to 
CVE-2017-7525.  However it is now know that the blacklist include in 2.9.4 was 
incomplete.This is the subject of CVE-2018-7489.




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-8158) [Broker-J] [System Tests] Refactor BDB HA system tests

[Keith Wall (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-8158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433681#comment-16433681
 ] 

Keith Wall commented on QPID-8158:
--

As discussed, the approach being taken by the above commit does not seem clean. 
 I think it is a mistake to conflate the management of a group with the 
management of a single broker.   Let's look again at this. 

> [Broker-J] [System Tests] Refactor BDB HA system tests
> --
>
> Key: QPID-8158
> URL: https://issues.apache.org/jira/browse/QPID-8158
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J, Java Tests
>Reporter: Alex Rudyy
>Priority: Major
>
> Currently BDB HA system tests are extended from {{QpidBrokerTestCase}}. They 
> need to be refactored to run with {{QpidTestRunner}}  similar to other system 
> tests.
> The BDB HA nodes  should be started as spawn brokers using special  
> {{BrokerAdmin}} allowing to start broker in a separate JVM.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (PROTON-636) remove confusing default for session capacity and allow disabling it

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell resolved PROTON-636.
---
Resolution: Fixed

> remove confusing default for session capacity and allow disabling it
> 
>
> Key: PROTON-636
> URL: https://issues.apache.org/jira/browse/PROTON-636
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Reporter: Rafael H. Schloming
>Assignee: Alan Conway
>Priority: Minor
>  Labels: framing
> Fix For: proton-c-0.23.0
>
>
> Original title: setting a 1MB frame size results in an undesirably small 
> session window)
> Description, from PROTON-1739:
> The session has a default 'incoming capacity' of 1MB, which actually has no 
> effect by default and leads to unexpected behaviour while changing other 
> configuration. It should be removed.
> The value is used when the engine decides what incoming session window to set 
> on Flow frames, but only if a specific frame size is configured for the 
> transport, which it isn't by default. If a specific frame size is set, then 
> any session capacity really needs to be set based on it in order to be 
> appropriate, the default being fixed as it is leads to unexpectedly low 
> window sizes in many cases which will impact performance in unexpected ways. 
> Its confusing that setting frame size results in completely different 
> behaviour than before for another thing (window size) which perhaps hasn't 
> been configured at all, and the existing behaviour is also such that you cant 
> turn it off.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (PROTON-636) remove confusing default for session capacity and allow disabling it

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-636:
--
Description: 
Original title: setting a 1MB frame size results in an undesirably small 
session window)

Description, from PROTON-1739:

The session has a default 'incoming capacity' of 1MB, which actually has no 
effect by default and leads to unexpected behaviour while changing other 
configuration. It should be removed.

The value is used when the engine decides what incoming session window to set 
on Flow frames, but only if a specific frame size is configured for the 
transport, which it isn't by default. If a specific frame size is set, then any 
session capacity really needs to be set based on it in order to be appropriate, 
the default being fixed as it is leads to unexpectedly low window sizes in many 
cases which will impact performance in unexpected ways. Its confusing that 
setting frame size results in completely different behaviour than before for 
another thing (window size) which perhaps hasn't been configured at all, and 
the existing behaviour is also such that you cant turn it off.
Summary: remove confusing default for session capacity and allow 
disabling it  (was: setting a 1MB frame size results in an undesirably small 
session window)

> remove confusing default for session capacity and allow disabling it
> 
>
> Key: PROTON-636
> URL: https://issues.apache.org/jira/browse/PROTON-636
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: Rafael H. Schloming
>Assignee: Alan Conway
>Priority: Major
>  Labels: framing
> Fix For: proton-c-0.23.0
>
>
> Original title: setting a 1MB frame size results in an undesirably small 
> session window)
> Description, from PROTON-1739:
> The session has a default 'incoming capacity' of 1MB, which actually has no 
> effect by default and leads to unexpected behaviour while changing other 
> configuration. It should be removed.
> The value is used when the engine decides what incoming session window to set 
> on Flow frames, but only if a specific frame size is configured for the 
> transport, which it isn't by default. If a specific frame size is set, then 
> any session capacity really needs to be set based on it in order to be 
> appropriate, the default being fixed as it is leads to unexpectedly low 
> window sizes in many cases which will impact performance in unexpected ways. 
> Its confusing that setting frame size results in completely different 
> behaviour than before for another thing (window size) which perhaps hasn't 
> been configured at all, and the existing behaviour is also such that you cant 
> turn it off.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (PROTON-636) remove confusing default for session capacity and allow disabling it

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-636:
--
Priority: Minor  (was: Major)

> remove confusing default for session capacity and allow disabling it
> 
>
> Key: PROTON-636
> URL: https://issues.apache.org/jira/browse/PROTON-636
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Reporter: Rafael H. Schloming
>Assignee: Alan Conway
>Priority: Minor
>  Labels: framing
> Fix For: proton-c-0.23.0
>
>
> Original title: setting a 1MB frame size results in an undesirably small 
> session window)
> Description, from PROTON-1739:
> The session has a default 'incoming capacity' of 1MB, which actually has no 
> effect by default and leads to unexpected behaviour while changing other 
> configuration. It should be removed.
> The value is used when the engine decides what incoming session window to set 
> on Flow frames, but only if a specific frame size is configured for the 
> transport, which it isn't by default. If a specific frame size is set, then 
> any session capacity really needs to be set based on it in order to be 
> appropriate, the default being fixed as it is leads to unexpectedly low 
> window sizes in many cases which will impact performance in unexpected ways. 
> Its confusing that setting frame size results in completely different 
> behaviour than before for another thing (window size) which perhaps hasn't 
> been configured at all, and the existing behaviour is also such that you cant 
> turn it off.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (PROTON-636) remove confusing default for session capacity and allow disabling it

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-636:
--
Issue Type: Improvement  (was: Bug)

> remove confusing default for session capacity and allow disabling it
> 
>
> Key: PROTON-636
> URL: https://issues.apache.org/jira/browse/PROTON-636
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Reporter: Rafael H. Schloming
>Assignee: Alan Conway
>Priority: Major
>  Labels: framing
> Fix For: proton-c-0.23.0
>
>
> Original title: setting a 1MB frame size results in an undesirably small 
> session window)
> Description, from PROTON-1739:
> The session has a default 'incoming capacity' of 1MB, which actually has no 
> effect by default and leads to unexpected behaviour while changing other 
> configuration. It should be removed.
> The value is used when the engine decides what incoming session window to set 
> on Flow frames, but only if a specific frame size is configured for the 
> transport, which it isn't by default. If a specific frame size is set, then 
> any session capacity really needs to be set based on it in order to be 
> appropriate, the default being fixed as it is leads to unexpectedly low 
> window sizes in many cases which will impact performance in unexpected ways. 
> Its confusing that setting frame size results in completely different 
> behaviour than before for another thing (window size) which perhaps hasn't 
> been configured at all, and the existing behaviour is also such that you cant 
> turn it off.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Reopened] (PROTON-636) setting a 1MB frame size results in an undesirably small session window

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell reopened PROTON-636:
---

> setting a 1MB frame size results in an undesirably small session window
> ---
>
> Key: PROTON-636
> URL: https://issues.apache.org/jira/browse/PROTON-636
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: Rafael H. Schloming
>Assignee: Alan Conway
>Priority: Major
>  Labels: framing
> Fix For: proton-c-0.23.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org