[jira] [Commented] (QPIDIT-61) Condense common code from the Python tests into a test module.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPIDIT-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16366342#comment-16366342
 ] 

ASF subversion and git services commented on QPIDIT-61:
---

Commit e20ae3c8b29a0af816d55238beff688c2700d62d in qpid-interop-test's branch 
refs/heads/master from [~kpvdr]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-interop-test.git;h=e20ae3c ]

QPIDIT-61: Fixed error in jms_hdrs_props_test Python Sender shim, which 
contained an invalid import which was not changed to match the newly refactored 
modules.


> Condense common code from the Python tests into a test module.
> --
>
> Key: QPIDIT-61
> URL: https://issues.apache.org/jira/browse/QPIDIT-61
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: Task
>  Components: AMQP Large Content Test, AMQP Types Test, JMS Headers 
> and Properties Test, JMS Message Test
>Affects Versions: 0.1.0
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Minor
> Fix For: 0.2.0
>
>
> Each test was written independently of the others. While this is a quick way 
> to start, it has not lead to a lot of duplicated code and common patterns. It 
> would help maintenance and readability of the code if the common bits were 
> placed into a test library.



--
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-927) detach not echoed back on multi-hop link route

[Gordon Sim (JIRA)]

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

Gordon Sim commented on DISPATCH-927:
-

So far I have only been able to reproduce with the activemq artemis broker. 
However I suspect this is just a timing issue. The broker does appear to be 
behaving correctly.

To reproduce,
 (1) start two routers with simple-topic-a.conf and simple-topic-b.conf
  e.g. 
 qdrouterd --conf  simple-topic-a.conf
 qdrouterd --conf  simple-topic-b.conf  
 (2) start artemis broker on port 5673 with examples topic configure (e.g. see 
broker,xml attached)
 (3) run two instances of the modified simple_recv example as attached (the 
change is that the client waits for the detach to be echoed back before exiting)
e.g.
python simple_recv_modified.py -m 10 &
python simple_recv_modified.py -m 10 &
 (4) run simple_send.py example from proton python
e.g.
python simple_send.py -m 10

Sometimes only one of the receivers will exit. If you enable PN_TRACE_FRM you 
can see that the detach is never received back from the router.

> detach not echoed back on multi-hop link route
> --
>
> Key: DISPATCH-927
> URL: https://issues.apache.org/jira/browse/DISPATCH-927
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Gordon Sim
>Priority: Major
> Attachments: broker.xml, simple-topic-a.conf, simple-topic-b.conf, 
> simple_recv_modified.py
>
>
> In a two router network, router-a and router-b, a link route is defined in 
> both directions on both routers. There is also an associated connector to a 
> broker on router-b. The address is configured to be a topic on the broker.
> If two receivers attach on this address to router-a, and then detach at the 
> same time having received the defined number of messages, frequently (but not 
> always), one of the receivers will not get a detach echoed back to it.
> On inspection of protocol traces, it appears that router-b, though it gets 
> the detach echoed back from the broker, does not forward this back to the 
> client (via router-a).



--
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-927) detach not echoed back on multi-hop link route

[Gordon Sim (JIRA)]

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

Gordon Sim updated DISPATCH-927:

Attachment: broker.xml

> detach not echoed back on multi-hop link route
> --
>
> Key: DISPATCH-927
> URL: https://issues.apache.org/jira/browse/DISPATCH-927
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Gordon Sim
>Priority: Major
> Attachments: broker.xml, simple-topic-a.conf, simple-topic-b.conf, 
> simple_recv_modified.py
>
>
> In a two router network, router-a and router-b, a link route is defined in 
> both directions on both routers. There is also an associated connector to a 
> broker on router-b. The address is configured to be a topic on the broker.
> If two receivers attach on this address to router-a, and then detach at the 
> same time having received the defined number of messages, frequently (but not 
> always), one of the receivers will not get a detach echoed back to it.
> On inspection of protocol traces, it appears that router-b, though it gets 
> the detach echoed back from the broker, does not forward this back to the 
> client (via router-a).



--
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-927) detach not echoed back on multi-hop link route

[Gordon Sim (JIRA)]

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

Gordon Sim updated DISPATCH-927:

Attachment: simple-topic-a.conf

> detach not echoed back on multi-hop link route
> --
>
> Key: DISPATCH-927
> URL: https://issues.apache.org/jira/browse/DISPATCH-927
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Gordon Sim
>Priority: Major
> Attachments: simple-topic-a.conf, simple-topic-b.conf, 
> simple_recv_modified.py
>
>
> In a two router network, router-a and router-b, a link route is defined in 
> both directions on both routers. There is also an associated connector to a 
> broker on router-b. The address is configured to be a topic on the broker.
> If two receivers attach on this address to router-a, and then detach at the 
> same time having received the defined number of messages, frequently (but not 
> always), one of the receivers will not get a detach echoed back to it.
> On inspection of protocol traces, it appears that router-b, though it gets 
> the detach echoed back from the broker, does not forward this back to the 
> client (via router-a).



--
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-927) detach not echoed back on multi-hop link route

[Gordon Sim (JIRA)]

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

Gordon Sim updated DISPATCH-927:

Attachment: simple-topic-b.conf

> detach not echoed back on multi-hop link route
> --
>
> Key: DISPATCH-927
> URL: https://issues.apache.org/jira/browse/DISPATCH-927
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Gordon Sim
>Priority: Major
> Attachments: simple-topic-a.conf, simple-topic-b.conf, 
> simple_recv_modified.py
>
>
> In a two router network, router-a and router-b, a link route is defined in 
> both directions on both routers. There is also an associated connector to a 
> broker on router-b. The address is configured to be a topic on the broker.
> If two receivers attach on this address to router-a, and then detach at the 
> same time having received the defined number of messages, frequently (but not 
> always), one of the receivers will not get a detach echoed back to it.
> On inspection of protocol traces, it appears that router-b, though it gets 
> the detach echoed back from the broker, does not forward this back to the 
> client (via router-a).



--
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-927) detach not echoed back on multi-hop link route

[Gordon Sim (JIRA)]

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

Gordon Sim updated DISPATCH-927:

Attachment: simple_recv_modified.py

> detach not echoed back on multi-hop link route
> --
>
> Key: DISPATCH-927
> URL: https://issues.apache.org/jira/browse/DISPATCH-927
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Gordon Sim
>Priority: Major
> Attachments: simple_recv_modified.py
>
>
> In a two router network, router-a and router-b, a link route is defined in 
> both directions on both routers. There is also an associated connector to a 
> broker on router-b. The address is configured to be a topic on the broker.
> If two receivers attach on this address to router-a, and then detach at the 
> same time having received the defined number of messages, frequently (but not 
> always), one of the receivers will not get a detach echoed back to it.
> On inspection of protocol traces, it appears that router-b, though it gets 
> the detach echoed back from the broker, does not forward this back to the 
> client (via router-a).



--
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-927) detach not echoed back on multi-hop link route

[Gordon Sim (JIRA)]

Gordon Sim created DISPATCH-927:
---

 Summary: detach not echoed back on multi-hop link route
 Key: DISPATCH-927
 URL: https://issues.apache.org/jira/browse/DISPATCH-927
 Project: Qpid Dispatch
  Issue Type: Bug
Reporter: Gordon Sim


In a two router network, router-a and router-b, a link route is defined in both 
directions on both routers. There is also an associated connector to a broker 
on router-b. The address is configured to be a topic on the broker.

If two receivers attach on this address to router-a, and then detach at the 
same time having received the defined number of messages, frequently (but not 
always), one of the receivers will not get a detach echoed back to it.

On inspection of protocol traces, it appears that router-b, though it gets the 
detach echoed back from the broker, does not forward this back to the client 
(via router-a).



--
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-8083) [REST] Refactor REST system test suite

[ASF subversion and git services (JIRA)]

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

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

Commit 91e14a64da924caa654b8c69a0f27e4c2e694342 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=91e14a6 ]

 QPID-8083 [System Tests] [REST/HTTP] Fix test failure that would occur if 
working path too long


> [REST] Refactor REST system test suite
> --
>
> Key: QPID-8083
> URL: https://issues.apache.org/jira/browse/QPID-8083
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
>
> REST is an orthogonal concern within the Broker.  It should be possible for 
> developers of the Broker to easily exclude REST tests from test runs whilst 
> developing other parts of the Broker.  To allow for this, the REST test suite 
> should be separate.
> Also many of the current tests are very repetitious in nature.  Currently 
> each model object is subjected to its own REST test merely testing that model 
> attributes are available over REST, pointlessly retesting the same piece of 
> common mechanism code over and over again.  Such tests should be eliminated.
> Tests that remain should focus on REST concerns such as:
>  * CRUD model access
>  * Model operations
>  * SASL and Preemptive Authentication
>  * Compression/Decompression
>  
>  



--
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-1762) [ruby] gem does not contain examples or tests

[Alan Conway (JIRA)]

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

Alan Conway resolved PROTON-1762.
-
Resolution: Fixed

> [ruby] gem does not contain examples or tests
> -
>
> Key: PROTON-1762
> URL: https://issues.apache.org/jira/browse/PROTON-1762
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: ruby-binding
>Affects Versions: proton-c-0.20.0
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
> Fix For: proton-c-0.21.0
>
>
> The ruby gem created by cmake does not include example files or tests. 
> The example sources should be included as part of the documentation and 
> linked from the README.
>  
> The tests should be included as per: 
> http://guides.rubygems.org/make-your-own-gem/#writing-tests



--
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] (QPIDIT-105) Getting started with AMQP.Net Lite in Fedora

[Kim van der Riet (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPIDIT-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16366193#comment-16366193
 ] 

Kim van der Riet commented on QPIDIT-105:
-

{{Mono JIT compiler version 4.6.2 (Stable 4.6.2.16/ac9e222 Mon Jul 31 05:33:32 
UTC 2017)}}

If this is a warning, we need to prevent it from printing to std::out or 
std::err, as any unexpected output on these will be interpreted as an error 
condition by the test program. Currently, both of these are piped to the 
calling Python test program in the {{subprocess.Popen()}} call.

> Getting started with AMQP.Net Lite in Fedora
> 
>
> Key: QPIDIT-105
> URL: https://issues.apache.org/jira/browse/QPIDIT-105
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: New Feature
>  Components: .Net Lite Shim
>Affects Versions: 0.1.0
> Environment: Fedora 25
> mono 4.4.2
>Reporter: Chuck Rolke
>Assignee: Kim van der Riet
>Priority: Major
>
> h4. Introduction
> With package mono version 4.4.2 installed on Fedora the system is capable of 
> compiling and running the AMQP.Net Lite shim tests. The remaining part of the 
> puzzle is acquiring a pre-compiled AMQP.Net Lite executable library. Here's 
> one solution.
> This note is not a feature request so much as it is a blog about one way to 
> do it.
> h4. Fetch AMQP.Net Lite 2.0.0 from NuGet
> Saved as file *get-lite.sh* in the top level directory it may be dot sourced 
> to pick up the definition of AMQPNETLITE_LIB_DIR.
> {noformat}
> #!/bin/bash
> #
> # file: get-lite.sh
> #
> litedir=amqpnetlite-lib-dir
> if [[ ! -d $litedir ]]; then
> mkdir $litedir
> cd$litedir
> wget https://www.nuget.org/api/v2/package/AMQPNetLite/2.0.0
> mv2.0.0 amqpnetlite.2.0.0.nupkg
> unzip   amqpnetlite.2.0.0.nupkg
> cd ..
> fi
> export AMQPNETLITE_LIB_DIR=`pwd`/$litedir/lib/net45
> {noformat}
> .h4 Build qpid-interop-test including AMQP.Net Lite
> Include the Lite library definition in the CMake command line
> {noformat}
> cmake -DAMQPNETLITE_LIB_DIR=${AMQPNETLITE_LIB_DIR} ...
> {noformat}
> Expect confirmation that the Lite library was picked up by CMake
> {noformat}
> -- BUILD_AMQPNETLITE = ON
> {noformat}
> h4. Run test with the AMQP.Net Lite shims
> Define the library location and specify the shims.
> {noformat}
> export 
> AMQPNETLITE_LIB_DIR=${QPID_INTEROP_TEST_HOME}/amqpnetlite-lib-dir/lib/net45
> ./src/python/qpid_interop_test/amqp_types_test.py \
> --include-shim ProtonCpp \
> --include-shim ProtonPython \
> --include-shim AmqpNetLite 
> {noformat}
> h4. Further integration
> This should get you started with the AMQP.Net Lite library. I've tried a few 
> things to auto-detect the library and use it if present. None of those 
> attempts is yet worthy.



--
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-1762) [ruby] gem does not contain examples or tests

[ASF subversion and git services (JIRA)]

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

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

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

PROTON-1762: [ruby] ruby-gem tests, examples and self-test

- ctests to install and smoke test the gem with the example self-tests
- package ruby/tests/ and examples/ruby directories in ruby gem


> [ruby] gem does not contain examples or tests
> -
>
> Key: PROTON-1762
> URL: https://issues.apache.org/jira/browse/PROTON-1762
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: ruby-binding
>Affects Versions: proton-c-0.20.0
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
> Fix For: proton-c-0.21.0
>
>
> The ruby gem created by cmake does not include example files or tests. 
> The example sources should be included as part of the documentation and 
> linked from the README.
>  
> The tests should be included as per: 
> http://guides.rubygems.org/make-your-own-gem/#writing-tests



--
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] (QPIDIT-105) Getting started with AMQP.Net Lite in Fedora

[Chuck Rolke (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPIDIT-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16366048#comment-16366048
 ] 

Chuck Rolke commented on QPIDIT-105:


The wisdom of the web suggests that this is a warning which may safely be 
ignored. See 
[https://stackoverflow.com/questions/45483133/got-a-bad-hardware-address-length-for-an-af-packet-16-8]

 

Can you get the version of mono that's running on CentOS7?   mono --version

 

> Getting started with AMQP.Net Lite in Fedora
> 
>
> Key: QPIDIT-105
> URL: https://issues.apache.org/jira/browse/QPIDIT-105
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: New Feature
>  Components: .Net Lite Shim
>Affects Versions: 0.1.0
> Environment: Fedora 25
> mono 4.4.2
>Reporter: Chuck Rolke
>Assignee: Kim van der Riet
>Priority: Major
>
> h4. Introduction
> With package mono version 4.4.2 installed on Fedora the system is capable of 
> compiling and running the AMQP.Net Lite shim tests. The remaining part of the 
> puzzle is acquiring a pre-compiled AMQP.Net Lite executable library. Here's 
> one solution.
> This note is not a feature request so much as it is a blog about one way to 
> do it.
> h4. Fetch AMQP.Net Lite 2.0.0 from NuGet
> Saved as file *get-lite.sh* in the top level directory it may be dot sourced 
> to pick up the definition of AMQPNETLITE_LIB_DIR.
> {noformat}
> #!/bin/bash
> #
> # file: get-lite.sh
> #
> litedir=amqpnetlite-lib-dir
> if [[ ! -d $litedir ]]; then
> mkdir $litedir
> cd$litedir
> wget https://www.nuget.org/api/v2/package/AMQPNetLite/2.0.0
> mv2.0.0 amqpnetlite.2.0.0.nupkg
> unzip   amqpnetlite.2.0.0.nupkg
> cd ..
> fi
> export AMQPNETLITE_LIB_DIR=`pwd`/$litedir/lib/net45
> {noformat}
> .h4 Build qpid-interop-test including AMQP.Net Lite
> Include the Lite library definition in the CMake command line
> {noformat}
> cmake -DAMQPNETLITE_LIB_DIR=${AMQPNETLITE_LIB_DIR} ...
> {noformat}
> Expect confirmation that the Lite library was picked up by CMake
> {noformat}
> -- BUILD_AMQPNETLITE = ON
> {noformat}
> h4. Run test with the AMQP.Net Lite shims
> Define the library location and specify the shims.
> {noformat}
> export 
> AMQPNETLITE_LIB_DIR=${QPID_INTEROP_TEST_HOME}/amqpnetlite-lib-dir/lib/net45
> ./src/python/qpid_interop_test/amqp_types_test.py \
> --include-shim ProtonCpp \
> --include-shim ProtonPython \
> --include-shim AmqpNetLite 
> {noformat}
> h4. Further integration
> This should get you started with the AMQP.Net Lite library. I've tried a few 
> things to auto-detect the library and use it if present. None of those 
> attempts is yet worthy.



--
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-8100) [Broker-J] [AMQP 0-10] SESSION_BUSY sent on wrong channel leading to hung Messaging API based application

[ASF subversion and git services (JIRA)]

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

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

Commit 1911d163b2fe21e6630ccf16730d30917ca888c9 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=1911d16 ]

QPID-8100: [Broker-J] [AMQP 0-10] Ensure that in error cases, session.detach is 
sent on the same channel as arrived the incoming frame.


> [Broker-J] [AMQP 0-10] SESSION_BUSY sent on wrong channel leading to hung 
> Messaging API based application
> -
>
> Key: QPID-8100
> URL: https://issues.apache.org/jira/browse/QPID-8100
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: 0.32, qpid-java-broker-7.0.0, qpid-java-broker-7.0.1
> Environment: * Qpid Broker-J 0.32 derivative
> * Qpid Cpp Client using messaging API.
>Reporter: Keith Wall
>Priority: Major
>
> If, during session attachment, the Broker detects that the 0-10 session is 
> already in use by the same principal, the Broker is required to detach the 
> session by sending a {{session.detach}} on the same channel.  Currently owing 
> to a defect, the Broker sends this detach on channel 0, regardless of the 
> channel used by the peer.
> This defect was a contributory factor in a larger problem.  It prevented an 
> application from recovering automatically.In that case, a Qpid CPP 
> Messaging API, recovering from a missing heartbeat, entered a hung state 
> whilst attaching the existing session.  The client library discarded the 
> {{session.detach}} on the unexpected channel, so it continued to await the 
> {{session.attached}}, which never came.  
> {noformat}
> /// original session attach
> 2018-02-15 13:17:50 [Network] trace SENT 
> [[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; 
> {SessionAttachBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }]
> 2018-02-15 13:17:50 [Network] trace RECV 
> [[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; 
> {SessionAttachedBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }]
> 2018-02-15 13:17:50 [Network] trace SENT 
> [[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; 
> {SessionRequestTimeoutBody: timeout=0; }]
> /// snip - later heartbeat timeout
> 2018-02-15 13:18:20 [Client] debug Traffic timeout
> /// snip - reconnecting again
> 2018-02-15 13:18:20 [System] info Connecting: 10.241.132.41:5672
> /// snip -reuse the same session id
> 2018-02-15 13:18:28 [Client] debug Known-brokers for connection:
> 2018-02-15 13:18:28 [Network] trace SENT 
> [[10.211.55.3:60056-10.241.132.41:5672]]: Frame[BEbe; channel=1; 
> {SessionAttachBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }]
> 2018-02-15 13:18:28 [Network] trace RECV 
> [[10.211.55.3:60056-10.241.132.41:5672]]: Frame[BEbe; channel=0; 
> {SessionDetachedBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; code=1; }]
> 2018-02-15 13:18:28 [Client] info Connection 
> [10.211.55.3:60056-10.241.132.41:5672] dropping frame received on invalid 
> channel: Frame[BEbe; channel=0; {SessionDetachedBody: 
> name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; code=1; }]
> {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-882) router buffers messages for slow presettled receiver

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-882:
-

GitHub user kgiusti opened a pull request:

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

DISPATCH-882: delay settlement until after the i/o thread puts the de…

…livery on the proper list

(cherry picked from commit 0118660ca013d3f524cad7bb1978d92c17bbe6eb)

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

$ git pull https://github.com/kgiusti/dispatch DISPATCH-882-1.0.1

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

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


commit 3b4668f684c826c45950ae15c4fed955c36430e7
Author: Kenneth Giusti 
Date:   2017-11-22T14:55:41Z

DISPATCH-882: delay settlement until after the i/o thread puts the delivery 
on the proper list

(cherry picked from commit 0118660ca013d3f524cad7bb1978d92c17bbe6eb)




> router buffers messages for slow presettled receiver
> 
>
> Key: DISPATCH-882
> URL: https://issues.apache.org/jira/browse/DISPATCH-882
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Gordon Sim
>Assignee: Ken Giusti
>Priority: Major
> Fix For: 1.0.1
>
>
> For an anycast address with incoming transfers unsettled and outgoing 
> transfers pre-settled, if the receiver can't keep up with the sender, the 
> router appears to buffer a growing number of deliveries.
> The link stats for the receiver, which is receiving pre-settled, are shown as 
> accepted and unsettled (with a small number of undelivered) with presettled 
> count remaining at zero and the unsettled count growing. qpid-stat -m shows 
> growth in buffer and message content related types.
> It looks like there is no limit to the amount of messages the router will try 
> to buffer in this case(?) though I did not push it all the way to failure.



--
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 #259: DISPATCH-882: delay settlement until after ...

[kgiusti]

GitHub user kgiusti opened a pull request:

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

DISPATCH-882: delay settlement until after the i/o thread puts the de…

…livery on the proper list

(cherry picked from commit 0118660ca013d3f524cad7bb1978d92c17bbe6eb)

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

$ git pull https://github.com/kgiusti/dispatch DISPATCH-882-1.0.1

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

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


commit 3b4668f684c826c45950ae15c4fed955c36430e7
Author: Kenneth Giusti 
Date:   2017-11-22T14:55:41Z

DISPATCH-882: delay settlement until after the i/o thread puts the delivery 
on the proper list

(cherry picked from commit 0118660ca013d3f524cad7bb1978d92c17bbe6eb)




---

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

[jira] [Resolved] (QPIDJMS-362) update Netty to 4.1.21

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell resolved QPIDJMS-362.

Resolution: Fixed

> update Netty to 4.1.21
> --
>
> Key: QPIDJMS-362
> URL: https://issues.apache.org/jira/browse/QPIDJMS-362
> Project: Qpid JMS
>  Issue Type: Task
>  Components: qpid-jms-client
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Major
> Fix For: 0.30.0
>
>
> update to the latest Netty



--
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-362) update Netty to 4.1.21

[ASF subversion and git services (JIRA)]

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

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

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

QPIDJMS-362: update to Netty 4.1.21


> update Netty to 4.1.21
> --
>
> Key: QPIDJMS-362
> URL: https://issues.apache.org/jira/browse/QPIDJMS-362
> Project: Qpid JMS
>  Issue Type: Task
>  Components: qpid-jms-client
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Major
> Fix For: 0.30.0
>
>
> update to the latest Netty



--
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-889) linkRoute patterns beginning with #/string match substrings after the /

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-889:
-

GitHub user kgiusti opened a pull request:

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

DISPATCH-889: fix the parse tree token string comparison

Backported from master

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

$ git pull https://github.com/kgiusti/dispatch DISPATCH-889-1.0.1

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

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


commit 9dee49e959a4966cbb6536849bca9eab20644c57
Author: Kenneth Giusti 
Date:   2017-12-04T17:04:58Z

DISPATCH-889: fix the parse tree token string comparison

(cherry picked from commit e531e1cff723702952836d369d5d731679f121b9)




> linkRoute patterns beginning with #/string match substrings after the / 
> 
>
> Key: DISPATCH-889
> URL: https://issues.apache.org/jira/browse/DISPATCH-889
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 1.0.0
>Reporter: Ernest Allen
>Assignee: Ken Giusti
>Priority: Major
> Fix For: 1.0.1
>
>
> linkRoutes with a pattern of #/policy match substrings of the word policy
> - 1. setup a router
> router {
> mode: standalone
> id: A
> }
> listener {
> host: 0.0.0.0
> port: 2
> role: normal
> saslMechanisms: ANONYMOUS
> }
> connector {
> name: policy-connector
> role: route-container
> host: 0.0.0.0
> port:  
> saslMechanisms: ANONYMOUS
> }
> linkRoute {
>pattern: #/policy
>dir: in
>   connection: policy-connector
> }
> - 2. start an acceptor on that host:port
> qpid-proton/examples/python/server_direct.py
> - 3. verify linkRoute is established
> qdstat -b 0.0.0.0:2 --linkroutes
> Link Routes
>   address   dir  distrib   status
>   =
>   #/policy  in   linkBalanced  active
> - 4. send some messages through the router
> addresses that should match
> qpid-proton/examples/python/simple_send -a 0.0.0.0:2/bob.com/policy -m 1
>   -> message received at server_direct.py
> qpid-proton/examples/python/simple_send -a 0.0.0.0:2/ken-is-great/policy 
> -m 1
>   -> message received at server_direct.py
> qpid-proton/examples/python/simple_send -a 0.0.0.0:2/policy -m 1
>   -> message received at server_direct.py
> addresses that should not match
> qpid-proton/examples/python/simple_send -a 0.0.0.0:2/bob.com/a -m 1
>   -> message NOT sent - this is the correct behavior 
> qpid-proton/examples/python/simple_send -a 0.0.0.0:2/bob.com/p -m 1
>   -> message received at server_direct.py - this is a bug
> qpid-proton/examples/python/simple_send -a 0.0.0.0:2/poli -m 1
>   -> message received at server_direct.py - this is a bug



--
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 #258: DISPATCH-889: fix the parse tree token stri...

[kgiusti]

GitHub user kgiusti opened a pull request:

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

DISPATCH-889: fix the parse tree token string comparison

Backported from master

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

$ git pull https://github.com/kgiusti/dispatch DISPATCH-889-1.0.1

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

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


commit 9dee49e959a4966cbb6536849bca9eab20644c57
Author: Kenneth Giusti 
Date:   2017-12-04T17:04:58Z

DISPATCH-889: fix the parse tree token string comparison

(cherry picked from commit e531e1cff723702952836d369d5d731679f121b9)




---

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

[jira] [Created] (QPIDJMS-362) update Netty to 4.1.21

[Robbie Gemmell (JIRA)]

Robbie Gemmell created QPIDJMS-362:
--

 Summary: update Netty to 4.1.21
 Key: QPIDJMS-362
 URL: https://issues.apache.org/jira/browse/QPIDJMS-362
 Project: Qpid JMS
  Issue Type: Task
  Components: qpid-jms-client
Reporter: Robbie Gemmell
Assignee: Robbie Gemmell
 Fix For: 0.30.0


update to the latest Netty



--
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 #257: DISPATCH-914: correctly free mutex from qd_...

[kgiusti]

GitHub user kgiusti opened a pull request:

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

DISPATCH-914: correctly free mutex from qd_connector_t

Backport for 1.0.1 release

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

$ git pull https://github.com/kgiusti/dispatch DISPATCH-914-1.0.1

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

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


commit 49cc681134801e90c682e2b5b05ef88c7d2822e8
Author: Kenneth Giusti 
Date:   2018-01-16T15:18:14Z

DISPATCH-914: correctly free mutex from qd_connector_t




---

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

[jira] [Commented] (DISPATCH-914) qd_connector_t leaks mutexes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-914:
-

GitHub user kgiusti opened a pull request:

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

DISPATCH-914: correctly free mutex from qd_connector_t

Backport for 1.0.1 release

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

$ git pull https://github.com/kgiusti/dispatch DISPATCH-914-1.0.1

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

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


commit 49cc681134801e90c682e2b5b05ef88c7d2822e8
Author: Kenneth Giusti 
Date:   2018-01-16T15:18:14Z

DISPATCH-914: correctly free mutex from qd_connector_t




> qd_connector_t leaks mutexes
> 
>
> Key: DISPATCH-914
> URL: https://issues.apache.org/jira/browse/DISPATCH-914
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.1.0
> Environment: Unit tests fail with the following traceback when run 
> under valgrind:
>  
> 39: ==5443== 64 bytes in 1 blocks are definitely lost in loss record 1,047 of 
> 3,514
> 39: ==5443==    at 0x4C30D47: memalign (vg_replace_malloc.c:857)
> 39: ==5443==    by 0x4C30E45: posix_memalign (vg_replace_malloc.c:1020)
> 39: ==5443==    by 0x4E70B58: sys_mutex (threading.c:40)
> 39: ==5443==    by 0x4E8BCAA: qd_server_connector (server.c:1363)
> 39: ==5443==    by 0x4E61A49: qd_dispatch_configure_connector 
> (connection_manager.c:711)
> 39: ==5443==    by 0x10FC8BDD: ffi_call_unix64 (unix64.S:76)
> 39: ==5443==    by 0x10FC854E: ffi_call (ffi64.c:525)
> 39: ==5443==    by 0x10DB53A4: _ctypes_callproc (in 
> /usr/lib64/python2.7/lib-dynload/_ctypes.so)
> 39: ==5443==    by 0x10DAF0BD: ??? (in 
> /usr/lib64/python2.7/lib-dynload/_ctypes.so)
> 39: ==5443==    by 0x5BBE342: PyObject_Call (in 
> /usr/lib64/libpython2.7.so.1.0)
> 39: ==5443==    by 0x5C831B1: PyEval_EvalFrameEx (in 
> /usr/lib64/libpython2.7.so.1.0)
> 39: ==5443==    by 0x5C85B18: PyEval_EvalFrameEx (in 
> /usr/lib64/libpython2.7.so.1.0)
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Major
> Fix For: 1.0.1
>
>




--
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] (QPIDIT-105) Getting started with AMQP.Net Lite in Fedora

[Kim van der Riet (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPIDIT-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16365654#comment-16365654
 ] 

Kim van der Riet commented on QPIDIT-105:
-

When running on CentOS7, the following error occurs on the shims:
 
{noformat}
InteropTestError: {Send,Receive} shim 'AmqpNetLite'
Got a bad hardware address length for an AF_PACKET 20 8
{noformat}

> Getting started with AMQP.Net Lite in Fedora
> 
>
> Key: QPIDIT-105
> URL: https://issues.apache.org/jira/browse/QPIDIT-105
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: New Feature
>  Components: .Net Lite Shim
>Affects Versions: 0.1.0
> Environment: Fedora 25
> mono 4.4.2
>Reporter: Chuck Rolke
>Assignee: Kim van der Riet
>Priority: Major
>
> h4. Introduction
> With package mono version 4.4.2 installed on Fedora the system is capable of 
> compiling and running the AMQP.Net Lite shim tests. The remaining part of the 
> puzzle is acquiring a pre-compiled AMQP.Net Lite executable library. Here's 
> one solution.
> This note is not a feature request so much as it is a blog about one way to 
> do it.
> h4. Fetch AMQP.Net Lite 2.0.0 from NuGet
> Saved as file *get-lite.sh* in the top level directory it may be dot sourced 
> to pick up the definition of AMQPNETLITE_LIB_DIR.
> {noformat}
> #!/bin/bash
> #
> # file: get-lite.sh
> #
> litedir=amqpnetlite-lib-dir
> if [[ ! -d $litedir ]]; then
> mkdir $litedir
> cd$litedir
> wget https://www.nuget.org/api/v2/package/AMQPNetLite/2.0.0
> mv2.0.0 amqpnetlite.2.0.0.nupkg
> unzip   amqpnetlite.2.0.0.nupkg
> cd ..
> fi
> export AMQPNETLITE_LIB_DIR=`pwd`/$litedir/lib/net45
> {noformat}
> .h4 Build qpid-interop-test including AMQP.Net Lite
> Include the Lite library definition in the CMake command line
> {noformat}
> cmake -DAMQPNETLITE_LIB_DIR=${AMQPNETLITE_LIB_DIR} ...
> {noformat}
> Expect confirmation that the Lite library was picked up by CMake
> {noformat}
> -- BUILD_AMQPNETLITE = ON
> {noformat}
> h4. Run test with the AMQP.Net Lite shims
> Define the library location and specify the shims.
> {noformat}
> export 
> AMQPNETLITE_LIB_DIR=${QPID_INTEROP_TEST_HOME}/amqpnetlite-lib-dir/lib/net45
> ./src/python/qpid_interop_test/amqp_types_test.py \
> --include-shim ProtonCpp \
> --include-shim ProtonPython \
> --include-shim AmqpNetLite 
> {noformat}
> h4. Further integration
> This should get you started with the AMQP.Net Lite library. I've tried a few 
> things to auto-detect the library and use it if present. None of those 
> attempts is yet worthy.



--
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] [Comment Edited] (QPIDIT-105) Getting started with AMQP.Net Lite in Fedora

[Kim van der Riet (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPIDIT-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16365654#comment-16365654
 ] 

Kim van der Riet edited comment on QPIDIT-105 at 2/15/18 2:45 PM:
--

When running on CentOS7, the following error occurs on the shims:
 
{noformat}
InteropTestError: {Send,Receive} shim 'AmqpNetLite'
Got a bad hardware address length for an AF_PACKET 20 8
{noformat}
but works ok on Fedora 27.


was (Author: kpvdr):
When running on CentOS7, the following error occurs on the shims:
 
{noformat}
InteropTestError: {Send,Receive} shim 'AmqpNetLite'
Got a bad hardware address length for an AF_PACKET 20 8
{noformat}

> Getting started with AMQP.Net Lite in Fedora
> 
>
> Key: QPIDIT-105
> URL: https://issues.apache.org/jira/browse/QPIDIT-105
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: New Feature
>  Components: .Net Lite Shim
>Affects Versions: 0.1.0
> Environment: Fedora 25
> mono 4.4.2
>Reporter: Chuck Rolke
>Assignee: Kim van der Riet
>Priority: Major
>
> h4. Introduction
> With package mono version 4.4.2 installed on Fedora the system is capable of 
> compiling and running the AMQP.Net Lite shim tests. The remaining part of the 
> puzzle is acquiring a pre-compiled AMQP.Net Lite executable library. Here's 
> one solution.
> This note is not a feature request so much as it is a blog about one way to 
> do it.
> h4. Fetch AMQP.Net Lite 2.0.0 from NuGet
> Saved as file *get-lite.sh* in the top level directory it may be dot sourced 
> to pick up the definition of AMQPNETLITE_LIB_DIR.
> {noformat}
> #!/bin/bash
> #
> # file: get-lite.sh
> #
> litedir=amqpnetlite-lib-dir
> if [[ ! -d $litedir ]]; then
> mkdir $litedir
> cd$litedir
> wget https://www.nuget.org/api/v2/package/AMQPNetLite/2.0.0
> mv2.0.0 amqpnetlite.2.0.0.nupkg
> unzip   amqpnetlite.2.0.0.nupkg
> cd ..
> fi
> export AMQPNETLITE_LIB_DIR=`pwd`/$litedir/lib/net45
> {noformat}
> .h4 Build qpid-interop-test including AMQP.Net Lite
> Include the Lite library definition in the CMake command line
> {noformat}
> cmake -DAMQPNETLITE_LIB_DIR=${AMQPNETLITE_LIB_DIR} ...
> {noformat}
> Expect confirmation that the Lite library was picked up by CMake
> {noformat}
> -- BUILD_AMQPNETLITE = ON
> {noformat}
> h4. Run test with the AMQP.Net Lite shims
> Define the library location and specify the shims.
> {noformat}
> export 
> AMQPNETLITE_LIB_DIR=${QPID_INTEROP_TEST_HOME}/amqpnetlite-lib-dir/lib/net45
> ./src/python/qpid_interop_test/amqp_types_test.py \
> --include-shim ProtonCpp \
> --include-shim ProtonPython \
> --include-shim AmqpNetLite 
> {noformat}
> h4. Further integration
> This should get you started with the AMQP.Net Lite library. I've tried a few 
> things to auto-detect the library and use it if present. None of those 
> attempts is yet worthy.



--
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] (QPIDIT-105) Getting started with AMQP.Net Lite in Fedora

[Kim van der Riet (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPIDIT-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16365602#comment-16365602
 ] 

Kim van der Riet commented on QPIDIT-105:
-

Thanks, Chuck, for this info, it works great.

I'm not sure how frequently the .dll gets updated, but when we do so, these 
scripts will need to be manually changed to match. I imagine that any new 
version will need to be tested in any event before being used for testing.

> Getting started with AMQP.Net Lite in Fedora
> 
>
> Key: QPIDIT-105
> URL: https://issues.apache.org/jira/browse/QPIDIT-105
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: New Feature
>  Components: .Net Lite Shim
>Affects Versions: 0.1.0
> Environment: Fedora 25
> mono 4.4.2
>Reporter: Chuck Rolke
>Assignee: Kim van der Riet
>Priority: Major
>
> h4. Introduction
> With package mono version 4.4.2 installed on Fedora the system is capable of 
> compiling and running the AMQP.Net Lite shim tests. The remaining part of the 
> puzzle is acquiring a pre-compiled AMQP.Net Lite executable library. Here's 
> one solution.
> This note is not a feature request so much as it is a blog about one way to 
> do it.
> h4. Fetch AMQP.Net Lite 2.0.0 from NuGet
> Saved as file *get-lite.sh* in the top level directory it may be dot sourced 
> to pick up the definition of AMQPNETLITE_LIB_DIR.
> {noformat}
> #!/bin/bash
> #
> # file: get-lite.sh
> #
> litedir=amqpnetlite-lib-dir
> if [[ ! -d $litedir ]]; then
> mkdir $litedir
> cd$litedir
> wget https://www.nuget.org/api/v2/package/AMQPNetLite/2.0.0
> mv2.0.0 amqpnetlite.2.0.0.nupkg
> unzip   amqpnetlite.2.0.0.nupkg
> cd ..
> fi
> export AMQPNETLITE_LIB_DIR=`pwd`/$litedir/lib/net45
> {noformat}
> .h4 Build qpid-interop-test including AMQP.Net Lite
> Include the Lite library definition in the CMake command line
> {noformat}
> cmake -DAMQPNETLITE_LIB_DIR=${AMQPNETLITE_LIB_DIR} ...
> {noformat}
> Expect confirmation that the Lite library was picked up by CMake
> {noformat}
> -- BUILD_AMQPNETLITE = ON
> {noformat}
> h4. Run test with the AMQP.Net Lite shims
> Define the library location and specify the shims.
> {noformat}
> export 
> AMQPNETLITE_LIB_DIR=${QPID_INTEROP_TEST_HOME}/amqpnetlite-lib-dir/lib/net45
> ./src/python/qpid_interop_test/amqp_types_test.py \
> --include-shim ProtonCpp \
> --include-shim ProtonPython \
> --include-shim AmqpNetLite 
> {noformat}
> h4. Further integration
> This should get you started with the AMQP.Net Lite library. I've tried a few 
> things to auto-detect the library and use it if present. None of those 
> attempts is yet worthy.



--
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-8100) [Broker-J] [AMQP 0-10] SESSION_BUSY sent on wrong channel leading to hung Messaging API based application

[Keith Wall (JIRA)]

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

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

> [Broker-J] [AMQP 0-10] SESSION_BUSY sent on wrong channel leading to hung 
> Messaging API based application
> -
>
> Key: QPID-8100
> URL: https://issues.apache.org/jira/browse/QPID-8100
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: 0.32, qpid-java-broker-7.0.0, qpid-java-broker-7.0.1
> Environment: * Qpid Broker-J 0.32 derivative
> * Qpid Cpp Client using messaging API.
>Reporter: Keith Wall
>Priority: Major
>
> If, during session attachment, the Broker detects that the 0-10 session is 
> already in use by the same principal, the Broker is required to detach the 
> session by sending a {{session.detach}} on the same channel.  Currently owing 
> to a defect, the Broker sends this detach on channel 0, regardless of the 
> channel used by the peer.
> This defect was a contributory factor in a larger problem.  It prevented an 
> application from recovering automatically.In that case, a Qpid CPP 
> Messaging API, recovering from a missing heartbeat, entered a hung state 
> whilst attaching the existing session.  The client library discarded the 
> {{session.detach}} on the unexpected channel, so it continued to await the 
> {{session.attached}}, which never came.  
> {noformat}
> /// original session attach
> 2018-02-15 13:17:50 [Network] trace SENT 
> [[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; 
> {SessionAttachBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }]
> 2018-02-15 13:17:50 [Network] trace RECV 
> [[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; 
> {SessionAttachedBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }]
> 2018-02-15 13:17:50 [Network] trace SENT 
> [[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; 
> {SessionRequestTimeoutBody: timeout=0; }]
> /// snip - later heartbeat timeout
> 2018-02-15 13:18:20 [Client] debug Traffic timeout
> /// snip - reconnecting again
> 2018-02-15 13:18:20 [System] info Connecting: 10.241.132.41:5672
> /// snip -reuse the same session id
> 2018-02-15 13:18:28 [Client] debug Known-brokers for connection:
> 2018-02-15 13:18:28 [Network] trace SENT 
> [[10.211.55.3:60056-10.241.132.41:5672]]: Frame[BEbe; channel=1; 
> {SessionAttachBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }]
> 2018-02-15 13:18:28 [Network] trace RECV 
> [[10.211.55.3:60056-10.241.132.41:5672]]: Frame[BEbe; channel=0; 
> {SessionDetachedBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; code=1; }]
> 2018-02-15 13:18:28 [Client] info Connection 
> [10.211.55.3:60056-10.241.132.41:5672] dropping frame received on invalid 
> channel: Frame[BEbe; channel=0; {SessionDetachedBody: 
> name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; code=1; }]
> {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-8100) [Broker-J] [AMQP 0-10] SESSION_BUSY sent on wrong channel leading to hung Messaging API based application

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-8100:
-
Description: 
If, during session attachment, the Broker detects that the 0-10 session is 
already in use by the same principal, the Broker is required to detach the 
session by sending a {{session.detach}} on the same channel.  Currently owing 
to a defect, the Broker sends this detach on channel 0, regardless of the 
channel used by the peer.

This defect was a contributory factor in a larger problem.  It prevented an 
application from recovering automatically.In that case, a Qpid CPP 
Messaging API, recovering from a missing heartbeat, entered a hung state whilst 
attaching the existing session.  The client library discarded the 
{{session.detach}} on the unexpected channel, so it continued to await the 
{{session.attached}}, which never came.  

{noformat}
/// original session attach
2018-02-15 13:17:50 [Network] trace SENT 
[[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; 
{SessionAttachBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }]
2018-02-15 13:17:50 [Network] trace RECV 
[[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; 
{SessionAttachedBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }]
2018-02-15 13:17:50 [Network] trace SENT 
[[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; 
{SessionRequestTimeoutBody: timeout=0; }]
/// snip - later heartbeat timeout
2018-02-15 13:18:20 [Client] debug Traffic timeout
/// snip - reconnecting again
2018-02-15 13:18:20 [System] info Connecting: 10.241.132.41:5672
/// snip -reuse the same session id
2018-02-15 13:18:28 [Client] debug Known-brokers for connection:
2018-02-15 13:18:28 [Network] trace SENT 
[[10.211.55.3:60056-10.241.132.41:5672]]: Frame[BEbe; channel=1; 
{SessionAttachBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }]
2018-02-15 13:18:28 [Network] trace RECV 
[[10.211.55.3:60056-10.241.132.41:5672]]: Frame[BEbe; channel=0; 
{SessionDetachedBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; code=1; }]
2018-02-15 13:18:28 [Client] info Connection 
[10.211.55.3:60056-10.241.132.41:5672] dropping frame received on invalid 
channel: Frame[BEbe; channel=0; {SessionDetachedBody: 
name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; code=1; }]
{noformat}

  was:
If, during session attachment, the Broker detects that the 0-10 session is 
already in use by the same principal, the Broker is required to detach the 
session by sending a {{session.detach}} on the same channel.  Currently owing 
to a defect, the Broker sends this detach on channel 0, regardless of the 
channel used by the peer.

This defect was a contributory factor in a larger problem.  It prevented an 
application from recovering automatically.In that case, a Qpid CPP 
Messaging API, recovering from a missing heartbeat, entered a hung state whilst 
attaching the existing session.  The client library discarded the 
session.detach on the unexpected channel, so it continued to await the 
session.attach, which never came.  

{noformat}
/// original session attach
2018-02-15 13:17:50 [Network] trace SENT 
[[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; 
{SessionAttachBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }]
2018-02-15 13:17:50 [Network] trace RECV 
[[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; 
{SessionAttachedBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }]
2018-02-15 13:17:50 [Network] trace SENT 
[[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; 
{SessionRequestTimeoutBody: timeout=0; }]
/// snip - later heartbeat timeout
2018-02-15 13:18:20 [Client] debug Traffic timeout
/// snip - reconnecting again
2018-02-15 13:18:20 [System] info Connecting: 10.241.132.41:5672
/// snip -reuse the same session id
2018-02-15 13:18:28 [Client] debug Known-brokers for connection:
2018-02-15 13:18:28 [Network] trace SENT 
[[10.211.55.3:60056-10.241.132.41:5672]]: Frame[BEbe; channel=1; 
{SessionAttachBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }]
2018-02-15 13:18:28 [Network] trace RECV 
[[10.211.55.3:60056-10.241.132.41:5672]]: Frame[BEbe; channel=0; 
{SessionDetachedBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; code=1; }]
2018-02-15 13:18:28 [Client] info Connection 
[10.211.55.3:60056-10.241.132.41:5672] dropping frame received on invalid 
channel: Frame[BEbe; channel=0; {SessionDetachedBody: 
name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; code=1; }]
{noformat}


> [Broker-J] [AMQP 0-10] SESSION_BUSY sent on wrong channel leading to hung 
> Messaging API based application
> -
>
> Key: QPID-8100
> URL: https://issues.apache.org/jira/browse/QPID-8100
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: 0.32, 

[jira] [Updated] (QPID-8100) [Broker-J] [AMQP 0-10] SESSION_BUSY sent on wrong channel leading to hung Messaging API based application

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-8100:
-
Summary: [Broker-J] [AMQP 0-10] SESSION_BUSY sent on wrong channel leading 
to hung Messaging API based application  (was: [Broker-J] [AMQP 0-10] 
SESSION_BUSY sent on wrong channel)

> [Broker-J] [AMQP 0-10] SESSION_BUSY sent on wrong channel leading to hung 
> Messaging API based application
> -
>
> Key: QPID-8100
> URL: https://issues.apache.org/jira/browse/QPID-8100
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: 0.32, qpid-java-broker-7.0.0, qpid-java-broker-7.0.1
> Environment: * Qpid Broker-J 0.32 derivative
> * Qpid Cpp Client using messaging API.
>Reporter: Keith Wall
>Priority: Minor
>
> If, during session attachment, the Broker detects that the 0-10 session is 
> already in use by the same principal, the Broker is required to detach the 
> session by sending a {{session.detach}} on the same channel.  Currently owing 
> to a defect, the Broker sends this detach on channel 0, regardless of the 
> channel used by the peer.
> This defect was a contributory factor in a larger problem.  It prevented an 
> application from recovering automatically.In that case, a Qpid CPP 
> Messaging API, recovering from a missing heartbeat, entered a hung state 
> whilst attaching the existing session.  The client library discarded the 
> session.detach on the unexpected channel, so it continued to await the 
> session.attach, which never came.  
> {noformat}
> /// original session attach
> 2018-02-15 13:17:50 [Network] trace SENT 
> [[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; 
> {SessionAttachBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }]
> 2018-02-15 13:17:50 [Network] trace RECV 
> [[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; 
> {SessionAttachedBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }]
> 2018-02-15 13:17:50 [Network] trace SENT 
> [[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; 
> {SessionRequestTimeoutBody: timeout=0; }]
> /// snip - later heartbeat timeout
> 2018-02-15 13:18:20 [Client] debug Traffic timeout
> /// snip - reconnecting again
> 2018-02-15 13:18:20 [System] info Connecting: 10.241.132.41:5672
> /// snip -reuse the same session id
> 2018-02-15 13:18:28 [Client] debug Known-brokers for connection:
> 2018-02-15 13:18:28 [Network] trace SENT 
> [[10.211.55.3:60056-10.241.132.41:5672]]: Frame[BEbe; channel=1; 
> {SessionAttachBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }]
> 2018-02-15 13:18:28 [Network] trace RECV 
> [[10.211.55.3:60056-10.241.132.41:5672]]: Frame[BEbe; channel=0; 
> {SessionDetachedBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; code=1; }]
> 2018-02-15 13:18:28 [Client] info Connection 
> [10.211.55.3:60056-10.241.132.41:5672] dropping frame received on invalid 
> channel: Frame[BEbe; channel=0; {SessionDetachedBody: 
> name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; code=1; }]
> {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-8100) [Broker-J] [AMQP 0-10] SESSION_BUSY sent on wrong channel

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-8100:
-
Description: 
If, during session attachment, the Broker detects that the 0-10 session is 
already in use by the same principal, the Broker is required to detach the 
session by sending a {{session.detach}} on the same channel.  Currently owing 
to a defect, the Broker sends this detach on channel 0, regardless of the 
channel used by the peer.

This defect was a contributory factor in a larger problem.  It prevented an 
application from recovering automatically.In that case, a Qpid CPP 
Messaging API, recovering from a missing heartbeat, entered a hung state whilst 
attaching the existing session.  The client library discarded the 
session.detach on the unexpected channel, so it continued to await the 
session.attach, which never came.  

{noformat}
/// original session attach
2018-02-15 13:17:50 [Network] trace SENT 
[[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; 
{SessionAttachBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }]
2018-02-15 13:17:50 [Network] trace RECV 
[[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; 
{SessionAttachedBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }]
2018-02-15 13:17:50 [Network] trace SENT 
[[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; 
{SessionRequestTimeoutBody: timeout=0; }]
/// snip - later heartbeat timeout
2018-02-15 13:18:20 [Client] debug Traffic timeout
/// snip - reconnecting again
2018-02-15 13:18:20 [System] info Connecting: 10.241.132.41:5672
/// snip -reuse the same session id
2018-02-15 13:18:28 [Client] debug Known-brokers for connection:
2018-02-15 13:18:28 [Network] trace SENT 
[[10.211.55.3:60056-10.241.132.41:5672]]: Frame[BEbe; channel=1; 
{SessionAttachBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }]
2018-02-15 13:18:28 [Network] trace RECV 
[[10.211.55.3:60056-10.241.132.41:5672]]: Frame[BEbe; channel=0; 
{SessionDetachedBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; code=1; }]
2018-02-15 13:18:28 [Client] info Connection 
[10.211.55.3:60056-10.241.132.41:5672] dropping frame received on invalid 
channel: Frame[BEbe; channel=0; {SessionDetachedBody: 
name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; code=1; }]
{noformat}

  was:
If, during session attachment, the Broker detects that the 0-10 session is 
already in use by the same principal, the Broker is required to detach the 
session by sending a {{session.detach}} on the same channel.  Currently owing 
to a defect, the Broker sends this detach on channel 0, regardless of the 
channel used by the peer.

This defect was a contributory factor in a larger problem.  It prevented an 
application from recovering automatically.In that case, a Qpid CPP 
Messaging API, recovering from a missing heartbeat, entered a hung state whilst 
attaching the existing session.  The client library discarded the 
session.detach on the unexpected channel, so it continued to await the 
session.attach, which never came.  

{noformat}
2018-02-15 13:17:50 [Network] trace SENT 
[[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; 
{SessionAttachBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }]
2018-02-15 13:17:50 [Network] trace RECV 
[[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; 
{SessionAttachedBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }]
2018-02-15 13:17:50 [Network] trace SENT 
[[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; 
{SessionRequestTimeoutBody: timeout=0; }]
/// snip
2018-02-15 13:18:20 [Client] debug Traffic timeout
/// snip
2018-02-15 13:18:20 [System] info Connecting: 10.241.132.41:5672
/// snip
2018-02-15 13:18:28 [Client] debug Known-brokers for connection:
2018-02-15 13:18:28 [Network] trace SENT 
[[10.211.55.3:60056-10.241.132.41:5672]]: Frame[BEbe; channel=1; 
{SessionAttachBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }]
2018-02-15 13:18:28 [Network] trace RECV 
[[10.211.55.3:60056-10.241.132.41:5672]]: Frame[BEbe; channel=0; 
{SessionDetachedBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; code=1; }]
2018-02-15 13:18:28 [Client] info Connection 
[10.211.55.3:60056-10.241.132.41:5672] dropping frame received on invalid 
channel: Frame[BEbe; channel=0; {SessionDetachedBody: 
name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; code=1; }]
{noformat}


> [Broker-J] [AMQP 0-10] SESSION_BUSY sent on wrong channel
> -
>
> Key: QPID-8100
> URL: https://issues.apache.org/jira/browse/QPID-8100
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: 0.32, qpid-java-broker-7.0.0, qpid-java-broker-7.0.1
> Environment: * Qpid Broker-J 0.32 derivative
> * Qpid Cpp Client using messaging API.
>Reporter: Keith Wall
>Priority: Minor
>
> If, during 

[jira] [Created] (QPID-8100) [Broker-J] [AMQP 0-10] SESSION_BUSY sent on wrong channel

[Keith Wall (JIRA)]

Keith Wall created QPID-8100:


 Summary: [Broker-J] [AMQP 0-10] SESSION_BUSY sent on wrong channel
 Key: QPID-8100
 URL: https://issues.apache.org/jira/browse/QPID-8100
 Project: Qpid
  Issue Type: Bug
  Components: Broker-J
Affects Versions: qpid-java-broker-7.0.1, qpid-java-broker-7.0.0, 0.32
 Environment: * Qpid Broker-J 0.32 derivative
* Qpid Cpp Client using messaging API.
Reporter: Keith Wall


If, during session attachment, the Broker detects that the 0-10 session is 
already in use by the same principal, the Broker is required to detach the 
session by sending a {{session.detach}} on the same channel.  Currently owing 
to a defect, the Broker sends this detach on channel 0, regardless of the 
channel used by the peer.

This defect was a contributory factor in a larger problem.  It prevented an 
application from recovering automatically.In that case, a Qpid CPP 
Messaging API, recovering from a missing heartbeat, entered a hung state whilst 
attaching the existing session.  The client library discarded the 
session.detach on the unexpected channel, so it continued to await the 
session.attach, which never came.  

{noformat}
2018-02-15 13:17:50 [Network] trace SENT 
[[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; 
{SessionAttachBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }]
2018-02-15 13:17:50 [Network] trace RECV 
[[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; 
{SessionAttachedBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }]
2018-02-15 13:17:50 [Network] trace SENT 
[[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; 
{SessionRequestTimeoutBody: timeout=0; }]
/// snip
2018-02-15 13:18:20 [Client] debug Traffic timeout
/// snip
2018-02-15 13:18:20 [System] info Connecting: 10.241.132.41:5672
/// snip
2018-02-15 13:18:28 [Client] debug Known-brokers for connection:
2018-02-15 13:18:28 [Network] trace SENT 
[[10.211.55.3:60056-10.241.132.41:5672]]: Frame[BEbe; channel=1; 
{SessionAttachBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }]
2018-02-15 13:18:28 [Network] trace RECV 
[[10.211.55.3:60056-10.241.132.41:5672]]: Frame[BEbe; channel=0; 
{SessionDetachedBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; code=1; }]
2018-02-15 13:18:28 [Client] info Connection 
[10.211.55.3:60056-10.241.132.41:5672] dropping frame received on invalid 
channel: Frame[BEbe; channel=0; {SessionDetachedBody: 
name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; code=1; }]
{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] (QPIDIT-109) Add ability to run Proton Python shims under Python 3

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPIDIT-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16365543#comment-16365543
 ] 

ASF subversion and git services commented on QPIDIT-109:


Commit 887d386864225f83accfdfa1773cab3b9d694f31 in qpid-interop-test's branch 
refs/heads/master from [~kpvdr]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-interop-test.git;h=887d386 ]

QPIDIT-109: Minor change to handling of PYTHON3PATH in config.sh file


> Add ability to run Proton Python shims under Python 3
> -
>
> Key: QPIDIT-109
> URL: https://issues.apache.org/jira/browse/QPIDIT-109
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: Improvement
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Major
> Fix For: 0.2.0
>
>
> Currently the shims run under Python 2.7, so add Python 3 as additional shim 
> type.



--
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-8098) [Broker-J] [AMQP 0-10] Queue browsers erroneously increment the delivery count

[Keith Wall (JIRA)]

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

Keith Wall reassigned QPID-8098:


Assignee: Keith Wall

> [Broker-J] [AMQP 0-10] Queue browsers erroneously increment the delivery count
> --
>
> Key: QPID-8098
> URL: https://issues.apache.org/jira/browse/QPID-8098
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: 0.30, 0.32, qpid-java-6.0, qpid-java-6.1, 
> qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.0.2, qpid-java-broker-7.1.0
>
>
> On the AMQP 0-10 protocol path within the Broker, deliveries to queue 
> browsers erroneously increase the {{MessageInstance#deliveryCount}}.  This 
> should not happen.  The purpose of the delivery count is to count deliveries 
> to (destructive) consumers - not browsers.  The problem is restricted to AMQP 
> 0-10 implementation.  Neither AMQP 0-x nor AMQP 1.0 are affected by this 
> defect.
> The defect could mean that messages are spuriously routed to a DLQ (if 
> configured).  For this to happen, there would need to be additional 
> destructive consumers on the queue that cause the message to be 'released'.  
> Releasing occurs during transaction rollback and client disconnection (when 
> messages are prefetched).   The message would be prematurely routed to the 
> DLQ in this case.
> The defect is longstanding.  I tested as far back as 0.30.
> https://mail-archives.apache.org/mod_mbox/qpid-users/201802.mbox/%3c1518546115789-0.p...@n2.nabble.com%3e



--
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-8098) [Broker-J] [AMQP 0-10] Queue browsers erroneously increment the delivery count

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-8098:
-
Status: Reviewable  (was: In Progress)

> [Broker-J] [AMQP 0-10] Queue browsers erroneously increment the delivery count
> --
>
> Key: QPID-8098
> URL: https://issues.apache.org/jira/browse/QPID-8098
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: 0.30, 0.32, qpid-java-6.0, qpid-java-6.1, 
> qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.0.2, qpid-java-broker-7.1.0
>
>
> On the AMQP 0-10 protocol path within the Broker, deliveries to queue 
> browsers erroneously increase the {{MessageInstance#deliveryCount}}.  This 
> should not happen.  The purpose of the delivery count is to count deliveries 
> to (destructive) consumers - not browsers.  The problem is restricted to AMQP 
> 0-10 implementation.  Neither AMQP 0-x nor AMQP 1.0 are affected by this 
> defect.
> The defect could mean that messages are spuriously routed to a DLQ (if 
> configured).  For this to happen, there would need to be additional 
> destructive consumers on the queue that cause the message to be 'released'.  
> Releasing occurs during transaction rollback and client disconnection (when 
> messages are prefetched).   The message would be prematurely routed to the 
> DLQ in this case.
> The defect is longstanding.  I tested as far back as 0.30.
> https://mail-archives.apache.org/mod_mbox/qpid-users/201802.mbox/%3c1518546115789-0.p...@n2.nabble.com%3e



--
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-8098) [Broker-J] [AMQP 0-10] Queue browsers erroneously increment the delivery count

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-8098:
-
Fix Version/s: qpid-java-broker-7.1.0
   qpid-java-broker-7.0.2

> [Broker-J] [AMQP 0-10] Queue browsers erroneously increment the delivery count
> --
>
> Key: QPID-8098
> URL: https://issues.apache.org/jira/browse/QPID-8098
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: 0.30, 0.32, qpid-java-6.0, qpid-java-6.1, 
> qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.0.2, qpid-java-broker-7.1.0
>
>
> On the AMQP 0-10 protocol path within the Broker, deliveries to queue 
> browsers erroneously increase the {{MessageInstance#deliveryCount}}.  This 
> should not happen.  The purpose of the delivery count is to count deliveries 
> to (destructive) consumers - not browsers.  The problem is restricted to AMQP 
> 0-10 implementation.  Neither AMQP 0-x nor AMQP 1.0 are affected by this 
> defect.
> The defect could mean that messages are spuriously routed to a DLQ (if 
> configured).  For this to happen, there would need to be additional 
> destructive consumers on the queue that cause the message to be 'released'.  
> Releasing occurs during transaction rollback and client disconnection (when 
> messages are prefetched).   The message would be prematurely routed to the 
> DLQ in this case.
> The defect is longstanding.  I tested as far back as 0.30.
> https://mail-archives.apache.org/mod_mbox/qpid-users/201802.mbox/%3c1518546115789-0.p...@n2.nabble.com%3e



--
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-8098) [Broker-J] [AMQP 0-10] Queue browsers erroneously increment the delivery count

[ASF subversion and git services (JIRA)]

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

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

Commit 59bd08a3103495ae0e8602c3e23b222a02a97bdf 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=59bd08a ]

QPID-8098: [Broker-J] Add supporting test case relating to browsing and 
delivery counts


> [Broker-J] [AMQP 0-10] Queue browsers erroneously increment the delivery count
> --
>
> Key: QPID-8098
> URL: https://issues.apache.org/jira/browse/QPID-8098
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: 0.30, 0.32, qpid-java-6.0, qpid-java-6.1, 
> qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Major
>
> On the AMQP 0-10 protocol path within the Broker, deliveries to queue 
> browsers erroneously increase the {{MessageInstance#deliveryCount}}.  This 
> should not happen.  The purpose of the delivery count is to count deliveries 
> to (destructive) consumers - not browsers.  The problem is restricted to AMQP 
> 0-10 implementation.  Neither AMQP 0-x nor AMQP 1.0 are affected by this 
> defect.
> The defect could mean that messages are spuriously routed to a DLQ (if 
> configured).  For this to happen, there would need to be additional 
> destructive consumers on the queue that cause the message to be 'released'.  
> Releasing occurs during transaction rollback and client disconnection (when 
> messages are prefetched).   The message would be prematurely routed to the 
> DLQ in this case.
> The defect is longstanding.  I tested as far back as 0.30.
> https://mail-archives.apache.org/mod_mbox/qpid-users/201802.mbox/%3c1518546115789-0.p...@n2.nabble.com%3e



--
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-8099) [Broker-J] [AMQP Management] Operation Queue#getMessageInfo response returned as serialised java object rather list of maps

[ASF subversion and git services (JIRA)]

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

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

Commit 1a28080d0872c2ff9c52f3ef915d83e33fbf4de0 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=1a28080 ]

QPID-8099: [Broker-J] Make MessageInfo and LogRecord implement 
ManagedAttributeValue.


> [Broker-J] [AMQP Management] Operation Queue#getMessageInfo response returned 
> as serialised java object rather list of maps
> ---
>
> Key: QPID-8099
> URL: https://issues.apache.org/jira/browse/QPID-8099
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.0, qpid-java-broker-7.0.1
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.1.0
>
>
> Invoking {{Queue#getMessageInfo}} over AMQP management returns response 
> message containing the serialised bytes of the MessageInfo object rather than 
> a list of maps.
> The problem is {{MessageInfo}} and {{LogRecord}} are missing the 
> {{ManagedAttributeValue}} interface, so 
> ManagedAttributeValueAbstractConverter is ignoring them.



--
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-8099) [Broker-J] [AMQP Management] Operation Queue#getMessageInfo response returned as serialised java object rather list of maps

[Keith Wall (JIRA)]

Keith Wall created QPID-8099:


 Summary: [Broker-J] [AMQP Management] Operation 
Queue#getMessageInfo response returned as serialised java object rather list of 
maps
 Key: QPID-8099
 URL: https://issues.apache.org/jira/browse/QPID-8099
 Project: Qpid
  Issue Type: Bug
  Components: Broker-J
Affects Versions: qpid-java-broker-7.0.0, qpid-java-broker-7.0.1
Reporter: Keith Wall
 Fix For: qpid-java-broker-7.1.0


Invoking {{Queue#getMessageInfo}} over AMQP management returns response message 
containing the serialised bytes of the MessageInfo object rather than a list of 
maps.

The problem is {{MessageInfo}} and {{LogRecord}} are missing the 
{{ManagedAttributeValue}} interface, so ManagedAttributeValueAbstractConverter 
is ignoring them.




--
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