[jira] [Closed] (DISPATCH-1035) pn_connection_wake() doesn't have any effect on websockets connections
[ https://issues.apache.org/jira/browse/DISPATCH-1035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim closed DISPATCH-1035. Resolution: Won't Fix There is a context dependent wake function pointer on qd_connection_t that can be used instead of calling pn_connection_wake directly and this works around the issue. > 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 >Priority: Major > > 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-1037) Listeners with http enabled are not being shutdown after they are deleted
[
https://issues.apache.org/jira/browse/DISPATCH-1037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16511553#comment-16511553
]
ASF GitHub Bot commented on DISPATCH-1037:
--
Github user codecov-io commented on the issue:
https://github.com/apache/qpid-dispatch/pull/325
#
[Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/325?src=pr=h1)
Report
> Merging
[#325](https://codecov.io/gh/apache/qpid-dispatch/pull/325?src=pr=desc) into
[master](https://codecov.io/gh/apache/qpid-dispatch/commit/e6864f63e7086b1fee0063ff22803cae1fc14a35?src=pr=desc)
will **increase** coverage by `0.02%`.
> The diff coverage is `n/a`.
[](https://codecov.io/gh/apache/qpid-dispatch/pull/325?src=pr=tree)
```diff
@@Coverage Diff @@
## master #325 +/- ##
==
+ Coverage 86.54% 86.56% +0.02%
==
Files 69 69
Lines 1546015462 +2
==
+ Hits1338013385 +5
+ Misses 2080 2077 -3
```
| [Impacted
Files](https://codecov.io/gh/apache/qpid-dispatch/pull/325?src=pr=tree) |
Coverage Δ | |
|---|---|---|
|
[src/router\_core/agent\_link.c](https://codecov.io/gh/apache/qpid-dispatch/pull/325/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2FnZW50X2xpbmsuYw==)
| `63.21% <0%> (-0.58%)` | :arrow_down: |
|
[src/remote\_sasl.c](https://codecov.io/gh/apache/qpid-dispatch/pull/325/diff?src=pr=tree#diff-c3JjL3JlbW90ZV9zYXNsLmM=)
| `82.72% <0%> (-0.31%)` | :arrow_down: |
|
[src/parse.c](https://codecov.io/gh/apache/qpid-dispatch/pull/325/diff?src=pr=tree#diff-c3JjL3BhcnNlLmM=)
| `85.83% <0%> (-0.28%)` | :arrow_down: |
|
[src/iterator.c](https://codecov.io/gh/apache/qpid-dispatch/pull/325/diff?src=pr=tree#diff-c3JjL2l0ZXJhdG9yLmM=)
| `86.6% <0%> (-0.2%)` | :arrow_down: |
|
[src/message.c](https://codecov.io/gh/apache/qpid-dispatch/pull/325/diff?src=pr=tree#diff-c3JjL21lc3NhZ2UuYw==)
| `85.85% <0%> (-0.19%)` | :arrow_down: |
|
[src/router\_node.c](https://codecov.io/gh/apache/qpid-dispatch/pull/325/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9ub2RlLmM=)
| `94.57% <0%> (+0.14%)` | :arrow_up: |
|
[src/container.c](https://codecov.io/gh/apache/qpid-dispatch/pull/325/diff?src=pr=tree#diff-c3JjL2NvbnRhaW5lci5j)
| `71.54% <0%> (+0.14%)` | :arrow_up: |
|
[src/router\_core/connections.c](https://codecov.io/gh/apache/qpid-dispatch/pull/325/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2Nvbm5lY3Rpb25zLmM=)
| `95.24% <0%> (+0.23%)` | :arrow_up: |
|
[src/router\_core/router\_core.c](https://codecov.io/gh/apache/qpid-dispatch/pull/325/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL3JvdXRlcl9jb3JlLmM=)
| `99.25% <0%> (+0.37%)` | :arrow_up: |
|
[src/router\_core/transfer.c](https://codecov.io/gh/apache/qpid-dispatch/pull/325/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL3RyYW5zZmVyLmM=)
| `90.73% <0%> (+0.62%)` | :arrow_up: |
--
[Continue to review full report at
Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/325?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/325?src=pr=footer).
Last update
[e6864f6...8276d91](https://codecov.io/gh/apache/qpid-dispatch/pull/325?src=pr=lastupdated).
Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).
> Listeners with http enabled are not being shutdown after they are deleted
> -
>
> Key: DISPATCH-1037
> URL: https://issues.apache.org/jira/browse/DISPATCH-1037
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Routing Engine
>Reporter: Fernando Giorgetti
>Assignee: Ganesh Murthy
>Priority: Major
>
> When an http enabled listener is deleted through the console, or via qdmanage
> ($management), it is being removed from the list of listeners (qdmanage
> query) but the router still listens to the related TCP port.
> In the example below I had a router with an http listener on port 5674 and a
> non-http listener at 5672.
> Here are the steps to demonstrate it:
> * Start the router and query listeners
>
> {code:java}
> $ qdmanage query --type listener | egrep 'name'
> "name": "listener/0.0.0.0:5672",
> "name": "listener/0.0.0.0:5674",
> {code}
>
> * Verify TCP ports being listened
>
> {code:java}
> $
[GitHub] qpid-dispatch issue #325: DISPATCH-1037 - Prevented deleting listener with h...
Github user codecov-io commented on the issue: https://github.com/apache/qpid-dispatch/pull/325 # [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/325?src=pr=h1) Report > Merging [#325](https://codecov.io/gh/apache/qpid-dispatch/pull/325?src=pr=desc) into [master](https://codecov.io/gh/apache/qpid-dispatch/commit/e6864f63e7086b1fee0063ff22803cae1fc14a35?src=pr=desc) will **increase** coverage by `0.02%`. > The diff coverage is `n/a`. [](https://codecov.io/gh/apache/qpid-dispatch/pull/325?src=pr=tree) ```diff @@Coverage Diff @@ ## master #325 +/- ## == + Coverage 86.54% 86.56% +0.02% == Files 69 69 Lines 1546015462 +2 == + Hits1338013385 +5 + Misses 2080 2077 -3 ``` | [Impacted Files](https://codecov.io/gh/apache/qpid-dispatch/pull/325?src=pr=tree) | Coverage Π| | |---|---|---| | [src/router\_core/agent\_link.c](https://codecov.io/gh/apache/qpid-dispatch/pull/325/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2FnZW50X2xpbmsuYw==) | `63.21% <0%> (-0.58%)` | :arrow_down: | | [src/remote\_sasl.c](https://codecov.io/gh/apache/qpid-dispatch/pull/325/diff?src=pr=tree#diff-c3JjL3JlbW90ZV9zYXNsLmM=) | `82.72% <0%> (-0.31%)` | :arrow_down: | | [src/parse.c](https://codecov.io/gh/apache/qpid-dispatch/pull/325/diff?src=pr=tree#diff-c3JjL3BhcnNlLmM=) | `85.83% <0%> (-0.28%)` | :arrow_down: | | [src/iterator.c](https://codecov.io/gh/apache/qpid-dispatch/pull/325/diff?src=pr=tree#diff-c3JjL2l0ZXJhdG9yLmM=) | `86.6% <0%> (-0.2%)` | :arrow_down: | | [src/message.c](https://codecov.io/gh/apache/qpid-dispatch/pull/325/diff?src=pr=tree#diff-c3JjL21lc3NhZ2UuYw==) | `85.85% <0%> (-0.19%)` | :arrow_down: | | [src/router\_node.c](https://codecov.io/gh/apache/qpid-dispatch/pull/325/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9ub2RlLmM=) | `94.57% <0%> (+0.14%)` | :arrow_up: | | [src/container.c](https://codecov.io/gh/apache/qpid-dispatch/pull/325/diff?src=pr=tree#diff-c3JjL2NvbnRhaW5lci5j) | `71.54% <0%> (+0.14%)` | :arrow_up: | | [src/router\_core/connections.c](https://codecov.io/gh/apache/qpid-dispatch/pull/325/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2Nvbm5lY3Rpb25zLmM=) | `95.24% <0%> (+0.23%)` | :arrow_up: | | [src/router\_core/router\_core.c](https://codecov.io/gh/apache/qpid-dispatch/pull/325/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL3JvdXRlcl9jb3JlLmM=) | `99.25% <0%> (+0.37%)` | :arrow_up: | | [src/router\_core/transfer.c](https://codecov.io/gh/apache/qpid-dispatch/pull/325/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL3RyYW5zZmVyLmM=) | `90.73% <0%> (+0.62%)` | :arrow_up: | -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/325?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/325?src=pr=footer). Last update [e6864f6...8276d91](https://codecov.io/gh/apache/qpid-dispatch/pull/325?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] [Resolved] (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:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-1026.
-
Resolution: Fixed
Fix Version/s: 1.2.0
> 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
> Fix For: 1.2.0
>
>
> 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] [Commented] (DISPATCH-1037) Listeners with http enabled are not being shutdown after they are deleted
[
https://issues.apache.org/jira/browse/DISPATCH-1037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16511545#comment-16511545
]
ASF GitHub Bot commented on DISPATCH-1037:
--
GitHub user ganeshmurthy opened a pull request:
https://github.com/apache/qpid-dispatch/pull/325
DISPATCH-1037 - Prevented deleting listener with http: yes
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-1037
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/qpid-dispatch/pull/325.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 #325
commit 8276d91bfff40446f1a3e45a275ff0298331c569
Author: Ganesh Murthy
Date: 2018-06-13T18:50:56Z
DISPATCH-1037 - Prevented deleting listener with http: yes
> Listeners with http enabled are not being shutdown after they are deleted
> -
>
> Key: DISPATCH-1037
> URL: https://issues.apache.org/jira/browse/DISPATCH-1037
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Routing Engine
>Reporter: Fernando Giorgetti
>Assignee: Ganesh Murthy
>Priority: Major
>
> When an http enabled listener is deleted through the console, or via qdmanage
> ($management), it is being removed from the list of listeners (qdmanage
> query) but the router still listens to the related TCP port.
> In the example below I had a router with an http listener on port 5674 and a
> non-http listener at 5672.
> Here are the steps to demonstrate it:
> * Start the router and query listeners
>
> {code:java}
> $ qdmanage query --type listener | egrep 'name'
> "name": "listener/0.0.0.0:5672",
> "name": "listener/0.0.0.0:5674",
> {code}
>
> * Verify TCP ports being listened
>
> {code:java}
> $ netstat -anp | egrep tcp.*LISTEN.*qdrouterd
> tcp 0 0 0.0.0.0:5672 0.0.0.0:* LISTEN 2887/qdrouterd
> tcp 0 0 0.0.0.0:5674 0.0.0.0:* LISTEN 2887/qdrouterd
> {code}
>
> * Delete HTTP listener on port 5674
>
> {code:java}
> $ qdmanage delete --type listener --name 'listener/0.0.0.0:5674'
> {code}
>
> * Query listeners
>
> {code:java}
> $ qdmanage query --type listener | egrep 'name'
> "name": "listener/0.0.0.0:5672",
> {code}
>
> * Verify TCP ports being listened
>
> {code:java}
> $ netstat -anp | egrep tcp.*LISTEN.*qdrouterd
> tcp 0 0 0.0.0.0:5672 0.0.0.0:* LISTEN 2887/qdrouterd
> tcp 0 0 0.0.0.0:5674 0.0.0.0:* LISTEN 2887/qdrouterd
> {code}
>
> Note: This is only happening with http enabled listeners. Regular listeners
> are being shutdown properly.
--
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 #325: DISPATCH-1037 - Prevented deleting listener...
GitHub user ganeshmurthy opened a pull request: https://github.com/apache/qpid-dispatch/pull/325 DISPATCH-1037 - Prevented deleting listener with http: yes You can merge this pull request into a Git repository by running: $ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-1037 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/325.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 #325 commit 8276d91bfff40446f1a3e45a275ff0298331c569 Author: Ganesh Murthy Date: 2018-06-13T18:50:56Z DISPATCH-1037 - Prevented deleting listener with http: yes --- - 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 closed the pull request at: https://github.com/apache/qpid-dispatch/pull/324 --- - 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=16511541#comment-16511541
]
ASF GitHub Bot commented on DISPATCH-976:
-
Github user fgiorgetti closed the pull request at:
https://github.com/apache/qpid-dispatch/pull/324
> 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-1037) Listeners with http enabled are not being shutdown after they are deleted
[
https://issues.apache.org/jira/browse/DISPATCH-1037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16511493#comment-16511493
]
Ganesh Murthy commented on DISPATCH-1037:
-
Due to difficulty in deleting HTTP listeners via libwebsockets, we are no
longer allowing delete operation on HTTP listeners
> Listeners with http enabled are not being shutdown after they are deleted
> -
>
> Key: DISPATCH-1037
> URL: https://issues.apache.org/jira/browse/DISPATCH-1037
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Routing Engine
>Reporter: Fernando Giorgetti
>Assignee: Ganesh Murthy
>Priority: Major
>
> When an http enabled listener is deleted through the console, or via qdmanage
> ($management), it is being removed from the list of listeners (qdmanage
> query) but the router still listens to the related TCP port.
> In the example below I had a router with an http listener on port 5674 and a
> non-http listener at 5672.
> Here are the steps to demonstrate it:
> * Start the router and query listeners
>
> {code:java}
> $ qdmanage query --type listener | egrep 'name'
> "name": "listener/0.0.0.0:5672",
> "name": "listener/0.0.0.0:5674",
> {code}
>
> * Verify TCP ports being listened
>
> {code:java}
> $ netstat -anp | egrep tcp.*LISTEN.*qdrouterd
> tcp 0 0 0.0.0.0:5672 0.0.0.0:* LISTEN 2887/qdrouterd
> tcp 0 0 0.0.0.0:5674 0.0.0.0:* LISTEN 2887/qdrouterd
> {code}
>
> * Delete HTTP listener on port 5674
>
> {code:java}
> $ qdmanage delete --type listener --name 'listener/0.0.0.0:5674'
> {code}
>
> * Query listeners
>
> {code:java}
> $ qdmanage query --type listener | egrep 'name'
> "name": "listener/0.0.0.0:5672",
> {code}
>
> * Verify TCP ports being listened
>
> {code:java}
> $ netstat -anp | egrep tcp.*LISTEN.*qdrouterd
> tcp 0 0 0.0.0.0:5672 0.0.0.0:* LISTEN 2887/qdrouterd
> tcp 0 0 0.0.0.0:5674 0.0.0.0:* LISTEN 2887/qdrouterd
> {code}
>
> Note: This is only happening with http enabled listeners. Regular listeners
> are being shutdown properly.
--
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=16511490#comment-16511490
]
ASF GitHub Bot commented on DISPATCH-976:
-
Github user fgiorgetti commented on the issue:
https://github.com/apache/qpid-dispatch/pull/324
Done. Seems to be working fine.
> 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 Done. Seems to be working fine. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1860) [cpp] connection::container_id should return the *remote* container-id
[ https://issues.apache.org/jira/browse/PROTON-1860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved PROTON-1860. - Resolution: Fixed > [cpp] connection::container_id should return the *remote* container-id > -- > > Key: PROTON-1860 > URL: https://issues.apache.org/jira/browse/PROTON-1860 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.23.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.24.0 > > > connection::container_id() should return the ID of the remote container. It > is returning the ID of the local container. > The local conatiner-id is already available via connection.container().id(), > the remote id needs to be available for applications that need to identify > the remote container. > > -- 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-1860) [cpp] connection::container_id should return the *remote* container-id
[ https://issues.apache.org/jira/browse/PROTON-1860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16511477#comment-16511477 ] Alan Conway commented on PROTON-1860: - Fixed by: 563c9ee9 PROTON-1860: [cpp] connection::container_id returns the *remote* container-id > [cpp] connection::container_id should return the *remote* container-id > -- > > Key: PROTON-1860 > URL: https://issues.apache.org/jira/browse/PROTON-1860 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.23.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.24.0 > > > connection::container_id() should return the ID of the remote container. It > is returning the ID of the local container. > The local conatiner-id is already available via connection.container().id(), > the remote id needs to be available for applications that need to identify > the remote container. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-1860) [cpp] connection::container_id should return the *remote* container-id
[ https://issues.apache.org/jira/browse/PROTON-1860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway reassigned PROTON-1860: --- Assignee: Alan Conway > [cpp] connection::container_id should return the *remote* container-id > -- > > Key: PROTON-1860 > URL: https://issues.apache.org/jira/browse/PROTON-1860 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.23.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.24.0 > > > connection::container_id() should return the ID of the remote container. It > is returning the ID of the local container. > The local conatiner-id is already available via connection.container().id(), > the remote id needs to be available for applications that need to identify > the remote container. > > -- 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-1860) [cpp] connection::container_id should return the *remote* container-id
Alan Conway created PROTON-1860: --- Summary: [cpp] connection::container_id should return the *remote* container-id Key: PROTON-1860 URL: https://issues.apache.org/jira/browse/PROTON-1860 Project: Qpid Proton Issue Type: Bug Components: cpp-binding Affects Versions: proton-c-0.23.0 Reporter: Alan Conway Fix For: proton-c-0.24.0 connection::container_id() should return the ID of the remote container. It is returning the ID of the local container. The local conatiner-id is already available via connection.container().id(), the remote id needs to be available for applications that need to identify the remote container. -- 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-965) Python 3 compatibiliy
[ https://issues.apache.org/jira/browse/DISPATCH-965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved DISPATCH-965. - Resolution: Fixed Fix Version/s: 1.2.0 > Python 3 compatibiliy > - > > Key: DISPATCH-965 > URL: https://issues.apache.org/jira/browse/DISPATCH-965 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Routing Engine, Tests, Tools >Affects Versions: 1.0.1 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.2.0 > > > All python files in the project should add python 3 support (while remaining > compatible with python 2.7) -- 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] (QPID-8150) [Broker-J] Prevent test failures due to slow initialisation of hostname resolution in HostnameAliasImpl
[
https://issues.apache.org/jira/browse/QPID-8150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy resolved QPID-8150.
--
Resolution: Fixed
Assignee: (was: Rob Godfrey)
Changes look good to me
> [Broker-J] Prevent test failures due to slow initialisation of hostname
> resolution in HostnameAliasImpl
> ---
>
> Key: QPID-8150
> URL: https://issues.apache.org/jira/browse/QPID-8150
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Rob Godfrey
>Priority: Major
> Fix For: qpid-java-broker-7.1.0
>
>
> On some operating systems / configurations (notably my laptop running OS X :)
> ) the resolution of potential hostnames which resolve to the local machine
> which takes place in {{HostnameAliasImpl}} can take a long time due to
> fruitless lookups. This can cause various system tests to fail.
> To prevent these failures
> # Do not include the hostname virtual host alias where it is not needed in
> the system tests
> # Reorder the list of {{InetAddress}} objects that are iterated over in the
> resolution phase so that addresses more likely to resolve (like the loopback
> interface) are processed first
--
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-8150) [Broker-J] Prevent test failures due to slow initialisation of hostname resolution in HostnameAliasImpl
[
https://issues.apache.org/jira/browse/QPID-8150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16511277#comment-16511277
]
ASF subversion and git services commented on QPID-8150:
---
Commit f4196afe7c4840bef3672b5cb306640053f2dd8f 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=f4196af ]
QPID-8150: [Broker-J][Tests] Remove redundant hostname alias settings from
broker configuration for AMQP 0-10 protocol tests
> [Broker-J] Prevent test failures due to slow initialisation of hostname
> resolution in HostnameAliasImpl
> ---
>
> Key: QPID-8150
> URL: https://issues.apache.org/jira/browse/QPID-8150
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
>Priority: Major
> Fix For: qpid-java-broker-7.1.0
>
>
> On some operating systems / configurations (notably my laptop running OS X :)
> ) the resolution of potential hostnames which resolve to the local machine
> which takes place in {{HostnameAliasImpl}} can take a long time due to
> fruitless lookups. This can cause various system tests to fail.
> To prevent these failures
> # Do not include the hostname virtual host alias where it is not needed in
> the system tests
> # Reorder the list of {{InetAddress}} objects that are iterated over in the
> resolution phase so that addresses more likely to resolve (like the loopback
> interface) are processed first
--
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 issue #149: Do not merge - just testing....
Github user kgiusti commented on the issue: https://github.com/apache/qpid-proton/pull/149 Done testing --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-proton pull request #149: Do not merge - just testing....
Github user kgiusti closed the pull request at: https://github.com/apache/qpid-proton/pull/149 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-proton issue #149: Do not merge - just testing....
Github user codecov-io commented on the issue: https://github.com/apache/qpid-proton/pull/149 # [Codecov](https://codecov.io/gh/apache/qpid-proton/pull/149?src=pr=h1) Report > Merging [#149](https://codecov.io/gh/apache/qpid-proton/pull/149?src=pr=desc) into [master](https://codecov.io/gh/apache/qpid-proton/commit/5bc84443c4092286e2447a522a08014295d484c8?src=pr=desc) will **decrease** coverage by `0.01%`. > The diff coverage is `n/a`. [](https://codecov.io/gh/apache/qpid-proton/pull/149?src=pr=tree) ```diff @@Coverage Diff @@ ## master #149 +/- ## == - Coverage 86.43% 86.41% -0.02% == Files 247 247 Lines 3031530320 +5 == Hits2620226202 - Misses 4113 4118 +5 ``` | [Impacted Files](https://codecov.io/gh/apache/qpid-proton/pull/149?src=pr=tree) | Coverage Π| | |---|---|---| | [c/src/core/codec.c](https://codecov.io/gh/apache/qpid-proton/pull/149/diff?src=pr=tree#diff-Yy9zcmMvY29yZS9jb2RlYy5j) | `81.93% <0%> (-0.32%)` | :arrow_down: | -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/qpid-proton/pull/149?src=pr=continue). > **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta) > `Π= absolute (impact)`, `ø = not affected`, `? = missing data` > Powered by [Codecov](https://codecov.io/gh/apache/qpid-proton/pull/149?src=pr=footer). Last update [5bc8444...dc0bc67](https://codecov.io/gh/apache/qpid-proton/pull/149?src=pr=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments). --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1037) Listeners with http enabled are not being shutdown after they are deleted
Fernando Giorgetti created DISPATCH-1037:
Summary: Listeners with http enabled are not being shutdown after
they are deleted
Key: DISPATCH-1037
URL: https://issues.apache.org/jira/browse/DISPATCH-1037
Project: Qpid Dispatch
Issue Type: Bug
Components: Routing Engine
Reporter: Fernando Giorgetti
When an http enabled listener is deleted through the console, or via qdmanage
($management), it is being removed from the list of listeners (qdmanage query)
but the router still listens to the related TCP port.
In the example below I had a router with an http listener on port 5674 and a
non-http listener at 5672.
Here are the steps to demonstrate it:
* Start the router and query listeners
{code:java}
$ qdmanage query --type listener | egrep 'name'
"name": "listener/0.0.0.0:5672",
"name": "listener/0.0.0.0:5674",
{code}
* Verify TCP ports being listened
{code:java}
$ netstat -anp | egrep tcp.*LISTEN.*qdrouterd
tcp 0 0 0.0.0.0:5672 0.0.0.0:* LISTEN 2887/qdrouterd
tcp 0 0 0.0.0.0:5674 0.0.0.0:* LISTEN 2887/qdrouterd
{code}
* Delete HTTP listener on port 5674
{code:java}
$ qdmanage delete --type listener --name 'listener/0.0.0.0:5674'
{code}
* Query listeners
{code:java}
$ qdmanage query --type listener | egrep 'name'
"name": "listener/0.0.0.0:5672",
{code}
* Verify TCP ports being listened
{code:java}
$ netstat -anp | egrep tcp.*LISTEN.*qdrouterd
tcp 0 0 0.0.0.0:5672 0.0.0.0:* LISTEN 2887/qdrouterd
tcp 0 0 0.0.0.0:5674 0.0.0.0:* LISTEN 2887/qdrouterd
{code}
Note: This is only happening with http enabled listeners. Regular listeners are
being shutdown properly.
--
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-1030) Empty table on Entities page of console
[ https://issues.apache.org/jira/browse/DISPATCH-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen resolved DISPATCH-1030. Resolution: Fixed Fix Version/s: 1.2.0 Added ui-grid-auto-resize to html and called gridApi resize functions to force a resize of grid. > Empty table on Entities page of console > --- > > Key: DISPATCH-1030 > URL: https://issues.apache.org/jira/browse/DISPATCH-1030 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 1.1.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Minor > Fix For: 1.2.0 > > > Expanding a new entity in the tree on the left on the Entities page shows an > empty grid on the right. > To see the full grid you need to either resize the browser or switch to > another console page and return. -- 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-1030) Empty table on Entities page of console
[ https://issues.apache.org/jira/browse/DISPATCH-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16511160#comment-16511160 ] ASF subversion and git services commented on DISPATCH-1030: --- Commit 0682ec69552a897bf890d2466ade50adabb737d1 in qpid-dispatch's branch refs/heads/master from [~eallen] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=0682ec6 ] DISPATCH-1030 Ensure grid is resized properly on console Entities page > Empty table on Entities page of console > --- > > Key: DISPATCH-1030 > URL: https://issues.apache.org/jira/browse/DISPATCH-1030 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 1.1.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Minor > > Expanding a new entity in the tree on the left on the Entities page shows an > empty grid on the right. > To see the full grid you need to either resize the browser or switch to > another console page and return. -- 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=16511155#comment-16511155
]
ASF GitHub Bot commented on DISPATCH-976:
-
Github user ChugR commented on the issue:
https://github.com/apache/qpid-dispatch/pull/324
Looking at it again I think all three of these need_check_* booleans are
suspect. Don't delete just the one, get rid of them all.
> 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 ChugR commented on the issue: https://github.com/apache/qpid-dispatch/pull/324 Looking at it again I think all three of these need_check_* booleans are suspect. Don't delete just the one, get rid of them all. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-proton pull request #149: Do not merge - just testing....
GitHub user kgiusti opened a pull request: https://github.com/apache/qpid-proton/pull/149 Do not merge - just testing Sorry for the noise, please disregard. I will delete this PR once travis is done. You can merge this pull request into a Git repository by running: $ git pull https://github.com/kgiusti/qpid-proton KAG-TEST-IGNORE Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-proton/pull/149.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 #149 commit dc0bc67426c52505a03687105da0d591ba5a352b Author: Kenneth Giusti Date: 2018-06-13T13:17:42Z Do not merge - just testing --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1036) Dropdown lists on the Entity page are the wrong color
[ https://issues.apache.org/jira/browse/DISPATCH-1036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1651#comment-1651 ] ASF subversion and git services commented on DISPATCH-1036: --- Commit 21af29f056bc9f9998e17f18272c8181d8dfaf98 in qpid-dispatch's branch refs/heads/master from [~eallen] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=21af29f ] DISPATCH-1036 Fixed select list style on console Entities page > Dropdown lists on the Entity page are the wrong color > - > > Key: DISPATCH-1036 > URL: https://issues.apache.org/jira/browse/DISPATCH-1036 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 1.1.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Major > Fix For: 1.2.0 > > > Any entity that allows CREATE on the Entities page will show a black > background for a dropdown select list. It is difficult to read the black text > on a black background. -- 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-1036) Dropdown lists on the Entity page are the wrong color
[ https://issues.apache.org/jira/browse/DISPATCH-1036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen resolved DISPATCH-1036. Resolution: Fixed Fix Version/s: 1.2.0 > Dropdown lists on the Entity page are the wrong color > - > > Key: DISPATCH-1036 > URL: https://issues.apache.org/jira/browse/DISPATCH-1036 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 1.1.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Major > Fix For: 1.2.0 > > > Any entity that allows CREATE on the Entities page will show a black > background for a dropdown select list. It is difficult to read the black text > on a black background. -- 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-1036) Dropdown lists on the Entity page are the wrong color
Ernest Allen created DISPATCH-1036: -- Summary: Dropdown lists on the Entity page are the wrong color Key: DISPATCH-1036 URL: https://issues.apache.org/jira/browse/DISPATCH-1036 Project: Qpid Dispatch Issue Type: Bug Components: Console Affects Versions: 1.1.0 Reporter: Ernest Allen Assignee: Ernest Allen Any entity that allows CREATE on the Entities page will show a black background for a dropdown select list. It is difficult to read the black text on a black background. -- 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-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:all-tabpanel ] Ernest Allen resolved DISPATCH-1003. Resolution: Fixed Fix Version/s: 1.2.0 Sasl authentication using PLAIN succeeds when the correct username/password is provided and fails when no/incorrect credentials are used. > 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 > Fix For: 1.2.0 > > > 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] [Closed] (DISPATCH-1018) CLONE - Install console dependencies with npm during make install
[ https://issues.apache.org/jira/browse/DISPATCH-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen closed DISPATCH-1018. -- Resolution: Resolved DISPATCH-1017 accomplishes the goal of this Jira. The console no longer needs an 'npm install' step after installation. Once the router is built and installed, the console is immediately available if an http: true listener is present. > CLONE - Install console dependencies with npm during make install > - > > Key: DISPATCH-1018 > URL: https://issues.apache.org/jira/browse/DISPATCH-1018 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Console >Affects Versions: 1.0.0 >Reporter: Alan Conway >Assignee: Ernest Allen >Priority: Major > Fix For: 1.2.0 > > Attachments: > 0001-NEED-JIRA-install-NPM-files-automatically-as-part-of.patch > > > During a make install, the stand-alone console's dependencies should be > installed using the command 'npm install' executed from the console's install > directory. -- 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] (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 resolved PROTON-1859. - Resolution: Fixed > [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] [Resolved] (PROTON-1855) [ruby] copy link terminus state for incoming links
[ https://issues.apache.org/jira/browse/PROTON-1855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved PROTON-1855. - Resolution: Fixed > [ruby] copy link terminus state for incoming links > -- > > Key: PROTON-1855 > URL: https://issues.apache.org/jira/browse/PROTON-1855 > 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 > > > For incoming links, the remote terminus state should be copied to the local > state automatically before the application handlers see the link object. This > way all relevant link state can be accessed using the simple get/set methods. > Other bindings do this, it is an oversight that ruby does not. -- 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-1033) Incorrect location for legend on Message flow page in console
[ https://issues.apache.org/jira/browse/DISPATCH-1033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen resolved DISPATCH-1033. Resolution: Fixed Fix Version/s: 1.2.0 Added left and top styles to media css selector. > Incorrect location for legend on Message flow page in console > - > > Key: DISPATCH-1033 > URL: https://issues.apache.org/jira/browse/DISPATCH-1033 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 1.1.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Minor > Fix For: 1.2.0 > > > When the console is view using a narrow browser (< 768px wide) and the legend > is displayed using the page menu (three horizontal bars in the upper left), > the legend is displayed in the incorrect place. The legend has a margin on > the left and top. > Remove the margin on the left and top of the legend when the console is in > narrow mode. -- 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] (PROTON-1856) [ruby] auto-accept over-writing user transfer state
[ https://issues.apache.org/jira/browse/PROTON-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved PROTON-1856. - Resolution: Fixed > [ruby] auto-accept over-writing user transfer state > --- > > Key: PROTON-1856 > URL: https://issues.apache.org/jira/browse/PROTON-1856 > 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-1033) Incorrect location for legend on Message flow page in console
[ https://issues.apache.org/jira/browse/DISPATCH-1033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16511088#comment-16511088 ] ASF subversion and git services commented on DISPATCH-1033: --- Commit c91e13cb663d54bfad31e63739ce62260d3489de in qpid-dispatch's branch refs/heads/master from [~eallen] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=c91e13c ] DISPATCH-1033 Fix legend position on Message Flow console page > Incorrect location for legend on Message flow page in console > - > > Key: DISPATCH-1033 > URL: https://issues.apache.org/jira/browse/DISPATCH-1033 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 1.1.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Minor > > When the console is view using a narrow browser (< 768px wide) and the legend > is displayed using the page menu (three horizontal bars in the upper left), > the legend is displayed in the incorrect place. The legend has a margin on > the left and top. > Remove the margin on the left and top of the legend when the console is in > narrow mode. -- 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-1855) [ruby] copy link terminus state for incoming links
[ https://issues.apache.org/jira/browse/PROTON-1855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16511079#comment-16511079 ] ASF subversion and git services commented on PROTON-1855: - Commit 24a142e429c2678d340207d83ed9662e15c72d92 in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=24a142e ] PROTON-1855: [ruby] copy terminus data for remotely-initiated links > [ruby] copy link terminus state for incoming links > -- > > Key: PROTON-1855 > URL: https://issues.apache.org/jira/browse/PROTON-1855 > 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 > > > For incoming links, the remote terminus state should be copied to the local > state automatically before the application handlers see the link object. This > way all relevant link state can be accessed using the simple get/set methods. > Other bindings do this, it is an oversight that ruby does not. -- 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-1859) [cpp] auto-accept over-writing user transfer state
[ https://issues.apache.org/jira/browse/PROTON-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16511081#comment-16511081 ] ASF subversion and git services commented on PROTON-1859: - Commit 5bc84443c4092286e2447a522a08014295d484c8 in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=5bc8444 ] PROTON-1859: [cpp] auto-accept over-writing user transfer state messaging_adapter was incorrectly checking settled() to determine if the local handler had settled a transfer, settled() returns the *remote* state. For a delivery that was not yet settled remotely, this would over-write the state set by the user handler. Check for local_state == 0 instead. > [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] [Commented] (PROTON-1856) [ruby] auto-accept over-writing user transfer state
[ https://issues.apache.org/jira/browse/PROTON-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16511080#comment-16511080 ] ASF subversion and git services commented on PROTON-1856: - Commit c7205a63db7d14e209d627be9be8314a49536e57 in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=c7205a6 ] PROTON-1856: [ruby] auto_accept overwriting user state MessagomgAdapter was incorrectly checking settled? to determine if the local handler had settled a transfer, but #settled? returns the *remote* state. For a delivery that was not yet settled remotely, this would over-write the state set by the user handler. Check for local_state == 0 instead. > [ruby] auto-accept over-writing user transfer state > --- > > Key: PROTON-1856 > URL: https://issues.apache.org/jira/browse/PROTON-1856 > 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] [Resolved] (DISPATCH-1031) Remove the links associated with a console from the console's overview page
[ https://issues.apache.org/jira/browse/DISPATCH-1031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen resolved DISPATCH-1031. Resolution: Fixed Fix Version/s: 1.2.0 Filtered out all addresses starting with Ltemp. > Remove the links associated with a console from the console's overview page > --- > > Key: DISPATCH-1031 > URL: https://issues.apache.org/jira/browse/DISPATCH-1031 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 1.1.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Minor > Fix For: 1.2.0 > > > The overview page of the console has a top links grid that shows the > statistics for the most active links in terms of delivery rate. When the > router network is idle, the links to the console are the most active links. > * Filter out the links associated with a console. > * If there are no active links, show a message > > -- 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-1031) Remove the links associated with a console from the console's overview page
[ https://issues.apache.org/jira/browse/DISPATCH-1031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16511000#comment-16511000 ] ASF subversion and git services commented on DISPATCH-1031: --- Commit 5402cd336754d900bb79f58f32531e3abeb3 in qpid-dispatch's branch refs/heads/master from [~eallen] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=5402cd3 ] DISPATCH-1031 Filter out internal addresses from top addresses list on overview page of console > Remove the links associated with a console from the console's overview page > --- > > Key: DISPATCH-1031 > URL: https://issues.apache.org/jira/browse/DISPATCH-1031 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 1.1.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Minor > > The overview page of the console has a top links grid that shows the > statistics for the most active links in terms of delivery rate. When the > router network is idle, the links to the console are the most active links. > * Filter out the links associated with a console. > * If there are no active links, show a message > > -- 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-392) Stalled Service Bus Subscriptions, Reconnect Loops
[
https://issues.apache.org/jira/browse/QPIDJMS-392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510979#comment-16510979
]
Paul Rogalinski commented on QPIDJMS-392:
-
Thanks for the clarification. Configured the application to log both variants.
Will come back as soon we have collected data of a new incident.
> 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 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:
[jira] [Resolved] (DISPATCH-1029) State is not retained on Entities tree for console
[ https://issues.apache.org/jira/browse/DISPATCH-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen resolved DISPATCH-1029. Resolution: Fixed Fix Version/s: 1.2.0 Handle the collapse event in the jquery.fancytree control. > State is not retained on Entities tree for console > -- > > Key: DISPATCH-1029 > URL: https://issues.apache.org/jira/browse/DISPATCH-1029 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 1.1.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Minor > Fix For: 1.2.0 > > > The expanded/collapsed state of the tree on the left on the Entitles page of > the console is not retained or restored between page loads. > -- 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-1029) State is not retained on Entities tree for console
[ https://issues.apache.org/jira/browse/DISPATCH-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510969#comment-16510969 ] ASF subversion and git services commented on DISPATCH-1029: --- Commit 33fa99832f2012fb6fa39ab29b41d0c65bcb914c in qpid-dispatch's branch refs/heads/master from [~eallen] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=33fa998 ] DISPATCH-1029 Remember the expanded state for Entities and Overview pages in console > State is not retained on Entities tree for console > -- > > Key: DISPATCH-1029 > URL: https://issues.apache.org/jira/browse/DISPATCH-1029 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 1.1.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Minor > > The expanded/collapsed state of the tree on the left on the Entitles page of > the console is not retained or restored between page loads. > -- 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-392) Stalled Service Bus Subscriptions, Reconnect Loops
[
https://issues.apache.org/jira/browse/QPIDJMS-392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510963#comment-16510963
]
Robbie Gemmell commented on QPIDJMS-392:
Note that in general PN_TRACE_FRM is fine (and slightly more detailed in some
ways due to lower level access), but in this case having the trace from
_amqp.traceFrames_ would be good also since it is timestamped in line with your
logging settings.
> 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 handling. This does at least explain
> the
[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=16510962#comment-16510962
]
Robbie Gemmell commented on QPIDJMS-392:
The options methods are called by reflection when using URI options, so you
simply wont see it in method usages and thats unrelated to any issue you are
having.
I'm guessing you have applied the _amqp.traceFrames_ option outside the
failover URI rather than on the inner server URI, see here for details of how
to set the options when using failover:
http://qpid.apache.org/releases/qpid-jms-0.32.0/docs/index.html#failover-configuration-options
> 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
[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=16510954#comment-16510954
]
Paul Rogalinski commented on QPIDJMS-392:
-
[~gemmellr]
_amqp.traceFrames=true_ URL parameter seems to be only effective within
Unit-Tests and not for API consumers. According to the usages of setTraceFrames
-> updateTracer in AmqpProvider there are no other calls to that code path
other than from Unit Tests. _PN_TRACE_FRM_ works on the other hand. We will be
collecting data frames logged by using the latter method hoping for the issue
to crop up again soon. If there is any reason to use the ProtocolTracer defined
in AmqpProvider - please let me know. I would need to shortwire that in a
forked version of qpid-jms-client and deploy a customized variant of the
application.
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
