[GitHub] [qpid-dispatch] dependabot[bot] closed pull request #1093: Bump @patternfly/react-topology from 4.7.45 to 4.8.14 in /console/react

2021-04-01 Thread GitBox


dependabot[bot] closed pull request #1093:
URL: https://github.com/apache/qpid-dispatch/pull/1093


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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



[GitHub] [qpid-dispatch] dependabot[bot] commented on pull request #1093: Bump @patternfly/react-topology from 4.7.45 to 4.8.14 in /console/react

2021-04-01 Thread GitBox


dependabot[bot] commented on pull request #1093:
URL: https://github.com/apache/qpid-dispatch/pull/1093#issuecomment-812330264


   Superseded by #1098.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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



[GitHub] [qpid-dispatch] dependabot[bot] opened a new pull request #1098: Bump @patternfly/react-topology from 4.7.45 to 4.8.15 in /console/react

2021-04-01 Thread GitBox


dependabot[bot] opened a new pull request #1098:
URL: https://github.com/apache/qpid-dispatch/pull/1098


   Bumps 
[@patternfly/react-topology](https://github.com/patternfly/patternfly-react) 
from 4.7.45 to 4.8.15.
   
   Release notes
   Sourced from https://github.com/patternfly/patternfly-react/releases";>@​patternfly/react-topology's
 releases.
   
   @​patternfly/react-topologyhttps://github.com/4";>@​4.8.15
   https://github.com/patternfly/patternfly-react/compare/@patternfly/react-topology@4.8.14...@patternfly/react-topology@4.8.15";>4.8.15
 (2021-04-01)
   Note: Version bump only for package 
@​patternfly/react-topology
   @​patternfly/react-topologyhttps://github.com/4";>@​4.8.14
   https://github.com/patternfly/patternfly-react/compare/@patternfly/react-topology@4.8.13...@patternfly/react-topology@4.8.14";>4.8.14
 (2021-03-29)
   Note: Version bump only for package 
@​patternfly/react-topology
   @​patternfly/react-topologyhttps://github.com/4";>@​4.8.13
   https://github.com/patternfly/patternfly-react/compare/@patternfly/react-topology@4.8.12...@patternfly/react-topology@4.8.13";>4.8.13
 (2021-03-26)
   Note: Version bump only for package 
@​patternfly/react-topology
   @​patternfly/react-topologyhttps://github.com/4";>@​4.8.12
   https://github.com/patternfly/patternfly-react/compare/@patternfly/react-topology@4.8.11...@patternfly/react-topology@4.8.12";>4.8.12
 (2021-03-26)
   Note: Version bump only for package 
@​patternfly/react-topology
   @​patternfly/react-topologyhttps://github.com/4";>@​4.8.11
   https://github.com/patternfly/patternfly-react/compare/@patternfly/react-topology@4.8.10...@patternfly/react-topology@4.8.11";>4.8.11
 (2021-03-26)
   Note: Version bump only for package 
@​patternfly/react-topology
   @​patternfly/react-topologyhttps://github.com/4";>@​4.8.10
   https://github.com/patternfly/patternfly-react/compare/@patternfly/react-topology@4.8.9...@patternfly/react-topology@4.8.10";>4.8.10
 (2021-03-26)
   Note: Version bump only for package 
@​patternfly/react-topology
   @​patternfly/react-topologyhttps://github.com/4";>@​4.8.9
   https://github.com/patternfly/patternfly-react/compare/@patternfly/react-topology@4.8.8...@patternfly/react-topology@4.8.9";>4.8.9
 (2021-03-25)
   Note: Version bump only for package 
@​patternfly/react-topology
   @​patternfly/react-topologyhttps://github.com/4";>@​4.8.8
   https://github.com/patternfly/patternfly-react/compare/@patternfly/react-topology@4.8.7...@patternfly/react-topology@4.8.8";>4.8.8
 (2021-03-25)
   Note: Version bump only for package 
@​patternfly/react-topology
   
   
   
   Commits
   
   https://github.com/patternfly/patternfly-react/commit/22a5f394db0b722b8b7b2ceafacc87293d0cd522";>22a5f39
 chore(release): releasing packages [ci skip]
   https://github.com/patternfly/patternfly-react/commit/2f6fcfde6c183d3c351516b3b2061d36968d14a5";>2f6fcfd
 fix(nav): don't call onExpand twice (https://github-redirect.dependabot.com/patternfly/patternfly-react/issues/5611";>#5611)
   https://github.com/patternfly/patternfly-react/commit/481bbb7ad5f4299603781862e25a228ebf620279";>481bbb7
 chore(release): releasing packages [ci skip]
   https://github.com/patternfly/patternfly-react/commit/8975fb55ad2d2241872d5b1d48906bb84f2f3912";>8975fb5
 Chore(docs):Add release notes for 2020.04 (https://github-redirect.dependabot.com/patternfly/patternfly-react/issues/5602";>#5602)
   https://github.com/patternfly/patternfly-react/commit/75e40de50a3068b5646345c6c97ff6317827d234";>75e40de
 chore(release): releasing packages [ci skip]
   https://github.com/patternfly/patternfly-react/commit/6577d4fd4b30721abd97fddaf7214c72d1e284b5";>6577d4f
 feat(Table): Add Tree Table variant (https://github-redirect.dependabot.com/patternfly/patternfly-react/issues/5573";>#5573)
   https://github.com/patternfly/patternfly-react/commit/72bc5746d8111ef943db97eb0b2e9c821220dd81";>72bc574
 chore(release): releasing packages [ci skip]
   https://github.com/patternfly/patternfly-react/commit/95ed7734e69b81ed7548f4125d320087b25d3b0c";>95ed773
 fix(Navigation): Fixed so that the onExpand callback is fired (https://github-redirect.dependabot.com/patternfly/patternfly-react/issues/5595";>#5595)
   https://github.com/patternfly/patternfly-react/commit/5569ee774299590f039844d51dbbc92e3dcb4330";>5569ee7
 chore(release): releasing packages [ci skip]
   https://github.com/patternfly/patternfly-react/commit/69d49971305e5a70ec7594e3c457a745dcbff6f4";>69d4997
 chore(deps): update dependency theme-patternfly-org to v0.4.33 (https://github-redirect.dependabot.com/patternfly/patternfly-react/issues/5587";>#5587)
   Additional commits viewable in https://github.com/patternfly/patternfly-react/compare/@patternfly/react-topology@4.7.45...@patternfly/react-topology@4.8.15";>compare
 view
   
   
   
   
   
   [![Dependabot compatibility 
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=@patternfly/react-topology&package-manager=npm_and_yarn&pr

[jira] [Commented] (PROTON-2365) Build failure without C++

2021-04-01 Thread Fabrice Fontaine (Jira)


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

Fabrice Fontaine commented on PROTON-2365:
--

In the context of embedded systems, C++ is not available everywhere but adding 
a C++ dependency to qpid-proton is totally acceptable from my point of view. In 
this case, I would advise to update the project statement at line 22 to require 
CXX.

> Build failure without C++
> -
>
> Key: PROTON-2365
> URL: https://issues.apache.org/jira/browse/PROTON-2365
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: build
>Affects Versions: proton-c-0.33.0
>Reporter: Fabrice Fontaine
>Priority: Major
> Attachments: 0003-CMakeLists.txt-fix-build-without-C.patch
>
>
> For an unknown reason, the following build failure is raised when the 
> toolchain does not have a working C++ compiler (with cmake 3.18.4):
> {code:java}
> -- The CXX compiler identification is unknown
> CMake Error at CMakeLists.txt:73 (enable_language):
>  The CMAKE_CXX_COMPILER:
> /home/giuliobenetti/autobuild/run/instance-3/output-1/host/bin/arm-linux-g++
> is not a full path to an existing compiler tool.
> Tell CMake where to find the compiler by setting either the environment
>  variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
>  to the compiler, or to the compiler name if it is in the PATH.
> -- Configuring incomplete, errors occurred!
> {code}
> I don't understand why this build failure is raised because 
> enable_language(CXX) is correctly protected by
> {code:java}
> check_language (CXX)
> if (CMAKE_CXX_COMPILER){code}
> Perhaps, there is a bug inside cmake, to fix it, check for BUILD_CPP



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Commented] (PROTON-2354) C++ test failures on MacOS due to unexported symbols being hidden

2021-04-01 Thread ASF subversion and git services (Jira)


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

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

Commit 22ff802f8a2b0a9eef794e05f8f72f8cabaa9897 in qpid-proton's branch 
refs/heads/main from Andrew Stitcher
[ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=22ff802 ]

PROTON-2354: Better fix for some 'macOS' test failures

Actually these failures aren't specific to macOS rather to clang's
libc++ runtime library which is pickier about RTTI information
being exported for excpetion catching and dynamic_cast<>.


> C++ test failures on MacOS due to unexported symbols being  hidden
> --
>
> Key: PROTON-2354
> URL: https://issues.apache.org/jira/browse/PROTON-2354
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
> Environment: macOSX 10.15 
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
>Priority: Major
>  Labels: macOS
> Fix For: proton-c-0.34.0
>
>
> Since PROTON-2343 build flags have been consistently applied to all builds. 
> This has resulted in the MacOS (clang) build respecting the 
> ENABLE_HIDE_UNEXPORTED_SYMBOLS, where it seemingly didn't before.
> This causes build failures like:
> {code}
>  % ./cpp/connection_driver_test 
> TEST: test_driver_link_id()
> TEST: test_endpoint_close()
> TEST: test_driver_disconnected()
> TEST: test_no_container()
> ERROR test_no_container()
> ../cpp/src/connection_driver_test.cpp:546: No container
> TEST: test_spin_interrupt()
> TEST: test_link_address()
> TEST: test_link_anonymous_dynamic()
> TEST: test_link_capability_filter()
> TEST: test_message()
> TEST: test_message_timeout_succeed()
> TEST: test_message_timeout_fail()
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Commented] (DISPATCH-2029) [tcp] Run some of the http1 adaptor tests over tcp

2021-04-01 Thread ASF GitHub Bot (Jira)


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

ASF GitHub Bot commented on DISPATCH-2029:
--

codecov-io commented on pull request #1097:
URL: https://github.com/apache/qpid-dispatch/pull/1097#issuecomment-812247511


   # 
[Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/1097?src=pr&el=h1) 
Report
   > Merging 
[#1097](https://codecov.io/gh/apache/qpid-dispatch/pull/1097?src=pr&el=desc) 
(09a06ed) into 
[main](https://codecov.io/gh/apache/qpid-dispatch/commit/f2e205c733558102006ed6dd0a44453c9821c80a?el=desc)
 (f2e205c) will **increase** coverage by `1.99%`.
   > The diff coverage is `n/a`.
   
   [![Impacted file tree 
graph](https://codecov.io/gh/apache/qpid-dispatch/pull/1097/graphs/tree.svg?width=650&height=150&src=pr&token=rk2Cgd27pP)](https://codecov.io/gh/apache/qpid-dispatch/pull/1097?src=pr&el=tree)
   
   ```diff
   @@Coverage Diff @@
   ## main#1097  +/-   ##
   ==
   + Coverage   82.29%   84.28%   +1.99% 
   ==
 Files 111  111  
 Lines   2754027540  
   ==
   + Hits2266323213 +550 
   + Misses   4877 4327 -550 
   ```
   
   
   | [Impacted 
Files](https://codecov.io/gh/apache/qpid-dispatch/pull/1097?src=pr&el=tree) | 
Coverage Δ | |
   |---|---|---|
   | 
[src/adaptors/http1/http1\_server.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1097/diff?src=pr&el=tree#diff-c3JjL2FkYXB0b3JzL2h0dHAxL2h0dHAxX3NlcnZlci5j)
 | `84.59% <0.00%> (-0.30%)` | :arrow_down: |
   | 
[src/adaptors/http1/http1\_codec.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1097/diff?src=pr&el=tree#diff-c3JjL2FkYXB0b3JzL2h0dHAxL2h0dHAxX2NvZGVjLmM=)
 | `85.15% <0.00%> (-0.13%)` | :arrow_down: |
   | 
[src/router\_node.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1097/diff?src=pr&el=tree#diff-c3JjL3JvdXRlcl9ub2RlLmM=)
 | `93.59% <0.00%> (-0.11%)` | :arrow_down: |
   | 
[src/server.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1097/diff?src=pr&el=tree#diff-c3JjL3NlcnZlci5j)
 | `86.76% <0.00%> (+0.10%)` | :arrow_up: |
   | 
[src/message.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1097/diff?src=pr&el=tree#diff-c3JjL21lc3NhZ2UuYw==)
 | `86.67% <0.00%> (+0.28%)` | :arrow_up: |
   | 
[src/router\_core/router\_core.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1097/diff?src=pr&el=tree#diff-c3JjL3JvdXRlcl9jb3JlL3JvdXRlcl9jb3JlLmM=)
 | `86.73% <0.00%> (+0.34%)` | :arrow_up: |
   | 
[src/router\_core/connections.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1097/diff?src=pr&el=tree#diff-c3JjL3JvdXRlcl9jb3JlL2Nvbm5lY3Rpb25zLmM=)
 | `89.93% <0.00%> (+1.29%)` | :arrow_up: |
   | 
[src/router\_core/transfer.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1097/diff?src=pr&el=tree#diff-c3JjL3JvdXRlcl9jb3JlL3RyYW5zZmVyLmM=)
 | `94.39% <0.00%> (+1.72%)` | :arrow_up: |
   | 
[src/adaptors/tcp\_adaptor.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1097/diff?src=pr&el=tree#diff-c3JjL2FkYXB0b3JzL3RjcF9hZGFwdG9yLmM=)
 | `69.14% <0.00%> (+66.24%)` | :arrow_up: |
   
   --
   
   [Continue to review full report at 
Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/1097?src=pr&el=continue).
   > **Legend** - [Click here to learn 
more](https://docs.codecov.io/docs/codecov-delta)
   > `Δ = absolute  (impact)`, `ø = not affected`, `? = missing data`
   > Powered by 
[Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/1097?src=pr&el=footer).
 Last update 
[f2e205c...09a06ed](https://codecov.io/gh/apache/qpid-dispatch/pull/1097?src=pr&el=lastupdated).
 Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> [tcp] Run some of the http1 adaptor tests over tcp
> --
>
> Key: DISPATCH-2029
> URL: https://issues.apache.org/jira/browse/DISPATCH-2029
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Tests
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.16.0
>
>
> There are some tests in system_tests_http1_adaptor.py that can also be run 
> over the tcp protocol. Create a common class that both these tests can use



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[GitHub] [qpid-dispatch] codecov-io commented on pull request #1097: DISPATCH-2029: Added a base class and moved some of the http1 adaptor…

2021-04-01 Thread GitBox


codecov-io commented on pull request #1097:
URL: https://github.com/apache/qpid-dispatch/pull/1097#issuecomment-812247511


   # 
[Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/1097?src=pr&el=h1) 
Report
   > Merging 
[#1097](https://codecov.io/gh/apache/qpid-dispatch/pull/1097?src=pr&el=desc) 
(09a06ed) into 
[main](https://codecov.io/gh/apache/qpid-dispatch/commit/f2e205c733558102006ed6dd0a44453c9821c80a?el=desc)
 (f2e205c) will **increase** coverage by `1.99%`.
   > The diff coverage is `n/a`.
   
   [![Impacted file tree 
graph](https://codecov.io/gh/apache/qpid-dispatch/pull/1097/graphs/tree.svg?width=650&height=150&src=pr&token=rk2Cgd27pP)](https://codecov.io/gh/apache/qpid-dispatch/pull/1097?src=pr&el=tree)
   
   ```diff
   @@Coverage Diff @@
   ## main#1097  +/-   ##
   ==
   + Coverage   82.29%   84.28%   +1.99% 
   ==
 Files 111  111  
 Lines   2754027540  
   ==
   + Hits2266323213 +550 
   + Misses   4877 4327 -550 
   ```
   
   
   | [Impacted 
Files](https://codecov.io/gh/apache/qpid-dispatch/pull/1097?src=pr&el=tree) | 
Coverage Δ | |
   |---|---|---|
   | 
[src/adaptors/http1/http1\_server.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1097/diff?src=pr&el=tree#diff-c3JjL2FkYXB0b3JzL2h0dHAxL2h0dHAxX3NlcnZlci5j)
 | `84.59% <0.00%> (-0.30%)` | :arrow_down: |
   | 
[src/adaptors/http1/http1\_codec.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1097/diff?src=pr&el=tree#diff-c3JjL2FkYXB0b3JzL2h0dHAxL2h0dHAxX2NvZGVjLmM=)
 | `85.15% <0.00%> (-0.13%)` | :arrow_down: |
   | 
[src/router\_node.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1097/diff?src=pr&el=tree#diff-c3JjL3JvdXRlcl9ub2RlLmM=)
 | `93.59% <0.00%> (-0.11%)` | :arrow_down: |
   | 
[src/server.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1097/diff?src=pr&el=tree#diff-c3JjL3NlcnZlci5j)
 | `86.76% <0.00%> (+0.10%)` | :arrow_up: |
   | 
[src/message.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1097/diff?src=pr&el=tree#diff-c3JjL21lc3NhZ2UuYw==)
 | `86.67% <0.00%> (+0.28%)` | :arrow_up: |
   | 
[src/router\_core/router\_core.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1097/diff?src=pr&el=tree#diff-c3JjL3JvdXRlcl9jb3JlL3JvdXRlcl9jb3JlLmM=)
 | `86.73% <0.00%> (+0.34%)` | :arrow_up: |
   | 
[src/router\_core/connections.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1097/diff?src=pr&el=tree#diff-c3JjL3JvdXRlcl9jb3JlL2Nvbm5lY3Rpb25zLmM=)
 | `89.93% <0.00%> (+1.29%)` | :arrow_up: |
   | 
[src/router\_core/transfer.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1097/diff?src=pr&el=tree#diff-c3JjL3JvdXRlcl9jb3JlL3RyYW5zZmVyLmM=)
 | `94.39% <0.00%> (+1.72%)` | :arrow_up: |
   | 
[src/adaptors/tcp\_adaptor.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1097/diff?src=pr&el=tree#diff-c3JjL2FkYXB0b3JzL3RjcF9hZGFwdG9yLmM=)
 | `69.14% <0.00%> (+66.24%)` | :arrow_up: |
   
   --
   
   [Continue to review full report at 
Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/1097?src=pr&el=continue).
   > **Legend** - [Click here to learn 
more](https://docs.codecov.io/docs/codecov-delta)
   > `Δ = absolute  (impact)`, `ø = not affected`, `? = missing data`
   > Powered by 
[Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/1097?src=pr&el=footer).
 Last update 
[f2e205c...09a06ed](https://codecov.io/gh/apache/qpid-dispatch/pull/1097?src=pr&el=lastupdated).
 Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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



[jira] [Commented] (DISPATCH-2029) [tcp] Run some of the http1 adaptor tests over tcp

2021-04-01 Thread ASF GitHub Bot (Jira)


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

ASF GitHub Bot commented on DISPATCH-2029:
--

ganeshmurthy opened a new pull request #1097:
URL: https://github.com/apache/qpid-dispatch/pull/1097


   … tests to this base class. Also introduced a new test that executes http1 
tests over tcp


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> [tcp] Run some of the http1 adaptor tests over tcp
> --
>
> Key: DISPATCH-2029
> URL: https://issues.apache.org/jira/browse/DISPATCH-2029
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Tests
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.16.0
>
>
> There are some tests in system_tests_http1_adaptor.py that can also be run 
> over the tcp protocol. Create a common class that both these tests can use



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[GitHub] [qpid-dispatch] ganeshmurthy opened a new pull request #1097: DISPATCH-2029: Added a base class and moved some of the http1 adaptor…

2021-04-01 Thread GitBox


ganeshmurthy opened a new pull request #1097:
URL: https://github.com/apache/qpid-dispatch/pull/1097


   … tests to this base class. Also introduced a new test that executes http1 
tests over tcp


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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



[jira] [Created] (DISPATCH-2029) [tcp] Run some of the http1 adaptor tests over tcp

2021-04-01 Thread Ganesh Murthy (Jira)
Ganesh Murthy created DISPATCH-2029:
---

 Summary: [tcp] Run some of the http1 adaptor tests over tcp
 Key: DISPATCH-2029
 URL: https://issues.apache.org/jira/browse/DISPATCH-2029
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Tests
Reporter: Ganesh Murthy
Assignee: Ganesh Murthy
 Fix For: 1.16.0


There are some tests in system_tests_http1_adaptor.py that can also be run over 
the tcp protocol. Create a common class that both these tests can use



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Commented] (PROTON-2357) [cpp] Improve test coverage in url.cpp

2021-04-01 Thread ASF GitHub Bot (Jira)


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

ASF GitHub Bot commented on PROTON-2357:


ssorj commented on a change in pull request #303:
URL: https://github.com/apache/qpid-proton/pull/303#discussion_r605897055



##
File path: cpp/src/url_test.cpp
##
@@ -111,6 +116,54 @@ TEST_CASE("parse URL","[url]") {
   "amqp", "user", "pass", "::1", "1234", "path",
   "amqp://user:pass@[::1]:1234/path");
 }
+SECTION("port") {
+CHECK("host:1234" == url("amqp://host:1234/path").host_port());
+CHECK(5672 == url("amqp://foo/path").port_int());
+CHECK(5671 == url("amqps://foo/path").port_int());
+CHECK(1234 == url("amqps://foo:1234/path").port_int());
+
+url u("amqps://foo:xyz/path");
+url_error caught_error("");
+try{
+  u.port_int();
+}
+catch(url_error& err){
+  caught_error=err;

Review comment:
   As a style and readability matter, put spaces around assignment operators

##
File path: cpp/src/url_test.cpp
##
@@ -111,6 +116,54 @@ TEST_CASE("parse URL","[url]") {
   "amqp", "user", "pass", "::1", "1234", "path",
   "amqp://user:pass@[::1]:1234/path");
 }
+SECTION("port") {
+CHECK("host:1234" == url("amqp://host:1234/path").host_port());
+CHECK(5672 == url("amqp://foo/path").port_int());
+CHECK(5671 == url("amqps://foo/path").port_int());
+CHECK(1234 == url("amqps://foo:1234/path").port_int());
+
+url u("amqps://foo:xyz/path");
+url_error caught_error("");
+try{
+  u.port_int();
+}
+catch(url_error& err){
+  caught_error=err;
+}
+CHECK(std::string("invalid port 'xyz'") == 
std::string(caught_error.what()));
+}
+SECTION("misc") {

Review comment:
   "Misc" is too generic here.  I think "constructors" for the copy 
constructor case and "operators" for the  remaining tests currently under misc 
would be more helpful to future developers.

##
File path: cpp/src/url_test.cpp
##
@@ -111,6 +116,54 @@ TEST_CASE("parse URL","[url]") {
   "amqp", "user", "pass", "::1", "1234", "path",
   "amqp://user:pass@[::1]:1234/path");
 }
+SECTION("port") {
+CHECK("host:1234" == url("amqp://host:1234/path").host_port());
+CHECK(5672 == url("amqp://foo/path").port_int());
+CHECK(5671 == url("amqps://foo/path").port_int());
+CHECK(1234 == url("amqps://foo:1234/path").port_int());
+
+url u("amqps://foo:xyz/path");
+url_error caught_error("");
+try{
+  u.port_int();
+}
+catch(url_error& err){
+  caught_error=err;
+}
+CHECK(std::string("invalid port 'xyz'") == 
std::string(caught_error.what()));
+}
+SECTION("misc") {
+{
+  // url copy constructor
+  url u1("amqp://foo:xyz/path");
+  url u2=u1;
+  CHECK(std::string("amqp://foo:xyz/path") == std::string(u2));
+
+  // url assignment operator
+  url u3("amqp://foo:xyz/pathdontcare");
+  u3=u1;
+  CHECK(std::string("amqp://foo:xyz/path") == std::string(u3));
+}
+{
+  url u("amqp://foo:1234/path");
+  CHECK(true == u.empty());
+  CHECK(std::string("amqp://foo:1234/path") == std::string(u));
+  CHECK(false == u.empty());
+}
+{
+  url u("amqp://foo:xyz/path");
+  std::ostringstream o;
+  o< [cpp] Improve test coverage in url.cpp
> --
>
> Key: PROTON-2357
> URL: https://issues.apache.org/jira/browse/PROTON-2357
> Project: Qpid Proton
>  Issue Type: Test
>  Components: cpp-binding
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Major
>  Labels: starter
>
> *Assignee: Rakhi Kumari*
> Url.cpp currently has 76% line coverage after running the tests.  Increase 
> the coverage to 100% or as close as is practical.  To do this, add or modify 
> tests in url_test.cpp.
> To set up coverage builds:
>  # Install lcov, the code coverage tool
>  # Configure the build for coverage analysis: cmake 
> -DCMAKE_BUILD_TYPE=Coverage [...]
>  # Build the code: make build
>  # Run the tests: make test
>  # Generate coverage results: make coverage
>  # View the results at /coverage_results



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[GitHub] [qpid-proton] ssorj commented on a change in pull request #303: PROTON-2357: Improve test coverage in url.cpp

2021-04-01 Thread GitBox


ssorj commented on a change in pull request #303:
URL: https://github.com/apache/qpid-proton/pull/303#discussion_r605897055



##
File path: cpp/src/url_test.cpp
##
@@ -111,6 +116,54 @@ TEST_CASE("parse URL","[url]") {
   "amqp", "user", "pass", "::1", "1234", "path",
   "amqp://user:pass@[::1]:1234/path");
 }
+SECTION("port") {
+CHECK("host:1234" == url("amqp://host:1234/path").host_port());
+CHECK(5672 == url("amqp://foo/path").port_int());
+CHECK(5671 == url("amqps://foo/path").port_int());
+CHECK(1234 == url("amqps://foo:1234/path").port_int());
+
+url u("amqps://foo:xyz/path");
+url_error caught_error("");
+try{
+  u.port_int();
+}
+catch(url_error& err){
+  caught_error=err;

Review comment:
   As a style and readability matter, put spaces around assignment operators

##
File path: cpp/src/url_test.cpp
##
@@ -111,6 +116,54 @@ TEST_CASE("parse URL","[url]") {
   "amqp", "user", "pass", "::1", "1234", "path",
   "amqp://user:pass@[::1]:1234/path");
 }
+SECTION("port") {
+CHECK("host:1234" == url("amqp://host:1234/path").host_port());
+CHECK(5672 == url("amqp://foo/path").port_int());
+CHECK(5671 == url("amqps://foo/path").port_int());
+CHECK(1234 == url("amqps://foo:1234/path").port_int());
+
+url u("amqps://foo:xyz/path");
+url_error caught_error("");
+try{
+  u.port_int();
+}
+catch(url_error& err){
+  caught_error=err;
+}
+CHECK(std::string("invalid port 'xyz'") == 
std::string(caught_error.what()));
+}
+SECTION("misc") {

Review comment:
   "Misc" is too generic here.  I think "constructors" for the copy 
constructor case and "operators" for the  remaining tests currently under misc 
would be more helpful to future developers.

##
File path: cpp/src/url_test.cpp
##
@@ -111,6 +116,54 @@ TEST_CASE("parse URL","[url]") {
   "amqp", "user", "pass", "::1", "1234", "path",
   "amqp://user:pass@[::1]:1234/path");
 }
+SECTION("port") {
+CHECK("host:1234" == url("amqp://host:1234/path").host_port());
+CHECK(5672 == url("amqp://foo/path").port_int());
+CHECK(5671 == url("amqps://foo/path").port_int());
+CHECK(1234 == url("amqps://foo:1234/path").port_int());
+
+url u("amqps://foo:xyz/path");
+url_error caught_error("");
+try{
+  u.port_int();
+}
+catch(url_error& err){
+  caught_error=err;
+}
+CHECK(std::string("invalid port 'xyz'") == 
std::string(caught_error.what()));
+}
+SECTION("misc") {
+{
+  // url copy constructor
+  url u1("amqp://foo:xyz/path");
+  url u2=u1;
+  CHECK(std::string("amqp://foo:xyz/path") == std::string(u2));
+
+  // url assignment operator
+  url u3("amqp://foo:xyz/pathdontcare");
+  u3=u1;
+  CHECK(std::string("amqp://foo:xyz/path") == std::string(u3));
+}
+{
+  url u("amqp://foo:1234/path");
+  CHECK(true == u.empty());
+  CHECK(std::string("amqp://foo:1234/path") == std::string(u));
+  CHECK(false == u.empty());
+}
+{
+  url u("amqp://foo:xyz/path");
+  std::ostringstream o;
+  o<

[jira] [Commented] (PROTON-2357) [cpp] Improve test coverage in url.cpp

2021-04-01 Thread Justin Ross (Jira)


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

Justin Ross commented on PROTON-2357:
-

It also seems that the check for bad() is redundant, since fail() already 
checks that:

http://www.cplusplus.com/reference/ios/ios/fail/

> [cpp] Improve test coverage in url.cpp
> --
>
> Key: PROTON-2357
> URL: https://issues.apache.org/jira/browse/PROTON-2357
> Project: Qpid Proton
>  Issue Type: Test
>  Components: cpp-binding
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Major
>  Labels: starter
>
> *Assignee: Rakhi Kumari*
> Url.cpp currently has 76% line coverage after running the tests.  Increase 
> the coverage to 100% or as close as is practical.  To do this, add or modify 
> tests in url_test.cpp.
> To set up coverage builds:
>  # Install lcov, the code coverage tool
>  # Configure the build for coverage analysis: cmake 
> -DCMAKE_BUILD_TYPE=Coverage [...]
>  # Build the code: make build
>  # Run the tests: make test
>  # Generate coverage results: make coverage
>  # View the results at /coverage_results



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Commented] (PROTON-2357) [cpp] Improve test coverage in url.cpp

2021-04-01 Thread Justin Ross (Jira)


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

Justin Ross commented on PROTON-2357:
-

I think I agree about the empty side of that branch.  I don't see how it can be 
triggered.

> [cpp] Improve test coverage in url.cpp
> --
>
> Key: PROTON-2357
> URL: https://issues.apache.org/jira/browse/PROTON-2357
> Project: Qpid Proton
>  Issue Type: Test
>  Components: cpp-binding
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Major
>  Labels: starter
>
> *Assignee: Rakhi Kumari*
> Url.cpp currently has 76% line coverage after running the tests.  Increase 
> the coverage to 100% or as close as is practical.  To do this, add or modify 
> tests in url_test.cpp.
> To set up coverage builds:
>  # Install lcov, the code coverage tool
>  # Configure the build for coverage analysis: cmake 
> -DCMAKE_BUILD_TYPE=Coverage [...]
>  # Build the code: make build
>  # Run the tests: make test
>  # Generate coverage results: make coverage
>  # View the results at /coverage_results



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Commented] (PROTON-2365) Build failure without C++

2021-04-01 Thread Jira


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

Jiri Daněk commented on PROTON-2365:


It could be that check_language in CMake does a less-than-thorough check, so it 
is possible to pass it, but then fail when C++ is actually being enabled.

bq. 0003-CMakeLists.txt-fix-build-without-C.patch

{{BUILD_CPP}} should be there already. There is some magic which is dynamically 
defining these variables based on a list of available binding, and it also 
takes into account the {{-DBUILD_BINDINGS}} option.

Doing a condition with {{CMAKE_CXX_COMPILER AND BUILD_CPP}} is not ideal, 
because some Proton C tests are written in C++ (using the Catch library) and 
the plan is to eventually move all C tests to C++. Compilation without C++ 
available would have to also disable building (some of) the tests. I don't like 
the direction this is going.

Is being able to build Proton without C++ all that important? As far as I can 
tell, the thinking has so far been that C++ is available everywhere, so we 
should make use of it as much as possible (e.g., use Catch to test Proton C). 
We already have a similar relationship with Python. The Proton project will not 
build without Python and many tests for Proton C need Python.

> Build failure without C++
> -
>
> Key: PROTON-2365
> URL: https://issues.apache.org/jira/browse/PROTON-2365
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: build
>Affects Versions: proton-c-0.33.0
>Reporter: Fabrice Fontaine
>Priority: Major
> Attachments: 0003-CMakeLists.txt-fix-build-without-C.patch
>
>
> For an unknown reason, the following build failure is raised when the 
> toolchain does not have a working C++ compiler (with cmake 3.18.4):
> {code:java}
> -- The CXX compiler identification is unknown
> CMake Error at CMakeLists.txt:73 (enable_language):
>  The CMAKE_CXX_COMPILER:
> /home/giuliobenetti/autobuild/run/instance-3/output-1/host/bin/arm-linux-g++
> is not a full path to an existing compiler tool.
> Tell CMake where to find the compiler by setting either the environment
>  variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
>  to the compiler, or to the compiler name if it is in the PATH.
> -- Configuring incomplete, errors occurred!
> {code}
> I don't understand why this build failure is raised because 
> enable_language(CXX) is correctly protected by
> {code:java}
> check_language (CXX)
> if (CMAKE_CXX_COMPILER){code}
> Perhaps, there is a bug inside cmake, to fix it, check for BUILD_CPP



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (PROTON-2365) Build failure without C++

2021-04-01 Thread Fabrice Fontaine (Jira)


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

Fabrice Fontaine updated PROTON-2365:
-
Description: 
For an unknown reason, the following build failure is raised when the toolchain 
does not have a working C++ compiler (with cmake 3.18.4):
{code:java}
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:73 (enable_language):
 The CMAKE_CXX_COMPILER:
/home/giuliobenetti/autobuild/run/instance-3/output-1/host/bin/arm-linux-g++
is not a full path to an existing compiler tool.
Tell CMake where to find the compiler by setting either the environment
 variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
 to the compiler, or to the compiler name if it is in the PATH.

-- Configuring incomplete, errors occurred!
{code}
I don't understand why this build failure is raised because 
enable_language(CXX) is correctly protected by
{code:java}
check_language (CXX)
if (CMAKE_CXX_COMPILER){code}
Perhaps, there is a bug inside cmake, to fix it, check for BUILD_CPP

  was:
For an unknown reason, the following build failure is raised when the toolchain 
does not have a working C++ compiler (with cmake 3.18.4):

 
{code:java}
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:73 (enable_language):
 The CMAKE_CXX_COMPILER:
/home/giuliobenetti/autobuild/run/instance-3/output-1/host/bin/arm-linux-g++
is not a full path to an existing compiler tool.
Tell CMake where to find the compiler by setting either the environment
 variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
 to the compiler, or to the compiler name if it is in the PATH.

-- Configuring incomplete, errors occurred!
{code}
I don't understand why this build failure is raised because 
enable_language(CXX) is correctly protected by
{code:java}
check_language (CXX)
if (CMAKE_CXX_COMPILER){code}
Perhaps, there is a bug inside cmake, to fix it, check for BUILD_CPP


> Build failure without C++
> -
>
> Key: PROTON-2365
> URL: https://issues.apache.org/jira/browse/PROTON-2365
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: build
>Affects Versions: proton-c-0.33.0
>Reporter: Fabrice Fontaine
>Priority: Major
> Attachments: 0003-CMakeLists.txt-fix-build-without-C.patch
>
>
> For an unknown reason, the following build failure is raised when the 
> toolchain does not have a working C++ compiler (with cmake 3.18.4):
> {code:java}
> -- The CXX compiler identification is unknown
> CMake Error at CMakeLists.txt:73 (enable_language):
>  The CMAKE_CXX_COMPILER:
> /home/giuliobenetti/autobuild/run/instance-3/output-1/host/bin/arm-linux-g++
> is not a full path to an existing compiler tool.
> Tell CMake where to find the compiler by setting either the environment
>  variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
>  to the compiler, or to the compiler name if it is in the PATH.
> -- Configuring incomplete, errors occurred!
> {code}
> I don't understand why this build failure is raised because 
> enable_language(CXX) is correctly protected by
> {code:java}
> check_language (CXX)
> if (CMAKE_CXX_COMPILER){code}
> Perhaps, there is a bug inside cmake, to fix it, check for BUILD_CPP



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (PROTON-2365) Build failure without C++

2021-04-01 Thread Fabrice Fontaine (Jira)


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

Fabrice Fontaine updated PROTON-2365:
-
Attachment: 0003-CMakeLists.txt-fix-build-without-C.patch

> Build failure without C++
> -
>
> Key: PROTON-2365
> URL: https://issues.apache.org/jira/browse/PROTON-2365
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: build
>Affects Versions: proton-c-0.33.0
>Reporter: Fabrice Fontaine
>Priority: Major
> Attachments: 0003-CMakeLists.txt-fix-build-without-C.patch
>
>
> For an unknown reason, the following build failure is raised when the 
> toolchain does not have a working C++ compiler (with cmake 3.18.4):
>  
> {code:java}
> -- The CXX compiler identification is unknown
> CMake Error at CMakeLists.txt:73 (enable_language):
>  The CMAKE_CXX_COMPILER:
> /home/giuliobenetti/autobuild/run/instance-3/output-1/host/bin/arm-linux-g++
> is not a full path to an existing compiler tool.
> Tell CMake where to find the compiler by setting either the environment
>  variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
>  to the compiler, or to the compiler name if it is in the PATH.
> -- Configuring incomplete, errors occurred!
> {code}
> I don't understand why this build failure is raised because 
> enable_language(CXX) is correctly protected by
> {code:java}
> check_language (CXX)
> if (CMAKE_CXX_COMPILER){code}
> Perhaps, there is a bug inside cmake, to fix it, check for BUILD_CPP



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (PROTON-2365) Build failure without C++

2021-04-01 Thread Fabrice Fontaine (Jira)


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

Fabrice Fontaine updated PROTON-2365:
-
Attachment: (was: 0003-CMakeLists.txt-fix-build-without-C.patch)

> Build failure without C++
> -
>
> Key: PROTON-2365
> URL: https://issues.apache.org/jira/browse/PROTON-2365
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: build
>Affects Versions: proton-c-0.33.0
>Reporter: Fabrice Fontaine
>Priority: Major
>
> For an unknown reason, the following build failure is raised when the 
> toolchain does not have a working C++ compiler (with cmake 3.18.4):
>  
> {code:java}
> -- The CXX compiler identification is unknown
> CMake Error at CMakeLists.txt:73 (enable_language):
>  The CMAKE_CXX_COMPILER:
> /home/giuliobenetti/autobuild/run/instance-3/output-1/host/bin/arm-linux-g++
> is not a full path to an existing compiler tool.
> Tell CMake where to find the compiler by setting either the environment
>  variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
>  to the compiler, or to the compiler name if it is in the PATH.
> -- Configuring incomplete, errors occurred!
> {code}
> I don't understand why this build failure is raised because 
> enable_language(CXX) is correctly protected by
> {code:java}
> check_language (CXX)
> if (CMAKE_CXX_COMPILER){code}
> Perhaps, there is a bug inside cmake, to fix it, check for BUILD_CPP



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Resolved] (DISPATCH-1991) system_tests_tcp_adaptor fails with timeout issue

2021-04-01 Thread Ganesh Murthy (Jira)


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

Ganesh Murthy resolved DISPATCH-1991.
-
Fix Version/s: 1.16.0
   Resolution: Fixed

I am hoping that the fix to DISPATCH-2016 also fixed this problem. I am marking 
this Resolved for now.

> system_tests_tcp_adaptor fails with timeout issue
> -
>
> Key: DISPATCH-1991
> URL: https://issues.apache.org/jira/browse/DISPATCH-1991
> Project: Qpid Dispatch
>  Issue Type: Test
>  Components: Tests
>Affects Versions: 1.15.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.16.0
>
>
> {noformat}
> 1: ==
> 71: FAIL: test_01_tcp_basic_connectivity (system_tests_tcp_adaptor.TcpAdaptor)
> 71: Echo a series of 1-byte messages, one at a time, to prove general 
> connectivity.
> 71: --
> 71: Traceback (most recent call last):
> 71:   File "/home/travis/build/apache/qpid-dispatch/tests/system_test.py", 
> line 919, in wrap
> 71: return f(*args, **kwargs)
> 71:   File 
> "/home/travis/build/apache/qpid-dispatch/tests/system_tests_tcp_adaptor.py", 
> line 626, in test_01_tcp_basic_connectivity
> 71: assert result is None, "TCP_TEST test_01_tcp_basic_connectivity Stop 
> %s FAIL: %s" % (name, result)
> 71: AssertionError: TCP_TEST test_01_tcp_basic_connectivity Stop 
> test_01_tcp_EC1_EA1 FAIL: TCP_TEST TIMEOUT - local wait time exceeded
> 71: 
> 71: ==
> 71: FAIL: test_11_tcp_INTA_INTA_1000 (system_tests_tcp_adaptor.TcpAdaptor)
> 71: --
> 71: Traceback (most recent call last):
> 71:   File "/home/travis/build/apache/qpid-dispatch/tests/system_test.py", 
> line 919, in wrap
> 71: return f(*args, **kwargs)
> 71:   File 
> "/home/travis/build/apache/qpid-dispatch/tests/system_tests_tcp_adaptor.py", 
> line 651, in test_11_tcp_INTA_INTA_1000
> 71: assert result is None, "TCP_TEST Stop %s FAIL: %s" % (name, result)
> 71: AssertionError: TCP_TEST Stop test_11_tcp_INTA_INTA_1000 FAIL: TCP_TEST 
> TIMEOUT - local wait time exceeded
> 71: 
> 71: --
> 71: Ran 7 tests in 75.321s
> 71: 
> 71: FAILED (failures=2)
> 71/73 Test #71: system_tests_tcp_adaptor ..***Failed  
>  75.44 sec {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Created] (PROTON-2365) Build failure without C++

2021-04-01 Thread Fabrice Fontaine (Jira)
Fabrice Fontaine created PROTON-2365:


 Summary: Build failure without C++
 Key: PROTON-2365
 URL: https://issues.apache.org/jira/browse/PROTON-2365
 Project: Qpid Proton
  Issue Type: Bug
  Components: build
Affects Versions: proton-c-0.33.0
Reporter: Fabrice Fontaine
 Attachments: 0003-CMakeLists.txt-fix-build-without-C.patch

For an unknown reason, the following build failure is raised when the toolchain 
does not have a working C++ compiler (with cmake 3.18.4):

 
{code:java}
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:73 (enable_language):
 The CMAKE_CXX_COMPILER:
/home/giuliobenetti/autobuild/run/instance-3/output-1/host/bin/arm-linux-g++
is not a full path to an existing compiler tool.
Tell CMake where to find the compiler by setting either the environment
 variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
 to the compiler, or to the compiler name if it is in the PATH.

-- Configuring incomplete, errors occurred!
{code}
I don't understand why this build failure is raised because 
enable_language(CXX) is correctly protected by
{code:java}
check_language (CXX)
if (CMAKE_CXX_COMPILER){code}
Perhaps, there is a bug inside cmake, to fix it, check for BUILD_CPP



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Commented] (PROTON-2357) [cpp] Improve test coverage in url.cpp

2021-04-01 Thread ASF GitHub Bot (Jira)


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

ASF GitHub Bot commented on PROTON-2357:


DreamPearl commented on pull request #303:
URL: https://github.com/apache/qpid-proton/pull/303#issuecomment-812060580


   @ssorj Can you please take a look and provide suggestions?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> [cpp] Improve test coverage in url.cpp
> --
>
> Key: PROTON-2357
> URL: https://issues.apache.org/jira/browse/PROTON-2357
> Project: Qpid Proton
>  Issue Type: Test
>  Components: cpp-binding
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Major
>  Labels: starter
>
> *Assignee: Rakhi Kumari*
> Url.cpp currently has 76% line coverage after running the tests.  Increase 
> the coverage to 100% or as close as is practical.  To do this, add or modify 
> tests in url_test.cpp.
> To set up coverage builds:
>  # Install lcov, the code coverage tool
>  # Configure the build for coverage analysis: cmake 
> -DCMAKE_BUILD_TYPE=Coverage [...]
>  # Build the code: make build
>  # Run the tests: make test
>  # Generate coverage results: make coverage
>  # View the results at /coverage_results



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[GitHub] [qpid-proton] DreamPearl commented on pull request #303: PROTON-2357: Improve test coverage in url.cpp

2021-04-01 Thread GitBox


DreamPearl commented on pull request #303:
URL: https://github.com/apache/qpid-proton/pull/303#issuecomment-812060580


   @ssorj Can you please take a look and provide suggestions?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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



[jira] [Assigned] (DISPATCH-1991) system_tests_tcp_adaptor fails with timeout issue

2021-04-01 Thread Ken Giusti (Jira)


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

Ken Giusti reassigned DISPATCH-1991:


Assignee: Ganesh Murthy

> system_tests_tcp_adaptor fails with timeout issue
> -
>
> Key: DISPATCH-1991
> URL: https://issues.apache.org/jira/browse/DISPATCH-1991
> Project: Qpid Dispatch
>  Issue Type: Test
>  Components: Tests
>Affects Versions: 1.15.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
>
> {noformat}
> 1: ==
> 71: FAIL: test_01_tcp_basic_connectivity (system_tests_tcp_adaptor.TcpAdaptor)
> 71: Echo a series of 1-byte messages, one at a time, to prove general 
> connectivity.
> 71: --
> 71: Traceback (most recent call last):
> 71:   File "/home/travis/build/apache/qpid-dispatch/tests/system_test.py", 
> line 919, in wrap
> 71: return f(*args, **kwargs)
> 71:   File 
> "/home/travis/build/apache/qpid-dispatch/tests/system_tests_tcp_adaptor.py", 
> line 626, in test_01_tcp_basic_connectivity
> 71: assert result is None, "TCP_TEST test_01_tcp_basic_connectivity Stop 
> %s FAIL: %s" % (name, result)
> 71: AssertionError: TCP_TEST test_01_tcp_basic_connectivity Stop 
> test_01_tcp_EC1_EA1 FAIL: TCP_TEST TIMEOUT - local wait time exceeded
> 71: 
> 71: ==
> 71: FAIL: test_11_tcp_INTA_INTA_1000 (system_tests_tcp_adaptor.TcpAdaptor)
> 71: --
> 71: Traceback (most recent call last):
> 71:   File "/home/travis/build/apache/qpid-dispatch/tests/system_test.py", 
> line 919, in wrap
> 71: return f(*args, **kwargs)
> 71:   File 
> "/home/travis/build/apache/qpid-dispatch/tests/system_tests_tcp_adaptor.py", 
> line 651, in test_11_tcp_INTA_INTA_1000
> 71: assert result is None, "TCP_TEST Stop %s FAIL: %s" % (name, result)
> 71: AssertionError: TCP_TEST Stop test_11_tcp_INTA_INTA_1000 FAIL: TCP_TEST 
> TIMEOUT - local wait time exceeded
> 71: 
> 71: --
> 71: Ran 7 tests in 75.321s
> 71: 
> 71: FAILED (failures=2)
> 71/73 Test #71: system_tests_tcp_adaptor ..***Failed  
>  75.44 sec {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (DISPATCH-1992) [tcp] Use PN_RAW_CONNECTION_DRAIN_BUFFERS in tcp adaptor

2021-04-01 Thread Ken Giusti (Jira)


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

Ken Giusti updated DISPATCH-1992:
-
Fix Version/s: 1.16.0

> [tcp] Use PN_RAW_CONNECTION_DRAIN_BUFFERS in tcp adaptor
> 
>
> Key: DISPATCH-1992
> URL: https://issues.apache.org/jira/browse/DISPATCH-1992
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Protocol Adaptors
>Reporter: Ganesh Murthy
>Assignee: Charles E. Rolke
>Priority: Major
> Fix For: 1.16.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (DISPATCH-1993) [http1] Use PN_RAW_CONNECTION_DRAIN_BUFFERS in http1 adaptor

2021-04-01 Thread Ken Giusti (Jira)


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

Ken Giusti updated DISPATCH-1993:
-
Fix Version/s: 1.17.0

> [http1] Use PN_RAW_CONNECTION_DRAIN_BUFFERS in http1 adaptor
> 
>
> Key: DISPATCH-1993
> URL: https://issues.apache.org/jira/browse/DISPATCH-1993
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Protocol Adaptors
>Reporter: Ganesh Murthy
>Assignee: Ken Giusti
>Priority: Major
> Fix For: 1.17.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Assigned] (DISPATCH-1992) [tcp] Use PN_RAW_CONNECTION_DRAIN_BUFFERS in tcp adaptor

2021-04-01 Thread Ken Giusti (Jira)


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

Ken Giusti reassigned DISPATCH-1992:


Assignee: Charles E. Rolke

> [tcp] Use PN_RAW_CONNECTION_DRAIN_BUFFERS in tcp adaptor
> 
>
> Key: DISPATCH-1992
> URL: https://issues.apache.org/jira/browse/DISPATCH-1992
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Protocol Adaptors
>Reporter: Ganesh Murthy
>Assignee: Charles E. Rolke
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Commented] (PROTON-2357) [cpp] Improve test coverage in url.cpp

2021-04-01 Thread ASF GitHub Bot (Jira)


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

ASF GitHub Bot commented on PROTON-2357:


DreamPearl commented on pull request #303:
URL: https://github.com/apache/qpid-proton/pull/303#issuecomment-812057572


   I think it's not possible to add test coverage for 
`i.clear(std::ios::failbit)` as if we try to make `if(!s.empty())` false then 
`s` has to be empty which means `if(!i.fail() && !i.bad())` will become false. 
Thus the targeted line can not be executed.
   ```cpp
   std::istream& operator>>(std::istream& i, url& u) {
   std::string s;
   i >> s;
   if (!i.fail() && !i.bad()) {
   if (!s.empty()) {
   url::impl* p = new url::impl(s);
   p->defaults();
   u.impl_.reset(p);
   } else {
   i.clear(std::ios::failbit);  // Not covered by test
   }
   }
   return i;
   } 
   ```
   I added the following code snippet in url_test.cpp to test the targeted line 
but it was not getting covered under test coverage.
   
   ```cpp
   {
  url u("amqp://foo:xyz/path");
  std::istringstream i(" ");
  CHECK(false==i.fail());
  i>>u;
  CHECK(std::string("amqp://foo:xyz/path") == std::string(u));
  CHECK(true==i.fail());
   }
   ```


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> [cpp] Improve test coverage in url.cpp
> --
>
> Key: PROTON-2357
> URL: https://issues.apache.org/jira/browse/PROTON-2357
> Project: Qpid Proton
>  Issue Type: Test
>  Components: cpp-binding
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Major
>  Labels: starter
>
> *Assignee: Rakhi Kumari*
> Url.cpp currently has 76% line coverage after running the tests.  Increase 
> the coverage to 100% or as close as is practical.  To do this, add or modify 
> tests in url_test.cpp.
> To set up coverage builds:
>  # Install lcov, the code coverage tool
>  # Configure the build for coverage analysis: cmake 
> -DCMAKE_BUILD_TYPE=Coverage [...]
>  # Build the code: make build
>  # Run the tests: make test
>  # Generate coverage results: make coverage
>  # View the results at /coverage_results



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (DISPATCH-1994) [http2] Use PN_RAW_CONNECTION_DRAIN_BUFFERS in http2 adaptor

2021-04-01 Thread Ken Giusti (Jira)


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

Ken Giusti updated DISPATCH-1994:
-
Fix Version/s: 1.17.0

> [http2] Use PN_RAW_CONNECTION_DRAIN_BUFFERS in http2 adaptor
> 
>
> Key: DISPATCH-1994
> URL: https://issues.apache.org/jira/browse/DISPATCH-1994
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Protocol Adaptors
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.17.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[GitHub] [qpid-proton] DreamPearl commented on pull request #303: [WIP] PROTON-2357: Improve test coverage in url.cpp

2021-04-01 Thread GitBox


DreamPearl commented on pull request #303:
URL: https://github.com/apache/qpid-proton/pull/303#issuecomment-812057572


   I think it's not possible to add test coverage for 
`i.clear(std::ios::failbit)` as if we try to make `if(!s.empty())` false then 
`s` has to be empty which means `if(!i.fail() && !i.bad())` will become false. 
Thus the targeted line can not be executed.
   ```cpp
   std::istream& operator>>(std::istream& i, url& u) {
   std::string s;
   i >> s;
   if (!i.fail() && !i.bad()) {
   if (!s.empty()) {
   url::impl* p = new url::impl(s);
   p->defaults();
   u.impl_.reset(p);
   } else {
   i.clear(std::ios::failbit);  // Not covered by test
   }
   }
   return i;
   } 
   ```
   I added the following code snippet in url_test.cpp to test the targeted line 
but it was not getting covered under test coverage.
   
   ```cpp
   {
  url u("amqp://foo:xyz/path");
  std::istringstream i(" ");
  CHECK(false==i.fail());
  i>>u;
  CHECK(std::string("amqp://foo:xyz/path") == std::string(u));
  CHECK(true==i.fail());
   }
   ```


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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



[jira] [Commented] (PROTON-2355) Build failure with -DPROACTOR=none

2021-04-01 Thread ASF subversion and git services (Jira)


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

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

Commit 2e3b81296020340692139f1a0d05c3bc7383b40e in qpid-proton's branch 
refs/heads/main from Jiri Daněk
[ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=2e3b812 ]

PROTON-2355: Fix build with -DPROACTOR=none (#302)

epoll proactor unconditionally uses pthread.h which will result in the
following build failure:

[  3%] Building C object 
c/CMakeFiles/qpid-proton-proactor-objects.dir/src/proactor/epoll.c.o
In file included from 
/nvme/rc-buildroot-test/scripts/instance-0/output-1/build/qpid-proton-0.33.0/c/src/proactor/epoll.c:60:
/nvme/rc-buildroot-test/scripts/instance-0/output-1/build/qpid-proton-0.33.0/c/src/proactor/epoll-internal.h:37:10:
 fatal error: pthread.h: No such file or directory
   37 | #include 
  |  ^~~

To fix this failure, the user could use -DPROACTOR=none but it also
fails on:

CMake Error at c/CMakeLists.txt:481 (add_library):
  Error evaluating generator expression:

$

  Objects of target "qpid-proton-proactor-objects" referenced but no such
  target exists.

Co-authored-by: Fabrice Fontaine 

> Build failure with -DPROACTOR=none
> --
>
> Key: PROTON-2355
> URL: https://issues.apache.org/jira/browse/PROTON-2355
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: build
>Affects Versions: proton-c-0.33.0
>Reporter: Fabrice Fontaine
>Assignee: Jiri Daněk
>Priority: Major
> Fix For: proton-c-0.34.0
>
> Attachments: 0001-Fix-build-with-DPROACTOR-none.patch
>
>
> Building with -DPROACTOR=none fails on: 
> {code:java}
> CMake Error at c/CMakeLists.txt:481 (add_library):
>  Error evaluating generator expression:
> $
> Objects of target "qpid-proton-proactor-objects" referenced but no such
>  target exists. 
> {code}
> It should also be noted that libqpid-proton-cpp also assumes that a proactor 
> is always available (e.g. pn_connection_wake is unconditionally used in 
> ./cpp/src/connection.cpp).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Resolved] (PROTON-2355) Build failure with -DPROACTOR=none

2021-04-01 Thread Jira


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

Jiri Daněk resolved PROTON-2355.

  Assignee: Jiri Daněk
Resolution: Fixed

> Build failure with -DPROACTOR=none
> --
>
> Key: PROTON-2355
> URL: https://issues.apache.org/jira/browse/PROTON-2355
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: build
>Affects Versions: proton-c-0.33.0
>Reporter: Fabrice Fontaine
>Assignee: Jiri Daněk
>Priority: Major
> Fix For: proton-c-0.34.0
>
> Attachments: 0001-Fix-build-with-DPROACTOR-none.patch
>
>
> Building with -DPROACTOR=none fails on: 
> {code:java}
> CMake Error at c/CMakeLists.txt:481 (add_library):
>  Error evaluating generator expression:
> $
> Objects of target "qpid-proton-proactor-objects" referenced but no such
>  target exists. 
> {code}
> It should also be noted that libqpid-proton-cpp also assumes that a proactor 
> is always available (e.g. pn_connection_wake is unconditionally used in 
> ./cpp/src/connection.cpp).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Commented] (PROTON-2355) Build failure with -DPROACTOR=none

2021-04-01 Thread ASF GitHub Bot (Jira)


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

ASF GitHub Bot commented on PROTON-2355:


jiridanek merged pull request #302:
URL: https://github.com/apache/qpid-proton/pull/302


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Build failure with -DPROACTOR=none
> --
>
> Key: PROTON-2355
> URL: https://issues.apache.org/jira/browse/PROTON-2355
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: build
>Affects Versions: proton-c-0.33.0
>Reporter: Fabrice Fontaine
>Priority: Major
> Fix For: proton-c-0.34.0
>
> Attachments: 0001-Fix-build-with-DPROACTOR-none.patch
>
>
> Building with -DPROACTOR=none fails on: 
> {code:java}
> CMake Error at c/CMakeLists.txt:481 (add_library):
>  Error evaluating generator expression:
> $
> Objects of target "qpid-proton-proactor-objects" referenced but no such
>  target exists. 
> {code}
> It should also be noted that libqpid-proton-cpp also assumes that a proactor 
> is always available (e.g. pn_connection_wake is unconditionally used in 
> ./cpp/src/connection.cpp).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[GitHub] [qpid-proton] jiridanek merged pull request #302: PROTON-2355: Fix build with -DPROACTOR=none

2021-04-01 Thread GitBox


jiridanek merged pull request #302:
URL: https://github.com/apache/qpid-proton/pull/302


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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



[jira] [Updated] (QPIDJMS-531) Update Netty to 4.1.63.Final and tcnative to 2.0.38.Final

2021-04-01 Thread Robbie Gemmell (Jira)


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

Robbie Gemmell updated QPIDJMS-531:
---
Summary: Update Netty to 4.1.63.Final and tcnative to 2.0.38.Final  (was: 
Update Netty to 4.1.62.Final and tcnative to 2.0.38.Final)

> Update Netty to 4.1.63.Final and tcnative to 2.0.38.Final
> -
>
> Key: QPIDJMS-531
> URL: https://issues.apache.org/jira/browse/QPIDJMS-531
> Project: Qpid JMS
>  Issue Type: Task
>  Components: qpid-jms-client
>Affects Versions: 0.57.0
>Reporter: Timothy A. Bish
>Assignee: Timothy A. Bish
>Priority: Minor
> Fix For: 0.58.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (DISPATCH-2013) Http1AdaptorManagementTest fails with AssertionError: 0 != 1 : HTTP connection not deleted

2021-04-01 Thread Ken Giusti (Jira)


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

Ken Giusti updated DISPATCH-2013:
-
Fix Version/s: 1.17.0

> Http1AdaptorManagementTest fails with AssertionError: 0 != 1 : HTTP 
> connection not deleted
> --
>
> Key: DISPATCH-2013
> URL: https://issues.apache.org/jira/browse/DISPATCH-2013
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Protocol Adaptors, Tests
>Affects Versions: 1.16.0
>Reporter: Jiri Daněk
>Assignee: Ken Giusti
>Priority: Major
> Fix For: 1.17.0
>
>
> # 
> https://github.com/jiridanek/qpid-dispatch/runs/2166630124?check_suite_focus=true#step:9:2035
> This is a PR build, not master. I remember seeing the same issue once before, 
> though. I'll make note of it here, in case it reappears again.
> {noformat}
> 71: Trigger Q2 backpressure against the HTTP server. ... ok
> 71: 
> 71: ==
> 71: FAIL: test_01_mgmt (system_tests_http1_adaptor.Http1AdaptorManagementTest)
> 71: Create and delete HTTP1 connectors and listeners
> 71: --
> 71: Traceback (most recent call last):
> 71:   File 
> "/home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/tests/system_tests_http1_adaptor.py",
>  line 464, in test_01_mgmt
> 71: self.assertEqual(0, hconns, msg="HTTP connection not deleted")
> 71: AssertionError: 0 != 1 : HTTP connection not deleted
> 71: 
> 71: --
> 71: Ran 20 tests in 80.903s
> 71: 
> 71: FAILED (failures=1)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Assigned] (DISPATCH-2013) Http1AdaptorManagementTest fails with AssertionError: 0 != 1 : HTTP connection not deleted

2021-04-01 Thread Ken Giusti (Jira)


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

Ken Giusti reassigned DISPATCH-2013:


Assignee: Ken Giusti

> Http1AdaptorManagementTest fails with AssertionError: 0 != 1 : HTTP 
> connection not deleted
> --
>
> Key: DISPATCH-2013
> URL: https://issues.apache.org/jira/browse/DISPATCH-2013
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Protocol Adaptors, Tests
>Affects Versions: 1.16.0
>Reporter: Jiri Daněk
>Assignee: Ken Giusti
>Priority: Major
>
> # 
> https://github.com/jiridanek/qpid-dispatch/runs/2166630124?check_suite_focus=true#step:9:2035
> This is a PR build, not master. I remember seeing the same issue once before, 
> though. I'll make note of it here, in case it reappears again.
> {noformat}
> 71: Trigger Q2 backpressure against the HTTP server. ... ok
> 71: 
> 71: ==
> 71: FAIL: test_01_mgmt (system_tests_http1_adaptor.Http1AdaptorManagementTest)
> 71: Create and delete HTTP1 connectors and listeners
> 71: --
> 71: Traceback (most recent call last):
> 71:   File 
> "/home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/tests/system_tests_http1_adaptor.py",
>  line 464, in test_01_mgmt
> 71: self.assertEqual(0, hconns, msg="HTTP connection not deleted")
> 71: AssertionError: 0 != 1 : HTTP connection not deleted
> 71: 
> 71: --
> 71: Ran 20 tests in 80.903s
> 71: 
> 71: FAILED (failures=1)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (PROTON-2114) [cpp] C++11 examples are not compiled by default

2021-04-01 Thread Robbie Gemmell (Jira)


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

Robbie Gemmell updated PROTON-2114:
---
Fix Version/s: (was: proton-c-0.34.0)
   proton-c-0.35.0
Affects Version/s: proton-c-0.34.0

> [cpp] C++11 examples are not compiled by default
> 
>
> Key: PROTON-2114
> URL: https://issues.apache.org/jira/browse/PROTON-2114
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: build, proton-c
>Affects Versions: proton-c-0.34.0
> Environment: RHEL 7.5
> qpid-proton-cpp-docs-0.26.0-1
> cmake 2.8.12.2
> gcc 4.8.5
> g++ 4.8.5
>Reporter: Nicholas Caughey
>Priority: Major
> Fix For: proton-c-0.35.0
>
>
> These C++11 examples are not compiled by default:
>  * multithreaded_client
>  * multithreaded_client_flow_control
>  * scheduled_send
>  * service_bus
> {{cmake}} is checking CPP11 availability, but it looks that it is not enough 
> and then it does not compile C++11 examples.
> But I am able to compile these examples by:
>  {{g++ .cpp -o  -lqpid-proton-cpp -std=c++11}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (DISPATCH-2014) Router TCP Adapter crash with high thread count and load

2021-04-01 Thread Ken Giusti (Jira)


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

Ken Giusti updated DISPATCH-2014:
-
Fix Version/s: 1.16.0

> Router TCP Adapter crash with high thread count and load
> 
>
> Key: DISPATCH-2014
> URL: https://issues.apache.org/jira/browse/DISPATCH-2014
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Protocol Adaptors
>Reporter: michael goulish
>Priority: Major
> Fix For: 1.16.0
>
>
> Using latest proton and dispatch master code as of 3 hours ago.
> Testing router TCP adapter on a machine with 32 cores / 64 threads.
> I gave the router 64 worker threads, then used 'hey' load generator to send 
> it HTTP requests to a TCP listener which router forwarded to Nginx on same 
> machine. 
> Multiple tests with increasing number of parallel senders: 10, 20, 30,...Each 
> sender throttled to 10 messages per second.
> It survived many tests, but crashed around test with 200 senders.
> I believe this is easily repeatable – I will go check that now.
>  
> Here is the thread that crashed:
> {color:#de350b} #0 0x7f33186a0684 in pthread_mutex_lock () from 
> /lib64/libpthread.so.0{color}
> {color:#de350b} #1 0x7f33186e2848 in lock (m=){color}
> {color:#de350b} at 
> /home/mick/latest/qpid-proton/c/src/proactor/epoll-internal.h:326{color}
> {color:#de350b} #2 process (tsk=){color}
> {color:#de350b} at 
> /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2248{color}
> {color:#de350b} #3 next_event_batch (p=0x10ed970, can_block=true){color}
> {color:#de350b} at 
> /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2423{color}
> {color:#de350b} #4 0x7f33187c192f in thread_run (arg=0x10f6e40){color}
> {color:#de350b} at /home/mick/latest/qpid-dispatch/src/server.c:1107{color}
> {color:#de350b} #5 0x7f331869e3f9 in start_thread () from 
> /lib64/libpthread.so.0{color}
> {color:#de350b} #6 0x7f33181b2b53 in clone () from /lib64/libc.so.6{color}
>  
> {color:#172b4d}And here are all the threads:{color}
> {color:#de350b}(gdb) thread apply all bt{color}
> {color:#de350b}Thread 65 (Thread 0x7f3244ff9640 (LWP 36500)):{color}
> {color:#de350b}#0 0x7f33186a7ea0 in __lll_lock_wait () from 
> /lib64/libpthread.so.0{color}
> {color:#de350b}#1 0x7f33186a08f5 in pthread_mutex_lock () from 
> /lib64/libpthread.so.0{color}
> {color:#de350b}#2 0x7f33186dfc5f in lock (m=0x10edc90) at 
> /home/mick/latest/qpid-proton/c/src/proactor/epoll-internal.h:326{color}
> {color:#de350b}#3 pni_raw_connection_done (rc=0x10ed3b8) at 
> /home/mick/latest/qpid-proton/c/src/proactor/epoll_raw_connection.c:423{color}
> {color:#de350b}#4 pn_proactor_done (batch=0x10ed970, p=0x10ed970) at 
> /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2696{color}
> {color:#de350b}#5 pn_proactor_done (p=0x10ed970, 
> batch=batch@entry=0x7f326811a578) at 
> /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2676{color}
> {color:#de350b}#6 0x7f33187c1a11 in thread_run (arg=0x10f6e40) at 
> /home/mick/latest/qpid-dispatch/src/server.c:1140{color}
> {color:#de350b}#7 0x7f331869e3f9 in start_thread () from 
> /lib64/libpthread.so.0{color}
> {color:#de350b}#8 0x7f33181b2b53 in clone () from /lib64/libc.so.6{color}
> {color:#de350b}Thread 64 (Thread 0x7f327640 (LWP 36481)):{color}
> {color:#de350b}#0 0x7f33186a7ea0 in __lll_lock_wait () from 
> /lib64/libpthread.so.0{color}
> {color:#de350b}#1 0x7f33186a08f5 in pthread_mutex_lock () from 
> /lib64/libpthread.so.0{color}
> {color:#de350b}#2 0x7f33186e2b7e in lock (m=0x10edc90) at 
> /home/mick/latest/qpid-proton/c/src/proactor/epoll-internal.h:326{color}
> {color:#de350b}#3 process (tsk=) at 
> /home/mick/latest/qpid-proton/c/src/proacto--Type  for more, q to quit, 
> c to continue without paging--{color}
> {color:#de350b}r/epoll.c:2248{color}
> {color:#de350b}#4 next_event_batch (p=, can_block=true) at 
> /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2423{color}
> {color:#de350b}#5 0x7f33187c192f in thread_run (arg=0x10f6e40) at 
> /home/mick/latest/qpid-dispatch/src/server.c:1107{color}
> {color:#de350b}#6 0x7f331869e3f9 in start_thread () from 
> /lib64/libpthread.so.0{color}
> {color:#de350b}#7 0x7f33181b2b53 in clone () from /lib64/libc.so.6{color}
> {color:#de350b}Thread 63 (Thread 0x7f322f7fe640 (LWP 36502)):{color}
> {color:#de350b}#0 0x7f33186a7ea0 in __lll_lock_wait () from 
> /lib64/libpthread.so.0{color}
> {color:#de350b}#1 0x7f33186a08f5 in pthread_mutex_lock () from 
> /lib64/libpthread.so.0{color}
> {color:#de350b}#2 0x7f33186dfc5f in lock (m=0x10edc90) at 
> /home/mick/latest/qpid-proton/c/src/proactor/epoll-internal.h:326{color}
> {color:#de350b}#3 pni_raw_connection_done (rc=0x10ed3b8) at 
> /home/mick/latest/qpid-proton/c/src/proactor/epoll

[jira] [Assigned] (DISPATCH-2014) Router TCP Adapter crash with high thread count and load

2021-04-01 Thread Ken Giusti (Jira)


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

Ken Giusti reassigned DISPATCH-2014:


Assignee: Ken Giusti

> Router TCP Adapter crash with high thread count and load
> 
>
> Key: DISPATCH-2014
> URL: https://issues.apache.org/jira/browse/DISPATCH-2014
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Protocol Adaptors
>Reporter: michael goulish
>Assignee: Ken Giusti
>Priority: Major
> Fix For: 1.16.0
>
>
> Using latest proton and dispatch master code as of 3 hours ago.
> Testing router TCP adapter on a machine with 32 cores / 64 threads.
> I gave the router 64 worker threads, then used 'hey' load generator to send 
> it HTTP requests to a TCP listener which router forwarded to Nginx on same 
> machine. 
> Multiple tests with increasing number of parallel senders: 10, 20, 30,...Each 
> sender throttled to 10 messages per second.
> It survived many tests, but crashed around test with 200 senders.
> I believe this is easily repeatable – I will go check that now.
>  
> Here is the thread that crashed:
> {color:#de350b} #0 0x7f33186a0684 in pthread_mutex_lock () from 
> /lib64/libpthread.so.0{color}
> {color:#de350b} #1 0x7f33186e2848 in lock (m=){color}
> {color:#de350b} at 
> /home/mick/latest/qpid-proton/c/src/proactor/epoll-internal.h:326{color}
> {color:#de350b} #2 process (tsk=){color}
> {color:#de350b} at 
> /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2248{color}
> {color:#de350b} #3 next_event_batch (p=0x10ed970, can_block=true){color}
> {color:#de350b} at 
> /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2423{color}
> {color:#de350b} #4 0x7f33187c192f in thread_run (arg=0x10f6e40){color}
> {color:#de350b} at /home/mick/latest/qpid-dispatch/src/server.c:1107{color}
> {color:#de350b} #5 0x7f331869e3f9 in start_thread () from 
> /lib64/libpthread.so.0{color}
> {color:#de350b} #6 0x7f33181b2b53 in clone () from /lib64/libc.so.6{color}
>  
> {color:#172b4d}And here are all the threads:{color}
> {color:#de350b}(gdb) thread apply all bt{color}
> {color:#de350b}Thread 65 (Thread 0x7f3244ff9640 (LWP 36500)):{color}
> {color:#de350b}#0 0x7f33186a7ea0 in __lll_lock_wait () from 
> /lib64/libpthread.so.0{color}
> {color:#de350b}#1 0x7f33186a08f5 in pthread_mutex_lock () from 
> /lib64/libpthread.so.0{color}
> {color:#de350b}#2 0x7f33186dfc5f in lock (m=0x10edc90) at 
> /home/mick/latest/qpid-proton/c/src/proactor/epoll-internal.h:326{color}
> {color:#de350b}#3 pni_raw_connection_done (rc=0x10ed3b8) at 
> /home/mick/latest/qpid-proton/c/src/proactor/epoll_raw_connection.c:423{color}
> {color:#de350b}#4 pn_proactor_done (batch=0x10ed970, p=0x10ed970) at 
> /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2696{color}
> {color:#de350b}#5 pn_proactor_done (p=0x10ed970, 
> batch=batch@entry=0x7f326811a578) at 
> /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2676{color}
> {color:#de350b}#6 0x7f33187c1a11 in thread_run (arg=0x10f6e40) at 
> /home/mick/latest/qpid-dispatch/src/server.c:1140{color}
> {color:#de350b}#7 0x7f331869e3f9 in start_thread () from 
> /lib64/libpthread.so.0{color}
> {color:#de350b}#8 0x7f33181b2b53 in clone () from /lib64/libc.so.6{color}
> {color:#de350b}Thread 64 (Thread 0x7f327640 (LWP 36481)):{color}
> {color:#de350b}#0 0x7f33186a7ea0 in __lll_lock_wait () from 
> /lib64/libpthread.so.0{color}
> {color:#de350b}#1 0x7f33186a08f5 in pthread_mutex_lock () from 
> /lib64/libpthread.so.0{color}
> {color:#de350b}#2 0x7f33186e2b7e in lock (m=0x10edc90) at 
> /home/mick/latest/qpid-proton/c/src/proactor/epoll-internal.h:326{color}
> {color:#de350b}#3 process (tsk=) at 
> /home/mick/latest/qpid-proton/c/src/proacto--Type  for more, q to quit, 
> c to continue without paging--{color}
> {color:#de350b}r/epoll.c:2248{color}
> {color:#de350b}#4 next_event_batch (p=, can_block=true) at 
> /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2423{color}
> {color:#de350b}#5 0x7f33187c192f in thread_run (arg=0x10f6e40) at 
> /home/mick/latest/qpid-dispatch/src/server.c:1107{color}
> {color:#de350b}#6 0x7f331869e3f9 in start_thread () from 
> /lib64/libpthread.so.0{color}
> {color:#de350b}#7 0x7f33181b2b53 in clone () from /lib64/libc.so.6{color}
> {color:#de350b}Thread 63 (Thread 0x7f322f7fe640 (LWP 36502)):{color}
> {color:#de350b}#0 0x7f33186a7ea0 in __lll_lock_wait () from 
> /lib64/libpthread.so.0{color}
> {color:#de350b}#1 0x7f33186a08f5 in pthread_mutex_lock () from 
> /lib64/libpthread.so.0{color}
> {color:#de350b}#2 0x7f33186dfc5f in lock (m=0x10edc90) at 
> /home/mick/latest/qpid-proton/c/src/proactor/epoll-internal.h:326{color}
> {color:#de350b}#3 pni_raw_connection_done (rc=0x10ed3b8) at 
> /home/mick

[jira] [Updated] (DISPATCH-2018) Improper handling of link refusal when destination peer for link-routing goes away

2021-04-01 Thread Ken Giusti (Jira)


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

Ken Giusti updated DISPATCH-2018:
-
Fix Version/s: 1.16.0

> Improper handling of link refusal when destination peer for link-routing goes 
> away
> --
>
> Key: DISPATCH-2018
> URL: https://issues.apache.org/jira/browse/DISPATCH-2018
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 1.14.0
>Reporter: Robbie Gemmell
>Assignee: Ken Giusti
>Priority: Major
> Fix For: 1.16.0
>
>
> In case of a router doing link routing to a broker, which goes away during an 
> error handling test, the router can then need to refuse new links and/or kill 
> existing links as it has nowhere to route them. That is all to be expected.
> When failing to attach some sender links though, it was observed the router 
> in one case did not response to a clients attach at all, and in a second case 
> incorrectly sent a response attach with a populated target, having address = 
> null, followed by a detach with error (which looks to lead to some unexpected 
> client behaviour as it was mislead into thinking the producer actually 
> opened, likely exposing a separate client issue).
> The attach in the second case should have had target=null, rather than a null 
> address, to indicate that this was a link refusal and the detach with error 
> would follow:
> {noformat}
> [1475580346:1] -> 
> Attach\{name='qpid-jms:sender:ID:cc949561-56bc-44f7-8d96-74f8a8d49988:521:8:1:destination',
>  handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
> source=Source{address='ID:cc949561-56bc-44f7-8d96-74f8a8d49988:521:8:1', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, distributionMode=null, filter=null, 
> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list, 
> amqp:released:list, amqp:modified:list], capabilities=null}, 
> target=Target\{address='destination', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=null, offeredCapabilities=null, 
> desiredCapabilities=[DELAYED_DELIVERY], properties=null}
> [1475580346:1] <- 
> Attach\{name='qpid-jms:sender:ID:cc949561-56bc-44f7-8d96-74f8a8d49988:521:8:1:destination',
>  handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST, 
> source=Source{address='ID:cc949561-56bc-44f7-8d96-74f8a8d49988:521:8:1', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, distributionMode=null, filter=null, 
> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list, 
> amqp:released:list, amqp:modified:list], capabilities=null}, 
> target=Target\{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, 
> properties=null}
> [1475580346:1] <- Detach\{handle=0, closed=true, 
> error=Error{condition=qd:no-route-to-dest, description='No route to the 
> destination node', info=null}}
> {noformat}
> In a third related instant earlier in the testing, the router did actually do 
> the correct thing while returning a [different] error, ommitting the attach 
> target entirely as is directed by the protocol spec:
> {noformat}
> [851826403:1] -> 
> Attach\{name='qpid-jms:sender:ID:d070acab-905f-45a7-b663-14d35547ab3e:3:25:1:destination',
>  handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
> source=Source{address='ID:d070acab-905f-45a7-b663-14d35547ab3e:3:25:1', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, distributionMode=null, filter=null, 
> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list, 
> amqp:released:list, amqp:modified:list], capabilities=null}, 
> target=Target\{address='destination', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=null, offeredCapabilities=null, 
> desiredCapabilities=[DELAYED_DELIVERY], properties=null}
> [851826403:1] <- 
> Attach\{name='qpid-jms:sender:ID:d070acab-905f-45a7-b663-14d35547ab3e:3:25:1:destination',
>  handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST, 
> source=Source{address='ID:d070acab-905f-45a7-b663-14d35547ab3e:3:25:1', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, distributionMode=nu

[jira] [Updated] (PROTON-2240) epoll proactor leaks connection resources

2021-04-01 Thread Robbie Gemmell (Jira)


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

Robbie Gemmell updated PROTON-2240:
---
Fix Version/s: (was: proton-c-0.34.0)
   proton-c-0.35.0
Affects Version/s: proton-c-0.34.0

> epoll proactor leaks connection resources
> -
>
> Key: PROTON-2240
> URL: https://issues.apache.org/jira/browse/PROTON-2240
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.31.0, proton-c-0.32.0, proton-c-0.33.0, 
> proton-c-0.34.0
>Reporter: Clifford Jansen
>Assignee: Clifford Jansen
>Priority: Major
> Fix For: proton-c-0.35.0
>
>
> Running the same test case from PROTON-2239 on the epoll proactor in master 
> results in the opposite problem.  Instead of occasional double frees, in this 
> case the cleanup process stalls waiting for a pending timeout.  Memory is not 
> reclaimed and file descriptors are not closed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Assigned] (DISPATCH-2018) Improper handling of link refusal when destination peer for link-routing goes away

2021-04-01 Thread Ken Giusti (Jira)


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

Ken Giusti reassigned DISPATCH-2018:


Assignee: Ken Giusti

> Improper handling of link refusal when destination peer for link-routing goes 
> away
> --
>
> Key: DISPATCH-2018
> URL: https://issues.apache.org/jira/browse/DISPATCH-2018
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 1.14.0
>Reporter: Robbie Gemmell
>Assignee: Ken Giusti
>Priority: Major
>
> In case of a router doing link routing to a broker, which goes away during an 
> error handling test, the router can then need to refuse new links and/or kill 
> existing links as it has nowhere to route them. That is all to be expected.
> When failing to attach some sender links though, it was observed the router 
> in one case did not response to a clients attach at all, and in a second case 
> incorrectly sent a response attach with a populated target, having address = 
> null, followed by a detach with error (which looks to lead to some unexpected 
> client behaviour as it was mislead into thinking the producer actually 
> opened, likely exposing a separate client issue).
> The attach in the second case should have had target=null, rather than a null 
> address, to indicate that this was a link refusal and the detach with error 
> would follow:
> {noformat}
> [1475580346:1] -> 
> Attach\{name='qpid-jms:sender:ID:cc949561-56bc-44f7-8d96-74f8a8d49988:521:8:1:destination',
>  handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
> source=Source{address='ID:cc949561-56bc-44f7-8d96-74f8a8d49988:521:8:1', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, distributionMode=null, filter=null, 
> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list, 
> amqp:released:list, amqp:modified:list], capabilities=null}, 
> target=Target\{address='destination', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=null, offeredCapabilities=null, 
> desiredCapabilities=[DELAYED_DELIVERY], properties=null}
> [1475580346:1] <- 
> Attach\{name='qpid-jms:sender:ID:cc949561-56bc-44f7-8d96-74f8a8d49988:521:8:1:destination',
>  handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST, 
> source=Source{address='ID:cc949561-56bc-44f7-8d96-74f8a8d49988:521:8:1', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, distributionMode=null, filter=null, 
> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list, 
> amqp:released:list, amqp:modified:list], capabilities=null}, 
> target=Target\{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, 
> properties=null}
> [1475580346:1] <- Detach\{handle=0, closed=true, 
> error=Error{condition=qd:no-route-to-dest, description='No route to the 
> destination node', info=null}}
> {noformat}
> In a third related instant earlier in the testing, the router did actually do 
> the correct thing while returning a [different] error, ommitting the attach 
> target entirely as is directed by the protocol spec:
> {noformat}
> [851826403:1] -> 
> Attach\{name='qpid-jms:sender:ID:d070acab-905f-45a7-b663-14d35547ab3e:3:25:1:destination',
>  handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
> source=Source{address='ID:d070acab-905f-45a7-b663-14d35547ab3e:3:25:1', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, distributionMode=null, filter=null, 
> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list, 
> amqp:released:list, amqp:modified:list], capabilities=null}, 
> target=Target\{address='destination', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=null, offeredCapabilities=null, 
> desiredCapabilities=[DELAYED_DELIVERY], properties=null}
> [851826403:1] <- 
> Attach\{name='qpid-jms:sender:ID:d070acab-905f-45a7-b663-14d35547ab3e:3:25:1:destination',
>  handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST, 
> source=Source{address='ID:d070acab-905f-45a7-b663-14d35547ab3e:3:25:1', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, distributionMode=null, filter=null, 
> defaul

[jira] [Assigned] (DISPATCH-2019) Error in system_tests_http2 SEGV in qdr_core_remove_address

2021-04-01 Thread Ken Giusti (Jira)


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

Ken Giusti reassigned DISPATCH-2019:


Assignee: Ganesh Murthy

> Error in system_tests_http2 SEGV in qdr_core_remove_address
> ---
>
> Key: DISPATCH-2019
> URL: https://issues.apache.org/jira/browse/DISPATCH-2019
> Project: Qpid Dispatch
>  Issue Type: Test
>Affects Versions: 1.16.0
>Reporter: Jiri Daněk
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.16.0
>
>
> https://travis-ci.com/github/apache/qpid-dispatch/jobs/493886831#L5794
> {noformat}
> 68: Router QDR output file:
> 68: 
> 68: 
> /home/travis/build/apache/qpid-dispatch/src/router_core/router_core.c:582:13: 
> runtime error: applying zero offset to null pointer
> 68: SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
> /home/travis/build/apache/qpid-dispatch/src/router_core/router_core.c:582:13 
> in 
> 68: 
> /home/travis/build/apache/qpid-dispatch/src/router_core/router_core.c:582:13: 
> runtime error: load of null pointer of type 'const char'
> 68: SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
> /home/travis/build/apache/qpid-dispatch/src/router_core/router_core.c:582:13 
> in 
> 68: AddressSanitizer:DEADLYSIGNAL
> 68: =
> 68: ==17754==ERROR: AddressSanitizer: SEGV on unknown address 0x 
> (pc 0x7f2611ba3318 bp 0x7f260be8d150 sp 0x7f260be8d100 T1)
> 68: ==17754==The signal is caused by a READ memory access.
> 68: ==17754==Hint: address points to the zero page.
> 68: #0 0x7f2611ba3318 in qdr_core_remove_address 
> /home/travis/build/apache/qpid-dispatch/src/router_core/router_core.c:582:13
> 68: #1 0x7f2611b30c71 in qdr_check_addr_CT 
> /home/travis/build/apache/qpid-dispatch/src/router_core/connections.c:1328:9
> 68: #2 0x7f2611b29e36 in qdr_link_inbound_detach_CT 
> /home/travis/build/apache/qpid-dispatch/src/router_core/connections.c:2110:9
> 68: #3 0x7f2611bb8651 in router_core_thread 
> /home/travis/build/apache/qpid-dispatch/src/router_core/router_core_thread.c:239:13
> 68: #4 0x7f26116a0608 in start_thread 
> (/lib/x86_64-linux-gnu/libpthread.so.0+0x9608)
> 68: #5 0x7f2610ecb292 in clone (/lib/x86_64-linux-gnu/libc.so.6+0x122292)
> 68: 
> 68: AddressSanitizer can not provide additional info.
> 68: SUMMARY: AddressSanitizer: SEGV 
> /home/travis/build/apache/qpid-dispatch/src/router_core/router_core.c:582:13 
> in qdr_core_remove_address
> 68: Thread T1 created by T0 here:
> 68: #0 0x480f0a in pthread_create 
> (/home/travis/build/apache/qpid-dispatch/build/router/qdrouterd+0x480f0a)
> 68: #1 0x7f2611ae4b4d in sys_thread 
> /home/travis/build/apache/qpid-dispatch/src/posix/threading.c:181:5
> 68: #2 0x7f2611b98d20 in qdr_core 
> /home/travis/build/apache/qpid-dispatch/src/router_core/router_core.c:121:20
> 68: #3 0x7f2611c26878 in qd_router_setup_late 
> /home/travis/build/apache/qpid-dispatch/src/router_node.c:2107:31
> 68: #4 0x7f260d7a9ff4  (/lib/x86_64-linux-gnu/libffi.so.7+0x6ff4)
> 68: LLVMSymbolizer: error reading file: No such file or directory
> 68: #5 0x7ffed1c889ef  ([stack]+0x1d9ef)
> 68: 
> 68: ==17754==ABORTING
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (DISPATCH-2019) Error in system_tests_http2 SEGV in qdr_core_remove_address

2021-04-01 Thread Ken Giusti (Jira)


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

Ken Giusti updated DISPATCH-2019:
-
Fix Version/s: 1.16.0

> Error in system_tests_http2 SEGV in qdr_core_remove_address
> ---
>
> Key: DISPATCH-2019
> URL: https://issues.apache.org/jira/browse/DISPATCH-2019
> Project: Qpid Dispatch
>  Issue Type: Test
>Affects Versions: 1.16.0
>Reporter: Jiri Daněk
>Priority: Major
> Fix For: 1.16.0
>
>
> https://travis-ci.com/github/apache/qpid-dispatch/jobs/493886831#L5794
> {noformat}
> 68: Router QDR output file:
> 68: 
> 68: 
> /home/travis/build/apache/qpid-dispatch/src/router_core/router_core.c:582:13: 
> runtime error: applying zero offset to null pointer
> 68: SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
> /home/travis/build/apache/qpid-dispatch/src/router_core/router_core.c:582:13 
> in 
> 68: 
> /home/travis/build/apache/qpid-dispatch/src/router_core/router_core.c:582:13: 
> runtime error: load of null pointer of type 'const char'
> 68: SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
> /home/travis/build/apache/qpid-dispatch/src/router_core/router_core.c:582:13 
> in 
> 68: AddressSanitizer:DEADLYSIGNAL
> 68: =
> 68: ==17754==ERROR: AddressSanitizer: SEGV on unknown address 0x 
> (pc 0x7f2611ba3318 bp 0x7f260be8d150 sp 0x7f260be8d100 T1)
> 68: ==17754==The signal is caused by a READ memory access.
> 68: ==17754==Hint: address points to the zero page.
> 68: #0 0x7f2611ba3318 in qdr_core_remove_address 
> /home/travis/build/apache/qpid-dispatch/src/router_core/router_core.c:582:13
> 68: #1 0x7f2611b30c71 in qdr_check_addr_CT 
> /home/travis/build/apache/qpid-dispatch/src/router_core/connections.c:1328:9
> 68: #2 0x7f2611b29e36 in qdr_link_inbound_detach_CT 
> /home/travis/build/apache/qpid-dispatch/src/router_core/connections.c:2110:9
> 68: #3 0x7f2611bb8651 in router_core_thread 
> /home/travis/build/apache/qpid-dispatch/src/router_core/router_core_thread.c:239:13
> 68: #4 0x7f26116a0608 in start_thread 
> (/lib/x86_64-linux-gnu/libpthread.so.0+0x9608)
> 68: #5 0x7f2610ecb292 in clone (/lib/x86_64-linux-gnu/libc.so.6+0x122292)
> 68: 
> 68: AddressSanitizer can not provide additional info.
> 68: SUMMARY: AddressSanitizer: SEGV 
> /home/travis/build/apache/qpid-dispatch/src/router_core/router_core.c:582:13 
> in qdr_core_remove_address
> 68: Thread T1 created by T0 here:
> 68: #0 0x480f0a in pthread_create 
> (/home/travis/build/apache/qpid-dispatch/build/router/qdrouterd+0x480f0a)
> 68: #1 0x7f2611ae4b4d in sys_thread 
> /home/travis/build/apache/qpid-dispatch/src/posix/threading.c:181:5
> 68: #2 0x7f2611b98d20 in qdr_core 
> /home/travis/build/apache/qpid-dispatch/src/router_core/router_core.c:121:20
> 68: #3 0x7f2611c26878 in qd_router_setup_late 
> /home/travis/build/apache/qpid-dispatch/src/router_node.c:2107:31
> 68: #4 0x7f260d7a9ff4  (/lib/x86_64-linux-gnu/libffi.so.7+0x6ff4)
> 68: LLVMSymbolizer: error reading file: No such file or directory
> 68: #5 0x7ffed1c889ef  ([stack]+0x1d9ef)
> 68: 
> 68: ==17754==ABORTING
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (DISPATCH-2022) system_tests_link_routes rarely fails with Cannot load configuration file

2021-04-01 Thread Ken Giusti (Jira)


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

Ken Giusti updated DISPATCH-2022:
-
Fix Version/s: 1.17.0

> system_tests_link_routes rarely fails with Cannot load configuration file
> -
>
> Key: DISPATCH-2022
> URL: https://issues.apache.org/jira/browse/DISPATCH-2022
> Project: Qpid Dispatch
>  Issue Type: Test
>Affects Versions: 1.16.0
>Reporter: Jiri Daněk
>Priority: Minor
> Fix For: 1.17.0
>
>
> The following happens every time on AArch64, but it has once happened on 
> amd64 too:
> https://github.com/apache/qpid-dispatch/runs/2183106014?check_suite_focus=true#step:9:652
> {noformat}
> 14: Process 2203 error: still running
> 14: qdrouterd -c X.conf -I 
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/python
> 14: 
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/build/tests/system_test.dir/system_tests_link_routes/ConnectionLinkRouteTest/test_config_file_bad/X-3.cmd
> 14: 
> 14: 2021-03-24 10:05:46.694485 + AGENT (error) Contents of failed config 
> file
> 14: 2021-03-24 10:05:46.694657 + AGENT (error) Line 1 |[["router", {
> 14: 2021-03-24 10:05:46.694701 + AGENT (error) Line 2 |"mode": "interior",
> 14: 2021-03-24 10:05:46.694738 + AGENT (error) Line 3 |"id": "QDR.X",
> 14: 2021-03-24 10:05:46.694772 + AGENT (error) Line 4 |"debugDumpFile": 
> "/home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/build/tests/system_test.dir/system_tests_link_routes/ConnectionLinkRouteTest/test_config_file_bad/X-qddebug.txt"}],
> 14: 2021-03-24 10:05:46.694806 + AGENT (error) Line 5 |["listener", {
> 14: 2021-03-24 10:05:46.694838 + AGENT (error) Line 6 |"role": "normal",
> 14: 2021-03-24 10:05:46.694870 + AGENT (error) Line 7 |"host": "0.0.0.0",
> 14: 2021-03-24 10:05:46.694902 + AGENT (error) Line 8 |"port": "25577",
> 14: 2021-03-24 10:05:46.694935 + AGENT (error) Line 9 |"saslMechanisms": 
> "ANONYMOUS",
> 14: 2021-03-24 10:05:46.694967 + AGENT (error) Line 10 
> |"idleTimeoutSeconds": "120",
> 14: 2021-03-24 10:05:46.694999 + AGENT (error) Line 11 
> |"authenticatePeer": "no"}],
> 14: 2021-03-24 10:05:46.695030 + AGENT (error) Line 12 
> |connection.["linkRoute", {
> 14: 2021-03-24 10:05:46.695062 + AGENT (error) Line 13 |"pattern": 
> "i/am/bad",
> 14: 2021-03-24 10:05:46.695094 + AGENT (error) Line 14 |"direction": 
> "out"}],
> 14: 2021-03-24 10:05:46.695130 + AGENT (error) Line 15 |["log", {
> 14: 2021-03-24 10:05:46.695200 + AGENT (error) Line 16 |"module": 
> "DEFAULT",
> 14: 2021-03-24 10:05:46.695235 + AGENT (error) Line 17 |"enable": 
> "trace+",
> 14: 2021-03-24 10:05:46.695267 + AGENT (error) Line 18 |"includeSource": 
> "true",
> 14: 2021-03-24 10:05:46.695298 + AGENT (error) Line 19 |"outputFile": 
> "X.log"}]]
> 14: 2021-03-24 10:05:46.695369 + ERROR (error) Python: Exception: Cannot 
> load configuration file X.conf: Expecting value: line 12 column 1 (char 400)
> 14: 2021-03-24 10:05:46.738956 + ERROR (error) Traceback (most recent 
> call last):
> 14:   File 
> "/home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
>  line 61, in __init__
> 14: self.load(filename, raw_json)
> 14:   File 
> "/home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
>  line 242, in load
> 14: self.load(f, raw_json)
> 14:   File 
> "/home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
>  line 244, in load
> 14: sections = self._parserawjson(source) if raw_json else 
> self._parse(source)
> 14:   File 
> "/home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
>  line 208, in _parse
> 14: sections = json.loads(js_text)
> 14:   File 
> "/opt/hostedtoolcache/Python/3.7.10/x64/lib/python3.7/json/__init__.py", line 
> 348, in loads
> 14: return _default_decoder.decode(s)
> 14:   File 
> "/opt/hostedtoolcache/Python/3.7.10/x64/lib/python3.7/json/decoder.py", line 
> 337, in decode
> 14: obj, end = self.raw_decode(s, idx=_w(s, 0).end())
> 14:   File 
> "/opt/hostedtoolcache/Python/3.7.10/x64/lib/python3.7/json/decoder.py", line 
> 355, in raw_decode
> 14: raise JSONDecodeError("Expecting value", s, err.value) from None
> 14: json.decoder.JSONDecodeError: Expecting value: line 12 column 1 (char 400)
> 14: 
> 14: During handling of the above exception, another exception occurred:
> 14: 
> 14: Traceback (most recent call last):
> 14:   File 
> "/home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
>  line 286, in 

[jira] [Updated] (DISPATCH-2023) system_tests_edge_router AttributeError: 'MobileAddressEventTest' object has no attribute 'reactor'

2021-04-01 Thread Ken Giusti (Jira)


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

Ken Giusti updated DISPATCH-2023:
-
Fix Version/s: 1.16.0

> system_tests_edge_router AttributeError: 'MobileAddressEventTest' object has 
> no attribute 'reactor'
> ---
>
> Key: DISPATCH-2023
> URL: https://issues.apache.org/jira/browse/DISPATCH-2023
> Project: Qpid Dispatch
>  Issue Type: Test
>Affects Versions: 1.16.0
>Reporter: Jiri Daněk
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.16.0
>
>
> https://travis-ci.com/github/apache/qpid-dispatch/jobs/494183504#L4957
> {noformat}
> 54: ==
> 54: ERROR: test_39_mobile_addr_event_three_receivers_diff_interior 
> (system_tests_edge_router.RouterTest)
> 54: --
> 54: Traceback (most recent call last):
> 54: File 
> "/home/travis/build/apache/qpid-dispatch/tests/system_tests_edge_router.py", 
> line 868, in test_39_mobile_addr_event_three_receivers_diff_interior
> 54: test.run()
> 54: File 
> "/home/travis/build/apache/qpid-dispatch/tests/system_tests_edge_router.py", 
> line 2917, in run
> 54: Container(self).run()
> 54: File 
> "/home/travis/build/apache/qpid-dispatch/qpid-proton/python/proton/_reactor.py",
>  line 182, in run
> 54: while self.process():
> 54: File 
> "/home/travis/build/apache/qpid-dispatch/qpid-proton/python/proton/_reactor.py",
>  line 240, in process
> 54: event.dispatch(handler)
> 54: File 
> "/home/travis/build/apache/qpid-dispatch/qpid-proton/python/proton/_events.py",
>  line 162, in dispatch
> 54: _dispatch(handler, type.method, self)
> 54: File 
> "/home/travis/build/apache/qpid-dispatch/qpid-proton/python/proton/_events.py",
>  line 123, in _dispatch
> 54: m(*args)
> 54: File 
> "/home/travis/build/apache/qpid-dispatch/tests/system_tests_edge_router.py", 
> line 54, in on_timer_task
> 54: self.parent.check_address()
> 54: File 
> "/home/travis/build/apache/qpid-dispatch/tests/system_tests_edge_router.py", 
> line 2836, in check_address
> 54: self.addr_timer = self.reactor.schedule(1.0, AddrTimer(self))
> 54: AttributeError: 'MobileAddressEventTest' object has no attribute 'reactor'
> 54: 
> 54: --
> 54: Ran 89 tests in 225.543s
> 54: 
> 54: FAILED (errors=1)
> 54/73 Test #54: system_tests_edge_router ..***Failed 
> 225.70 sec
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Assigned] (DISPATCH-2023) system_tests_edge_router AttributeError: 'MobileAddressEventTest' object has no attribute 'reactor'

2021-04-01 Thread Ken Giusti (Jira)


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

Ken Giusti reassigned DISPATCH-2023:


Assignee: Ganesh Murthy

> system_tests_edge_router AttributeError: 'MobileAddressEventTest' object has 
> no attribute 'reactor'
> ---
>
> Key: DISPATCH-2023
> URL: https://issues.apache.org/jira/browse/DISPATCH-2023
> Project: Qpid Dispatch
>  Issue Type: Test
>Affects Versions: 1.16.0
>Reporter: Jiri Daněk
>Assignee: Ganesh Murthy
>Priority: Major
>
> https://travis-ci.com/github/apache/qpid-dispatch/jobs/494183504#L4957
> {noformat}
> 54: ==
> 54: ERROR: test_39_mobile_addr_event_three_receivers_diff_interior 
> (system_tests_edge_router.RouterTest)
> 54: --
> 54: Traceback (most recent call last):
> 54: File 
> "/home/travis/build/apache/qpid-dispatch/tests/system_tests_edge_router.py", 
> line 868, in test_39_mobile_addr_event_three_receivers_diff_interior
> 54: test.run()
> 54: File 
> "/home/travis/build/apache/qpid-dispatch/tests/system_tests_edge_router.py", 
> line 2917, in run
> 54: Container(self).run()
> 54: File 
> "/home/travis/build/apache/qpid-dispatch/qpid-proton/python/proton/_reactor.py",
>  line 182, in run
> 54: while self.process():
> 54: File 
> "/home/travis/build/apache/qpid-dispatch/qpid-proton/python/proton/_reactor.py",
>  line 240, in process
> 54: event.dispatch(handler)
> 54: File 
> "/home/travis/build/apache/qpid-dispatch/qpid-proton/python/proton/_events.py",
>  line 162, in dispatch
> 54: _dispatch(handler, type.method, self)
> 54: File 
> "/home/travis/build/apache/qpid-dispatch/qpid-proton/python/proton/_events.py",
>  line 123, in _dispatch
> 54: m(*args)
> 54: File 
> "/home/travis/build/apache/qpid-dispatch/tests/system_tests_edge_router.py", 
> line 54, in on_timer_task
> 54: self.parent.check_address()
> 54: File 
> "/home/travis/build/apache/qpid-dispatch/tests/system_tests_edge_router.py", 
> line 2836, in check_address
> 54: self.addr_timer = self.reactor.schedule(1.0, AddrTimer(self))
> 54: AttributeError: 'MobileAddressEventTest' object has no attribute 'reactor'
> 54: 
> 54: --
> 54: Ran 89 tests in 225.543s
> 54: 
> 54: FAILED (errors=1)
> 54/73 Test #54: system_tests_edge_router ..***Failed 
> 225.70 sec
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Resolved] (PROTON-2343) Simplify and clean up build flag selection for different compilers

2021-04-01 Thread Robbie Gemmell (Jira)


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

Robbie Gemmell resolved PROTON-2343.

Resolution: Fixed

> Simplify and clean up build flag selection for different compilers
> --
>
> Key: PROTON-2343
> URL: https://issues.apache.org/jira/browse/PROTON-2343
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: proton-c-0.33.0
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
>Priority: Major
> Fix For: proton-c-0.34.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (DISPATCH-2024) [libuv] system_tests_two_routers delivery state AssertionError: MODIFIED != RELEASED

2021-04-01 Thread Ken Giusti (Jira)


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

Ken Giusti updated DISPATCH-2024:
-
Fix Version/s: 1.17.0

> [libuv] system_tests_two_routers delivery state AssertionError: MODIFIED != 
> RELEASED
> 
>
> Key: DISPATCH-2024
> URL: https://issues.apache.org/jira/browse/DISPATCH-2024
> Project: Qpid Dispatch
>  Issue Type: Test
>Affects Versions: 1.16.0
>Reporter: Jiri Daněk
>Priority: Major
> Fix For: 1.17.0
>
>
> This is using the libuv proactor on Linux
> https://github.com/jiridanek/qpid-dispatch/runs/2208416852#step:9:1035
> {noformat}
> 34: test_10a_propagated_disposition_data 
> (system_tests_two_routers.TwoRouterTest) ... FAIL
> 34: test_11_three_ack (system_tests_two_routers.TwoRouterTest) ... ok
> 34: test_12_excess_deliveries_released 
> (system_tests_two_routers.TwoRouterTest)
> 34: Message-route a series of deliveries where the receiver provides credit 
> for a subset and ... ok
> 34: test_15_attach_on_inter_router (system_tests_two_routers.TwoRouterTest) 
> ... ok
> 34: test_17_address_wildcard (system_tests_two_routers.TwoRouterTest) ... ok
> 34: test_17_large_streaming_test (system_tests_two_routers.TwoRouterTest) ... 
> ok
> 34: test_18_single_char_dest_test (system_tests_two_routers.TwoRouterTest) 
> ... ok
> 34: test_19_delete_inter_router_connection 
> (system_tests_two_routers.TwoRouterTest)
> 34: This test tries to delete an inter-router connection but is ... ok
> 34: test_20_delete_connection (system_tests_two_routers.TwoRouterTest)
> 34: This test creates a blocking connection and tries to delete that 
> connection. ... ok
> 34: test_21_delete_connection_with_receiver 
> (system_tests_two_routers.TwoRouterTest) ... ok
> 34: test_30_huge_address (system_tests_two_routers.TwoRouterTest) ... ok
> 34: 
> 34: Router QDR.B debug dump file:
> 34: 
> 34: alloc.c: Items of type 'qd_iterator_t' remain allocated at shutdown: 28 
> (SUPPRESSED)
> 34: alloc.c: Items of type 'qd_timer_t' remain allocated at shutdown: 1 
> (SUPPRESSED)
> 34: alloc.c: Items of type 'qd_bitmask_t' remain allocated at shutdown: 3 
> (SUPPRESSED)
> 34: alloc.c: Items of type 'qdr_action_t' remain allocated at shutdown: 1 
> (SUPPRESSED)
> 34: alloc.c: Items of type 'qd_buffer_t' remain allocated at shutdown: 11 
> (SUPPRESSED)
> 34: alloc.c: Items of type 'qd_parsed_field_t' remain allocated at shutdown: 
> 11 (SUPPRESSED)
> 34: alloc.c: Items of type 'qd_connector_t' remain allocated at shutdown: 1 
> (SUPPRESSED)
> 34: alloc.c: Items of type 'qd_message_t' remain allocated at shutdown: 5 
> (SUPPRESSED)
> 34: alloc.c: Items of type 'qd_message_content_t' remain allocated at 
> shutdown: 3 (SUPPRESSED)
> 34: alloc.c: Items of type 'qdr_delivery_t' remain allocated at shutdown: 5 
> (SUPPRESSED)
> 34: alloc.c: Items of type 'qd_link_ref_t' remain allocated at shutdown: 4 
> (SUPPRESSED)
> 34: 
> 34: 
> 34: 
> 34: ==
> 34: FAIL: test_10a_propagated_disposition_data 
> (system_tests_two_routers.TwoRouterTest)
> 34: --
> 34: Traceback (most recent call last):
> 34:   File 
> "/home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/tests/system_tests_two_routers.py",
>  line 211, in test_10a_propagated_disposition_data
> 34: test.run()
> 34:   File 
> "/home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/tests/system_tests_two_routers.py",
>  line 1640, in run
> 34: Container(self).run()
> 34:   File 
> "/opt/hostedtoolcache/Python/3.7.10/x64/lib/python3.7/site-packages/proton/_reactor.py",
>  line 182, in run
> 34: while self.process():
> 34:   File 
> "/opt/hostedtoolcache/Python/3.7.10/x64/lib/python3.7/site-packages/proton/_reactor.py",
>  line 240, in process
> 34: event.dispatch(handler)
> 34:   File 
> "/opt/hostedtoolcache/Python/3.7.10/x64/lib/python3.7/site-packages/proton/_events.py",
>  line 165, in dispatch
> 34: self.dispatch(h, type)
> 34:   File 
> "/opt/hostedtoolcache/Python/3.7.10/x64/lib/python3.7/site-packages/proton/_events.py",
>  line 165, in dispatch
> 34: self.dispatch(h, type)
> 34:   File 
> "/opt/hostedtoolcache/Python/3.7.10/x64/lib/python3.7/site-packages/proton/_events.py",
>  line 162, in dispatch
> 34: _dispatch(handler, type.method, self)
> 34:   File 
> "/opt/hostedtoolcache/Python/3.7.10/x64/lib/python3.7/site-packages/proton/_events.py",
>  line 123, in _dispatch
> 34: m(*args)
> 34:   File 
> "/opt/hostedtoolcache/Python/3.7.10/x64/lib/python3.7/site-packages/proton/_handlers.py",
>  line 71, in on_delivery
> 34: self.on_released(event)
> 34:   File 
> "/opt/hostedtoolcache/Python/3.7.10/x64/lib/python3.7/sit

[jira] [Updated] (DISPATCH-2026) [tcp] Add a test to delete tcpConnector and tcpListener via management

2021-04-01 Thread Ken Giusti (Jira)


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

Ken Giusti updated DISPATCH-2026:
-
Fix Version/s: 1.16.0

> [tcp] Add a test to delete tcpConnector and tcpListener via management
> --
>
> Key: DISPATCH-2026
> URL: https://issues.apache.org/jira/browse/DISPATCH-2026
> Project: Qpid Dispatch
>  Issue Type: Test
>  Components: Tests
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.16.0
>
>
> Add a tcp adaptor system test to add and delete a tcpListener and tcpConnector



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Assigned] (DISPATCH-2028) Edge router system test is failing on RHEL8

2021-04-01 Thread Ken Giusti (Jira)


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

Ken Giusti reassigned DISPATCH-2028:


Assignee: Ganesh Murthy

> Edge router system test is failing on RHEL8
> ---
>
> Key: DISPATCH-2028
> URL: https://issues.apache.org/jira/browse/DISPATCH-2028
> Project: Qpid Dispatch
>  Issue Type: Test
>Reporter: Fernando Giorgetti
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.16.0
>
> Attachments: system_tests_edge_router.rhel8.log
>
>
> Two edge router system tests are failing on RHEL8:
> test_61_anon_sender_multicast_mobile_address_edge_to_interior
> test_66_anon_sender_drop_rx_client_multicast_large_message
>  
> Output for this particular ST is attached.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (DISPATCH-2028) Edge router system test is failing on RHEL8

2021-04-01 Thread Ken Giusti (Jira)


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

Ken Giusti updated DISPATCH-2028:
-
Fix Version/s: 1.16.0

> Edge router system test is failing on RHEL8
> ---
>
> Key: DISPATCH-2028
> URL: https://issues.apache.org/jira/browse/DISPATCH-2028
> Project: Qpid Dispatch
>  Issue Type: Test
>Reporter: Fernando Giorgetti
>Priority: Major
> Fix For: 1.16.0
>
> Attachments: system_tests_edge_router.rhel8.log
>
>
> Two edge router system tests are failing on RHEL8:
> test_61_anon_sender_multicast_mobile_address_edge_to_interior
> test_66_anon_sender_drop_rx_client_multicast_large_message
>  
> Output for this particular ST is attached.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Commented] (PROTON-2351) [c] Proactor: MacOSX/FreeBSD libuv proactor unit test fails with libuv 1.41

2021-04-01 Thread Robbie Gemmell (Jira)


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

Robbie Gemmell commented on PROTON-2351:


Note that I have updated Travis to allow the OSX builds not to fail the overall 
job, so that new/unexpected Linux build failures can still be seen and arent 
masked. The GitHub Actions MacOS build will still fail those jobs overall.

Changes to this JIRA should revert the above commit.

> [c] Proactor: MacOSX/FreeBSD libuv proactor unit test fails with libuv 1.41
> ---
>
> Key: PROTON-2351
> URL: https://issues.apache.org/jira/browse/PROTON-2351
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: Andrew Stitcher
>Priority: Major
>  Labels: freebsd, mac-os-x
>
> Simplest reproducer:
> {code:java}
> $ PN_LOG=debug gdb --args ./c/tests/c-proactor-test proactor_connect
> (gdb) r
> Starting program: /usr/home/andrew/qpid-proton/bld/c/tests/c-proactor-test 
> proactor_connect
> [0x8003a00e0]:EVENT:DEBUG:[0x800d6d000]:(PN_LISTENER_OPEN)
> [0x800da51d0]:EVENT:DEBUG:(PN_CONNECTION_INIT, pn_connection<0x800d81290>)
> [0x800da51d0]:EVENT:DEBUG:(PN_CONNECTION_LOCAL_OPEN, 
> pn_connection<0x800d81290>)
> [0x800da51d0]:EVENT:DEBUG:(PN_CONNECTION_BOUND, pn_connection<0x800d81290>)
> [0x8003a00e0]:EVENT:DEBUG:[0x800d6d000]:(PN_LISTENER_ACCEPT)
> [0x800da5390]:EVENT:DEBUG:(PN_CONNECTION_INIT, pn_connection<0x800d813d0>)
> [0x800da5390]:EVENT:DEBUG:(PN_CONNECTION_BOUND, pn_connection<0x800d813d0>)
> [0x800da51d0]:EVENT:DEBUG:(PN_TRANSPORT_TAIL_CLOSED, 
> pn_transport<0x800da51d0>)
> [0x800da51d0]:EVENT:DEBUG:(PN_TRANSPORT_ERROR, pn_transport<0x800da51d0>)
> ~~~
> c-proactor-test is a Catch v1.12.2 host application.
> Run with -? for options
> ---
> proactor_connect
> ---
> /home/andrew/qpid-proton/src/c/tests/proactor_test.cpp:138
> ...
> /home/andrew/qpid-proton/src/c/tests/proactor_test.cpp:145: FAILED:
>   CHECKED_IF( (PN_TRANSPORT_CLOSED) == (p).run(PN_TRANSPORT_CLOSED) )
> with expansion:
>   PN_TRANSPORT_CLOSED == PN_TRANSPORT_ERROR
> /home/andrew/qpid-proton/src/c/tests/proactor_test.cpp:145: FAILED:
> explicitly with message:
>   pn_condition{"proton:io", "connection already in progress - read :55624"}
> ===
> test cases: 1 | 1 failed
> assertions: 3 | 1 passed | 2 failed
> [Inferior 1 (process 50316) exited with code 02]
> {code}
> This test passes fine with libuv 1.40. At this point it is unclear whether it 
> is a bug with libuv or with Proton.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Commented] (PROTON-2351) [c] Proactor: MacOSX/FreeBSD libuv proactor unit test fails with libuv 1.41

2021-04-01 Thread ASF subversion and git services (Jira)


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

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

Commit cbdb8d531ade5b4bb9d037d3383ac0ddd81613aa in qpid-proton's branch 
refs/heads/main from Robbie Gemmell
[ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=cbdb8d5 ]

PROTON-2351: allow Travis based OSX runs not to fail the overall job for now, 
to help avoid masking issues on other OS runs. GHA MacOS builds will still fail.


> [c] Proactor: MacOSX/FreeBSD libuv proactor unit test fails with libuv 1.41
> ---
>
> Key: PROTON-2351
> URL: https://issues.apache.org/jira/browse/PROTON-2351
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: Andrew Stitcher
>Priority: Major
>  Labels: freebsd, mac-os-x
>
> Simplest reproducer:
> {code:java}
> $ PN_LOG=debug gdb --args ./c/tests/c-proactor-test proactor_connect
> (gdb) r
> Starting program: /usr/home/andrew/qpid-proton/bld/c/tests/c-proactor-test 
> proactor_connect
> [0x8003a00e0]:EVENT:DEBUG:[0x800d6d000]:(PN_LISTENER_OPEN)
> [0x800da51d0]:EVENT:DEBUG:(PN_CONNECTION_INIT, pn_connection<0x800d81290>)
> [0x800da51d0]:EVENT:DEBUG:(PN_CONNECTION_LOCAL_OPEN, 
> pn_connection<0x800d81290>)
> [0x800da51d0]:EVENT:DEBUG:(PN_CONNECTION_BOUND, pn_connection<0x800d81290>)
> [0x8003a00e0]:EVENT:DEBUG:[0x800d6d000]:(PN_LISTENER_ACCEPT)
> [0x800da5390]:EVENT:DEBUG:(PN_CONNECTION_INIT, pn_connection<0x800d813d0>)
> [0x800da5390]:EVENT:DEBUG:(PN_CONNECTION_BOUND, pn_connection<0x800d813d0>)
> [0x800da51d0]:EVENT:DEBUG:(PN_TRANSPORT_TAIL_CLOSED, 
> pn_transport<0x800da51d0>)
> [0x800da51d0]:EVENT:DEBUG:(PN_TRANSPORT_ERROR, pn_transport<0x800da51d0>)
> ~~~
> c-proactor-test is a Catch v1.12.2 host application.
> Run with -? for options
> ---
> proactor_connect
> ---
> /home/andrew/qpid-proton/src/c/tests/proactor_test.cpp:138
> ...
> /home/andrew/qpid-proton/src/c/tests/proactor_test.cpp:145: FAILED:
>   CHECKED_IF( (PN_TRANSPORT_CLOSED) == (p).run(PN_TRANSPORT_CLOSED) )
> with expansion:
>   PN_TRANSPORT_CLOSED == PN_TRANSPORT_ERROR
> /home/andrew/qpid-proton/src/c/tests/proactor_test.cpp:145: FAILED:
> explicitly with message:
>   pn_condition{"proton:io", "connection already in progress - read :55624"}
> ===
> test cases: 1 | 1 failed
> assertions: 3 | 1 passed | 2 failed
> [Inferior 1 (process 50316) exited with code 02]
> {code}
> This test passes fine with libuv 1.40. At this point it is unclear whether it 
> is a bug with libuv or with Proton.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (PROTON-2364) [cpp] Improve test coverage in decoder.cpp

2021-04-01 Thread Justin Ross (Jira)


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

Justin Ross updated PROTON-2364:

Description: 
*Assignee: Shivani Singh*

Decoder.cpp currently has 74% line coverage after running the tests.  Increase 
the coverage to 100% or as close as is practical.  To do this, add or modify 
tests in codec_test.cpp.

To set up coverage builds:
 # Install lcov, the code coverage tool
 # Configure the build for coverage analysis: cmake -DCMAKE_BUILD_TYPE=Coverage 
[...]
 # Build the code: make build
 # Run the tests: make test
 # Generate coverage results: make coverage
 # View the results at /coverage_results

  was:
*Assignee: Kajal Sah*

Message.cpp currently has 84% line coverage after running the tests.  Increase 
the coverage to 100% or as close as is practical.  To do this, add or modify 
tests in message_test.cpp.

To set up coverage builds:
 # Install lcov, the code coverage tool
 # Configure the build for coverage analysis: cmake -DCMAKE_BUILD_TYPE=Coverage 
[...]
 # Build the code: make build
 # Run the tests: make test
 # Generate coverage results: make coverage
 # View the results at /coverage_results


> [cpp] Improve test coverage in decoder.cpp
> --
>
> Key: PROTON-2364
> URL: https://issues.apache.org/jira/browse/PROTON-2364
> Project: Qpid Proton
>  Issue Type: Test
>  Components: cpp-binding
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Major
>  Labels: starter
>
> *Assignee: Shivani Singh*
> Decoder.cpp currently has 74% line coverage after running the tests.  
> Increase the coverage to 100% or as close as is practical.  To do this, add 
> or modify tests in codec_test.cpp.
> To set up coverage builds:
>  # Install lcov, the code coverage tool
>  # Configure the build for coverage analysis: cmake 
> -DCMAKE_BUILD_TYPE=Coverage [...]
>  # Build the code: make build
>  # Run the tests: make test
>  # Generate coverage results: make coverage
>  # View the results at /coverage_results



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Created] (PROTON-2364) [cpp] Improve test coverage in decoder.cpp

2021-04-01 Thread Justin Ross (Jira)
Justin Ross created PROTON-2364:
---

 Summary: [cpp] Improve test coverage in decoder.cpp
 Key: PROTON-2364
 URL: https://issues.apache.org/jira/browse/PROTON-2364
 Project: Qpid Proton
  Issue Type: Test
  Components: cpp-binding
Reporter: Justin Ross
Assignee: Justin Ross


*Assignee: Kajal Sah*

Message.cpp currently has 84% line coverage after running the tests.  Increase 
the coverage to 100% or as close as is practical.  To do this, add or modify 
tests in message_test.cpp.

To set up coverage builds:
 # Install lcov, the code coverage tool
 # Configure the build for coverage analysis: cmake -DCMAKE_BUILD_TYPE=Coverage 
[...]
 # Build the code: make build
 # Run the tests: make test
 # Generate coverage results: make coverage
 # View the results at /coverage_results



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Comment Edited] (PROTON-2362) c-threaderciser timed out on 32-core machine.

2021-04-01 Thread michael goulish (Jira)


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

michael goulish edited comment on PROTON-2362 at 4/1/21, 4:49 PM:
--

OK, here's the whole list.

64 threads, 30 seconds per run, 50 runs for each feature.

 

With all actions enabled crash 10
{{ {{-no-close-connect    crash 12

{{-no-listen           }}{{crash 0 hang 2}}
{{ {color:#de350b}{{-no-close-listen NO PROBLEMS}}{color}}}
{{ {color:#de350b}{{-no-connect  NO PROBLEMS}}{color}}}
{{ {{-no-close-connect    crash 10 hang 2
{{ {{-no-wake crash 11
{{ {{-no-timeout  crash 11
 {{no-cancel-timeout    crash 12}}

 

 


was (Author: michaelgoulish):
OK, here's the whole list.

64 threads, 30 seconds per run, 50 runs for each feature.

 

{{With all actions enabled crash 10}}
 {{-no-close-connect    crash 12}}

-no-listen                        crash 0 hang 2
 {color:#de350b}{{-no-close-listen NO PROBLEMS}}{color}
 {color:#de350b}{{-no-connect  NO PROBLEMS}}{color}
 {{-no-close-connect    crash 10 hang 2}}
 {{-no-wake crash 11}}
 {{-no-timeout  crash 11}}
 {{no-cancel-timeout    crash 12}}

 

 

> c-threaderciser timed out on 32-core machine.
> -
>
> Key: PROTON-2362
> URL: https://issues.apache.org/jira/browse/PROTON-2362
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: michael goulish
>Priority: Major
>
> Using recent master – maybe 3 days old or so – I just ran Proton's ctest, 
> after turning on THREADERCISER.  I ran it on a box with 32 physical cores, 64 
> threads.
>  
> Test number 6 – c-threaderciser – failed with timeout after 1500 seconds.
> ( 1.5e18 femtoseconds. )
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Comment Edited] (PROTON-2362) c-threaderciser timed out on 32-core machine.

2021-04-01 Thread michael goulish (Jira)


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

michael goulish edited comment on PROTON-2362 at 4/1/21, 4:48 PM:
--

OK, here's the whole list.

64 threads, 30 seconds per run, 50 runs for each feature.

 

{{With all actions enabled crash 10}}
 {{-no-close-connect    crash 12}}

-no-listen                        crash 0 hang 2
 {color:#de350b}{{-no-close-listen NO PROBLEMS}}{color}
 {color:#de350b}{{-no-connect  NO PROBLEMS}}{color}
 {{-no-close-connect    crash 10 hang 2}}
 {{-no-wake crash 11}}
 {{-no-timeout  crash 11}}
 {{no-cancel-timeout    crash 12}}

 

 


was (Author: michaelgoulish):
OK, here's the whole list.

64 threads, 30 seconds per run, 50 runs for each feature.

 

{{With all actions enabled crash 10}}
{{-no-close-connect    crash 12}}

{{ -no-listen   crash 0 hang 2}}
{color:#de350b}{{-no-close-listen NO PROBLEMS}}{color}
{color:#de350b}{{-no-connect  NO PROBLEMS}}{color}
{{-no-close-connect    crash 10 hang 2}}
{{-no-wake crash 11}}
{{-no-timeout  crash 11}}
{{no-cancel-timeout    crash 12}}

 

 

> c-threaderciser timed out on 32-core machine.
> -
>
> Key: PROTON-2362
> URL: https://issues.apache.org/jira/browse/PROTON-2362
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: michael goulish
>Priority: Major
>
> Using recent master – maybe 3 days old or so – I just ran Proton's ctest, 
> after turning on THREADERCISER.  I ran it on a box with 32 physical cores, 64 
> threads.
>  
> Test number 6 – c-threaderciser – failed with timeout after 1500 seconds.
> ( 1.5e18 femtoseconds. )
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Commented] (PROTON-2362) c-threaderciser timed out on 32-core machine.

2021-04-01 Thread michael goulish (Jira)


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

michael goulish commented on PROTON-2362:
-

OK, here's the whole list.

64 threads, 30 seconds per run, 50 runs for each feature.

 

{{With all actions enabled crash 10}}
{{-no-close-connect    crash 12}}

{{ -no-listen   crash 0 hang 2}}
{color:#de350b}{{-no-close-listen NO PROBLEMS}}{color}
{color:#de350b}{{-no-connect  NO PROBLEMS}}{color}
{{-no-close-connect    crash 10 hang 2}}
{{-no-wake crash 11}}
{{-no-timeout  crash 11}}
{{no-cancel-timeout    crash 12}}

 

 

> c-threaderciser timed out on 32-core machine.
> -
>
> Key: PROTON-2362
> URL: https://issues.apache.org/jira/browse/PROTON-2362
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: michael goulish
>Priority: Major
>
> Using recent master – maybe 3 days old or so – I just ran Proton's ctest, 
> after turning on THREADERCISER.  I ran it on a box with 32 physical cores, 64 
> threads.
>  
> Test number 6 – c-threaderciser – failed with timeout after 1500 seconds.
> ( 1.5e18 femtoseconds. )
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Commented] (PROTON-2357) [cpp] Improve test coverage in url.cpp

2021-04-01 Thread ASF GitHub Bot (Jira)


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

ASF GitHub Bot commented on PROTON-2357:


DreamPearl opened a new pull request #303:
URL: https://github.com/apache/qpid-proton/pull/303


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> [cpp] Improve test coverage in url.cpp
> --
>
> Key: PROTON-2357
> URL: https://issues.apache.org/jira/browse/PROTON-2357
> Project: Qpid Proton
>  Issue Type: Test
>  Components: cpp-binding
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Major
>  Labels: starter
>
> *Assignee: Rakhi Kumari*
> Url.cpp currently has 76% line coverage after running the tests.  Increase 
> the coverage to 100% or as close as is practical.  To do this, add or modify 
> tests in url_test.cpp.
> To set up coverage builds:
>  # Install lcov, the code coverage tool
>  # Configure the build for coverage analysis: cmake 
> -DCMAKE_BUILD_TYPE=Coverage [...]
>  # Build the code: make build
>  # Run the tests: make test
>  # Generate coverage results: make coverage
>  # View the results at /coverage_results



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[GitHub] [qpid-proton] DreamPearl opened a new pull request #303: [WIP] PROTON-2357: Improve test coverage in url.cpp

2021-04-01 Thread GitBox


DreamPearl opened a new pull request #303:
URL: https://github.com/apache/qpid-proton/pull/303


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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



[jira] [Updated] (PROTON-2363) [cpp] Improve test coverage in map.cpp

2021-04-01 Thread Justin Ross (Jira)


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

Justin Ross updated PROTON-2363:

Description: 
*Assignee: Sushma Unnibhavi*

Map.cpp currently has 57% line coverage after running the tests (for my local 
config).  Increase the coverage to 100% or as close as is practical.  To do 
this, add or modify tests in map_test.cpp.

To set up coverage builds:
 # Install lcov, the code coverage tool
 # Configure the build for coverage analysis: cmake -DCMAKE_BUILD_TYPE=Coverage 
[...]
 # Build the code: make build
 # Run the tests: make test
 # Generate coverage results: make coverage
 # View the results at /coverage_results

  was:
*Assignee: Kajal Sah*

Message.cpp currently has 84% line coverage after running the tests.  Increase 
the coverage to 100% or as close as is practical.  To do this, add or modify 
tests in message_test.cpp.

To set up coverage builds:
 # Install lcov, the code coverage tool
 # Configure the build for coverage analysis: cmake -DCMAKE_BUILD_TYPE=Coverage 
[...]
 # Build the code: make build
 # Run the tests: make test
 # Generate coverage results: make coverage
 # View the results at /coverage_results


> [cpp] Improve test coverage in map.cpp
> --
>
> Key: PROTON-2363
> URL: https://issues.apache.org/jira/browse/PROTON-2363
> Project: Qpid Proton
>  Issue Type: Test
>  Components: cpp-binding
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Major
>  Labels: starter
>
> *Assignee: Sushma Unnibhavi*
> Map.cpp currently has 57% line coverage after running the tests (for my local 
> config).  Increase the coverage to 100% or as close as is practical.  To do 
> this, add or modify tests in map_test.cpp.
> To set up coverage builds:
>  # Install lcov, the code coverage tool
>  # Configure the build for coverage analysis: cmake 
> -DCMAKE_BUILD_TYPE=Coverage [...]
>  # Build the code: make build
>  # Run the tests: make test
>  # Generate coverage results: make coverage
>  # View the results at /coverage_results



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (DISPATCH-1671) An unused import?

2021-04-01 Thread Jira


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

Jiri Daněk updated DISPATCH-1671:
-
Affects Version/s: 1.15.0

> An unused import?
> -
>
> Key: DISPATCH-1671
> URL: https://issues.apache.org/jira/browse/DISPATCH-1671
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 1.15.0
>Reporter: Justin Ross
>Priority: Minor
>
> https://github.com/apache/qpid-dispatch/blob/f62c85f40bbd6d0bddea66938fe9319deaa5/tests/system_test.py#L83
> The system test code tries to import python qpid_messaging.  I don't think it 
> uses it.  But the presence of the import triggers a failure on Fedora 31 for 
> me, because if qpid_messaging is present, it attempts to use a swig API that 
> has gone away in swig 4.0.
> I think the right thing is to remove the qpid_messaging import.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Resolved] (DISPATCH-1714) [aarch64] runtime error: store to misaligned address

2021-04-01 Thread Jira


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

Jiri Daněk resolved DISPATCH-1714.
--
Resolution: Duplicate

> [aarch64] runtime error: store to misaligned address
> 
>
> Key: DISPATCH-1714
> URL: https://issues.apache.org/jira/browse/DISPATCH-1714
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 1.12.0
> Environment: Ubuntu Xenial on Travis
> arm64
>Reporter: Jiri Daněk
>Priority: Major
>  Labels: ubsan
>
> https://travis-ci.com/github/jiridanek/qpid-dispatch/jobs/362413522
> {noformat}
> 3: /home/travis/build/jiridanek/qpid-dispatch/src/alloc_pool.c:418:61: 
> runtime error: store to misaligned address 0x9ac06b32 for type 
> 'uint32_t', which requires 4 byte alignment
> 3: 0x9ac06b32: note: pointer points here
> 3:  be be  be be be be be be be be  be be be be be be be be  00 00 00 00 00 
> 00 00 00  00 00 00 00 00 00
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (DISPATCH-1923) Remove support for Python 3.5

2021-04-01 Thread Jira


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

Jiri Daněk updated DISPATCH-1923:
-
Status: Reviewable  (was: In Progress)

> Remove support for Python 3.5
> -
>
> Key: DISPATCH-1923
> URL: https://issues.apache.org/jira/browse/DISPATCH-1923
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Documentation, Tools
>Affects Versions: 1.15.0
>Reporter: Jiri Daněk
>Assignee: Jiri Daněk
>Priority: Major
> Fix For: 1.16.0
>
>
>  Python 3.5 reached the end of its life on September 13th, 2020. The default 
> Python3 on RHEL 7 and 8 is version 3.6. There is no point in supporting 3.5 
> any more.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Resolved] (DISPATCH-1713) [aarch64] runtime error: left shift of 128 by 24 places cannot be represented in type 'int'

2021-04-01 Thread Jira


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

Jiri Daněk resolved DISPATCH-1713.
--
Resolution: Duplicate

> [aarch64] runtime error: left shift of 128 by 24 places cannot be represented 
> in type 'int'
> ---
>
> Key: DISPATCH-1713
> URL: https://issues.apache.org/jira/browse/DISPATCH-1713
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 1.12.0
> Environment: Ubuntu Xenial on Travis
> arm64
>Reporter: Jiri Daněk
>Priority: Major
>  Labels: ubsan
>
> https://travis-ci.com/github/jiridanek/qpid-dispatch/jobs/362413522
> {noformat}
> 1: /home/travis/build/jiridanek/qpid-dispatch/src/parse.c:509:74: runtime 
> error: left shift of 128 by 24 places cannot be represented in type 'int'
> 1: /home/travis/build/jiridanek/qpid-dispatch/src/parse.c:497:66: runtime 
> error: left shift of 128 by 56 places cannot be represented in type 'long int'
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Resolved] (DISPATCH-1923) Remove support for Python 3.5

2021-04-01 Thread Jira


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

Jiri Daněk resolved DISPATCH-1923.
--
Resolution: Fixed

> Remove support for Python 3.5
> -
>
> Key: DISPATCH-1923
> URL: https://issues.apache.org/jira/browse/DISPATCH-1923
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Documentation, Tools
>Affects Versions: 1.15.0
>Reporter: Jiri Daněk
>Assignee: Jiri Daněk
>Priority: Major
> Fix For: 1.16.0
>
>
>  Python 3.5 reached the end of its life on September 13th, 2020. The default 
> Python3 on RHEL 7 and 8 is version 3.6. There is no point in supporting 3.5 
> any more.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (DISPATCH-1754) [macOS] system_tests_policy_oversize_compound sometimes fails with error: exit code -11, expected -1

2021-04-01 Thread Jira


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

Jiri Daněk updated DISPATCH-1754:
-
Fix Version/s: 1.16.0

> [macOS] system_tests_policy_oversize_compound sometimes fails with error: 
> exit code -11, expected -1
> 
>
> Key: DISPATCH-1754
> URL: https://issues.apache.org/jira/browse/DISPATCH-1754
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 1.13.0
>Reporter: Jiri Daněk
>Priority: Major
>  Labels: macOS
> Fix For: 1.16.0
>
>
> https://travis-ci.com/github/jiridanek/qpid-dispatch/jobs/373237713#L3328
> From time to time, {{Process 20891 error: exit code -11, expected -1}} error 
> appears in the test.
> {noformat}
> 26: ==
> 26: ERROR: tearDownClass 
> (system_tests_policy_oversize_compound.MaxMessageSizeLinkRouteOversize)
> 26: --
> 26: Traceback (most recent call last):
> 26:   File 
> "/Users/travis/build/jiridanek/qpid-dispatch/tests/system_tests_policy_oversize_compound.py",
>  line 1202, in tearDownClass
> 26: super(MaxMessageSizeLinkRouteOversize, cls).tearDownClass()
> 26:   File 
> "/Users/travis/build/jiridanek/qpid-dispatch/tests/system_test.py", line 773, 
> in tearDownClass
> 26: cls.tester.teardown()
> 26:   File 
> "/Users/travis/build/jiridanek/qpid-dispatch/tests/system_test.py", line 719, 
> in teardown
> 26: raise RuntimeError("Errors during teardown: \n\n%s" % 
> "\n\n".join([str(e) for e in errors]))
> 26: RuntimeError: Errors during teardown: 
> 26: 
> 26: Process 20891 error: exit code -11, expected -1
> 26: qdrouterd -c INT.B.conf -I 
> /Users/travis/build/jiridanek/qpid-dispatch/python
> 26: 
> /Users/travis/build/jiridanek/qpid-dispatch/build/tests/system_test.dir/system_tests_policy_oversize_compound/MaxMessageSizeLinkRouteOversize/setUpClass/INT.B-6.cmd
> 26: 
> 26: 
> 26: 
> 26: --
> 26: Ran 7 tests in 29.007s
> 26: 
> 26: FAILED (errors=1)
> 26/69 Test #26: system_tests_policy_oversize_compound .***Failed  
>  29.19 sec
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Created] (PROTON-2363) [cpp] Improve test coverage in map.cpp

2021-04-01 Thread Justin Ross (Jira)
Justin Ross created PROTON-2363:
---

 Summary: [cpp] Improve test coverage in map.cpp
 Key: PROTON-2363
 URL: https://issues.apache.org/jira/browse/PROTON-2363
 Project: Qpid Proton
  Issue Type: Test
  Components: cpp-binding
Reporter: Justin Ross
Assignee: Justin Ross


*Assignee: Kajal Sah*

Message.cpp currently has 84% line coverage after running the tests.  Increase 
the coverage to 100% or as close as is practical.  To do this, add or modify 
tests in message_test.cpp.

To set up coverage builds:
 # Install lcov, the code coverage tool
 # Configure the build for coverage analysis: cmake -DCMAKE_BUILD_TYPE=Coverage 
[...]
 # Build the code: make build
 # Run the tests: make test
 # Generate coverage results: make coverage
 # View the results at /coverage_results



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Resolved] (DISPATCH-1754) [macOS] system_tests_policy_oversize_compound sometimes fails with error: exit code -11, expected -1

2021-04-01 Thread Jira


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

Jiri Daněk resolved DISPATCH-1754.
--
Resolution: Cannot Reproduce

> [macOS] system_tests_policy_oversize_compound sometimes fails with error: 
> exit code -11, expected -1
> 
>
> Key: DISPATCH-1754
> URL: https://issues.apache.org/jira/browse/DISPATCH-1754
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 1.13.0
>Reporter: Jiri Daněk
>Priority: Major
>  Labels: macOS
>
> https://travis-ci.com/github/jiridanek/qpid-dispatch/jobs/373237713#L3328
> From time to time, {{Process 20891 error: exit code -11, expected -1}} error 
> appears in the test.
> {noformat}
> 26: ==
> 26: ERROR: tearDownClass 
> (system_tests_policy_oversize_compound.MaxMessageSizeLinkRouteOversize)
> 26: --
> 26: Traceback (most recent call last):
> 26:   File 
> "/Users/travis/build/jiridanek/qpid-dispatch/tests/system_tests_policy_oversize_compound.py",
>  line 1202, in tearDownClass
> 26: super(MaxMessageSizeLinkRouteOversize, cls).tearDownClass()
> 26:   File 
> "/Users/travis/build/jiridanek/qpid-dispatch/tests/system_test.py", line 773, 
> in tearDownClass
> 26: cls.tester.teardown()
> 26:   File 
> "/Users/travis/build/jiridanek/qpid-dispatch/tests/system_test.py", line 719, 
> in teardown
> 26: raise RuntimeError("Errors during teardown: \n\n%s" % 
> "\n\n".join([str(e) for e in errors]))
> 26: RuntimeError: Errors during teardown: 
> 26: 
> 26: Process 20891 error: exit code -11, expected -1
> 26: qdrouterd -c INT.B.conf -I 
> /Users/travis/build/jiridanek/qpid-dispatch/python
> 26: 
> /Users/travis/build/jiridanek/qpid-dispatch/build/tests/system_test.dir/system_tests_policy_oversize_compound/MaxMessageSizeLinkRouteOversize/setUpClass/INT.B-6.cmd
> 26: 
> 26: 
> 26: 
> 26: --
> 26: Ran 7 tests in 29.007s
> 26: 
> 26: FAILED (errors=1)
> 26/69 Test #26: system_tests_policy_oversize_compound .***Failed  
>  29.19 sec
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Commented] (DISPATCH-1934) Dispatch should not ignore all Proton memory leak reports wholesale

2021-04-01 Thread Jira


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

Jiri Daněk commented on DISPATCH-1934:
--

Individual proton suppressions were added, together with a comment saying that 
they have to yet be triaged.

> Dispatch should not ignore all Proton memory leak reports wholesale
> ---
>
> Key: DISPATCH-1934
> URL: https://issues.apache.org/jira/browse/DISPATCH-1934
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Affects Versions: 1.14.0
>Reporter: Jiri Daněk
>Assignee: Jiri Daněk
>Priority: Major
> Fix For: 1.16.0
>
>
> Currently, leak suppressions include {{\*libqpid-proton\*}}. Such leaks can 
> be caused by
> # harmless things in proton
> # bug in proton
> # bug in usage of proton by dispatch
> Case 1 should be suppressed using targeted suppression. Cases 2 and 3 would 
> still manifest as dispatch bugs to a customer, therefore should not be 
> suppressed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (PROTON-2357) [cpp] Improve test coverage in url.cpp

2021-04-01 Thread Justin Ross (Jira)


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

Justin Ross updated PROTON-2357:

Labels: starter  (was: )

> [cpp] Improve test coverage in url.cpp
> --
>
> Key: PROTON-2357
> URL: https://issues.apache.org/jira/browse/PROTON-2357
> Project: Qpid Proton
>  Issue Type: Test
>  Components: cpp-binding
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Major
>  Labels: starter
>
> *Assignee: Rakhi Kumari*
> Url.cpp currently has 76% line coverage after running the tests.  Increase 
> the coverage to 100% or as close as is practical.  To do this, add or modify 
> tests in url_test.cpp.
> To set up coverage builds:
>  # Install lcov, the code coverage tool
>  # Configure the build for coverage analysis: cmake 
> -DCMAKE_BUILD_TYPE=Coverage [...]
>  # Build the code: make build
>  # Run the tests: make test
>  # Generate coverage results: make coverage
>  # View the results at /coverage_results



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Closed] (DISPATCH-1934) Dispatch should not ignore all Proton memory leak reports wholesale

2021-04-01 Thread Jira


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

Jiri Daněk closed DISPATCH-1934.

Resolution: Implemented

> Dispatch should not ignore all Proton memory leak reports wholesale
> ---
>
> Key: DISPATCH-1934
> URL: https://issues.apache.org/jira/browse/DISPATCH-1934
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Affects Versions: 1.14.0
>Reporter: Jiri Daněk
>Priority: Major
>
> Currently, leak suppressions include {{\*libqpid-proton\*}}. Such leaks can 
> be caused by
> # harmless things in proton
> # bug in proton
> # bug in usage of proton by dispatch
> Case 1 should be suppressed using targeted suppression. Cases 2 and 3 would 
> still manifest as dispatch bugs to a customer, therefore should not be 
> suppressed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (DISPATCH-1934) Dispatch should not ignore all Proton memory leak reports wholesale

2021-04-01 Thread Jira


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

Jiri Daněk updated DISPATCH-1934:
-
Fix Version/s: 1.16.0

> Dispatch should not ignore all Proton memory leak reports wholesale
> ---
>
> Key: DISPATCH-1934
> URL: https://issues.apache.org/jira/browse/DISPATCH-1934
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Affects Versions: 1.14.0
>Reporter: Jiri Daněk
>Priority: Major
> Fix For: 1.16.0
>
>
> Currently, leak suppressions include {{\*libqpid-proton\*}}. Such leaks can 
> be caused by
> # harmless things in proton
> # bug in proton
> # bug in usage of proton by dispatch
> Case 1 should be suppressed using targeted suppression. Cases 2 and 3 would 
> still manifest as dispatch bugs to a customer, therefore should not be 
> suppressed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Assigned] (DISPATCH-1934) Dispatch should not ignore all Proton memory leak reports wholesale

2021-04-01 Thread Jira


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

Jiri Daněk reassigned DISPATCH-1934:


Assignee: Jiri Daněk

> Dispatch should not ignore all Proton memory leak reports wholesale
> ---
>
> Key: DISPATCH-1934
> URL: https://issues.apache.org/jira/browse/DISPATCH-1934
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Affects Versions: 1.14.0
>Reporter: Jiri Daněk
>Assignee: Jiri Daněk
>Priority: Major
> Fix For: 1.16.0
>
>
> Currently, leak suppressions include {{\*libqpid-proton\*}}. Such leaks can 
> be caused by
> # harmless things in proton
> # bug in proton
> # bug in usage of proton by dispatch
> Case 1 should be suppressed using targeted suppression. Cases 2 and 3 would 
> still manifest as dispatch bugs to a customer, therefore should not be 
> suppressed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (PROTON-2360) [cpp] Improve test coverage in link.cpp

2021-04-01 Thread Justin Ross (Jira)


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

Justin Ross updated PROTON-2360:

Labels: starter  (was: )

> [cpp] Improve test coverage in link.cpp
> ---
>
> Key: PROTON-2360
> URL: https://issues.apache.org/jira/browse/PROTON-2360
> Project: Qpid Proton
>  Issue Type: Test
>  Components: cpp-binding
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Major
>  Labels: starter
>
> *Assignee: Sunday Mgbogu*
> Link.cpp currently has 82% line coverage after running the tests.  Increase 
> the coverage to 100% or as close as is practical.  To do this, add or modify 
> tests in link_test.cpp.
> To set up coverage builds:
>  # Install lcov, the code coverage tool
>  # Configure the build for coverage analysis: cmake 
> -DCMAKE_BUILD_TYPE=Coverage [...]
>  # Build the code: make build
>  # Run the tests: make test
>  # Generate coverage results: make coverage
>  # View the results at /coverage_results



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (PROTON-2356) [cpp] Improve test coverage in message.cpp

2021-04-01 Thread Justin Ross (Jira)


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

Justin Ross updated PROTON-2356:

Labels: starter  (was: )

> [cpp] Improve test coverage in message.cpp
> --
>
> Key: PROTON-2356
> URL: https://issues.apache.org/jira/browse/PROTON-2356
> Project: Qpid Proton
>  Issue Type: Test
>  Components: cpp-binding
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Major
>  Labels: starter
>
> *Assignee: Kajal Sah*
> Message.cpp currently has 84% line coverage after running the tests.  
> Increase the coverage to 100% or as close as is practical.  To do this, add 
> or modify tests in message_test.cpp.
> To set up coverage builds:
>  # Install lcov, the code coverage tool
>  # Configure the build for coverage analysis: cmake 
> -DCMAKE_BUILD_TYPE=Coverage [...]
>  # Build the code: make build
>  # Run the tests: make test
>  # Generate coverage results: make coverage
>  # View the results at /coverage_results



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (PROTON-2358) [cpp] Improve test coverage in container.cpp

2021-04-01 Thread Justin Ross (Jira)


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

Justin Ross updated PROTON-2358:

Labels: starter  (was: )

> [cpp] Improve test coverage in container.cpp
> 
>
> Key: PROTON-2358
> URL: https://issues.apache.org/jira/browse/PROTON-2358
> Project: Qpid Proton
>  Issue Type: Test
>  Components: cpp-binding
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Major
>  Labels: starter
>
> *Assignee: Mehaboob Shariff*
> Container.cpp currently has 70% line coverage after running the tests.  
> Increase the coverage to 100% or as close as is practical.  To do this, add 
> or modify tests in container_test.cpp.
> To set up coverage builds:
>  # Install lcov, the code coverage tool
>  # Configure the build for coverage analysis: cmake 
> -DCMAKE_BUILD_TYPE=Coverage [...]
>  # Build the code: make build
>  # Run the tests: make test
>  # Generate coverage results: make coverage
>  # View the results at /coverage_results



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Closed] (DISPATCH-2010) system_tests_link_routes fails on Aarch64 unable to load JSON config

2021-04-01 Thread Jira


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

Jiri Daněk closed DISPATCH-2010.

Resolution: Duplicate

> system_tests_link_routes fails on Aarch64 unable to load JSON config
> 
>
> Key: DISPATCH-2010
> URL: https://issues.apache.org/jira/browse/DISPATCH-2010
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 1.16.0
>Reporter: Jiri Daněk
>Priority: Major
>
> https://travis-ci.com/github/apache/qpid-dispatch/jobs/492275900#L3696
> https://github.com/apache/qpid-dispatch/pull/1077
> {noformat}
> test 14
>   Start 14: system_tests_link_routes
> 14: Test command: /usr/bin/python3.8 
> "/home/travis/build/apache/qpid-dispatch/build/tests/run.py" "-m" "unittest" 
> "-v" "system_tests_link_routes"
> 14: Test timeout computed to be: 550
> 14: test_address_propagation 
> (system_tests_link_routes.ConnectionLinkRouteTest) ... ok
> 14: test_config_file_bad (system_tests_link_routes.ConnectionLinkRouteTest) 
> ... ok
> 14: test_mgmt (system_tests_link_routes.ConnectionLinkRouteTest) ... ok
> 14: test_send_receive (system_tests_link_routes.ConnectionLinkRouteTest) ... 
> ok
> 14: 
> 14: Router QDR.X output file:
> 14: 
> 14: 2021-03-19 11:30:18.300349 + AGENT (error) Contents of failed config 
> file
> 14: 2021-03-19 11:30:18.300646 + AGENT (error) Line 1 |[["router", {
> 14: 2021-03-19 11:30:18.300857 + AGENT (error) Line 2 |"mode": "interior",
> 14: 2021-03-19 11:30:18.301075 + AGENT (error) Line 3 |"id": "QDR.X",
> 14: 2021-03-19 11:30:18.301293 + AGENT (error) Line 4 |"debugDumpFile": 
> "/home/travis/build/apache/qpid-dispatch/build/tests/system_test.dir/system_tests_link_routes/ConnectionLinkRouteTest/test_config_file_bad/X-qddebug.txt"}],
> 14: 2021-03-19 11:30:18.301522 + AGENT (error) Line 5 |["listener", {
> 14: 2021-03-19 11:30:18.301723 + AGENT (error) Line 6 |"role": "normal",
> 14: 2021-03-19 11:30:18.301921 + AGENT (error) Line 7 |"host": "0.0.0.0",
> 14: 2021-03-19 11:30:18.302122 + AGENT (error) Line 8 |"port": "22635",
> 14: 2021-03-19 11:30:18.302321 + AGENT (error) Line 9 |"saslMechanisms": 
> "ANONYMOUS",
> 14: 2021-03-19 11:30:18.302524 + AGENT (error) Line 10 
> |"idleTimeoutSeconds": "120",
> 14: 2021-03-19 11:30:18.302727 + AGENT (error) Line 11 
> |"authenticatePeer": "no"}],
> 14: 2021-03-19 11:30:18.302954 + AGENT (error) Line 12 
> |connection.["linkRoute", {
> 14: 2021-03-19 11:30:18.303157 + AGENT (error) Line 13 |"pattern": 
> "i/am/bad",
> 14: 2021-03-19 11:30:18.303357 + AGENT (error) Line 14 |"direction": 
> "out"}],
> 14: 2021-03-19 11:30:18.303556 + AGENT (error) Line 15 |["log", {
> 14: 2021-03-19 11:30:18.303801 + AGENT (error) Line 16 |"module": 
> "DEFAULT",
> 14: 2021-03-19 11:30:18.304004 + AGENT (error) Line 17 |"enable": 
> "trace+",
> 14: 2021-03-19 11:30:18.304207 + AGENT (error) Line 18 |"includeSource": 
> "true",
> 14: 2021-03-19 11:30:18.304435 + AGENT (error) Line 19 |"outputFile": 
> "X.log"}]]
> 14: 2021-03-19 11:30:18.304628 + ERROR (error) Python: Exception: Cannot 
> load configuration file X.conf: Expecting value: line 12 column 1 (char 380)
> 14: 2021-03-19 11:30:18.306867 + ERROR (error) Traceback (most recent 
> call last):
> 14:   File 
> "/home/travis/build/apache/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
>  line 61, in __init__
> 14: self.load(filename, raw_json)
> 14:   File 
> "/home/travis/build/apache/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
>  line 242, in load
> 14: self.load(f, raw_json)
> 14:   File 
> "/home/travis/build/apache/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
>  line 244, in load
> 14: sections = self._parserawjson(source) if raw_json else 
> self._parse(source)
> 14:   File 
> "/home/travis/build/apache/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
>  line 208, in _parse
> 14: sections = json.loads(js_text)
> 14:   File "/usr/lib/python3.8/json/__init__.py", line 357, in loads
> 14: return _default_decoder.decode(s)
> 14:   File "/usr/lib/python3.8/json/decoder.py", line 337, in decode
> 14: obj, end = self.raw_decode(s, idx=_w(s, 0).end())
> 14:   File "/usr/lib/python3.8/json/decoder.py", line 355, in raw_decode
> 14: raise JSONDecodeError("Expecting value", s, err.value) from None
> 14: json.decoder.JSONDecodeError: Expecting value: line 12 column 1 (char 380)
> 14: 
> 14: During handling of the above exception, another exception occurred:
> 14: 
> 14: Traceback (most recent call last):
> 14:   File 
> "/home/travis/build/apache/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
>  line 286, in co

[jira] [Updated] (DISPATCH-2011) Support hwasan variant of address sanitizer on Aarch64 in CMake

2021-04-01 Thread Jira


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

Jiri Daněk updated DISPATCH-2011:
-
Fix Version/s: 1.16.0

> Support hwasan variant of address sanitizer on Aarch64 in CMake
> ---
>
> Key: DISPATCH-2011
> URL: https://issues.apache.org/jira/browse/DISPATCH-2011
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Tests
>Affects Versions: 1.16.0
>Reporter: Jiri Daněk
>Assignee: Jiri Daněk
>Priority: Major
> Fix For: 1.16.0
>
>
> hwasan (hardware-assisted asan) is a complementary tool to the classical asan.
> Both tools can catch an overlapping set of memory issues, but each has 
> strengths and weaknesses. HWASAN uses memory tagging (allocated memory gets 
> randomly assigned a "color tag", when access happens through a pointer of 
> different color, a failure is reported). ASAN uses buffer zones before and 
> after allocated memory and detects invalid accesses into these zones and into 
> recently freed memory.
> HWASAN is designed to have much smaller memory overhead, with the original 
> idea being that it could be turned on by default in production (on mobile 
> Android devices).
> Currently, in LLVM 11, HWASAN does not work to compile Dispatch. It would be 
> nice if Clang 12 did work. Issue needs to be reported.
> https://travis-ci.com/github/apache/qpid-dispatch/jobs/492330729#L1859
> {noformat}
> [ 35%] Building C object 
> src/CMakeFiles/qpid-dispatch.dir/router_core/agent.c.o
> fatal error: error in backend: Unexpected instruction
> PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash 
> backtrace, preprocessed source, and associated run script.
> Stack dump:
> 0.Program arguments: /usr/bin/clang-11 -g -fno-omit-frame-pointer 
> -fsanitize=hwaddress,undefined -std=gnu99 -O2 -g -fPIC -Wall -Wpedantic 
> -Wno-gnu-statement-expression -fcolor-diagnostics -Werror 
> -Dqpid_dispatch_EXPORTS -I/home/travis/build/apache/qpid-dispatch/include 
> -I/home/travis/build/apache/qpid-dispatch/build/include 
> -I/home/travis/build/apache/qpid-dispatch/install/include 
> -I/usr/include/python3.8 -I/home/travis/build/apache/qpid-dispatch/src 
> -I/home/travis/build/apache/qpid-dispatch/src/router_core 
> -I/home/travis/build/apache/qpid-dispatch/build/src -DQD_MEMORY_DEBUG 
> -DNDEBUG -c -o CMakeFiles/qpid-dispatch.dir/router_config.c.o 
> /home/travis/build/apache/qpid-dispatch/src/router_config.c 
> 1. parser at end of file
> 2.Per-module optimization passes
> 3.Running pass 'Function Pass Manager' on module 
> '/home/travis/build/apache/qpid-dispatch/src/router_config.c'.
> 4.Running pass 'HWAddressSanitizer' on function 
> '@qdi_router_configure_body'
>  #0 0x7fa2755b542f llvm::sys::PrintStackTrace(llvm::raw_ostream&) 
> (/lib/x86_64-linux-gnu/libLLVM-11.so.1+0xaa642f)
>  #1 0x7fa2755b3790 llvm::sys::RunSignalHandlers() 
> (/lib/x86_64-linux-gnu/libLLVM-11.so.1+0xaa4790)
>  #2 0x7fa2755b4b7d llvm::sys::CleanupOnSignal(unsigned long) 
> (/lib/x86_64-linux-gnu/libLLVM-11.so.1+0xaa5b7d)
>  #3 0x7fa2754fcb0a (/lib/x86_64-linux-gnu/libLLVM-11.so.1+0x9edb0a)
>  #4 0x7fa2754fcaab (/lib/x86_64-linux-gnu/libLLVM-11.so.1+0x9edaab)
>  #5 0x7fa2755b025e (/lib/x86_64-linux-gnu/libLLVM-11.so.1+0xaa125e)
>  #6 0x00412932 (/usr/bin/clang-11+0x412932)
>  #7 0x7fa275508b6f llvm::report_fatal_error(llvm::Twine const&, bool) 
> (/lib/x86_64-linux-gnu/libLLVM-11.so.1+0x9f9b6f)
>  #8 0x7fa275508a48 (/lib/x86_64-linux-gnu/libLLVM-11.so.1+0x9f9a48)
>  #9 0x7fa275fa050f (/lib/x86_64-linux-gnu/libLLVM-11.so.1+0x149150f)
> #10 0x7fa2756c4579 llvm::FPPassManager::runOnFunction(llvm::Function&) 
> (/lib/x86_64-linux-gnu/libLLVM-11.so.1+0xbb5579)
> #11 0x7fa2756c9b23 llvm::FPPassManager::runOnModule(llvm::Module&) 
> (/lib/x86_64-linux-gnu/libLLVM-11.so.1+0xbbab23)
> #12 0x7fa2756c4b90 llvm::legacy::PassManagerImpl::run(llvm::Module&) 
> (/lib/x86_64-linux-gnu/libLLVM-11.so.1+0xbb5b90)
> #13 0x7fa27b034120 clang::EmitBackendOutput(clang::DiagnosticsEngine&, 
> clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, 
> clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout 
> const&, llvm::Module*, clang::BackendAction, 
> std::unique_ptr std::default_delete >) 
> (/lib/x86_64-linux-gnu/libclang-cpp.so.11+0x1581120)
> #14 0x7fa27b2f2076 (/lib/x86_64-linux-gnu/libclang-cpp.so.11+0x183f076)
> #15 0x7fa27a3bd003 clang::ParseAST(clang::Sema&, bool, bool) 
> (/lib/x86_64-linux-gnu/libclang-cpp.so.11+0x90a003)
> #16 0x7fa27b9875c8 clang::FrontendAction::Execute() 
> (/lib/x86_64-linux-gnu/libclang-cpp.so.11+0x1ed45c8)
> #17 0x7fa27b93d8c1 
> clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) 

[jira] [Resolved] (DISPATCH-2011) Support hwasan variant of address sanitizer on Aarch64 in CMake

2021-04-01 Thread Jira


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

Jiri Daněk resolved DISPATCH-2011.
--
Resolution: Fixed

> Support hwasan variant of address sanitizer on Aarch64 in CMake
> ---
>
> Key: DISPATCH-2011
> URL: https://issues.apache.org/jira/browse/DISPATCH-2011
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Tests
>Affects Versions: 1.16.0
>Reporter: Jiri Daněk
>Assignee: Jiri Daněk
>Priority: Major
> Fix For: 1.16.0
>
>
> hwasan (hardware-assisted asan) is a complementary tool to the classical asan.
> Both tools can catch an overlapping set of memory issues, but each has 
> strengths and weaknesses. HWASAN uses memory tagging (allocated memory gets 
> randomly assigned a "color tag", when access happens through a pointer of 
> different color, a failure is reported). ASAN uses buffer zones before and 
> after allocated memory and detects invalid accesses into these zones and into 
> recently freed memory.
> HWASAN is designed to have much smaller memory overhead, with the original 
> idea being that it could be turned on by default in production (on mobile 
> Android devices).
> Currently, in LLVM 11, HWASAN does not work to compile Dispatch. It would be 
> nice if Clang 12 did work. Issue needs to be reported.
> https://travis-ci.com/github/apache/qpid-dispatch/jobs/492330729#L1859
> {noformat}
> [ 35%] Building C object 
> src/CMakeFiles/qpid-dispatch.dir/router_core/agent.c.o
> fatal error: error in backend: Unexpected instruction
> PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash 
> backtrace, preprocessed source, and associated run script.
> Stack dump:
> 0.Program arguments: /usr/bin/clang-11 -g -fno-omit-frame-pointer 
> -fsanitize=hwaddress,undefined -std=gnu99 -O2 -g -fPIC -Wall -Wpedantic 
> -Wno-gnu-statement-expression -fcolor-diagnostics -Werror 
> -Dqpid_dispatch_EXPORTS -I/home/travis/build/apache/qpid-dispatch/include 
> -I/home/travis/build/apache/qpid-dispatch/build/include 
> -I/home/travis/build/apache/qpid-dispatch/install/include 
> -I/usr/include/python3.8 -I/home/travis/build/apache/qpid-dispatch/src 
> -I/home/travis/build/apache/qpid-dispatch/src/router_core 
> -I/home/travis/build/apache/qpid-dispatch/build/src -DQD_MEMORY_DEBUG 
> -DNDEBUG -c -o CMakeFiles/qpid-dispatch.dir/router_config.c.o 
> /home/travis/build/apache/qpid-dispatch/src/router_config.c 
> 1. parser at end of file
> 2.Per-module optimization passes
> 3.Running pass 'Function Pass Manager' on module 
> '/home/travis/build/apache/qpid-dispatch/src/router_config.c'.
> 4.Running pass 'HWAddressSanitizer' on function 
> '@qdi_router_configure_body'
>  #0 0x7fa2755b542f llvm::sys::PrintStackTrace(llvm::raw_ostream&) 
> (/lib/x86_64-linux-gnu/libLLVM-11.so.1+0xaa642f)
>  #1 0x7fa2755b3790 llvm::sys::RunSignalHandlers() 
> (/lib/x86_64-linux-gnu/libLLVM-11.so.1+0xaa4790)
>  #2 0x7fa2755b4b7d llvm::sys::CleanupOnSignal(unsigned long) 
> (/lib/x86_64-linux-gnu/libLLVM-11.so.1+0xaa5b7d)
>  #3 0x7fa2754fcb0a (/lib/x86_64-linux-gnu/libLLVM-11.so.1+0x9edb0a)
>  #4 0x7fa2754fcaab (/lib/x86_64-linux-gnu/libLLVM-11.so.1+0x9edaab)
>  #5 0x7fa2755b025e (/lib/x86_64-linux-gnu/libLLVM-11.so.1+0xaa125e)
>  #6 0x00412932 (/usr/bin/clang-11+0x412932)
>  #7 0x7fa275508b6f llvm::report_fatal_error(llvm::Twine const&, bool) 
> (/lib/x86_64-linux-gnu/libLLVM-11.so.1+0x9f9b6f)
>  #8 0x7fa275508a48 (/lib/x86_64-linux-gnu/libLLVM-11.so.1+0x9f9a48)
>  #9 0x7fa275fa050f (/lib/x86_64-linux-gnu/libLLVM-11.so.1+0x149150f)
> #10 0x7fa2756c4579 llvm::FPPassManager::runOnFunction(llvm::Function&) 
> (/lib/x86_64-linux-gnu/libLLVM-11.so.1+0xbb5579)
> #11 0x7fa2756c9b23 llvm::FPPassManager::runOnModule(llvm::Module&) 
> (/lib/x86_64-linux-gnu/libLLVM-11.so.1+0xbbab23)
> #12 0x7fa2756c4b90 llvm::legacy::PassManagerImpl::run(llvm::Module&) 
> (/lib/x86_64-linux-gnu/libLLVM-11.so.1+0xbb5b90)
> #13 0x7fa27b034120 clang::EmitBackendOutput(clang::DiagnosticsEngine&, 
> clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, 
> clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout 
> const&, llvm::Module*, clang::BackendAction, 
> std::unique_ptr std::default_delete >) 
> (/lib/x86_64-linux-gnu/libclang-cpp.so.11+0x1581120)
> #14 0x7fa27b2f2076 (/lib/x86_64-linux-gnu/libclang-cpp.so.11+0x183f076)
> #15 0x7fa27a3bd003 clang::ParseAST(clang::Sema&, bool, bool) 
> (/lib/x86_64-linux-gnu/libclang-cpp.so.11+0x90a003)
> #16 0x7fa27b9875c8 clang::FrontendAction::Execute() 
> (/lib/x86_64-linux-gnu/libclang-cpp.so.11+0x1ed45c8)
> #17 0x7fa27b93d8c1 
> clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) 
> 

[jira] [Updated] (PROTON-2358) [cpp] Improve test coverage in container.cpp

2021-04-01 Thread Justin Ross (Jira)


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

Justin Ross updated PROTON-2358:

Description: 
*Assignee: Mehaboob Shariff*

Container.cpp currently has 70% line coverage after running the tests.  
Increase the coverage to 100% or as close as is practical.  To do this, add or 
modify tests in container_test.cpp.

To set up coverage builds:
 # Install lcov, the code coverage tool
 # Configure the build for coverage analysis: cmake -DCMAKE_BUILD_TYPE=Coverage 
[...]
 # Build the code: make build
 # Run the tests: make test
 # Generate coverage results: make coverage
 # View the results at /coverage_results

  was:
Container.cpp currently has 70% line coverage after running the tests.  
Increase the coverage to 100% or as close as is practical.  To do this, add or 
modify tests in container_test.cpp.

To set up coverage builds:
 # Install lcov, the code coverage tool
 # Configure the build for coverage analysis: cmake -DCMAKE_BUILD_TYPE=Coverage 
[...]
 # Build the code: make build
 # Run the tests: make test
 # Generate coverage results: make coverage
 # View the results at /coverage_results


> [cpp] Improve test coverage in container.cpp
> 
>
> Key: PROTON-2358
> URL: https://issues.apache.org/jira/browse/PROTON-2358
> Project: Qpid Proton
>  Issue Type: Test
>  Components: cpp-binding
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Major
>
> *Assignee: Mehaboob Shariff*
> Container.cpp currently has 70% line coverage after running the tests.  
> Increase the coverage to 100% or as close as is practical.  To do this, add 
> or modify tests in container_test.cpp.
> To set up coverage builds:
>  # Install lcov, the code coverage tool
>  # Configure the build for coverage analysis: cmake 
> -DCMAKE_BUILD_TYPE=Coverage [...]
>  # Build the code: make build
>  # Run the tests: make test
>  # Generate coverage results: make coverage
>  # View the results at /coverage_results



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (PROTON-2356) [cpp] Improve test coverage in message.cpp

2021-04-01 Thread Justin Ross (Jira)


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

Justin Ross updated PROTON-2356:

Description: 
*Assignee: Kajal Sah*

Message.cpp currently has 84% line coverage after running the tests.  Increase 
the coverage to 100% or as close as is practical.  To do this, add or modify 
tests in message_test.cpp.

To set up coverage builds:
 # Install lcov, the code coverage tool
 # Configure the build for coverage analysis: cmake -DCMAKE_BUILD_TYPE=Coverage 
[...]
 # Build the code: make build
 # Run the tests: make test
 # Generate coverage results: make coverage
 # View the results at /coverage_results

  was:
Message.cpp currently has 84% line coverage after running the tests.  Increase 
the coverage to 100% or as close as is practical.  To do this, add or modify 
tests in message_test.cpp.

To set up coverage builds:
 # Install lcov, the code coverage tool
 # Configure the build for coverage analysis: cmake -DCMAKE_BUILD_TYPE=Coverage 
[...]
 # Build the code: make build
 # Run the tests: make test
 # Generate coverage results: make coverage
 # View the results at /coverage_results


> [cpp] Improve test coverage in message.cpp
> --
>
> Key: PROTON-2356
> URL: https://issues.apache.org/jira/browse/PROTON-2356
> Project: Qpid Proton
>  Issue Type: Test
>  Components: cpp-binding
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Major
>
> *Assignee: Kajal Sah*
> Message.cpp currently has 84% line coverage after running the tests.  
> Increase the coverage to 100% or as close as is practical.  To do this, add 
> or modify tests in message_test.cpp.
> To set up coverage builds:
>  # Install lcov, the code coverage tool
>  # Configure the build for coverage analysis: cmake 
> -DCMAKE_BUILD_TYPE=Coverage [...]
>  # Build the code: make build
>  # Run the tests: make test
>  # Generate coverage results: make coverage
>  # View the results at /coverage_results



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Commented] (PROTON-2360) [cpp] Improve test coverage in link.cpp

2021-04-01 Thread Justin Ross (Jira)


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

Justin Ross commented on PROTON-2360:
-

[~digitalsimboja], when you have something that increases the coverage, I 
recommend raising a PR to get some early feedback.

> [cpp] Improve test coverage in link.cpp
> ---
>
> Key: PROTON-2360
> URL: https://issues.apache.org/jira/browse/PROTON-2360
> Project: Qpid Proton
>  Issue Type: Test
>  Components: cpp-binding
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Major
>
> *Assignee: Sunday Mgbogu*
> Link.cpp currently has 82% line coverage after running the tests.  Increase 
> the coverage to 100% or as close as is practical.  To do this, add or modify 
> tests in link_test.cpp.
> To set up coverage builds:
>  # Install lcov, the code coverage tool
>  # Configure the build for coverage analysis: cmake 
> -DCMAKE_BUILD_TYPE=Coverage [...]
>  # Build the code: make build
>  # Run the tests: make test
>  # Generate coverage results: make coverage
>  # View the results at /coverage_results



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (PROTON-2360) [cpp] Improve test coverage in link.cpp

2021-04-01 Thread Justin Ross (Jira)


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

Justin Ross updated PROTON-2360:

Description: 
*Assignee: Sunday Mgbogu*

Link.cpp currently has 82% line coverage after running the tests.  Increase the 
coverage to 100% or as close as is practical.  To do this, add or modify tests 
in link_test.cpp.

To set up coverage builds:
 # Install lcov, the code coverage tool
 # Configure the build for coverage analysis: cmake -DCMAKE_BUILD_TYPE=Coverage 
[...]
 # Build the code: make build
 # Run the tests: make test
 # Generate coverage results: make coverage
 # View the results at /coverage_results

  was:
Link.cpp currently has 82% line coverage after running the tests.  Increase the 
coverage to 100% or as close as is practical.  To do this, add or modify tests 
in link_test.cpp.

To set up coverage builds:
 # Install lcov, the code coverage tool
 # Configure the build for coverage analysis: cmake -DCMAKE_BUILD_TYPE=Coverage 
[...]
 # Build the code: make build
 # Run the tests: make test
 # Generate coverage results: make coverage
 # View the results at /coverage_results


> [cpp] Improve test coverage in link.cpp
> ---
>
> Key: PROTON-2360
> URL: https://issues.apache.org/jira/browse/PROTON-2360
> Project: Qpid Proton
>  Issue Type: Test
>  Components: cpp-binding
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Major
>
> *Assignee: Sunday Mgbogu*
> Link.cpp currently has 82% line coverage after running the tests.  Increase 
> the coverage to 100% or as close as is practical.  To do this, add or modify 
> tests in link_test.cpp.
> To set up coverage builds:
>  # Install lcov, the code coverage tool
>  # Configure the build for coverage analysis: cmake 
> -DCMAKE_BUILD_TYPE=Coverage [...]
>  # Build the code: make build
>  # Run the tests: make test
>  # Generate coverage results: make coverage
>  # View the results at /coverage_results



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Commented] (PROTON-2357) [cpp] Improve test coverage in url.cpp

2021-04-01 Thread Rakhi Kumari (Jira)


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

Rakhi Kumari commented on PROTON-2357:
--

Thanks for the suggestion!! I'm on it.

> [cpp] Improve test coverage in url.cpp
> --
>
> Key: PROTON-2357
> URL: https://issues.apache.org/jira/browse/PROTON-2357
> Project: Qpid Proton
>  Issue Type: Test
>  Components: cpp-binding
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Major
>
> *Assignee: Rakhi Kumari*
> Url.cpp currently has 76% line coverage after running the tests.  Increase 
> the coverage to 100% or as close as is practical.  To do this, add or modify 
> tests in url_test.cpp.
> To set up coverage builds:
>  # Install lcov, the code coverage tool
>  # Configure the build for coverage analysis: cmake 
> -DCMAKE_BUILD_TYPE=Coverage [...]
>  # Build the code: make build
>  # Run the tests: make test
>  # Generate coverage results: make coverage
>  # View the results at /coverage_results



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Commented] (QPIDJMS-531) Update Netty to 4.1.62.Final and tcnative to 2.0.38.Final

2021-04-01 Thread ASF subversion and git services (Jira)


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

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

Commit 9309219a84e4ab36fdbf8dd45ad09243c527df78 in qpid-jms's branch 
refs/heads/main from Robbie Gemmell
[ https://gitbox.apache.org/repos/asf?p=qpid-jms.git;h=9309219 ]

QPIDJMS-531: update to Update netty to 4.1.63.Final


> Update Netty to 4.1.62.Final and tcnative to 2.0.38.Final
> -
>
> Key: QPIDJMS-531
> URL: https://issues.apache.org/jira/browse/QPIDJMS-531
> Project: Qpid JMS
>  Issue Type: Task
>  Components: qpid-jms-client
>Affects Versions: 0.57.0
>Reporter: Timothy A. Bish
>Assignee: Timothy A. Bish
>Priority: Minor
> Fix For: 0.58.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Commented] (PROTON-2357) [cpp] Improve test coverage in url.cpp

2021-04-01 Thread Justin Ross (Jira)


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

Justin Ross commented on PROTON-2357:
-

[~DreamPearl], if you are already at 98%, I think raising a PR for initial 
review is a good idea.  You'll likely get comments about how to structure the 
tests and that kind of thing.

> [cpp] Improve test coverage in url.cpp
> --
>
> Key: PROTON-2357
> URL: https://issues.apache.org/jira/browse/PROTON-2357
> Project: Qpid Proton
>  Issue Type: Test
>  Components: cpp-binding
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Major
>
> *Assignee: Rakhi Kumari*
> Url.cpp currently has 76% line coverage after running the tests.  Increase 
> the coverage to 100% or as close as is practical.  To do this, add or modify 
> tests in url_test.cpp.
> To set up coverage builds:
>  # Install lcov, the code coverage tool
>  # Configure the build for coverage analysis: cmake 
> -DCMAKE_BUILD_TYPE=Coverage [...]
>  # Build the code: make build
>  # Run the tests: make test
>  # Generate coverage results: make coverage
>  # View the results at /coverage_results



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (PROTON-2357) [cpp] Improve test coverage in url.cpp

2021-04-01 Thread Justin Ross (Jira)


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

Justin Ross updated PROTON-2357:

Description: 
*Assignee: Rakhi Kumari*

Url.cpp currently has 76% line coverage after running the tests.  Increase the 
coverage to 100% or as close as is practical.  To do this, add or modify tests 
in url_test.cpp.

To set up coverage builds:
 # Install lcov, the code coverage tool
 # Configure the build for coverage analysis: cmake -DCMAKE_BUILD_TYPE=Coverage 
[...]
 # Build the code: make build
 # Run the tests: make test
 # Generate coverage results: make coverage
 # View the results at /coverage_results

  was:
Url.cpp currently has 76% line coverage after running the tests.  Increase the 
coverage to 100% or as close as is practical.  To do this, add or modify tests 
in url_test.cpp.

To set up coverage builds:
 # Install lcov, the code coverage tool
 # Configure the build for coverage analysis: cmake -DCMAKE_BUILD_TYPE=Coverage 
[...]
 # Build the code: make build
 # Run the tests: make test
 # Generate coverage results: make coverage
 # View the results at /coverage_results


> [cpp] Improve test coverage in url.cpp
> --
>
> Key: PROTON-2357
> URL: https://issues.apache.org/jira/browse/PROTON-2357
> Project: Qpid Proton
>  Issue Type: Test
>  Components: cpp-binding
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Major
>
> *Assignee: Rakhi Kumari*
> Url.cpp currently has 76% line coverage after running the tests.  Increase 
> the coverage to 100% or as close as is practical.  To do this, add or modify 
> tests in url_test.cpp.
> To set up coverage builds:
>  # Install lcov, the code coverage tool
>  # Configure the build for coverage analysis: cmake 
> -DCMAKE_BUILD_TYPE=Coverage [...]
>  # Build the code: make build
>  # Run the tests: make test
>  # Generate coverage results: make coverage
>  # View the results at /coverage_results



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Commented] (PROTON-2357) [cpp] Improve test coverage in url.cpp

2021-04-01 Thread Justin Ross (Jira)


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

Justin Ross commented on PROTON-2357:
-

Hi, [~sushmau].  I assigned this one to Rakhi.  I'll find another task for you.

> [cpp] Improve test coverage in url.cpp
> --
>
> Key: PROTON-2357
> URL: https://issues.apache.org/jira/browse/PROTON-2357
> Project: Qpid Proton
>  Issue Type: Test
>  Components: cpp-binding
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Major
>
> Url.cpp currently has 76% line coverage after running the tests.  Increase 
> the coverage to 100% or as close as is practical.  To do this, add or modify 
> tests in url_test.cpp.
> To set up coverage builds:
>  # Install lcov, the code coverage tool
>  # Configure the build for coverage analysis: cmake 
> -DCMAKE_BUILD_TYPE=Coverage [...]
>  # Build the code: make build
>  # Run the tests: make test
>  # Generate coverage results: make coverage
>  # View the results at /coverage_results



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Commented] (QPID-8484) [Broker-J] Reimplementation of the limit number of connections per user

2021-04-01 Thread ASF GitHub Bot (Jira)


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

ASF GitHub Bot commented on QPID-8484:
--

mklaca edited a comment on pull request #76:
URL: https://github.com/apache/qpid-broker-j/pull/76#issuecomment-800155282


   Hi @alex-rufous,
   
   > I think that creation of design document (we can use qpid confluence) for 
this new feature (before jumping into implementation) would benefit us both and 
could save us a lot of time. it is still not to late to do it.
   
   I don't have rights to create a new or edit any qpid confluence page.
   
   > IMHO functionality to check limits should live on ConnectionLimitProviders 
including registering and de-registering connections. On connection 
registration/deregistration the VH simply needs to iterate through its own and 
broker ConnectionLimitProviders and call corresponding methods 
(register/deregister) to verify limits. The VH should not call 
ConnectionLimiter and keep a reference to it. Instead, VH should operate with 
ConnectionLimitProviders.
   
   If the borker ConnectionLimitProvider kept the ConnectionLimiter then the 
connection counters inside the limiter would be shared amoung multiple 
VirtualHosts. The VirtualHosts would effect each other, but it is stated in the 
documentation - [Java Broker 
concepts](http://qpid.apache.org/releases/qpid-broker-j-8.0.3/book/Java-Broker-Concepts-Virtualhosts.html)
 that:
   _Virtualhosts are independent; the messaging that goes on within one 
virtualhost is independent of any messaging that goes on in another 
virtualhost._
   Hence, I proposed the ConnectionLimitProvider as a factory that builds a new 
independent limiter, which is provided to a VirtualHost.
   
   VirtualHost can not simple iterate through the limit providers or limiters 
because the consistency of the connection counters is needed. Let's suppose 
that the VirtualHost has multiple limit providers. If any of the 
providers/limiters fails to register connection then all have to fail. The 
connection has to be registered everywhere or nowhere and so the co-ordination 
is needed. Hence, the virtual host needs a master limiter that co-ordinates the 
update of the connection counters.
   
   There are concurrency issues with simple iteration. The working thread needs 
an exclusive access to all connection counters of the user to check and update 
all counters atomically.
   
   I see three approaches:
   1. One connection limiter.
   2. Master limiter that co-ordinates all limiters.
   3. Chain of responsibility, when the limiter itself call the next limiter.
   
   I have to point out that the functionality of the multiple limiters has not 
been requested yet.
   
   > IMHO a special runtime exception can be thrown when any of the limits is 
breached this type of exception can be caught in the protocol IO layers and 
connection can be closed accordingly.
   
   I have introduced a new ConnectionLimitException but it looks like a checked 
exception to me.
   
   > I would prefer to use json/yml over bespoke format. That should reduce 
implementation code.
   
   I want the file based configuration that is backward compatible with 
existing ACL rule file. Therefore, I had introduced a ACL like bespoke format 
and so it is not required to generate a new configuration file in different 
format. The file based configuration can point to the former ACL file.
   
   > The limit rules can be simplified by removing "Blocked". The user simply 
can create a rule for ALL where connection limit (frequency limit) is 0.
   
   Yes, it can be but 
   
   - Declaring an user as blocked is more friendly and understandable.
   - Setting "count_limit=0" could be confusing because the value 0 has meaning 
"no limit" in many other situations. I don't like the idea of the "magic" 
constant.
   - The blocked user is handled in different way as unblocked user, a 
connection opened by blocked user can be rejected immediately and any counter 
is not needed.
   
   > A frequency value can be set as a number of connections per unit of time 
in the rules. For example, 1/s, 2/m,100/h, 1000/d. I think that would make the 
rules simpler for the end user.
   
   Yes it is transparent for end user, I have implemented it but the feature 
complicates evaluation of the rules a lot.
   
   Let suppose that user is a part of the groups gA, gB, gC. Each group has 
frequency limit:
   gA: frequency limit = 10
   gB: frequency limit = 5
   gC: frequency limit = 15
   I can easily pick up the most restrictive limit 5 because all limits have 
the same time period and I can easily merge all limits into single effective 
limit.
   
   The frequency limit 1/s is not the same as 60/m, they looks similar but 60/m 
allows a short peak of new connections, 1/s does not. If multiple rules could 
have different time period then I can not pick up

[GitHub] [qpid-broker-j] mklaca edited a comment on pull request #76: QPID-8484: [Broker-J] Reimplementation of the limit number of connections per user

2021-04-01 Thread GitBox


mklaca edited a comment on pull request #76:
URL: https://github.com/apache/qpid-broker-j/pull/76#issuecomment-800155282


   Hi @alex-rufous,
   
   > I think that creation of design document (we can use qpid confluence) for 
this new feature (before jumping into implementation) would benefit us both and 
could save us a lot of time. it is still not to late to do it.
   
   I don't have rights to create a new or edit any qpid confluence page.
   
   > IMHO functionality to check limits should live on ConnectionLimitProviders 
including registering and de-registering connections. On connection 
registration/deregistration the VH simply needs to iterate through its own and 
broker ConnectionLimitProviders and call corresponding methods 
(register/deregister) to verify limits. The VH should not call 
ConnectionLimiter and keep a reference to it. Instead, VH should operate with 
ConnectionLimitProviders.
   
   If the borker ConnectionLimitProvider kept the ConnectionLimiter then the 
connection counters inside the limiter would be shared amoung multiple 
VirtualHosts. The VirtualHosts would effect each other, but it is stated in the 
documentation - [Java Broker 
concepts](http://qpid.apache.org/releases/qpid-broker-j-8.0.3/book/Java-Broker-Concepts-Virtualhosts.html)
 that:
   _Virtualhosts are independent; the messaging that goes on within one 
virtualhost is independent of any messaging that goes on in another 
virtualhost._
   Hence, I proposed the ConnectionLimitProvider as a factory that builds a new 
independent limiter, which is provided to a VirtualHost.
   
   VirtualHost can not simple iterate through the limit providers or limiters 
because the consistency of the connection counters is needed. Let's suppose 
that the VirtualHost has multiple limit providers. If any of the 
providers/limiters fails to register connection then all have to fail. The 
connection has to be registered everywhere or nowhere and so the co-ordination 
is needed. Hence, the virtual host needs a master limiter that co-ordinates the 
update of the connection counters.
   
   There are concurrency issues with simple iteration. The working thread needs 
an exclusive access to all connection counters of the user to check and update 
all counters atomically.
   
   I see three approaches:
   1. One connection limiter.
   2. Master limiter that co-ordinates all limiters.
   3. Chain of responsibility, when the limiter itself call the next limiter.
   
   I have to point out that the functionality of the multiple limiters has not 
been requested yet.
   
   > IMHO a special runtime exception can be thrown when any of the limits is 
breached this type of exception can be caught in the protocol IO layers and 
connection can be closed accordingly.
   
   I have introduced a new ConnectionLimitException but it looks like a checked 
exception to me.
   
   > I would prefer to use json/yml over bespoke format. That should reduce 
implementation code.
   
   I want the file based configuration that is backward compatible with 
existing ACL rule file. Therefore, I had introduced a ACL like bespoke format 
and so it is not required to generate a new configuration file in different 
format. The file based configuration can point to the former ACL file.
   
   > The limit rules can be simplified by removing "Blocked". The user simply 
can create a rule for ALL where connection limit (frequency limit) is 0.
   
   Yes, it can be but 
   
   - Declaring an user as blocked is more friendly and understandable.
   - Setting "count_limit=0" could be confusing because the value 0 has meaning 
"no limit" in many other situations. I don't like the idea of the "magic" 
constant.
   - The blocked user is handled in different way as unblocked user, a 
connection opened by blocked user can be rejected immediately and any counter 
is not needed.
   
   > A frequency value can be set as a number of connections per unit of time 
in the rules. For example, 1/s, 2/m,100/h, 1000/d. I think that would make the 
rules simpler for the end user.
   
   Yes it is transparent for end user, I have implemented it but the feature 
complicates evaluation of the rules a lot.
   
   Let suppose that user is a part of the groups gA, gB, gC. Each group has 
frequency limit:
   gA: frequency limit = 10
   gB: frequency limit = 5
   gC: frequency limit = 15
   I can easily pick up the most restrictive limit 5 because all limits have 
the same time period and I can easily merge all limits into single effective 
limit.
   
   The frequency limit 1/s is not the same as 60/m, they looks similar but 60/m 
allows a short peak of new connections, 1/s does not. If multiple rules could 
have different time period then I can not pick up the most restrictive limit 
and the user can have multiple frequency limits with different frequency 
periods.
   
   > The reject reason can be logged as part of connection close operational 
logs. Thus, new message resources are not really required.

[jira] [Commented] (PROTON-2357) [cpp] Improve test coverage in url.cpp

2021-04-01 Thread Rakhi Kumari (Jira)


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

Rakhi Kumari commented on PROTON-2357:
--

Hi [~sushmau] [~jross]
 Looks like there has been some confusion, I thought I had to work on this bug 
as per the conversation on the mailing list, and I am almost done and got 98% 
coverage already.

Justin, can you please take a look?

> [cpp] Improve test coverage in url.cpp
> --
>
> Key: PROTON-2357
> URL: https://issues.apache.org/jira/browse/PROTON-2357
> Project: Qpid Proton
>  Issue Type: Test
>  Components: cpp-binding
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Major
>
> Url.cpp currently has 76% line coverage after running the tests.  Increase 
> the coverage to 100% or as close as is practical.  To do this, add or modify 
> tests in url_test.cpp.
> To set up coverage builds:
>  # Install lcov, the code coverage tool
>  # Configure the build for coverage analysis: cmake 
> -DCMAKE_BUILD_TYPE=Coverage [...]
>  # Build the code: make build
>  # Run the tests: make test
>  # Generate coverage results: make coverage
>  # View the results at /coverage_results



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Commented] (PROTON-2357) [cpp] Improve test coverage in url.cpp

2021-04-01 Thread Sushma Unnibhavi (Jira)


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

Sushma Unnibhavi commented on PROTON-2357:
--

I have started working on this issue and will submit a patch when I finish this.

> [cpp] Improve test coverage in url.cpp
> --
>
> Key: PROTON-2357
> URL: https://issues.apache.org/jira/browse/PROTON-2357
> Project: Qpid Proton
>  Issue Type: Test
>  Components: cpp-binding
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Major
>
> Url.cpp currently has 76% line coverage after running the tests.  Increase 
> the coverage to 100% or as close as is practical.  To do this, add or modify 
> tests in url_test.cpp.
> To set up coverage builds:
>  # Install lcov, the code coverage tool
>  # Configure the build for coverage analysis: cmake 
> -DCMAKE_BUILD_TYPE=Coverage [...]
>  # Build the code: make build
>  # Run the tests: make test
>  # Generate coverage results: make coverage
>  # View the results at /coverage_results



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Commented] (DISPATCH-2022) system_tests_link_routes rarely fails with Cannot load configuration file

2021-04-01 Thread Charles E. Rolke (Jira)


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

Charles E. Rolke commented on DISPATCH-2022:


The lines of code quoted in comment #1 used to say:
{code:java}
cfg = Qdrouterd.Config(config)
router = self.tester.qdrouterd("X", cfg, wait=False)
# we expect the router to fail
while router.poll() is None:
sleep(0.1)
self.assertRaises(RuntimeError, router.teardown)
self.assertNotEqual(0, router.returncode)
{code}
Does this look more like a suitable timeout loop?

The code was replaced under _DISPATCH-1678: fix misleading ASAN tracebacks for 
pooled items._
 * It is unclear how the code change relates to ASAN and pooled objects. Maybe 
The code quoted here causes object leaks?

Logically this test has nothing to do with link routes and this test should be 
moved out of the current source file. The unparsable config file should fail 
the same way if the failing config object has _linkroute_ in its name or not. 
But that's a separate issue.

> system_tests_link_routes rarely fails with Cannot load configuration file
> -
>
> Key: DISPATCH-2022
> URL: https://issues.apache.org/jira/browse/DISPATCH-2022
> Project: Qpid Dispatch
>  Issue Type: Test
>Affects Versions: 1.16.0
>Reporter: Jiri Daněk
>Priority: Minor
>
> The following happens every time on AArch64, but it has once happened on 
> amd64 too:
> https://github.com/apache/qpid-dispatch/runs/2183106014?check_suite_focus=true#step:9:652
> {noformat}
> 14: Process 2203 error: still running
> 14: qdrouterd -c X.conf -I 
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/python
> 14: 
> /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/build/tests/system_test.dir/system_tests_link_routes/ConnectionLinkRouteTest/test_config_file_bad/X-3.cmd
> 14: 
> 14: 2021-03-24 10:05:46.694485 + AGENT (error) Contents of failed config 
> file
> 14: 2021-03-24 10:05:46.694657 + AGENT (error) Line 1 |[["router", {
> 14: 2021-03-24 10:05:46.694701 + AGENT (error) Line 2 |"mode": "interior",
> 14: 2021-03-24 10:05:46.694738 + AGENT (error) Line 3 |"id": "QDR.X",
> 14: 2021-03-24 10:05:46.694772 + AGENT (error) Line 4 |"debugDumpFile": 
> "/home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/build/tests/system_test.dir/system_tests_link_routes/ConnectionLinkRouteTest/test_config_file_bad/X-qddebug.txt"}],
> 14: 2021-03-24 10:05:46.694806 + AGENT (error) Line 5 |["listener", {
> 14: 2021-03-24 10:05:46.694838 + AGENT (error) Line 6 |"role": "normal",
> 14: 2021-03-24 10:05:46.694870 + AGENT (error) Line 7 |"host": "0.0.0.0",
> 14: 2021-03-24 10:05:46.694902 + AGENT (error) Line 8 |"port": "25577",
> 14: 2021-03-24 10:05:46.694935 + AGENT (error) Line 9 |"saslMechanisms": 
> "ANONYMOUS",
> 14: 2021-03-24 10:05:46.694967 + AGENT (error) Line 10 
> |"idleTimeoutSeconds": "120",
> 14: 2021-03-24 10:05:46.694999 + AGENT (error) Line 11 
> |"authenticatePeer": "no"}],
> 14: 2021-03-24 10:05:46.695030 + AGENT (error) Line 12 
> |connection.["linkRoute", {
> 14: 2021-03-24 10:05:46.695062 + AGENT (error) Line 13 |"pattern": 
> "i/am/bad",
> 14: 2021-03-24 10:05:46.695094 + AGENT (error) Line 14 |"direction": 
> "out"}],
> 14: 2021-03-24 10:05:46.695130 + AGENT (error) Line 15 |["log", {
> 14: 2021-03-24 10:05:46.695200 + AGENT (error) Line 16 |"module": 
> "DEFAULT",
> 14: 2021-03-24 10:05:46.695235 + AGENT (error) Line 17 |"enable": 
> "trace+",
> 14: 2021-03-24 10:05:46.695267 + AGENT (error) Line 18 |"includeSource": 
> "true",
> 14: 2021-03-24 10:05:46.695298 + AGENT (error) Line 19 |"outputFile": 
> "X.log"}]]
> 14: 2021-03-24 10:05:46.695369 + ERROR (error) Python: Exception: Cannot 
> load configuration file X.conf: Expecting value: line 12 column 1 (char 400)
> 14: 2021-03-24 10:05:46.738956 + ERROR (error) Traceback (most recent 
> call last):
> 14:   File 
> "/home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
>  line 61, in __init__
> 14: self.load(filename, raw_json)
> 14:   File 
> "/home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
>  line 242, in load
> 14: self.load(f, raw_json)
> 14:   File 
> "/home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
>  line 244, in load
> 14: sections = self._parserawjson(source) if raw_json else 
> self._parse(source)
> 14:   File 
> "/home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
>  line 208,

[GitHub] [qpid-jms] alainpham opened a new pull request #39: Compare hostname instead of IP to avoid uris being discared

2021-04-01 Thread GitBox


alainpham opened a new pull request #39:
URL: https://github.com/apache/qpid-jms/pull/39


   There is an issue when the a client tries to reach AMQP brokers are behind 
an HAProxy with TLS/SNI routing such as when deployed on Openshift and exposed 
through Openshift Routes.
   Hostnames that are mentioned in the list of failover uris are discarded as 
they resolve to the same IP address. Comparing URI's should resolve to IP 
addresses only when it's a loopback address, otherwise the hostnames should be 
used to avoid being discarded.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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



[jira] [Commented] (PROTON-2362) c-threaderciser timed out on 32-core machine.

2021-04-01 Thread michael goulish (Jira)


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

michael goulish commented on PROTON-2362:
-

I am running batches of 50 threaderciser tests, 64 threads each, turning off 
one feature at a time, and counting failures.

See if you can spot the case, below, that I feel may be interesting.

 

All Features On   crash: 10

-no-close-connect    crash: 12

-no-listen   crash: 0    hang: 2

-no-close-listen  (y)   :)    (*)(*r)(*g) {color:#de350b}*NO PROBLEMS 
(*g)(*r)(*)    :)   (y)*      {color}

{color:#de350b}{color:#172b4d}~{color:#c1c7d0} 
(sorry, I can't figure out how to make the above text 
blink){color}~{color}{color} 

 

 

 

p.s.

    _"Brontosaurus"_ means _"Thunder Lizard"_, a kind of dinosaur.  

  I do not have a dinosaur.

  _"Brontonomicon",_ on the other hand, means _"What the Thunder Said"_    
or   _"Words of the Thunder"_   or possibly   _"The Book of Thunder"_.

  That's what I've got. 

  And when the thunder speaks, the software had better listen.

 

 

> c-threaderciser timed out on 32-core machine.
> -
>
> Key: PROTON-2362
> URL: https://issues.apache.org/jira/browse/PROTON-2362
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: michael goulish
>Priority: Major
>
> Using recent master – maybe 3 days old or so – I just ran Proton's ctest, 
> after turning on THREADERCISER.  I ran it on a box with 32 physical cores, 64 
> threads.
>  
> Test number 6 – c-threaderciser – failed with timeout after 1500 seconds.
> ( 1.5e18 femtoseconds. )
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Comment Edited] (DISPATCH-2018) Improper handling of link refusal when destination peer for link-routing goes away

2021-04-01 Thread Robbie Gemmell (Jira)


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

Robbie Gemmell edited comment on DISPATCH-2018 at 4/1/21, 10:52 AM:


I dont personally have a reproducer. My log snippets were out of a separate 
user report of a client issue, where I spotted the router behaviours in the 
protocol trace logs and it was the 'case 2' behaviour that caused the client to 
allow the application/itself into a state that then gave opportunity to hit the 
clients own bug in handling the scenario (QPIDJMS-529).

I'll point you to the report elsewhere, but I'd say the main difference looks 
to be repetition and timing. The user scenario looked to open+use+closes a 
sender periodically over time, and repeatedly down the link routed broker while 
this is ongoing. It also has link routed consumer to consume the messages it 
sends.


was (Author: gemmellr):
I dont personally have a reproducer. My log snippets were out of a separate 
user report of a client issue, where I spotted the router behaviours in the 
protocol trace logs and it was the 'case 2' behaviour that caused the client to 
allow the application/itself into a state that then gave opportunity to hit the 
clients own bug in handling the scenario (QPIDJMS-529).

I'll point you to the report elsewhere, but I'd say the main difference looks 
to be repetition and timing. The user scenario looked to open+use+closes a 
sender periodically over time, and repeatedly down the link routed broker while 
this is ongoing. It also has link routed consumer to consumer the messages it 
sends.

> Improper handling of link refusal when destination peer for link-routing goes 
> away
> --
>
> Key: DISPATCH-2018
> URL: https://issues.apache.org/jira/browse/DISPATCH-2018
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 1.14.0
>Reporter: Robbie Gemmell
>Priority: Major
>
> In case of a router doing link routing to a broker, which goes away during an 
> error handling test, the router can then need to refuse new links and/or kill 
> existing links as it has nowhere to route them. That is all to be expected.
> When failing to attach some sender links though, it was observed the router 
> in one case did not response to a clients attach at all, and in a second case 
> incorrectly sent a response attach with a populated target, having address = 
> null, followed by a detach with error (which looks to lead to some unexpected 
> client behaviour as it was mislead into thinking the producer actually 
> opened, likely exposing a separate client issue).
> The attach in the second case should have had target=null, rather than a null 
> address, to indicate that this was a link refusal and the detach with error 
> would follow:
> {noformat}
> [1475580346:1] -> 
> Attach\{name='qpid-jms:sender:ID:cc949561-56bc-44f7-8d96-74f8a8d49988:521:8:1:destination',
>  handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
> source=Source{address='ID:cc949561-56bc-44f7-8d96-74f8a8d49988:521:8:1', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, distributionMode=null, filter=null, 
> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list, 
> amqp:released:list, amqp:modified:list], capabilities=null}, 
> target=Target\{address='destination', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=null, offeredCapabilities=null, 
> desiredCapabilities=[DELAYED_DELIVERY], properties=null}
> [1475580346:1] <- 
> Attach\{name='qpid-jms:sender:ID:cc949561-56bc-44f7-8d96-74f8a8d49988:521:8:1:destination',
>  handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST, 
> source=Source{address='ID:cc949561-56bc-44f7-8d96-74f8a8d49988:521:8:1', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, distributionMode=null, filter=null, 
> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list, 
> amqp:released:list, amqp:modified:list], capabilities=null}, 
> target=Target\{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, 
> properties=null}
> [1475580346:1] <- Detach\{handle=0, closed=true, 
> error=Error{condition=qd:no-route-to-dest, description='No route to the 
> destination node', info=null}}
> {noformat}
> In a third related instant earlier in 

[jira] [Commented] (DISPATCH-2018) Improper handling of link refusal when destination peer for link-routing goes away

2021-04-01 Thread Robbie Gemmell (Jira)


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

Robbie Gemmell commented on DISPATCH-2018:
--

I dont personally have a reproducer. My log snippets were out of a separate 
user report of a client issue, where I spotted the router behaviours in the 
protocol trace logs and it was the 'case 2' behaviour that caused the client to 
allow the application/itself into a state that then gave opportunity to hit the 
clients own bug in handling the scenario (QPIDJMS-529).

I'll point you to the report elsewhere, but I'd say the main difference looks 
to be repetition and timing. The user scenario looked to open+use+closes a 
sender periodically over time, and repeatedly down the link routed broker while 
this is ongoing. It also has link routed consumer to consumer the messages it 
sends.

> Improper handling of link refusal when destination peer for link-routing goes 
> away
> --
>
> Key: DISPATCH-2018
> URL: https://issues.apache.org/jira/browse/DISPATCH-2018
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 1.14.0
>Reporter: Robbie Gemmell
>Priority: Major
>
> In case of a router doing link routing to a broker, which goes away during an 
> error handling test, the router can then need to refuse new links and/or kill 
> existing links as it has nowhere to route them. That is all to be expected.
> When failing to attach some sender links though, it was observed the router 
> in one case did not response to a clients attach at all, and in a second case 
> incorrectly sent a response attach with a populated target, having address = 
> null, followed by a detach with error (which looks to lead to some unexpected 
> client behaviour as it was mislead into thinking the producer actually 
> opened, likely exposing a separate client issue).
> The attach in the second case should have had target=null, rather than a null 
> address, to indicate that this was a link refusal and the detach with error 
> would follow:
> {noformat}
> [1475580346:1] -> 
> Attach\{name='qpid-jms:sender:ID:cc949561-56bc-44f7-8d96-74f8a8d49988:521:8:1:destination',
>  handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
> source=Source{address='ID:cc949561-56bc-44f7-8d96-74f8a8d49988:521:8:1', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, distributionMode=null, filter=null, 
> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list, 
> amqp:released:list, amqp:modified:list], capabilities=null}, 
> target=Target\{address='destination', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=null, offeredCapabilities=null, 
> desiredCapabilities=[DELAYED_DELIVERY], properties=null}
> [1475580346:1] <- 
> Attach\{name='qpid-jms:sender:ID:cc949561-56bc-44f7-8d96-74f8a8d49988:521:8:1:destination',
>  handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST, 
> source=Source{address='ID:cc949561-56bc-44f7-8d96-74f8a8d49988:521:8:1', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, distributionMode=null, filter=null, 
> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list, 
> amqp:released:list, amqp:modified:list], capabilities=null}, 
> target=Target\{address='null', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, 
> properties=null}
> [1475580346:1] <- Detach\{handle=0, closed=true, 
> error=Error{condition=qd:no-route-to-dest, description='No route to the 
> destination node', info=null}}
> {noformat}
> In a third related instant earlier in the testing, the router did actually do 
> the correct thing while returning a [different] error, ommitting the attach 
> target entirely as is directed by the protocol spec:
> {noformat}
> [851826403:1] -> 
> Attach\{name='qpid-jms:sender:ID:d070acab-905f-45a7-b663-14d35547ab3e:3:25:1:destination',
>  handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST, 
> source=Source{address='ID:d070acab-905f-45a7-b663-14d35547ab3e:3:25:1', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, distributionMode=null, filter=null, 
> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list, 
> amqp:released:list, amqp:modified:list], capabilities=null}, 
> target=Target\{address='destination', durable=

[jira] [Updated] (QPID-8509) [Broker-J] java.util.NoSuchElementException in AMQPConnection_1_0Impl.next()

2021-04-01 Thread Alex Rudyy (Jira)


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

Alex Rudyy updated QPID-8509:
-
Summary: [Broker-J] java.util.NoSuchElementException in 
AMQPConnection_1_0Impl.next()  (was: java.util.NoSuchElementException in 
AMQPConnection_1_0Impl.next())

> [Broker-J] java.util.NoSuchElementException in AMQPConnection_1_0Impl.next()
> 
>
> Key: QPID-8509
> URL: https://issues.apache.org/jira/browse/QPID-8509
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-8.0.4
>Reporter: Daniil Kirilyuk
>Priority: Minor
>
> Issue discovered during log analysis after introducing a monitoring tool, 
> which polls broker REST API for statistics on a regular basis:
> {noformat}
> 2021-02-26 13:12:13,834 INFO  [qtp1796793599-147] (q.m.a.allowed) - 
> [mng:N/A(monit@/127.0.0.1:54330)] ACL-1001 : Allowed : Access Management
> 2021-02-26 13:12:13,902 ERROR [qtp1796793599-147] 
> (o.a.q.s.m.p.f.ExceptionHandlingFilter) - Unexpected exception in servlet 
> '/api/latest/broker': 
> java.util.NoSuchElementException: null
> at 
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl$2.next(AMQPConnection_1_0Impl.java:1876)
> at 
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl$2.next(AMQPConnection_1_0Impl.java:1846)
> at 
> org.apache.qpid.server.transport.AbstractAMQPConnection.getOldestTransactionStartTime(AbstractAMQPConnection.java:1108)
> at sun.reflect.GeneratedMethodAccessor273.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.apache.qpid.server.model.ConfiguredObjectMethodAttributeOrStatistic.getValue(ConfiguredObjectMethodAttributeOrStatistic.java:68)
> at 
> org.apache.qpid.server.model.ConfiguredObjectMethodStatistic.getValue(ConfiguredObjectMethodStatistic.java:26)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject.getStatistics(AbstractConfiguredObject.java:3436)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject.getStatistics(AbstractConfiguredObject.java:3423)
> at 
> org.apache.qpid.server.management.plugin.servlet.rest.ConfiguredObjectToMapConverter.incorporateStatisticsIntoMap(ConfiguredObjectToMapConverter.java:218)
> at 
> org.apache.qpid.server.management.plugin.servlet.rest.ConfiguredObjectToMapConverter.convertObjectToMap(ConfiguredObjectToMapConverter.java:65)
> at 
> org.apache.qpid.server.management.plugin.servlet.rest.ConfiguredObjectToMapConverter.incorporateChildrenIntoMap(ConfiguredObjectToMapConverter.java:271)
> at 
> org.apache.qpid.server.management.plugin.servlet.rest.ConfiguredObjectToMapConverter.convertObjectToMap(ConfiguredObjectToMapConverter.java:69)
> at 
> org.apache.qpid.server.management.plugin.servlet.rest.ConfiguredObjectToMapConverter.incorporateChildrenIntoMap(ConfiguredObjectToMapConverter.java:271)
> at 
> org.apache.qpid.server.management.plugin.servlet.rest.ConfiguredObjectToMapConverter.convertObjectToMap(ConfiguredObjectToMapConverter.java:69)
> at 
> org.apache.qpid.server.management.plugin.controller.latest.LatestManagementController.convertObject(LatestManagementController.java:590)
> at 
> org.apache.qpid.server.management.plugin.controller.latest.LatestManagementController.formatConfiguredObject(LatestManagementController.java:555)
> at 
> org.apache.qpid.server.management.plugin.servlet.rest.RestServlet.sendResponse(RestServlet.java:263)
> at 
> org.apache.qpid.server.management.plugin.servlet.rest.RestServlet.doGet(RestServlet.java:119)
> at 
> org.apache.qpid.server.management.plugin.servlet.rest.AbstractServlet.doGet(AbstractServlet.java:128)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at 
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:755)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1617)
> at 
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter$1.run(AuthenticationCheckFilter.java:161)
> at 
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter$1.run(AuthenticationCheckFilter.java:157)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at 
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter.doFilterChainAs(AuthenticationCheckFilter.java:156)
> at 
> org.apach

  1   2   >