[GitHub] [qpid-proton] RoddieKieley closed pull request #189: PROTON-2105 Add go module support
RoddieKieley closed pull request #189: PROTON-2105 Add go module support URL: https://github.com/apache/qpid-proton/pull/189 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 With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2105) Support Go modules
[ https://issues.apache.org/jira/browse/PROTON-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16962585#comment-16962585 ] ASF GitHub Bot commented on PROTON-2105: RoddieKieley commented on issue #189: PROTON-2105 Add go module support URL: https://github.com/apache/qpid-proton/pull/189#issuecomment-547698444 @lulf Thanks for the prodding to get this done! Go module support should now be available via [7dc59589a806bc902836d86f43105aff4c8556a3](https://github.com/apache/qpid-proton/commit/7dc59589a806bc902836d86f43105aff4c8556a3) and [d693de22cceb0466ecb904e8462ee5e04418374a](https://github.com/apache/qpid-proton/commit/d693de22cceb0466ecb904e8462ee5e04418374a) Please give it a try and let me know if it works for you. 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 > Support Go modules > -- > > Key: PROTON-2105 > URL: https://issues.apache.org/jira/browse/PROTON-2105 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Reporter: Ulf Lilleengen >Assignee: Roddie Kieley >Priority: Major > Fix For: proton-c-0.30.0 > > > As of Go 1.12, go module support is available. In order to manage > dependencies using go modules, dependencies must also be using go modules. > Therefore, adding a go.mod file to each module would allow qpid proton go > bindings to be managed as a go module. -- 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] RoddieKieley commented on issue #189: PROTON-2105 Add go module support
RoddieKieley commented on issue #189: PROTON-2105 Add go module support URL: https://github.com/apache/qpid-proton/pull/189#issuecomment-547698444 @lulf Thanks for the prodding to get this done! Go module support should now be available via [7dc59589a806bc902836d86f43105aff4c8556a3](https://github.com/apache/qpid-proton/commit/7dc59589a806bc902836d86f43105aff4c8556a3) and [d693de22cceb0466ecb904e8462ee5e04418374a](https://github.com/apache/qpid-proton/commit/d693de22cceb0466ecb904e8462ee5e04418374a) Please give it a try and let me know if it works for you. 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 With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2105) Support Go modules
[ https://issues.apache.org/jira/browse/PROTON-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16962586#comment-16962586 ] ASF GitHub Bot commented on PROTON-2105: RoddieKieley commented on pull request #189: PROTON-2105 Add go module support URL: https://github.com/apache/qpid-proton/pull/189 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 > Support Go modules > -- > > Key: PROTON-2105 > URL: https://issues.apache.org/jira/browse/PROTON-2105 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Reporter: Ulf Lilleengen >Assignee: Roddie Kieley >Priority: Major > Fix For: proton-c-0.30.0 > > > As of Go 1.12, go module support is available. In order to manage > dependencies using go modules, dependencies must also be using go modules. > Therefore, adding a go.mod file to each module would allow qpid proton go > bindings to be managed as a go module. -- 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-2107) Go module support
[ https://issues.apache.org/jira/browse/PROTON-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16962582#comment-16962582 ] Roddie Kieley commented on PROTON-2107: --- [~thitiphong.a] I've just committed work via PROTON-2105 to implement support for go modules. Please give it a try and let us know if it resolves your issue. NOTE that the module is github.com/apache/qpid-proton as per [go.mod|https://github.com/apache/qpid-proton/blob/master/go.mod] and that go 1.11 is now required. > Go module support > - > > Key: PROTON-2107 > URL: https://issues.apache.org/jira/browse/PROTON-2107 > Project: Qpid Proton > Issue Type: Improvement > Components: build >Affects Versions: proton-c-0.29.0 >Reporter: Thtiphong Anansukkasem >Assignee: Roddie Kieley >Priority: Major > > I found the error , when i run "go get" command in go module enabled project > $go get -v qpid.apache.org/electron > go: finding qpid.apache.org latest > go get qpid.apache.org/electron: module qpid.apache.org@upgrade > (v0.0.0-20190919033840-551513f49822) found, but does not contain package > qpid.apache.org/electron > $ go get -v qpid.apache.org/amqp > go: finding qpid.apache.org latest > go get qpid.apache.org/amqp: module qpid.apache.org@upgrade > (v0.0.0-20190919033840-551513f49822) found, but does not contain package > qpid.apache.org/amqp > -- 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-2105) Support Go modules
[ https://issues.apache.org/jira/browse/PROTON-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roddie Kieley resolved PROTON-2105. --- Fix Version/s: proton-c-0.30.0 Resolution: Implemented > Support Go modules > -- > > Key: PROTON-2105 > URL: https://issues.apache.org/jira/browse/PROTON-2105 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Reporter: Ulf Lilleengen >Assignee: Roddie Kieley >Priority: Major > Fix For: proton-c-0.30.0 > > > As of Go 1.12, go module support is available. In order to manage > dependencies using go modules, dependencies must also be using go modules. > Therefore, adding a go.mod file to each module would allow qpid proton go > bindings to be managed as a go module. -- 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-2105) Support Go modules
[
https://issues.apache.org/jira/browse/PROTON-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16962578#comment-16962578
]
Roddie Kieley commented on PROTON-2105:
---
As above I committed the work for the go module support. Locally all tests
pass, however I do note that in travis in the build *before* these commits,
2205, the [Xcode 10.1
variant|https://travis-ci.org/apache/qpid-proton/jobs/603007629] shows the
electron go-test TestHeartbeat failing:
{code}
26: === RUN TestHeartbeat
362126: --- FAIL: TestHeartbeat (0.49s)
362226: electron_test.go:325: connection failed to time out
{code}
The commits did not change the state with the tests still only failing for the
subsequent 2206 build job in the [Xcode 10.1
variant|https://travis-ci.org/apache/qpid-proton/jobs/604743078] for the same
reason:
{code}
26: === RUN TestHeartbeat
363926: --- FAIL: TestHeartbeat (0.41s)
364026: electron_test.go:325: connection failed to time out
{code}
As this appears unrelated to the committed work I will mark this complete.
> Support Go modules
> --
>
> Key: PROTON-2105
> URL: https://issues.apache.org/jira/browse/PROTON-2105
> Project: Qpid Proton
> Issue Type: Bug
> Components: go-binding
>Reporter: Ulf Lilleengen
>Assignee: Roddie Kieley
>Priority: Major
>
> As of Go 1.12, go module support is available. In order to manage
> dependencies using go modules, dependencies must also be using go modules.
> Therefore, adding a go.mod file to each module would allow qpid proton go
> bindings to be managed as a go module.
--
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-2105) Support Go modules
[ https://issues.apache.org/jira/browse/PROTON-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16962565#comment-16962565 ] ASF subversion and git services commented on PROTON-2105: - Commit 7dc59589a806bc902836d86f43105aff4c8556a3 in qpid-proton's branch refs/heads/master from Roddie Kieley [ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=7dc5958 ] PROTON-2105: Added support for go modules. > Support Go modules > -- > > Key: PROTON-2105 > URL: https://issues.apache.org/jira/browse/PROTON-2105 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Reporter: Ulf Lilleengen >Assignee: Roddie Kieley >Priority: Major > > As of Go 1.12, go module support is available. In order to manage > dependencies using go modules, dependencies must also be using go modules. > Therefore, adding a go.mod file to each module would allow qpid proton go > bindings to be managed as a go module. -- 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-2105) Support Go modules
[ https://issues.apache.org/jira/browse/PROTON-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16962566#comment-16962566 ] ASF subversion and git services commented on PROTON-2105: - Commit d693de22cceb0466ecb904e8462ee5e04418374a in qpid-proton's branch refs/heads/master from Roddie Kieley [ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=d693de2 ] PROTON-2105: Relaxed go require to 1.11. Disabled go build for Xcode8.3 travis ci. > Support Go modules > -- > > Key: PROTON-2105 > URL: https://issues.apache.org/jira/browse/PROTON-2105 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Reporter: Ulf Lilleengen >Assignee: Roddie Kieley >Priority: Major > > As of Go 1.12, go module support is available. In order to manage > dependencies using go modules, dependencies must also be using go modules. > Therefore, adding a go.mod file to each module would allow qpid proton go > bindings to be managed as a go module. -- 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-1427) Allow policy to define user (group) specific connection limits
[ https://issues.apache.org/jira/browse/DISPATCH-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16962465#comment-16962465 ] ASF GitHub Bot commented on DISPATCH-1427: -- ganeshmurthy commented on issue #601: DISPATCH-1427: Add user and host connection limits to vhost groups URL: https://github.com/apache/qpid-dispatch/pull/601#issuecomment-547627242 @ChugR can you please squash into one commit and commit to master. Thanks. 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 > Allow policy to define user (group) specific connection limits > -- > > Key: DISPATCH-1427 > URL: https://issues.apache.org/jira/browse/DISPATCH-1427 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Gordon Sim >Assignee: Charles E. Rolke >Priority: Major > > At present the max connections allowed is the same for all users. It would be > useful to be able to vary this as some classes of user may have different > needs to others. -- 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 commented on issue #601: DISPATCH-1427: Add user and host connection limits to vhost groups
ganeshmurthy commented on issue #601: DISPATCH-1427: Add user and host connection limits to vhost groups URL: https://github.com/apache/qpid-dispatch/pull/601#issuecomment-547627242 @ChugR can you please squash into one commit and commit to master. Thanks. 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 With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1428) route connection not indexed by 'connection' field of connector
[
https://issues.apache.org/jira/browse/DISPATCH-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16962366#comment-16962366
]
ASF GitHub Bot commented on DISPATCH-1428:
--
codecov-io commented on issue #603: DISPATCH-1428 - Minor modification to test
to make sure link routes a…
URL: https://github.com/apache/qpid-dispatch/pull/603#issuecomment-547603686
#
[Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/603?src=pr=h1)
Report
> Merging
[#603](https://codecov.io/gh/apache/qpid-dispatch/pull/603?src=pr=desc) into
[master](https://codecov.io/gh/apache/qpid-dispatch/commit/37aef86a9ac20f5925de955846dd001de117ed5a?src=pr=desc)
will **increase** coverage by `0.01%`.
> The diff coverage is `n/a`.
[](https://codecov.io/gh/apache/qpid-dispatch/pull/603?src=pr=tree)
```diff
@@Coverage Diff @@
## master #603 +/- ##
==
+ Coverage 86.42% 86.44% +0.01%
==
Files 91 91
Lines 2058220583 +1
==
+ Hits1778917792 +3
+ Misses 2793 2791 -2
```
| [Impacted
Files](https://codecov.io/gh/apache/qpid-dispatch/pull/603?src=pr=tree) |
Coverage Δ | |
|---|---|---|
|
[src/router\_core/router\_core.c](https://codecov.io/gh/apache/qpid-dispatch/pull/603/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL3JvdXRlcl9jb3JlLmM=)
| `86.52% <0%> (-0.2%)` | :arrow_down: |
|
[src/iterator.c](https://codecov.io/gh/apache/qpid-dispatch/pull/603/diff?src=pr=tree#diff-c3JjL2l0ZXJhdG9yLmM=)
| `89.17% <0%> (-0.17%)` | :arrow_down: |
|
[src/router\_node.c](https://codecov.io/gh/apache/qpid-dispatch/pull/603/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9ub2RlLmM=)
| `92.92% <0%> (-0.12%)` | :arrow_down: |
|
[src/parse.c](https://codecov.io/gh/apache/qpid-dispatch/pull/603/diff?src=pr=tree#diff-c3JjL3BhcnNlLmM=)
| `87.86% <0%> (+0.22%)` | :arrow_up: |
|
[src/router\_core/connections.c](https://codecov.io/gh/apache/qpid-dispatch/pull/603/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2Nvbm5lY3Rpb25zLmM=)
| `94.31% <0%> (+0.22%)` | :arrow_up: |
|
[src/router\_core/route\_tables.c](https://codecov.io/gh/apache/qpid-dispatch/pull/603/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL3JvdXRlX3RhYmxlcy5j)
| `76.17% <0%> (+0.49%)` | :arrow_up: |
--
[Continue to review full report at
Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/603?src=pr=continue).
> **Legend** - [Click here to learn
more](https://docs.codecov.io/docs/codecov-delta)
> `Δ = absolute (impact)`, `ø = not affected`, `? = missing data`
> Powered by
[Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/603?src=pr=footer).
Last update
[37aef86...a732789](https://codecov.io/gh/apache/qpid-dispatch/pull/603?src=pr=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
> route connection not indexed by 'connection' field of connector
> ---
>
> Key: DISPATCH-1428
> URL: https://issues.apache.org/jira/browse/DISPATCH-1428
> Project: Qpid Dispatch
> Issue Type: Bug
>Reporter: Gordon Sim
>Assignee: Gordon Sim
>Priority: Major
>
> The connection established by a route-container connector will not be indexed
> by the 'connection' field of that connector if there is already an existing
> route-connection with the same container id but established by a different
> connector.
> E.g. start router on 5672 and a broker (or a separate router emulating a
> broker) on 5673, then:
> {noformat}
> for n in foo bar; do
> qdmanage CREATE --type connector --name $n role=route-container
> host=localhost port=5673;
> qdmanage CREATE --type linkRoute --name $n pattern=$n direction=in
> connection=$n;
> done;
> qdstat --linkroute
> {noformat}
> Only one of these link routes is active though both connections are
> established.
> The issues is that when the first connection is established, it indexes the
> qdr_conn_identifier_t by container-id and the connection label from the
> connector. When the second connection is established, it looks up first by
> container id, so adds itself to the qdr_conn_identifier_t
[GitHub] [qpid-dispatch] codecov-io commented on issue #603: DISPATCH-1428 - Minor modification to test to make sure link routes a…
codecov-io commented on issue #603: DISPATCH-1428 - Minor modification to test to make sure link routes a… URL: https://github.com/apache/qpid-dispatch/pull/603#issuecomment-547603686 # [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/603?src=pr=h1) Report > Merging [#603](https://codecov.io/gh/apache/qpid-dispatch/pull/603?src=pr=desc) into [master](https://codecov.io/gh/apache/qpid-dispatch/commit/37aef86a9ac20f5925de955846dd001de117ed5a?src=pr=desc) will **increase** coverage by `0.01%`. > The diff coverage is `n/a`. [](https://codecov.io/gh/apache/qpid-dispatch/pull/603?src=pr=tree) ```diff @@Coverage Diff @@ ## master #603 +/- ## == + Coverage 86.42% 86.44% +0.01% == Files 91 91 Lines 2058220583 +1 == + Hits1778917792 +3 + Misses 2793 2791 -2 ``` | [Impacted Files](https://codecov.io/gh/apache/qpid-dispatch/pull/603?src=pr=tree) | Coverage Δ | | |---|---|---| | [src/router\_core/router\_core.c](https://codecov.io/gh/apache/qpid-dispatch/pull/603/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL3JvdXRlcl9jb3JlLmM=) | `86.52% <0%> (-0.2%)` | :arrow_down: | | [src/iterator.c](https://codecov.io/gh/apache/qpid-dispatch/pull/603/diff?src=pr=tree#diff-c3JjL2l0ZXJhdG9yLmM=) | `89.17% <0%> (-0.17%)` | :arrow_down: | | [src/router\_node.c](https://codecov.io/gh/apache/qpid-dispatch/pull/603/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9ub2RlLmM=) | `92.92% <0%> (-0.12%)` | :arrow_down: | | [src/parse.c](https://codecov.io/gh/apache/qpid-dispatch/pull/603/diff?src=pr=tree#diff-c3JjL3BhcnNlLmM=) | `87.86% <0%> (+0.22%)` | :arrow_up: | | [src/router\_core/connections.c](https://codecov.io/gh/apache/qpid-dispatch/pull/603/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2Nvbm5lY3Rpb25zLmM=) | `94.31% <0%> (+0.22%)` | :arrow_up: | | [src/router\_core/route\_tables.c](https://codecov.io/gh/apache/qpid-dispatch/pull/603/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL3JvdXRlX3RhYmxlcy5j) | `76.17% <0%> (+0.49%)` | :arrow_up: | -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/603?src=pr=continue). > **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta) > `Δ = absolute (impact)`, `ø = not affected`, `? = missing data` > Powered by [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/603?src=pr=footer). Last update [37aef86...a732789](https://codecov.io/gh/apache/qpid-dispatch/pull/603?src=pr=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 With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1428) route connection not indexed by 'connection' field of connector
[
https://issues.apache.org/jira/browse/DISPATCH-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16962348#comment-16962348
]
ASF GitHub Bot commented on DISPATCH-1428:
--
ganeshmurthy commented on pull request #603: DISPATCH-1428 - Minor modification
to test to make sure link routes a…
URL: https://github.com/apache/qpid-dispatch/pull/603
…re all activated before the test begins
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
> route connection not indexed by 'connection' field of connector
> ---
>
> Key: DISPATCH-1428
> URL: https://issues.apache.org/jira/browse/DISPATCH-1428
> Project: Qpid Dispatch
> Issue Type: Bug
>Reporter: Gordon Sim
>Assignee: Gordon Sim
>Priority: Major
>
> The connection established by a route-container connector will not be indexed
> by the 'connection' field of that connector if there is already an existing
> route-connection with the same container id but established by a different
> connector.
> E.g. start router on 5672 and a broker (or a separate router emulating a
> broker) on 5673, then:
> {noformat}
> for n in foo bar; do
> qdmanage CREATE --type connector --name $n role=route-container
> host=localhost port=5673;
> qdmanage CREATE --type linkRoute --name $n pattern=$n direction=in
> connection=$n;
> done;
> qdstat --linkroute
> {noformat}
> Only one of these link routes is active though both connections are
> established.
> The issues is that when the first connection is established, it indexes the
> qdr_conn_identifier_t by container-id and the connection label from the
> connector. When the second connection is established, it looks up first by
> container id, so adds itself to the qdr_conn_identifier_t created by the
> first connection. There is then no entry in the index for the connection
> label of the second connector, so the second link route can never be
> activated.
--
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-1428) route connection not indexed by 'connection' field of connector
[
https://issues.apache.org/jira/browse/DISPATCH-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16962351#comment-16962351
]
ASF GitHub Bot commented on DISPATCH-1428:
--
ganeshmurthy commented on issue #603: DISPATCH-1428 - Minor modification to
test to make sure link routes a…
URL: https://github.com/apache/qpid-dispatch/pull/603#issuecomment-547595834
Sometimes this test fails with the error
`14: ==
14: FAIL: test_both_link_routes_active
(system_tests_link_routes.Dispatch1428)
14: --
14: Traceback (most recent call last):
14: File "/foo/qpid-dispatch/tests/system_tests_link_routes.py", line
2126, in test_both_link_routes_active
14: self.assertEqual(None, first.error)
14: AssertionError: None != u'Timeout Expired - Check for cores'
14:
14: --
14: Ran 34 tests in 91.313s`
This test will fix the above problem.
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
> route connection not indexed by 'connection' field of connector
> ---
>
> Key: DISPATCH-1428
> URL: https://issues.apache.org/jira/browse/DISPATCH-1428
> Project: Qpid Dispatch
> Issue Type: Bug
>Reporter: Gordon Sim
>Assignee: Gordon Sim
>Priority: Major
>
> The connection established by a route-container connector will not be indexed
> by the 'connection' field of that connector if there is already an existing
> route-connection with the same container id but established by a different
> connector.
> E.g. start router on 5672 and a broker (or a separate router emulating a
> broker) on 5673, then:
> {noformat}
> for n in foo bar; do
> qdmanage CREATE --type connector --name $n role=route-container
> host=localhost port=5673;
> qdmanage CREATE --type linkRoute --name $n pattern=$n direction=in
> connection=$n;
> done;
> qdstat --linkroute
> {noformat}
> Only one of these link routes is active though both connections are
> established.
> The issues is that when the first connection is established, it indexes the
> qdr_conn_identifier_t by container-id and the connection label from the
> connector. When the second connection is established, it looks up first by
> container id, so adds itself to the qdr_conn_identifier_t created by the
> first connection. There is then no entry in the index for the connection
> label of the second connector, so the second link route can never be
> activated.
--
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-1428) route connection not indexed by 'connection' field of connector
[
https://issues.apache.org/jira/browse/DISPATCH-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16962350#comment-16962350
]
ASF GitHub Bot commented on DISPATCH-1428:
--
ganeshmurthy commented on issue #603: DISPATCH-1428 - Minor modification to
test to make sure link routes a…
URL: https://github.com/apache/qpid-dispatch/pull/603#issuecomment-547595834
Sometimes this test fails with the error
`14: ==
14: FAIL: test_both_link_routes_active
(system_tests_link_routes.Dispatch1428)
14: --
14: Traceback (most recent call last):
14: File "/foo/qpid-dispatch/tests/system_tests_link_routes.py", line
2126, in test_both_link_routes_active
14: self.assertEqual(None, first.error)
14: AssertionError: None != u'Timeout Expired - Check for cores'
14:
14: --
14: Ran 34 tests in 91.313s`
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
> route connection not indexed by 'connection' field of connector
> ---
>
> Key: DISPATCH-1428
> URL: https://issues.apache.org/jira/browse/DISPATCH-1428
> Project: Qpid Dispatch
> Issue Type: Bug
>Reporter: Gordon Sim
>Assignee: Gordon Sim
>Priority: Major
>
> The connection established by a route-container connector will not be indexed
> by the 'connection' field of that connector if there is already an existing
> route-connection with the same container id but established by a different
> connector.
> E.g. start router on 5672 and a broker (or a separate router emulating a
> broker) on 5673, then:
> {noformat}
> for n in foo bar; do
> qdmanage CREATE --type connector --name $n role=route-container
> host=localhost port=5673;
> qdmanage CREATE --type linkRoute --name $n pattern=$n direction=in
> connection=$n;
> done;
> qdstat --linkroute
> {noformat}
> Only one of these link routes is active though both connections are
> established.
> The issues is that when the first connection is established, it indexes the
> qdr_conn_identifier_t by container-id and the connection label from the
> connector. When the second connection is established, it looks up first by
> container id, so adds itself to the qdr_conn_identifier_t created by the
> first connection. There is then no entry in the index for the connection
> label of the second connector, so the second link route can never be
> activated.
--
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 commented on issue #603: DISPATCH-1428 - Minor modification to test to make sure link routes a…
ganeshmurthy commented on issue #603: DISPATCH-1428 - Minor modification to test to make sure link routes a… URL: https://github.com/apache/qpid-dispatch/pull/603#issuecomment-547595834 Sometimes this test fails with the error `14: == 14: FAIL: test_both_link_routes_active (system_tests_link_routes.Dispatch1428) 14: -- 14: Traceback (most recent call last): 14: File "/foo/qpid-dispatch/tests/system_tests_link_routes.py", line 2126, in test_both_link_routes_active 14: self.assertEqual(None, first.error) 14: AssertionError: None != u'Timeout Expired - Check for cores' 14: 14: -- 14: Ran 34 tests in 91.313s` 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 With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] ganeshmurthy edited a comment on issue #603: DISPATCH-1428 - Minor modification to test to make sure link routes a…
ganeshmurthy edited a comment on issue #603: DISPATCH-1428 - Minor modification to test to make sure link routes a… URL: https://github.com/apache/qpid-dispatch/pull/603#issuecomment-547595834 Sometimes this test fails with the error `14: == 14: FAIL: test_both_link_routes_active (system_tests_link_routes.Dispatch1428) 14: -- 14: Traceback (most recent call last): 14: File "/foo/qpid-dispatch/tests/system_tests_link_routes.py", line 2126, in test_both_link_routes_active 14: self.assertEqual(None, first.error) 14: AssertionError: None != u'Timeout Expired - Check for cores' 14: 14: -- 14: Ran 34 tests in 91.313s` This test will fix the above problem. 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 With regards, Apache Git Services - 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 #603: DISPATCH-1428 - Minor modification to test to make sure link routes a…
ganeshmurthy opened a new pull request #603: DISPATCH-1428 - Minor modification to test to make sure link routes a… URL: https://github.com/apache/qpid-dispatch/pull/603 …re all activated before the test begins 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 With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-441) Using QPID JMS behind a proxy
[ https://issues.apache.org/jira/browse/QPIDJMS-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16962304#comment-16962304 ] ASF GitHub Bot commented on QPIDJMS-441: gemmellr commented on issue #32: QPIDJMS-441: add proxy support URL: https://github.com/apache/qpid-jms/pull/32#issuecomment-547565314 Tim and I took a look at this latest version and made some fixes and tweaks, you can see the current state of them in the second commit at: https://github.com/apache/qpid-jms/compare/master...gemmellr:pr32-proxy-b There is still a remaining issue needing resolved before the addition can be made however. The failover test (\[1\]) failed very occasionally for me when run locally, and fails a lot of the time when run in the Appveyor CI job on Windows. After some digging we eventually established this seems to happen when the proxy doesnt look to close the connection from the client, after the test peer drops the server end. The client thus doesn't notice the drop as intended in the test, which eventually times out waiting for the failover and subsequent test steps to happen. This seems to happen only when the proxy code goes through this segment: https://github.com/apache/qpid-jms/commit/436092b2eba9a4b46a7b5ed404e60e3803d0f141#diff-a85fa6452826ab6e749d0c34973365f1R310 of the read processing. However, just adding a matching close for the writeChannel there makes the test (and others) fail differently, doing the expected steps but throwing during autoclosure of the test peer because its final read attempt had thrown a connection reset exception. Its not immediately clear to me why that happens, but the test issues need resolved one way or another before this can be merged so it would be good if you could debug it to resolve it. If you identify a fix, just add a new commit on top of those ones so we can easily see the new changes. You can enable Appveyor (https://ci.appveyor.com) on your fork of the repo and it will pick up the existing configuration in there and run when you push changes, plus you can repeat builds through the Appveyor site. The Repeat annotation (\[2\]) above the test can be be useful for running lots of iterations of a test in a single test run while verifying changes. (\[1\]) https://github.com/apache/qpid-jms/commit/436092b2eba9a4b46a7b5ed404e60e3803d0f141#diff-eab37a02742dcdeacb54fd8fde6e5a6bR133 (\[2\]) https://github.com/apache/qpid-jms/commit/436092b2eba9a4b46a7b5ed404e60e3803d0f141#diff-eab37a02742dcdeacb54fd8fde6e5a6bR131 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 > Using QPID JMS behind a proxy > - > > Key: QPIDJMS-441 > URL: https://issues.apache.org/jira/browse/QPIDJMS-441 > Project: Qpid JMS > Issue Type: Wish > Components: qpid-jms-client >Affects Versions: 0.40.0 >Reporter: morten >Priority: Blocker > > I actually did not find a possibility to use the jms qpid client behind a > proxy. I guess there will be a lot of people who needs to run the library > behind a proxy. It would be nice to have the possibility to set a proxy > somehow. -- 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-jms] gemmellr commented on issue #32: QPIDJMS-441: add proxy support
gemmellr commented on issue #32: QPIDJMS-441: add proxy support URL: https://github.com/apache/qpid-jms/pull/32#issuecomment-547565314 Tim and I took a look at this latest version and made some fixes and tweaks, you can see the current state of them in the second commit at: https://github.com/apache/qpid-jms/compare/master...gemmellr:pr32-proxy-b There is still a remaining issue needing resolved before the addition can be made however. The failover test (\[1\]) failed very occasionally for me when run locally, and fails a lot of the time when run in the Appveyor CI job on Windows. After some digging we eventually established this seems to happen when the proxy doesnt look to close the connection from the client, after the test peer drops the server end. The client thus doesn't notice the drop as intended in the test, which eventually times out waiting for the failover and subsequent test steps to happen. This seems to happen only when the proxy code goes through this segment: https://github.com/apache/qpid-jms/commit/436092b2eba9a4b46a7b5ed404e60e3803d0f141#diff-a85fa6452826ab6e749d0c34973365f1R310 of the read processing. However, just adding a matching close for the writeChannel there makes the test (and others) fail differently, doing the expected steps but throwing during autoclosure of the test peer because its final read attempt had thrown a connection reset exception. Its not immediately clear to me why that happens, but the test issues need resolved one way or another before this can be merged so it would be good if you could debug it to resolve it. If you identify a fix, just add a new commit on top of those ones so we can easily see the new changes. You can enable Appveyor (https://ci.appveyor.com) on your fork of the repo and it will pick up the existing configuration in there and run when you push changes, plus you can repeat builds through the Appveyor site. The Repeat annotation (\[2\]) above the test can be be useful for running lots of iterations of a test in a single test run while verifying changes. (\[1\]) https://github.com/apache/qpid-jms/commit/436092b2eba9a4b46a7b5ed404e60e3803d0f141#diff-eab37a02742dcdeacb54fd8fde6e5a6bR133 (\[2\]) https://github.com/apache/qpid-jms/commit/436092b2eba9a4b46a7b5ed404e60e3803d0f141#diff-eab37a02742dcdeacb54fd8fde6e5a6bR131 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 With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2030) Use CLOCK_MONOTONIC in proactors for pn_transport_tick
[
https://issues.apache.org/jira/browse/PROTON-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16962233#comment-16962233
]
ASF GitHub Bot commented on PROTON-2030:
astitcher commented on pull request #180: PROTON-2030 Use CLOCK_MONOTONIC in
proactors for pn_transport_tick
URL: https://github.com/apache/qpid-proton/pull/180#discussion_r340204445
##
File path: c/src/proactor/epoll.c
##
@@ -1426,10 +1419,10 @@ static void pconnection_tick(pconnection_t *pc) {
pn_transport_t *t = pc->driver.transport;
if (pn_transport_get_idle_timeout(t) ||
pn_transport_get_remote_idle_timeout(t)) {
ptimer_set(>timer, 0);
-uint64_t now = pn_i_now2();
-uint64_t next = pn_transport_tick(t, now);
+int64_t now = pn_proactor_now_64();
+int64_t next = pn_transport_tick(t, now);
if (next) {
- ptimer_set(>timer, next - now);
+ ptimer_set(>timer, (uint64_t) next - now);
}
Review comment:
As it is important that the subtraction is done using unsigned arithmetic
(to get 'wrap-around' differences correct). So I'd suggest keeping `uint64_t
now` & `uint64_t next`. Casting the assignments and leaving the subtraction.
It's easier to see this is correct - I can personally never remember which
order the conversions are done so even if the arithmetic is correct it takes me
a little while to be sure!
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
> Use CLOCK_MONOTONIC in proactors for pn_transport_tick
> --
>
> Key: PROTON-2030
> URL: https://issues.apache.org/jira/browse/PROTON-2030
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-c
>Affects Versions: proton-c-0.27.0
>Reporter: Jiri Daněk
>Priority: Major
>
> IOCP and epoll proactors are feeding wall clock time to pn_transport_tick. I
> tested (with epoll) that changing system clock breaks heartbeating.
> The libuv proactor does use monotonic already.
--
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-2030) Use CLOCK_MONOTONIC in proactors for pn_transport_tick
[
https://issues.apache.org/jira/browse/PROTON-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16962234#comment-16962234
]
ASF GitHub Bot commented on PROTON-2030:
astitcher commented on pull request #180: PROTON-2030 Use CLOCK_MONOTONIC in
proactors for pn_transport_tick
URL: https://github.com/apache/qpid-proton/pull/180#discussion_r340205929
##
File path: c/src/proactor/win_iocp.c
##
@@ -2145,8 +2132,8 @@ static void pconnection_tick(pconnection_t *pc) {
if(!stop_timer(pc->context.proactor->timer_queue, >tick_timer)) {
// TODO: handle error
}
-uint64_t now = pn_i_now2();
-uint64_t next = pn_transport_tick(t, now);
+int64_t now = pn_proactor_now_64();
+int64_t next = pn_transport_tick(t, now);
if (next) {
if (!start_timer(pc->context.proactor->timer_queue, >tick_timer,
tick_timer_cb, pc, next - now)) {
Review comment:
Comment as above in the epoll case - but note that here there may actually
be a bug as the subtraction is done using signed int64_t arithmetic which
doesn't have defined wraparound semantics.
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
> Use CLOCK_MONOTONIC in proactors for pn_transport_tick
> --
>
> Key: PROTON-2030
> URL: https://issues.apache.org/jira/browse/PROTON-2030
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-c
>Affects Versions: proton-c-0.27.0
>Reporter: Jiri Daněk
>Priority: Major
>
> IOCP and epoll proactors are feeding wall clock time to pn_transport_tick. I
> tested (with epoll) that changing system clock breaks heartbeating.
> The libuv proactor does use monotonic already.
--
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] astitcher commented on a change in pull request #180: PROTON-2030 Use CLOCK_MONOTONIC in proactors for pn_transport_tick
astitcher commented on a change in pull request #180: PROTON-2030 Use
CLOCK_MONOTONIC in proactors for pn_transport_tick
URL: https://github.com/apache/qpid-proton/pull/180#discussion_r340204445
##
File path: c/src/proactor/epoll.c
##
@@ -1426,10 +1419,10 @@ static void pconnection_tick(pconnection_t *pc) {
pn_transport_t *t = pc->driver.transport;
if (pn_transport_get_idle_timeout(t) ||
pn_transport_get_remote_idle_timeout(t)) {
ptimer_set(>timer, 0);
-uint64_t now = pn_i_now2();
-uint64_t next = pn_transport_tick(t, now);
+int64_t now = pn_proactor_now_64();
+int64_t next = pn_transport_tick(t, now);
if (next) {
- ptimer_set(>timer, next - now);
+ ptimer_set(>timer, (uint64_t) next - now);
}
Review comment:
As it is important that the subtraction is done using unsigned arithmetic
(to get 'wrap-around' differences correct). So I'd suggest keeping `uint64_t
now` & `uint64_t next`. Casting the assignments and leaving the subtraction.
It's easier to see this is correct - I can personally never remember which
order the conversions are done so even if the arithmetic is correct it takes me
a little while to be sure!
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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] astitcher commented on a change in pull request #180: PROTON-2030 Use CLOCK_MONOTONIC in proactors for pn_transport_tick
astitcher commented on a change in pull request #180: PROTON-2030 Use
CLOCK_MONOTONIC in proactors for pn_transport_tick
URL: https://github.com/apache/qpid-proton/pull/180#discussion_r340205929
##
File path: c/src/proactor/win_iocp.c
##
@@ -2145,8 +2132,8 @@ static void pconnection_tick(pconnection_t *pc) {
if(!stop_timer(pc->context.proactor->timer_queue, >tick_timer)) {
// TODO: handle error
}
-uint64_t now = pn_i_now2();
-uint64_t next = pn_transport_tick(t, now);
+int64_t now = pn_proactor_now_64();
+int64_t next = pn_transport_tick(t, now);
if (next) {
if (!start_timer(pc->context.proactor->timer_queue, >tick_timer,
tick_timer_cb, pc, next - now)) {
Review comment:
Comment as above in the epoll case - but note that here there may actually
be a bug as the subtraction is done using signed int64_t arithmetic which
doesn't have defined wraparound semantics.
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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1453) Adding "defaultDistribution: unavailable" overrides the regular handling of transaction coordinator link refusal
[
https://issues.apache.org/jira/browse/DISPATCH-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-1453.
-
Fix Version/s: 1.10.0
Resolution: Fixed
> Adding "defaultDistribution: unavailable" overrides the regular handling of
> transaction coordinator link refusal
>
>
> Key: DISPATCH-1453
> URL: https://issues.apache.org/jira/browse/DISPATCH-1453
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.9.0
>Reporter: Robbie Gemmell
>Assignee: Ganesh Murthy
>Priority: Minor
> Fix For: 1.10.0
>
>
> DISPATCH-802 added handling to refuse links to the transaction coordinator
> (which has no address, but is a specific target) if a link route to e.g a
> broker isnt configured (using DISPATCH-195), and help clarify the reasons for
> the refusal.
> DISPATCH-803 was added to provide a way for links to adressses that are
> otherwise unknown to be refused rather than message routed, by setting
> "defaultDistribution: unavailable". This functionality overrides the
> behaviour from DISPATCH-802, making it less clear again why a transaction
> usage attempt has failed.
> From a JMS client trying to create a transacted session, the failure with
> "defaultDistribution: unavailable" config present looks like:
> {noformat}
> javax.jms.JMSException: No route to the destination node [condition =
> qd:no-route-to-dest]
> at
> org.apache.qpid.jms.provider.ProviderException.toJMSException(ProviderException.java:34)
> at
> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:80)
> at
> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:112)
> at org.apache.qpid.jms.JmsConnection.createResource(JmsConnection.java:698)
> at
> org.apache.qpid.jms.JmsLocalTransactionContext.begin(JmsLocalTransactionContext.java:140)
> at org.apache.qpid.jms.JmsSession.(JmsSession.java:172)
> at org.apache.qpid.jms.JmsConnection.createSession(JmsConnection.java:316)
> at org.apache.qpid.jms.example.HelloWorld.main(HelloWorld.java:52)
> {noformat}
> While without it,the router sends a more specific error condition, and so the
> failure normally looks like:
> {noformat}
> javax.jms.JMSException: The router can't coordinate transactions by itself, a
> linkRoute to a coordinator must be configured to use transactions. [condition
> = amqp:precondition-failed]
> at
> org.apache.qpid.jms.provider.ProviderException.toJMSException(ProviderException.java:34)
> at
> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:80)
> at
> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:112)
> at org.apache.qpid.jms.JmsConnection.createResource(JmsConnection.java:698)
> at
> org.apache.qpid.jms.JmsLocalTransactionContext.begin(JmsLocalTransactionContext.java:140)
> at org.apache.qpid.jms.JmsSession.(JmsSession.java:172)
> at org.apache.qpid.jms.JmsConnection.createSession(JmsConnection.java:316)
> at org.apache.qpid.jms.example.HelloWorld.main(HelloWorld.java:52)
> {noformat}
> It would be nicer if the regular coordinator refusal error condition was sent
> in both cases.
--
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-1453) Adding "defaultDistribution: unavailable" overrides the regular handling of transaction coordinator link refusal
[
https://issues.apache.org/jira/browse/DISPATCH-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16962212#comment-16962212
]
ASF GitHub Bot commented on DISPATCH-1453:
--
asfgit commented on pull request #602: DISPATCH-1453 - Fix the code so the
correct error message shows up wh…
URL: https://github.com/apache/qpid-dispatch/pull/602
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
> Adding "defaultDistribution: unavailable" overrides the regular handling of
> transaction coordinator link refusal
>
>
> Key: DISPATCH-1453
> URL: https://issues.apache.org/jira/browse/DISPATCH-1453
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.9.0
>Reporter: Robbie Gemmell
>Assignee: Ganesh Murthy
>Priority: Minor
>
> DISPATCH-802 added handling to refuse links to the transaction coordinator
> (which has no address, but is a specific target) if a link route to e.g a
> broker isnt configured (using DISPATCH-195), and help clarify the reasons for
> the refusal.
> DISPATCH-803 was added to provide a way for links to adressses that are
> otherwise unknown to be refused rather than message routed, by setting
> "defaultDistribution: unavailable". This functionality overrides the
> behaviour from DISPATCH-802, making it less clear again why a transaction
> usage attempt has failed.
> From a JMS client trying to create a transacted session, the failure with
> "defaultDistribution: unavailable" config present looks like:
> {noformat}
> javax.jms.JMSException: No route to the destination node [condition =
> qd:no-route-to-dest]
> at
> org.apache.qpid.jms.provider.ProviderException.toJMSException(ProviderException.java:34)
> at
> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:80)
> at
> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:112)
> at org.apache.qpid.jms.JmsConnection.createResource(JmsConnection.java:698)
> at
> org.apache.qpid.jms.JmsLocalTransactionContext.begin(JmsLocalTransactionContext.java:140)
> at org.apache.qpid.jms.JmsSession.(JmsSession.java:172)
> at org.apache.qpid.jms.JmsConnection.createSession(JmsConnection.java:316)
> at org.apache.qpid.jms.example.HelloWorld.main(HelloWorld.java:52)
> {noformat}
> While without it,the router sends a more specific error condition, and so the
> failure normally looks like:
> {noformat}
> javax.jms.JMSException: The router can't coordinate transactions by itself, a
> linkRoute to a coordinator must be configured to use transactions. [condition
> = amqp:precondition-failed]
> at
> org.apache.qpid.jms.provider.ProviderException.toJMSException(ProviderException.java:34)
> at
> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:80)
> at
> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:112)
> at org.apache.qpid.jms.JmsConnection.createResource(JmsConnection.java:698)
> at
> org.apache.qpid.jms.JmsLocalTransactionContext.begin(JmsLocalTransactionContext.java:140)
> at org.apache.qpid.jms.JmsSession.(JmsSession.java:172)
> at org.apache.qpid.jms.JmsConnection.createSession(JmsConnection.java:316)
> at org.apache.qpid.jms.example.HelloWorld.main(HelloWorld.java:52)
> {noformat}
> It would be nicer if the regular coordinator refusal error condition was sent
> in both cases.
--
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-1453) Adding "defaultDistribution: unavailable" overrides the regular handling of transaction coordinator link refusal
[
https://issues.apache.org/jira/browse/DISPATCH-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16962211#comment-16962211
]
ASF subversion and git services commented on DISPATCH-1453:
---
Commit 37aef86a9ac20f5925de955846dd001de117ed5a in qpid-dispatch's branch
refs/heads/master from Ganesh Murthy
[ https://gitbox.apache.org/repos/asf?p=qpid-dispatch.git;h=37aef86 ]
DISPATCH-1453 - Fix the code so that a correct error message shows up when a tx
sender attaches in the absence of a coordinated link route. This closes #602.
> Adding "defaultDistribution: unavailable" overrides the regular handling of
> transaction coordinator link refusal
>
>
> Key: DISPATCH-1453
> URL: https://issues.apache.org/jira/browse/DISPATCH-1453
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.9.0
>Reporter: Robbie Gemmell
>Assignee: Ganesh Murthy
>Priority: Minor
>
> DISPATCH-802 added handling to refuse links to the transaction coordinator
> (which has no address, but is a specific target) if a link route to e.g a
> broker isnt configured (using DISPATCH-195), and help clarify the reasons for
> the refusal.
> DISPATCH-803 was added to provide a way for links to adressses that are
> otherwise unknown to be refused rather than message routed, by setting
> "defaultDistribution: unavailable". This functionality overrides the
> behaviour from DISPATCH-802, making it less clear again why a transaction
> usage attempt has failed.
> From a JMS client trying to create a transacted session, the failure with
> "defaultDistribution: unavailable" config present looks like:
> {noformat}
> javax.jms.JMSException: No route to the destination node [condition =
> qd:no-route-to-dest]
> at
> org.apache.qpid.jms.provider.ProviderException.toJMSException(ProviderException.java:34)
> at
> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:80)
> at
> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:112)
> at org.apache.qpid.jms.JmsConnection.createResource(JmsConnection.java:698)
> at
> org.apache.qpid.jms.JmsLocalTransactionContext.begin(JmsLocalTransactionContext.java:140)
> at org.apache.qpid.jms.JmsSession.(JmsSession.java:172)
> at org.apache.qpid.jms.JmsConnection.createSession(JmsConnection.java:316)
> at org.apache.qpid.jms.example.HelloWorld.main(HelloWorld.java:52)
> {noformat}
> While without it,the router sends a more specific error condition, and so the
> failure normally looks like:
> {noformat}
> javax.jms.JMSException: The router can't coordinate transactions by itself, a
> linkRoute to a coordinator must be configured to use transactions. [condition
> = amqp:precondition-failed]
> at
> org.apache.qpid.jms.provider.ProviderException.toJMSException(ProviderException.java:34)
> at
> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:80)
> at
> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:112)
> at org.apache.qpid.jms.JmsConnection.createResource(JmsConnection.java:698)
> at
> org.apache.qpid.jms.JmsLocalTransactionContext.begin(JmsLocalTransactionContext.java:140)
> at org.apache.qpid.jms.JmsSession.(JmsSession.java:172)
> at org.apache.qpid.jms.JmsConnection.createSession(JmsConnection.java:316)
> at org.apache.qpid.jms.example.HelloWorld.main(HelloWorld.java:52)
> {noformat}
> It would be nicer if the regular coordinator refusal error condition was sent
> in both cases.
--
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] asfgit closed pull request #602: DISPATCH-1453 - Fix the code so the correct error message shows up wh…
asfgit closed pull request #602: DISPATCH-1453 - Fix the code so the correct error message shows up wh… URL: https://github.com/apache/qpid-dispatch/pull/602 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 With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1453) Adding "defaultDistribution: unavailable" overrides the regular handling of transaction coordinator link refusal
[
https://issues.apache.org/jira/browse/DISPATCH-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16962207#comment-16962207
]
ASF GitHub Bot commented on DISPATCH-1453:
--
ganeshmurthy commented on issue #602: DISPATCH-1453 - Fix the code so the
correct error message shows up wh…
URL: https://github.com/apache/qpid-dispatch/pull/602#issuecomment-547515268
> The non-test code didnt seem to change since my previous comment, so I
dont think theres anything needing me to try it out again is there? That being
the case, still fine with me.
That is indeed the case. No need to try it out again. I will squash and
merge this PR to master.
Thanks @gemmellr and @kgiusti
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
> Adding "defaultDistribution: unavailable" overrides the regular handling of
> transaction coordinator link refusal
>
>
> Key: DISPATCH-1453
> URL: https://issues.apache.org/jira/browse/DISPATCH-1453
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.9.0
>Reporter: Robbie Gemmell
>Assignee: Ganesh Murthy
>Priority: Minor
>
> DISPATCH-802 added handling to refuse links to the transaction coordinator
> (which has no address, but is a specific target) if a link route to e.g a
> broker isnt configured (using DISPATCH-195), and help clarify the reasons for
> the refusal.
> DISPATCH-803 was added to provide a way for links to adressses that are
> otherwise unknown to be refused rather than message routed, by setting
> "defaultDistribution: unavailable". This functionality overrides the
> behaviour from DISPATCH-802, making it less clear again why a transaction
> usage attempt has failed.
> From a JMS client trying to create a transacted session, the failure with
> "defaultDistribution: unavailable" config present looks like:
> {noformat}
> javax.jms.JMSException: No route to the destination node [condition =
> qd:no-route-to-dest]
> at
> org.apache.qpid.jms.provider.ProviderException.toJMSException(ProviderException.java:34)
> at
> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:80)
> at
> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:112)
> at org.apache.qpid.jms.JmsConnection.createResource(JmsConnection.java:698)
> at
> org.apache.qpid.jms.JmsLocalTransactionContext.begin(JmsLocalTransactionContext.java:140)
> at org.apache.qpid.jms.JmsSession.(JmsSession.java:172)
> at org.apache.qpid.jms.JmsConnection.createSession(JmsConnection.java:316)
> at org.apache.qpid.jms.example.HelloWorld.main(HelloWorld.java:52)
> {noformat}
> While without it,the router sends a more specific error condition, and so the
> failure normally looks like:
> {noformat}
> javax.jms.JMSException: The router can't coordinate transactions by itself, a
> linkRoute to a coordinator must be configured to use transactions. [condition
> = amqp:precondition-failed]
> at
> org.apache.qpid.jms.provider.ProviderException.toJMSException(ProviderException.java:34)
> at
> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:80)
> at
> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:112)
> at org.apache.qpid.jms.JmsConnection.createResource(JmsConnection.java:698)
> at
> org.apache.qpid.jms.JmsLocalTransactionContext.begin(JmsLocalTransactionContext.java:140)
> at org.apache.qpid.jms.JmsSession.(JmsSession.java:172)
> at org.apache.qpid.jms.JmsConnection.createSession(JmsConnection.java:316)
> at org.apache.qpid.jms.example.HelloWorld.main(HelloWorld.java:52)
> {noformat}
> It would be nicer if the regular coordinator refusal error condition was sent
> in both cases.
--
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 commented on issue #602: DISPATCH-1453 - Fix the code so the correct error message shows up wh…
ganeshmurthy commented on issue #602: DISPATCH-1453 - Fix the code so the correct error message shows up wh… URL: https://github.com/apache/qpid-dispatch/pull/602#issuecomment-547515268 > The non-test code didnt seem to change since my previous comment, so I dont think theres anything needing me to try it out again is there? That being the case, still fine with me. That is indeed the case. No need to try it out again. I will squash and merge this PR to master. Thanks @gemmellr and @kgiusti 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 With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1463) Detect deliveries that are stuck in the router for a long time
[
https://issues.apache.org/jira/browse/DISPATCH-1463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16962164#comment-16962164
]
ASF GitHub Bot commented on DISPATCH-1463:
--
ChugR commented on pull request #600: DISPATCH-1463 - Add detection for stuck
deliveries
URL: https://github.com/apache/qpid-dispatch/pull/600#discussion_r340178092
##
File path: python/qpid_dispatch/management/qdrouter.json
##
@@ -570,6 +570,11 @@
"graph": true,
"description": "The total number of settled deliveries
that were held in the router for more than 10 seconds."
},
+"deliveriesStuck": {
+"type": "integer",
+"graph": true,
+"description": "The current number of deliveries that are
unsettled and have been held in the router for more than 10 seconds."
+},
Review comment:
Live stats is fine. Adding more becomes a slippery slope towards too much.
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
> Detect deliveries that are stuck in the router for a long time
> --
>
> Key: DISPATCH-1463
> URL: https://issues.apache.org/jira/browse/DISPATCH-1463
> Project: Qpid Dispatch
> Issue Type: New Feature
> Components: Router Node
>Reporter: Ted Ross
>Assignee: Ted Ross
>Priority: Major
> Fix For: 1.10.0
>
>
> The delayed-delivery counts are limited in that they only count deliveries
> that have been settled. These counters do not count deliveries that are
> currently "stuck" and have not been settled.
> This feature provides visibility into the number of stuck deliveries per link
> and per router.
> A new counter "deliveriesStuck" shall be added to the link and router
> entities for per-link and aggregated-per-router respectively.
> A delivery is considered "stuck" when it has been in the undelivered or
> unsettled lists for more than ten seconds and is still not settled. Once a
> stuck delivery is settled or otherwise removed, it is no longer considered
> stuck.
> When a link transitions from zero to one stuck delivery, an INFO log message
> shall be emitted indicating that at least one delivery is stuck on that link.
--
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] ChugR commented on a change in pull request #600: DISPATCH-1463 - Add detection for stuck deliveries
ChugR commented on a change in pull request #600: DISPATCH-1463 - Add detection
for stuck deliveries
URL: https://github.com/apache/qpid-dispatch/pull/600#discussion_r340178092
##
File path: python/qpid_dispatch/management/qdrouter.json
##
@@ -570,6 +570,11 @@
"graph": true,
"description": "The total number of settled deliveries
that were held in the router for more than 10 seconds."
},
+"deliveriesStuck": {
+"type": "integer",
+"graph": true,
+"description": "The current number of deliveries that are
unsettled and have been held in the router for more than 10 seconds."
+},
Review comment:
Live stats is fine. Adding more becomes a slippery slope towards too much.
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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1453) Adding "defaultDistribution: unavailable" overrides the regular handling of transaction coordinator link refusal
[
https://issues.apache.org/jira/browse/DISPATCH-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16962143#comment-16962143
]
ASF GitHub Bot commented on DISPATCH-1453:
--
gemmellr commented on issue #602: DISPATCH-1453 - Fix the code so the correct
error message shows up wh…
URL: https://github.com/apache/qpid-dispatch/pull/602#issuecomment-547492577
The non-test code didnt seem to change since my previous comment, so I dont
think theres anything needing me to try it out again is there? That being the
case, still fine with me.
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
> Adding "defaultDistribution: unavailable" overrides the regular handling of
> transaction coordinator link refusal
>
>
> Key: DISPATCH-1453
> URL: https://issues.apache.org/jira/browse/DISPATCH-1453
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.9.0
>Reporter: Robbie Gemmell
>Assignee: Ganesh Murthy
>Priority: Minor
>
> DISPATCH-802 added handling to refuse links to the transaction coordinator
> (which has no address, but is a specific target) if a link route to e.g a
> broker isnt configured (using DISPATCH-195), and help clarify the reasons for
> the refusal.
> DISPATCH-803 was added to provide a way for links to adressses that are
> otherwise unknown to be refused rather than message routed, by setting
> "defaultDistribution: unavailable". This functionality overrides the
> behaviour from DISPATCH-802, making it less clear again why a transaction
> usage attempt has failed.
> From a JMS client trying to create a transacted session, the failure with
> "defaultDistribution: unavailable" config present looks like:
> {noformat}
> javax.jms.JMSException: No route to the destination node [condition =
> qd:no-route-to-dest]
> at
> org.apache.qpid.jms.provider.ProviderException.toJMSException(ProviderException.java:34)
> at
> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:80)
> at
> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:112)
> at org.apache.qpid.jms.JmsConnection.createResource(JmsConnection.java:698)
> at
> org.apache.qpid.jms.JmsLocalTransactionContext.begin(JmsLocalTransactionContext.java:140)
> at org.apache.qpid.jms.JmsSession.(JmsSession.java:172)
> at org.apache.qpid.jms.JmsConnection.createSession(JmsConnection.java:316)
> at org.apache.qpid.jms.example.HelloWorld.main(HelloWorld.java:52)
> {noformat}
> While without it,the router sends a more specific error condition, and so the
> failure normally looks like:
> {noformat}
> javax.jms.JMSException: The router can't coordinate transactions by itself, a
> linkRoute to a coordinator must be configured to use transactions. [condition
> = amqp:precondition-failed]
> at
> org.apache.qpid.jms.provider.ProviderException.toJMSException(ProviderException.java:34)
> at
> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:80)
> at
> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:112)
> at org.apache.qpid.jms.JmsConnection.createResource(JmsConnection.java:698)
> at
> org.apache.qpid.jms.JmsLocalTransactionContext.begin(JmsLocalTransactionContext.java:140)
> at org.apache.qpid.jms.JmsSession.(JmsSession.java:172)
> at org.apache.qpid.jms.JmsConnection.createSession(JmsConnection.java:316)
> at org.apache.qpid.jms.example.HelloWorld.main(HelloWorld.java:52)
> {noformat}
> It would be nicer if the regular coordinator refusal error condition was sent
> in both cases.
--
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] gemmellr commented on issue #602: DISPATCH-1453 - Fix the code so the correct error message shows up wh…
gemmellr commented on issue #602: DISPATCH-1453 - Fix the code so the correct error message shows up wh… URL: https://github.com/apache/qpid-dispatch/pull/602#issuecomment-547492577 The non-test code didnt seem to change since my previous comment, so I dont think theres anything needing me to try it out again is there? That being the case, still fine with me. 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 With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1463) Detect deliveries that are stuck in the router for a long time
[ https://issues.apache.org/jira/browse/DISPATCH-1463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-1463. Resolution: Fixed > Detect deliveries that are stuck in the router for a long time > -- > > Key: DISPATCH-1463 > URL: https://issues.apache.org/jira/browse/DISPATCH-1463 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Router Node >Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.10.0 > > > The delayed-delivery counts are limited in that they only count deliveries > that have been settled. These counters do not count deliveries that are > currently "stuck" and have not been settled. > This feature provides visibility into the number of stuck deliveries per link > and per router. > A new counter "deliveriesStuck" shall be added to the link and router > entities for per-link and aggregated-per-router respectively. > A delivery is considered "stuck" when it has been in the undelivered or > unsettled lists for more than ten seconds and is still not settled. Once a > stuck delivery is settled or otherwise removed, it is no longer considered > stuck. > When a link transitions from zero to one stuck delivery, an INFO log message > shall be emitted indicating that at least one delivery is stuck on that link. -- 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-1463) Detect deliveries that are stuck in the router for a long time
[ https://issues.apache.org/jira/browse/DISPATCH-1463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16962119#comment-16962119 ] ASF GitHub Bot commented on DISPATCH-1463: -- asfgit commented on pull request #600: DISPATCH-1463 - Add detection for stuck deliveries URL: https://github.com/apache/qpid-dispatch/pull/600 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 > Detect deliveries that are stuck in the router for a long time > -- > > Key: DISPATCH-1463 > URL: https://issues.apache.org/jira/browse/DISPATCH-1463 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Router Node >Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.10.0 > > > The delayed-delivery counts are limited in that they only count deliveries > that have been settled. These counters do not count deliveries that are > currently "stuck" and have not been settled. > This feature provides visibility into the number of stuck deliveries per link > and per router. > A new counter "deliveriesStuck" shall be added to the link and router > entities for per-link and aggregated-per-router respectively. > A delivery is considered "stuck" when it has been in the undelivered or > unsettled lists for more than ten seconds and is still not settled. Once a > stuck delivery is settled or otherwise removed, it is no longer considered > stuck. > When a link transitions from zero to one stuck delivery, an INFO log message > shall be emitted indicating that at least one delivery is stuck on that link. -- 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] asfgit closed pull request #600: DISPATCH-1463 - Add detection for stuck deliveries
asfgit closed pull request #600: DISPATCH-1463 - Add detection for stuck deliveries URL: https://github.com/apache/qpid-dispatch/pull/600 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 With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1463) Detect deliveries that are stuck in the router for a long time
[ https://issues.apache.org/jira/browse/DISPATCH-1463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16962118#comment-16962118 ] ASF subversion and git services commented on DISPATCH-1463: --- Commit ef4fba8b25bfa54d54c76d291cdc2493c6183ad3 in qpid-dispatch's branch refs/heads/master from Ted Ross [ https://gitbox.apache.org/repos/asf?p=qpid-dispatch.git;h=ef4fba8 ] DISPATCH-1463 - Added facility for detect stuck deliveries in the router. Added facility for the core thread to process background actions when there are no normal actions available. Added counters to router and link for currently-stuck deliveries. Added a core module to periodically check for long-unsettled (stuck) deliveries on links. Added a test set for stuck-delivery detection Exposed the new deliveries_stuck metric to the HTTP-accessible global metrics This closes #600 > Detect deliveries that are stuck in the router for a long time > -- > > Key: DISPATCH-1463 > URL: https://issues.apache.org/jira/browse/DISPATCH-1463 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Router Node >Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.10.0 > > > The delayed-delivery counts are limited in that they only count deliveries > that have been settled. These counters do not count deliveries that are > currently "stuck" and have not been settled. > This feature provides visibility into the number of stuck deliveries per link > and per router. > A new counter "deliveriesStuck" shall be added to the link and router > entities for per-link and aggregated-per-router respectively. > A delivery is considered "stuck" when it has been in the undelivered or > unsettled lists for more than ten seconds and is still not settled. Once a > stuck delivery is settled or otherwise removed, it is no longer considered > stuck. > When a link transitions from zero to one stuck delivery, an INFO log message > shall be emitted indicating that at least one delivery is stuck on that link. -- 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-2030) Use CLOCK_MONOTONIC in proactors for pn_transport_tick
[ https://issues.apache.org/jira/browse/PROTON-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16962114#comment-16962114 ] ASF GitHub Bot commented on PROTON-2030: jdanekrh commented on issue #180: PROTON-2030 Use CLOCK_MONOTONIC in proactors for pn_transport_tick URL: https://github.com/apache/qpid-proton/pull/180#issuecomment-547477437 Thanks. I'll definitely wait for PROTON-2126 to have AppVeyor green before merging. 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 > Use CLOCK_MONOTONIC in proactors for pn_transport_tick > -- > > Key: PROTON-2030 > URL: https://issues.apache.org/jira/browse/PROTON-2030 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: proton-c-0.27.0 >Reporter: Jiri Daněk >Priority: Major > > IOCP and epoll proactors are feeding wall clock time to pn_transport_tick. I > tested (with epoll) that changing system clock breaks heartbeating. > The libuv proactor does use monotonic already. -- 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] jdanekrh commented on issue #180: PROTON-2030 Use CLOCK_MONOTONIC in proactors for pn_transport_tick
jdanekrh commented on issue #180: PROTON-2030 Use CLOCK_MONOTONIC in proactors for pn_transport_tick URL: https://github.com/apache/qpid-proton/pull/180#issuecomment-547477437 Thanks. I'll definitely wait for PROTON-2126 to have AppVeyor green before merging. 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 With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1439) Expose create time/last transfer time through the Connection management entity
[ https://issues.apache.org/jira/browse/DISPATCH-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16962098#comment-16962098 ] Ulf Lilleengen commented on DISPATCH-1439: -- [~kwall] seconds since is probably enough, as thats what we want to compute for alerts anyway I think. > Expose create time/last transfer time through the Connection management entity > -- > > Key: DISPATCH-1439 > URL: https://issues.apache.org/jira/browse/DISPATCH-1439 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Keith Wall >Priority: Major > > Having these two additional attributes: > * connection create time > * connection last transfer time > would aid fault finding activities. > It would also serve as useful input to external tooling wishing to say, > balance connections to a router network. -- 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-1439) Expose create time/last transfer time through the Connection management entity
[ https://issues.apache.org/jira/browse/DISPATCH-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16962089#comment-16962089 ] Keith Wall commented on DISPATCH-1439: -- [~tross] seconds since connection creation and seconds since last transfer would suffice. As the caller, we could use the seconds since values back into absolute time values, if we wished. [~lulf]? For background - the initial use case would be as connection statistics to be displayed in a Console application. > Expose create time/last transfer time through the Connection management entity > -- > > Key: DISPATCH-1439 > URL: https://issues.apache.org/jira/browse/DISPATCH-1439 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Keith Wall >Priority: Major > > Having these two additional attributes: > * connection create time > * connection last transfer time > would aid fault finding activities. > It would also serve as useful input to external tooling wishing to say, > balance connections to a router network. -- 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-1453) Adding "defaultDistribution: unavailable" overrides the regular handling of transaction coordinator link refusal
[
https://issues.apache.org/jira/browse/DISPATCH-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16962086#comment-16962086
]
ASF GitHub Bot commented on DISPATCH-1453:
--
ganeshmurthy commented on issue #602: DISPATCH-1453 - Fix the code so the
correct error message shows up wh…
URL: https://github.com/apache/qpid-dispatch/pull/602#issuecomment-547466177
@gemmellr please approve this PR when you get a chance.
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
> Adding "defaultDistribution: unavailable" overrides the regular handling of
> transaction coordinator link refusal
>
>
> Key: DISPATCH-1453
> URL: https://issues.apache.org/jira/browse/DISPATCH-1453
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.9.0
>Reporter: Robbie Gemmell
>Assignee: Ganesh Murthy
>Priority: Minor
>
> DISPATCH-802 added handling to refuse links to the transaction coordinator
> (which has no address, but is a specific target) if a link route to e.g a
> broker isnt configured (using DISPATCH-195), and help clarify the reasons for
> the refusal.
> DISPATCH-803 was added to provide a way for links to adressses that are
> otherwise unknown to be refused rather than message routed, by setting
> "defaultDistribution: unavailable". This functionality overrides the
> behaviour from DISPATCH-802, making it less clear again why a transaction
> usage attempt has failed.
> From a JMS client trying to create a transacted session, the failure with
> "defaultDistribution: unavailable" config present looks like:
> {noformat}
> javax.jms.JMSException: No route to the destination node [condition =
> qd:no-route-to-dest]
> at
> org.apache.qpid.jms.provider.ProviderException.toJMSException(ProviderException.java:34)
> at
> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:80)
> at
> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:112)
> at org.apache.qpid.jms.JmsConnection.createResource(JmsConnection.java:698)
> at
> org.apache.qpid.jms.JmsLocalTransactionContext.begin(JmsLocalTransactionContext.java:140)
> at org.apache.qpid.jms.JmsSession.(JmsSession.java:172)
> at org.apache.qpid.jms.JmsConnection.createSession(JmsConnection.java:316)
> at org.apache.qpid.jms.example.HelloWorld.main(HelloWorld.java:52)
> {noformat}
> While without it,the router sends a more specific error condition, and so the
> failure normally looks like:
> {noformat}
> javax.jms.JMSException: The router can't coordinate transactions by itself, a
> linkRoute to a coordinator must be configured to use transactions. [condition
> = amqp:precondition-failed]
> at
> org.apache.qpid.jms.provider.ProviderException.toJMSException(ProviderException.java:34)
> at
> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:80)
> at
> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:112)
> at org.apache.qpid.jms.JmsConnection.createResource(JmsConnection.java:698)
> at
> org.apache.qpid.jms.JmsLocalTransactionContext.begin(JmsLocalTransactionContext.java:140)
> at org.apache.qpid.jms.JmsSession.(JmsSession.java:172)
> at org.apache.qpid.jms.JmsConnection.createSession(JmsConnection.java:316)
> at org.apache.qpid.jms.example.HelloWorld.main(HelloWorld.java:52)
> {noformat}
> It would be nicer if the regular coordinator refusal error condition was sent
> in both cases.
--
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 commented on issue #602: DISPATCH-1453 - Fix the code so the correct error message shows up wh…
ganeshmurthy commented on issue #602: DISPATCH-1453 - Fix the code so the correct error message shows up wh… URL: https://github.com/apache/qpid-dispatch/pull/602#issuecomment-547466177 @gemmellr please approve this PR when you get a chance. 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 With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (DISPATCH-1439) Expose create time/last transfer time through the Connection management entity
[ https://issues.apache.org/jira/browse/DISPATCH-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16961035#comment-16961035 ] Ted Ross edited comment on DISPATCH-1439 at 10/29/19 1:52 PM: -- [~kwall] What kind of timestamps are desired/acceptable for this feature? Do you want to correlate the time to log entries? Is it acceptable to have "seconds since connection creation" and "seconds since last transfer"? The latter is more efficient to implement. was (Author: tedross): What kind of timestamps are desired/acceptable for this feature? Do you want to correlate the time to log entries? Is it acceptable to have "seconds since connection creation" and "seconds since last transfer"? The latter is more efficient to implement. > Expose create time/last transfer time through the Connection management entity > -- > > Key: DISPATCH-1439 > URL: https://issues.apache.org/jira/browse/DISPATCH-1439 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Keith Wall >Priority: Major > > Having these two additional attributes: > * connection create time > * connection last transfer time > would aid fault finding activities. > It would also serve as useful input to external tooling wishing to say, > balance connections to a router network. -- 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-1453) Adding "defaultDistribution: unavailable" overrides the regular handling of transaction coordinator link refusal
[ https://issues.apache.org/jira/browse/DISPATCH-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16962023#comment-16962023 ] ASF GitHub Bot commented on DISPATCH-1453: -- codecov-io commented on issue #602: DISPATCH-1453 - Fix the code so the correct error message shows up wh… URL: https://github.com/apache/qpid-dispatch/pull/602#issuecomment-547126348 # [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/602?src=pr=h1) Report > Merging [#602](https://codecov.io/gh/apache/qpid-dispatch/pull/602?src=pr=desc) into [master](https://codecov.io/gh/apache/qpid-dispatch/commit/d37ee8c3ae0344e462d816c90db8a915588c2b1d?src=pr=desc) will **decrease** coverage by `<.01%`. > The diff coverage is `100%`. [](https://codecov.io/gh/apache/qpid-dispatch/pull/602?src=pr=tree) ```diff @@Coverage Diff @@ ## master #602 +/- ## == - Coverage 86.39% 86.38% -0.01% == Files 90 90 Lines 2049520496 +1 == - Hits1770717706 -1 - Misses 2788 2790 +2 ``` | [Impacted Files](https://codecov.io/gh/apache/qpid-dispatch/pull/602?src=pr=tree) | Coverage Δ | | |---|---|---| | [...core/modules/address\_lookup\_client/lookup\_client.c](https://codecov.io/gh/apache/qpid-dispatch/pull/602/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL21vZHVsZXMvYWRkcmVzc19sb29rdXBfY2xpZW50L2xvb2t1cF9jbGllbnQuYw==) | `92.38% <100%> (+1.09%)` | :arrow_up: | | [src/router\_core/transfer.c](https://codecov.io/gh/apache/qpid-dispatch/pull/602/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL3RyYW5zZmVyLmM=) | `93.26% <0%> (-0.75%)` | :arrow_down: | | [src/message.c](https://codecov.io/gh/apache/qpid-dispatch/pull/602/diff?src=pr=tree#diff-c3JjL21lc3NhZ2UuYw==) | `90.99% <0%> (-0.4%)` | :arrow_down: | | [src/router\_core/connections.c](https://codecov.io/gh/apache/qpid-dispatch/pull/602/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2Nvbm5lY3Rpb25zLmM=) | `93.86% <0%> (-0.35%)` | :arrow_down: | | [src/iterator.c](https://codecov.io/gh/apache/qpid-dispatch/pull/602/diff?src=pr=tree#diff-c3JjL2l0ZXJhdG9yLmM=) | `89.34% <0%> (-0.02%)` | :arrow_down: | | [src/router\_node.c](https://codecov.io/gh/apache/qpid-dispatch/pull/602/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9ub2RlLmM=) | `93.16% <0%> (+0.11%)` | :arrow_up: | | [src/router\_core/agent\_link.c](https://codecov.io/gh/apache/qpid-dispatch/pull/602/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2FnZW50X2xpbmsuYw==) | `67.33% <0%> (+0.5%)` | :arrow_up: | | [src/router\_core/forwarder.c](https://codecov.io/gh/apache/qpid-dispatch/pull/602/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2ZvcndhcmRlci5j) | `93.89% <0%> (+0.7%)` | :arrow_up: | -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/602?src=pr=continue). > **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta) > `Δ = absolute (impact)`, `ø = not affected`, `? = missing data` > Powered by [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/602?src=pr=footer). Last update [d37ee8c...1e5bc9f](https://codecov.io/gh/apache/qpid-dispatch/pull/602?src=pr=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 > Adding "defaultDistribution: unavailable" overrides the regular handling of > transaction coordinator link refusal > > > Key: DISPATCH-1453 > URL: https://issues.apache.org/jira/browse/DISPATCH-1453 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 1.9.0 >Reporter: Robbie Gemmell >Assignee: Ganesh Murthy >Priority: Minor > > DISPATCH-802 added handling to refuse links to the transaction coordinator > (which has no address, but is a specific target) if a link route to e.g a > broker isnt configured (using DISPATCH-195), and help clarify the reasons for > the refusal. > DISPATCH-803 was added to provide a way for links to adressses that are > otherwise unknown to be refused rather than message routed, by setting >
[GitHub] [qpid-dispatch] codecov-io edited a comment on issue #602: DISPATCH-1453 - Fix the code so the correct error message shows up wh…
codecov-io edited a comment on issue #602: DISPATCH-1453 - Fix the code so the correct error message shows up wh… URL: https://github.com/apache/qpid-dispatch/pull/602#issuecomment-547126348 # [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/602?src=pr=h1) Report > Merging [#602](https://codecov.io/gh/apache/qpid-dispatch/pull/602?src=pr=desc) into [master](https://codecov.io/gh/apache/qpid-dispatch/commit/d37ee8c3ae0344e462d816c90db8a915588c2b1d?src=pr=desc) will **decrease** coverage by `<.01%`. > The diff coverage is `100%`. [](https://codecov.io/gh/apache/qpid-dispatch/pull/602?src=pr=tree) ```diff @@Coverage Diff @@ ## master #602 +/- ## == - Coverage 86.39% 86.38% -0.01% == Files 90 90 Lines 2049520496 +1 == - Hits1770717706 -1 - Misses 2788 2790 +2 ``` | [Impacted Files](https://codecov.io/gh/apache/qpid-dispatch/pull/602?src=pr=tree) | Coverage Δ | | |---|---|---| | [...core/modules/address\_lookup\_client/lookup\_client.c](https://codecov.io/gh/apache/qpid-dispatch/pull/602/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL21vZHVsZXMvYWRkcmVzc19sb29rdXBfY2xpZW50L2xvb2t1cF9jbGllbnQuYw==) | `92.38% <100%> (+1.09%)` | :arrow_up: | | [src/router\_core/transfer.c](https://codecov.io/gh/apache/qpid-dispatch/pull/602/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL3RyYW5zZmVyLmM=) | `93.26% <0%> (-0.75%)` | :arrow_down: | | [src/message.c](https://codecov.io/gh/apache/qpid-dispatch/pull/602/diff?src=pr=tree#diff-c3JjL21lc3NhZ2UuYw==) | `90.99% <0%> (-0.4%)` | :arrow_down: | | [src/router\_core/connections.c](https://codecov.io/gh/apache/qpid-dispatch/pull/602/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2Nvbm5lY3Rpb25zLmM=) | `93.86% <0%> (-0.35%)` | :arrow_down: | | [src/iterator.c](https://codecov.io/gh/apache/qpid-dispatch/pull/602/diff?src=pr=tree#diff-c3JjL2l0ZXJhdG9yLmM=) | `89.34% <0%> (-0.02%)` | :arrow_down: | | [src/router\_node.c](https://codecov.io/gh/apache/qpid-dispatch/pull/602/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9ub2RlLmM=) | `93.16% <0%> (+0.11%)` | :arrow_up: | | [src/router\_core/agent\_link.c](https://codecov.io/gh/apache/qpid-dispatch/pull/602/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2FnZW50X2xpbmsuYw==) | `67.33% <0%> (+0.5%)` | :arrow_up: | | [src/router\_core/forwarder.c](https://codecov.io/gh/apache/qpid-dispatch/pull/602/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2ZvcndhcmRlci5j) | `93.89% <0%> (+0.7%)` | :arrow_up: | -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/602?src=pr=continue). > **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta) > `Δ = absolute (impact)`, `ø = not affected`, `? = missing data` > Powered by [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/602?src=pr=footer). Last update [d37ee8c...1e5bc9f](https://codecov.io/gh/apache/qpid-dispatch/pull/602?src=pr=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 With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] ganeshmurthy commented on a change in pull request #602: DISPATCH-1453 - Fix the code so the correct error message shows up wh…
ganeshmurthy commented on a change in pull request #602: DISPATCH-1453 - Fix
the code so the correct error message shows up wh…
URL: https://github.com/apache/qpid-dispatch/pull/602#discussion_r340069963
##
File path: tests/system_tests_one_router.py
##
@@ -3160,6 +3159,86 @@ def on_message(self, event):
self.receiver.close()
self.recv_conn.close()
+class OneRouterUnavailableCoordinatorTest(TestCase):
+@classmethod
+def setUpClass(cls):
+super(OneRouterUnavailableCoordinatorTest, cls).setUpClass()
+name = "test-router"
+OneRouterTest.listen_port = cls.tester.get_port()
+config = Qdrouterd.Config([
+('router', {'mode': 'standalone', 'id': 'QDR',
'defaultDistribution': 'unavailable'}),
+('listener', {'port': cls.tester.get_port() }),
+('address', {'prefix': 'closest', 'distribution': 'closest'}),
+('address', {'prefix': 'balanced', 'distribution': 'balanced'}),
+('address', {'prefix': 'multicast', 'distribution': 'multicast'}),
+])
+cls.router = cls.tester.qdrouterd(name, config)
+cls.router.wait_ready()
+cls.address = cls.router.addresses[0]
+
+def test_46_coordinator_linkroute_unavailable_DISPATCH_1453(self):
+# The defaultDistribution on the router is unavailable. We try to
connect a tx sender
+# to make sure a good detailed message saying "the link route to a
coordinator must be
+# configured" is sent back.
+test = RejectCoordinatorGoodMessageTest(self.address)
+test.run()
+self.assertTrue(test.passed)
+
+def test_47_coordinator_linkroute_available_DISPATCH_1453(self):
+# The defaultDistribution on the router is unavailable. We create a
link route with $coordinator address
+# The link route is not attached to any broker. When the attach comes
in, the reject message must be
+# condition=:"qd:no-route-to-dest", description="No route to the
destination node"
+COORDINATOR = "$coordinator"
+long_type = 'org.apache.qpid.dispatch.router.config.linkRoute'
+qd_manager = QdManager(self, address=self.address)
+args = {"prefix": COORDINATOR, "connection": "broker", "dir": "in"}
+qd_manager.create(long_type, args)
+link_route_created = False
+
+# Verify that the link route was created by querying for it.
+outs = qd_manager.query(long_type)[0]
+if outs:
+try:
+if outs['prefix'] == COORDINATOR:
+link_route_created = True
+except:
+pass
+
+self.assertTrue(link_route_created)
+
+# We have verified that the link route has been created but there is
no broker connections.
+# Now let's try to open a transaction. We should get a no route to
destination error
+test = RejectCoordinatorGoodMessageTest(self.address,
link_route_present=True)
+test.run()
+self.assertTrue(test.passed)
+
+
+class RejectCoordinatorGoodMessageTest(RejectCoordinatorTest):
+def __init__(self, url, link_route_present=False):
+super(RejectCoordinatorGoodMessageTest, self).__init__(url)
+self.link_route_present = link_route_present
+self.error_with_link_route = "No route to the destination node"
+
+def on_link_error(self, event):
Review comment:
Removed duplicate on_link_error. thanks
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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1453) Adding "defaultDistribution: unavailable" overrides the regular handling of transaction coordinator link refusal
[
https://issues.apache.org/jira/browse/DISPATCH-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16962006#comment-16962006
]
ASF GitHub Bot commented on DISPATCH-1453:
--
ganeshmurthy commented on pull request #602: DISPATCH-1453 - Fix the code so
the correct error message shows up wh…
URL: https://github.com/apache/qpid-dispatch/pull/602#discussion_r340069963
##
File path: tests/system_tests_one_router.py
##
@@ -3160,6 +3159,86 @@ def on_message(self, event):
self.receiver.close()
self.recv_conn.close()
+class OneRouterUnavailableCoordinatorTest(TestCase):
+@classmethod
+def setUpClass(cls):
+super(OneRouterUnavailableCoordinatorTest, cls).setUpClass()
+name = "test-router"
+OneRouterTest.listen_port = cls.tester.get_port()
+config = Qdrouterd.Config([
+('router', {'mode': 'standalone', 'id': 'QDR',
'defaultDistribution': 'unavailable'}),
+('listener', {'port': cls.tester.get_port() }),
+('address', {'prefix': 'closest', 'distribution': 'closest'}),
+('address', {'prefix': 'balanced', 'distribution': 'balanced'}),
+('address', {'prefix': 'multicast', 'distribution': 'multicast'}),
+])
+cls.router = cls.tester.qdrouterd(name, config)
+cls.router.wait_ready()
+cls.address = cls.router.addresses[0]
+
+def test_46_coordinator_linkroute_unavailable_DISPATCH_1453(self):
+# The defaultDistribution on the router is unavailable. We try to
connect a tx sender
+# to make sure a good detailed message saying "the link route to a
coordinator must be
+# configured" is sent back.
+test = RejectCoordinatorGoodMessageTest(self.address)
+test.run()
+self.assertTrue(test.passed)
+
+def test_47_coordinator_linkroute_available_DISPATCH_1453(self):
+# The defaultDistribution on the router is unavailable. We create a
link route with $coordinator address
+# The link route is not attached to any broker. When the attach comes
in, the reject message must be
+# condition=:"qd:no-route-to-dest", description="No route to the
destination node"
+COORDINATOR = "$coordinator"
+long_type = 'org.apache.qpid.dispatch.router.config.linkRoute'
+qd_manager = QdManager(self, address=self.address)
+args = {"prefix": COORDINATOR, "connection": "broker", "dir": "in"}
+qd_manager.create(long_type, args)
+link_route_created = False
+
+# Verify that the link route was created by querying for it.
+outs = qd_manager.query(long_type)[0]
+if outs:
+try:
+if outs['prefix'] == COORDINATOR:
+link_route_created = True
+except:
+pass
+
+self.assertTrue(link_route_created)
+
+# We have verified that the link route has been created but there is
no broker connections.
+# Now let's try to open a transaction. We should get a no route to
destination error
+test = RejectCoordinatorGoodMessageTest(self.address,
link_route_present=True)
+test.run()
+self.assertTrue(test.passed)
+
+
+class RejectCoordinatorGoodMessageTest(RejectCoordinatorTest):
+def __init__(self, url, link_route_present=False):
+super(RejectCoordinatorGoodMessageTest, self).__init__(url)
+self.link_route_present = link_route_present
+self.error_with_link_route = "No route to the destination node"
+
+def on_link_error(self, event):
Review comment:
Removed duplicate on_link_error. thanks
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
> Adding "defaultDistribution: unavailable" overrides the regular handling of
> transaction coordinator link refusal
>
>
> Key: DISPATCH-1453
> URL: https://issues.apache.org/jira/browse/DISPATCH-1453
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.9.0
>Reporter: Robbie Gemmell
>Assignee: Ganesh Murthy
>Priority: Minor
>
> DISPATCH-802 added handling to refuse links to the transaction coordinator
> (which has no address, but is a specific target) if a link route to e.g a
> broker isnt configured (using DISPATCH-195), and help clarify the reasons for
> the refusal.
> DISPATCH-803 was added to provide a way for links to adressses that are
> otherwise unknown to be refused rather than message routed, by
[GitHub] [qpid-dispatch] ted-ross commented on a change in pull request #600: DISPATCH-1463 - Add detection for stuck deliveries
ted-ross commented on a change in pull request #600: DISPATCH-1463 - Add
detection for stuck deliveries
URL: https://github.com/apache/qpid-dispatch/pull/600#discussion_r340068152
##
File path: python/qpid_dispatch/management/qdrouter.json
##
@@ -570,6 +570,11 @@
"graph": true,
"description": "The total number of settled deliveries
that were held in the router for more than 10 seconds."
},
+"deliveriesStuck": {
+"type": "integer",
+"graph": true,
+"description": "The current number of deliveries that are
unsettled and have been held in the router for more than 10 seconds."
+},
Review comment:
Do we need this? INFO logs are issued when a link has stuck deliveries and
the count is available through the prometheus-format scraper.
Since this is more of a gauge than a counter, having a peak value might be
appropriate. Would it also require a way to be reset?
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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1463) Detect deliveries that are stuck in the router for a long time
[
https://issues.apache.org/jira/browse/DISPATCH-1463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16962003#comment-16962003
]
ASF GitHub Bot commented on DISPATCH-1463:
--
ted-ross commented on pull request #600: DISPATCH-1463 - Add detection for
stuck deliveries
URL: https://github.com/apache/qpid-dispatch/pull/600#discussion_r340068152
##
File path: python/qpid_dispatch/management/qdrouter.json
##
@@ -570,6 +570,11 @@
"graph": true,
"description": "The total number of settled deliveries
that were held in the router for more than 10 seconds."
},
+"deliveriesStuck": {
+"type": "integer",
+"graph": true,
+"description": "The current number of deliveries that are
unsettled and have been held in the router for more than 10 seconds."
+},
Review comment:
Do we need this? INFO logs are issued when a link has stuck deliveries and
the count is available through the prometheus-format scraper.
Since this is more of a gauge than a counter, having a peak value might be
appropriate. Would it also require a way to be reset?
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
> Detect deliveries that are stuck in the router for a long time
> --
>
> Key: DISPATCH-1463
> URL: https://issues.apache.org/jira/browse/DISPATCH-1463
> Project: Qpid Dispatch
> Issue Type: New Feature
> Components: Router Node
>Reporter: Ted Ross
>Assignee: Ted Ross
>Priority: Major
> Fix For: 1.10.0
>
>
> The delayed-delivery counts are limited in that they only count deliveries
> that have been settled. These counters do not count deliveries that are
> currently "stuck" and have not been settled.
> This feature provides visibility into the number of stuck deliveries per link
> and per router.
> A new counter "deliveriesStuck" shall be added to the link and router
> entities for per-link and aggregated-per-router respectively.
> A delivery is considered "stuck" when it has been in the undelivered or
> unsettled lists for more than ten seconds and is still not settled. Once a
> stuck delivery is settled or otherwise removed, it is no longer considered
> stuck.
> When a link transitions from zero to one stuck delivery, an INFO log message
> shall be emitted indicating that at least one delivery is stuck on that link.
--
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-1453) Adding "defaultDistribution: unavailable" overrides the regular handling of transaction coordinator link refusal
[
https://issues.apache.org/jira/browse/DISPATCH-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16961982#comment-16961982
]
ASF GitHub Bot commented on DISPATCH-1453:
--
kgiusti commented on pull request #602: DISPATCH-1453 - Fix the code so the
correct error message shows up wh…
URL: https://github.com/apache/qpid-dispatch/pull/602#discussion_r340056525
##
File path: tests/system_tests_one_router.py
##
@@ -3160,6 +3159,86 @@ def on_message(self, event):
self.receiver.close()
self.recv_conn.close()
+class OneRouterUnavailableCoordinatorTest(TestCase):
+@classmethod
+def setUpClass(cls):
+super(OneRouterUnavailableCoordinatorTest, cls).setUpClass()
+name = "test-router"
+OneRouterTest.listen_port = cls.tester.get_port()
+config = Qdrouterd.Config([
+('router', {'mode': 'standalone', 'id': 'QDR',
'defaultDistribution': 'unavailable'}),
+('listener', {'port': cls.tester.get_port() }),
+('address', {'prefix': 'closest', 'distribution': 'closest'}),
+('address', {'prefix': 'balanced', 'distribution': 'balanced'}),
+('address', {'prefix': 'multicast', 'distribution': 'multicast'}),
+])
+cls.router = cls.tester.qdrouterd(name, config)
+cls.router.wait_ready()
+cls.address = cls.router.addresses[0]
+
+def test_46_coordinator_linkroute_unavailable_DISPATCH_1453(self):
+# The defaultDistribution on the router is unavailable. We try to
connect a tx sender
+# to make sure a good detailed message saying "the link route to a
coordinator must be
+# configured" is sent back.
+test = RejectCoordinatorGoodMessageTest(self.address)
+test.run()
+self.assertTrue(test.passed)
+
+def test_47_coordinator_linkroute_available_DISPATCH_1453(self):
+# The defaultDistribution on the router is unavailable. We create a
link route with $coordinator address
+# The link route is not attached to any broker. When the attach comes
in, the reject message must be
+# condition=:"qd:no-route-to-dest", description="No route to the
destination node"
+COORDINATOR = "$coordinator"
+long_type = 'org.apache.qpid.dispatch.router.config.linkRoute'
+qd_manager = QdManager(self, address=self.address)
+args = {"prefix": COORDINATOR, "connection": "broker", "dir": "in"}
+qd_manager.create(long_type, args)
+link_route_created = False
+
+# Verify that the link route was created by querying for it.
+outs = qd_manager.query(long_type)[0]
+if outs:
+try:
+if outs['prefix'] == COORDINATOR:
+link_route_created = True
+except:
+pass
+
+self.assertTrue(link_route_created)
+
+# We have verified that the link route has been created but there is
no broker connections.
+# Now let's try to open a transaction. We should get a no route to
destination error
+test = RejectCoordinatorGoodMessageTest(self.address,
link_route_present=True)
+test.run()
+self.assertTrue(test.passed)
+
+
+class RejectCoordinatorGoodMessageTest(RejectCoordinatorTest):
+def __init__(self, url, link_route_present=False):
+super(RejectCoordinatorGoodMessageTest, self).__init__(url)
+self.link_route_present = link_route_present
+self.error_with_link_route = "No route to the destination node"
+
+def on_link_error(self, event):
Review comment:
Duplicate def of on_link_error (see next def below)
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
> Adding "defaultDistribution: unavailable" overrides the regular handling of
> transaction coordinator link refusal
>
>
> Key: DISPATCH-1453
> URL: https://issues.apache.org/jira/browse/DISPATCH-1453
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.9.0
>Reporter: Robbie Gemmell
>Assignee: Ganesh Murthy
>Priority: Minor
>
> DISPATCH-802 added handling to refuse links to the transaction coordinator
> (which has no address, but is a specific target) if a link route to e.g a
> broker isnt configured (using DISPATCH-195), and help clarify the reasons for
> the refusal.
> DISPATCH-803 was added to provide a way for links to adressses that are
> otherwise unknown to be refused rather than message routed,
[GitHub] [qpid-dispatch] kgiusti commented on a change in pull request #602: DISPATCH-1453 - Fix the code so the correct error message shows up wh…
kgiusti commented on a change in pull request #602: DISPATCH-1453 - Fix the
code so the correct error message shows up wh…
URL: https://github.com/apache/qpid-dispatch/pull/602#discussion_r340056525
##
File path: tests/system_tests_one_router.py
##
@@ -3160,6 +3159,86 @@ def on_message(self, event):
self.receiver.close()
self.recv_conn.close()
+class OneRouterUnavailableCoordinatorTest(TestCase):
+@classmethod
+def setUpClass(cls):
+super(OneRouterUnavailableCoordinatorTest, cls).setUpClass()
+name = "test-router"
+OneRouterTest.listen_port = cls.tester.get_port()
+config = Qdrouterd.Config([
+('router', {'mode': 'standalone', 'id': 'QDR',
'defaultDistribution': 'unavailable'}),
+('listener', {'port': cls.tester.get_port() }),
+('address', {'prefix': 'closest', 'distribution': 'closest'}),
+('address', {'prefix': 'balanced', 'distribution': 'balanced'}),
+('address', {'prefix': 'multicast', 'distribution': 'multicast'}),
+])
+cls.router = cls.tester.qdrouterd(name, config)
+cls.router.wait_ready()
+cls.address = cls.router.addresses[0]
+
+def test_46_coordinator_linkroute_unavailable_DISPATCH_1453(self):
+# The defaultDistribution on the router is unavailable. We try to
connect a tx sender
+# to make sure a good detailed message saying "the link route to a
coordinator must be
+# configured" is sent back.
+test = RejectCoordinatorGoodMessageTest(self.address)
+test.run()
+self.assertTrue(test.passed)
+
+def test_47_coordinator_linkroute_available_DISPATCH_1453(self):
+# The defaultDistribution on the router is unavailable. We create a
link route with $coordinator address
+# The link route is not attached to any broker. When the attach comes
in, the reject message must be
+# condition=:"qd:no-route-to-dest", description="No route to the
destination node"
+COORDINATOR = "$coordinator"
+long_type = 'org.apache.qpid.dispatch.router.config.linkRoute'
+qd_manager = QdManager(self, address=self.address)
+args = {"prefix": COORDINATOR, "connection": "broker", "dir": "in"}
+qd_manager.create(long_type, args)
+link_route_created = False
+
+# Verify that the link route was created by querying for it.
+outs = qd_manager.query(long_type)[0]
+if outs:
+try:
+if outs['prefix'] == COORDINATOR:
+link_route_created = True
+except:
+pass
+
+self.assertTrue(link_route_created)
+
+# We have verified that the link route has been created but there is
no broker connections.
+# Now let's try to open a transaction. We should get a no route to
destination error
+test = RejectCoordinatorGoodMessageTest(self.address,
link_route_present=True)
+test.run()
+self.assertTrue(test.passed)
+
+
+class RejectCoordinatorGoodMessageTest(RejectCoordinatorTest):
+def __init__(self, url, link_route_present=False):
+super(RejectCoordinatorGoodMessageTest, self).__init__(url)
+self.link_route_present = link_route_present
+self.error_with_link_route = "No route to the destination node"
+
+def on_link_error(self, event):
Review comment:
Duplicate def of on_link_error (see next def below)
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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] gemmellr commented on issue #602: DISPATCH-1453 - Fix the code so the correct error message shows up wh…
gemmellr commented on issue #602: DISPATCH-1453 - Fix the code so the correct error message shows up wh… URL: https://github.com/apache/qpid-dispatch/pull/602#issuecomment-547358472 @ganeshmurthy this seems to do the trick, with links to the coordinator rejected with same specific error condition+description regardless whether "defaultDistribution : unavailable" is configured or not. 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 With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1453) Adding "defaultDistribution: unavailable" overrides the regular handling of transaction coordinator link refusal
[
https://issues.apache.org/jira/browse/DISPATCH-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16961875#comment-16961875
]
ASF GitHub Bot commented on DISPATCH-1453:
--
gemmellr commented on issue #602: DISPATCH-1453 - Fix the code so the correct
error message shows up wh…
URL: https://github.com/apache/qpid-dispatch/pull/602#issuecomment-547358472
@ganeshmurthy this seems to do the trick, with links to the coordinator
rejected with same specific error condition+description regardless whether
"defaultDistribution : unavailable" is configured or not.
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
> Adding "defaultDistribution: unavailable" overrides the regular handling of
> transaction coordinator link refusal
>
>
> Key: DISPATCH-1453
> URL: https://issues.apache.org/jira/browse/DISPATCH-1453
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.9.0
>Reporter: Robbie Gemmell
>Assignee: Ganesh Murthy
>Priority: Minor
>
> DISPATCH-802 added handling to refuse links to the transaction coordinator
> (which has no address, but is a specific target) if a link route to e.g a
> broker isnt configured (using DISPATCH-195), and help clarify the reasons for
> the refusal.
> DISPATCH-803 was added to provide a way for links to adressses that are
> otherwise unknown to be refused rather than message routed, by setting
> "defaultDistribution: unavailable". This functionality overrides the
> behaviour from DISPATCH-802, making it less clear again why a transaction
> usage attempt has failed.
> From a JMS client trying to create a transacted session, the failure with
> "defaultDistribution: unavailable" config present looks like:
> {noformat}
> javax.jms.JMSException: No route to the destination node [condition =
> qd:no-route-to-dest]
> at
> org.apache.qpid.jms.provider.ProviderException.toJMSException(ProviderException.java:34)
> at
> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:80)
> at
> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:112)
> at org.apache.qpid.jms.JmsConnection.createResource(JmsConnection.java:698)
> at
> org.apache.qpid.jms.JmsLocalTransactionContext.begin(JmsLocalTransactionContext.java:140)
> at org.apache.qpid.jms.JmsSession.(JmsSession.java:172)
> at org.apache.qpid.jms.JmsConnection.createSession(JmsConnection.java:316)
> at org.apache.qpid.jms.example.HelloWorld.main(HelloWorld.java:52)
> {noformat}
> While without it,the router sends a more specific error condition, and so the
> failure normally looks like:
> {noformat}
> javax.jms.JMSException: The router can't coordinate transactions by itself, a
> linkRoute to a coordinator must be configured to use transactions. [condition
> = amqp:precondition-failed]
> at
> org.apache.qpid.jms.provider.ProviderException.toJMSException(ProviderException.java:34)
> at
> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:80)
> at
> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:112)
> at org.apache.qpid.jms.JmsConnection.createResource(JmsConnection.java:698)
> at
> org.apache.qpid.jms.JmsLocalTransactionContext.begin(JmsLocalTransactionContext.java:140)
> at org.apache.qpid.jms.JmsSession.(JmsSession.java:172)
> at org.apache.qpid.jms.JmsConnection.createSession(JmsConnection.java:316)
> at org.apache.qpid.jms.example.HelloWorld.main(HelloWorld.java:52)
> {noformat}
> It would be nicer if the regular coordinator refusal error condition was sent
> in both cases.
--
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
