[jira] [Commented] (DISPATCH-1081) Messages to multicast addresses are being released when no receivers attached
[
https://issues.apache.org/jira/browse/DISPATCH-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16635998#comment-16635998
]
ASF GitHub Bot commented on DISPATCH-1081:
--
Github user bhardesty closed the pull request at:
https://github.com/apache/qpid-dispatch/pull/376
> Messages to multicast addresses are being released when no receivers attached
> -
>
> Key: DISPATCH-1081
> URL: https://issues.apache.org/jira/browse/DISPATCH-1081
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Alexander Rafferty
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.4.0
>
>
> When sending messages to a multicast address to which no consumers are
> attached, the router sends back a disposition of RELEASED. The expected
> behaviour is that all messages will be immediately settled by the ingress
> router with a disposition of ACCEPTED as per section 2.4.1 of the Dispatch
> router book:
> {quote}Multicast delivery is not reliable. If a producer sends an unsettled
> delivery, the ingress router shall settle the delivery with ACCEPTED
> disposition regardless of whether the message was delivered to any consumers.
> {quote}
> Is this a bug, or is this the expected behaviour? If this is the expected
> behaviour, can the router be configured to always accept messages to
> multicast addresses even where no consumers are actively listening?
--
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 #376: DISPATCH-1081 - Update doc for multicast de...
Github user bhardesty closed the pull request at: https://github.com/apache/qpid-dispatch/pull/376 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1081) Messages to multicast addresses are being released when no receivers attached
[
https://issues.apache.org/jira/browse/DISPATCH-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-1081.
-
Resolution: Fixed
Fix Version/s: 1.4.0
> Messages to multicast addresses are being released when no receivers attached
> -
>
> Key: DISPATCH-1081
> URL: https://issues.apache.org/jira/browse/DISPATCH-1081
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Alexander Rafferty
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.4.0
>
>
> When sending messages to a multicast address to which no consumers are
> attached, the router sends back a disposition of RELEASED. The expected
> behaviour is that all messages will be immediately settled by the ingress
> router with a disposition of ACCEPTED as per section 2.4.1 of the Dispatch
> router book:
> {quote}Multicast delivery is not reliable. If a producer sends an unsettled
> delivery, the ingress router shall settle the delivery with ACCEPTED
> disposition regardless of whether the message was delivered to any consumers.
> {quote}
> Is this a bug, or is this the expected behaviour? If this is the expected
> behaviour, can the router be configured to always accept messages to
> multicast addresses even where no consumers are actively listening?
--
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-1081) Messages to multicast addresses are being released when no receivers attached
[
https://issues.apache.org/jira/browse/DISPATCH-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16635992#comment-16635992
]
ASF subversion and git services commented on DISPATCH-1081:
---
Commit 6689d5f1d6dc343ab0482befcf3286479aef2e04 in qpid-dispatch's branch
refs/heads/master from [~bhardest]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=6689d5f ]
DISPATCH-1081 - Update doc for multicast delivery settlement
> Messages to multicast addresses are being released when no receivers attached
> -
>
> Key: DISPATCH-1081
> URL: https://issues.apache.org/jira/browse/DISPATCH-1081
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Alexander Rafferty
>Assignee: Ganesh Murthy
>Priority: Major
>
> When sending messages to a multicast address to which no consumers are
> attached, the router sends back a disposition of RELEASED. The expected
> behaviour is that all messages will be immediately settled by the ingress
> router with a disposition of ACCEPTED as per section 2.4.1 of the Dispatch
> router book:
> {quote}Multicast delivery is not reliable. If a producer sends an unsettled
> delivery, the ingress router shall settle the delivery with ACCEPTED
> disposition regardless of whether the message was delivered to any consumers.
> {quote}
> Is this a bug, or is this the expected behaviour? If this is the expected
> behaviour, can the router be configured to always accept messages to
> multicast addresses even where no consumers are actively listening?
--
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-1081) Messages to multicast addresses are being released when no receivers attached
[
https://issues.apache.org/jira/browse/DISPATCH-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16635970#comment-16635970
]
ASF GitHub Bot commented on DISPATCH-1081:
--
Github user ganeshmurthy commented on the issue:
https://github.com/apache/qpid-dispatch/pull/376
I will merge this shortly, thanks.
> Messages to multicast addresses are being released when no receivers attached
> -
>
> Key: DISPATCH-1081
> URL: https://issues.apache.org/jira/browse/DISPATCH-1081
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Alexander Rafferty
>Assignee: Ganesh Murthy
>Priority: Major
>
> When sending messages to a multicast address to which no consumers are
> attached, the router sends back a disposition of RELEASED. The expected
> behaviour is that all messages will be immediately settled by the ingress
> router with a disposition of ACCEPTED as per section 2.4.1 of the Dispatch
> router book:
> {quote}Multicast delivery is not reliable. If a producer sends an unsettled
> delivery, the ingress router shall settle the delivery with ACCEPTED
> disposition regardless of whether the message was delivered to any consumers.
> {quote}
> Is this a bug, or is this the expected behaviour? If this is the expected
> behaviour, can the router be configured to always accept messages to
> multicast addresses even where no consumers are actively listening?
--
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 #376: DISPATCH-1081 - Update doc for multicast delivery ...
Github user ganeshmurthy commented on the issue: https://github.com/apache/qpid-dispatch/pull/376 I will merge this shortly, thanks. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1081) Messages to multicast addresses are being released when no receivers attached
[
https://issues.apache.org/jira/browse/DISPATCH-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16635936#comment-16635936
]
ASF GitHub Bot commented on DISPATCH-1081:
--
Github user codecov-io commented on the issue:
https://github.com/apache/qpid-dispatch/pull/376
#
[Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/376?src=pr&el=h1)
Report
> Merging
[#376](https://codecov.io/gh/apache/qpid-dispatch/pull/376?src=pr&el=desc) into
[master](https://codecov.io/gh/apache/qpid-dispatch/commit/c392ea84e639a7d2e1c7cb765b047b698d2f0521?src=pr&el=desc)
will **decrease** coverage by `0.04%`.
> The diff coverage is `n/a`.
[](https://codecov.io/gh/apache/qpid-dispatch/pull/376?src=pr&el=tree)
```diff
@@Coverage Diff @@
## master #376 +/- ##
==
- Coverage 84.85% 84.81% -0.05%
==
Files 70 73 +3
Lines 1607316475 +402
==
+ Hits1363913973 +334
- Misses 2434 2502 +68
```
| [Impacted
Files](https://codecov.io/gh/apache/qpid-dispatch/pull/376?src=pr&el=tree) |
Coverage Δ | |
|---|---|---|
|
[src/server.c](https://codecov.io/gh/apache/qpid-dispatch/pull/376/diff?src=pr&el=tree#diff-c3JjL3NlcnZlci5j)
| `82.3% <0%> (-2.14%)` | :arrow_down: |
|
[src/message.c](https://codecov.io/gh/apache/qpid-dispatch/pull/376/diff?src=pr&el=tree#diff-c3JjL21lc3NhZ2UuYw==)
| `88.06% <0%> (-0.61%)` | :arrow_down: |
|
[src/router\_core/agent\_link.c](https://codecov.io/gh/apache/qpid-dispatch/pull/376/diff?src=pr&el=tree#diff-c3JjL3JvdXRlcl9jb3JlL2FnZW50X2xpbmsuYw==)
| `63.21% <0%> (-0.58%)` | :arrow_down: |
|
[src/router\_core/router\_core.c](https://codecov.io/gh/apache/qpid-dispatch/pull/376/diff?src=pr&el=tree#diff-c3JjL3JvdXRlcl9jb3JlL3JvdXRlcl9jb3JlLmM=)
| `92.07% <0%> (-0.16%)` | :arrow_down: |
|
[src/remote\_sasl.c](https://codecov.io/gh/apache/qpid-dispatch/pull/376/diff?src=pr&el=tree#diff-c3JjL3JlbW90ZV9zYXNsLmM=)
| `1.15% <0%> (-0.01%)` | :arrow_down: |
|
[src/router\_core/router\_core\_thread.c](https://codecov.io/gh/apache/qpid-dispatch/pull/376/diff?src=pr&el=tree#diff-c3JjL3JvdXRlcl9jb3JlL3JvdXRlcl9jb3JlX3RocmVhZC5j)
| `100% <0%> (ø)` | :arrow_up: |
|
[src/router\_core/edge\_control.c](https://codecov.io/gh/apache/qpid-dispatch/pull/376/diff?src=pr&el=tree#diff-c3JjL3JvdXRlcl9jb3JlL2VkZ2VfY29udHJvbC5j)
| `80% <0%> (ø)` | |
|
[src/router\_core/core\_link\_endpoint.c](https://codecov.io/gh/apache/qpid-dispatch/pull/376/diff?src=pr&el=tree#diff-c3JjL3JvdXRlcl9jb3JlL2NvcmVfbGlua19lbmRwb2ludC5j)
| `80% <0%> (ø)` | |
|
[src/router\_core/modules/core\_test\_hooks.c](https://codecov.io/gh/apache/qpid-dispatch/pull/376/diff?src=pr&el=tree#diff-c3JjL3JvdXRlcl9jb3JlL21vZHVsZXMvY29yZV90ZXN0X2hvb2tzLmM=)
| `87.02% <0%> (ø)` | |
|
[src/router\_node.c](https://codecov.io/gh/apache/qpid-dispatch/pull/376/diff?src=pr&el=tree#diff-c3JjL3JvdXRlcl9ub2RlLmM=)
| `93.75% <0%> (ø)` | :arrow_up: |
| ... and [6
more](https://codecov.io/gh/apache/qpid-dispatch/pull/376/diff?src=pr&el=tree-more)
| |
--
[Continue to review full report at
Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/376?src=pr&el=continue).
> **Legend** - [Click here to learn
more](https://docs.codecov.io/docs/codecov-delta)
> `Δ = absolute (impact)`, `ø = not affected`, `? = missing data`
> Powered by
[Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/376?src=pr&el=footer).
Last update
[c392ea8...a1e3f5d](https://codecov.io/gh/apache/qpid-dispatch/pull/376?src=pr&el=lastupdated).
Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).
> Messages to multicast addresses are being released when no receivers attached
> -
>
> Key: DISPATCH-1081
> URL: https://issues.apache.org/jira/browse/DISPATCH-1081
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Alexander Rafferty
>Assignee: Ganesh Murthy
>Priority: Major
>
> When sending messages to a multicast address to which no consumers are
> attached, the router sends back a disposition of RELEASED. The expected
> behaviour is that all messages will be immediately settled by the ingress
> router with a disposition of ACCEPTED as per section 2.4.1 of the Dispatch
> router book:
> {quote}Multicast delivery is
[GitHub] qpid-dispatch issue #376: DISPATCH-1081 - Update doc for multicast delivery ...
Github user codecov-io commented on the issue: https://github.com/apache/qpid-dispatch/pull/376 # [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/376?src=pr&el=h1) Report > Merging [#376](https://codecov.io/gh/apache/qpid-dispatch/pull/376?src=pr&el=desc) into [master](https://codecov.io/gh/apache/qpid-dispatch/commit/c392ea84e639a7d2e1c7cb765b047b698d2f0521?src=pr&el=desc) will **decrease** coverage by `0.04%`. > The diff coverage is `n/a`. [](https://codecov.io/gh/apache/qpid-dispatch/pull/376?src=pr&el=tree) ```diff @@Coverage Diff @@ ## master #376 +/- ## == - Coverage 84.85% 84.81% -0.05% == Files 70 73 +3 Lines 1607316475 +402 == + Hits1363913973 +334 - Misses 2434 2502 +68 ``` | [Impacted Files](https://codecov.io/gh/apache/qpid-dispatch/pull/376?src=pr&el=tree) | Coverage Π| | |---|---|---| | [src/server.c](https://codecov.io/gh/apache/qpid-dispatch/pull/376/diff?src=pr&el=tree#diff-c3JjL3NlcnZlci5j) | `82.3% <0%> (-2.14%)` | :arrow_down: | | [src/message.c](https://codecov.io/gh/apache/qpid-dispatch/pull/376/diff?src=pr&el=tree#diff-c3JjL21lc3NhZ2UuYw==) | `88.06% <0%> (-0.61%)` | :arrow_down: | | [src/router\_core/agent\_link.c](https://codecov.io/gh/apache/qpid-dispatch/pull/376/diff?src=pr&el=tree#diff-c3JjL3JvdXRlcl9jb3JlL2FnZW50X2xpbmsuYw==) | `63.21% <0%> (-0.58%)` | :arrow_down: | | [src/router\_core/router\_core.c](https://codecov.io/gh/apache/qpid-dispatch/pull/376/diff?src=pr&el=tree#diff-c3JjL3JvdXRlcl9jb3JlL3JvdXRlcl9jb3JlLmM=) | `92.07% <0%> (-0.16%)` | :arrow_down: | | [src/remote\_sasl.c](https://codecov.io/gh/apache/qpid-dispatch/pull/376/diff?src=pr&el=tree#diff-c3JjL3JlbW90ZV9zYXNsLmM=) | `1.15% <0%> (-0.01%)` | :arrow_down: | | [src/router\_core/router\_core\_thread.c](https://codecov.io/gh/apache/qpid-dispatch/pull/376/diff?src=pr&el=tree#diff-c3JjL3JvdXRlcl9jb3JlL3JvdXRlcl9jb3JlX3RocmVhZC5j) | `100% <0%> (ø)` | :arrow_up: | | [src/router\_core/edge\_control.c](https://codecov.io/gh/apache/qpid-dispatch/pull/376/diff?src=pr&el=tree#diff-c3JjL3JvdXRlcl9jb3JlL2VkZ2VfY29udHJvbC5j) | `80% <0%> (ø)` | | | [src/router\_core/core\_link\_endpoint.c](https://codecov.io/gh/apache/qpid-dispatch/pull/376/diff?src=pr&el=tree#diff-c3JjL3JvdXRlcl9jb3JlL2NvcmVfbGlua19lbmRwb2ludC5j) | `80% <0%> (ø)` | | | [src/router\_core/modules/core\_test\_hooks.c](https://codecov.io/gh/apache/qpid-dispatch/pull/376/diff?src=pr&el=tree#diff-c3JjL3JvdXRlcl9jb3JlL21vZHVsZXMvY29yZV90ZXN0X2hvb2tzLmM=) | `87.02% <0%> (ø)` | | | [src/router\_node.c](https://codecov.io/gh/apache/qpid-dispatch/pull/376/diff?src=pr&el=tree#diff-c3JjL3JvdXRlcl9ub2RlLmM=) | `93.75% <0%> (ø)` | :arrow_up: | | ... and [6 more](https://codecov.io/gh/apache/qpid-dispatch/pull/376/diff?src=pr&el=tree-more) | | -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/376?src=pr&el=continue). > **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta) > `Π= absolute (impact)`, `ø = not affected`, `? = missing data` > Powered by [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/376?src=pr&el=footer). Last update [c392ea8...a1e3f5d](https://codecov.io/gh/apache/qpid-dispatch/pull/376?src=pr&el=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-1081) Messages to multicast addresses are being released when no receivers attached
[
https://issues.apache.org/jira/browse/DISPATCH-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16635928#comment-16635928
]
ASF GitHub Bot commented on DISPATCH-1081:
--
Github user bhardesty commented on the issue:
https://github.com/apache/qpid-dispatch/pull/376
@ganeshmurthy @ted-ross I updated this with Ted's feedback. Ganesh, let me
know if you need me to rebase in preparation for merging.
> Messages to multicast addresses are being released when no receivers attached
> -
>
> Key: DISPATCH-1081
> URL: https://issues.apache.org/jira/browse/DISPATCH-1081
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Alexander Rafferty
>Assignee: Ganesh Murthy
>Priority: Major
>
> When sending messages to a multicast address to which no consumers are
> attached, the router sends back a disposition of RELEASED. The expected
> behaviour is that all messages will be immediately settled by the ingress
> router with a disposition of ACCEPTED as per section 2.4.1 of the Dispatch
> router book:
> {quote}Multicast delivery is not reliable. If a producer sends an unsettled
> delivery, the ingress router shall settle the delivery with ACCEPTED
> disposition regardless of whether the message was delivered to any consumers.
> {quote}
> Is this a bug, or is this the expected behaviour? If this is the expected
> behaviour, can the router be configured to always accept messages to
> multicast addresses even where no consumers are actively listening?
--
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 #376: DISPATCH-1081 - Update doc for multicast delivery ...
Github user bhardesty commented on the issue: https://github.com/apache/qpid-dispatch/pull/376 @ganeshmurthy @ted-ross I updated this with Ted's feedback. Ganesh, let me know if you need me to rebase in preparation for merging. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Reopened] (PROTON-1947) [cpp] not correctly locating jsoncpp library on some platforms
[ https://issues.apache.org/jira/browse/PROTON-1947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway reopened PROTON-1947: - Seeing problems running the relevant test on Ubuntu. > [cpp] not correctly locating jsoncpp library on some platforms > -- > > Key: PROTON-1947 > URL: https://issues.apache.org/jira/browse/PROTON-1947 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.25.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.26.0 > > -- 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-1946) [cpp] connection config file parser mis-handling TLS defaults
[
https://issues.apache.org/jira/browse/PROTON-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway resolved PROTON-1946.
-
Resolution: Fixed
> [cpp] connection config file parser mis-handling TLS defaults
> -
>
> Key: PROTON-1946
> URL: https://issues.apache.org/jira/browse/PROTON-1946
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.25.0
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
> Fix For: proton-c-0.26.0
>
>
> The C++ connection configuration parser mis-handles default values in several
> ways:
> * tls is not enabled unless there is a tls: {} section - it should be
> enabled (with default config) if scheme: amqps is present even if there is no
> tls section
> * in several cases an explicit 'field: null' is treated differently (as an
> error) from field being absent (use default value). null and absent should be
> equivalent.
> * Host defaults to "", it should be "localhost"
> * Some exceptions from jsoncpp are leaked, they should be wrapped in
> proton::error
> * Need additional tests to cover all of the above
--
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-1947) [cpp] not correctly locating jsoncpp library on some platforms
[ https://issues.apache.org/jira/browse/PROTON-1947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved PROTON-1947. - Resolution: Fixed > [cpp] not correctly locating jsoncpp library on some platforms > -- > > Key: PROTON-1947 > URL: https://issues.apache.org/jira/browse/PROTON-1947 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.25.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.26.0 > > -- 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-414) update to Netty 4.1.30
[ https://issues.apache.org/jira/browse/QPIDJMS-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPIDJMS-414. Resolution: Fixed > update to Netty 4.1.30 > -- > > Key: QPIDJMS-414 > URL: https://issues.apache.org/jira/browse/QPIDJMS-414 > Project: Qpid JMS > Issue Type: Task > Components: qpid-jms-client >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 0.38.0 > > > update to the latest Netty release -- 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-415) update test dependencies
[ https://issues.apache.org/jira/browse/QPIDJMS-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPIDJMS-415. Resolution: Fixed > update test dependencies > > > Key: QPIDJMS-415 > URL: https://issues.apache.org/jira/browse/QPIDJMS-415 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 0.38.0 > > > update to the latest version of various test dependencies -- 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-415) update test dependencies
[ https://issues.apache.org/jira/browse/QPIDJMS-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16635674#comment-16635674 ] ASF subversion and git services commented on QPIDJMS-415: - Commit 0ad2047904ed4754352be150704eb11c4943c6df in qpid-jms's branch refs/heads/master from [~gemmellr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=0ad2047 ] QPIDJMS-415: update netty-tcnative, activemq, jetty, mockito, jacoco test deps > update test dependencies > > > Key: QPIDJMS-415 > URL: https://issues.apache.org/jira/browse/QPIDJMS-415 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 0.38.0 > > > update to the latest version of various test dependencies -- 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-414) update to Netty 4.1.30
[ https://issues.apache.org/jira/browse/QPIDJMS-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16635675#comment-16635675 ] ASF subversion and git services commented on QPIDJMS-414: - Commit 4b8739b756fd94d77965df17c7aed84c56b95dea in qpid-jms's branch refs/heads/master from [~gemmellr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=4b8739b ] QPIDJMS-414: update to Netty 4.1.30 > update to Netty 4.1.30 > -- > > Key: QPIDJMS-414 > URL: https://issues.apache.org/jira/browse/QPIDJMS-414 > Project: Qpid JMS > Issue Type: Task > Components: qpid-jms-client >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 0.38.0 > > > update to the latest Netty release -- 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-415) update test dependencies
Robbie Gemmell created QPIDJMS-415: -- Summary: update test dependencies Key: QPIDJMS-415 URL: https://issues.apache.org/jira/browse/QPIDJMS-415 Project: Qpid JMS Issue Type: Bug Components: qpid-jms-client Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.38.0 update to the latest version of various test dependencies -- 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-414) update to Netty 4.1.30
[ https://issues.apache.org/jira/browse/QPIDJMS-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPIDJMS-414: --- Issue Type: Task (was: Bug) > update to Netty 4.1.30 > -- > > Key: QPIDJMS-414 > URL: https://issues.apache.org/jira/browse/QPIDJMS-414 > Project: Qpid JMS > Issue Type: Task > Components: qpid-jms-client >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 0.38.0 > > > update to the latest Netty release -- 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-414) update to Netty 4.1.30
Robbie Gemmell created QPIDJMS-414: -- Summary: update to Netty 4.1.30 Key: QPIDJMS-414 URL: https://issues.apache.org/jira/browse/QPIDJMS-414 Project: Qpid JMS Issue Type: Bug Components: qpid-jms-client Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.38.0 update to the latest Netty release -- 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-1947) [cpp] not correctly locating jsoncpp library on some platforms
[ https://issues.apache.org/jira/browse/PROTON-1947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16635660#comment-16635660 ] ASF subversion and git services commented on PROTON-1947: - Commit ab82a8b8e92f2dff3fa8d03d9c11403439420bba in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=ab82a8b ] PROTON-1947: [cpp] not locating jsoncpp library on some platforms CMake was not adding the INCLUDE_DIR locations found by FindJsonCpp so a non-standard installation would be found but cause a compile failure. > [cpp] not correctly locating jsoncpp library on some platforms > -- > > Key: PROTON-1947 > URL: https://issues.apache.org/jira/browse/PROTON-1947 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.25.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.26.0 > > -- 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-1946) [cpp] connection config file parser mis-handling TLS defaults
[
https://issues.apache.org/jira/browse/PROTON-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16635633#comment-16635633
]
ASF subversion and git services commented on PROTON-1946:
-
Commit b34215170680ebb2f6b60604374c58f598b45803 in qpid-proton's branch
refs/heads/master from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=b342151 ]
PROTON-1946: [cpp] connection config parser incorrect defaults
- Change default "host" to "localhost" (was "")
- Only throw proton::error, don't leak jsoncpp exceptions
- Add tests for SASL/TLS behavior
- Treat explicit "null" valued field as equivalent to a missing field
> [cpp] connection config file parser mis-handling TLS defaults
> -
>
> Key: PROTON-1946
> URL: https://issues.apache.org/jira/browse/PROTON-1946
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.25.0
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
> Fix For: proton-c-0.26.0
>
>
> The C++ connection configuration parser mis-handles default values in several
> ways:
> * tls is not enabled unless there is a tls: {} section - it should be
> enabled (with default config) if scheme: amqps is present even if there is no
> tls section
> * in several cases an explicit 'field: null' is treated differently (as an
> error) from field being absent (use default value). null and absent should be
> equivalent.
> * Host defaults to "", it should be "localhost"
> * Some exceptions from jsoncpp are leaked, they should be wrapped in
> proton::error
> * Need additional tests to cover all of the above
--
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-1947) [cpp] not correctly locating jsoncpp library on some platforms
Alan Conway created PROTON-1947: --- Summary: [cpp] not correctly locating jsoncpp library on some platforms Key: PROTON-1947 URL: https://issues.apache.org/jira/browse/PROTON-1947 Project: Qpid Proton Issue Type: Bug Components: cpp-binding Affects Versions: proton-c-0.25.0 Reporter: Alan Conway Assignee: Alan Conway Fix For: proton-c-0.26.0 -- 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-1136) Receiver crash due to data corruption on multicast presettled messages
[ https://issues.apache.org/jira/browse/DISPATCH-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved DISPATCH-1136. --- Resolution: Fixed fixed at commit 430efa07 > Receiver crash due to data corruption on multicast presettled messages > -- > > Key: DISPATCH-1136 > URL: https://issues.apache.org/jira/browse/DISPATCH-1136 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.3.0 > Environment: Fedora 27 > Three routers connected serially as described in DISPATCH-1124 > >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > > After applying the fixes from DISPATCH-1124 and DISPATCH-1129 receivers in > long-running multicast presettled tests still fail with corrupted data > sequences. There is no single symptom but several: > * Receivers use all system memory and cache and getting hit by the OOM killer > * underrun > * illegal value for field > Research shows that function qdr_forward_drop_presettled_CT_LH is routinely > dropping presettled deliveries that have already made forward progress in > transmitting bytes to the wire. After that happens there is a race condition > as to whether the message is successfully transmitted or the message is torn > down in the middle of transmission. > For reproducing this error the sender must supply messages significantly > faster than the receiving router can forward them to the next router. This > triggers the presettled drops. My test setup does this by having the sender > and the receiving router on the same laptop and having the next router > connected over a relatively slow WiFi. > -- 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-1136) Receiver crash due to data corruption on multicast presettled messages
[ https://issues.apache.org/jira/browse/DISPATCH-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16635605#comment-16635605 ] ASF subversion and git services commented on DISPATCH-1136: --- Commit 430efa0777c87289f5b59a83d0d36cab7647adac in qpid-dispatch's branch refs/heads/master from [~chug] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=430efa0 ] DISPATCH-1136: Don't drop presettled message at head of list This message may have had bytes go over the wire already and dropping it now may corrupt the link data stream. > Receiver crash due to data corruption on multicast presettled messages > -- > > Key: DISPATCH-1136 > URL: https://issues.apache.org/jira/browse/DISPATCH-1136 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.3.0 > Environment: Fedora 27 > Three routers connected serially as described in DISPATCH-1124 > >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > > After applying the fixes from DISPATCH-1124 and DISPATCH-1129 receivers in > long-running multicast presettled tests still fail with corrupted data > sequences. There is no single symptom but several: > * Receivers use all system memory and cache and getting hit by the OOM killer > * underrun > * illegal value for field > Research shows that function qdr_forward_drop_presettled_CT_LH is routinely > dropping presettled deliveries that have already made forward progress in > transmitting bytes to the wire. After that happens there is a race condition > as to whether the message is successfully transmitted or the message is torn > down in the middle of transmission. > For reproducing this error the sender must supply messages significantly > faster than the receiving router can forward them to the next router. This > triggers the presettled drops. My test setup does this by having the sender > and the receiving router on the same laptop and having the next router > connected over a relatively slow WiFi. > -- 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-1136) Receiver crash due to data corruption on multicast presettled messages
Chuck Rolke created DISPATCH-1136: - Summary: Receiver crash due to data corruption on multicast presettled messages Key: DISPATCH-1136 URL: https://issues.apache.org/jira/browse/DISPATCH-1136 Project: Qpid Dispatch Issue Type: Bug Components: Routing Engine Affects Versions: 1.3.0 Environment: Fedora 27 Three routers connected serially as described in DISPATCH-1124 Reporter: Chuck Rolke Assignee: Chuck Rolke After applying the fixes from DISPATCH-1124 and DISPATCH-1129 receivers in long-running multicast presettled tests still fail with corrupted data sequences. There is no single symptom but several: * Receivers use all system memory and cache and getting hit by the OOM killer * underrun * illegal value for field Research shows that function qdr_forward_drop_presettled_CT_LH is routinely dropping presettled deliveries that have already made forward progress in transmitting bytes to the wire. After that happens there is a race condition as to whether the message is successfully transmitted or the message is torn down in the middle of transmission. For reproducing this error the sender must supply messages significantly faster than the receiving router can forward them to the next router. This triggers the presettled drops. My test setup does this by having the sender and the receiving router on the same laptop and having the next router connected over a relatively slow WiFi. -- 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-1946) [cpp] connection config file parser mis-handling TLS defaults
Alan Conway created PROTON-1946:
---
Summary: [cpp] connection config file parser mis-handling TLS
defaults
Key: PROTON-1946
URL: https://issues.apache.org/jira/browse/PROTON-1946
Project: Qpid Proton
Issue Type: Bug
Components: cpp-binding
Affects Versions: proton-c-0.25.0
Reporter: Alan Conway
Assignee: Alan Conway
Fix For: proton-c-0.26.0
The C++ connection configuration parser mis-handles default values in several
ways:
* tls is not enabled unless there is a tls: {} section - it should be enabled
(with default config) if scheme: amqps is present even if there is no tls
section
* in several cases an explicit 'field: null' is treated differently (as an
error) from field being absent (use default value). null and absent should be
equivalent.
* Host defaults to "", it should be "localhost"
* Some exceptions from jsoncpp are leaked, they should be wrapped in
proton::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] [Updated] (PROTON-1946) [cpp] connection config file parser mis-handling TLS defaults
[
https://issues.apache.org/jira/browse/PROTON-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway updated PROTON-1946:
Description:
The C++ connection configuration parser mis-handles default values in several
ways:
* tls is not enabled unless there is a tls: {} section - it should be enabled
(with default config) if scheme: amqps is present even if there is no tls
section
* in several cases an explicit 'field: null' is treated differently (as an
error) from field being absent (use default value). null and absent should be
equivalent.
* Host defaults to "", it should be "localhost"
* Some exceptions from jsoncpp are leaked, they should be wrapped in
proton::error
* Need additional tests to cover all of the above
was:
The C++ connection configuration parser mis-handles default values in several
ways:
* tls is not enabled unless there is a tls: {} section - it should be enabled
(with default config) if scheme: amqps is present even if there is no tls
section
* in several cases an explicit 'field: null' is treated differently (as an
error) from field being absent (use default value). null and absent should be
equivalent.
* Host defaults to "", it should be "localhost"
* Some exceptions from jsoncpp are leaked, they should be wrapped in
proton::error
> [cpp] connection config file parser mis-handling TLS defaults
> -
>
> Key: PROTON-1946
> URL: https://issues.apache.org/jira/browse/PROTON-1946
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.25.0
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
> Fix For: proton-c-0.26.0
>
>
> The C++ connection configuration parser mis-handles default values in several
> ways:
> * tls is not enabled unless there is a tls: {} section - it should be
> enabled (with default config) if scheme: amqps is present even if there is no
> tls section
> * in several cases an explicit 'field: null' is treated differently (as an
> error) from field being absent (use default value). null and absent should be
> equivalent.
> * Host defaults to "", it should be "localhost"
> * Some exceptions from jsoncpp are leaked, they should be wrapped in
> proton::error
> * Need additional tests to cover all of the above
--
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
