date:20180425

[jira] [Commented] (DISPATCH-960) TCP port randomly assigned when using 'port: amqp' along with 'http: yes' on a listener

2018-04-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on DISPATCH-960:
-

GitHub user fgiorgetti opened a pull request:

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

DISPATCH-960 - Resolving service port when using http listener

As suggested by @ted-ross, I am re-submitting this PR again now using 
getservbyname_r which is multi-thread safe.

If you find any other possible issue, please let me know. 

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

$ git pull https://github.com/fgiorgetti/qpid-dispatch 
fgiorgetti-DISPATCH-960

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

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


commit 1fbfb14dee43f00113002d308e1862213edb2f7e
Author: Fernando Giorgetti 
Date:   2018-04-10T19:39:27Z

DISPATCH-960 - Resolving service port when using http listener




> TCP port randomly assigned when using 'port: amqp' along with 'http: yes' on 
> a listener
> ---
>
> Key: DISPATCH-960
> URL: https://issues.apache.org/jira/browse/DISPATCH-960
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 1.0.1
>Reporter: Fernando Giorgetti
>Priority: Major
> Attachments: dispatch-960-reproducer.tar.gz
>
>
> The default configuration for the dispatch router contains a default listener 
> set up to use 'port: amqp'.
> If you change the default listener to use 'http: yes' and starts the router, 
> it causes an issue as the service name (amqp) is not resolved, and so the 
> router attempts to listen to port 0 (random), causing an unpredictable 
> behavior.
>  
> A reproducer is attached to this issue.



--
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 #294: DISPATCH-960 - Resolving service port when ...

2018-04-25 Thread fgiorgetti

GitHub user fgiorgetti opened a pull request:

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

DISPATCH-960 - Resolving service port when using http listener

As suggested by @ted-ross, I am re-submitting this PR again now using 
getservbyname_r which is multi-thread safe.

If you find any other possible issue, please let me know. 

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

$ git pull https://github.com/fgiorgetti/qpid-dispatch 
fgiorgetti-DISPATCH-960

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

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


commit 1fbfb14dee43f00113002d308e1862213edb2f7e
Author: Fernando Giorgetti 
Date:   2018-04-10T19:39:27Z

DISPATCH-960 - Resolving service port when using http listener




---

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

[jira] [Commented] (DISPATCH-960) TCP port randomly assigned when using 'port: amqp' along with 'http: yes' on a listener

2018-04-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on DISPATCH-960:
-

Github user fgiorgetti closed the pull request at:

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


> TCP port randomly assigned when using 'port: amqp' along with 'http: yes' on 
> a listener
> ---
>
> Key: DISPATCH-960
> URL: https://issues.apache.org/jira/browse/DISPATCH-960
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 1.0.1
>Reporter: Fernando Giorgetti
>Priority: Major
> Attachments: dispatch-960-reproducer.tar.gz
>
>
> The default configuration for the dispatch router contains a default listener 
> set up to use 'port: amqp'.
> If you change the default listener to use 'http: yes' and starts the router, 
> it causes an issue as the service name (amqp) is not resolved, and so the 
> router attempts to listen to port 0 (random), causing an unpredictable 
> behavior.
>  
> A reproducer is attached to this issue.



--
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 #284: DISPATCH-960 - Resolving service port when ...

2018-04-25 Thread fgiorgetti

Github user fgiorgetti closed the pull request at:

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


---

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

[jira] [Commented] (PROTON-1831) [C++ binding] Nested complex types fail compilation with "incomplete type" error

2018-04-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on PROTON-1831:


Github user codecov-io commented on the issue:

https://github.com/apache/qpid-proton/pull/142
  
# [Codecov](https://codecov.io/gh/apache/qpid-proton/pull/142?src=pr=h1) 
Report
> Merging 
[#142](https://codecov.io/gh/apache/qpid-proton/pull/142?src=pr=desc) into 
[master](https://codecov.io/gh/apache/qpid-proton/commit/19ceafa529a0432eee294200e6f6056f7817038a?src=pr=desc)
 will **increase** coverage by `0.06%`.
> The diff coverage is `93.54%`.

[![Impacted file tree 
graph](https://codecov.io/gh/apache/qpid-proton/pull/142/graphs/tree.svg?height=150=UKKzV9XnFF=pr=650)](https://codecov.io/gh/apache/qpid-proton/pull/142?src=pr=tree)

```diff
@@Coverage Diff @@
##   master #142  +/-   ##
==
+ Coverage   85.88%   85.94%   +0.06% 
==
  Files 236  236  
  Lines   3005630117  +61 
==
+ Hits2581325885  +72 
+ Misses   4243 4232  -11
```


| [Impacted 
Files](https://codecov.io/gh/apache/qpid-proton/pull/142?src=pr=tree) | 
Coverage Δ | |
|---|---|---|
| 
[c/src/core/transport.c](https://codecov.io/gh/apache/qpid-proton/pull/142/diff?src=pr=tree#diff-Yy9zcmMvY29yZS90cmFuc3BvcnQuYw==)
 | `90.49% <100%> (+0.02%)` | :arrow_up: |
| 
[c/tests/connection\_driver.c](https://codecov.io/gh/apache/qpid-proton/pull/142/diff?src=pr=tree#diff-Yy90ZXN0cy9jb25uZWN0aW9uX2RyaXZlci5j)
 | `98.8% <92.3%> (-1.2%)` | :arrow_down: |
| 
[c/src/core/codec.c](https://codecov.io/gh/apache/qpid-proton/pull/142/diff?src=pr=tree#diff-Yy9zcmMvY29yZS9jb2RlYy5j)
 | `81.93% <0%> (-0.32%)` | :arrow_down: |
| 
[c/tests/test\_tools.h](https://codecov.io/gh/apache/qpid-proton/pull/142/diff?src=pr=tree#diff-Yy90ZXN0cy90ZXN0X3Rvb2xzLmg=)
 | `86.88% <0%> (+14.75%)` | :arrow_up: |
| 
[c/tests/test\_handler.h](https://codecov.io/gh/apache/qpid-proton/pull/142/diff?src=pr=tree#diff-Yy90ZXN0cy90ZXN0X2hhbmRsZXIuaA==)
 | `100% <0%> (+15.94%)` | :arrow_up: |

--

[Continue to review full report at 
Codecov](https://codecov.io/gh/apache/qpid-proton/pull/142?src=pr=continue).
> **Legend** - [Click here to learn 
more](https://docs.codecov.io/docs/codecov-delta)
> `Δ = absolute  (impact)`, `ø = not affected`, `? = missing data`
> Powered by 
[Codecov](https://codecov.io/gh/apache/qpid-proton/pull/142?src=pr=footer). 
Last update 
[19ceafa...53b1768](https://codecov.io/gh/apache/qpid-proton/pull/142?src=pr=lastupdated).
 Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).



> [C++ binding] Nested complex types fail compilation with "incomplete type" 
> error
> 
>
> Key: PROTON-1831
> URL: https://issues.apache.org/jira/browse/PROTON-1831
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Reporter: Kim van der Riet
>Assignee: Alan Conway
>Priority: Major
>
> When using nested complex types (for example, a list of maps or an array of 
> lists), the compiler fails to compile. For example, the following code 
> snippet (saved as {{ctt.cpp}}):
> {noformat}
> #include 
> #include 
> #include 
> int main(int, char**) {
> std::map m1 = {{uint8_t(0), "zero"}, 
> {uint8_t(1), "one"}};
> std::map m2 = {{true, "true"}, {false, 
> "false"}};
> std::vector > am = {m1, m2};
> proton::value pv = am;
> }{noformat}
> fails compilation with the following error:
> {noformat}
> In file included from install/include/proton/types.hpp:47:0,
> from ctt.cpp:3:
> install/include/proton/./codec/vector.hpp: In instantiation of 
> ‘proton::codec::encoder& proton::codec::operator<<(proton::codec::encoder&, 
> const std::vector<_Tp, _Alloc>&) [with T = std::map proton::value>; A = std::allocator >]’:
> install/include/proton/./value.hpp:84:11: required from ‘typename 
> proton::value::assignable::type 
> proton::value::operator=(const T&) [with T = 
> std::vector >; typename 
> proton::value::assignable::type = proton::value&]’
> install/include/proton/./value.hpp:79:85: required from 
> ‘proton::value::value(const T&, typename proton::value::assignable::type*) 
> [with T = std::vector

[GitHub] qpid-proton issue #142: PROTON-1831: Incorrect open/close sequence for same ...

2018-04-25 Thread codecov-io

Github user codecov-io commented on the issue:

https://github.com/apache/qpid-proton/pull/142
  
# [Codecov](https://codecov.io/gh/apache/qpid-proton/pull/142?src=pr=h1) 
Report
> Merging 
[#142](https://codecov.io/gh/apache/qpid-proton/pull/142?src=pr=desc) into 
[master](https://codecov.io/gh/apache/qpid-proton/commit/19ceafa529a0432eee294200e6f6056f7817038a?src=pr=desc)
 will **increase** coverage by `0.06%`.
> The diff coverage is `93.54%`.

[![Impacted file tree 
graph](https://codecov.io/gh/apache/qpid-proton/pull/142/graphs/tree.svg?height=150=UKKzV9XnFF=pr=650)](https://codecov.io/gh/apache/qpid-proton/pull/142?src=pr=tree)

```diff
@@Coverage Diff @@
##   master #142  +/-   ##
==
+ Coverage   85.88%   85.94%   +0.06% 
==
  Files 236  236  
  Lines   3005630117  +61 
==
+ Hits2581325885  +72 
+ Misses   4243 4232  -11
```


| [Impacted 
Files](https://codecov.io/gh/apache/qpid-proton/pull/142?src=pr=tree) | 
Coverage Î | |
|---|---|---|
| 
[c/src/core/transport.c](https://codecov.io/gh/apache/qpid-proton/pull/142/diff?src=pr=tree#diff-Yy9zcmMvY29yZS90cmFuc3BvcnQuYw==)
 | `90.49% <100%> (+0.02%)` | :arrow_up: |
| 
[c/tests/connection\_driver.c](https://codecov.io/gh/apache/qpid-proton/pull/142/diff?src=pr=tree#diff-Yy90ZXN0cy9jb25uZWN0aW9uX2RyaXZlci5j)
 | `98.8% <92.3%> (-1.2%)` | :arrow_down: |
| 
[c/src/core/codec.c](https://codecov.io/gh/apache/qpid-proton/pull/142/diff?src=pr=tree#diff-Yy9zcmMvY29yZS9jb2RlYy5j)
 | `81.93% <0%> (-0.32%)` | :arrow_down: |
| 
[c/tests/test\_tools.h](https://codecov.io/gh/apache/qpid-proton/pull/142/diff?src=pr=tree#diff-Yy90ZXN0cy90ZXN0X3Rvb2xzLmg=)
 | `86.88% <0%> (+14.75%)` | :arrow_up: |
| 
[c/tests/test\_handler.h](https://codecov.io/gh/apache/qpid-proton/pull/142/diff?src=pr=tree#diff-Yy90ZXN0cy90ZXN0X2hhbmRsZXIuaA==)
 | `100% <0%> (+15.94%)` | :arrow_up: |

--

[Continue to review full report at 
Codecov](https://codecov.io/gh/apache/qpid-proton/pull/142?src=pr=continue).
> **Legend** - [Click here to learn 
more](https://docs.codecov.io/docs/codecov-delta)
> `Î = absolute  (impact)`, `Ã¸ = not affected`, `? = missing 
data`
> Powered by 
[Codecov](https://codecov.io/gh/apache/qpid-proton/pull/142?src=pr=footer). 
Last update 
[19ceafa...53b1768](https://codecov.io/gh/apache/qpid-proton/pull/142?src=pr=lastupdated).
 Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).



---

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

[jira] [Created] (QPIDIT-124) [Complex Types Test] Write .NetLite generator and shims

2018-04-25 Thread Kim van der Riet (JIRA)

Kim van der Riet created QPIDIT-124:
---

 Summary: [Complex Types Test] Write .NetLite generator and shims
 Key: QPIDIT-124
 URL: https://issues.apache.org/jira/browse/QPIDIT-124
 Project: Apache QPID Interoperability Test Suite
  Issue Type: Task
Reporter: Kim van der Riet


* Add the Amqp.NetLite generator
 * Write the send and receive shims



--
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] (QPIDIT-124) [Complex Types Test] Write .NetLite generator and shims

2018-04-25 Thread Kim van der Riet (JIRA)


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

Kim van der Riet updated QPIDIT-124:

Component/s: AMQP Complex Types Test

> [Complex Types Test] Write .NetLite generator and shims
> ---
>
> Key: QPIDIT-124
> URL: https://issues.apache.org/jira/browse/QPIDIT-124
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: Task
>  Components: AMQP Complex Types Test
>Reporter: Kim van der Riet
>Priority: Major
>
> * Add the Amqp.NetLite generator
>  * Write the send and receive shims



--
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] (QPIDIT-124) [Complex Types Test] Write .NetLite generator and shims

2018-04-25 Thread Kim van der Riet (JIRA)


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

Kim van der Riet reassigned QPIDIT-124:
---

Assignee: Kim van der Riet

> [Complex Types Test] Write .NetLite generator and shims
> ---
>
> Key: QPIDIT-124
> URL: https://issues.apache.org/jira/browse/QPIDIT-124
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: Task
>  Components: AMQP Complex Types Test
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Major
>
> * Add the Amqp.NetLite generator
>  * Write the send and receive shims



--
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] (QPIDIT-123) [Complex Types Test] Write RheaJS generator and shims

2018-04-25 Thread Kim van der Riet (JIRA)


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

Kim van der Riet reassigned QPIDIT-123:
---

Assignee: Kim van der Riet

> [Complex Types Test] Write RheaJS generator and shims
> -
>
> Key: QPIDIT-123
> URL: https://issues.apache.org/jira/browse/QPIDIT-123
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: Task
>  Components: AMQP Complex Types Test
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Major
>
> * Add the Rhea JS generator
>  * Add the Send and Recieve shims



--
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] (QPIDIT-123) [Complex Types Test] Write RheaJS generator and shims

2018-04-25 Thread Kim van der Riet (JIRA)

Kim van der Riet created QPIDIT-123:
---

 Summary: [Complex Types Test] Write RheaJS generator and shims
 Key: QPIDIT-123
 URL: https://issues.apache.org/jira/browse/QPIDIT-123
 Project: Apache QPID Interoperability Test Suite
  Issue Type: Task
  Components: AMQP Complex Types Test
Reporter: Kim van der Riet


* Add the Rhea JS generator
 * Add the Send and Recieve shims



--
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-1831) [C++ binding] Nested complex types fail compilation with "incomplete type" error

2018-04-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on PROTON-1831:


GitHub user alanconway opened a pull request:

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

PROTON-1831: Incorrect open/close sequence for same link name.

Fixes the server side part of PROTON-1831 - transport error if a duplicate 
link
name is attached instead of seg fault.

Client side problem remains: pni_process does not respect the order of 
individual open/close calls,
and it is possible to generate an invalid sequence that attempts a duplicate
attach when it should not. This commit includes a test that illustrates the
problem, the test runs but status is ignored for now.

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

$ git pull https://github.com/alanconway/qpid-proton c-link-open-close

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

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


commit 3ac3e22ce343523291d0baa64debc20fe5a3f415
Author: Alan Conway 
Date:   2018-04-20T19:53:26Z

PROTON-1831: Incorrect open/close sequence for same link name.

Fixes the server side part of PROTON-1831 - transport error if a duplicate 
link
name is attached instead of seg fault.

Client side problem remains: pni_process does not respect the order of 
individual open/close calls,
and it is possible to generate an invalid sequence that attempts a duplicate
attach when it should not. This commit includes a test that illustrates the
problem, the test runs but status is ignored for now.




> [C++ binding] Nested complex types fail compilation with "incomplete type" 
> error
> 
>
> Key: PROTON-1831
> URL: https://issues.apache.org/jira/browse/PROTON-1831
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Reporter: Kim van der Riet
>Assignee: Alan Conway
>Priority: Major
>
> When using nested complex types (for example, a list of maps or an array of 
> lists), the compiler fails to compile. For example, the following code 
> snippet (saved as {{ctt.cpp}}):
> {noformat}
> #include 
> #include 
> #include 
> int main(int, char**) {
> std::map m1 = {{uint8_t(0), "zero"}, 
> {uint8_t(1), "one"}};
> std::map m2 = {{true, "true"}, {false, 
> "false"}};
> std::vector > am = {m1, m2};
> proton::value pv = am;
> }{noformat}
> fails compilation with the following error:
> {noformat}
> In file included from install/include/proton/types.hpp:47:0,
> from ctt.cpp:3:
> install/include/proton/./codec/vector.hpp: In instantiation of 
> ‘proton::codec::encoder& proton::codec::operator<<(proton::codec::encoder&, 
> const std::vector<_Tp, _Alloc>&) [with T = std::map proton::value>; A = std::allocator >]’:
> install/include/proton/./value.hpp:84:11: required from ‘typename 
> proton::value::assignable::type 
> proton::value::operator=(const T&) [with T = 
> std::vector >; typename 
> proton::value::assignable::type = proton::value&]’
> install/include/proton/./value.hpp:79:85: required from 
> ‘proton::value::value(const T&, typename proton::value::assignable::type*) 
> [with T = std::vector >; typename 
> proton::value::assignable::type = void]’
> ctt.cpp:9:24: required from here
> install/include/proton/./codec/vector.hpp:39:31: error: incomplete type 
> ‘proton::internal::type_id_of >’ used 
> in nested name specifier
> return e << encoder::array(x, internal::type_id_of::value);
> ~~^~~
> {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-proton pull request #142: PROTON-1831: Incorrect open/close sequence fo...

2018-04-25 Thread alanconway

GitHub user alanconway opened a pull request:

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

PROTON-1831: Incorrect open/close sequence for same link name.

Fixes the server side part of PROTON-1831 - transport error if a duplicate 
link
name is attached instead of seg fault.

Client side problem remains: pni_process does not respect the order of 
individual open/close calls,
and it is possible to generate an invalid sequence that attempts a duplicate
attach when it should not. This commit includes a test that illustrates the
problem, the test runs but status is ignored for now.

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

$ git pull https://github.com/alanconway/qpid-proton c-link-open-close

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

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


commit 3ac3e22ce343523291d0baa64debc20fe5a3f415
Author: Alan Conway 
Date:   2018-04-20T19:53:26Z

PROTON-1831: Incorrect open/close sequence for same link name.

Fixes the server side part of PROTON-1831 - transport error if a duplicate 
link
name is attached instead of seg fault.

Client side problem remains: pni_process does not respect the order of 
individual open/close calls,
and it is possible to generate an invalid sequence that attempts a duplicate
attach when it should not. This commit includes a test that illustrates the
problem, the test runs but status is ignored for now.




---

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

[jira] [Updated] (QPIDIT-119) Add AMQP complex type test

2018-04-25 Thread Kim van der Riet (JIRA)


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

Kim van der Riet updated QPIDIT-119:

Component/s: AMQP Complex Types Test

> Add AMQP complex type test
> --
>
> Key: QPIDIT-119
> URL: https://issues.apache.org/jira/browse/QPIDIT-119
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: Task
>  Components: AMQP Complex Types Test
>Affects Versions: 0.1.0
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Major
> Fix For: 0.2.0
>
>
> The AMQP types test cover the simple tests well, but do not do a good job of 
> the complex types. This is because the ability to represent the test data for 
> the complex types is itself a complex issue, as each complex type may contain 
> an arbitrary number of other complex types. For example, a list may contain 
> other lists or maps, and maps may contain other lists and maps as both keys 
> and values.
> Solving this problem requires that a mechanism exist to create and represent 
> an arbitrarily large and complex set of data for testing, and allow the sent 
> and received data to be compared to determine success or 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

[jira] [Created] (QPIDIT-122) [Complex Types Test] Complete and test AMQP array type

2018-04-25 Thread Kim van der Riet (JIRA)

Kim van der Riet created QPIDIT-122:
---

 Summary: [Complex Types Test] Complete and test AMQP array type
 Key: QPIDIT-122
 URL: https://issues.apache.org/jira/browse/QPIDIT-122
 Project: Apache QPID Interoperability Test Suite
  Issue Type: Task
Reporter: Kim van der Riet
Assignee: Kim van der Riet


This is blocked by PROTON-1824: [Python binding] Use of proton.Array causes 
SIGSEGV in Proton encoder.

Once this is cleared, then the Python shims can be completed and tested. The 
C++ shims are mostly complete.



--
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] (QPIDJMS-381) update to proton-j 0.27.1

2018-04-25 Thread Robbie Gemmell (JIRA)


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

Robbie Gemmell updated QPIDJMS-381:
---
Description: Update to proton-j 0.27.1 to pick up some implicit perf 
improvements (particularly receiving large messages) and new functionality we 
can additionally utilise to produce others.  (was: Update to proton-j 0.27.0 to 
pick up some implicit perf improvements (particularly receiving large messages) 
and new functionality we can additionally utilise to produce others.)
Summary: update to proton-j 0.27.1  (was: update to proton-j 0.27.0)

> update to proton-j 0.27.1
> -
>
> Key: QPIDJMS-381
> URL: https://issues.apache.org/jira/browse/QPIDJMS-381
> Project: Qpid JMS
>  Issue Type: Task
>  Components: qpid-jms-client
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Major
> Fix For: 0.32.0
>
> Attachments: map-string-decode-test.diff
>
>
> Update to proton-j 0.27.1 to pick up some implicit perf improvements 
> (particularly receiving large messages) and new functionality we can 
> additionally utilise to produce others.



--
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-979) self test mock policy manager does not forward policy warnings

2018-04-25 Thread ASF subversion and git services (JIRA)


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

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

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

DISPATCH-979: add missing warning interface to text mock policy manager


> self test mock policy manager does not forward policy warnings
> --
>
> Key: DISPATCH-979
> URL: https://issues.apache.org/jira/browse/DISPATCH-979
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Policy Engine, Tests
>Affects Versions: 1.0.1
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>Priority: Minor
>
> Similar to DISPATCH-967 a mock policy manager is missing the warning 
> interface.



--
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-979) self test mock policy manager does not forward policy warnings

2018-04-25 Thread Chuck Rolke (JIRA)

Chuck Rolke created DISPATCH-979:


 Summary: self test mock policy manager does not forward policy 
warnings
 Key: DISPATCH-979
 URL: https://issues.apache.org/jira/browse/DISPATCH-979
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Policy Engine, Tests
Affects Versions: 1.0.1
Reporter: Chuck Rolke
Assignee: Chuck Rolke


Similar to DISPATCH-967 a mock policy manager is missing the warning interface.



--
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-1836) the empty string encoding gets decoded as null when using a CompositeReadableBuffer

2018-04-25 Thread ASF subversion and git services (JIRA)


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

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

Commit f2482bb10200ed78401100d5faac4c5797bc810c 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=f2482bb ]

PROTON-1836 Fix test name typo

> the empty string encoding gets decoded as null when using a 
> CompositeReadableBuffer
> ---
>
> Key: PROTON-1836
> URL: https://issues.apache.org/jira/browse/PROTON-1836
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: proton-j-0.27.0
>Reporter: Robbie Gemmell
>Priority: Major
> Fix For: proton-j-0.28.0
>
>
> When an empty string encoding arrives and a CompositeReadableBuffer (as 
> returned from the new Delivery#recv()) is in use then the decoding will 
> return null instead of empty string.



--
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-1836) the empty string encoding gets decoded as null when using a CompositeReadableBuffer

2018-04-25 Thread ASF subversion and git services (JIRA)


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

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

Commit 62cbea9d79d9c0352a9b5076e64056289b00f0ac 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=62cbea9 ]

PROTON-1836 Fix empty string decoding from CompositeReadableBuffer

Ensure that empty string is read as empty and not null string.  Adds
tests and optimizes the StringType encodings to fast return on size zero
strings.

> the empty string encoding gets decoded as null when using a 
> CompositeReadableBuffer
> ---
>
> Key: PROTON-1836
> URL: https://issues.apache.org/jira/browse/PROTON-1836
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: proton-j-0.27.0
>Reporter: Robbie Gemmell
>Priority: Major
> Fix For: proton-j-0.28.0
>
>
> When an empty string encoding arrives and a CompositeReadableBuffer (as 
> returned from the new Delivery#recv()) is in use then the decoding will 
> return null instead of empty string.



--
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-966) Qpid dispatch unstable inter-router connections

2018-04-25 Thread ASF subversion and git services (JIRA)


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

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

Commit 80b592165a3a8fc76db40e088350b75e5f41fcc8 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=80b5921 ]

DISPATCH-966 - Improved logging in the router engine so long bodies don't cause 
back-traces to be truncated.


> Qpid dispatch unstable inter-router connections
> ---
>
> Key: DISPATCH-966
> URL: https://issues.apache.org/jira/browse/DISPATCH-966
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Routing Engine
>Affects Versions: 1.0.1
>Reporter: Marcel Meulemans
>Assignee: Ted Ross
>Priority: Major
> Attachments: qdrouterd-unsettled-true.log, qdrouterd.conf, 
> qdrouterd.log, router-unsettled-true.dump, router.dump
>
>
> I am running a three node fully connected mesh of dispatch routers with 1 
> attached clients and I am seeing some unstable inter-router connections (I am 
> sending around 1000 small, less than 1K, messages per second through the 
> network). The inter-router connections fail every so many seconds with the 
> message:
> {{Connection to router-2:55672 failed: amqp:session:invalid-field sequencing 
> error, expected delivery-id 7, got 6}}
> (the numbers 7 and 6 differ per connection loss)
> In wireshark, using the attached tcpdump capture, I can see that every time 
> before the inter router connection is dropped, therw is a rejected 
> disposition with the message:
> {{Condition: qd:forbidden}}
> {{Description: Deliveries to a multicast address must be pre-settled}}
> The routers are connected as follows:
>  * router-0 -> router-1
>  * router-0 -> router-2
>  * router-1 -> router-2
> The routers are running as a docker container (debian stretch) on google 
> compute engine machines (every router on a separate node).
> Attached are:
>  * my qdrouter.conf (from one of the routers)
>  * a log snippet from router-0 at debug level from connection drop to 
> connection re-established to connection drop again.
>  * a tcpdump capture of the inter-router connection between router-0 and 
> router-1 during which several of the failures occur
> Versions:
>  * qpid-dispatch@1.0.1-rc1
>  * qpid-proton@0.20.0
>  
> [^qdrouterd.log]
> [^qdrouterd.conf]
> [^router.dump]



--
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 #284: DISPATCH-960 - Resolving service port when ...

2018-04-25 Thread ted-ross

Github user ted-ross commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/284#discussion_r184177949
  
--- Diff: src/amqp.c ---
@@ -73,11 +76,24 @@ const char * const QD_AMQP_COND_FRAME_SIZE_TOO_SMALL = 
"amqp:frame-size-too-smal
 const char * const QD_AMQP_PORT_STR = "5672";
 const char * const QD_AMQPS_PORT_STR = "5671";
 
+const char * const QD_AMQP_DFLT_PROTO = "tcp";
+
 int qd_port_int(const char* port_str) {
 if (!strcmp(port_str, QD_AMQP_PORT_STR)) return QD_AMQP_PORT_INT;
 if (!strcmp(port_str, QD_AMQPS_PORT_STR)) return QD_AMQPS_PORT_INT;
 errno = 0;
 unsigned long n = strtoul(port_str, NULL, 10);
 if (errno || n > 0x) return -1;
+
+// Port is not an integer (port = 'amqp' or 'amqps')
+if ( !n && strlen(port_str) > 0 ) {
+// Resolve service port
+struct servent *serv_info = getservbyname(port_str, 
QD_AMQP_DFLT_PROTO);
--- End diff --

The man page for getservbyname states that this call is 
multi-thread-unsafe.  This should be replaced by a thread-safe equivalent to 
avoid concurrency issues.


---

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

[jira] [Commented] (DISPATCH-960) TCP port randomly assigned when using 'port: amqp' along with 'http: yes' on a listener

2018-04-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on DISPATCH-960:
-

Github user ted-ross commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/284#discussion_r184177949
  
--- Diff: src/amqp.c ---
@@ -73,11 +76,24 @@ const char * const QD_AMQP_COND_FRAME_SIZE_TOO_SMALL = 
"amqp:frame-size-too-smal
 const char * const QD_AMQP_PORT_STR = "5672";
 const char * const QD_AMQPS_PORT_STR = "5671";
 
+const char * const QD_AMQP_DFLT_PROTO = "tcp";
+
 int qd_port_int(const char* port_str) {
 if (!strcmp(port_str, QD_AMQP_PORT_STR)) return QD_AMQP_PORT_INT;
 if (!strcmp(port_str, QD_AMQPS_PORT_STR)) return QD_AMQPS_PORT_INT;
 errno = 0;
 unsigned long n = strtoul(port_str, NULL, 10);
 if (errno || n > 0x) return -1;
+
+// Port is not an integer (port = 'amqp' or 'amqps')
+if ( !n && strlen(port_str) > 0 ) {
+// Resolve service port
+struct servent *serv_info = getservbyname(port_str, 
QD_AMQP_DFLT_PROTO);
--- End diff --

The man page for getservbyname states that this call is 
multi-thread-unsafe.  This should be replaced by a thread-safe equivalent to 
avoid concurrency issues.


> TCP port randomly assigned when using 'port: amqp' along with 'http: yes' on 
> a listener
> ---
>
> Key: DISPATCH-960
> URL: https://issues.apache.org/jira/browse/DISPATCH-960
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 1.0.1
>Reporter: Fernando Giorgetti
>Priority: Major
> Attachments: dispatch-960-reproducer.tar.gz
>
>
> The default configuration for the dispatch router contains a default listener 
> set up to use 'port: amqp'.
> If you change the default listener to use 'http: yes' and starts the router, 
> it causes an issue as the service name (amqp) is not resolved, and so the 
> router attempts to listen to port 0 (random), causing an unpredictable 
> behavior.
>  
> A reproducer is attached to this issue.



--
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-1836) the empty string encoding gets decoded as null when using a CompositeReadableBuffer

2018-04-25 Thread Robbie Gemmell (JIRA)


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

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

> the empty string encoding gets decoded as null when using a 
> CompositeReadableBuffer
> ---
>
> Key: PROTON-1836
> URL: https://issues.apache.org/jira/browse/PROTON-1836
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: proton-j-0.27.0
>Reporter: Robbie Gemmell
>Priority: Major
> Fix For: proton-j-0.28.0
>
>
> When an empty string encoding arrives and a CompositeReadableBuffer (as 
> returned from the new Delivery#recv()) is in use then the decoding will 
> return null instead of empty string.



--
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-381) update to proton-j 0.27.0

2018-04-25 Thread Robbie Gemmell (JIRA)


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

Robbie Gemmell commented on QPIDJMS-381:


Attached a client test which demonstrates the issue.

> update to proton-j 0.27.0
> -
>
> Key: QPIDJMS-381
> URL: https://issues.apache.org/jira/browse/QPIDJMS-381
> Project: Qpid JMS
>  Issue Type: Task
>  Components: qpid-jms-client
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Major
> Fix For: 0.32.0
>
> Attachments: map-string-decode-test.diff
>
>
> Update to proton-j 0.27.0 to pick up some implicit perf improvements 
> (particularly receiving large messages) and new functionality we can 
> additionally utilise to produce others.



--
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] (QPIDJMS-381) update to proton-j 0.27.0

2018-04-25 Thread Robbie Gemmell (JIRA)


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

Robbie Gemmell reopened QPIDJMS-381:


Reopening, we will need a new release for QPIDJMS-383 to work fully, due to 
PROTON-1836.

> update to proton-j 0.27.0
> -
>
> Key: QPIDJMS-381
> URL: https://issues.apache.org/jira/browse/QPIDJMS-381
> Project: Qpid JMS
>  Issue Type: Task
>  Components: qpid-jms-client
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Major
> Fix For: 0.32.0
>
> Attachments: map-string-decode-test.diff
>
>
> Update to proton-j 0.27.0 to pick up some implicit perf improvements 
> (particularly receiving large messages) and new functionality we can 
> additionally utilise to produce others.



--
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] (QPIDJMS-381) update to proton-j 0.27.0

2018-04-25 Thread Robbie Gemmell (JIRA)


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

Robbie Gemmell updated QPIDJMS-381:
---
Attachment: map-string-decode-test.diff

> update to proton-j 0.27.0
> -
>
> Key: QPIDJMS-381
> URL: https://issues.apache.org/jira/browse/QPIDJMS-381
> Project: Qpid JMS
>  Issue Type: Task
>  Components: qpid-jms-client
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Major
> Fix For: 0.32.0
>
> Attachments: map-string-decode-test.diff
>
>
> Update to proton-j 0.27.0 to pick up some implicit perf improvements 
> (particularly receiving large messages) and new functionality we can 
> additionally utilise to produce others.



--
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-1836) the empty string encoding gets decoded as null when using a CompositeReadableBuffer

2018-04-25 Thread Robbie Gemmell (JIRA)

Robbie Gemmell created PROTON-1836:
--

 Summary: the empty string encoding gets decoded as null when using 
a CompositeReadableBuffer
 Key: PROTON-1836
 URL: https://issues.apache.org/jira/browse/PROTON-1836
 Project: Qpid Proton
  Issue Type: Improvement
  Components: proton-j
Affects Versions: proton-j-0.27.0
Reporter: Robbie Gemmell
 Fix For: proton-j-0.28.0


When an empty string encoding arrives and a CompositeReadableBuffer (as 
returned from the new Delivery#recv()) is in use then the decoding will return 
null instead of empty string.



--
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-378) Update Netty to latest 4.1.24.Final

2018-04-25 Thread Timothy Bish (JIRA)


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

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

> Update Netty to latest 4.1.24.Final
> ---
>
> Key: QPIDJMS-378
> URL: https://issues.apache.org/jira/browse/QPIDJMS-378
> Project: Qpid JMS
>  Issue Type: Task
>Affects Versions: 0.31.0
>Reporter: Timothy Bish
>Assignee: Robbie Gemmell
>Priority: Minor
> Fix For: 0.32.0
>
>
> Update netty to latest release



--
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-966) Qpid dispatch unstable inter-router connections

2018-04-25 Thread Ted Ross (JIRA)


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

Ted Ross commented on DISPATCH-966:
---

Near the bottom of the log there is a control message error logged from the 
router engine.  Unfortunately, the most interesting part of the log (the back 
trace) has been truncated.  I will provide a patch that separates these into 
two log entries so we don't lose the back trace when there is a large message 
body.

 

> Qpid dispatch unstable inter-router connections
> ---
>
> Key: DISPATCH-966
> URL: https://issues.apache.org/jira/browse/DISPATCH-966
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Routing Engine
>Affects Versions: 1.0.1
>Reporter: Marcel Meulemans
>Assignee: Ted Ross
>Priority: Major
> Attachments: qdrouterd-unsettled-true.log, qdrouterd.conf, 
> qdrouterd.log, router-unsettled-true.dump, router.dump
>
>
> I am running a three node fully connected mesh of dispatch routers with 1 
> attached clients and I am seeing some unstable inter-router connections (I am 
> sending around 1000 small, less than 1K, messages per second through the 
> network). The inter-router connections fail every so many seconds with the 
> message:
> {{Connection to router-2:55672 failed: amqp:session:invalid-field sequencing 
> error, expected delivery-id 7, got 6}}
> (the numbers 7 and 6 differ per connection loss)
> In wireshark, using the attached tcpdump capture, I can see that every time 
> before the inter router connection is dropped, therw is a rejected 
> disposition with the message:
> {{Condition: qd:forbidden}}
> {{Description: Deliveries to a multicast address must be pre-settled}}
> The routers are connected as follows:
>  * router-0 -> router-1
>  * router-0 -> router-2
>  * router-1 -> router-2
> The routers are running as a docker container (debian stretch) on google 
> compute engine machines (every router on a separate node).
> Attached are:
>  * my qdrouter.conf (from one of the routers)
>  * a log snippet from router-0 at debug level from connection drop to 
> connection re-established to connection drop again.
>  * a tcpdump capture of the inter-router connection between router-0 and 
> router-1 during which several of the failures occur
> Versions:
>  * qpid-dispatch@1.0.1-rc1
>  * qpid-proton@0.20.0
>  
> [^qdrouterd.log]
> [^qdrouterd.conf]
> [^router.dump]



--
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-380) Implement ConnectionConsumer to enable use in resource adapters

2018-04-25 Thread Timothy Bish (JIRA)


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

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

> Implement ConnectionConsumer to enable use in resource adapters
> ---
>
> Key: QPIDJMS-380
> URL: https://issues.apache.org/jira/browse/QPIDJMS-380
> Project: Qpid JMS
>  Issue Type: Improvement
>Affects Versions: 0.31.0
>Reporter: Justin Ross
>Assignee: Timothy Bish
>Priority: Major
> Fix For: 0.32.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

[jira] [Resolved] (QPIDJMS-384) Add support for user user defined extensions to override client configuration

2018-04-25 Thread Timothy Bish (JIRA)


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

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

> Add support for user user defined extensions to override client configuration
> -
>
> Key: QPIDJMS-384
> URL: https://issues.apache.org/jira/browse/QPIDJMS-384
> Project: Qpid JMS
>  Issue Type: Improvement
>  Components: qpid-jms-client
>Affects Versions: 0.31.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Major
> Fix For: 0.32.0
>
>
> Implement a means of injecting user defined configuration overrides that 
> allow the client to query user code to obtain various configuration values 
> such as HTTP headers for WebSocket authentication of per connection login 
> credentials in failover scenarios. 



--
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-377) Update testing dependencies (ActiveMQ, MiniKDC and Mockito)

2018-04-25 Thread ASF subversion and git services (JIRA)


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

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

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

QPIDJMS-377 Update Mockito to latest 2.18.3 release

> 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] [Updated] (DISPATCH-941) Router is returning incorrect files from http get requests.

2018-04-25 Thread Ted Ross (JIRA)


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

Ted Ross updated DISPATCH-941:
--
Summary: Router is returning incorrect files from http get requests.  (was: 
Router is returning icorrect files from http get requests.)

> Router is returning incorrect files from http get requests.
> ---
>
> Key: DISPATCH-941
> URL: https://issues.apache.org/jira/browse/DISPATCH-941
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Routing Engine
>Affects Versions: 1.0.1
>Reporter: Ernest Allen
>Priority: Major
> Fix For: Backlog
>
> Attachments: CaptureApache_angular.PNG, CaptureApache_angular.PNG, 
> CaptureApache_woff2.PNG, CaptureApache_woff2.PNG, CaptureApache_woff2.PNG, 
> CaptureDispatch_angular.PNG, CaptureDispatch_angular.PNG, 
> CaptureDispatch_woff2.PNG
>
>
> When http requests are made from a Windows machine, the http response headers 
> appear to be mixed up or for a different request. For example, when the 
> browser requests the file OpenSans-Regular-webfont.woff2, the response has a 
> content-type of text/javascript and an incorrect content-length. Here is the 
> bad response: !CaptureDispatch_woff2.PNG!
> When the same browser on the same machine requests the same file from Apache 
> tomcat, the response is correct:
> !CaptureApache_woff2.PNG!
> Another example: This time the request is for the javascript file angular.js. 
> Here is the bad response from the router:
> !CaptureDispatch_angular.PNG!
>  
> And here is the correct response from tomcat for the same file:
> !CaptureApache_angular.PNG!
> The incorrect content-types and content-lengths returned by the router lead 
> me to believe that the responses are getting mixed up.
> Possibly important note: Which requests are mixed up varies each time I 
> reload the page. Sometimes files that failed on a previous page load will 
> come down just fine. It doesn't always happen on the same files.
> This happens for all browsers I've tried on Windows. It does not happen for 
> any browser when the request comes from my linux box.
>  



--
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-384) Add support for user user defined extensions to override client configuration

2018-04-25 Thread ASF subversion and git services (JIRA)


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

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

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

QPIDJMS-384 Add documentation around WS and custom HTTP headers

Show how HTTP Headers can be configured on the transport URI

> Add support for user user defined extensions to override client configuration
> -
>
> Key: QPIDJMS-384
> URL: https://issues.apache.org/jira/browse/QPIDJMS-384
> Project: Qpid JMS
>  Issue Type: Improvement
>  Components: qpid-jms-client
>Affects Versions: 0.31.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Major
> Fix For: 0.32.0
>
>
> Implement a means of injecting user defined configuration overrides that 
> allow the client to query user code to obtain various configuration values 
> such as HTTP headers for WebSocket authentication of per connection login 
> credentials in failover scenarios. 



--
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-373) Support for OAuth flow and setting of "Authorization" Header for WS upgrade request

2018-04-25 Thread Timothy Bish (JIRA)


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

Timothy Bish commented on QPIDJMS-373:
--

You can now add callbacks that will be executed on each connection via 
QPIDJMS-384 which allows for this sort of thing.  The HTTP Headers used on WS 
handshaking can be updated now and an example is added in this [test 
case.|https://github.com/apache/qpid-jms/blob/master/qpid-jms-client/src/test/java/org/apache/qpid/jms/transports/netty/NettyTcpToMockServerTest.java#L303]

 

 

> Support for OAuth flow and setting of "Authorization" Header for WS upgrade 
> request
> ---
>
> Key: QPIDJMS-373
> URL: https://issues.apache.org/jira/browse/QPIDJMS-373
> Project: Qpid JMS
>  Issue Type: New Feature
>  Components: qpid-jms-client
>Reporter: Michael Bolz
>Priority: Major
>
> Add support for OAuth flow ("client_credentials" and "password") (-and 
> setting of "Authorization" Header- moved into 
> [QPIDJMS-375|https://issues.apache.org/jira/browse/QPIDJMS-375]) during 
> WebSocket connection handshake.
> -Used "Authorization" Header or OAuth settings should/could be set via the 
> "transport" parameters (TransportOptions).- (see above)
>  
> As PoC I created a [Fork|https://github.com/mibo/qpid-jms/tree/ws_add_header] 
> and have done one commit for the [add of the Authorization 
> Header|https://github.com/mibo/qpid-jms/commit/711052f0891556db0da6e7d68908b2f9dafadede]
>  and one commit for the [OAuth 
> flow|https://github.com/mibo/qpid-jms/commit/de70f0d3e4441358a239b3e776455201c133895d].
>  
> Hope this feature is not only interesting for me.
> If yes, I will add the currently missing tests to my contribution and do a 
> pull request.
>  
> Regards, Michael



--
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-1835) [Python binding] Use of Python dict for AMQP maps does not allow derived or related keys of the same value

2018-04-25 Thread Kim van der Riet (JIRA)


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

Kim van der Riet updated PROTON-1835:
-
Description: 
The AMQP map (expressed as a list) {{[binary(123), "hello", decimal128(123), 
"world"]}} cannot be implemented in Python using the {{dict}} type. This 
happens because {{proton.decimal}} is derived from {{bytes}}, and the 
dictionary treats the keys as the same value and causes the first value to be 
overwritten by the second:
{noformat}
>>> import proton
>>> {b'123': 'hello', proton.decimal128(b'123'): 'world'}
{'123': 'world'}
{noformat}
Using the {{[]}} operator to add the values one at a time to an empty {{dict}} 
results in the same outcome. Even using related classes (ie both derived from a 
common parent) don't work:
{noformat}
>>> import proton
>>> class mybin(bytes):
... def __repr__(self):
... return 'mybin(%s)' % bytes.__repr__(self)
... 
>>> {mybin(b'123'): 'hello', proton.decimal128(b'123'): 'world'}
{mybin('123'): 'world'}
{noformat}
 

  was:
The AMQP map (expressed as a list) {{[binary(123), "hello", decimal128(123), 
"world"]}} cannot be implemented in Python using the {{dict}} type. This 
happens because {{proton.decimal}} is derived from {{bytes}}, and the 
dictionary treats the keys as the same value and causes the first value to be 
overwritten by the second:
{noformat}
>>> import proton
>>> {b'123': 'hello', proton.decimal128(b'123'): 'world'}
{'123': 'world'}
{noformat}
Using the {{[]}} operator to add the values one at a time to an empty {{dict}} 
results in the same outcome. Even using related classes (ie both derived from a 
common parent) don't work:
{noformat}
>>> import proton
>>> class mybin(bytes):
... def __repr__(self):
... return 'mybin(%s)' % bytes.__repr__(self)
... 
>>> {mybin(b'123'): 'hello', proton.decimal128(b'123'): 'world'}
{mybin('123'): 'world'}
{noformat}
This issue highlights that the Python {{dict}} type is not suitable for 
representing AMQP maps. In addition, dicts do not guarantee ordering of the 
elements (although other Python classes such as {{collections.OrderedDict}} 
do). Solving this issue will probably require re-implementing the way AMQP maps 
are represented.


> [Python binding] Use of Python dict for AMQP maps does not allow derived or 
> related keys of the same value
> --
>
> Key: PROTON-1835
> URL: https://issues.apache.org/jira/browse/PROTON-1835
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Reporter: Kim van der Riet
>Priority: Major
>
> The AMQP map (expressed as a list) {{[binary(123), "hello", decimal128(123), 
> "world"]}} cannot be implemented in Python using the {{dict}} type. This 
> happens because {{proton.decimal}} is derived from {{bytes}}, and the 
> dictionary treats the keys as the same value and causes the first value to be 
> overwritten by the second:
> {noformat}
> >>> import proton
> >>> {b'123': 'hello', proton.decimal128(b'123'): 'world'}
> {'123': 'world'}
> {noformat}
> Using the {{[]}} operator to add the values one at a time to an empty 
> {{dict}} results in the same outcome. Even using related classes (ie both 
> derived from a common parent) don't work:
> {noformat}
> >>> import proton
> >>> class mybin(bytes):
> ... def __repr__(self):
> ... return 'mybin(%s)' % bytes.__repr__(self)
> ... 
> >>> {mybin(b'123'): 'hello', proton.decimal128(b'123'): 'world'}
> {mybin('123'): 'world'}
> {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] (PROTON-1834) [C++ binding] equality operator used on nested lists causes SIGABRT

2018-04-25 Thread Kim van der Riet (JIRA)


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

Kim van der Riet updated PROTON-1834:
-
Summary: [C++ binding] equality operator used on nested lists causes 
SIGABRT  (was: [C++ binding] equality operator of nested lists causes SIGABRT)

> [C++ binding] equality operator used on nested lists causes SIGABRT
> ---
>
> Key: PROTON-1834
> URL: https://issues.apache.org/jira/browse/PROTON-1834
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Reporter: Kim van der Riet
>Priority: Major
> Attachments: test1.cpp
>
>
> Checking the equality of nested list {{[[], [3, "hello"]]}} causes a core 
> dump. However, if the list (as a {{proton::value}}) is created and checked 
> against itself, it works fine. However, if the list is assigned to a message 
> body and then compared with the original, then the equality cores. The 
> following is dumped from the attached reproducer:
> {noformat}
> #0  0x7f37f7bc7660 in raise () from /lib64/libc.so.6
> #1  0x7f37f7bc8c41 in abort () from /lib64/libc.so.6
> #2  0x7f37f853d025 in __gnu_cxx::__verbose_terminate_handler() () from 
> /lib64/libstdc++.so.6
> #3  0x7f37f853ac16 in __cxxabiv1::__terminate(void (*)()) () from 
> /lib64/libstdc++.so.6
> #4  0x7f37f853ac61 in std::terminate() () from /lib64/libstdc++.so.6
> #5  0x7f37f853aea4 in __cxa_throw () from /lib64/libstdc++.so.6
> #6  0x7f37f8caaa2b in proton::codec::decoder::pre_get 
> (this=this@entry=0x7fff4b7a6340) at 
> /home/kvdr/RedHat/qpid-proton/cpp/src/decoder.cpp:76
> #7  0x7f37f8c7 in proton::codec::decoder::next_type 
> (this=this@entry=0x7fff4b7a6340) at 
> /home/kvdr/RedHat/qpid-proton/cpp/src/decoder.cpp:104
> #8  0x7f37f8cbce39 in proton::(anonymous namespace)::compare_next (a=..., 
> b=...) at /home/kvdr/RedHat/qpid-proton/cpp/src/value.cpp:113
> #9  0x7f37f8cbd79b in proton::(anonymous namespace)::compare_container 
> (b=..., a=...) at /home/kvdr/RedHat/qpid-proton/cpp/src/value.cpp:97
> #10 proton::(anonymous namespace)::compare_next (a=..., b=...) at 
> /home/kvdr/RedHat/qpid-proton/cpp/src/value.cpp:123
> #11 0x7f37f8cbd937 in proton::(anonymous namespace)::compare (x=..., 
> y=...) at /home/kvdr/RedHat/qpid-proton/cpp/src/value.cpp:163
> #12 0x7f37f8cbdda7 in proton::operator== (x=..., y=...) at 
> /home/kvdr/RedHat/qpid-proton/cpp/src/value.cpp:176
> #13 0x0040169d in main ()
> {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] [Resolved] (QPIDJMS-375) Enable setting of an "Authorization" Header during WebSocket connection handshake.

2018-04-25 Thread Timothy Bish (JIRA)


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

Timothy Bish resolved QPIDJMS-375.
--
   Resolution: Fixed
 Assignee: Timothy Bish
Fix Version/s: 0.32.0

QPIDJMS-384 Adds features that allow for this by using URI configuration or by 
injecting a callback function that provides the HTTP headers to the WS 
Transport.

The URI can be configured via options such as 
"transport.ws.httpHeader.Authorization=FOO"

> Enable setting of an "Authorization" Header during WebSocket connection 
> handshake.
> --
>
> Key: QPIDJMS-375
> URL: https://issues.apache.org/jira/browse/QPIDJMS-375
> Project: Qpid JMS
>  Issue Type: New Feature
>  Components: qpid-jms-client
>Reporter: Michael Bolz
>Assignee: Timothy Bish
>Priority: Major
> Fix For: 0.32.0
>
>
> Add support for setting of an "Authorization" Header during WebSocket 
> connection handshake.
> This "Authorization" Header will be passed via the "transport" parameters 
> (TransportOptions).
> Proposed transport is {{transport.ws.authorizationHeader}}.
> According "[Pull Request|https://github.com/apache/qpid-jms/pull/18];



--
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-384) Add support for user user defined extensions to override client configuration

2018-04-25 Thread ASF subversion and git services (JIRA)


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

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

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

QPIDJMS-384 Allow for extensions to provide information to the connection

Create an extension mechanism where the user can supply functions that are
called at various point in the connection lifecylce to supply or override
conifguration based on user needs.

This closes #18


> Add support for user user defined extensions to override client configuration
> -
>
> Key: QPIDJMS-384
> URL: https://issues.apache.org/jira/browse/QPIDJMS-384
> Project: Qpid JMS
>  Issue Type: Improvement
>  Components: qpid-jms-client
>Affects Versions: 0.31.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Major
> Fix For: 0.32.0
>
>
> Implement a means of injecting user defined configuration overrides that 
> allow the client to query user code to obtain various configuration values 
> such as HTTP headers for WebSocket authentication of per connection login 
> credentials in failover scenarios. 



--
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-375) Enable setting of an "Authorization" Header during WebSocket connection handshake.

2018-04-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on QPIDJMS-375:


Github user asfgit closed the pull request at:

https://github.com/apache/qpid-jms/pull/18


> Enable setting of an "Authorization" Header during WebSocket connection 
> handshake.
> --
>
> Key: QPIDJMS-375
> URL: https://issues.apache.org/jira/browse/QPIDJMS-375
> Project: Qpid JMS
>  Issue Type: New Feature
>  Components: qpid-jms-client
>Reporter: Michael Bolz
>Priority: Major
>
> Add support for setting of an "Authorization" Header during WebSocket 
> connection handshake.
> This "Authorization" Header will be passed via the "transport" parameters 
> (TransportOptions).
> Proposed transport is {{transport.ws.authorizationHeader}}.
> According "[Pull Request|https://github.com/apache/qpid-jms/pull/18];



--
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-jms pull request #18: QPIDJMS-375: Added transport.ws.authorizationHead...

2018-04-25 Thread asfgit

Github user asfgit closed the pull request at:

https://github.com/apache/qpid-jms/pull/18


---

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

[jira] [Created] (QPIDJMS-384) Add support for user user defined extensions to override client configuration

2018-04-25 Thread Timothy Bish (JIRA)

Timothy Bish created QPIDJMS-384:


 Summary: Add support for user user defined extensions to override 
client configuration
 Key: QPIDJMS-384
 URL: https://issues.apache.org/jira/browse/QPIDJMS-384
 Project: Qpid JMS
  Issue Type: Improvement
  Components: qpid-jms-client
Affects Versions: 0.31.0
Reporter: Timothy Bish
Assignee: Timothy Bish
 Fix For: 0.32.0


Implement a means of injecting user defined configuration overrides that allow 
the client to query user code to obtain various configuration values such as 
HTTP headers for WebSocket authentication of per connection login credentials 
in failover scenarios. 



--
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-977) Document transaction support

2018-04-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on DISPATCH-977:
-

Github user grs commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/293#discussion_r184128463
  
--- Diff: doc/new-book/routing.adoc ---
@@ -575,6 +575,20 @@ connector {
 For information about additional attributes, see 
link:{qdrouterdConfManPageUrl}#_connector[connector] in the `qdrouterd.conf` 
man page.
 --
 
+. If you want clients to send local transactions to the broker, create a 
link route for the transaction coordinator:
--- End diff --

One thing I think needs to be clear is that routing the coordinator really 
only works if there is only one broker with which any transactional 
interactions are undertaken.


> Document transaction support
> 
>
> Key: DISPATCH-977
> URL: https://issues.apache.org/jira/browse/DISPATCH-977
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Documentation
>Reporter: Ben Hardesty
>Assignee: Ben Hardesty
>Priority: Major
>
> Dispatch Router provides transaction support through link routes and 
> $coordinator. This capability should be documented.



--
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 #293: DISPATCH-977: Add transaction coordinator s...

2018-04-25 Thread grs

Github user grs commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/293#discussion_r184128463
  
--- Diff: doc/new-book/routing.adoc ---
@@ -575,6 +575,20 @@ connector {
 For information about additional attributes, see 
link:{qdrouterdConfManPageUrl}#_connector[connector] in the `qdrouterd.conf` 
man page.
 --
 
+. If you want clients to send local transactions to the broker, create a 
link route for the transaction coordinator:
--- End diff --

One thing I think needs to be clear is that routing the coordinator really 
only works if there is only one broker with which any transactional 
interactions are undertaken.


---

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

[jira] [Commented] (DISPATCH-977) Document transaction support

2018-04-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on DISPATCH-977:
-

Github user grs commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/293#discussion_r184127780
  
--- Diff: doc/new-book/routing.adoc ---
@@ -575,6 +575,20 @@ connector {
 For information about additional attributes, see 
link:{qdrouterdConfManPageUrl}#_connector[connector] in the `qdrouterd.conf` 
man page.
 --
 
+. If you want clients to send local transactions to the broker, create a 
link route for the transaction coordinator:
++
+--
+[options="nowrap",subs="+quotes"]
+
+linkRoute {
+prefix: $coordinator  <1>
+connection: __CONNECTOR_NAME__
+direction: in
+}
+
+<1> The `$coordinator` prefix designates this link route as a transaction 
coordinator. When the client opens a transacted session, the transactional 
state is propagated along this link route to the broker.
--- End diff --

The coordinator link is used for declaring and completing (committing or 
rolling back) the transactions. In the AMQP spec, the term 'transactional 
state' is used to tie the publication and consumption of messages to a given 
transaction, and is part of the transfer or disposition - loosely the message 
or its acknowledgement - which do not go over the coordinator link.

Perhaps it would be less (potentially) confusing to change from 'the 
transactional state is propagated along this link route to the broker' to 
'requests to start or end a transaction are propagated along this link route to 
the broker.' ??


> Document transaction support
> 
>
> Key: DISPATCH-977
> URL: https://issues.apache.org/jira/browse/DISPATCH-977
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Documentation
>Reporter: Ben Hardesty
>Assignee: Ben Hardesty
>Priority: Major
>
> Dispatch Router provides transaction support through link routes and 
> $coordinator. This capability should be documented.



--
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 #293: DISPATCH-977: Add transaction coordinator s...

2018-04-25 Thread grs

Github user grs commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/293#discussion_r184127780
  
--- Diff: doc/new-book/routing.adoc ---
@@ -575,6 +575,20 @@ connector {
 For information about additional attributes, see 
link:{qdrouterdConfManPageUrl}#_connector[connector] in the `qdrouterd.conf` 
man page.
 --
 
+. If you want clients to send local transactions to the broker, create a 
link route for the transaction coordinator:
++
+--
+[options="nowrap",subs="+quotes"]
+
+linkRoute {
+prefix: $coordinator  <1>
+connection: __CONNECTOR_NAME__
+direction: in
+}
+
+<1> The `$coordinator` prefix designates this link route as a transaction 
coordinator. When the client opens a transacted session, the transactional 
state is propagated along this link route to the broker.
--- End diff --

The coordinator link is used for declaring and completing (committing or 
rolling back) the transactions. In the AMQP spec, the term 'transactional 
state' is used to tie the publication and consumption of messages to a given 
transaction, and is part of the transfer or disposition - loosely the message 
or its acknowledgement - which do not go over the coordinator link.

Perhaps it would be less (potentially) confusing to change from 'the 
transactional state is propagated along this link route to the broker' to 
'requests to start or end a transaction are propagated along this link route to 
the broker.' ??


---

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

[jira] [Commented] (DISPATCH-977) Document transaction support

2018-04-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on DISPATCH-977:
-

Github user bhardesty commented on the issue:

https://github.com/apache/qpid-dispatch/pull/293
  
@grs could you please review this doc update for technical accuracy? This 
just adds an additional step to the procedure for creating a link route (to 
optionally configure the link route to support transacted messages).


> Document transaction support
> 
>
> Key: DISPATCH-977
> URL: https://issues.apache.org/jira/browse/DISPATCH-977
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Documentation
>Reporter: Ben Hardesty
>Assignee: Ben Hardesty
>Priority: Major
>
> Dispatch Router provides transaction support through link routes and 
> $coordinator. This capability should be documented.



--
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 #293: DISPATCH-977: Add transaction coordinator step to ...

2018-04-25 Thread bhardesty

Github user bhardesty commented on the issue:

https://github.com/apache/qpid-dispatch/pull/293
  
@grs could you please review this doc update for technical accuracy? This 
just adds an additional step to the procedure for creating a link route (to 
optionally configure the link route to support transacted messages).


---

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

[jira] [Commented] (DISPATCH-977) Document transaction support

2018-04-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on DISPATCH-977:
-

GitHub user bhardesty opened a pull request:

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

DISPATCH-977: Add transaction coordinator step to link routing procedure

The Dispatch Router doc mentions that you can use link routing for 
transactions, but it didn't describe how to configure this. 

This doc update describes how to configure a link route that supports 
transactions.

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

$ git pull https://github.com/bhardesty/qpid-dispatch 
dispatch-977-doc-transaction-support

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

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


commit 3d20e9ed9cbf0011b24caabc74a24839613a47dc
Author: Ben Hardesty 
Date:   2018-04-24T21:18:58Z

Add transaction coordinator step to link routing procedure




> Document transaction support
> 
>
> Key: DISPATCH-977
> URL: https://issues.apache.org/jira/browse/DISPATCH-977
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Documentation
>Reporter: Ben Hardesty
>Assignee: Ben Hardesty
>Priority: Major
>
> Dispatch Router provides transaction support through link routes and 
> $coordinator. This capability should be documented.



--
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 #293: DISPATCH-977: Add transaction coordinator s...

2018-04-25 Thread bhardesty

GitHub user bhardesty opened a pull request:

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

DISPATCH-977: Add transaction coordinator step to link routing procedure

The Dispatch Router doc mentions that you can use link routing for 
transactions, but it didn't describe how to configure this. 

This doc update describes how to configure a link route that supports 
transactions.

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

$ git pull https://github.com/bhardesty/qpid-dispatch 
dispatch-977-doc-transaction-support

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

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


commit 3d20e9ed9cbf0011b24caabc74a24839613a47dc
Author: Ben Hardesty 
Date:   2018-04-24T21:18:58Z

Add transaction coordinator step to link routing procedure




---

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

[jira] [Commented] (PROTON-1835) [Python binding] Use of Python dict for AMQP maps does not allow derived or related keys of the same value

2018-04-25 Thread Kim van der Riet (JIRA)


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

Kim van der Riet commented on PROTON-1835:
--

This can be solved by defining {{__eq__()}} functions for each of the derived 
classes. This is illustrated here with a similar test class {{mybin}}:
{noformat}
>>> import proton
>>> proton.decimal128(b'123') == b'123'
True
>>> 
>>> class mybin(bytes):
... def __repr__(self):
... return 'mybin(%s)' % bytes.__repr__(self)
... def __eq__(self, other):
... if type(self) == type(other):
... return self == other
... else:
... return False
>>> mybin(b'123') == b'123'
False
>>> {mybin(b'123'): 'hello', b'123': 'world'}
{'123': 'world', mybin('123'): 'hello'}{noformat}

> [Python binding] Use of Python dict for AMQP maps does not allow derived or 
> related keys of the same value
> --
>
> Key: PROTON-1835
> URL: https://issues.apache.org/jira/browse/PROTON-1835
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Reporter: Kim van der Riet
>Priority: Major
>
> The AMQP map (expressed as a list) {{[binary(123), "hello", decimal128(123), 
> "world"]}} cannot be implemented in Python using the {{dict}} type. This 
> happens because {{proton.decimal}} is derived from {{bytes}}, and the 
> dictionary treats the keys as the same value and causes the first value to be 
> overwritten by the second:
> {noformat}
> >>> import proton
> >>> {b'123': 'hello', proton.decimal128(b'123'): 'world'}
> {'123': 'world'}
> {noformat}
> Using the {{[]}} operator to add the values one at a time to an empty 
> {{dict}} results in the same outcome. Even using related classes (ie both 
> derived from a common parent) don't work:
> {noformat}
> >>> import proton
> >>> class mybin(bytes):
> ... def __repr__(self):
> ... return 'mybin(%s)' % bytes.__repr__(self)
> ... 
> >>> {mybin(b'123'): 'hello', proton.decimal128(b'123'): 'world'}
> {mybin('123'): 'world'}
> {noformat}
> This issue highlights that the Python {{dict}} type is not suitable for 
> representing AMQP maps. In addition, dicts do not guarantee ordering of the 
> elements (although other Python classes such as {{collections.OrderedDict}} 
> do). Solving this issue will probably require re-implementing the way AMQP 
> maps are represented.



--
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-1835) [Python binding] Use of Python dict for AMQP maps does not allow derived or related keys of the same value

2018-04-25 Thread Kim van der Riet (JIRA)


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

Kim van der Riet commented on PROTON-1835:
--

The above uses unusual types, but the same is true of more common types:
{noformat}
>>> import proton
>>> {proton.ubyte(2): 'A', proton.ushort(2): 'b'}
{ubyte(2): 'b'}
>>> {u'A': 100, proton.symbol(u'A'): 200}
{u'A': 200}
{noformat}

> [Python binding] Use of Python dict for AMQP maps does not allow derived or 
> related keys of the same value
> --
>
> Key: PROTON-1835
> URL: https://issues.apache.org/jira/browse/PROTON-1835
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Reporter: Kim van der Riet
>Priority: Major
>
> The AMQP map (expressed as a list) {{[binary(123), "hello", decimal128(123), 
> "world"]}} cannot be implemented in Python using the {{dict}} type. This 
> happens because {{proton.decimal}} is derived from {{bytes}}, and the 
> dictionary treats the keys as the same value and causes the first value to be 
> overwritten by the second:
> {noformat}
> >>> import proton
> >>> {b'123': 'hello', proton.decimal128(b'123'): 'world'}
> {'123': 'world'}
> {noformat}
> Using the {{[]}} operator to add the values one at a time to an empty 
> {{dict}} results in the same outcome. Even using related classes (ie both 
> derived from a common parent) don't work:
> {noformat}
> >>> import proton
> >>> class mybin(bytes):
> ... def __repr__(self):
> ... return 'mybin(%s)' % bytes.__repr__(self)
> ... 
> >>> {mybin(b'123'): 'hello', proton.decimal128(b'123'): 'world'}
> {mybin('123'): 'world'}
> {noformat}
> This issue highlights that the Python {{dict}} type is not suitable for 
> representing AMQP maps. In addition, dicts do not guarantee ordering of the 
> elements (although other Python classes such as {{collections.OrderedDict}} 
> do). Solving this issue will probably require re-implementing the way AMQP 
> maps are represented.



--
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-1835) [Python binding] Use of Python dict for AMQP maps does not allow derived or related keys of the same value

2018-04-25 Thread Kim van der Riet (JIRA)


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

Kim van der Riet updated PROTON-1835:
-
Description: 
The AMQP map (expressed as a list) {{[binary(123), "hello", decimal128(123), 
"world"]}} cannot be implemented in Python using the {{dict}} type. This 
happens because {{proton.decimal}} is derived from {{bytes}}, and the 
dictionary treats the keys as the same value and causes the first value to be 
overwritten by the second:
{noformat}
>>> import proton
>>> {b'123': 'hello', proton.decimal128(b'123'): 'world'}
{'123': 'world'}
{noformat}
Using the {{[]}} operator to add the values one at a time to an empty {{dict}} 
results in the same outcome. Even using related classes (ie both derived from a 
common parent) don't work:
{noformat}
>>> import proton
>>> class mybin(bytes):
... def __repr__(self):
... return 'mybin(%s)' % bytes.__repr__(self)
... 
>>> {mybin(b'123'): 'hello', proton.decimal128(b'123'): 'world'}
{mybin('123'): 'world'}
{noformat}
This issue highlights that the Python {{dict}} type is not suitable for 
representing AMQP maps. In addition, dicts do not guarantee ordering of the 
elements (although other Python classes such as {{collections.OrderedDict}} 
do). Solving this issue will probably require re-implementing the way AMQP maps 
are represented.

  was:
The AMQP map (expressed as a list) {{[binary(123), "hello", decimal128(123), 
"world"]}} cannot be implemented in Python using the {{dict}} type. This 
happens because {{proton.decimal}} is derived from {{bytes}}, and the 
dictionary treats the keys as the same value and causes the first value to be 
overwritten by the second:
{noformat}
>>> import proton
>>> {b'123': 'hello', proton.decimal128(b'123'): 'world'}
{'123': 'world'}
{noformat}
Using the {{[]}} operator to add the values one at a time to an empty {{dict}} 
results in the same outcome. Even using related classes (ie both derived from a 
common parent) don't work:
{noformat}
>>> import proton
>>> class mybin(bytes):
... def __repr__(self):
... return 'mybin(%s)' % bytes.__repr__(self)
... 
>>> {mybin(b'123'): 'hello', proton.decimal128(b'123'): 'world'}
{mybin('123'): 'world'}
{noformat}
This issue highlights that the Python {{dict}} type is not suitable for 
representing AMQP maps. In addition, {{dict}}s do not guarantee ordering of the 
elements (although other Python classes such as {{collections.OrderedDict}} 
do). Solving this issue will probably require re-implementing the way AMQP maps 
are represented.


> [Python binding] Use of Python dict for AMQP maps does not allow derived or 
> related keys of the same value
> --
>
> Key: PROTON-1835
> URL: https://issues.apache.org/jira/browse/PROTON-1835
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Reporter: Kim van der Riet
>Priority: Major
>
> The AMQP map (expressed as a list) {{[binary(123), "hello", decimal128(123), 
> "world"]}} cannot be implemented in Python using the {{dict}} type. This 
> happens because {{proton.decimal}} is derived from {{bytes}}, and the 
> dictionary treats the keys as the same value and causes the first value to be 
> overwritten by the second:
> {noformat}
> >>> import proton
> >>> {b'123': 'hello', proton.decimal128(b'123'): 'world'}
> {'123': 'world'}
> {noformat}
> Using the {{[]}} operator to add the values one at a time to an empty 
> {{dict}} results in the same outcome. Even using related classes (ie both 
> derived from a common parent) don't work:
> {noformat}
> >>> import proton
> >>> class mybin(bytes):
> ... def __repr__(self):
> ... return 'mybin(%s)' % bytes.__repr__(self)
> ... 
> >>> {mybin(b'123'): 'hello', proton.decimal128(b'123'): 'world'}
> {mybin('123'): 'world'}
> {noformat}
> This issue highlights that the Python {{dict}} type is not suitable for 
> representing AMQP maps. In addition, dicts do not guarantee ordering of the 
> elements (although other Python classes such as {{collections.OrderedDict}} 
> do). Solving this issue will probably require re-implementing the way AMQP 
> maps are represented.



--
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-1835) [Python binding] Use of Python dict for AMQP maps does not allow derived or related keys of the same value

2018-04-25 Thread Kim van der Riet (JIRA)


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

Kim van der Riet updated PROTON-1835:
-
Description: 
The AMQP map (expressed as a list) {{[binary(123), "hello", decimal128(123), 
"world"]}} cannot be implemented in Python using the {{dict}} type. This 
happens because {{proton.decimal}} is derived from {{bytes}}, and the 
dictionary treats the keys as the same value and causes the first value to be 
overwritten by the second:
{noformat}
>>> import proton
>>> {b'123': 'hello', proton.decimal128(b'123'): 'world'}
{'123': 'world'}
{noformat}
Using the {{[]}} operator to add the values one at a time to an empty {{dict}} 
results in the same outcome. Even using related classes (ie both derived from a 
common parent) don't work:
{noformat}
>>> import proton
>>> class mybin(bytes):
... def __repr__(self):
... return 'mybin(%s)' % bytes.__repr__(self)
... 
>>> {mybin(b'123'): 'hello', proton.decimal128(b'123'): 'world'}
{mybin('123'): 'world'}
{noformat}
This issue highlights that the Python {{dict}} type is not suitable for 
representing AMQP maps. In addition, {{dict}}s do not guarantee ordering of the 
elements (although other Python classes such as {{collections.OrderedDict}} 
do). Solving this issue will probably require re-implementing the way AMQP maps 
are represented.

  was:
The AMQP map (expressed as a list) {{[binary(123), "hello", decimal128(123), 
"world"]}} cannot be implemented in Python using the {{dict}} type. This 
happens because {{proton.decimal}} is derived from {{bytes}}, and the 
dictionary treats the keys as the same value and causes the first value to be 
overwritten by the second:
{noformat}
>>> import proton
>>> {b'123': 'hello', proton.decimal128(b'123'): 'world'}
{'123': 'world'}
{noformat}
Using the [] operator to add the values one at a time to an empty {{dict}} 
results in the same outcome. Even using related classes (ie both derived from a 
common parent) don't work:
{noformat}
>>> import proton
>>> class mybin(bytes):
... def __repr__(self):
... return 'mybin(%s)' % bytes.__repr__(self)
... 
>>> {mybin(b'123'): 'hello', proton.decimal128(b'123'): 'world'}
{mybin('123'): 'world'}
{noformat}
This issue highlights that the Python {{dict}} type is not suitable for 
representing AMQP maps. In addition, {{dict}}s do not guarantee ordering of the 
elements (although other Python classes such as {{collections.OrderedDict}} 
do). Solving this issue will probably require re-implementing the way AMQP maps 
are represented.


> [Python binding] Use of Python dict for AMQP maps does not allow derived or 
> related keys of the same value
> --
>
> Key: PROTON-1835
> URL: https://issues.apache.org/jira/browse/PROTON-1835
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Reporter: Kim van der Riet
>Priority: Major
>
> The AMQP map (expressed as a list) {{[binary(123), "hello", decimal128(123), 
> "world"]}} cannot be implemented in Python using the {{dict}} type. This 
> happens because {{proton.decimal}} is derived from {{bytes}}, and the 
> dictionary treats the keys as the same value and causes the first value to be 
> overwritten by the second:
> {noformat}
> >>> import proton
> >>> {b'123': 'hello', proton.decimal128(b'123'): 'world'}
> {'123': 'world'}
> {noformat}
> Using the {{[]}} operator to add the values one at a time to an empty 
> {{dict}} results in the same outcome. Even using related classes (ie both 
> derived from a common parent) don't work:
> {noformat}
> >>> import proton
> >>> class mybin(bytes):
> ... def __repr__(self):
> ... return 'mybin(%s)' % bytes.__repr__(self)
> ... 
> >>> {mybin(b'123'): 'hello', proton.decimal128(b'123'): 'world'}
> {mybin('123'): 'world'}
> {noformat}
> This issue highlights that the Python {{dict}} type is not suitable for 
> representing AMQP maps. In addition, {{dict}}s do not guarantee ordering of 
> the elements (although other Python classes such as 
> {{collections.OrderedDict}} do). Solving this issue will probably require 
> re-implementing the way AMQP maps are represented.



--
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-1835) [Python binding] Use of Python dict for AMQP maps does not allow derived or related keys of the same value

2018-04-25 Thread Kim van der Riet (JIRA)


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

Kim van der Riet updated PROTON-1835:
-
Description: 
The AMQP map (expressed as a list) {{[binary(123), "hello", decimal128(123), 
"world"]}} cannot be implemented in Python using the {{dict}} type. This 
happens because {{proton.decimal}} is derived from {{bytes}}, and the 
dictionary treats the keys as the same value and causes the first value to be 
overwritten by the second:
{noformat}
>>> import proton
>>> {b'123': 'hello', proton.decimal128(b'123'): 'world'}
{'123': 'world'}
{noformat}
Using the [] operator to add the values one at a time to an empty {{dict}} 
results in the same outcome. Even using related classes (ie both derived from a 
common parent) don't work:
{noformat}
>>> import proton
>>> class mybin(bytes):
... def __repr__(self):
... return 'mybin(%s)' % bytes.__repr__(self)
... 
>>> {mybin(b'123'): 'hello', proton.decimal128(b'123'): 'world'}
{mybin('123'): 'world'}
{noformat}
This issue highlights that the Python {{dict}} type is not suitable for 
representing AMQP maps. In addition, {{dict}}s do not guarantee ordering of the 
elements (although other Python classes such as {{collections.OrderedDict}} 
do). Solving this issue will probably require re-implementing the way AMQP maps 
are represented.

  was:
The AMQP map (expressed as a list) {{[binary(123), "hello", decimal128(123), 
"world"]}} cannot be implemented in Python using the {{dict}} type. This 
happens because {{proton.decimal}} is derived from {{bytes}}, and the 
dictionary treats them as the same value and causes the first value to be 
overwritten by the second:
{noformat}
>>> import proton
>>> {b'123': 'hello', proton.decimal128(b'123'): 'world'}
{'123': 'world'}
{noformat}
Using the [] operator to add the values one at a time to an empty {{dict}} 
results in the same outcome. Even using related classes (ie both derived from a 
common parent) don't work:
{noformat}
>>> import proton
>>> class mybin(bytes):
... def __repr__(self):
... return 'mybin(%s)' % bytes.__repr__(self)
... 
>>> {mybin(b'123'): 'hello', proton.decimal128(b'123'): 'world'}
{mybin('123'): 'world'}
{noformat}
This issue highlights that the Python {{dict}} type is not suitable for 
representing AMQP maps. In addition, {{dict}}s do not guarantee ordering of the 
elements (although other Python classes such as {{collections.OrderedDict}} 
do). Solving this issue will probably require re-implementing the way AMQP maps 
are represented.


> [Python binding] Use of Python dict for AMQP maps does not allow derived or 
> related keys of the same value
> --
>
> Key: PROTON-1835
> URL: https://issues.apache.org/jira/browse/PROTON-1835
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Reporter: Kim van der Riet
>Priority: Major
>
> The AMQP map (expressed as a list) {{[binary(123), "hello", decimal128(123), 
> "world"]}} cannot be implemented in Python using the {{dict}} type. This 
> happens because {{proton.decimal}} is derived from {{bytes}}, and the 
> dictionary treats the keys as the same value and causes the first value to be 
> overwritten by the second:
> {noformat}
> >>> import proton
> >>> {b'123': 'hello', proton.decimal128(b'123'): 'world'}
> {'123': 'world'}
> {noformat}
> Using the [] operator to add the values one at a time to an empty {{dict}} 
> results in the same outcome. Even using related classes (ie both derived from 
> a common parent) don't work:
> {noformat}
> >>> import proton
> >>> class mybin(bytes):
> ... def __repr__(self):
> ... return 'mybin(%s)' % bytes.__repr__(self)
> ... 
> >>> {mybin(b'123'): 'hello', proton.decimal128(b'123'): 'world'}
> {mybin('123'): 'world'}
> {noformat}
> This issue highlights that the Python {{dict}} type is not suitable for 
> representing AMQP maps. In addition, {{dict}}s do not guarantee ordering of 
> the elements (although other Python classes such as 
> {{collections.OrderedDict}} do). Solving this issue will probably require 
> re-implementing the way AMQP maps are represented.



--
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-1835) [Python binding] Use of Python dict for AMQP maps does not allow derived or related keys of the same value

2018-04-25 Thread Kim van der Riet (JIRA)

Kim van der Riet created PROTON-1835:


 Summary: [Python binding] Use of Python dict for AMQP maps does 
not allow derived or related keys of the same value
 Key: PROTON-1835
 URL: https://issues.apache.org/jira/browse/PROTON-1835
 Project: Qpid Proton
  Issue Type: Bug
  Components: python-binding
Reporter: Kim van der Riet


The AMQP map (expressed as a list) {{[binary(123), "hello", decimal128(123), 
"world"]}} cannot be implemented in Python using the {{dict}} type. This 
happens because {{proton.decimal}} is derived from {{bytes}}, and the 
dictionary treats them as the same value and causes the first value to be 
overwritten by the second:
{noformat}
>>> import proton
>>> {b'123': 'hello', proton.decimal128(b'123'): 'world'}
{'123': 'world'}
{noformat}
Using the [] operator to add the values one at a time to an empty {{dict}} 
results in the same outcome. Even using related classes (ie both derived from a 
common parent) don't work:
{noformat}
>>> import proton
>>> class mybin(bytes):
... def __repr__(self):
... return 'mybin(%s)' % bytes.__repr__(self)
... 
>>> {mybin(b'123'): 'hello', proton.decimal128(b'123'): 'world'}
{mybin('123'): 'world'}
{noformat}
This issue highlights that the Python {{dict}} type is not suitable for 
representing AMQP maps. In addition, {{dict}}s do not guarantee ordering of the 
elements (although other Python classes such as {{collections.OrderedDict}} 
do). Solving this issue will probably require re-implementing the way AMQP maps 
are represented.



--
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-1834) [C++ binding] equality operator of nested lists causes SIGABRT

2018-04-25 Thread Kim van der Riet (JIRA)

Kim van der Riet created PROTON-1834:


 Summary: [C++ binding] equality operator of nested lists causes 
SIGABRT
 Key: PROTON-1834
 URL: https://issues.apache.org/jira/browse/PROTON-1834
 Project: Qpid Proton
  Issue Type: Bug
  Components: cpp-binding
Reporter: Kim van der Riet
 Attachments: test1.cpp

Checking the equality of nested list {{[[], [3, "hello"]]}} causes a core dump. 
However, if the list (as a {{proton::value}}) is created and checked against 
itself, it works fine. However, if the list is assigned to a message body and 
then compared with the original, then the equality cores. The following is 
dumped from the attached reproducer:
{noformat}
#0  0x7f37f7bc7660 in raise () from /lib64/libc.so.6
#1  0x7f37f7bc8c41 in abort () from /lib64/libc.so.6
#2  0x7f37f853d025 in __gnu_cxx::__verbose_terminate_handler() () from 
/lib64/libstdc++.so.6
#3  0x7f37f853ac16 in __cxxabiv1::__terminate(void (*)()) () from 
/lib64/libstdc++.so.6
#4  0x7f37f853ac61 in std::terminate() () from /lib64/libstdc++.so.6
#5  0x7f37f853aea4 in __cxa_throw () from /lib64/libstdc++.so.6
#6  0x7f37f8caaa2b in proton::codec::decoder::pre_get 
(this=this@entry=0x7fff4b7a6340) at 
/home/kvdr/RedHat/qpid-proton/cpp/src/decoder.cpp:76
#7  0x7f37f8c7 in proton::codec::decoder::next_type 
(this=this@entry=0x7fff4b7a6340) at 
/home/kvdr/RedHat/qpid-proton/cpp/src/decoder.cpp:104
#8  0x7f37f8cbce39 in proton::(anonymous namespace)::compare_next (a=..., 
b=...) at /home/kvdr/RedHat/qpid-proton/cpp/src/value.cpp:113
#9  0x7f37f8cbd79b in proton::(anonymous namespace)::compare_container 
(b=..., a=...) at /home/kvdr/RedHat/qpid-proton/cpp/src/value.cpp:97
#10 proton::(anonymous namespace)::compare_next (a=..., b=...) at 
/home/kvdr/RedHat/qpid-proton/cpp/src/value.cpp:123
#11 0x7f37f8cbd937 in proton::(anonymous namespace)::compare (x=..., y=...) 
at /home/kvdr/RedHat/qpid-proton/cpp/src/value.cpp:163
#12 0x7f37f8cbdda7 in proton::operator== (x=..., y=...) at 
/home/kvdr/RedHat/qpid-proton/cpp/src/value.cpp:176
#13 0x0040169d in main ()
{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] [Closed] (QPIDJMS-342) Missed connect error on start can lead to hung failover reconnect cycle

2018-04-25 Thread Robbie Gemmell (JIRA)


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

Robbie Gemmell closed QPIDJMS-342.
--
Resolution: Fixed

> Missed connect error on start can lead to hung failover reconnect cycle
> ---
>
> Key: QPIDJMS-342
> URL: https://issues.apache.org/jira/browse/QPIDJMS-342
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.26.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Major
> Fix For: 0.27.0
>
>
> In some cases where the jms.connectTimeout is tripped during socket level 
> connection and the failover transport bits are in use the client an fall into 
> a reconnect loop or stall waiting for an error callback that won't be 
> triggered.
> One workaround exists which is to configure the transport level socket 
> connect timeout to be lower than the jms.connectTimeout value



--
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-342) Missed connect error on start can lead to hung failover reconnect cycle

2018-04-25 Thread Robbie Gemmell (JIRA)


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

Robbie Gemmell commented on QPIDJMS-342:


Fixed the test name (found an old diff I must have forgot to push at the time), 
and updated description per Jiri's comment.

> Missed connect error on start can lead to hung failover reconnect cycle
> ---
>
> Key: QPIDJMS-342
> URL: https://issues.apache.org/jira/browse/QPIDJMS-342
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.26.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Major
> Fix For: 0.27.0
>
>
> In some cases where the jms.connectTimeout is tripped during socket level 
> connection and the failover transport bits are in use the client an fall into 
> a reconnect loop or stall waiting for an error callback that won't be 
> triggered.
> One workaround exists which is to configure the transport level socket 
> connect timeout to be lower than the jms.connectTimeout value



--
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-342) Missed connect error on start can lead to hung failover reconnect cycle

2018-04-25 Thread ASF subversion and git services (JIRA)


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

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

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

QPIDJMS-342: fix the test name


> Missed connect error on start can lead to hung failover reconnect cycle
> ---
>
> Key: QPIDJMS-342
> URL: https://issues.apache.org/jira/browse/QPIDJMS-342
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.26.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Major
> Fix For: 0.27.0
>
>
> In some cases where the jms.connectTimeout is tripped during socket level 
> connection and the failover transport bits are in use the client an fall into 
> a reconnect loop or stall waiting for an error callback that won't be 
> triggered.
> One workaround exists which is to configure the transport level socket 
> connect timeout to be lower than the jms.connectTimeout value



--
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] (QPIDJMS-342) Missed connect error on start can lead to hung failover reconnect cycle

2018-04-25 Thread Robbie Gemmell (JIRA)


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

Robbie Gemmell updated QPIDJMS-342:
---
Description: 
In some cases where the jms.connectTimeout is tripped during socket level 
connection and the failover transport bits are in use the client an fall into a 
reconnect loop or stall waiting for an error callback that won't be triggered.

One workaround exists which is to configure the transport level socket connect 
timeout to be lower than the jms.connectTimeout value

  was:
In some cases where the jms.connectTimeout is tripped during socket level 
connection and the failover transport bits are in use the client an fall into a 
reconnect loop or stall waiting for an error callback that won't be triggered.  

One workaround exists which is to configure the transport level socket connect 
timeout to be lower than the jms.connectionTimeout value


> Missed connect error on start can lead to hung failover reconnect cycle
> ---
>
> Key: QPIDJMS-342
> URL: https://issues.apache.org/jira/browse/QPIDJMS-342
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.26.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Major
> Fix For: 0.27.0
>
>
> In some cases where the jms.connectTimeout is tripped during socket level 
> connection and the failover transport bits are in use the client an fall into 
> a reconnect loop or stall waiting for an error callback that won't be 
> triggered.
> One workaround exists which is to configure the transport level socket 
> connect timeout to be lower than the jms.connectTimeout value



--
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] (QPIDJMS-342) Missed connect error on start can lead to hung failover reconnect cycle

2018-04-25 Thread Robbie Gemmell (JIRA)


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

Robbie Gemmell reopened QPIDJMS-342:


> Missed connect error on start can lead to hung failover reconnect cycle
> ---
>
> Key: QPIDJMS-342
> URL: https://issues.apache.org/jira/browse/QPIDJMS-342
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.26.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Major
> Fix For: 0.27.0
>
>
> In some cases where the jms.connectTimeout is tripped during socket level 
> connection and the failover transport bits are in use the client an fall into 
> a reconnect loop or stall waiting for an error callback that won't be 
> triggered.  
> One workaround exists which is to configure the transport level socket 
> connect timeout to be lower than the jms.connectionTimeout value



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

63 matches

Mail list logo