[jira] [Resolved] (PROTON-1604) Windows C++ prefers std::endl to newlines

[Cliff Jansen (JIRA)]

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

Cliff Jansen resolved PROTON-1604.
--
Resolution: Fixed

> Windows C++ prefers std::endl to newlines
> -
>
> Key: PROTON-1604
> URL: https://issues.apache.org/jira/browse/PROTON-1604
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: proton-c-0.18.0
> Environment: Visual Studio
>Reporter: Cliff Jansen
>Assignee: Cliff Jansen
> Fix For: proton-c-0.18.0
>
>
> Using C newline escaped char sequence can result in mysteriously missing 
> output.
> Use std::endl instead of \\n.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (PROTON-1601) windows proactor fails ipv6 target ":::5672"

[Cliff Jansen (JIRA)]

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

Cliff Jansen resolved PROTON-1601.
--
Resolution: Fixed

> windows proactor fails ipv6 target ":::5672"
> 
>
> Key: PROTON-1601
> URL: https://issues.apache.org/jira/browse/PROTON-1601
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
> Environment: windows
>Reporter: Cliff Jansen
>Assignee: Cliff Jansen
> Fix For: proton-c-0.18.0
>
>
> fails with "The format of the specified network name is invalid".
> Other ipv6 specific tests are OK.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PROTON-1601) windows proactor fails ipv6 target ":::5672"

[ASF subversion and git services (JIRA)]

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

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

Commit 446ade386dab7e0cf163f435beee467e0e294c93 in qpid-proton's branch 
refs/heads/master from Clifford Jansen
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=446ade3 ]

PROTON-1601: make Windows more like Posix in handling the unpecified address 
for outbound connections


> windows proactor fails ipv6 target ":::5672"
> 
>
> Key: PROTON-1601
> URL: https://issues.apache.org/jira/browse/PROTON-1601
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
> Environment: windows
>Reporter: Cliff Jansen
>Assignee: Cliff Jansen
> Fix For: proton-c-0.18.0
>
>
> fails with "The format of the specified network name is invalid".
> Other ipv6 specific tests are OK.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-7531) [Java Broker] Tidy up AMQP 1.0 implementation

[ASF subversion and git services (JIRA)]

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

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

Commit 634eb6a90f221eced9e3ff971846a574de8f87ad in qpid-broker-j's branch 
refs/heads/master from [~lorenz.quack]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=634eb6a ]

QPID-7531: [Java Broker] Add more transaction tests to AMQP 1.0 protocol tests


> [Java Broker] Tidy up AMQP 1.0 implementation
> -
>
> Key: QPID-7531
> URL: https://issues.apache.org/jira/browse/QPID-7531
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Fix For: qpid-java-broker-7.0.0
>
>
> The initial implementation of AMQP 1.0 in the broker came about through 
> importing initial prototyping code used in the creation of the protocol 
> standard and grafting it into the broker code.
> Since this is now the only place the libraries are used we can tidy up the 
> joins between the initial AMQP implementation and the broker.  We should also 
> look to remove (implement) TODOs and generally improve the code.  This must 
> include improvements to the performative constructors that currently swallow 
> incorrectly composed performative (i.e. they swallow ClassCastExceptions).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-7531) [Java Broker] Tidy up AMQP 1.0 implementation

[ASF subversion and git services (JIRA)]

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

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

Commit 876ddd6dd04246a0a2605ef709081f44d42661d1 in qpid-broker-j's branch 
refs/heads/master from [~lorenz.quack]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=876ddd6 ]

QPID-7531: [Java Broker, AMQP 1.0] Improve error handling when receiving 
unknown a transaction-id.


> [Java Broker] Tidy up AMQP 1.0 implementation
> -
>
> Key: QPID-7531
> URL: https://issues.apache.org/jira/browse/QPID-7531
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Fix For: qpid-java-broker-7.0.0
>
>
> The initial implementation of AMQP 1.0 in the broker came about through 
> importing initial prototyping code used in the creation of the protocol 
> standard and grafting it into the broker code.
> Since this is now the only place the libraries are used we can tidy up the 
> joins between the initial AMQP implementation and the broker.  We should also 
> look to remove (implement) TODOs and generally improve the code.  This must 
> include improvements to the performative constructors that currently swallow 
> incorrectly composed performative (i.e. they swallow ClassCastExceptions).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-7531) [Java Broker] Tidy up AMQP 1.0 implementation

[ASF subversion and git services (JIRA)]

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

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

Commit 6a7633d0ba1361a69f8249fffb72a23d8ceb7fc0 in qpid-broker-j's branch 
refs/heads/master from [~lorenz.quack]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=6a7633d ]

QPID-7531: [Java Broker, AMQP 1.0] Allow receiving of Transfers on 
semi-detached links but end the session if link is errored


> [Java Broker] Tidy up AMQP 1.0 implementation
> -
>
> Key: QPID-7531
> URL: https://issues.apache.org/jira/browse/QPID-7531
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Fix For: qpid-java-broker-7.0.0
>
>
> The initial implementation of AMQP 1.0 in the broker came about through 
> importing initial prototyping code used in the creation of the protocol 
> standard and grafting it into the broker code.
> Since this is now the only place the libraries are used we can tidy up the 
> joins between the initial AMQP implementation and the broker.  We should also 
> look to remove (implement) TODOs and generally improve the code.  This must 
> include improvements to the performative constructors that currently swallow 
> incorrectly composed performative (i.e. they swallow ClassCastExceptions).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-7531) [Java Broker] Tidy up AMQP 1.0 implementation

[ASF subversion and git services (JIRA)]

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

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

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

QPID-7531: [Java Broker] add JIRA references to TODOs


> [Java Broker] Tidy up AMQP 1.0 implementation
> -
>
> Key: QPID-7531
> URL: https://issues.apache.org/jira/browse/QPID-7531
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Fix For: qpid-java-broker-7.0.0
>
>
> The initial implementation of AMQP 1.0 in the broker came about through 
> importing initial prototyping code used in the creation of the protocol 
> standard and grafting it into the broker code.
> Since this is now the only place the libraries are used we can tidy up the 
> joins between the initial AMQP implementation and the broker.  We should also 
> look to remove (implement) TODOs and generally improve the code.  This must 
> include improvements to the performative constructors that currently swallow 
> incorrectly composed performative (i.e. they swallow ClassCastExceptions).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-7957) [Java Broker, AMQP 1.0] Add support for max-message-size on Attach

[ASF subversion and git services (JIRA)]

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

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

Commit 103251579d14b82559386f45437e9ea65beca636 in qpid-broker-j's branch 
refs/heads/master from [~lorenz.quack]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=1032515 ]

QPID-7957: [Java Broker, AMQP 1.0] Add support for max-message-size on Attach


> [Java Broker, AMQP 1.0] Add support for max-message-size on Attach
> --
>
> Key: QPID-7957
> URL: https://issues.apache.org/jira/browse/QPID-7957
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-broker-7.0.0
>
>
> Currently the max-message-size on Attach is never set by the broker.
> We should set it to the limit configured on the Connection/VirtualHost and 
> enforce it upon receiving Transfers.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-7531) [Java Broker] Tidy up AMQP 1.0 implementation

[ASF subversion and git services (JIRA)]

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

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

Commit 016279faac0cd0feb2a1208b3ae2bf6d5edadcfb in qpid-broker-j's branch 
refs/heads/master from [~lorenz.quack]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=016279f ]

QPID-7531: [Java Broker, AMQP 1.0] Improve links recovering


> [Java Broker] Tidy up AMQP 1.0 implementation
> -
>
> Key: QPID-7531
> URL: https://issues.apache.org/jira/browse/QPID-7531
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Fix For: qpid-java-broker-7.0.0
>
>
> The initial implementation of AMQP 1.0 in the broker came about through 
> importing initial prototyping code used in the creation of the protocol 
> standard and grafting it into the broker code.
> Since this is now the only place the libraries are used we can tidy up the 
> joins between the initial AMQP implementation and the broker.  We should also 
> look to remove (implement) TODOs and generally improve the code.  This must 
> include improvements to the performative constructors that currently swallow 
> incorrectly composed performative (i.e. they swallow ClassCastExceptions).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-7531) [Java Broker] Tidy up AMQP 1.0 implementation

[ASF subversion and git services (JIRA)]

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

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

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

QPID-7531: [Java Broker, AMQP 1.0] Improve reported error conditions


> [Java Broker] Tidy up AMQP 1.0 implementation
> -
>
> Key: QPID-7531
> URL: https://issues.apache.org/jira/browse/QPID-7531
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Fix For: qpid-java-broker-7.0.0
>
>
> The initial implementation of AMQP 1.0 in the broker came about through 
> importing initial prototyping code used in the creation of the protocol 
> standard and grafting it into the broker code.
> Since this is now the only place the libraries are used we can tidy up the 
> joins between the initial AMQP implementation and the broker.  We should also 
> look to remove (implement) TODOs and generally improve the code.  This must 
> include improvements to the performative constructors that currently swallow 
> incorrectly composed performative (i.e. they swallow ClassCastExceptions).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-7531) [Java Broker] Tidy up AMQP 1.0 implementation

[ASF subversion and git services (JIRA)]

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

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

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

QPID-7531: [Java Broker, AMQP 1.0] Ensure consumer target is closed on 
detaching of sending link endpoint


> [Java Broker] Tidy up AMQP 1.0 implementation
> -
>
> Key: QPID-7531
> URL: https://issues.apache.org/jira/browse/QPID-7531
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Fix For: qpid-java-broker-7.0.0
>
>
> The initial implementation of AMQP 1.0 in the broker came about through 
> importing initial prototyping code used in the creation of the protocol 
> standard and grafting it into the broker code.
> Since this is now the only place the libraries are used we can tidy up the 
> joins between the initial AMQP implementation and the broker.  We should also 
> look to remove (implement) TODOs and generally improve the code.  This must 
> include improvements to the performative constructors that currently swallow 
> incorrectly composed performative (i.e. they swallow ClassCastExceptions).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-7531) [Java Broker] Tidy up AMQP 1.0 implementation

[ASF subversion and git services (JIRA)]

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

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

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

QPID-7531: [Java Broker, AMQP 1.0] Improve reporting of error condition on link 
attachments


> [Java Broker] Tidy up AMQP 1.0 implementation
> -
>
> Key: QPID-7531
> URL: https://issues.apache.org/jira/browse/QPID-7531
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Fix For: qpid-java-broker-7.0.0
>
>
> The initial implementation of AMQP 1.0 in the broker came about through 
> importing initial prototyping code used in the creation of the protocol 
> standard and grafting it into the broker code.
> Since this is now the only place the libraries are used we can tidy up the 
> joins between the initial AMQP implementation and the broker.  We should also 
> look to remove (implement) TODOs and generally improve the code.  This must 
> include improvements to the performative constructors that currently swallow 
> incorrectly composed performative (i.e. they swallow ClassCastExceptions).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-7950) [Java Broker, AMQP 1.0] Discharging transaction after consumer link detach does not apply the correct outcomes

[ASF subversion and git services (JIRA)]

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

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

Commit 6b44f4129f61818a4a095fdc515508fea47450b2 in qpid-broker-j's branch 
refs/heads/master from [~lorenz.quack]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=6b44f41 ]

QPID-7950: [Java Broker, AMQP 1.0] Allow (semi-)detached Link endpoints to 
communicate indirectly via session.


> [Java Broker, AMQP 1.0] Discharging transaction after consumer link detach 
> does not apply the correct outcomes
> --
>
> Key: QPID-7950
> URL: https://issues.apache.org/jira/browse/QPID-7950
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Lorenz Quack
>Priority: Blocker
> Fix For: qpid-java-broker-7.0.0
>
>
> Consider the following scenario:
>  * declare transaction
>  * receive a delivery
>  * detach the consumer
>  * send disposition with txn-state and Accepted outcome
>  * discharge the transaction
> After this message should be deleted from the broker. It currently is not.
> Currently, detaching the link applies the Modified outcome to all unsettled 
> messages therefore the disposition and discharge have no effect on them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (DISPATCH-852) Add dispatch router installation procedure to main book

[Ben Hardesty (JIRA)]

Ben Hardesty created DISPATCH-852:
-

 Summary: Add dispatch router installation procedure to main book
 Key: DISPATCH-852
 URL: https://issues.apache.org/jira/browse/DISPATCH-852
 Project: Qpid Dispatch
  Issue Type: Sub-task
  Components: Documentation
Reporter: Ben Hardesty
Assignee: Ben Hardesty


The QDR installation procedure [1] should be included in the main Dispatch 
Router book. It should include both installing from source and installing from 
a package on Linux [2].

[1] - 
https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;a=blob_plain;f=README;hb=0.8.0
[2] - https://qpid.apache.org/packages.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (DISPATCH-851) Update CMakeLists.txt to build new Dispatch Router Book

[Ben Hardesty (JIRA)]

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

Ben Hardesty commented on DISPATCH-851:
---

[~jr...@redhat.com], as I thought about this, I think what will work best for 
now is to just have one "book" with all of the content in it and then have 
links to the relevant chapters from the Qpid Dispatch Router site. Since there 
will only be one book, the directory can remain "book". If we ever have need 
for additional books in the future, we could always change it to "books" with 
separate dirs for each book. 

> Update CMakeLists.txt to build new Dispatch Router Book
> ---
>
> Key: DISPATCH-851
> URL: https://issues.apache.org/jira/browse/DISPATCH-851
> Project: Qpid Dispatch
>  Issue Type: Sub-task
>  Components: Documentation
>Reporter: Ben Hardesty
>Assignee: Justin Ross
>
> CMakeLists.txt should build the new Dispatch Router book, currently located 
> in /doc/new-book/.
> * The new book should be built using AsciiDoctor instead of AsciiDoc Python 
> (additional info here: 
> http://asciidoctor.org/docs/user-manual/#migrating-from-asciidoc-python).
> * For copying the book dir images, note that the images are now located in 
> /doc/new-book/images/. Before, they were located in /doc/book/.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PROTON-1606) (Proton-J) Using Sasl needs to be optional for Client Role

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PROTON-1606:


GitHub user timtay-microsoft opened a pull request:

https://github.com/apache/qpid-proton-j/pull/11

PROTON-1606: Added ability to make SASL communication optional

Previously, the IOhandler created to be the global handler automatically 
created the SASL layer whether a user of the library wanted it or not. This 
commit exposes an option when creating the reactor to disable creating the SASL 
layer at all.

https://issues.apache.org/jira/browse/PROTON-1606

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

$ git pull https://github.com/timtay-microsoft/qpid-proton-j 
clientSaslOptionality

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

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


commit 965bc73893f887a15b1558891039d0a5cb7556eb
Author: timtay-microsoft 
Date:   2017-10-05T18:40:28Z

PROTON-1606: Added ability to make SASL communication optional for CLIENT 
role

Previously, the IOhandler created to be the global handler automatically 
created the SASL layer whether a user of the library wanted it or not. This 
commit exposes an option when creating the reactor to disable creating the SASL 
layer at all.

https://issues.apache.org/jira/browse/PROTON-1606




> (Proton-J) Using Sasl needs to be optional for Client Role
> --
>
> Key: PROTON-1606
> URL: https://issues.apache.org/jira/browse/PROTON-1606
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-j
>Affects Versions: proton-j-0.22.0
> Environment: N/A
>Reporter: Tim Taylor
>   Original Estimate: 8h
>  Remaining Estimate: 8h
>
> In order for my application to use Proton-j for amqps messaging, the Sasl 
> layer cannot be created by the global handler (IOHandler) at 
> CONNECTION_LOCAL_OPEN time. The code below breaks our ability to use proton-j 
> for amqps messaging as a CLIENT against our service.
> ...
> sasl = transport.sasl();
> sasl.client();
> sasl.setMechanisms("ANONYMOUS");
> ...
> I need these three lines of code to be optional in the global handler, or for 
> a new API that allows a transport implementation to undo creating the Sasl 
> layer.
> Something like:
> 
> Transport transport = event.getConnection().getTransport();
> transport.disableSasl();
> 
> The service I am hitting against is not using Proton-j as the SERVER role.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[GitHub] qpid-proton-j pull request #11: PROTON-1606: Added ability to make SASL comm...

[timtay-microsoft]

GitHub user timtay-microsoft opened a pull request:

https://github.com/apache/qpid-proton-j/pull/11

PROTON-1606: Added ability to make SASL communication optional

Previously, the IOhandler created to be the global handler automatically 
created the SASL layer whether a user of the library wanted it or not. This 
commit exposes an option when creating the reactor to disable creating the SASL 
layer at all.

https://issues.apache.org/jira/browse/PROTON-1606

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

$ git pull https://github.com/timtay-microsoft/qpid-proton-j 
clientSaslOptionality

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

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


commit 965bc73893f887a15b1558891039d0a5cb7556eb
Author: timtay-microsoft 
Date:   2017-10-05T18:40:28Z

PROTON-1606: Added ability to make SASL communication optional for CLIENT 
role

Previously, the IOhandler created to be the global handler automatically 
created the SASL layer whether a user of the library wanted it or not. This 
commit exposes an option when creating the reactor to disable creating the SASL 
layer at all.

https://issues.apache.org/jira/browse/PROTON-1606




---

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

[GitHub] qpid-dispatch pull request #206: Dispatch 829 3

[ganeshmurthy]

GitHub user ganeshmurthy opened a pull request:

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

Dispatch 829 3



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

$ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-829-3

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

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


commit 4ea149a5ff0a854daa15a7ade16c29ca0636b0e2
Author: Chuck Rolke 
Date:   2017-09-28T14:35:45Z

DISPATCH-829: Sense messages received with abort status.

commit 87bef2ccf183ed8525c7f155b49af199dc8e1c3e
Author: Chuck Rolke 
Date:   2017-10-02T20:06:57Z

DISPATCH-829: handle aborted messages




---

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

[jira] [Commented] (DISPATCH-851) Update CMakeLists.txt to build new Dispatch Router Book

[Justin Ross (JIRA)]

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

Justin Ross commented on DISPATCH-851:
--

[~bhardest], I thought the plan was to go to something like 
doc/books/?  In either case, no problem.  We can track that in 
another issue.

> Update CMakeLists.txt to build new Dispatch Router Book
> ---
>
> Key: DISPATCH-851
> URL: https://issues.apache.org/jira/browse/DISPATCH-851
> Project: Qpid Dispatch
>  Issue Type: Sub-task
>  Components: Documentation
>Reporter: Ben Hardesty
>Assignee: Justin Ross
>
> CMakeLists.txt should build the new Dispatch Router book, currently located 
> in /doc/new-book/.
> * The new book should be built using AsciiDoctor instead of AsciiDoc Python 
> (additional info here: 
> http://asciidoctor.org/docs/user-manual/#migrating-from-asciidoc-python).
> * For copying the book dir images, note that the images are now located in 
> /doc/new-book/images/. Before, they were located in /doc/book/.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (QPID-7958) [Java Broker] [AMQ0-10] References to messages sent by $virtualhostProperties node retained by store

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7958:
-
Priority: Critical  (was: Major)

> [Java Broker] [AMQ0-10] References to messages sent by $virtualhostProperties 
> node retained by store
> 
>
> Key: QPID-7958
> URL: https://issues.apache.org/jira/browse/QPID-7958
> Project: Qpid
>  Issue Type: Bug
>Affects Versions: qpid-java-6.0.7, qpid-java-broker-7.0.0, qpid-java-6.1.3
>Reporter: Keith Wall
>Priority: Critical
>
> On  the 0-10 path, I notice that references to messages created by the 
> {{${virtualhostProperties\}}} node are being retained internally within the 
> store.  This is leaking approximately ~1024 bytes per connection.  Restarting 
> the Broker or recycling the virtualhost frees the memory.
> The reference are being retained by the {{AbstractXXXMessageStore#_messages}} 
> set.
> From a brief look, on ConsumerTarget_0_8, it is the NoAckConsumer 
> taking/releasing of the message reference that causes the store to forget the 
> message.  It looks like 
> org/apache/qpid/server/protocol/v0_10/ConsumerTarget_0_10.java:331 (the else 
> path) should have something equivalent.
> QPID-7783 added the _messages data structure.  It was back ported to 6.0 and 
> 6.1, so the leak might be present there too.  I have not verify this.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (QPID-7958) [Java Broker] [AMQ0-10] References to messages sent by $virtualhostProperties node retained by store

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7958:
-
Affects Version/s: qpid-java-6.0.7
   qpid-java-6.1.3

> [Java Broker] [AMQ0-10] References to messages sent by $virtualhostProperties 
> node retained by store
> 
>
> Key: QPID-7958
> URL: https://issues.apache.org/jira/browse/QPID-7958
> Project: Qpid
>  Issue Type: Bug
>Affects Versions: qpid-java-6.0.7, qpid-java-broker-7.0.0, qpid-java-6.1.3
>Reporter: Keith Wall
>
> On  the 0-10 path, I notice that references to messages created by the 
> {{${virtualhostProperties\}}} node are being retained internally within the 
> store.  This is leaking approximately ~1024 bytes per connection.  Restarting 
> the Broker or recycling the virtualhost frees the memory.
> The reference are being retained by the {{AbstractXXXMessageStore#_messages}} 
> set.
> From a brief look, on ConsumerTarget_0_8, it is the NoAckConsumer 
> taking/releasing of the message reference that causes the store to forget the 
> message.  It looks like 
> org/apache/qpid/server/protocol/v0_10/ConsumerTarget_0_10.java:331 (the else 
> path) should have something equivalent.
> QPID-7783 added the _messages data structure.  It was back ported to 6.0 and 
> 6.1, so the leak might be present there too.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (QPID-7958) [Java Broker] [AMQ0-10] References to messages sent by $virtualhostProperties node retained by store

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7958:
-
Affects Version/s: qpid-java-broker-7.0.0

> [Java Broker] [AMQ0-10] References to messages sent by $virtualhostProperties 
> node retained by store
> 
>
> Key: QPID-7958
> URL: https://issues.apache.org/jira/browse/QPID-7958
> Project: Qpid
>  Issue Type: Bug
>Affects Versions: qpid-java-6.0.7, qpid-java-broker-7.0.0, qpid-java-6.1.3
>Reporter: Keith Wall
>
> On  the 0-10 path, I notice that references to messages created by the 
> {{${virtualhostProperties\}}} node are being retained internally within the 
> store.  This is leaking approximately ~1024 bytes per connection.  Restarting 
> the Broker or recycling the virtualhost frees the memory.
> The reference are being retained by the {{AbstractXXXMessageStore#_messages}} 
> set.
> From a brief look, on ConsumerTarget_0_8, it is the NoAckConsumer 
> taking/releasing of the message reference that causes the store to forget the 
> message.  It looks like 
> org/apache/qpid/server/protocol/v0_10/ConsumerTarget_0_10.java:331 (the else 
> path) should have something equivalent.
> QPID-7783 added the _messages data structure.  It was back ported to 6.0 and 
> 6.1, so the leak might be present there too.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (QPID-7958) [Java Broker] [AMQ0-10] References to messages sent by $virtualhostProperties node retained by store

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7958:
-
Description: 
On  the 0-10 path, I notice that references to messages created by the 
{{${virtualhostProperties\}}} node are being retained internally within the 
store.  This is leaking approximately ~1024 bytes per connection.  Restarting 
the Broker or recycling the virtualhost frees the memory.

The reference are being retained by the {{AbstractXXXMessageStore#_messages}} 
set.

>From a brief look, on ConsumerTarget_0_8, it is the NoAckConsumer 
>taking/releasing of the message reference that causes the store to forget the 
>message.  It looks like 
>org/apache/qpid/server/protocol/v0_10/ConsumerTarget_0_10.java:331 (the else 
>path) should have something equivalent.

QPID-7783 added the _messages data structure.  It was back ported to 6.0 and 
6.1, so the leak might be present there too.  I have not verify this.

  was:
On  the 0-10 path, I notice that references to messages created by the 
{{${virtualhostProperties\}}} node are being retained internally within the 
store.  This is leaking approximately ~1024 bytes per connection.  Restarting 
the Broker or recycling the virtualhost frees the memory.

The reference are being retained by the {{AbstractXXXMessageStore#_messages}} 
set.

>From a brief look, on ConsumerTarget_0_8, it is the NoAckConsumer 
>taking/releasing of the message reference that causes the store to forget the 
>message.  It looks like 
>org/apache/qpid/server/protocol/v0_10/ConsumerTarget_0_10.java:331 (the else 
>path) should have something equivalent.

QPID-7783 added the _messages data structure.  It was back ported to 6.0 and 
6.1, so the leak might be present there too.


> [Java Broker] [AMQ0-10] References to messages sent by $virtualhostProperties 
> node retained by store
> 
>
> Key: QPID-7958
> URL: https://issues.apache.org/jira/browse/QPID-7958
> Project: Qpid
>  Issue Type: Bug
>Affects Versions: qpid-java-6.0.7, qpid-java-broker-7.0.0, qpid-java-6.1.3
>Reporter: Keith Wall
>
> On  the 0-10 path, I notice that references to messages created by the 
> {{${virtualhostProperties\}}} node are being retained internally within the 
> store.  This is leaking approximately ~1024 bytes per connection.  Restarting 
> the Broker or recycling the virtualhost frees the memory.
> The reference are being retained by the {{AbstractXXXMessageStore#_messages}} 
> set.
> From a brief look, on ConsumerTarget_0_8, it is the NoAckConsumer 
> taking/releasing of the message reference that causes the store to forget the 
> message.  It looks like 
> org/apache/qpid/server/protocol/v0_10/ConsumerTarget_0_10.java:331 (the else 
> path) should have something equivalent.
> QPID-7783 added the _messages data structure.  It was back ported to 6.0 and 
> 6.1, so the leak might be present there too.  I have not verify this.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (QPID-7958) [Java Broker] [AMQ0-10] References to messages sent by $virtualhostProperties node retained by store

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7958:
-
Description: 
On  the 0-10 path, I notice that references to messages created by the 
{{${virtualhostProperties\}}} node are being retained internally within the 
store.  This is leaking approximately ~1024 bytes per connection.  Restarting 
the Broker or recycling the virtualhost frees the memory.

The reference are being retained by the {{AbstractXXXMessageStore#_messages}} 
set.

>From a brief look, on ConsumerTarget_0_8, it is the NoAckConsumer 
>taking/releasing of the message reference that causes the store to forget the 
>message.  It looks like 
>org/apache/qpid/server/protocol/v0_10/ConsumerTarget_0_10.java:331 (the else 
>path) should have something equivalent.

QPID-7783 added the _messages data structure.  It was back ported to 6.0 and 
6.1, so the leak might be present there too.

  was:
On  the 0-10 path, I notice that references to messages created by the 
${virtualhostProperties} node are being retained internally within the store.  
This is leaking approximately ~1024 bytes per connection.  Restarting the 
Broker or recycling the virtualhost frees the memory.

The reference are being retained by the {{AbstractXXXMessageStore#_messages}} 
set.

>From a brief look, on ConsumerTarget_0_8, it is the NoAckConsumer 
>taking/releasing of the message reference that causes the store to forget the 
>message.  It looks like 
>org/apache/qpid/server/protocol/v0_10/ConsumerTarget_0_10.java:331 (the else 
>path) should have something equivalent.

QPID-7783 added the _messages data structure.  It was back ported to 6.0 and 
6.1, so the leak might be present there too.


> [Java Broker] [AMQ0-10] References to messages sent by $virtualhostProperties 
> node retained by store
> 
>
> Key: QPID-7958
> URL: https://issues.apache.org/jira/browse/QPID-7958
> Project: Qpid
>  Issue Type: Bug
>Reporter: Keith Wall
>
> On  the 0-10 path, I notice that references to messages created by the 
> {{${virtualhostProperties\}}} node are being retained internally within the 
> store.  This is leaking approximately ~1024 bytes per connection.  Restarting 
> the Broker or recycling the virtualhost frees the memory.
> The reference are being retained by the {{AbstractXXXMessageStore#_messages}} 
> set.
> From a brief look, on ConsumerTarget_0_8, it is the NoAckConsumer 
> taking/releasing of the message reference that causes the store to forget the 
> message.  It looks like 
> org/apache/qpid/server/protocol/v0_10/ConsumerTarget_0_10.java:331 (the else 
> path) should have something equivalent.
> QPID-7783 added the _messages data structure.  It was back ported to 6.0 and 
> 6.1, so the leak might be present there too.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (QPID-7958) [Java Broker] [AMQ0-10] References to messages sent by $virtualhostProperties node retained by store

[Keith Wall (JIRA)]

Keith Wall created QPID-7958:


 Summary: [Java Broker] [AMQ0-10] References to messages sent by 
$virtualhostProperties node retained by store
 Key: QPID-7958
 URL: https://issues.apache.org/jira/browse/QPID-7958
 Project: Qpid
  Issue Type: Bug
Reporter: Keith Wall


On  the 0-10 path, I notice that references to messages created by the 
${virtualhostProperties} node are being retained internally within the store.  
This is leaking approximately ~1024 bytes per connection.  Restarting the 
Broker or recycling the virtualhost frees the memory.

The reference are being retained by the {{AbstractXXXMessageStore#_messages}} 
set.

>From a brief look, on ConsumerTarget_0_8, it is the NoAckConsumer 
>taking/releasing of the message reference that causes the store to forget the 
>message.  It looks like 
>org/apache/qpid/server/protocol/v0_10/ConsumerTarget_0_10.java:331 (the else 
>path) should have something equivalent.

QPID-7783 added the _messages data structure.  It was back ported to 6.0 and 
6.1, so the leak might be present there too.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Closed] (PROTON-344) Need Ruby version of msgr-send/msgr-recv tools

[Ken Giusti (JIRA)]

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

Ken Giusti closed PROTON-344.
-
Resolution: Won't Fix

lack of support for messenger

> Need Ruby version of msgr-send/msgr-recv tools
> --
>
> Key: PROTON-344
> URL: https://issues.apache.org/jira/browse/PROTON-344
> Project: Qpid Proton
>  Issue Type: Task
>  Components: proton-c
>Affects Versions: 0.4
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>  Labels: message, messenger
>
> A ruby variant of msgr-send/recv traffic generators should be added to the 
> soak tests.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (DISPATCH-851) Update CMakeLists.txt to build new Dispatch Router Book

[Ben Hardesty (JIRA)]

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

Ben Hardesty commented on DISPATCH-851:
---

[~jr...@redhat.com] - Eventually, the /doc/new-book/ dir should be changed to 
/doc/book/, and the contents of the current /doc/book/ dir should be 
retired/archived. However, I didn't specify any of that yet in case you'd 
rather build both the current Dispatch Router book and the new one. 

> Update CMakeLists.txt to build new Dispatch Router Book
> ---
>
> Key: DISPATCH-851
> URL: https://issues.apache.org/jira/browse/DISPATCH-851
> Project: Qpid Dispatch
>  Issue Type: Sub-task
>  Components: Documentation
>Reporter: Ben Hardesty
>Assignee: Justin Ross
>
> CMakeLists.txt should build the new Dispatch Router book, currently located 
> in /doc/new-book/.
> * The new book should be built using AsciiDoctor instead of AsciiDoc Python 
> (additional info here: 
> http://asciidoctor.org/docs/user-manual/#migrating-from-asciidoc-python).
> * For copying the book dir images, note that the images are now located in 
> /doc/new-book/images/. Before, they were located in /doc/book/.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (DISPATCH-851) Update CMakeLists.txt to build new Dispatch Router Book

[Ben Hardesty (JIRA)]

Ben Hardesty created DISPATCH-851:
-

 Summary: Update CMakeLists.txt to build new Dispatch Router Book
 Key: DISPATCH-851
 URL: https://issues.apache.org/jira/browse/DISPATCH-851
 Project: Qpid Dispatch
  Issue Type: Sub-task
  Components: Documentation
Reporter: Ben Hardesty
Assignee: Justin Ross


CMakeLists.txt should build the new Dispatch Router book, currently located in 
/doc/new-book/.

* The new book should be built using AsciiDoctor instead of AsciiDoc Python 
(additional info here: 
http://asciidoctor.org/docs/user-manual/#migrating-from-asciidoc-python).
* For copying the book dir images, note that the images are now located in 
/doc/new-book/images/. Before, they were located in /doc/book/.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (PROTON-1573) Undefined behavior in some calls to memmove in Proton

[Justin Ross (JIRA)]

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

Justin Ross resolved PROTON-1573.
-
Resolution: Fixed

> Undefined behavior in some calls to memmove in Proton
> -
>
> Key: PROTON-1573
> URL: https://issues.apache.org/jira/browse/PROTON-1573
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Assignee: Alan Conway
>Priority: Trivial
> Fix For: proton-c-0.18.0
>
>
> Proton sometimes calls to memmove with arguments memmove(?, null, 0), that 
> is, the source pointer is null and length is zero.
> According to UndefinedBehaviorSanitizer tool (UBSan), this has undefined 
> behavior.
> {noformat}
> SUMMARY: AddressSanitizer: undefined-behavior 
> /home/jdanek/Work/repos/qpid-proton/proton-c/src/core/codec.c:268:35 in 
> /home/jdanek/Work/repos/qpid-proton/proton-c/src/core/framing.c:97:39: 
> runtime error: null pointer passed as argument 2, which is declared to never 
> be null
> {noformat}
> It can be "fixed" in the following manner, but I think it is probably not 
> worth worrying about, unless the code can be somehow restructured that {{n = 
> 0}} is caught sooner. I verified the fix by running UBSan again. Nothing was 
> reported this time.
> {noformat}
> diff --git a/proton-c/src/core/buffer.c b/proton-c/src/core/buffer.c
> index c3015f49..f47acd6d 100644
> --- a/proton-c/src/core/buffer.c
> +++ b/proton-c/src/core/buffer.c
> @@ -170,8 +170,12 @@ int pn_buffer_append(pn_buffer_t *buf, const char 
> *bytes, size_t size)
>size_t tail_space = pni_buffer_tail_space(buf);
>size_t n = pn_min(tail_space, size);
>  
> +  if (n > 0) {
>memmove(buf->bytes + tail, bytes, n);
> +  }
> +  if (size - n > 0) { 
>memmove(buf->bytes, bytes + n, size - n);
> +  }
>  
>buf->size += size;
>  
> diff --git a/proton-c/src/core/framing.c b/proton-c/src/core/framing.c
> index 09bf4bba..d2c355f8 100644
> --- a/proton-c/src/core/framing.c
> +++ b/proton-c/src/core/framing.c
> @@ -94,7 +94,9 @@ size_t pn_write_frame(char *bytes, size_t available, 
> pn_frame_t frame)
>  bytes[5] = frame.type;
>  pn_i_write16([6], frame.channel);
>  
> -memmove(bytes + AMQP_HEADER_SIZE, frame.extended, frame.ex_size);
> +if (frame.ex_size > 0) {
> +memmove(bytes + AMQP_HEADER_SIZE, frame.extended, frame.ex_size);
> +}
>  memmove(bytes + 4*doff, frame.payload, frame.size);
>  return size;
>} else {
> {noformat}
> After brief Googling, I believe that although this really is an undefined 
> behavior, it is reasonable to expect that any real-world implementation of 
> memmove will be a simple noop as long as {{n = 0}}, which it is always the 
> case. (https://stackoverflow.com/a/5243068/1047788)
> Probably best to ignore this.
> The tests that uncover this are for example
> proton_tests.engine.ConnectionTest.test_capabilities:
> ../proton-c/src/core/framing.c:97:5: runtime error: null pointer passed as 
> argument 2, which is declared to never be null
> proton_tests.engine.CreditTest.testPartialDrain:
> ../proton-c/src/core/buffer.c:173:3: runtime error: null pointer passed as 
> argument 2, which is declared to never be null
> ../proton-c/src/core/buffer.c:174:3: runtime error: null pointer passed as 
> argument 2, which is declared to never be null



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PROTON-1573) Undefined behavior in some calls to memmove in Proton

[Justin Ross (JIRA)]

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

Justin Ross commented on PROTON-1573:
-

Thanks, [~jdanek].


> Undefined behavior in some calls to memmove in Proton
> -
>
> Key: PROTON-1573
> URL: https://issues.apache.org/jira/browse/PROTON-1573
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Assignee: Alan Conway
>Priority: Trivial
> Fix For: proton-c-0.18.0
>
>
> Proton sometimes calls to memmove with arguments memmove(?, null, 0), that 
> is, the source pointer is null and length is zero.
> According to UndefinedBehaviorSanitizer tool (UBSan), this has undefined 
> behavior.
> {noformat}
> SUMMARY: AddressSanitizer: undefined-behavior 
> /home/jdanek/Work/repos/qpid-proton/proton-c/src/core/codec.c:268:35 in 
> /home/jdanek/Work/repos/qpid-proton/proton-c/src/core/framing.c:97:39: 
> runtime error: null pointer passed as argument 2, which is declared to never 
> be null
> {noformat}
> It can be "fixed" in the following manner, but I think it is probably not 
> worth worrying about, unless the code can be somehow restructured that {{n = 
> 0}} is caught sooner. I verified the fix by running UBSan again. Nothing was 
> reported this time.
> {noformat}
> diff --git a/proton-c/src/core/buffer.c b/proton-c/src/core/buffer.c
> index c3015f49..f47acd6d 100644
> --- a/proton-c/src/core/buffer.c
> +++ b/proton-c/src/core/buffer.c
> @@ -170,8 +170,12 @@ int pn_buffer_append(pn_buffer_t *buf, const char 
> *bytes, size_t size)
>size_t tail_space = pni_buffer_tail_space(buf);
>size_t n = pn_min(tail_space, size);
>  
> +  if (n > 0) {
>memmove(buf->bytes + tail, bytes, n);
> +  }
> +  if (size - n > 0) { 
>memmove(buf->bytes, bytes + n, size - n);
> +  }
>  
>buf->size += size;
>  
> diff --git a/proton-c/src/core/framing.c b/proton-c/src/core/framing.c
> index 09bf4bba..d2c355f8 100644
> --- a/proton-c/src/core/framing.c
> +++ b/proton-c/src/core/framing.c
> @@ -94,7 +94,9 @@ size_t pn_write_frame(char *bytes, size_t available, 
> pn_frame_t frame)
>  bytes[5] = frame.type;
>  pn_i_write16([6], frame.channel);
>  
> -memmove(bytes + AMQP_HEADER_SIZE, frame.extended, frame.ex_size);
> +if (frame.ex_size > 0) {
> +memmove(bytes + AMQP_HEADER_SIZE, frame.extended, frame.ex_size);
> +}
>  memmove(bytes + 4*doff, frame.payload, frame.size);
>  return size;
>} else {
> {noformat}
> After brief Googling, I believe that although this really is an undefined 
> behavior, it is reasonable to expect that any real-world implementation of 
> memmove will be a simple noop as long as {{n = 0}}, which it is always the 
> case. (https://stackoverflow.com/a/5243068/1047788)
> Probably best to ignore this.
> The tests that uncover this are for example
> proton_tests.engine.ConnectionTest.test_capabilities:
> ../proton-c/src/core/framing.c:97:5: runtime error: null pointer passed as 
> argument 2, which is declared to never be null
> proton_tests.engine.CreditTest.testPartialDrain:
> ../proton-c/src/core/buffer.c:173:3: runtime error: null pointer passed as 
> argument 2, which is declared to never be null
> ../proton-c/src/core/buffer.c:174:3: runtime error: null pointer passed as 
> argument 2, which is declared to never be null



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-1613) Default value for Messenger::recv is -1, not 2048

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1613:

Labels: messenger  (was: )

> Default value for Messenger::recv is -1, not 2048
> -
>
> Key: PROTON-1613
> URL: https://issues.apache.org/jira/browse/PROTON-1613
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: examples
>Affects Versions: 0.17.0
>Reporter: Jiri Daněk
>Priority: Trivial
>  Labels: messenger
>
> {code}
> diff --git a/tests/javascript/msgr-recv.js b/tests/javascript/msgr-recv.js
> index 24bdcae7..f1353685 100755
> --- a/tests/javascript/msgr-recv.js
> +++ b/tests/javascript/msgr-recv.js
> @@ -191,7 +191,7 @@ if (typeof process === 'object' && typeof require === 
> 'function') {
>  'Usage: msgr-recv [OPTIONS]\n' +
>  ' -a [,]* \tAddresses to listen on [amqp://~0.0.0.0]\n' +
>  ' -c # \tNumber of messages to receive before exiting [0=forever]\n' +
> -' -b # \tArgument to Messenger::recv(n) [2048]\n' +
> +' -b # \tArgument to Messenger::recv(n) [-1]\n' +
>  ' -w # \tSize for incoming window [0]\n' +
>  ' -e # \t# seconds to report statistics, 0 = end of test [0] *TBD*\n' +
>  ' -R \tSend reply if \'reply-to\' present\n' +
> diff --git a/tests/tools/apps/c/msgr-recv.c b/tests/tools/apps/c/msgr-recv.c
> index eff5820c..b87f29a8 100644
> --- a/tests/tools/apps/c/msgr-recv.c
> +++ b/tests/tools/apps/c/msgr-recv.c
> @@ -52,7 +52,7 @@ static void usage(int rc)
>  printf("Usage: msgr-recv [OPTIONS] \n"
> " -a [,]* \tAddresses to listen on 
> [amqp://~0.0.0.0]\n"
> " -c # \tNumber of messages to receive before exiting 
> [0=forever]\n"
> -   " -b # \tArgument to Messenger::recv(n) [2048]\n"
> +   " -b # \tArgument to Messenger::recv(n) [-1]\n"
> " -w # \tSize for incoming window [0]\n"
> " -t # \tInactivity timeout in seconds, -1 = no timeout [-1]\n"
> " -e # \t# seconds to report statistics, 0 = end of test [0] 
> *TBD*\n"
> diff --git a/tests/tools/apps/python/msgr-recv.py 
> b/tests/tools/apps/python/msgr-recv.py
> index 757b19c2..52fe69c3 100755
> --- a/tests/tools/apps/python/msgr-recv.py
> +++ b/tests/tools/apps/python/msgr-recv.py
> @@ -34,7 +34,7 @@ usage = """
>  Usage: msgr-recv [OPTIONS]
>   -a [,]* \tAddresses to listen on [amqp://~0.0.0.0]
>   -c # \tNumber of messages to receive before exiting [0=forever]
> - -b # \tArgument to Messenger::recv(n) [2048]
> + -b # \tArgument to Messenger::recv(n) [-1]
>   -w # \tSize for incoming window [0]
>   -t # \tInactivity timeout in seconds, -1 = no timeout [-1]
>   -e # \t# seconds to report statistics, 0 = end of test [0] *TBD*
> {code}
> There may possibly be more discrepancies, I spotted and then was able to find 
> only this single one. The function in various bindings is usually not called 
> Messenger::recv...



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (DISPATCH-850) Implement new Dispatch Router Book

[Ben Hardesty (JIRA)]

Ben Hardesty created DISPATCH-850:
-

 Summary: Implement new Dispatch Router Book
 Key: DISPATCH-850
 URL: https://issues.apache.org/jira/browse/DISPATCH-850
 Project: Qpid Dispatch
  Issue Type: Improvement
  Components: Documentation
Reporter: Ben Hardesty
Assignee: Ben Hardesty


A new Dispatch Router user guide is available in /doc/new-book/. This new doc 
needs to be made available on the Qpid Dispatch website, and integrated into 
the Dispatch Router build tooling.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-1613) Default value for Messenger::recv is -1, not 2048

[JIRA]

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

Jiri Daněk updated PROTON-1613:
---
Description: 
{code}
diff --git a/tests/javascript/msgr-recv.js b/tests/javascript/msgr-recv.js
index 24bdcae7..f1353685 100755
--- a/tests/javascript/msgr-recv.js
+++ b/tests/javascript/msgr-recv.js
@@ -191,7 +191,7 @@ if (typeof process === 'object' && typeof require === 
'function') {
 'Usage: msgr-recv [OPTIONS]\n' +
 ' -a [,]* \tAddresses to listen on [amqp://~0.0.0.0]\n' +
 ' -c # \tNumber of messages to receive before exiting [0=forever]\n' +
-' -b # \tArgument to Messenger::recv(n) [2048]\n' +
+' -b # \tArgument to Messenger::recv(n) [-1]\n' +
 ' -w # \tSize for incoming window [0]\n' +
 ' -e # \t# seconds to report statistics, 0 = end of test [0] *TBD*\n' +
 ' -R \tSend reply if \'reply-to\' present\n' +
diff --git a/tests/tools/apps/c/msgr-recv.c b/tests/tools/apps/c/msgr-recv.c
index eff5820c..b87f29a8 100644
--- a/tests/tools/apps/c/msgr-recv.c
+++ b/tests/tools/apps/c/msgr-recv.c
@@ -52,7 +52,7 @@ static void usage(int rc)
 printf("Usage: msgr-recv [OPTIONS] \n"
" -a [,]* \tAddresses to listen on [amqp://~0.0.0.0]\n"
" -c # \tNumber of messages to receive before exiting [0=forever]\n"
-   " -b # \tArgument to Messenger::recv(n) [2048]\n"
+   " -b # \tArgument to Messenger::recv(n) [-1]\n"
" -w # \tSize for incoming window [0]\n"
" -t # \tInactivity timeout in seconds, -1 = no timeout [-1]\n"
" -e # \t# seconds to report statistics, 0 = end of test [0] 
*TBD*\n"
diff --git a/tests/tools/apps/python/msgr-recv.py 
b/tests/tools/apps/python/msgr-recv.py
index 757b19c2..52fe69c3 100755
--- a/tests/tools/apps/python/msgr-recv.py
+++ b/tests/tools/apps/python/msgr-recv.py
@@ -34,7 +34,7 @@ usage = """
 Usage: msgr-recv [OPTIONS]
  -a [,]* \tAddresses to listen on [amqp://~0.0.0.0]
  -c # \tNumber of messages to receive before exiting [0=forever]
- -b # \tArgument to Messenger::recv(n) [2048]
+ -b # \tArgument to Messenger::recv(n) [-1]
  -w # \tSize for incoming window [0]
  -t # \tInactivity timeout in seconds, -1 = no timeout [-1]
  -e # \t# seconds to report statistics, 0 = end of test [0] *TBD*
{code}

There may possibly be more discrepancies, I spotted and then was able to find 
only this single one. The function in various bindings is usually not called 
Messenger::recv...

  was:
{code}
diff --git a/tests/javascript/msgr-recv.js b/tests/javascript/msgr-recv.js
index 24bdcae7..f1353685 100755
--- a/tests/javascript/msgr-recv.js
+++ b/tests/javascript/msgr-recv.js
@@ -191,7 +191,7 @@ if (typeof process === 'object' && typeof require === 
'function') {
 'Usage: msgr-recv [OPTIONS]\n' +
 ' -a [,]* \tAddresses to listen on [amqp://~0.0.0.0]\n' +
 ' -c # \tNumber of messages to receive before exiting [0=forever]\n' +
-' -b # \tArgument to Messenger::recv(n) [2048]\n' +
+' -b # \tArgument to Messenger::recv(n) [-1]\n' +
 ' -w # \tSize for incoming window [0]\n' +
 ' -e # \t# seconds to report statistics, 0 = end of test [0] *TBD*\n' +
 ' -R \tSend reply if \'reply-to\' present\n' +
diff --git a/tests/tools/apps/c/msgr-recv.c b/tests/tools/apps/c/msgr-recv.c
index eff5820c..b87f29a8 100644
--- a/tests/tools/apps/c/msgr-recv.c
+++ b/tests/tools/apps/c/msgr-recv.c
@@ -52,7 +52,7 @@ static void usage(int rc)
 printf("Usage: msgr-recv [OPTIONS] \n"
" -a [,]* \tAddresses to listen on [amqp://~0.0.0.0]\n"
" -c # \tNumber of messages to receive before exiting [0=forever]\n"
-   " -b # \tArgument to Messenger::recv(n) [2048]\n"
+   " -b # \tArgument to Messenger::recv(n) [-1]\n"
" -w # \tSize for incoming window [0]\n"
" -t # \tInactivity timeout in seconds, -1 = no timeout [-1]\n"
" -e # \t# seconds to report statistics, 0 = end of test [0] 
*TBD*\n"
diff --git a/tests/tools/apps/python/msgr-recv.py 
b/tests/tools/apps/python/msgr-recv.py
index 757b19c2..52fe69c3 100755
--- a/tests/tools/apps/python/msgr-recv.py
+++ b/tests/tools/apps/python/msgr-recv.py
@@ -34,7 +34,7 @@ usage = """
 Usage: msgr-recv [OPTIONS]
  -a [,]* \tAddresses to listen on [amqp://~0.0.0.0]
  -c # \tNumber of messages to receive before exiting [0=forever]
- -b # \tArgument to Messenger::recv(n) [2048]
+ -b # \tArgument to Messenger::recv(n) [-1]
  -w # \tSize for incoming window [0]
  -t # \tInactivity timeout in seconds, -1 = no timeout [-1]
  -e # \t# seconds to report statistics, 0 = end of test [0] *TBD*
{code}

There may possibly be more discrepancies, I spotted and then was able to find 
only this single one.


> Default value for Messenger::recv is -1, not 2048
> -
>
> Key: PROTON-1613
> URL: 

[jira] [Updated] (PROTON-1613) Default value for Messenger::recv is -1, not 2048

[JIRA]

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

Jiri Daněk updated PROTON-1613:
---
Summary: Default value for Messenger::recv is -1, not 2048  (was: Default 
value for is -1, not 2048)

> Default value for Messenger::recv is -1, not 2048
> -
>
> Key: PROTON-1613
> URL: https://issues.apache.org/jira/browse/PROTON-1613
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: examples
>Affects Versions: 0.17.0
>Reporter: Jiri Daněk
>Priority: Trivial
>
> {code}
> diff --git a/tests/javascript/msgr-recv.js b/tests/javascript/msgr-recv.js
> index 24bdcae7..f1353685 100755
> --- a/tests/javascript/msgr-recv.js
> +++ b/tests/javascript/msgr-recv.js
> @@ -191,7 +191,7 @@ if (typeof process === 'object' && typeof require === 
> 'function') {
>  'Usage: msgr-recv [OPTIONS]\n' +
>  ' -a [,]* \tAddresses to listen on [amqp://~0.0.0.0]\n' +
>  ' -c # \tNumber of messages to receive before exiting [0=forever]\n' +
> -' -b # \tArgument to Messenger::recv(n) [2048]\n' +
> +' -b # \tArgument to Messenger::recv(n) [-1]\n' +
>  ' -w # \tSize for incoming window [0]\n' +
>  ' -e # \t# seconds to report statistics, 0 = end of test [0] *TBD*\n' +
>  ' -R \tSend reply if \'reply-to\' present\n' +
> diff --git a/tests/tools/apps/c/msgr-recv.c b/tests/tools/apps/c/msgr-recv.c
> index eff5820c..b87f29a8 100644
> --- a/tests/tools/apps/c/msgr-recv.c
> +++ b/tests/tools/apps/c/msgr-recv.c
> @@ -52,7 +52,7 @@ static void usage(int rc)
>  printf("Usage: msgr-recv [OPTIONS] \n"
> " -a [,]* \tAddresses to listen on 
> [amqp://~0.0.0.0]\n"
> " -c # \tNumber of messages to receive before exiting 
> [0=forever]\n"
> -   " -b # \tArgument to Messenger::recv(n) [2048]\n"
> +   " -b # \tArgument to Messenger::recv(n) [-1]\n"
> " -w # \tSize for incoming window [0]\n"
> " -t # \tInactivity timeout in seconds, -1 = no timeout [-1]\n"
> " -e # \t# seconds to report statistics, 0 = end of test [0] 
> *TBD*\n"
> diff --git a/tests/tools/apps/python/msgr-recv.py 
> b/tests/tools/apps/python/msgr-recv.py
> index 757b19c2..52fe69c3 100755
> --- a/tests/tools/apps/python/msgr-recv.py
> +++ b/tests/tools/apps/python/msgr-recv.py
> @@ -34,7 +34,7 @@ usage = """
>  Usage: msgr-recv [OPTIONS]
>   -a [,]* \tAddresses to listen on [amqp://~0.0.0.0]
>   -c # \tNumber of messages to receive before exiting [0=forever]
> - -b # \tArgument to Messenger::recv(n) [2048]
> + -b # \tArgument to Messenger::recv(n) [-1]
>   -w # \tSize for incoming window [0]
>   -t # \tInactivity timeout in seconds, -1 = no timeout [-1]
>   -e # \t# seconds to report statistics, 0 = end of test [0] *TBD*
> {code}
> There may possibly be more discrepancies, I spotted and then was able to find 
> only this single one.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (PROTON-1613) Default value for is -1, not 2048

[JIRA]

Jiri Daněk created PROTON-1613:
--

 Summary: Default value for is -1, not 2048
 Key: PROTON-1613
 URL: https://issues.apache.org/jira/browse/PROTON-1613
 Project: Qpid Proton
  Issue Type: Bug
  Components: examples
Affects Versions: 0.17.0
Reporter: Jiri Daněk
Priority: Trivial


{code}
diff --git a/tests/javascript/msgr-recv.js b/tests/javascript/msgr-recv.js
index 24bdcae7..f1353685 100755
--- a/tests/javascript/msgr-recv.js
+++ b/tests/javascript/msgr-recv.js
@@ -191,7 +191,7 @@ if (typeof process === 'object' && typeof require === 
'function') {
 'Usage: msgr-recv [OPTIONS]\n' +
 ' -a [,]* \tAddresses to listen on [amqp://~0.0.0.0]\n' +
 ' -c # \tNumber of messages to receive before exiting [0=forever]\n' +
-' -b # \tArgument to Messenger::recv(n) [2048]\n' +
+' -b # \tArgument to Messenger::recv(n) [-1]\n' +
 ' -w # \tSize for incoming window [0]\n' +
 ' -e # \t# seconds to report statistics, 0 = end of test [0] *TBD*\n' +
 ' -R \tSend reply if \'reply-to\' present\n' +
diff --git a/tests/tools/apps/c/msgr-recv.c b/tests/tools/apps/c/msgr-recv.c
index eff5820c..b87f29a8 100644
--- a/tests/tools/apps/c/msgr-recv.c
+++ b/tests/tools/apps/c/msgr-recv.c
@@ -52,7 +52,7 @@ static void usage(int rc)
 printf("Usage: msgr-recv [OPTIONS] \n"
" -a [,]* \tAddresses to listen on [amqp://~0.0.0.0]\n"
" -c # \tNumber of messages to receive before exiting [0=forever]\n"
-   " -b # \tArgument to Messenger::recv(n) [2048]\n"
+   " -b # \tArgument to Messenger::recv(n) [-1]\n"
" -w # \tSize for incoming window [0]\n"
" -t # \tInactivity timeout in seconds, -1 = no timeout [-1]\n"
" -e # \t# seconds to report statistics, 0 = end of test [0] 
*TBD*\n"
diff --git a/tests/tools/apps/python/msgr-recv.py 
b/tests/tools/apps/python/msgr-recv.py
index 757b19c2..52fe69c3 100755
--- a/tests/tools/apps/python/msgr-recv.py
+++ b/tests/tools/apps/python/msgr-recv.py
@@ -34,7 +34,7 @@ usage = """
 Usage: msgr-recv [OPTIONS]
  -a [,]* \tAddresses to listen on [amqp://~0.0.0.0]
  -c # \tNumber of messages to receive before exiting [0=forever]
- -b # \tArgument to Messenger::recv(n) [2048]
+ -b # \tArgument to Messenger::recv(n) [-1]
  -w # \tSize for incoming window [0]
  -t # \tInactivity timeout in seconds, -1 = no timeout [-1]
  -e # \t# seconds to report statistics, 0 = end of test [0] *TBD*
{code}

There may possibly be more discrepancies, I spotted and then was able to find 
only this single one.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PROTON-1573) Undefined behavior in some calls to memmove in Proton

[JIRA]

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

Jiri Daněk commented on PROTON-1573:


This one here 
https://github.com/apache/qpid-proton/commit/feafb6c80b121f0a7ce87ea09c9b2f0f2d0fadf5

> Undefined behavior in some calls to memmove in Proton
> -
>
> Key: PROTON-1573
> URL: https://issues.apache.org/jira/browse/PROTON-1573
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Assignee: Alan Conway
>Priority: Trivial
> Fix For: proton-c-0.18.0
>
>
> Proton sometimes calls to memmove with arguments memmove(?, null, 0), that 
> is, the source pointer is null and length is zero.
> According to UndefinedBehaviorSanitizer tool (UBSan), this has undefined 
> behavior.
> {noformat}
> SUMMARY: AddressSanitizer: undefined-behavior 
> /home/jdanek/Work/repos/qpid-proton/proton-c/src/core/codec.c:268:35 in 
> /home/jdanek/Work/repos/qpid-proton/proton-c/src/core/framing.c:97:39: 
> runtime error: null pointer passed as argument 2, which is declared to never 
> be null
> {noformat}
> It can be "fixed" in the following manner, but I think it is probably not 
> worth worrying about, unless the code can be somehow restructured that {{n = 
> 0}} is caught sooner. I verified the fix by running UBSan again. Nothing was 
> reported this time.
> {noformat}
> diff --git a/proton-c/src/core/buffer.c b/proton-c/src/core/buffer.c
> index c3015f49..f47acd6d 100644
> --- a/proton-c/src/core/buffer.c
> +++ b/proton-c/src/core/buffer.c
> @@ -170,8 +170,12 @@ int pn_buffer_append(pn_buffer_t *buf, const char 
> *bytes, size_t size)
>size_t tail_space = pni_buffer_tail_space(buf);
>size_t n = pn_min(tail_space, size);
>  
> +  if (n > 0) {
>memmove(buf->bytes + tail, bytes, n);
> +  }
> +  if (size - n > 0) { 
>memmove(buf->bytes, bytes + n, size - n);
> +  }
>  
>buf->size += size;
>  
> diff --git a/proton-c/src/core/framing.c b/proton-c/src/core/framing.c
> index 09bf4bba..d2c355f8 100644
> --- a/proton-c/src/core/framing.c
> +++ b/proton-c/src/core/framing.c
> @@ -94,7 +94,9 @@ size_t pn_write_frame(char *bytes, size_t available, 
> pn_frame_t frame)
>  bytes[5] = frame.type;
>  pn_i_write16([6], frame.channel);
>  
> -memmove(bytes + AMQP_HEADER_SIZE, frame.extended, frame.ex_size);
> +if (frame.ex_size > 0) {
> +memmove(bytes + AMQP_HEADER_SIZE, frame.extended, frame.ex_size);
> +}
>  memmove(bytes + 4*doff, frame.payload, frame.size);
>  return size;
>} else {
> {noformat}
> After brief Googling, I believe that although this really is an undefined 
> behavior, it is reasonable to expect that any real-world implementation of 
> memmove will be a simple noop as long as {{n = 0}}, which it is always the 
> case. (https://stackoverflow.com/a/5243068/1047788)
> Probably best to ignore this.
> The tests that uncover this are for example
> proton_tests.engine.ConnectionTest.test_capabilities:
> ../proton-c/src/core/framing.c:97:5: runtime error: null pointer passed as 
> argument 2, which is declared to never be null
> proton_tests.engine.CreditTest.testPartialDrain:
> ../proton-c/src/core/buffer.c:173:3: runtime error: null pointer passed as 
> argument 2, which is declared to never be null
> ../proton-c/src/core/buffer.c:174:3: runtime error: null pointer passed as 
> argument 2, which is declared to never be null



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-1574) WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) due to missing unlock in stop_polling()

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1574:

Fix Version/s: proton-c-0.18.0

> WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) due to 
> missing unlock in stop_polling()
> ---
>
> Key: PROTON-1574
> URL: https://issues.apache.org/jira/browse/PROTON-1574
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Assignee: Alan Conway
> Fix For: proton-c-0.18.0
>
>
> There is a lot of warnings about lock order on proton tests, that all result 
> from a missing unlock in {{stop_polling()}}.
> {code}
> diff --git a/proton-c/src/proactor/epoll.c b/proton-c/src/proactor/epoll.c 
> index 46effcc7..887327dc 100644 
> --- a/proton-c/src/proactor/epoll.c 
> +++ b/proton-c/src/proactor/epoll.c 
> @@ -296,8 +296,10 @@ static bool start_polling(epoll_extended_t *ee, int 
> epollfd) { 
> static void stop_polling(epoll_extended_t *ee, int epollfd) { 
>   // TODO: check for error, return bool or just log? 
>   lock(>mutex); 
> -  if (ee->fd == -1 || !ee->polling || epollfd == -1) 
> +  if (ee->fd == -1 || !ee->polling || epollfd == -1) { 
> +unlock(>mutex); 
> return; 
> +  } 
>   struct epoll_event ev; 
>   ev.data.ptr = ee; 
>   ev.events = 0;
> {code}
> The warnings follow. TSan is enabled as described in PROTON-1540.
> {noformat}
> $ LD_PRELOAD=/path/to/gcc-7.1.0-lib/lib/libtsan.so TSAN_OPTIONS="color=always 
> second_deadlock_stack=1" ctest -VV
> [...]
> 21: Test command: 
> /home/jdanek/Work/repos/qpid-proton/build/proton-c/src/tests/c-proactor-tests 
> 21: Test timeout computed to be: 1500 
> 21: TEST: test_inactive() 
> 21: TEST: test_interrupt_timeout() 
> 21: TEST: test_errors() 
> 21: TEST: test_client_server() 
> 21: TEST: test_connection_wake() 
> 21: == 
> 21: WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) 
> (pid=687) 
> 21:   Cycle in lock order graph: M170 (0x7b7014a0) => M173 
> (0x7b701558) => M170  
>   
>  
> 21:  
> 21:   Mutex M173 acquired here while holding mutex M170 in main thread: 
> 21: #0 pthread_mutex_lock  (libtsan.so.0+0x000385df)
>   
>   
>   
> 21: #1 lock 
> /home/jdanek/Work/repos/qpid-proton/proton-c/src/proactor/epoll.c:112 
> (libqpid-proton.so.11+0x00044f10) 
> 21: #2 start_polling 
> /home/jdanek/Work/repos/qpid-proton/proton-c/src/proactor/epoll.c:286 
> (libqpid-proton.so.11+0x00044f10) 
> 21: #3 start_polling 
> /home/jdanek/Work/repos/qpid-proton/proton-c/src/proactor/epoll.c:1194 
> (libqpid-proton.so.11+0x0004513e) 
> 21: #4 pconnection_start 
> /home/jdanek/Work/repos/qpid-proton/proton-c/src/proactor/epoll.c:1178 
> (libqpid-proton.so.11+0x0004513e) 
> 21: #5 pn_listener_accept 
> /home/jdanek/Work/repos/qpid-proton/proton-c/src/proactor/epoll.c:1611 
> (libqpid-proton.so.11+0x00048cf2) 
> 21: #6 listen_handler 
> /home/jdanek/Work/repos/qpid-proton/proton-c/src/tests/proactor.c:328 
> (c-proactor-tests+0x00405720) 
> 21: #7 test_proactors_get 
> /home/jdanek/Work/repos/qpid-proton/proton-c/src/tests/proactor.c:167 
> (c-proactor-tests+0x00407490) 
> 21: #8 test_proactors_run 
> /home/jdanek/Work/repos/qpid-proton/proton-c/src/tests/proactor.c:183 
> (c-proactor-tests+0x0040bf84) 
> 21: #9 test_connection_wake 
> /home/jdanek/Work/repos/qpid-proton/proton-c/src/tests/proactor.c:397 
> (c-proactor-tests+0x0040bf84) 
> 21: #10 main 
> /home/jdanek/Work/repos/qpid-proton/proton-c/src/tests/proactor.c:1066 
> (c-proactor-tests+0x00404371) 
> 21:  
> 21:   Mutex M170 previously acquired by the same thread here: 
> 21: #0 pthread_mutex_lock  (libtsan.so.0+0x000385df) 
> 21: #1 lock 
> /home/jdanek/Work/repos/qpid-proton/proton-c/src/proactor/epoll.c:112 
> (libqpid-proton.so.11+0x00048cd3) 
> 21: #2 pn_listener_accept 
> /home/jdanek/Work/repos/qpid-proton/proton-c/src/proactor/epoll.c:1608 
> (libqpid-proton.so.11+0x00048cd3) 
> 21: #3 listen_handler 
> /home/jdanek/Work/repos/qpid-proton/proton-c/src/tests/proactor.c:328 
> (c-proactor-tests+0x00405720) 
> 21: #4 test_proactors_get 
> /home/jdanek/Work/repos/qpid-proton/proton-c/src/tests/proactor.c:167 
> (c-proactor-tests+0x00407490) 
> 

[jira] [Assigned] (PROTON-1573) Undefined behavior in some calls to memmove in Proton

[Justin Ross (JIRA)]

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

Justin Ross reassigned PROTON-1573:
---

Assignee: Alan Conway

> Undefined behavior in some calls to memmove in Proton
> -
>
> Key: PROTON-1573
> URL: https://issues.apache.org/jira/browse/PROTON-1573
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Assignee: Alan Conway
>Priority: Trivial
> Fix For: proton-c-0.18.0
>
>
> Proton sometimes calls to memmove with arguments memmove(?, null, 0), that 
> is, the source pointer is null and length is zero.
> According to UndefinedBehaviorSanitizer tool (UBSan), this has undefined 
> behavior.
> {noformat}
> SUMMARY: AddressSanitizer: undefined-behavior 
> /home/jdanek/Work/repos/qpid-proton/proton-c/src/core/codec.c:268:35 in 
> /home/jdanek/Work/repos/qpid-proton/proton-c/src/core/framing.c:97:39: 
> runtime error: null pointer passed as argument 2, which is declared to never 
> be null
> {noformat}
> It can be "fixed" in the following manner, but I think it is probably not 
> worth worrying about, unless the code can be somehow restructured that {{n = 
> 0}} is caught sooner. I verified the fix by running UBSan again. Nothing was 
> reported this time.
> {noformat}
> diff --git a/proton-c/src/core/buffer.c b/proton-c/src/core/buffer.c
> index c3015f49..f47acd6d 100644
> --- a/proton-c/src/core/buffer.c
> +++ b/proton-c/src/core/buffer.c
> @@ -170,8 +170,12 @@ int pn_buffer_append(pn_buffer_t *buf, const char 
> *bytes, size_t size)
>size_t tail_space = pni_buffer_tail_space(buf);
>size_t n = pn_min(tail_space, size);
>  
> +  if (n > 0) {
>memmove(buf->bytes + tail, bytes, n);
> +  }
> +  if (size - n > 0) { 
>memmove(buf->bytes, bytes + n, size - n);
> +  }
>  
>buf->size += size;
>  
> diff --git a/proton-c/src/core/framing.c b/proton-c/src/core/framing.c
> index 09bf4bba..d2c355f8 100644
> --- a/proton-c/src/core/framing.c
> +++ b/proton-c/src/core/framing.c
> @@ -94,7 +94,9 @@ size_t pn_write_frame(char *bytes, size_t available, 
> pn_frame_t frame)
>  bytes[5] = frame.type;
>  pn_i_write16([6], frame.channel);
>  
> -memmove(bytes + AMQP_HEADER_SIZE, frame.extended, frame.ex_size);
> +if (frame.ex_size > 0) {
> +memmove(bytes + AMQP_HEADER_SIZE, frame.extended, frame.ex_size);
> +}
>  memmove(bytes + 4*doff, frame.payload, frame.size);
>  return size;
>} else {
> {noformat}
> After brief Googling, I believe that although this really is an undefined 
> behavior, it is reasonable to expect that any real-world implementation of 
> memmove will be a simple noop as long as {{n = 0}}, which it is always the 
> case. (https://stackoverflow.com/a/5243068/1047788)
> Probably best to ignore this.
> The tests that uncover this are for example
> proton_tests.engine.ConnectionTest.test_capabilities:
> ../proton-c/src/core/framing.c:97:5: runtime error: null pointer passed as 
> argument 2, which is declared to never be null
> proton_tests.engine.CreditTest.testPartialDrain:
> ../proton-c/src/core/buffer.c:173:3: runtime error: null pointer passed as 
> argument 2, which is declared to never be null
> ../proton-c/src/core/buffer.c:174:3: runtime error: null pointer passed as 
> argument 2, which is declared to never be null



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-1573) Undefined behavior in some calls to memmove in Proton

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1573:

Fix Version/s: proton-c-0.18.0

> Undefined behavior in some calls to memmove in Proton
> -
>
> Key: PROTON-1573
> URL: https://issues.apache.org/jira/browse/PROTON-1573
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Priority: Trivial
> Fix For: proton-c-0.18.0
>
>
> Proton sometimes calls to memmove with arguments memmove(?, null, 0), that 
> is, the source pointer is null and length is zero.
> According to UndefinedBehaviorSanitizer tool (UBSan), this has undefined 
> behavior.
> {noformat}
> SUMMARY: AddressSanitizer: undefined-behavior 
> /home/jdanek/Work/repos/qpid-proton/proton-c/src/core/codec.c:268:35 in 
> /home/jdanek/Work/repos/qpid-proton/proton-c/src/core/framing.c:97:39: 
> runtime error: null pointer passed as argument 2, which is declared to never 
> be null
> {noformat}
> It can be "fixed" in the following manner, but I think it is probably not 
> worth worrying about, unless the code can be somehow restructured that {{n = 
> 0}} is caught sooner. I verified the fix by running UBSan again. Nothing was 
> reported this time.
> {noformat}
> diff --git a/proton-c/src/core/buffer.c b/proton-c/src/core/buffer.c
> index c3015f49..f47acd6d 100644
> --- a/proton-c/src/core/buffer.c
> +++ b/proton-c/src/core/buffer.c
> @@ -170,8 +170,12 @@ int pn_buffer_append(pn_buffer_t *buf, const char 
> *bytes, size_t size)
>size_t tail_space = pni_buffer_tail_space(buf);
>size_t n = pn_min(tail_space, size);
>  
> +  if (n > 0) {
>memmove(buf->bytes + tail, bytes, n);
> +  }
> +  if (size - n > 0) { 
>memmove(buf->bytes, bytes + n, size - n);
> +  }
>  
>buf->size += size;
>  
> diff --git a/proton-c/src/core/framing.c b/proton-c/src/core/framing.c
> index 09bf4bba..d2c355f8 100644
> --- a/proton-c/src/core/framing.c
> +++ b/proton-c/src/core/framing.c
> @@ -94,7 +94,9 @@ size_t pn_write_frame(char *bytes, size_t available, 
> pn_frame_t frame)
>  bytes[5] = frame.type;
>  pn_i_write16([6], frame.channel);
>  
> -memmove(bytes + AMQP_HEADER_SIZE, frame.extended, frame.ex_size);
> +if (frame.ex_size > 0) {
> +memmove(bytes + AMQP_HEADER_SIZE, frame.extended, frame.ex_size);
> +}
>  memmove(bytes + 4*doff, frame.payload, frame.size);
>  return size;
>} else {
> {noformat}
> After brief Googling, I believe that although this really is an undefined 
> behavior, it is reasonable to expect that any real-world implementation of 
> memmove will be a simple noop as long as {{n = 0}}, which it is always the 
> case. (https://stackoverflow.com/a/5243068/1047788)
> Probably best to ignore this.
> The tests that uncover this are for example
> proton_tests.engine.ConnectionTest.test_capabilities:
> ../proton-c/src/core/framing.c:97:5: runtime error: null pointer passed as 
> argument 2, which is declared to never be null
> proton_tests.engine.CreditTest.testPartialDrain:
> ../proton-c/src/core/buffer.c:173:3: runtime error: null pointer passed as 
> argument 2, which is declared to never be null
> ../proton-c/src/core/buffer.c:174:3: runtime error: null pointer passed as 
> argument 2, which is declared to never be null



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (PROTON-1571) The ssl C++ example appears leaky, proton::listener does not have a destructor

[Justin Ross (JIRA)]

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

Justin Ross reassigned PROTON-1571:
---

Assignee: Alan Conway  (was: Cliff Jansen)

> The ssl C++ example appears leaky, proton::listener does not have a destructor
> --
>
> Key: PROTON-1571
> URL: https://issues.apache.org/jira/browse/PROTON-1571
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding, examples
>Affects Versions: proton-c-0.18.0
> Environment: commit e631bf6b11960d9687d42dfdde1ff4c65804981c 
> (upstream/master)
> Author: Andrew Stitcher 
> Date:   Thu Aug 31 17:31:17 2017 -0400
> PROTON-1567: Implement failover urls
> - Example "reliable" client sending and receiving messages
> - Also add jitter to retry backoff (with C++11
>Reporter: Jiri Daněk
>Assignee: Alan Conway
> Fix For: proton-c-0.18.0
>
>
> After applying the following patch (to rin in a loop multiple times and to 
> log RSS and VSS (the last two columns))
> {code}
> diff --git a/examples/cpp/ssl.cpp b/examples/cpp/ssl.cpp
> index 99ceb4aa..f5864f42 100644
> --- a/examples/cpp/ssl.cpp
> +++ b/examples/cpp/ssl.cpp
> @@ -37,6 +37,9 @@
>  
>  #include "fake_cpp11.hpp"
>  
> +#include 
> +#include 
> +
>  using proton::connection_options;
>  using proton::ssl_client_options;
>  using proton::ssl_server_options;
> @@ -178,8 +181,21 @@ int main(int argc, char **argv) {
>  if (verify != verify_noname && verify != verify_full && verify != 
> verify_fail)
>  throw std::runtime_error("bad verify argument: " + verify);
>  
> -hello_world_direct hwd(address);
> -proton::default_container(hwd).run();
> +for (int i = 0; i < 1; i++) {
> +try {
> +hello_world_direct hwd(address);
> +proton::default_container(hwd).run();
> +} catch (const std::exception& e) {
> +if (verify_failed) {
> +if (verify == verify_fail) {
> +std::cout << "Expected failure of connection with wrong 
> peer name: " << e.what() << std::endl;
> +}
> +}
> +}
> +int ret = system("ps -eo pmem,comm,pid,maj_flt,min_flt,rss,vsz | 
> grep ssl");
> +(void)ret;
> +// sleep(1);
> +}
>  return 0;
>  } catch (const std::exception& e) {
>  if (verify_failed) {
> {code}
> and normal compilation,
> {{CFLAGS=-g cmake .. -DBUILD_GO=OFF -DENABLE_VALGRIND=OFF 
> -DCMAKE_BUILD_TYPE=Release -GNijna}}
> run the example and observe that with {{-v fail}}, the RSS grows, while 
> without it, it seems to keep steady. This to me suggests that either the 
> binding does not properly handle failures, or that the example itself does 
> not.
> {noformat}
> $ examples/cpp/ssl -a amqps://localhost:46085/examples -c 
> /home/jdanek/Work/repos/qpid-proton/examples/cpp/ssl_certs -v fail
> Expected failure of connection with wrong peer name: 
> amqp:connection:framing-error: SSL Failure: error:14090086:SSL 
> routines:ssl3_get_server_certificate:certificate verify failed
>  0.0 ssl 29657  0378  6892  35928
> Expected failure of connection with wrong peer name: 
> amqp:connection:framing-error: SSL Failure: error:14090086:SSL 
> routines:ssl3_get_server_certificate:certificate verify failed
>  0.0 ssl 29657  0475  7124  36344
> Expected failure of connection with wrong peer name: 
> amqp:connection:framing-error: SSL Failure: error:14090086:SSL 
> routines:ssl3_get_server_certificate:certificate verify failed
>  0.0 ssl 29657  0572  7500  36756
> Expected failure of connection with wrong peer name: 
> amqp:connection:framing-error: SSL Failure: error:14090086:SSL 
> routines:ssl3_get_server_certificate:certificate verify failed
>  0.0 ssl 29657  0669  7736  37160
> Expected failure of connection with wrong peer name: 
> amqp:connection:framing-error: SSL Failure: error:14090086:SSL 
> routines:ssl3_get_server_certificate:certificate verify failed
>  0.0 ssl 29657  0773  7828  37444
> Expected failure of connection with wrong peer name: 
> amqp:connection:framing-error: SSL Failure: error:14090086:SSL 
> routines:ssl3_get_server_certificate:certificate verify failed
>  0.0 ssl 29657  0874  8192  37860
> Expected failure of connection with wrong peer name: 
> amqp:connection:framing-error: SSL Failure: error:14090086:SSL 
> routines:ssl3_get_server_certificate:certificate verify failed
>  0.0 ssl 29657  0972  8292  38272
> Expected failure of connection with wrong peer name: 
> amqp:connection:framing-error: SSL Failure: error:14090086:SSL 
> 

[jira] [Updated] (PROTON-1571) The ssl C++ example appears leaky, proton::listener does not have a destructor

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1571:

Fix Version/s: proton-c-0.18.0

> The ssl C++ example appears leaky, proton::listener does not have a destructor
> --
>
> Key: PROTON-1571
> URL: https://issues.apache.org/jira/browse/PROTON-1571
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding, examples
>Affects Versions: proton-c-0.18.0
> Environment: commit e631bf6b11960d9687d42dfdde1ff4c65804981c 
> (upstream/master)
> Author: Andrew Stitcher 
> Date:   Thu Aug 31 17:31:17 2017 -0400
> PROTON-1567: Implement failover urls
> - Example "reliable" client sending and receiving messages
> - Also add jitter to retry backoff (with C++11
>Reporter: Jiri Daněk
>Assignee: Cliff Jansen
> Fix For: proton-c-0.18.0
>
>
> After applying the following patch (to rin in a loop multiple times and to 
> log RSS and VSS (the last two columns))
> {code}
> diff --git a/examples/cpp/ssl.cpp b/examples/cpp/ssl.cpp
> index 99ceb4aa..f5864f42 100644
> --- a/examples/cpp/ssl.cpp
> +++ b/examples/cpp/ssl.cpp
> @@ -37,6 +37,9 @@
>  
>  #include "fake_cpp11.hpp"
>  
> +#include 
> +#include 
> +
>  using proton::connection_options;
>  using proton::ssl_client_options;
>  using proton::ssl_server_options;
> @@ -178,8 +181,21 @@ int main(int argc, char **argv) {
>  if (verify != verify_noname && verify != verify_full && verify != 
> verify_fail)
>  throw std::runtime_error("bad verify argument: " + verify);
>  
> -hello_world_direct hwd(address);
> -proton::default_container(hwd).run();
> +for (int i = 0; i < 1; i++) {
> +try {
> +hello_world_direct hwd(address);
> +proton::default_container(hwd).run();
> +} catch (const std::exception& e) {
> +if (verify_failed) {
> +if (verify == verify_fail) {
> +std::cout << "Expected failure of connection with wrong 
> peer name: " << e.what() << std::endl;
> +}
> +}
> +}
> +int ret = system("ps -eo pmem,comm,pid,maj_flt,min_flt,rss,vsz | 
> grep ssl");
> +(void)ret;
> +// sleep(1);
> +}
>  return 0;
>  } catch (const std::exception& e) {
>  if (verify_failed) {
> {code}
> and normal compilation,
> {{CFLAGS=-g cmake .. -DBUILD_GO=OFF -DENABLE_VALGRIND=OFF 
> -DCMAKE_BUILD_TYPE=Release -GNijna}}
> run the example and observe that with {{-v fail}}, the RSS grows, while 
> without it, it seems to keep steady. This to me suggests that either the 
> binding does not properly handle failures, or that the example itself does 
> not.
> {noformat}
> $ examples/cpp/ssl -a amqps://localhost:46085/examples -c 
> /home/jdanek/Work/repos/qpid-proton/examples/cpp/ssl_certs -v fail
> Expected failure of connection with wrong peer name: 
> amqp:connection:framing-error: SSL Failure: error:14090086:SSL 
> routines:ssl3_get_server_certificate:certificate verify failed
>  0.0 ssl 29657  0378  6892  35928
> Expected failure of connection with wrong peer name: 
> amqp:connection:framing-error: SSL Failure: error:14090086:SSL 
> routines:ssl3_get_server_certificate:certificate verify failed
>  0.0 ssl 29657  0475  7124  36344
> Expected failure of connection with wrong peer name: 
> amqp:connection:framing-error: SSL Failure: error:14090086:SSL 
> routines:ssl3_get_server_certificate:certificate verify failed
>  0.0 ssl 29657  0572  7500  36756
> Expected failure of connection with wrong peer name: 
> amqp:connection:framing-error: SSL Failure: error:14090086:SSL 
> routines:ssl3_get_server_certificate:certificate verify failed
>  0.0 ssl 29657  0669  7736  37160
> Expected failure of connection with wrong peer name: 
> amqp:connection:framing-error: SSL Failure: error:14090086:SSL 
> routines:ssl3_get_server_certificate:certificate verify failed
>  0.0 ssl 29657  0773  7828  37444
> Expected failure of connection with wrong peer name: 
> amqp:connection:framing-error: SSL Failure: error:14090086:SSL 
> routines:ssl3_get_server_certificate:certificate verify failed
>  0.0 ssl 29657  0874  8192  37860
> Expected failure of connection with wrong peer name: 
> amqp:connection:framing-error: SSL Failure: error:14090086:SSL 
> routines:ssl3_get_server_certificate:certificate verify failed
>  0.0 ssl 29657  0972  8292  38272
> Expected failure of connection with wrong peer name: 
> amqp:connection:framing-error: SSL Failure: error:14090086:SSL 
> 

[jira] [Updated] (PROTON-1612) python test fail if Cyrus SASL PLAIN and MD5 packages not installed

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1612:

Component/s: (was: proton-c)

> python test fail if Cyrus SASL PLAIN and MD5 packages not installed
> ---
>
> Key: PROTON-1612
> URL: https://issues.apache.org/jira/browse/PROTON-1612
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Affects Versions: proton-c-0.18.0
> Environment: clean centos 7 docker container
>Reporter: Ken Giusti
>Assignee: Justin Ross
> Fix For: proton-c-0.18.0
>
>
> After following the directions in INSTALL.md, and installing the Python build 
> tools (python-devel), the python-test unit test fails the SASL tests.
> 1: proton_tests.sasl.SASLMechTest.testDIGESTMD5  
> fail
> 1: Error during test:  Traceback (most recent call last):
> 1: File "/root/qpid-proton-0.18.0-beta/tests/python/proton-test", line 
> 365, in run
> 1:   phase()
> 1: File 
> "/root/qpid-proton-0.18.0-beta/tests/python/proton_tests/sasl.py", line 326, 
> in testDIGESTMD5
> 1:   _testSaslMech(self, 'DIGEST-MD5')
> 1: File 
> "/root/qpid-proton-0.18.0-beta/tests/python/proton_tests/sasl.py", line 53, 
> in _testSaslMech
> 1:   assert self.t2.authenticated == authenticated, authenticated
> 1:   AssertionError: True
> proton_tests.reactor.ContainerTest.test_authentication_via_url .. fail
> 
> 1: File 
> "/root/qpid-proton-0.18.0-beta/tests/python/proton_tests/reactor.py", line 
> 339, in on_connection_opening
> 1:   assert event.connection.transport.user == "user@proton"
> 1:   AssertionError
> These tests require MD5 and PLAIN support.  The following packages must be 
> installed for the tests to pass:
> $ yum install cyrus-sasl-plain cyrus-sasl-md5
> Either these packages must be listed as required in the INSTALL.md file, or 
> the tests should skip if these mechanisms are not available.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Closed] (QPIDJMS-314) AssertionError from Netty during cleanup of Epoll channel with SO_LINGER configured

[JIRA]

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

Jiri Daněk closed QPIDJMS-314.
--

Works for me in the 0.26.0 first release candidate.

> AssertionError from Netty during cleanup of Epoll channel with SO_LINGER 
> configured
> ---
>
> Key: QPIDJMS-314
> URL: https://issues.apache.org/jira/browse/QPIDJMS-314
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.24.0, 0.25.0
>Reporter: Jiri Daněk
>Assignee: Robbie Gemmell
>Priority: Minor
> Fix For: 0.26.0
>
>
> I have a test suite which sometimes causes qpid-jms to die on AssertionError 
> from netty. Rerunning the single failing test does not seem to reproduce it, 
> I have to run the whole suite.
> First, start a broker. I am using ActiveMQ Artemis. The travis build uses a 
> docker image with the broker. Then run the test suite in a loop, until it 
> fails.
> {noformat}
> git clone g...@github.com:jdanekrh/cli-java.git
> cd cli-java/
> git checkout jd_code_push
> ret=0
> while [[ ret -eq 0 ]]; do mvn test; ret=$?; done
> {noformat}
> Here is log from when it failed in Travis, 
> https://travis-ci.org/rh-messaging-qe/cli-java/jobs/267185207
> I do not know how to debug this (it never happened when I was running it 
> under debugger). Also, even if I could get it in a debugger, I would not know 
> what to do next.
> The relevant part of maven output is
> {noformat}
> [...]
> Receiving: 
> 6,1,sendAndReceiveWithAllSenderCLISwitches(String),sendAndReceiveWithAllSenderCLISwitches(String),null,null,null
> 15:36:17.444Connecting: 1 0 1
> 15:36:17.515Sending: {'durable': True, 'priority': 4, 'ttl': 0, 
> 'first-acquirer': False, 'delivery-count': 0, 'redelivered': False, 'id': 
> 'ID:aConnIdPrefix32a68f56-629b-4111-a36c-aede9135c52c:1:1:1-1', 'user_id': 
> None, 'address': 'lalaLand_l6o9ghgpom4jmu15cln21gpoi5', 'subject': None, 
> 'reply_to': None, 'correlation_id': None, 'content_type': None, 
> 'content_encoding': None, 'absolute-expiry-time': 0, 'creation-time': 
> 1503408977545, 'group-id': None, 'group-sequence': 0, 'reply-to-group-id': 
> None, 'properties': {'JMSXDeliveryCount': 1}, 'content': None}
> Tests run: 21, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 10.384 sec 
> <<< FAILURE! - in AacMainTest
> sendAndReceiveWithAllSenderCLISwitches(String)  Time elapsed: 0.336 sec  <<< 
> FAILURE!
> java.lang.AssertionError
> at 
> io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)
> at 
> io.netty.channel.epoll.AbstractEpollChannel.doDeregister(AbstractEpollChannel.java:142)
> at 
> io.netty.channel.epoll.AbstractEpollChannel.doClose(AbstractEpollChannel.java:118)
> at 
> io.netty.channel.epoll.AbstractEpollStreamChannel.doClose(AbstractEpollStreamChannel.java:703)
> at 
> io.netty.channel.AbstractChannel$AbstractUnsafe.doClose0(AbstractChannel.java:685)
> at 
> io.netty.channel.AbstractChannel$AbstractUnsafe.access$700(AbstractChannel.java:419)
> at 
> io.netty.channel.AbstractChannel$AbstractUnsafe$5.run(AbstractChannel.java:646)
> at 
> io.netty.util.concurrent.GlobalEventExecutor$TaskRunner.run(GlobalEventExecutor.java:233)
> at 
> io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:138)
> at java.lang.Thread.run(Thread.java:748)
> sendAndReceiveSingleMessage()  Time elapsed: 0.049 sec  <<< FAILURE!
> java.lang.AssertionError
> at 
> io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)
> at 
> io.netty.channel.epoll.AbstractEpollChannel.doDeregister(AbstractEpollChannel.java:142)
> at 
> io.netty.channel.epoll.AbstractEpollChannel.doClose(AbstractEpollChannel.java:118)
> at 
> io.netty.channel.epoll.AbstractEpollStreamChannel.doClose(AbstractEpollStreamChannel.java:703)
> at 
> io.netty.channel.AbstractChannel$AbstractUnsafe.doClose0(AbstractChannel.java:685)
> at 
> io.netty.channel.AbstractChannel$AbstractUnsafe.access$700(AbstractChannel.java:419)
> at 
> io.netty.channel.AbstractChannel$AbstractUnsafe$5.run(AbstractChannel.java:646)
> at 
> io.netty.util.concurrent.GlobalEventExecutor$TaskRunner.run(GlobalEventExecutor.java:233)
> at 
> io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:138)
> at java.lang.Thread.run(Thread.java:748)
> Results :
> Failed tests: 
>   AbstractMainTest.sendAndReceiveSingleMessage
> sendAndReceiveWithAllSenderCLISwitches(String).sendAndReceiveWithAllSenderCLISwitches(String)
>   Run 1: PASS
>   Run 2: PASS
>   Run 3: PASS
>   Run 4: PASS
>   Run 5: PASS
>   Run 6: PASS
>   Run 7: 

[jira] [Created] (QPID-7957) [Java Broker, AMQP 1.0] Add support for max-message-size on Attach

[Lorenz Quack (JIRA)]

Lorenz Quack created QPID-7957:
--

 Summary: [Java Broker, AMQP 1.0] Add support for max-message-size 
on Attach
 Key: QPID-7957
 URL: https://issues.apache.org/jira/browse/QPID-7957
 Project: Qpid
  Issue Type: Improvement
  Components: Java Broker
Reporter: Lorenz Quack
 Fix For: qpid-java-broker-7.0.0


Currently the max-message-size on Attach is never set by the broker.
We should set it to the limit configured on the Connection/VirtualHost and 
enforce it upon receiving Transfers.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (QPID-7059) BDBHAVirtualHostNodeRestTest.testDeleteMasterNode failed sporadically on Apache CI

[Keith Wall (JIRA)]

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

Keith Wall edited comment on QPID-7059 at 10/5/17 9:30 AM:
---

Repeat of same issue - log attached.  The new logging shows us that the DbPing 
is giving us a non-zero value.   The problem will be a race in the test code.   
The thread updating the remote node's attributes will be racing with the Jetty 
thread reading the attributes.   The unlucky case is where the 
lastTransactionId has been read by Jetty and then the node state mutates.  This 
will give the failure. 


was (Author: k-wall):
Repeat of same issue - log attached.  The new logging shows us that the DbPing 
is giving us a non-zero value.   The problem must be within the Qpid code, but 
I can't spot it.

> BDBHAVirtualHostNodeRestTest.testDeleteMasterNode failed sporadically on 
> Apache CI
> --
>
> Key: QPID-7059
> URL: https://issues.apache.org/jira/browse/QPID-7059
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Keith Wall
>Priority: Minor
> Attachments: 
> TEST-org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.testCreate3NodeGroup.txt
>
>
> The following test was seen to fail on Apache CI:
> https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Java-Java-BDB-TestMatrix/jdk=JDK%201.7%20(latest),label=Ubuntu,profile=java-bdb.0-10/2122/testReport/junit/org.apache.qpid.server.store.berkeleydb.replication/BDBHAVirtualHostNodeRestTest/testDeleteMasterNode/
> The test verifies that the remote view of the other nodes in the group is 
> populated.  In this case the test failed because the node's join time is 
> recorded as zero. 
> {noformat}
> org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.testDeleteMasterNode
> Failing for the past 1 build (Since Failed#2122 )
> Took 10 sec.
> add description
> Error Message
> Node node2 has unexpected joinTime 0
> Stacktrace
> junit.framework.AssertionFailedError: Node node2 has unexpected joinTime 0
>   at junit.framework.Assert.fail(Assert.java:57)
>   at junit.framework.Assert.assertTrue(Assert.java:22)
>   at junit.framework.TestCase.assertTrue(TestCase.java:192)
>   at 
> org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.assertRemoteNodeData(BDBHAVirtualHostNodeRestTest.java:412)
>   at 
> org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.assertRemoteNodes(BDBHAVirtualHostNodeRestTest.java:397)
>   at 
> org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.testDeleteMasterNode(BDBHAVirtualHostNodeRestTest.java:206)
> {noformat}
> There were no further errors in the logs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-7059) BDBHAVirtualHostNodeRestTest.testDeleteMasterNode failed sporadically on Apache CI

[Keith Wall (JIRA)]

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

Keith Wall commented on QPID-7059:
--

Repeat of same issue - log attached.  The new logging shows us that the DbPing 
is giving us a non-zero value.   The problem must be within the Qpid code, but 
I can't spot it.

> BDBHAVirtualHostNodeRestTest.testDeleteMasterNode failed sporadically on 
> Apache CI
> --
>
> Key: QPID-7059
> URL: https://issues.apache.org/jira/browse/QPID-7059
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Keith Wall
>Priority: Minor
> Attachments: 
> TEST-org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.testCreate3NodeGroup.txt
>
>
> The following test was seen to fail on Apache CI:
> https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Java-Java-BDB-TestMatrix/jdk=JDK%201.7%20(latest),label=Ubuntu,profile=java-bdb.0-10/2122/testReport/junit/org.apache.qpid.server.store.berkeleydb.replication/BDBHAVirtualHostNodeRestTest/testDeleteMasterNode/
> The test verifies that the remote view of the other nodes in the group is 
> populated.  In this case the test failed because the node's join time is 
> recorded as zero. 
> {noformat}
> org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.testDeleteMasterNode
> Failing for the past 1 build (Since Failed#2122 )
> Took 10 sec.
> add description
> Error Message
> Node node2 has unexpected joinTime 0
> Stacktrace
> junit.framework.AssertionFailedError: Node node2 has unexpected joinTime 0
>   at junit.framework.Assert.fail(Assert.java:57)
>   at junit.framework.Assert.assertTrue(Assert.java:22)
>   at junit.framework.TestCase.assertTrue(TestCase.java:192)
>   at 
> org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.assertRemoteNodeData(BDBHAVirtualHostNodeRestTest.java:412)
>   at 
> org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.assertRemoteNodes(BDBHAVirtualHostNodeRestTest.java:397)
>   at 
> org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.testDeleteMasterNode(BDBHAVirtualHostNodeRestTest.java:206)
> {noformat}
> There were no further errors in the logs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (QPID-7059) BDBHAVirtualHostNodeRestTest.testDeleteMasterNode failed sporadically on Apache CI

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7059:
-
Attachment: 
TEST-org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.testCreate3NodeGroup.txt

> BDBHAVirtualHostNodeRestTest.testDeleteMasterNode failed sporadically on 
> Apache CI
> --
>
> Key: QPID-7059
> URL: https://issues.apache.org/jira/browse/QPID-7059
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Keith Wall
>Priority: Minor
> Attachments: 
> TEST-org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.testCreate3NodeGroup.txt
>
>
> The following test was seen to fail on Apache CI:
> https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Java-Java-BDB-TestMatrix/jdk=JDK%201.7%20(latest),label=Ubuntu,profile=java-bdb.0-10/2122/testReport/junit/org.apache.qpid.server.store.berkeleydb.replication/BDBHAVirtualHostNodeRestTest/testDeleteMasterNode/
> The test verifies that the remote view of the other nodes in the group is 
> populated.  In this case the test failed because the node's join time is 
> recorded as zero. 
> {noformat}
> org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.testDeleteMasterNode
> Failing for the past 1 build (Since Failed#2122 )
> Took 10 sec.
> add description
> Error Message
> Node node2 has unexpected joinTime 0
> Stacktrace
> junit.framework.AssertionFailedError: Node node2 has unexpected joinTime 0
>   at junit.framework.Assert.fail(Assert.java:57)
>   at junit.framework.Assert.assertTrue(Assert.java:22)
>   at junit.framework.TestCase.assertTrue(TestCase.java:192)
>   at 
> org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.assertRemoteNodeData(BDBHAVirtualHostNodeRestTest.java:412)
>   at 
> org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.assertRemoteNodes(BDBHAVirtualHostNodeRestTest.java:397)
>   at 
> org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.testDeleteMasterNode(BDBHAVirtualHostNodeRestTest.java:206)
> {noformat}
> There were no further errors in the logs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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