[jira] [Commented] (DISPATCH-976) Allow policy for sources and targets to handle multiple wildcards
[
https://issues.apache.org/jira/browse/DISPATCH-976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510526#comment-16510526
]
ASF GitHub Bot commented on DISPATCH-976:
-
Github user fgiorgetti commented on the issue:
https://github.com/apache/qpid-dispatch/pull/324
@ganeshmurthy and @ChugR after debugging it a little bit more, I noticed
that the first if statement that checks for an absent user key in the iterating
allowed address, was also checking the "need_check_nosubst" boolean, enforcing
that only one address with "absent" user key is defined.
So with this boolean flag, in case more than one address is defined in the
tree (without the user key), it causes the last "else" statement to be
processed and then executing the "assert(false);" which was crashing the router.
In this PR I have removed the need_check_nosubst flag which seems to
resolve the issue reported in DISPATCH-1026 as well.
> Allow policy for sources and targets to handle multiple wildcards
> -
>
> Key: DISPATCH-976
> URL: https://issues.apache.org/jira/browse/DISPATCH-976
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Policy Engine
>Affects Versions: 1.0.1
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>Priority: Major
> Fix For: 1.2.0
>
>
> As per the [upstream policy
> documentation|https://github.com/apache/qpid-dispatch/blob/1.0.0/doc/book/policy.adoc]
> in the secion on [AMQP Source and Target Wildcard and Name
> Substitution|https://github.com/apache/qpid-dispatch/blob/1.0.0/doc/book/policy.adoc#amqp-source-and-target-wildcard-and-name-substitution]
> utilization of the asterisk wildcard is constrained as per the following
> quote:
> {quote}The asterisk is recognized only if it is the last character in the
> link name.
> {quote}
> It is desirable that the configuration could handle a situation where there
> are multiple asterisks in use such as:
>
> |{color:#00}"tstGroup": {{color}|
> |{color:#00} "users": "tst@amq",{color}|
> |{color:#00} "sources": "abc.*,my.*.b2b.tst.*",{color}|
> |{color:#00} "targets": "abc.*,my.*.b2b.tst.*",{color}|
> |{color:#00} "remoteHosts": "*"{color}|
> |{color:#00}} {color}|
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch issue #324: DISPATCH-976 - Fixed issue with policy validation ...
Github user fgiorgetti commented on the issue: https://github.com/apache/qpid-dispatch/pull/324 @ganeshmurthy and @ChugR after debugging it a little bit more, I noticed that the first if statement that checks for an absent user key in the iterating allowed address, was also checking the "need_check_nosubst" boolean, enforcing that only one address with "absent" user key is defined. So with this boolean flag, in case more than one address is defined in the tree (without the user key), it causes the last "else" statement to be processed and then executing the "assert(false);" which was crashing the router. In this PR I have removed the need_check_nosubst flag which seems to resolve the issue reported in DISPATCH-1026 as well. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-976) Allow policy for sources and targets to handle multiple wildcards
[
https://issues.apache.org/jira/browse/DISPATCH-976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510521#comment-16510521
]
ASF GitHub Bot commented on DISPATCH-976:
-
Github user codecov-io commented on the issue:
https://github.com/apache/qpid-dispatch/pull/324
#
[Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/324?src=pr=h1)
Report
> Merging
[#324](https://codecov.io/gh/apache/qpid-dispatch/pull/324?src=pr=desc) into
[master](https://codecov.io/gh/apache/qpid-dispatch/commit/8c7e87275fb481f25d8deaa4f639f3a4d1c532d9?src=pr=desc)
will **decrease** coverage by `0.01%`.
> The diff coverage is `100%`.
[](https://codecov.io/gh/apache/qpid-dispatch/pull/324?src=pr=tree)
```diff
@@Coverage Diff @@
## master #324 +/- ##
==
- Coverage 86.55% 86.54% -0.02%
==
Files 69 69
Lines 1546615464 -2
==
- Hits1338713383 -4
- Misses 2079 2081 +2
```
| [Impacted
Files](https://codecov.io/gh/apache/qpid-dispatch/pull/324?src=pr=tree) |
Coverage Δ | |
|---|---|---|
|
[src/policy.c](https://codecov.io/gh/apache/qpid-dispatch/pull/324/diff?src=pr=tree#diff-c3JjL3BvbGljeS5j)
| `86.75% <100%> (+0.85%)` | :arrow_up: |
|
[src/router\_core/agent\_link.c](https://codecov.io/gh/apache/qpid-dispatch/pull/324/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2FnZW50X2xpbmsuYw==)
| `63.21% <0%> (-0.58%)` | :arrow_down: |
|
[src/router\_core/router\_core.c](https://codecov.io/gh/apache/qpid-dispatch/pull/324/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL3JvdXRlcl9jb3JlLmM=)
| `98.88% <0%> (-0.38%)` | :arrow_down: |
|
[src/router\_core/transfer.c](https://codecov.io/gh/apache/qpid-dispatch/pull/324/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL3RyYW5zZmVyLmM=)
| `90.26% <0%> (-0.32%)` | :arrow_down: |
|
[src/router\_core/connections.c](https://codecov.io/gh/apache/qpid-dispatch/pull/324/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2Nvbm5lY3Rpb25zLmM=)
| `95.01% <0%> (-0.24%)` | :arrow_down: |
|
[src/router\_node.c](https://codecov.io/gh/apache/qpid-dispatch/pull/324/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9ub2RlLmM=)
| `94.57% <0%> (-0.15%)` | :arrow_down: |
|
[src/server.c](https://codecov.io/gh/apache/qpid-dispatch/pull/324/diff?src=pr=tree#diff-c3JjL3NlcnZlci5j)
| `87.73% <0%> (-0.12%)` | :arrow_down: |
|
[src/iterator.c](https://codecov.io/gh/apache/qpid-dispatch/pull/324/diff?src=pr=tree#diff-c3JjL2l0ZXJhdG9yLmM=)
| `86.8% <0%> (+0.19%)` | :arrow_up: |
--
[Continue to review full report at
Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/324?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/324?src=pr=footer).
Last update
[8c7e872...1892f5d](https://codecov.io/gh/apache/qpid-dispatch/pull/324?src=pr=lastupdated).
Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).
> Allow policy for sources and targets to handle multiple wildcards
> -
>
> Key: DISPATCH-976
> URL: https://issues.apache.org/jira/browse/DISPATCH-976
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Policy Engine
>Affects Versions: 1.0.1
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>Priority: Major
> Fix For: 1.2.0
>
>
> As per the [upstream policy
> documentation|https://github.com/apache/qpid-dispatch/blob/1.0.0/doc/book/policy.adoc]
> in the secion on [AMQP Source and Target Wildcard and Name
> Substitution|https://github.com/apache/qpid-dispatch/blob/1.0.0/doc/book/policy.adoc#amqp-source-and-target-wildcard-and-name-substitution]
> utilization of the asterisk wildcard is constrained as per the following
> quote:
> {quote}The asterisk is recognized only if it is the last character in the
> link name.
> {quote}
> It is desirable that the configuration could handle a situation where there
> are multiple asterisks in use such as:
>
> |{color:#00}"tstGroup": {{color}|
> |{color:#00} "users": "tst@amq",{color}|
> |{color:#00} "sources": "abc.*,my.*.b2b.tst.*",{color}|
> |{color:#00} "targets": "abc.*,my.*.b2b.tst.*",{color}|
> |{color:#00} "remoteHosts": "*"{color}|
> |{color:#00}} {color}|
[GitHub] qpid-dispatch issue #324: DISPATCH-976 - Fixed issue with policy validation ...
Github user codecov-io commented on the issue: https://github.com/apache/qpid-dispatch/pull/324 # [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/324?src=pr=h1) Report > Merging [#324](https://codecov.io/gh/apache/qpid-dispatch/pull/324?src=pr=desc) into [master](https://codecov.io/gh/apache/qpid-dispatch/commit/8c7e87275fb481f25d8deaa4f639f3a4d1c532d9?src=pr=desc) will **decrease** coverage by `0.01%`. > The diff coverage is `100%`. [](https://codecov.io/gh/apache/qpid-dispatch/pull/324?src=pr=tree) ```diff @@Coverage Diff @@ ## master #324 +/- ## == - Coverage 86.55% 86.54% -0.02% == Files 69 69 Lines 1546615464 -2 == - Hits1338713383 -4 - Misses 2079 2081 +2 ``` | [Impacted Files](https://codecov.io/gh/apache/qpid-dispatch/pull/324?src=pr=tree) | Coverage Π| | |---|---|---| | [src/policy.c](https://codecov.io/gh/apache/qpid-dispatch/pull/324/diff?src=pr=tree#diff-c3JjL3BvbGljeS5j) | `86.75% <100%> (+0.85%)` | :arrow_up: | | [src/router\_core/agent\_link.c](https://codecov.io/gh/apache/qpid-dispatch/pull/324/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2FnZW50X2xpbmsuYw==) | `63.21% <0%> (-0.58%)` | :arrow_down: | | [src/router\_core/router\_core.c](https://codecov.io/gh/apache/qpid-dispatch/pull/324/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL3JvdXRlcl9jb3JlLmM=) | `98.88% <0%> (-0.38%)` | :arrow_down: | | [src/router\_core/transfer.c](https://codecov.io/gh/apache/qpid-dispatch/pull/324/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL3RyYW5zZmVyLmM=) | `90.26% <0%> (-0.32%)` | :arrow_down: | | [src/router\_core/connections.c](https://codecov.io/gh/apache/qpid-dispatch/pull/324/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2Nvbm5lY3Rpb25zLmM=) | `95.01% <0%> (-0.24%)` | :arrow_down: | | [src/router\_node.c](https://codecov.io/gh/apache/qpid-dispatch/pull/324/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9ub2RlLmM=) | `94.57% <0%> (-0.15%)` | :arrow_down: | | [src/server.c](https://codecov.io/gh/apache/qpid-dispatch/pull/324/diff?src=pr=tree#diff-c3JjL3NlcnZlci5j) | `87.73% <0%> (-0.12%)` | :arrow_down: | | [src/iterator.c](https://codecov.io/gh/apache/qpid-dispatch/pull/324/diff?src=pr=tree#diff-c3JjL2l0ZXJhdG9yLmM=) | `86.8% <0%> (+0.19%)` | :arrow_up: | -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/324?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/324?src=pr=footer). Last update [8c7e872...1892f5d](https://codecov.io/gh/apache/qpid-dispatch/pull/324?src=pr=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments). --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-976) Allow policy for sources and targets to handle multiple wildcards
[
https://issues.apache.org/jira/browse/DISPATCH-976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510514#comment-16510514
]
ASF GitHub Bot commented on DISPATCH-976:
-
GitHub user fgiorgetti opened a pull request:
https://github.com/apache/qpid-dispatch/pull/324
DISPATCH-976 - Fixed issue with policy validation of allowed addresses
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/fgiorgetti/qpid-dispatch
fgiorgetti-DISPATCH-976-1
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/qpid-dispatch/pull/324.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #324
commit 1892f5dc68296e5b5ec107f6212e0e24f4b852e3
Author: Fernando Giorgetti
Date: 2018-06-13T01:57:17Z
DISPATCH-976 - Fixed issue with policy validation of allowed addresses
> Allow policy for sources and targets to handle multiple wildcards
> -
>
> Key: DISPATCH-976
> URL: https://issues.apache.org/jira/browse/DISPATCH-976
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Policy Engine
>Affects Versions: 1.0.1
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>Priority: Major
> Fix For: 1.2.0
>
>
> As per the [upstream policy
> documentation|https://github.com/apache/qpid-dispatch/blob/1.0.0/doc/book/policy.adoc]
> in the secion on [AMQP Source and Target Wildcard and Name
> Substitution|https://github.com/apache/qpid-dispatch/blob/1.0.0/doc/book/policy.adoc#amqp-source-and-target-wildcard-and-name-substitution]
> utilization of the asterisk wildcard is constrained as per the following
> quote:
> {quote}The asterisk is recognized only if it is the last character in the
> link name.
> {quote}
> It is desirable that the configuration could handle a situation where there
> are multiple asterisks in use such as:
>
> |{color:#00}"tstGroup": {{color}|
> |{color:#00} "users": "tst@amq",{color}|
> |{color:#00} "sources": "abc.*,my.*.b2b.tst.*",{color}|
> |{color:#00} "targets": "abc.*,my.*.b2b.tst.*",{color}|
> |{color:#00} "remoteHosts": "*"{color}|
> |{color:#00}} {color}|
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #324: DISPATCH-976 - Fixed issue with policy vali...
GitHub user fgiorgetti opened a pull request: https://github.com/apache/qpid-dispatch/pull/324 DISPATCH-976 - Fixed issue with policy validation of allowed addresses You can merge this pull request into a Git repository by running: $ git pull https://github.com/fgiorgetti/qpid-dispatch fgiorgetti-DISPATCH-976-1 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/324.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #324 commit 1892f5dc68296e5b5ec107f6212e0e24f4b852e3 Author: Fernando Giorgetti Date: 2018-06-13T01:57:17Z DISPATCH-976 - Fixed issue with policy validation of allowed addresses --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-976) Allow policy for sources and targets to handle multiple wildcards
[
https://issues.apache.org/jira/browse/DISPATCH-976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510506#comment-16510506
]
ASF GitHub Bot commented on DISPATCH-976:
-
Github user fgiorgetti closed the pull request at:
https://github.com/apache/qpid-dispatch/pull/323
> Allow policy for sources and targets to handle multiple wildcards
> -
>
> Key: DISPATCH-976
> URL: https://issues.apache.org/jira/browse/DISPATCH-976
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Policy Engine
>Affects Versions: 1.0.1
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>Priority: Major
> Fix For: 1.2.0
>
>
> As per the [upstream policy
> documentation|https://github.com/apache/qpid-dispatch/blob/1.0.0/doc/book/policy.adoc]
> in the secion on [AMQP Source and Target Wildcard and Name
> Substitution|https://github.com/apache/qpid-dispatch/blob/1.0.0/doc/book/policy.adoc#amqp-source-and-target-wildcard-and-name-substitution]
> utilization of the asterisk wildcard is constrained as per the following
> quote:
> {quote}The asterisk is recognized only if it is the last character in the
> link name.
> {quote}
> It is desirable that the configuration could handle a situation where there
> are multiple asterisks in use such as:
>
> |{color:#00}"tstGroup": {{color}|
> |{color:#00} "users": "tst@amq",{color}|
> |{color:#00} "sources": "abc.*,my.*.b2b.tst.*",{color}|
> |{color:#00} "targets": "abc.*,my.*.b2b.tst.*",{color}|
> |{color:#00} "remoteHosts": "*"{color}|
> |{color:#00}} {color}|
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #323: DISPATCH-976 - Commenting last assert which...
Github user fgiorgetti closed the pull request at: https://github.com/apache/qpid-dispatch/pull/323 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-976) Allow policy for sources and targets to handle multiple wildcards
[
https://issues.apache.org/jira/browse/DISPATCH-976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510502#comment-16510502
]
ASF GitHub Bot commented on DISPATCH-976:
-
Github user fgiorgetti commented on the issue:
https://github.com/apache/qpid-dispatch/pull/323
I believe I found the reason for the failure. I will provide a new PR and
ask Chuck to review it.
> Allow policy for sources and targets to handle multiple wildcards
> -
>
> Key: DISPATCH-976
> URL: https://issues.apache.org/jira/browse/DISPATCH-976
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Policy Engine
>Affects Versions: 1.0.1
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>Priority: Major
> Fix For: 1.2.0
>
>
> As per the [upstream policy
> documentation|https://github.com/apache/qpid-dispatch/blob/1.0.0/doc/book/policy.adoc]
> in the secion on [AMQP Source and Target Wildcard and Name
> Substitution|https://github.com/apache/qpid-dispatch/blob/1.0.0/doc/book/policy.adoc#amqp-source-and-target-wildcard-and-name-substitution]
> utilization of the asterisk wildcard is constrained as per the following
> quote:
> {quote}The asterisk is recognized only if it is the last character in the
> link name.
> {quote}
> It is desirable that the configuration could handle a situation where there
> are multiple asterisks in use such as:
>
> |{color:#00}"tstGroup": {{color}|
> |{color:#00} "users": "tst@amq",{color}|
> |{color:#00} "sources": "abc.*,my.*.b2b.tst.*",{color}|
> |{color:#00} "targets": "abc.*,my.*.b2b.tst.*",{color}|
> |{color:#00} "remoteHosts": "*"{color}|
> |{color:#00}} {color}|
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch issue #323: DISPATCH-976 - Commenting last assert which is cau...
Github user fgiorgetti commented on the issue: https://github.com/apache/qpid-dispatch/pull/323 I believe I found the reason for the failure. I will provide a new PR and ask Chuck to review it. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1859) CLONE - [cpp] auto-accept over-writing user transfer state
[ https://issues.apache.org/jira/browse/PROTON-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway updated PROTON-1859: Description: The auto-accept functionality of the messaging_adpater is incorrectly setting the transfer state even if the user had already set it. It is checking for "settled" to decide if it should set state, but this is incorrect on the server side since the message may be locally but not remotely settled at this point. (was: The auto-accept functionality of the MessagingAdapter is incorrectly setting the transfer state even if the user had already set it. It is checking for "settled?" to decide if it should set state, but this is incorrect since the message may be locally but not remotely settled at this point.) > CLONE - [cpp] auto-accept over-writing user transfer state > -- > > Key: PROTON-1859 > URL: https://issues.apache.org/jira/browse/PROTON-1859 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: proton-c-0.23.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.24.0 > > > The auto-accept functionality of the messaging_adpater is incorrectly setting > the transfer state even if the user had already set it. It is checking for > "settled" to decide if it should set state, but this is incorrect on the > server side since the message may be locally but not remotely settled at this > point. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1859) [cpp] auto-accept over-writing user transfer state
[ https://issues.apache.org/jira/browse/PROTON-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway updated PROTON-1859: Summary: [cpp] auto-accept over-writing user transfer state (was: CLONE - [cpp] auto-accept over-writing user transfer state) > [cpp] auto-accept over-writing user transfer state > -- > > Key: PROTON-1859 > URL: https://issues.apache.org/jira/browse/PROTON-1859 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: proton-c-0.23.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.24.0 > > > The auto-accept functionality of the messaging_adpater is incorrectly setting > the transfer state even if the user had already set it. It is checking for > "settled" to decide if it should set state, but this is incorrect on the > server side since the message may be locally but not remotely settled at this > point. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1859) CLONE - [ruby] auto-accept over-writing user transfer state
Alan Conway created PROTON-1859: --- Summary: CLONE - [ruby] auto-accept over-writing user transfer state Key: PROTON-1859 URL: https://issues.apache.org/jira/browse/PROTON-1859 Project: Qpid Proton Issue Type: Bug Components: ruby-binding Affects Versions: proton-c-0.23.0 Reporter: Alan Conway Assignee: Alan Conway Fix For: proton-c-0.24.0 The auto-accept functionality of the MessagingAdapter is incorrectly setting the transfer state even if the user had already set it. It is checking for "settled?" to decide if it should set state, but this is incorrect since the message may be locally but not remotely settled at this point. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1859) CLONE - [cpp] auto-accept over-writing user transfer state
[ https://issues.apache.org/jira/browse/PROTON-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway updated PROTON-1859: Summary: CLONE - [cpp] auto-accept over-writing user transfer state (was: CLONE - [ruby] auto-accept over-writing user transfer state) > CLONE - [cpp] auto-accept over-writing user transfer state > -- > > Key: PROTON-1859 > URL: https://issues.apache.org/jira/browse/PROTON-1859 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: proton-c-0.23.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.24.0 > > > The auto-accept functionality of the MessagingAdapter is incorrectly setting > the transfer state even if the user had already set it. It is checking for > "settled?" to decide if it should set state, but this is incorrect since the > message may be locally but not remotely settled at this point. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-976) Allow policy for sources and targets to handle multiple wildcards
[
https://issues.apache.org/jira/browse/DISPATCH-976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510182#comment-16510182
]
ASF GitHub Bot commented on DISPATCH-976:
-
Github user codecov-io commented on the issue:
https://github.com/apache/qpid-dispatch/pull/323
#
[Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/323?src=pr=h1)
Report
> Merging
[#323](https://codecov.io/gh/apache/qpid-dispatch/pull/323?src=pr=desc) into
[master](https://codecov.io/gh/apache/qpid-dispatch/commit/8c7e87275fb481f25d8deaa4f639f3a4d1c532d9?src=pr=desc)
will **increase** coverage by `0.03%`.
> The diff coverage is `n/a`.
[](https://codecov.io/gh/apache/qpid-dispatch/pull/323?src=pr=tree)
```diff
@@Coverage Diff @@
## master #323 +/- ##
==
+ Coverage 86.55% 86.58% +0.03%
==
Files 69 69
Lines 1546615465 -1
==
+ Hits1338713391 +4
+ Misses 2079 2074 -5
```
| [Impacted
Files](https://codecov.io/gh/apache/qpid-dispatch/pull/323?src=pr=tree) |
Coverage Δ | |
|---|---|---|
|
[src/policy.c](https://codecov.io/gh/apache/qpid-dispatch/pull/323/diff?src=pr=tree#diff-c3JjL3BvbGljeS5j)
| `86.95% <ø> (+1.06%)` | :arrow_up: |
|
[src/router\_core/agent\_link.c](https://codecov.io/gh/apache/qpid-dispatch/pull/323/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2FnZW50X2xpbmsuYw==)
| `63.21% <0%> (-0.58%)` | :arrow_down: |
|
[src/router\_node.c](https://codecov.io/gh/apache/qpid-dispatch/pull/323/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9ub2RlLmM=)
| `94.57% <0%> (-0.15%)` | :arrow_down: |
|
[src/server.c](https://codecov.io/gh/apache/qpid-dispatch/pull/323/diff?src=pr=tree#diff-c3JjL3NlcnZlci5j)
| `87.73% <0%> (-0.12%)` | :arrow_down: |
|
[src/iterator.c](https://codecov.io/gh/apache/qpid-dispatch/pull/323/diff?src=pr=tree#diff-c3JjL2l0ZXJhdG9yLmM=)
| `86.8% <0%> (+0.19%)` | :arrow_up: |
|
[src/remote\_sasl.c](https://codecov.io/gh/apache/qpid-dispatch/pull/323/diff?src=pr=tree#diff-c3JjL3JlbW90ZV9zYXNsLmM=)
| `83.03% <0%> (+0.3%)` | :arrow_up: |
--
[Continue to review full report at
Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/323?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/323?src=pr=footer).
Last update
[8c7e872...fd7eda3](https://codecov.io/gh/apache/qpid-dispatch/pull/323?src=pr=lastupdated).
Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).
> Allow policy for sources and targets to handle multiple wildcards
> -
>
> Key: DISPATCH-976
> URL: https://issues.apache.org/jira/browse/DISPATCH-976
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Policy Engine
>Affects Versions: 1.0.1
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>Priority: Major
> Fix For: 1.2.0
>
>
> As per the [upstream policy
> documentation|https://github.com/apache/qpid-dispatch/blob/1.0.0/doc/book/policy.adoc]
> in the secion on [AMQP Source and Target Wildcard and Name
> Substitution|https://github.com/apache/qpid-dispatch/blob/1.0.0/doc/book/policy.adoc#amqp-source-and-target-wildcard-and-name-substitution]
> utilization of the asterisk wildcard is constrained as per the following
> quote:
> {quote}The asterisk is recognized only if it is the last character in the
> link name.
> {quote}
> It is desirable that the configuration could handle a situation where there
> are multiple asterisks in use such as:
>
> |{color:#00}"tstGroup": {{color}|
> |{color:#00} "users": "tst@amq",{color}|
> |{color:#00} "sources": "abc.*,my.*.b2b.tst.*",{color}|
> |{color:#00} "targets": "abc.*,my.*.b2b.tst.*",{color}|
> |{color:#00} "remoteHosts": "*"{color}|
> |{color:#00}} {color}|
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch issue #323: DISPATCH-976 - Commenting last assert which is cau...
Github user codecov-io commented on the issue: https://github.com/apache/qpid-dispatch/pull/323 # [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/323?src=pr=h1) Report > Merging [#323](https://codecov.io/gh/apache/qpid-dispatch/pull/323?src=pr=desc) into [master](https://codecov.io/gh/apache/qpid-dispatch/commit/8c7e87275fb481f25d8deaa4f639f3a4d1c532d9?src=pr=desc) will **increase** coverage by `0.03%`. > The diff coverage is `n/a`. [](https://codecov.io/gh/apache/qpid-dispatch/pull/323?src=pr=tree) ```diff @@Coverage Diff @@ ## master #323 +/- ## == + Coverage 86.55% 86.58% +0.03% == Files 69 69 Lines 1546615465 -1 == + Hits1338713391 +4 + Misses 2079 2074 -5 ``` | [Impacted Files](https://codecov.io/gh/apache/qpid-dispatch/pull/323?src=pr=tree) | Coverage Π| | |---|---|---| | [src/policy.c](https://codecov.io/gh/apache/qpid-dispatch/pull/323/diff?src=pr=tree#diff-c3JjL3BvbGljeS5j) | `86.95% <ø> (+1.06%)` | :arrow_up: | | [src/router\_core/agent\_link.c](https://codecov.io/gh/apache/qpid-dispatch/pull/323/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2FnZW50X2xpbmsuYw==) | `63.21% <0%> (-0.58%)` | :arrow_down: | | [src/router\_node.c](https://codecov.io/gh/apache/qpid-dispatch/pull/323/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9ub2RlLmM=) | `94.57% <0%> (-0.15%)` | :arrow_down: | | [src/server.c](https://codecov.io/gh/apache/qpid-dispatch/pull/323/diff?src=pr=tree#diff-c3JjL3NlcnZlci5j) | `87.73% <0%> (-0.12%)` | :arrow_down: | | [src/iterator.c](https://codecov.io/gh/apache/qpid-dispatch/pull/323/diff?src=pr=tree#diff-c3JjL2l0ZXJhdG9yLmM=) | `86.8% <0%> (+0.19%)` | :arrow_up: | | [src/remote\_sasl.c](https://codecov.io/gh/apache/qpid-dispatch/pull/323/diff?src=pr=tree#diff-c3JjL3JlbW90ZV9zYXNsLmM=) | `83.03% <0%> (+0.3%)` | :arrow_up: | -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/323?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/323?src=pr=footer). Last update [8c7e872...fd7eda3](https://codecov.io/gh/apache/qpid-dispatch/pull/323?src=pr=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments). --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #323: DISPATCH-976 - Commenting last assert which...
GitHub user fgiorgetti opened a pull request: https://github.com/apache/qpid-dispatch/pull/323 DISPATCH-976 - Commenting last assert which is causing router to crash You can merge this pull request into a Git repository by running: $ git pull https://github.com/fgiorgetti/qpid-dispatch fgiorgetti-DISPATCH-976-1 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/323.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #323 commit fd7eda39c245b57596841222c5db1d7c8581c86f Author: Fernando Giorgetti Date: 2018-06-12T20:35:33Z DISPATCH-976 - Commenting last assert which is causing router to crash --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-976) Allow policy for sources and targets to handle multiple wildcards
[
https://issues.apache.org/jira/browse/DISPATCH-976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510166#comment-16510166
]
ASF GitHub Bot commented on DISPATCH-976:
-
GitHub user fgiorgetti opened a pull request:
https://github.com/apache/qpid-dispatch/pull/323
DISPATCH-976 - Commenting last assert which is causing router to crash
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/fgiorgetti/qpid-dispatch
fgiorgetti-DISPATCH-976-1
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/qpid-dispatch/pull/323.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #323
commit fd7eda39c245b57596841222c5db1d7c8581c86f
Author: Fernando Giorgetti
Date: 2018-06-12T20:35:33Z
DISPATCH-976 - Commenting last assert which is causing router to crash
> Allow policy for sources and targets to handle multiple wildcards
> -
>
> Key: DISPATCH-976
> URL: https://issues.apache.org/jira/browse/DISPATCH-976
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Policy Engine
>Affects Versions: 1.0.1
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>Priority: Major
> Fix For: 1.2.0
>
>
> As per the [upstream policy
> documentation|https://github.com/apache/qpid-dispatch/blob/1.0.0/doc/book/policy.adoc]
> in the secion on [AMQP Source and Target Wildcard and Name
> Substitution|https://github.com/apache/qpid-dispatch/blob/1.0.0/doc/book/policy.adoc#amqp-source-and-target-wildcard-and-name-substitution]
> utilization of the asterisk wildcard is constrained as per the following
> quote:
> {quote}The asterisk is recognized only if it is the last character in the
> link name.
> {quote}
> It is desirable that the configuration could handle a situation where there
> are multiple asterisks in use such as:
>
> |{color:#00}"tstGroup": {{color}|
> |{color:#00} "users": "tst@amq",{color}|
> |{color:#00} "sources": "abc.*,my.*.b2b.tst.*",{color}|
> |{color:#00} "targets": "abc.*,my.*.b2b.tst.*",{color}|
> |{color:#00} "remoteHosts": "*"{color}|
> |{color:#00}} {color}|
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1354) Disable problematic SASL mechanisms if they are not explicitly enabled
[ https://issues.apache.org/jira/browse/PROTON-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510157#comment-16510157 ] ASF GitHub Bot commented on PROTON-1354: GitHub user astitcher opened a pull request: https://github.com/apache/qpid-proton/pull/148 PROTON-1354: Don't allow SASL mechanisms GSSAPI or GSS-SPNEGO by default Small change that fixes a pain point if you have kerberos on you client machine but aren't using it for proton. The SASL handling is changed so that if you want to use kerberos you now need to tell the pn_sasl_allowed_mechs() API on both the client and server that you allow GSSAPI and/or GSS-SPNEGO mechanisms (along with any other mechanisms you want). The logic here is that you are very unlikely to want GSSAPI unless you have specifically set it up and then you will know that and can allow it specifically. You can merge this pull request into a Git repository by running: $ git pull https://github.com/astitcher/qpid-proton proton-1354 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-proton/pull/148.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #148 commit bad63dc878856bd9fb657f03eb008cad02f44098 Author: Andrew Stitcher Date: 2018-06-12T20:17:42Z PROTON-1354: Don't allow SASL mechanisms GSSAPI or GSS-SPNEGO by default - If you want to use these mechanisms they must be explicitly set in the allowed mechanisms list for server and client that are connecting > Disable problematic SASL mechanisms if they are not explicitly enabled > -- > > Key: PROTON-1354 > URL: https://issues.apache.org/jira/browse/PROTON-1354 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: Justin Ross >Assignee: Andrew Stitcher >Priority: Major > Labels: sasl, usability > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-proton pull request #148: PROTON-1354: Don't allow SASL mechanisms GSSA...
GitHub user astitcher opened a pull request: https://github.com/apache/qpid-proton/pull/148 PROTON-1354: Don't allow SASL mechanisms GSSAPI or GSS-SPNEGO by default Small change that fixes a pain point if you have kerberos on you client machine but aren't using it for proton. The SASL handling is changed so that if you want to use kerberos you now need to tell the pn_sasl_allowed_mechs() API on both the client and server that you allow GSSAPI and/or GSS-SPNEGO mechanisms (along with any other mechanisms you want). The logic here is that you are very unlikely to want GSSAPI unless you have specifically set it up and then you will know that and can allow it specifically. You can merge this pull request into a Git repository by running: $ git pull https://github.com/astitcher/qpid-proton proton-1354 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-proton/pull/148.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #148 commit bad63dc878856bd9fb657f03eb008cad02f44098 Author: Andrew Stitcher Date: 2018-06-12T20:17:42Z PROTON-1354: Don't allow SASL mechanisms GSSAPI or GSS-SPNEGO by default - If you want to use these mechanisms they must be explicitly set in the allowed mechanisms list for server and client that are connecting --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1026) Router crashing when using sourcePattern/targetPattern with multiple patterns and one of them being user token when trying to open an unauthorized address
[
https://issues.apache.org/jira/browse/DISPATCH-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510093#comment-16510093
]
Fernando Giorgetti commented on DISPATCH-1026:
--
Just some additional information.
The router is crashing as code executes the "assert(false)" in the last else
statement of _qd_policy_approve_link_name_tree within src/policy.c.
> Router crashing when using sourcePattern/targetPattern with multiple patterns
> and one of them being user token when trying to open an unauthorized address
> --
>
> Key: DISPATCH-1026
> URL: https://issues.apache.org/jira/browse/DISPATCH-1026
> Project: Qpid Dispatch
> Issue Type: Bug
>Reporter: Fernando Giorgetti
>Priority: Major
>
> When you define a vhost policy with a targetPattern or a sourcePattern using
> multiple addresses and one of them being the ${user} (user token), and if you
> try to connect to an unauthorized address, the router crashes.
> Example:
> targetPattern: queue/${user}, sample, address
>
> If you try to connect a sender to an address, like, "notauthorized" then the
> router crashes with:
> qdrouterd: /tmp/qpid-dispatch/src/policy.c:848:
> _qd_policy_approve_link_name_tree: Assertion `0' failed.
> Aborted (core dumped)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDJMS-394) Completion Listener singaled in error when send blocked waiting for failover
[ https://issues.apache.org/jira/browse/QPIDJMS-394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-394. -- Resolution: Fixed > Completion Listener singaled in error when send blocked waiting for failover > > > Key: QPIDJMS-394 > URL: https://issues.apache.org/jira/browse/QPIDJMS-394 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.33.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Major > Fix For: 0.34.0 > > > If a send is issued using a completion listener and it blocks waiting for > credit or just happens to land in the Failover provider at the right moment > during connection loss the send will be held in the failover provider and > reissued on reconnect. During reconnection processing inflight async > completion sends are failed as their state is not recoverable and this can > lead to a signal of failed send to the blocked completion send attempt in > error. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1003) Enable console support for connecting to listener configured with saslMechanisms other than ANONYMOUS
[ https://issues.apache.org/jira/browse/DISPATCH-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510044#comment-16510044 ] ASF subversion and git services commented on DISPATCH-1003: --- Commit 8c7e87275fb481f25d8deaa4f639f3a4d1c532d9 in qpid-dispatch's branch refs/heads/master from [~eallen] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=8c7e872 ] DISPATCH-1003 Fixing disconnect between form and options sent to connect. > Enable console support for connecting to listener configured with > saslMechanisms other than ANONYMOUS > - > > Key: DISPATCH-1003 > URL: https://issues.apache.org/jira/browse/DISPATCH-1003 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 1.1.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Major > > For the console, this boils down to: > * prompt for a username / password on the connect page > * pass the username / password to the connect request > There will be a different Jira to allow the http enabled listener to use the > username/password and authenticate. Currently authentication works if you go > though a non-http listener, but not a http enabled listener. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-394) Completion Listener singaled in error when send blocked waiting for failover
Timothy Bish created QPIDJMS-394: Summary: Completion Listener singaled in error when send blocked waiting for failover Key: QPIDJMS-394 URL: https://issues.apache.org/jira/browse/QPIDJMS-394 Project: Qpid JMS Issue Type: Bug Components: qpid-jms-client Affects Versions: 0.33.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.34.0 If a send is issued using a completion listener and it blocks waiting for credit or just happens to land in the Failover provider at the right moment during connection loss the send will be held in the failover provider and reissued on reconnect. During reconnection processing inflight async completion sends are failed as their state is not recoverable and this can lead to a signal of failed send to the blocked completion send attempt in error. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-394) Completion Listener singaled in error when send blocked waiting for failover
[ https://issues.apache.org/jira/browse/QPIDJMS-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510073#comment-16510073 ] ASF subversion and git services commented on QPIDJMS-394: - Commit e676248c74e9747031e5a89a640442bb51ffcb28 in qpid-jms's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=e676248 ] QPIDJMS-394 Fix failover wrongly signalling async completion Ensure that an inflight async completion that is held in the Failover provider is not signaled as failed by the session during connection recovery. > Completion Listener singaled in error when send blocked waiting for failover > > > Key: QPIDJMS-394 > URL: https://issues.apache.org/jira/browse/QPIDJMS-394 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.33.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Major > Fix For: 0.34.0 > > > If a send is issued using a completion listener and it blocks waiting for > credit or just happens to land in the Failover provider at the right moment > during connection loss the send will be held in the failover provider and > reissued on reconnect. During reconnection processing inflight async > completion sends are failed as their state is not recoverable and this can > lead to a signal of failed send to the blocked completion send attempt in > error. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1853) [Python] Remove pn_url use from Url class
[ https://issues.apache.org/jira/browse/PROTON-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510042#comment-16510042 ] ASF subversion and git services commented on PROTON-1853: - Commit ccfd19ce2a296482e1b8f9f378c8f90050048e76 in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=ccfd19c ] PROTON-1853: [Python] Fix Url parsing to cope with '://' in path > [Python] Remove pn_url use from Url class > - > > Key: PROTON-1853 > URL: https://issues.apache.org/jira/browse/PROTON-1853 > Project: Qpid Proton > Issue Type: Improvement > Components: python-binding >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (DISPATCH-1004) Enable support for connecting to http enabled listener configured with saslMechanisms other than ANONYMOUS
[ https://issues.apache.org/jira/browse/DISPATCH-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen closed DISPATCH-1004. -- Resolution: Not A Bug The problem was in the console's javascript code. This was fixed in DISPATCH-1003 > Enable support for connecting to http enabled listener configured with > saslMechanisms other than ANONYMOUS > -- > > Key: DISPATCH-1004 > URL: https://issues.apache.org/jira/browse/DISPATCH-1004 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.1.0 >Reporter: Ernest Allen >Priority: Major > > Authentication fails when connecting to an http enabled listener that has > authenticatePeer: true with a router configured with sasl authentication. > The log messages are: > 2018-05-18 07:36:27.347973 -0400 SERVER (debug) [2] upgraded HTTP connection > from 127.0.0.1 to AMQPWS > (/home/eallen/workspace/qpid-dispatch/src/http-libwebsockets.c:402) > 2018-05-18 07:36:27.348025 -0400 POLICY (trace) ALLOW Connection '127.0.0.1' > based on global connection count. nConnections= 1 > (/home/eallen/workspace/qpid-dispatch/src/policy.c:204) > 2018-05-18 07:36:27.348041 -0400 SERVER (info) Accepted connection to > 0.0.0.0:29315 from 127.0.0.1 > (/home/eallen/workspace/qpid-dispatch/src/server.c:656) > 2018-05-18 07:36:27.348400 -0400 SERVER (trace) [2]: <- EOS > (/home/eallen/workspace/qpid-dispatch/src/server.c:103) > 2018-05-18 07:36:27.348434 -0400 SERVER (info) Connection from 127.0.0.1 (to > 0.0.0.0:29315) failed: amqp:connection:policy-error Client skipped > authentication - forbidden > (/home/eallen/workspace/qpid-dispatch/src/server.c:920) > 2018-05-18 07:36:27.348447 -0400 SERVER (trace) [2]: -> EOS > (/home/eallen/workspace/qpid-dispatch/src/server.c:103) > 2018-05-18 07:36:27.348462 -0400 POLICY (debug) Connection '127.0.0.1' closed > with resources n_sessions=0, n_senders=0, n_receivers=0. nConnections= 0. > (/home/eallen/workspace/qpid-dispatch/src/policy.c:249) > Note: To test this I did the following: > * run the router's system tests > * cd > build/tests/system_test.dir/system_tests_sasl_plain/RouterTestPlainSasl/setUpClass > * edit the X.conf file to include a listener with http: true on a new port > and start a router using X.conf > * attempt to connect to the new port using the latest console with > [t...@domain.com|mailto:t...@domain.com] / password > * view the X.log file to see the above error output > Authentication succeeds when connecting to that same router using a listener > that is not http enabled. > To verify the sasl setup, using that same router, run the following command: > qdstat -b 0.0.0.0:29215 -c --sasl-mechanisms=PLAIN > --sasl-username=t...@domain.com --sasl-password=password > The output is: > Connections > id host container role dir > security authentication tenant > > === > 6247 127.0.0.1:44554 5972a5a1-aa46-4b36-8932-8f090307f66a normal in > no-security t...@domain.com(PLAIN) > I verified that the rhea.js library used by the console is passing the > username/password by running rhea's test "simple_sasl_client.js" under nodejs > against the above router's non-http enabled port. The connection succeeds. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1027) Cannot connect to router using WS when amqp protocol is specified
[
https://issues.apache.org/jira/browse/DISPATCH-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510026#comment-16510026
]
Gordon Sim commented on DISPATCH-1027:
--
I can't reproduce this. the cli-rhea-sender example in description seems to
work for me against router on master and 1.1.0. the client.html exaple from
rhea works as is (which include those protocols). I modified the client.js to
also include binary and amqp protocols and it also works.
> Cannot connect to router using WS when amqp protocol is specified
> -
>
> Key: DISPATCH-1027
> URL: https://issues.apache.org/jira/browse/DISPATCH-1027
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.1.0
> Environment: client - rhea
> router - 1.1.0-RC3 (same issue is with previous versions)
>Reporter: David Kornel
>Priority: Major
>
> I cannot connect using websocket connection to router when http is enabled in
> listener when 'amqp' protocol is specified in websocket connection. I can
> only do that when only 'binary' is specified without 'amqp'. Otherwise I
> cannot connect to artemis using websocket when amqp is not specified.
> Router:
> {code:java}
> SERVER (info) Connection from 127.0.0.1 (to 0.0.0.0:5673) failed:
> amqp:connection:framing-error No valid protocol header found
> {code}
>
> Reproducer
>
> {code:java}
> npm install cli-rhea -g
> cli-rhea-sender --broker localhost:5673 --count 1 --conn-ws true
> --conn-ws-protocols binary amqp{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1008) Router should preserve original connection information when attempting to make failover connections
[
https://issues.apache.org/jira/browse/DISPATCH-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509973#comment-16509973
]
ASF GitHub Bot commented on DISPATCH-1008:
--
GitHub user ganeshmurthy opened a pull request:
https://github.com/apache/qpid-dispatch/pull/322
DISPATCH-1008 - Original connection information is preserved in the f…
…ailover list and a connection is attempted via round robin when the router
fails over
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-1008-1
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/qpid-dispatch/pull/322.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #322
commit 1d72de1edffee463d221c5d2a0d552ae26c3a28d
Author: Ganesh Murthy
Date: 2018-05-25T19:07:44Z
DISPATCH-1008 - Original connection information is preserved in the
failover list and a connection is attempted via round robin when the router
fails over
> Router should preserve original connection information when attempting to
> make failover connections
> ---
>
> Key: DISPATCH-1008
> URL: https://issues.apache.org/jira/browse/DISPATCH-1008
> Project: Qpid Dispatch
> Issue Type: Bug
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
> Attachments: broker-slave.xml, broker.xml, qdrouterd-failover.conf
>
>
> # Start artemis master and slave brokers and the router with the attached
> config files.
> # Notice that the router receives an open frame from the master broker with
> the following failover information
> #
> {noformat}
> 2018-05-22 22:11:11.830106 -0230 SERVER (trace) [1]:0 <- @open(16)
> [container-id="localhost", max-frame-size=4294967295, channel-max=65535,
> idle-time-out=3,
> offered-capabilities=@PN_SYMBOL[:"sole-connection-for-container",
> :"DELAYED_DELIVERY", :"SHARED-SUBS", :"ANONYMOUS-RELAY"],
> properties={:product="apache-activemq-artemis",
> :"failover-server-list"=[{:hostname="0.0.0.8", :scheme="amqp", :port=61617,
> :"network-host"="0.0.0.0"}]"}]{noformat}
>
> # Now, kill the master broker and notice that the router correctly fails
> over to the slave broker. But the slave broker does not provide any failover
> information in its open frame and hence the router erases its original master
> broker connection information
> # When the master broker is now restarted and the slave broker is killed,
> the router attempts to repeatedly connect only to the slave broker but never
> attempts a connection to the master broker.
> # If the router did not erase its failover list but preserved the original
> master connection information, it would have connected the master broker.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #322: DISPATCH-1008 - Original connection informa...
GitHub user ganeshmurthy opened a pull request: https://github.com/apache/qpid-dispatch/pull/322 DISPATCH-1008 - Original connection information is preserved in the f⦠â¦ailover list and a connection is attempted via round robin when the router fails over You can merge this pull request into a Git repository by running: $ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-1008-1 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/322.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #322 commit 1d72de1edffee463d221c5d2a0d552ae26c3a28d Author: Ganesh Murthy Date: 2018-05-25T19:07:44Z DISPATCH-1008 - Original connection information is preserved in the failover list and a connection is attempted via round robin when the router fails over --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1008) Router should preserve original connection information when attempting to make failover connections
[
https://issues.apache.org/jira/browse/DISPATCH-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509968#comment-16509968
]
ASF GitHub Bot commented on DISPATCH-1008:
--
Github user ganeshmurthy closed the pull request at:
https://github.com/apache/qpid-dispatch/pull/310
> Router should preserve original connection information when attempting to
> make failover connections
> ---
>
> Key: DISPATCH-1008
> URL: https://issues.apache.org/jira/browse/DISPATCH-1008
> Project: Qpid Dispatch
> Issue Type: Bug
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
> Attachments: broker-slave.xml, broker.xml, qdrouterd-failover.conf
>
>
> # Start artemis master and slave brokers and the router with the attached
> config files.
> # Notice that the router receives an open frame from the master broker with
> the following failover information
> #
> {noformat}
> 2018-05-22 22:11:11.830106 -0230 SERVER (trace) [1]:0 <- @open(16)
> [container-id="localhost", max-frame-size=4294967295, channel-max=65535,
> idle-time-out=3,
> offered-capabilities=@PN_SYMBOL[:"sole-connection-for-container",
> :"DELAYED_DELIVERY", :"SHARED-SUBS", :"ANONYMOUS-RELAY"],
> properties={:product="apache-activemq-artemis",
> :"failover-server-list"=[{:hostname="0.0.0.8", :scheme="amqp", :port=61617,
> :"network-host"="0.0.0.0"}]"}]{noformat}
>
> # Now, kill the master broker and notice that the router correctly fails
> over to the slave broker. But the slave broker does not provide any failover
> information in its open frame and hence the router erases its original master
> broker connection information
> # When the master broker is now restarted and the slave broker is killed,
> the router attempts to repeatedly connect only to the slave broker but never
> attempts a connection to the master broker.
> # If the router did not erase its failover list but preserved the original
> master connection information, it would have connected the master broker.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #310: DISPATCH-1008 - Original connection informa...
Github user ganeshmurthy closed the pull request at: https://github.com/apache/qpid-dispatch/pull/310 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1025) User token not being replaced properly on a vhost policy when defined in the prefix or suffix
[
https://issues.apache.org/jira/browse/DISPATCH-1025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-1025.
-
Resolution: Fixed
> User token not being replaced properly on a vhost policy when defined in the
> prefix or suffix
> -
>
> Key: DISPATCH-1025
> URL: https://issues.apache.org/jira/browse/DISPATCH-1025
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Policy Engine
>Reporter: Fernando Giorgetti
>Priority: Major
> Fix For: 1.2.0
>
>
> When a vhost policy is defined with a sources/sourcePattern and/or
> targets/targetPattern containing a user token (${user}), the token is just
> being replaced properly when using: sources/targets and only if it is
> embedded (not being in prefix or suffix).
> This causes policy validation to reject link attachment to the related
> address.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1025) User token not being replaced properly on a vhost policy when defined in the prefix or suffix
[
https://issues.apache.org/jira/browse/DISPATCH-1025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy updated DISPATCH-1025:
Fix Version/s: 1.2.0
> User token not being replaced properly on a vhost policy when defined in the
> prefix or suffix
> -
>
> Key: DISPATCH-1025
> URL: https://issues.apache.org/jira/browse/DISPATCH-1025
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Policy Engine
>Reporter: Fernando Giorgetti
>Priority: Major
> Fix For: 1.2.0
>
>
> When a vhost policy is defined with a sources/sourcePattern and/or
> targets/targetPattern containing a user token (${user}), the token is just
> being replaced properly when using: sources/targets and only if it is
> embedded (not being in prefix or suffix).
> This causes policy validation to reject link attachment to the related
> address.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-976) Allow policy for sources and targets to handle multiple wildcards
[
https://issues.apache.org/jira/browse/DISPATCH-976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509951#comment-16509951
]
ASF subversion and git services commented on DISPATCH-976:
--
Commit 2f3d32d5b8a72cb9104bdf315335822af0a50e47 in qpid-dispatch's branch
refs/heads/master from [~fgiorget]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=2f3d32d ]
DISPATCH-976 - System test to validate vhost policies on source and target
addresses. This closes #320
> Allow policy for sources and targets to handle multiple wildcards
> -
>
> Key: DISPATCH-976
> URL: https://issues.apache.org/jira/browse/DISPATCH-976
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Policy Engine
>Affects Versions: 1.0.1
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>Priority: Major
> Fix For: 1.2.0
>
>
> As per the [upstream policy
> documentation|https://github.com/apache/qpid-dispatch/blob/1.0.0/doc/book/policy.adoc]
> in the secion on [AMQP Source and Target Wildcard and Name
> Substitution|https://github.com/apache/qpid-dispatch/blob/1.0.0/doc/book/policy.adoc#amqp-source-and-target-wildcard-and-name-substitution]
> utilization of the asterisk wildcard is constrained as per the following
> quote:
> {quote}The asterisk is recognized only if it is the last character in the
> link name.
> {quote}
> It is desirable that the configuration could handle a situation where there
> are multiple asterisks in use such as:
>
> |{color:#00}"tstGroup": {{color}|
> |{color:#00} "users": "tst@amq",{color}|
> |{color:#00} "sources": "abc.*,my.*.b2b.tst.*",{color}|
> |{color:#00} "targets": "abc.*,my.*.b2b.tst.*",{color}|
> |{color:#00} "remoteHosts": "*"{color}|
> |{color:#00}} {color}|
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-976) Allow policy for sources and targets to handle multiple wildcards
[
https://issues.apache.org/jira/browse/DISPATCH-976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509956#comment-16509956
]
ASF GitHub Bot commented on DISPATCH-976:
-
Github user asfgit closed the pull request at:
https://github.com/apache/qpid-dispatch/pull/320
> Allow policy for sources and targets to handle multiple wildcards
> -
>
> Key: DISPATCH-976
> URL: https://issues.apache.org/jira/browse/DISPATCH-976
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Policy Engine
>Affects Versions: 1.0.1
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>Priority: Major
> Fix For: 1.2.0
>
>
> As per the [upstream policy
> documentation|https://github.com/apache/qpid-dispatch/blob/1.0.0/doc/book/policy.adoc]
> in the secion on [AMQP Source and Target Wildcard and Name
> Substitution|https://github.com/apache/qpid-dispatch/blob/1.0.0/doc/book/policy.adoc#amqp-source-and-target-wildcard-and-name-substitution]
> utilization of the asterisk wildcard is constrained as per the following
> quote:
> {quote}The asterisk is recognized only if it is the last character in the
> link name.
> {quote}
> It is desirable that the configuration could handle a situation where there
> are multiple asterisks in use such as:
>
> |{color:#00}"tstGroup": {{color}|
> |{color:#00} "users": "tst@amq",{color}|
> |{color:#00} "sources": "abc.*,my.*.b2b.tst.*",{color}|
> |{color:#00} "targets": "abc.*,my.*.b2b.tst.*",{color}|
> |{color:#00} "remoteHosts": "*"{color}|
> |{color:#00}} {color}|
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1025) User token not being replaced properly on a vhost policy when defined in the prefix or suffix
[
https://issues.apache.org/jira/browse/DISPATCH-1025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509950#comment-16509950
]
ASF subversion and git services commented on DISPATCH-1025:
---
Commit 4ce42abcac7424251ff0efe35a28500af8ef547a in qpid-dispatch's branch
refs/heads/master from [~fgiorget]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=4ce42ab ]
DISPATCH-1025 - Fixes user token replacement used in prefix or suffix. This
closes #319
> User token not being replaced properly on a vhost policy when defined in the
> prefix or suffix
> -
>
> Key: DISPATCH-1025
> URL: https://issues.apache.org/jira/browse/DISPATCH-1025
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Policy Engine
>Reporter: Fernando Giorgetti
>Priority: Major
>
> When a vhost policy is defined with a sources/sourcePattern and/or
> targets/targetPattern containing a user token (${user}), the token is just
> being replaced properly when using: sources/targets and only if it is
> embedded (not being in prefix or suffix).
> This causes policy validation to reject link attachment to the related
> address.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1025) User token not being replaced properly on a vhost policy when defined in the prefix or suffix
[
https://issues.apache.org/jira/browse/DISPATCH-1025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509955#comment-16509955
]
ASF GitHub Bot commented on DISPATCH-1025:
--
Github user asfgit closed the pull request at:
https://github.com/apache/qpid-dispatch/pull/319
> User token not being replaced properly on a vhost policy when defined in the
> prefix or suffix
> -
>
> Key: DISPATCH-1025
> URL: https://issues.apache.org/jira/browse/DISPATCH-1025
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Policy Engine
>Reporter: Fernando Giorgetti
>Priority: Major
>
> When a vhost policy is defined with a sources/sourcePattern and/or
> targets/targetPattern containing a user token (${user}), the token is just
> being replaced properly when using: sources/targets and only if it is
> embedded (not being in prefix or suffix).
> This causes policy validation to reject link attachment to the related
> address.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #319: DISPATCH-1025 - Fixes user token replacemen...
Github user asfgit closed the pull request at: https://github.com/apache/qpid-dispatch/pull/319 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #320: DISPATCH-976 - System test to validate vhos...
Github user asfgit closed the pull request at: https://github.com/apache/qpid-dispatch/pull/320 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[ANNOUNCE] Apache Qpid Dispatch 1.1.0 released
The Apache Qpid (http://qpid.apache.org) community is pleased to announce the immediate availability of Apache Qpid Dispatch 1.1.0 Qpid Dispatch is a router for the Advanced Message Queuing Protocol 1.0 (AMQP 1.0, ISO/IEC 19464, http://www.amqp.org). It provides a flexible and scalable interconnect between AMQP endpoints, whether they be clients, brokers, or other AMQP-enabled services. The release is available now from our website: https://qpid.apache.org/releases/qpid-dispatch-1.1.0/index.html Release notes can be found at: http://qpid.apache.org/releases/qpid-dispatch-1.1.0/release-notes.html Thanks to all involved. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDJMS-393) Async Completion sends not signaled when sent while TX is in doubt
[ https://issues.apache.org/jira/browse/QPIDJMS-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-393. -- Resolution: Fixed > Async Completion sends not signaled when sent while TX is in doubt > -- > > Key: QPIDJMS-393 > URL: https://issues.apache.org/jira/browse/QPIDJMS-393 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.33.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Major > Fix For: 0.34.0 > > > After a failover occurs while an active TX is in play the TX will be placed > in an in-doubt state and all sends that are made prior to a commit or > rollback will be effectively turned into a no-op. If however an async > completion send is done the code does not signal the onCompletion event of > the given CompletionListener. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-393) Async Completion sends not signaled when sent while TX is in doubt
[ https://issues.apache.org/jira/browse/QPIDJMS-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509888#comment-16509888 ] ASF subversion and git services commented on QPIDJMS-393: - Commit 7226605a7f478ce45a858a6791f961511d0e2180 in qpid-jms's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=7226605 ] QPIDJMS-393 Signal async completion when TX is in-doubt Send an onCompletion event to any caller using the async completion API for sending messages when a TX has been tagged as in-doubt > Async Completion sends not signaled when sent while TX is in doubt > -- > > Key: QPIDJMS-393 > URL: https://issues.apache.org/jira/browse/QPIDJMS-393 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.33.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Major > Fix For: 0.34.0 > > > After a failover occurs while an active TX is in play the TX will be placed > in an in-doubt state and all sends that are made prior to a commit or > rollback will be effectively turned into a no-op. If however an async > completion send is done the code does not signal the onCompletion event of > the given CompletionListener. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1003) Enable console support for connecting to listener configured with saslMechanisms other than ANONYMOUS
[ https://issues.apache.org/jira/browse/DISPATCH-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509882#comment-16509882 ] ASF subversion and git services commented on DISPATCH-1003: --- Commit 374bb687ea80a6c0dfa44b1d408c48c38271b699 in qpid-dispatch's branch refs/heads/master from [~eallen] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=374bb68 ] DISPATCH-1003 Pass username/password into connect call for console > Enable console support for connecting to listener configured with > saslMechanisms other than ANONYMOUS > - > > Key: DISPATCH-1003 > URL: https://issues.apache.org/jira/browse/DISPATCH-1003 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 1.1.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Major > > For the console, this boils down to: > * prompt for a username / password on the connect page > * pass the username / password to the connect request > There will be a different Jira to allow the http enabled listener to use the > username/password and authenticate. Currently authentication works if you go > though a non-http listener, but not a http enabled listener. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-393) Async Completion sends not signaled when sent while TX is in doubt
Timothy Bish created QPIDJMS-393: Summary: Async Completion sends not signaled when sent while TX is in doubt Key: QPIDJMS-393 URL: https://issues.apache.org/jira/browse/QPIDJMS-393 Project: Qpid JMS Issue Type: Bug Components: qpid-jms-client Affects Versions: 0.33.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.34.0 After a failover occurs while an active TX is in play the TX will be placed in an in-doubt state and all sends that are made prior to a commit or rollback will be effectively turned into a no-op. If however an async completion send is done the code does not signal the onCompletion event of the given CompletionListener. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1035) pn_connection_wake() doesn't have any effect on websockets connections
Gordon Sim created DISPATCH-1035: Summary: pn_connection_wake() doesn't have any effect on websockets connections Key: DISPATCH-1035 URL: https://issues.apache.org/jira/browse/DISPATCH-1035 Project: Qpid Dispatch Issue Type: Bug Reporter: Gordon Sim This makes using the sasl delegation plugin over websockets slow as it relies on the timeout to move through the stages. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1034) saslPlugin option does not work with http option in listener
[ https://issues.apache.org/jira/browse/DISPATCH-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509833#comment-16509833 ] Gordon Sim commented on DISPATCH-1034: -- See also DISPATCH-1035 > saslPlugin option does not work with http option in listener > > > Key: DISPATCH-1034 > URL: https://issues.apache.org/jira/browse/DISPATCH-1034 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: Gordon Sim >Assignee: Gordon Sim >Priority: Major > Fix For: 1.2.0 > > > If you have a listener configured to accept websockets, and want to use the > sasl-delegation plugin to some central auth service, wesocket connections to > that listener cannot be authenticated. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1034) saslPlugin option does not work with http option in listener
[ https://issues.apache.org/jira/browse/DISPATCH-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved DISPATCH-1034. -- Resolution: Fixed > saslPlugin option does not work with http option in listener > > > Key: DISPATCH-1034 > URL: https://issues.apache.org/jira/browse/DISPATCH-1034 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: Gordon Sim >Assignee: Gordon Sim >Priority: Major > Fix For: 1.2.0 > > > If you have a listener configured to accept websockets, and want to use the > sasl-delegation plugin to some central auth service, wesocket connections to > that listener cannot be authenticated. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1034) saslPlugin option does not work with http option in listener
[ https://issues.apache.org/jira/browse/DISPATCH-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509823#comment-16509823 ] ASF subversion and git services commented on DISPATCH-1034: --- Commit 403f35c503561a5e540c57e086424f9793d21e7f in qpid-dispatch's branch refs/heads/master from Gordon Sim [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=403f35c ] DISPATCH-1034: pass proactor to use in to remote_sasl plugin > saslPlugin option does not work with http option in listener > > > Key: DISPATCH-1034 > URL: https://issues.apache.org/jira/browse/DISPATCH-1034 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: Gordon Sim >Assignee: Gordon Sim >Priority: Major > Fix For: 1.2.0 > > > If you have a listener configured to accept websockets, and want to use the > sasl-delegation plugin to some central auth service, wesocket connections to > that listener cannot be authenticated. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #321: NO-JIRA: enable code coverage report in tra...
Github user asfgit closed the pull request at: https://github.com/apache/qpid-dispatch/pull/321 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch issue #321: NO-JIRA: enable code coverage report in travis
Github user codecov-io commented on the issue: https://github.com/apache/qpid-dispatch/pull/321 # [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/321?src=pr=h1) Report > :exclamation: No coverage uploaded for pull request base (`master@13c2107`). [Click here to learn what that means](https://docs.codecov.io/docs/error-reference#section-missing-base-commit). > The diff coverage is `n/a`. [](https://codecov.io/gh/apache/qpid-dispatch/pull/321?src=pr=tree) ```diff @@ Coverage Diff@@ ## master#321 +/- ## Coverage ? 86.5% Files ? 69 Lines ? 15466 Branches ? 0 Hits ? 13379 Misses?2087 Partials ? 0 ``` -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/321?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/321?src=pr=footer). Last update [13c2107...99e3694](https://codecov.io/gh/apache/qpid-dispatch/pull/321?src=pr=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments). --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #321: NO-JIRA: enable code coverage report in tra...
GitHub user kgiusti opened a pull request: https://github.com/apache/qpid-dispatch/pull/321 NO-JIRA: enable code coverage report in travis This patch enables code coverage reporting on travis. If the build + tests are successful, at the end of the output log a url will be printed. That url can be used to view the coverage report. Example: ==> Uploading reports url: https://codecov.io query: branch=travis-coverage=99e369453e37f96268e8b08b340b78dd616c2673=42.1_urlkgiusti%2Fdispatch=travis==false=391325606 -> Pinging Codecov -> Uploading -> View reports at https://codecov.io/github/kgiusti/dispatch/commit/99e369453e37f96268e8b08b340b78dd616c2673 Open the "View reports" link in a browser, and click on the Files header for the coverage results. You can merge this pull request into a Git repository by running: $ git pull https://github.com/kgiusti/dispatch travis-coverage Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/321.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #321 commit 99e369453e37f96268e8b08b340b78dd616c2673 Author: Kenneth Giusti Date: 2018-06-12T15:30:49Z NO-JIRA: enable code coverage report in travis --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-392) Stalled Service Bus Subscriptions, Reconnect Loops
[
https://issues.apache.org/jira/browse/QPIDJMS-392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509733#comment-16509733
]
Paul Rogalinski commented on QPIDJMS-392:
-
Sorry for not taking that issue onto the mailing list first, I followed the
directions at
[https://qpid.apache.org/issues.html|https://qpid.apache.org/issues.html#report-a-bug]
I will be collecting more logs as you suggested and update the issue
accordingly.
Thank you for your time!
> Stalled Service Bus Subscriptions, Reconnect Loops
> --
>
> Key: QPIDJMS-392
> URL: https://issues.apache.org/jira/browse/QPIDJMS-392
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.32.0
> Environment: * Azure App Service
> * Spring 1.5.12 via embedded web server / standalone
> * java.runtime.version "1.8.0_144-b01"
> * java.vm.version "25.144-b01"
> * java.vm.vendor "Azul Systems, Inc."
> * os.arch "amd64"
> * os.name "Windows Server 2016"
>Reporter: Paul Rogalinski
>Priority: Major
> Attachments: qpid-log.txt
>
>
> We are experiencing connection recovery loops after an random (hours to days)
> amount of time on JMS connection subscribed to a Service Bus Topic via
> (durable) Subscription. The application does connect to two different service
> bus instances at the same time.
> We had to use the failover:(amqp:...) URL pattern in order to actually see
> something in the log files as the FailoverProvider is a bit more verbose
> (TRACE level). When using plain ampqs:// connection URL pattern the only way
> to tell a hanging/stalled subscription was to monitor the number of
> active/unconsumed Messages in a Service Bus' Subscription using a different
> client. Regardless of the Provider implementation, the problem of stalled
> subscriptions persisted.
> Log observations so far:
> After an initial disconnect:
> {code:java}
> o.a.qpid.jms.provider.amqp.AmqpProvider : New Proton Event:
> CONNECTION_REMOTE_CLOSE
> (...)
> Failover: the provider reports failure: The connection was inactive for more
> than the allowed 30 milliseconds and is closed by container
> 'LinkTracker'. TrackingId:c2925ed17c9549b29a825cc581852d1a_G6,
> SystemTracker:gateway9, Timestamp:5/1/2018 6:11:44 PM [condition =
> amqp:connection:forced]
> {code}
> the application will enter into a reconnect/connection recovery loop with an
> interval of one minute.
> {code:java}
> 18:11:44.670Z Failover: the provider reports failure: The connection was
> inactive for more than the allowed 30 milliseconds and is closed by
> container 'LinkTracker'. TrackingId:c2925ed17c9549b29a825cc581852d1a_G6,
> SystemTracker:gateway9, Timestamp:5/1/2018 6:11:44 PM [condition =
> amqp:connection:forced]
> 18:12:44.789Z Failover: the provider reports failure: The connection was
> inactive for more than the allowed 6 milliseconds and is closed by
> container 'LinkTracker'. TrackingId:50b008fdb56f443b947d76ded87691a9_G5,
> SystemTracker:gateway9, Timestamp:5/1/2018 6:12:44 PM [condition =
> amqp:connection:forced]
> 18:13:44.918Z Failover: the provider reports failure: The connection was
> inactive for more than the allowed 6 milliseconds and is closed by
> container 'LinkTracker'. TrackingId:a2832475e8ab4702b6189d9218588132_G15,
> SystemTracker:gateway9, Timestamp:5/1/2018 6:13:44 PM [condition =
> amqp:connection:forced]
> {code}
> In between we see the connection being recovered along with log messages as:
> {code:java}
> org.apache.qpid.jms.JmsConnection : Connection
> ID:8061906b-13e9-46a3-b6d0-fd227b339f67:1 is finalizing recovery
> {code}
> followed by
> {code:java}
> o.a.qpid.jms.provider.amqp.AmqpProvider : New Proton Event:
> SESSION_REMOTE_CLOSE
> {code}
> after a minute.
> A full cycle is attached in the log file, URLs are anonymized.
> In general we can see the following sequence of Proton-Events repeating:
> {code:java}
> 23:58:53.676Z CONNECTION_INIT
> 23:58:53.722Z CONNECTION_LOCAL_OPEN
> 23:58:53.722Z CONNECTION_REMOTE_OPEN
> 23:58:53.722Z SESSION_INIT
> 23:58:53.722Z SESSION_LOCAL_OPEN
> 23:58:53.738Z SESSION_REMOTE_OPEN
> 23:59:53.690Z SESSION_REMOTE_CLOSE
> 23:59:53.690Z SESSION_LOCAL_CLOSE
> 23:59:53.690Z SESSION_FINAL
> 23:59:53.706Z CONNECTION_REMOTE_CLOSE
> 23:59:53.706Z TRANSPORT_TAIL_CLOSED
> 23:59:53.706Z CONNECTION_LOCAL_CLOSE
> 23:59:53.706Z TRANSPORT_HEAD_CLOSED
> 23:59:53.706Z TRANSPORT_CLOSED
> {code}
> We did also open a ticket with Microsoft / Azure as the disconnects seemed to
> originate from the Service Bus instance (SESSION_REMOTE_CLOSE) where we did
> learn, that the Service Bus has a hardwired TTL of 5 minutes before inactive
> Subscriptions will be terminated. According to Azure-Support the issue is
> most likely related to Qpid connection
[jira] [Commented] (QPIDJMS-392) Stalled Service Bus Subscriptions, Reconnect Loops
[
https://issues.apache.org/jira/browse/QPIDJMS-392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509719#comment-16509719
]
Robbie Gemmell commented on QPIDJMS-392:
In general, use the users list to raise things for discussion first.
Turn on the protocol tracing and it will be more evident what each side is, or
isnt, doing:
[http://qpid.apache.org/releases/qpid-jms-0.32.0/docs/index.html#logging]
A candidate for 0.33.0 is currently under release vote, there are some fixes in
it that might be of a little interest, but only as you started using the
failover provider (which just runs the other one underneath it, so it shouldn't
change things much if you already had issues), you can find details in this
mail thread if you want to try with it:
[https://lists.apache.org/thread.html/96ee2e915f4d191b4a18960664b335b85c74c124973edf7748103930@%3Cusers.qpid.apache.org%3E]
> Stalled Service Bus Subscriptions, Reconnect Loops
> --
>
> Key: QPIDJMS-392
> URL: https://issues.apache.org/jira/browse/QPIDJMS-392
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.32.0
> Environment: * Azure App Service
> * Spring 1.5.12 via embedded web server / standalone
> * java.runtime.version "1.8.0_144-b01"
> * java.vm.version "25.144-b01"
> * java.vm.vendor "Azul Systems, Inc."
> * os.arch "amd64"
> * os.name "Windows Server 2016"
>Reporter: Paul Rogalinski
>Priority: Major
> Attachments: qpid-log.txt
>
>
> We are experiencing connection recovery loops after an random (hours to days)
> amount of time on JMS connection subscribed to a Service Bus Topic via
> (durable) Subscription. The application does connect to two different service
> bus instances at the same time.
> We had to use the failover:(amqp:...) URL pattern in order to actually see
> something in the log files as the FailoverProvider is a bit more verbose
> (TRACE level). When using plain ampqs:// connection URL pattern the only way
> to tell a hanging/stalled subscription was to monitor the number of
> active/unconsumed Messages in a Service Bus' Subscription using a different
> client. Regardless of the Provider implementation, the problem of stalled
> subscriptions persisted.
> Log observations so far:
> After an initial disconnect:
> {code:java}
> o.a.qpid.jms.provider.amqp.AmqpProvider : New Proton Event:
> CONNECTION_REMOTE_CLOSE
> (...)
> Failover: the provider reports failure: The connection was inactive for more
> than the allowed 30 milliseconds and is closed by container
> 'LinkTracker'. TrackingId:c2925ed17c9549b29a825cc581852d1a_G6,
> SystemTracker:gateway9, Timestamp:5/1/2018 6:11:44 PM [condition =
> amqp:connection:forced]
> {code}
> the application will enter into a reconnect/connection recovery loop with an
> interval of one minute.
> {code:java}
> 18:11:44.670Z Failover: the provider reports failure: The connection was
> inactive for more than the allowed 30 milliseconds and is closed by
> container 'LinkTracker'. TrackingId:c2925ed17c9549b29a825cc581852d1a_G6,
> SystemTracker:gateway9, Timestamp:5/1/2018 6:11:44 PM [condition =
> amqp:connection:forced]
> 18:12:44.789Z Failover: the provider reports failure: The connection was
> inactive for more than the allowed 6 milliseconds and is closed by
> container 'LinkTracker'. TrackingId:50b008fdb56f443b947d76ded87691a9_G5,
> SystemTracker:gateway9, Timestamp:5/1/2018 6:12:44 PM [condition =
> amqp:connection:forced]
> 18:13:44.918Z Failover: the provider reports failure: The connection was
> inactive for more than the allowed 6 milliseconds and is closed by
> container 'LinkTracker'. TrackingId:a2832475e8ab4702b6189d9218588132_G15,
> SystemTracker:gateway9, Timestamp:5/1/2018 6:13:44 PM [condition =
> amqp:connection:forced]
> {code}
> In between we see the connection being recovered along with log messages as:
> {code:java}
> org.apache.qpid.jms.JmsConnection : Connection
> ID:8061906b-13e9-46a3-b6d0-fd227b339f67:1 is finalizing recovery
> {code}
> followed by
> {code:java}
> o.a.qpid.jms.provider.amqp.AmqpProvider : New Proton Event:
> SESSION_REMOTE_CLOSE
> {code}
> after a minute.
> A full cycle is attached in the log file, URLs are anonymized.
> In general we can see the following sequence of Proton-Events repeating:
> {code:java}
> 23:58:53.676Z CONNECTION_INIT
> 23:58:53.722Z CONNECTION_LOCAL_OPEN
> 23:58:53.722Z CONNECTION_REMOTE_OPEN
> 23:58:53.722Z SESSION_INIT
> 23:58:53.722Z SESSION_LOCAL_OPEN
> 23:58:53.738Z SESSION_REMOTE_OPEN
> 23:59:53.690Z SESSION_REMOTE_CLOSE
> 23:59:53.690Z SESSION_LOCAL_CLOSE
> 23:59:53.690Z SESSION_FINAL
> 23:59:53.706Z CONNECTION_REMOTE_CLOSE
> 23:59:53.706Z TRANSPORT_TAIL_CLOSED
> 23:59:53.706Z CONNECTION_LOCAL_CLOSE
> 23:59:53.706Z
[jira] [Commented] (PROTON-1858) [Python] Rewrite wrapped C handlers in python
[ https://issues.apache.org/jira/browse/PROTON-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509701#comment-16509701 ] ASF subversion and git services commented on PROTON-1858: - Commit 67d4d749033c1eb03b2f1bff20518c8050d0ccdb in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=67d4d74 ] PROTON-1858: Rework wrapped C handlers in pure python - Rewritten Handshaker and FlowController in python - CFlowController and CHandshaker are now aliases for Flowcontroller and Handshaker > [Python] Rewrite wrapped C handlers in python > - > > Key: PROTON-1858 > URL: https://issues.apache.org/jira/browse/PROTON-1858 > Project: Qpid Proton > Issue Type: Improvement > Components: python-binding >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Major > > This is necessary to move the python bindings off the reactor implementations > and only depend on qpid-proton-core -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDJMS-392) Stalled Service Bus Subscriptions, Reconnect Loops
[
https://issues.apache.org/jira/browse/QPIDJMS-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Rogalinski updated QPIDJMS-392:
Description:
We are experiencing connection recovery loops after an random (hours to days)
amount of time on JMS connection subscribed to a Service Bus Topic via
(durable) Subscription. The application does connect to two different service
bus instances at the same time.
We had to use the failover:(amqp:...) URL pattern in order to actually see
something in the log files as the FailoverProvider is a bit more verbose (TRACE
level). When using plain ampqs:// connection URL pattern the only way to tell a
hanging/stalled subscription was to monitor the number of active/unconsumed
Messages in a Service Bus' Subscription using a different client. Regardless of
the Provider implementation, the problem of stalled subscriptions persisted.
Log observations so far:
After an initial disconnect:
{code:java}
o.a.qpid.jms.provider.amqp.AmqpProvider : New Proton Event:
CONNECTION_REMOTE_CLOSE
(...)
Failover: the provider reports failure: The connection was inactive for more
than the allowed 30 milliseconds and is closed by container 'LinkTracker'.
TrackingId:c2925ed17c9549b29a825cc581852d1a_G6, SystemTracker:gateway9,
Timestamp:5/1/2018 6:11:44 PM [condition = amqp:connection:forced]
{code}
the application will enter into a reconnect/connection recovery loop with an
interval of one minute.
{code:java}
18:11:44.670Z Failover: the provider reports failure: The connection was
inactive for more than the allowed 30 milliseconds and is closed by
container 'LinkTracker'. TrackingId:c2925ed17c9549b29a825cc581852d1a_G6,
SystemTracker:gateway9, Timestamp:5/1/2018 6:11:44 PM [condition =
amqp:connection:forced]
18:12:44.789Z Failover: the provider reports failure: The connection was
inactive for more than the allowed 6 milliseconds and is closed by
container 'LinkTracker'. TrackingId:50b008fdb56f443b947d76ded87691a9_G5,
SystemTracker:gateway9, Timestamp:5/1/2018 6:12:44 PM [condition =
amqp:connection:forced]
18:13:44.918Z Failover: the provider reports failure: The connection was
inactive for more than the allowed 6 milliseconds and is closed by
container 'LinkTracker'. TrackingId:a2832475e8ab4702b6189d9218588132_G15,
SystemTracker:gateway9, Timestamp:5/1/2018 6:13:44 PM [condition =
amqp:connection:forced]
{code}
In between we see the connection being recovered along with log messages as:
{code:java}
org.apache.qpid.jms.JmsConnection : Connection
ID:8061906b-13e9-46a3-b6d0-fd227b339f67:1 is finalizing recovery
{code}
followed by
{code:java}
o.a.qpid.jms.provider.amqp.AmqpProvider : New Proton Event:
SESSION_REMOTE_CLOSE
{code}
after a minute.
A full cycle is attached in the log file, URLs are anonymized.
In general we can see the following sequence of Proton-Events repeating:
{code:java}
23:58:53.676Z CONNECTION_INIT
23:58:53.722Z CONNECTION_LOCAL_OPEN
23:58:53.722Z CONNECTION_REMOTE_OPEN
23:58:53.722Z SESSION_INIT
23:58:53.722Z SESSION_LOCAL_OPEN
23:58:53.738Z SESSION_REMOTE_OPEN
23:59:53.690Z SESSION_REMOTE_CLOSE
23:59:53.690Z SESSION_LOCAL_CLOSE
23:59:53.690Z SESSION_FINAL
23:59:53.706Z CONNECTION_REMOTE_CLOSE
23:59:53.706Z TRANSPORT_TAIL_CLOSED
23:59:53.706Z CONNECTION_LOCAL_CLOSE
23:59:53.706Z TRANSPORT_HEAD_CLOSED
23:59:53.706Z TRANSPORT_CLOSED
{code}
We did also open a ticket with Microsoft / Azure as the disconnects seemed to
originate from the Service Bus instance (SESSION_REMOTE_CLOSE) where we did
learn, that the Service Bus has a hardwired TTL of 5 minutes before inactive
Subscriptions will be terminated. According to Azure-Support the issue is most
likely related to Qpid connection handling. This does at least explain the
first / initial timeout of 30 seen in the logs. The connection / client is
set up as follows
URLs:
{code:java}
failover:(amqps://instance1.servicebus.windows.net)?amqp.idleTimeout=12000
failover:(amqps://instance2.servicebus.windows.net)?amqp.idleTimeout=12000
{code}
Connection Factories:
{code:java}
JmsConnectionFactory qpidConnectionFactory = new
JmsConnectionFactory(sbUsername, sbPassword, sbAmqpRemoteUri);
qpidConnectionFactory.setReceiveLocalOnly(true);
qpidConnectionFactory.setClientID(UUID.randomUUID().toString()); {code}
JmsListenerContainerFactories:
{code:java}
DefaultJmsListenerContainerFactory jmsListenerContainerFactory = new
DefaultJmsListenerContainerFactory();
jmsListenerContainerFactory.setConnectionFactory(jmsConnectionFactory);
jmsListenerContainerFactory.setPubSubDomain(true);
jmsListenerContainerFactory.setSubscriptionDurable(true);
jmsListenerContainerFactory.setSessionAcknowledgeMode(Session.CLIENT_ACKNOWLEDGE);
return jmsListenerContainerFactory;{code}
And Spring-JMS Listeners:
{code:java}
@Component
public class MyListener {
@Autowired
JMSSupport jmsSupport;
[jira] [Created] (PROTON-1858) [Python] Rewrite wrapped C handlers in python
Andrew Stitcher created PROTON-1858: --- Summary: [Python] Rewrite wrapped C handlers in python Key: PROTON-1858 URL: https://issues.apache.org/jira/browse/PROTON-1858 Project: Qpid Proton Issue Type: Improvement Components: python-binding Reporter: Andrew Stitcher Assignee: Andrew Stitcher This is necessary to move the python bindings off the reactor implementations and only depend on qpid-proton-core -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1354) Disable problematic SASL mechanisms if they are not explicitly enabled
[ https://issues.apache.org/jira/browse/PROTON-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509690#comment-16509690 ] Andrew Stitcher commented on PROTON-1354: - I think the correct (and simplest) thing to do here is on the _server_ side. So that SASL servers will not offer GSSAPI or GSS-SPNEGO unless they are specifically selected. I don't think it is necessary to filter them out on the client side, as the server probably should be controlling which mechanisms are in use anyway. > Disable problematic SASL mechanisms if they are not explicitly enabled > -- > > Key: PROTON-1354 > URL: https://issues.apache.org/jira/browse/PROTON-1354 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: Justin Ross >Assignee: Andrew Stitcher >Priority: Major > Labels: sasl, usability > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDJMS-392) Stalled Service Bus Subscriptions, Reconnect Loops
[
https://issues.apache.org/jira/browse/QPIDJMS-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Rogalinski updated QPIDJMS-392:
Description:
We are experiencing connection recovery loops after an random (hours to days)
amount of time on JMS connection subscribed to a Service Bus Topic via
(durable) Subscription. The application does connect to two different service
bus instances at the same time.
We had to use the failover:(amqp:...) URL pattern in order to actually see
something in the log files as the FailoverProvider is a bit more verbose (TRACE
level). When using plain ampqs:// connection URL pattern the only way to tell a
hanging/stalled subscription was to monitor the number of active/unconsumed
Messages in a Service Bus' Subscription using a different client. Regardless of
the Provider implementation, the problem of stalled subscriptions persisted.
Log observations so far:
After an initial disconnect:
{code:java}
o.a.qpid.jms.provider.amqp.AmqpProvider : New Proton Event:
CONNECTION_REMOTE_CLOSE
(...)
Failover: the provider reports failure: The connection was inactive for more
than the allowed 30 milliseconds and is closed by container 'LinkTracker'.
TrackingId:c2925ed17c9549b29a825cc581852d1a_G6, SystemTracker:gateway9,
Timestamp:5/1/2018 6:11:44 PM [condition = amqp:connection:forced]
{code}
the application will enter into a reconnect/connection recovery loop with an
interval of one minute.
{code:java}
18:11:44.670Z Failover: the provider reports failure: The connection was
inactive for more than the allowed 30 milliseconds and is closed by
container 'LinkTracker'. TrackingId:c2925ed17c9549b29a825cc581852d1a_G6,
SystemTracker:gateway9, Timestamp:5/1/2018 6:11:44 PM [condition =
amqp:connection:forced]
18:12:44.789Z Failover: the provider reports failure: The connection was
inactive for more than the allowed 6 milliseconds and is closed by
container 'LinkTracker'. TrackingId:50b008fdb56f443b947d76ded87691a9_G5,
SystemTracker:gateway9, Timestamp:5/1/2018 6:12:44 PM [condition =
amqp:connection:forced]
18:13:44.918Z Failover: the provider reports failure: The connection was
inactive for more than the allowed 6 milliseconds and is closed by
container 'LinkTracker'. TrackingId:a2832475e8ab4702b6189d9218588132_G15,
SystemTracker:gateway9, Timestamp:5/1/2018 6:13:44 PM [condition =
amqp:connection:forced]
{code}
In between we see the connection being recovered along with log messages as:
{code:java}
org.apache.qpid.jms.JmsConnection : Connection
ID:8061906b-13e9-46a3-b6d0-fd227b339f67:1 is finalizing recovery
{code}
followed by
{code:java}
o.a.qpid.jms.provider.amqp.AmqpProvider : New Proton Event:
SESSION_REMOTE_CLOSE
{code}
after a minute.
A full cycle is attached in the log file, URLs are anonymized.
In general we can see the following sequence of Proton-Events repeating:
{code:java}
23:58:53.676Z CONNECTION_INIT
23:58:53.722Z CONNECTION_LOCAL_OPEN
23:58:53.722Z CONNECTION_REMOTE_OPEN
23:58:53.722Z SESSION_INIT
23:58:53.722Z SESSION_LOCAL_OPEN
23:58:53.738Z SESSION_REMOTE_OPEN
23:59:53.690Z SESSION_REMOTE_CLOSE
23:59:53.690Z SESSION_LOCAL_CLOSE
23:59:53.690Z SESSION_FINAL
23:59:53.706Z CONNECTION_REMOTE_CLOSE
23:59:53.706Z TRANSPORT_TAIL_CLOSED
23:59:53.706Z CONNECTION_LOCAL_CLOSE
23:59:53.706Z TRANSPORT_HEAD_CLOSED
23:59:53.706Z TRANSPORT_CLOSED
{code}
We did also open a ticket with Microsoft / Azure as the disconnects seemed to
originate from the Service Bus instance (SESSION_REMOTE_CLOSE) where we did
learn, that the Service Bus has a hardwired TTL of 5 minutes before inactive
Subscriptions will be terminated. According to Azure-Support the issue is most
likely related to Qpid connection handling. This does at least explain the
first / initial timeout of 30 seen in the logs. The connection / client is
set up as follows
URLs:
{code:java}
failover:(amqps://instance1.servicebus.windows.net)?amqp.idleTimeout=12000
failover:(amqps://instance2.servicebus.windows.net)?amqp.idleTimeout=12000
{code}
Connection Factories:
{code:java}
JmsConnectionFactory qpidConnectionFactory = new
JmsConnectionFactory(sbUsername, sbPassword, sbAmqpRemoteUri);
qpidConnectionFactory.setReceiveLocalOnly(true);
qpidConnectionFactory.setClientID(UUID.randomUUID().toString()); {code}
JmsListenerContainerFactories:
{code:java}
DefaultJmsListenerContainerFactory jmsListenerContainerFactory = new
DefaultJmsListenerContainerFactory();
jmsListenerContainerFactory.setConnectionFactory(jmsConnectionFactory);
jmsListenerContainerFactory.setPubSubDomain(true);
jmsListenerContainerFactory.setSubscriptionDurable(true);
jmsListenerContainerFactory.setSessionAcknowledgeMode(Session.CLIENT_ACKNOWLEDGE);
return jmsListenerContainerFactory;{code}
And Spring-JMS Listeners:
{code:java}
@Component
public class MyListener {
@Autowired
JMSSupport jmsSupport;
[jira] [Created] (QPIDJMS-392) Stalled Service Bus Subscriptions, Reconnect Loops
Paul Rogalinski created QPIDJMS-392:
---
Summary: Stalled Service Bus Subscriptions, Reconnect Loops
Key: QPIDJMS-392
URL: https://issues.apache.org/jira/browse/QPIDJMS-392
Project: Qpid JMS
Issue Type: Bug
Components: qpid-jms-client
Affects Versions: 0.32.0
Environment: * Azure App Service
* Spring 1.5.12 via embedded web server / standalone
* java.runtime.version "1.8.0_144-b01"
* java.vm.version "25.144-b01"
* java.vm.vendor "Azul Systems, Inc."
* os.arch "amd64"
* os.name "Windows Server 2016"
Reporter: Paul Rogalinski
Attachments: qpid-log.txt
We are experiencing connection recovery loops after an random (hours to days)
amount of time on JMS connection subscribed to a Service Bus Topic via
(durable) Subscription. The application does connect to two different service
bus instances at the same time.
We had to use the failover:(amqp:...) URL pattern in order to actually see
something in the log files as the FailoverProvider is a bit more verbose (TRACE
level). When using plain ampqs:// connection URL pattern the only way to tell a
hanging/stalled subscription was to monitor the number of active/unconsumed
Messages in a Service Bus' Subscription using a different client. Regardless of
the Provider implementation, the problem of stalled subscriptions persisted.
Log observations so far:
After an initial disconnect:
{code:java}
o.a.qpid.jms.provider.amqp.AmqpProvider : New Proton Event:
CONNECTION_REMOTE_CLOSE
(...)
Failover: the provider reports failure: The connection was inactive for more
than the allowed 30 milliseconds and is closed by container 'LinkTracker'.
TrackingId:c2925ed17c9549b29a825cc581852d1a_G6, SystemTracker:gateway9,
Timestamp:5/1/2018 6:11:44 PM [condition = amqp:connection:forced]
{code}
the application will enter into a reconnect/connection recovery loop with an
interval of one minute.
{code:java}
18:11:44.670Z Failover: the provider reports failure: The connection was
inactive for more than the allowed 30 milliseconds and is closed by
container 'LinkTracker'. TrackingId:c2925ed17c9549b29a825cc581852d1a_G6,
SystemTracker:gateway9, Timestamp:5/1/2018 6:11:44 PM [condition =
amqp:connection:forced]
18:12:44.789Z Failover: the provider reports failure: The connection was
inactive for more than the allowed 6 milliseconds and is closed by
container 'LinkTracker'. TrackingId:50b008fdb56f443b947d76ded87691a9_G5,
SystemTracker:gateway9, Timestamp:5/1/2018 6:12:44 PM [condition =
amqp:connection:forced]
18:13:44.918Z Failover: the provider reports failure: The connection was
inactive for more than the allowed 6 milliseconds and is closed by
container 'LinkTracker'. TrackingId:a2832475e8ab4702b6189d9218588132_G15,
SystemTracker:gateway9, Timestamp:5/1/2018 6:13:44 PM [condition =
amqp:connection:forced]
{code}
In between we see the connection being recovered along with log messages as:
{code:java}
org.apache.qpid.jms.JmsConnection : Connection
ID:8061906b-13e9-46a3-b6d0-fd227b339f67:1 is finalizing recovery
{code}
followed by
{code:java}
o.a.qpid.jms.provider.amqp.AmqpProvider : New Proton Event:
SESSION_REMOTE_CLOSE
{code}
after a minute.
A full cycle is attached in the log file, URLs are anonymized.
In general we can see the following sequence of Proton-Events repeating:
{code:java}
23:58:53.676Z CONNECTION_INIT
23:58:53.722Z CONNECTION_LOCAL_OPEN
23:58:53.722Z CONNECTION_REMOTE_OPEN
23:58:53.722Z SESSION_INIT
23:58:53.722Z SESSION_LOCAL_OPEN
23:58:53.738Z SESSION_REMOTE_OPEN
23:59:53.690Z SESSION_REMOTE_CLOSE
23:59:53.690Z SESSION_LOCAL_CLOSE
23:59:53.690Z SESSION_FINAL
23:59:53.706Z CONNECTION_REMOTE_CLOSE
23:59:53.706Z TRANSPORT_TAIL_CLOSED
23:59:53.706Z CONNECTION_LOCAL_CLOSE
23:59:53.706Z TRANSPORT_HEAD_CLOSED
23:59:53.706Z TRANSPORT_CLOSED
{code}
We did also open a ticket with Microsoft / Azure as the disconnects seemed to
originate from the Service Bus instance (SESSION_REMOTE_CLOSE) where we did
learn, that the Service Bus has a hardwired TTL of 5 minutes before inactive
Subscriptions will be terminated. According to Azure-Support the issue is most
likely related to Qpid connection handling. This does at least explain the
first / initial timeout of 30 seen in the logs. The connection / client is
set up as follows
URLs:
{code:java}
failover:(amqps://instance1.servicebus.windows.net)?amqp.idleTimeout=12000
failover:(amqps://instance2.servicebus.windows.net)?amqp.idleTimeout=12000
{code}
Connection Factories:
{code:java}
JmsConnectionFactory qpidConnectionFactory = new
JmsConnectionFactory(sbUsername, sbPassword, sbAmqpRemoteUri);
qpidConnectionFactory.setReceiveLocalOnly(true);
qpidConnectionFactory.setClientID(UUID.randomUUID().toString()); {code}
JmsListenerContainerFactories:
{code:java}
DefaultJmsListenerContainerFactory
[jira] [Commented] (PROTON-1354) Disable problematic SASL mechanisms if they are not explicitly enabled
[ https://issues.apache.org/jira/browse/PROTON-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509688#comment-16509688 ] Andrew Stitcher commented on PROTON-1354: - I think the problematic mechanisms are GSS-SPNEGO and GSSAPI because if the server offers them and the client has any kerberos session it will completely fail the sasl exchange if the server is is not known to the client rather than just not choose those mechanisms. As kerberos is latent in the environment this can be puzzling as there is no sign that kerberos is set up. This produces a very puzzling error, that is quite hard to work around without setting the client mechanisms up explicitly - in other words needs the client code modified. > Disable problematic SASL mechanisms if they are not explicitly enabled > -- > > Key: PROTON-1354 > URL: https://issues.apache.org/jira/browse/PROTON-1354 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: Justin Ross >Assignee: Andrew Stitcher >Priority: Major > Labels: sasl, usability > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1034) saslPlugin option does not work with http option in listener
Gordon Sim created DISPATCH-1034: Summary: saslPlugin option does not work with http option in listener Key: DISPATCH-1034 URL: https://issues.apache.org/jira/browse/DISPATCH-1034 Project: Qpid Dispatch Issue Type: Bug Affects Versions: 1.1.0 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 1.2.0 If you have a listener configured to accept websockets, and want to use the sasl-delegation plugin to some central auth service, wesocket connections to that listener cannot be authenticated. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-386) failover provider prevents handling of remote resource closure from completing correctly
[ https://issues.apache.org/jira/browse/QPIDJMS-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509482#comment-16509482 ] Abhishek Kumar commented on QPIDJMS-386: It is working as expected. Thanks a lot for quick fixes. Appreciate your quick help guys. > failover provider prevents handling of remote resource closure from > completing correctly > > > Key: QPIDJMS-386 > URL: https://issues.apache.org/jira/browse/QPIDJMS-386 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.32.0 > Environment: >Reporter: Robbie Gemmell >Assignee: Timothy Bish >Priority: Major > Fix For: 0.33.0 > > > QPIDJMS-376 added functionality to fire the connection ExceptionListener if a > MessageConsumer with a MessageListener is remotely closed, since the lack of > future message deliveries would mean the application has no further > interaction with the consumer to observe the issue. It has since been > identified that this doesn't occur when using the built in failover provider, > which is preventing the process of handling the remote consumer resource > closure from completing fully. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8207) [Broker-J] Flow to disk might not be triggered in some circumstances
[ https://issues.apache.org/jira/browse/QPID-8207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8207: - Issue Type: Bug (was: Task) > [Broker-J] Flow to disk might not be triggered in some circumstances > > > Key: QPID-8207 > URL: https://issues.apache.org/jira/browse/QPID-8207 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3, > qpid-java-broker-7.0.2, qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2, > qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5, qpid-java-6.1, > qpid-java-6.0.6, qpid-java-6.1.1, qpid-java-6.1.2, qpid-java-6.0.7, > qpid-java-6.1.3, qpid-java-6.0.8, qpid-java-6.1.4, qpid-java-broker-7.0.0, > qpid-java-6.1.5, qpid-java-broker-7.0.1, qpid-java-6.1.7, qpid-java-6.0.9, > qpid-java-broker-7.0.4 >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Critical > Fix For: qpid-java-6.1.7, qpid-java-broker-7.0.5 > > Attachments: > 0001-QPID-8207-Broker-J-Fix-evaluation-of-flow-to-disk-th.patch > > > An evaluation of Virtual Host flow to disk threshold can overflow and yield > incorrect value. As result, the flow of messages to disk might not be > triggered and Broker can ran out of direct memory. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1003) Enable console support for connecting to listener configured with saslMechanisms other than ANONYMOUS
[ https://issues.apache.org/jira/browse/DISPATCH-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509473#comment-16509473 ] ASF subversion and git services commented on DISPATCH-1003: --- Commit 13c2107ba96bd901e90a47a494c3a73732471602 in qpid-dispatch's branch refs/heads/master from [~eallen] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=13c2107 ] DISPATCH-1003 Adding username/password fields to hawtio connect page > Enable console support for connecting to listener configured with > saslMechanisms other than ANONYMOUS > - > > Key: DISPATCH-1003 > URL: https://issues.apache.org/jira/browse/DISPATCH-1003 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 1.1.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Major > > For the console, this boils down to: > * prompt for a username / password on the connect page > * pass the username / password to the connect request > There will be a different Jira to allow the http enabled listener to use the > username/password and authenticate. Currently authentication works if you go > though a non-http listener, but not a http enabled listener. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8208) [Broker-J] Improve handling of unexpected exceptions on establishing LDAP connections in SimpleLDAPAuthenticationProvider
[
https://issues.apache.org/jira/browse/QPID-8208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8208:
-
Summary: [Broker-J] Improve handling of unexpected exceptions on
establishing LDAP connections in SimpleLDAPAuthenticationProvider (was:
[Broker-J] Improve unexpected exception handling for LDAP connections in
SimpleLDAPAuthenticationProvider)
> [Broker-J] Improve handling of unexpected exceptions on establishing LDAP
> connections in SimpleLDAPAuthenticationProvider
> --
>
> Key: QPID-8208
> URL: https://issues.apache.org/jira/browse/QPID-8208
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3,
> qpid-java-broker-7.0.2, 0.32, qpid-java-6.0, qpid-java-6.0.1,
> qpid-java-6.0.2, qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5,
> qpid-java-6.1, qpid-java-6.0.6, qpid-java-6.1.1, qpid-java-6.1.2,
> qpid-java-6.0.7, qpid-java-6.1.3, qpid-java-6.0.8, qpid-java-6.1.4,
> qpid-java-broker-7.0.0, qpid-java-6.1.5, qpid-java-broker-7.0.1,
> qpid-java-broker-7.0.4
>Reporter: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-7.0.6
>
> Attachments: 0001-QPID-8208-Broker-J-Improve-exception-handling.patch
>
>
> The establishment of connection with LDAP using default
> {{com.sun.jndi.ldap.LdapCtxFactory}} can end-up in unexpected exception
> thrown from {{com.sun.jndi.ldap.LdapClient}}. Thought, it looks like a defect
> in {{LdapClient}}, the unexpected exceptions should be handled appropriately.
> The exception should be logged and the authentication failure error should be
> returned back to the client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8208) [Broker-J] Improve unexpected exception handling for LDAP connections in SimpleLDAPAuthenticationProvider
[
https://issues.apache.org/jira/browse/QPID-8208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8208:
-
Fix Version/s: (was: qpid-java-broker-7.0.5)
qpid-java-broker-7.0.6
> [Broker-J] Improve unexpected exception handling for LDAP connections in
> SimpleLDAPAuthenticationProvider
> -
>
> Key: QPID-8208
> URL: https://issues.apache.org/jira/browse/QPID-8208
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3,
> qpid-java-broker-7.0.2, 0.32, qpid-java-6.0, qpid-java-6.0.1,
> qpid-java-6.0.2, qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5,
> qpid-java-6.1, qpid-java-6.0.6, qpid-java-6.1.1, qpid-java-6.1.2,
> qpid-java-6.0.7, qpid-java-6.1.3, qpid-java-6.0.8, qpid-java-6.1.4,
> qpid-java-broker-7.0.0, qpid-java-6.1.5, qpid-java-broker-7.0.1,
> qpid-java-broker-7.0.4
>Reporter: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-7.0.6
>
> Attachments: 0001-QPID-8208-Broker-J-Improve-exception-handling.patch
>
>
> The establishment of connection with LDAP using default
> {{com.sun.jndi.ldap.LdapCtxFactory}} can end-up in unexpected exception
> thrown from {{com.sun.jndi.ldap.LdapClient}}. Thought, it looks like a defect
> in {{LdapClient}}, the unexpected exceptions should be handled appropriately.
> The exception should be logged and the authentication failure error should be
> returned back to the client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8208) [Broker-J] Improve unexpected exception handling for LDAP connections in SimpleLDAPAuthenticationProvider
[
https://issues.apache.org/jira/browse/QPID-8208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8208:
-
Issue Type: Improvement (was: Bug)
> [Broker-J] Improve unexpected exception handling for LDAP connections in
> SimpleLDAPAuthenticationProvider
> -
>
> Key: QPID-8208
> URL: https://issues.apache.org/jira/browse/QPID-8208
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3,
> qpid-java-broker-7.0.2, 0.32, qpid-java-6.0, qpid-java-6.0.1,
> qpid-java-6.0.2, qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5,
> qpid-java-6.1, qpid-java-6.0.6, qpid-java-6.1.1, qpid-java-6.1.2,
> qpid-java-6.0.7, qpid-java-6.1.3, qpid-java-6.0.8, qpid-java-6.1.4,
> qpid-java-broker-7.0.0, qpid-java-6.1.5, qpid-java-broker-7.0.1,
> qpid-java-broker-7.0.4
>Reporter: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-7.0.6
>
> Attachments: 0001-QPID-8208-Broker-J-Improve-exception-handling.patch
>
>
> The establishment of connection with LDAP using default
> {{com.sun.jndi.ldap.LdapCtxFactory}} can end-up in unexpected exception
> thrown from {{com.sun.jndi.ldap.LdapClient}}. Thought, it looks like a defect
> in {{LdapClient}}, the unexpected exceptions should be handled appropriately.
> The exception should be logged and the authentication failure error should be
> returned back to the client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8208) [Broker-J] Improve unexpected exception handling for LDAP connections in SimpleLDAPAuthenticationProvider
[
https://issues.apache.org/jira/browse/QPID-8208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509365#comment-16509365
]
Alex Rudyy commented on QPID-8208:
--
I reverted the changes with a work around for the issue which looks to me like
JVM defect. I am going to de-scope this JIRA from 7.0.5 release. The Oracle
JVM defect should be raised and its number should be referred in a work-around
> [Broker-J] Improve unexpected exception handling for LDAP connections in
> SimpleLDAPAuthenticationProvider
> -
>
> Key: QPID-8208
> URL: https://issues.apache.org/jira/browse/QPID-8208
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3,
> qpid-java-broker-7.0.2, 0.32, qpid-java-6.0, qpid-java-6.0.1,
> qpid-java-6.0.2, qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5,
> qpid-java-6.1, qpid-java-6.0.6, qpid-java-6.1.1, qpid-java-6.1.2,
> qpid-java-6.0.7, qpid-java-6.1.3, qpid-java-6.0.8, qpid-java-6.1.4,
> qpid-java-broker-7.0.0, qpid-java-6.1.5, qpid-java-broker-7.0.1,
> qpid-java-broker-7.0.4
>Reporter: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-7.0.5
>
> Attachments: 0001-QPID-8208-Broker-J-Improve-exception-handling.patch
>
>
> The establishment of connection with LDAP using default
> {{com.sun.jndi.ldap.LdapCtxFactory}} can end-up in unexpected exception
> thrown from {{com.sun.jndi.ldap.LdapClient}}. Thought, it looks like a defect
> in {{LdapClient}}, the unexpected exceptions should be handled appropriately.
> The exception should be logged and the authentication failure error should be
> returned back to the client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8208) [Broker-J] Improve unexpected exception handling for LDAP connections in SimpleLDAPAuthenticationProvider
[
https://issues.apache.org/jira/browse/QPID-8208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509358#comment-16509358
]
ASF subversion and git services commented on QPID-8208:
---
Commit ad99c10efdec912845107af228610c3e323ef68e in qpid-broker-j's branch
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=ad99c10 ]
Revert "QPID-8208: [Broker-J] Strengthen handling of exception thrown on
establishing of LDAP connections"
This reverts commit 93a288fdc6d44c0a39ad217beb4b58e768753128.
> [Broker-J] Improve unexpected exception handling for LDAP connections in
> SimpleLDAPAuthenticationProvider
> -
>
> Key: QPID-8208
> URL: https://issues.apache.org/jira/browse/QPID-8208
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3,
> qpid-java-broker-7.0.2, 0.32, qpid-java-6.0, qpid-java-6.0.1,
> qpid-java-6.0.2, qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5,
> qpid-java-6.1, qpid-java-6.0.6, qpid-java-6.1.1, qpid-java-6.1.2,
> qpid-java-6.0.7, qpid-java-6.1.3, qpid-java-6.0.8, qpid-java-6.1.4,
> qpid-java-broker-7.0.0, qpid-java-6.1.5, qpid-java-broker-7.0.1,
> qpid-java-broker-7.0.4
>Reporter: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-7.0.5
>
> Attachments: 0001-QPID-8208-Broker-J-Improve-exception-handling.patch
>
>
> The establishment of connection with LDAP using default
> {{com.sun.jndi.ldap.LdapCtxFactory}} can end-up in unexpected exception
> thrown from {{com.sun.jndi.ldap.LdapClient}}. Thought, it looks like a defect
> in {{LdapClient}}, the unexpected exceptions should be handled appropriately.
> The exception should be logged and the authentication failure error should be
> returned back to the client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8208) [Broker-J] Improve unexpected exception handling for LDAP connections in SimpleLDAPAuthenticationProvider
[
https://issues.apache.org/jira/browse/QPID-8208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509357#comment-16509357
]
ASF subversion and git services commented on QPID-8208:
---
Commit 6acc91299ccf6440268592d901ae45f7f3800224 in qpid-broker-j's branch
refs/heads/7.0.x from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=6acc912 ]
Revert "QPID-8208: [Broker-J] Strengthen handling of exception thrown on
establishing of LDAP connections"
This reverts commit 06c01aa94dd4e71be8280c1fd218f909fddf3f15.
> [Broker-J] Improve unexpected exception handling for LDAP connections in
> SimpleLDAPAuthenticationProvider
> -
>
> Key: QPID-8208
> URL: https://issues.apache.org/jira/browse/QPID-8208
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3,
> qpid-java-broker-7.0.2, 0.32, qpid-java-6.0, qpid-java-6.0.1,
> qpid-java-6.0.2, qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5,
> qpid-java-6.1, qpid-java-6.0.6, qpid-java-6.1.1, qpid-java-6.1.2,
> qpid-java-6.0.7, qpid-java-6.1.3, qpid-java-6.0.8, qpid-java-6.1.4,
> qpid-java-broker-7.0.0, qpid-java-6.1.5, qpid-java-broker-7.0.1,
> qpid-java-broker-7.0.4
>Reporter: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-7.0.5
>
> Attachments: 0001-QPID-8208-Broker-J-Improve-exception-handling.patch
>
>
> The establishment of connection with LDAP using default
> {{com.sun.jndi.ldap.LdapCtxFactory}} can end-up in unexpected exception
> thrown from {{com.sun.jndi.ldap.LdapClient}}. Thought, it looks like a defect
> in {{LdapClient}}, the unexpected exceptions should be handled appropriately.
> The exception should be logged and the authentication failure error should be
> returned back to the client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
