[jira] [Commented] (DISPATCH-1150) A request/response message client API for core
[ https://issues.apache.org/jira/browse/DISPATCH-1150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16712118#comment-16712118 ] ASF subversion and git services commented on DISPATCH-1150: --- Commit 7ec199d46ea6cb268c27977ccd0a00102da3b371 in qpid-dispatch's branch refs/heads/master from Kenneth Giusti [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=7ec199d ] DISPATCH-1150: add core client request time out > A request/response message client API for core > -- > > Key: DISPATCH-1150 > URL: https://issues.apache.org/jira/browse/DISPATCH-1150 > Project: Qpid Dispatch > Issue Type: New Feature >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.5.0 > > > Add an internal API to the core thread that supports a request/response > message pattern. It allows the core to send request messages and receive > responses to an external service. > This will be used by the edge router to communicate with the management agent > on the interior router. -- 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-1978) Disposition frames can take a *very* long time to complete
[ https://issues.apache.org/jira/browse/PROTON-1978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated PROTON-1978: Description: This bug was found by the oss-fuzz project: [https://oss-fuzz.com/testcase?key=5118747114209280] If the last delivery value affected is legitimate (before the next sequence number to be assigned), but the first value is hugely before it then the disposition frame handling will loop through every affected delivery number from first to last which can take a very long time and effectively hang the process. was: This bug was found by the oss-fuzz project: [https://oss-fuzz.com/testcase?key=5118747114209280|http://example.com/] If the last delivery value affected is legitimate (before the next sequence number to be assigned), but the first value is hugely before it then the disposition frame handling will loop through every affected delivery number from first to last which can take a very long time and effectively hang the process. > Disposition frames can take a *very* long time to complete > -- > > Key: PROTON-1978 > URL: https://issues.apache.org/jira/browse/PROTON-1978 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Major > Labels: fuzzer > Fix For: proton-c-0.27.0 > > > This bug was found by the oss-fuzz project: > [https://oss-fuzz.com/testcase?key=5118747114209280] > If the last delivery value affected is legitimate (before the next sequence > number to be assigned), but the first value is hugely before it then the > disposition frame handling will loop through every affected delivery number > from first to last which can take a very long time and effectively hang the > process. -- 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-1978) Disposition frames can take a *very* long time to complete
[ https://issues.apache.org/jira/browse/PROTON-1978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-1978. - Resolution: Fixed Fix Version/s: proton-c-0.27.0 > Disposition frames can take a *very* long time to complete > -- > > Key: PROTON-1978 > URL: https://issues.apache.org/jira/browse/PROTON-1978 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Major > Labels: fuzzer > Fix For: proton-c-0.27.0 > > > This bug was found by the oss-fuzz project: > [https://oss-fuzz.com/testcase?key=5118747114209280|http://example.com/] > If the last delivery value affected is legitimate (before the next sequence > number to be assigned), but the first value is hugely before it then the > disposition frame handling will loop through every affected delivery number > from first to last which can take a very long time and effectively hang the > process. -- 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-1979) Decoding a bad message can overflow the stack
[ https://issues.apache.org/jira/browse/PROTON-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated PROTON-1979: Labels: fuzzer (was: ) > Decoding a bad message can overflow the stack > - > > Key: PROTON-1979 > URL: https://issues.apache.org/jira/browse/PROTON-1979 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Major > Labels: fuzzer > Fix For: proton-c-0.27.0 > > > Found by oss-fuzz: [https://oss-fuzz.com/testcase?key=5920119225057280] > A message with a described type whose descriptor is an array containing > described types of an array containing described types of... can cause enough > stack use to overflow the process stack. > The message is quite long (and essentially meaningless) but none the less > syntactically valid. -- 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-1978) Disposition frames can take a *very* long time to complete
[ https://issues.apache.org/jira/browse/PROTON-1978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated PROTON-1978: Labels: fuzzer (was: ) > Disposition frames can take a *very* long time to complete > -- > > Key: PROTON-1978 > URL: https://issues.apache.org/jira/browse/PROTON-1978 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Major > Labels: fuzzer > Fix For: proton-c-0.27.0 > > > This bug was found by the oss-fuzz project: > [https://oss-fuzz.com/testcase?key=5118747114209280|http://example.com/] > If the last delivery value affected is legitimate (before the next sequence > number to be assigned), but the first value is hugely before it then the > disposition frame handling will loop through every affected delivery number > from first to last which can take a very long time and effectively hang the > process. -- 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-1979) Decoding a bad message can overflow the stack
[ https://issues.apache.org/jira/browse/PROTON-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16712092#comment-16712092 ] ASF subversion and git services commented on PROTON-1979: - Commit 5ba471d97f9e04c8e68f2270681038b3c1eac0ed in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=5ba471d ] PROTON-1979: [c] Forbid AMQP values that could lead to a nested descriptor type - Any described type descriptors that could lead to a nested described type in the descriptor type itself are forbidden as these can lead to indefinite stack use. - In any event only symbol and ulong are currently valid types for descriptors, all other types are reserved although syntactically valid (according to amqp 1.0). Problem found by oss-fuzz: https://oss-fuzz.com/testcase?key=5920119225057280 > Decoding a bad message can overflow the stack > - > > Key: PROTON-1979 > URL: https://issues.apache.org/jira/browse/PROTON-1979 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Major > Fix For: proton-c-0.27.0 > > > Found by oss-fuzz: [https://oss-fuzz.com/testcase?key=5920119225057280] > A message with a described type whose descriptor is an array containing > described types of an array containing described types of... can cause enough > stack use to overflow the process stack. > The message is quite long (and essentially meaningless) but none the less > syntactically valid. -- 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-1978) Disposition frames can take a *very* long time to complete
[ https://issues.apache.org/jira/browse/PROTON-1978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16712091#comment-16712091 ] ASF subversion and git services commented on PROTON-1978: - Commit 6a5140b4efc2b6c8f92ad2ca8f7ea551b37bcd1c in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=6a5140b ] PROTON-1978: [c] Make disposition performative handling more efficient - Minimise the effort to update deliveries affected by the disposition performative: If there are fewer deliveries outstanding than delivery ids in the performative then loop through them all to update them. Otherwise, loop through the specified delivery ids. - We have to go through this effort as we don't keep the outstanding deliveries sorted by id. Instead they are in a hash table and in a separate linked list. Problem found by oss-fuzz: https://oss-fuzz.com/testcase?key=5118747114209280 > Disposition frames can take a *very* long time to complete > -- > > Key: PROTON-1978 > URL: https://issues.apache.org/jira/browse/PROTON-1978 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Major > > This bug was found by the oss-fuzz project: > [https://oss-fuzz.com/testcase?key=5118747114209280|http://example.com/] > If the last delivery value affected is legitimate (before the next sequence > number to be assigned), but the first value is hugely before it then the > disposition frame handling will loop through every affected delivery number > from first to last which can take a very long time and effectively hang the > process. -- 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-1979) Decoding a bad message can overflow the stack
[ https://issues.apache.org/jira/browse/PROTON-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-1979. - Resolution: Fixed Fix Version/s: proton-c-0.27.0 > Decoding a bad message can overflow the stack > - > > Key: PROTON-1979 > URL: https://issues.apache.org/jira/browse/PROTON-1979 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Major > Fix For: proton-c-0.27.0 > > > Found by oss-fuzz: [https://oss-fuzz.com/testcase?key=5920119225057280] > A message with a described type whose descriptor is an array containing > described types of an array containing described types of... can cause enough > stack use to overflow the process stack. > The message is quite long (and essentially meaningless) but none the less > syntactically valid. -- 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-1979) Decoding a bad message can overflow the stack
Andrew Stitcher created PROTON-1979: --- Summary: Decoding a bad message can overflow the stack Key: PROTON-1979 URL: https://issues.apache.org/jira/browse/PROTON-1979 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Andrew Stitcher Assignee: Andrew Stitcher Found by oss-fuzz: [https://oss-fuzz.com/testcase?key=5920119225057280] A message with a described type whose descriptor is an array containing described types of an array containing described types of... can cause enough stack use to overflow the process stack. The message is quite long (and essentially meaningless) but none the less syntactically valid. -- 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-1978) Disposition frames can take a *very* long time to complete
Andrew Stitcher created PROTON-1978: --- Summary: Disposition frames can take a *very* long time to complete Key: PROTON-1978 URL: https://issues.apache.org/jira/browse/PROTON-1978 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Andrew Stitcher Assignee: Andrew Stitcher This bug was found by the oss-fuzz project: [https://oss-fuzz.com/testcase?key=5118747114209280|http://example.com/] If the last delivery value affected is legitimate (before the next sequence number to be assigned), but the first value is hugely before it then the disposition frame handling will loop through every affected delivery number from first to last which can take a very long time and effectively hang the process. -- 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-1194) Asynchronous address lookup on attach for Edge to determine if there are link-route destinations
[ https://issues.apache.org/jira/browse/DISPATCH-1194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16712075#comment-16712075 ] ASF subversion and git services commented on DISPATCH-1194: --- Commit 7a9378d588edeb66f96770f03a87f05f182b74a2 in qpid-dispatch's branch refs/heads/master from [~tr...@redhat.com] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=7a9378d ] DISPATCH-1194 - Wired in the link-route attach forwarding based on address lookup result. > Asynchronous address lookup on attach for Edge to determine if there are > link-route destinations > > > Key: DISPATCH-1194 > URL: https://issues.apache.org/jira/browse/DISPATCH-1194 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Router Node >Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.5.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] (DISPATCH-1197) Released multi-frame deliveries can cause stalling of inbound links
[ https://issues.apache.org/jira/browse/DISPATCH-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16712062#comment-16712062 ] ASF subversion and git services commented on DISPATCH-1197: --- Commit 58567f979deef3ecc4d797610f92539396de5f40 in qpid-dispatch's branch refs/heads/master from [~ganeshmurthy] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=58567f9 ] DISPATCH-1197 - Added system test to make sure that streaming deliveries are handled without stalling when receiver goes away causing messages to be released > Released multi-frame deliveries can cause stalling of inbound links > --- > > Key: DISPATCH-1197 > URL: https://issues.apache.org/jira/browse/DISPATCH-1197 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.4.1 >Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.5.0 > > > Under specific circumstances, a multi-frame delivery that is released can > cause the sender's link to stall such that deliveries stop flowing over that > one link. -- 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-1210) [tools] Scraper could find and show unsettled transfers
[ https://issues.apache.org/jira/browse/DISPATCH-1210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16712053#comment-16712053 ] ASF subversion and git services commented on DISPATCH-1210: --- Commit 8701feb7f6924bdb7f126881c50d2a6368434e8f in qpid-dispatch's branch refs/heads/master from [~chug] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=8701feb ] DISPATCH-1210: Scraper shows unsettled messages Compute message settlement earlier and display summary totals for connections, sessions, and links in details display. > [tools] Scraper could find and show unsettled transfers > --- > > Key: DISPATCH-1210 > URL: https://issues.apache.org/jira/browse/DISPATCH-1210 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Tools >Affects Versions: 1.5.0 >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > > * Unsettled messages can be found and displayed directly > * Some settlement messages could be more clear. > * Navigating per-link data sets needs improvement. > -- 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-1213) Sender link sending pre-settled multi-frame deliveries can stall if receiver drops
[
https://issues.apache.org/jira/browse/DISPATCH-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711987#comment-16711987
]
ASF GitHub Bot commented on DISPATCH-1213:
--
Github user codecov-io commented on the issue:
https://github.com/apache/qpid-dispatch/pull/425
#
[Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/425?src=pr=h1)
Report
> Merging
[#425](https://codecov.io/gh/apache/qpid-dispatch/pull/425?src=pr=desc) into
[master](https://codecov.io/gh/apache/qpid-dispatch/commit/2dde7030fb032a54fdefe5b7c5c4a39a4f1bfd6e?src=pr=desc)
will **decrease** coverage by `<.01%`.
> The diff coverage is `100%`.
[](https://codecov.io/gh/apache/qpid-dispatch/pull/425?src=pr=tree)
```diff
@@Coverage Diff @@
## master #425 +/- ##
==
- Coverage 87.93% 87.92% -0.01%
==
Files 85 85
Lines 1823618243 +7
==
+ Hits1603516041 +6
- Misses 2201 2202 +1
```
| [Impacted
Files](https://codecov.io/gh/apache/qpid-dispatch/pull/425?src=pr=tree) |
Coverage Δ | |
|---|---|---|
|
[src/router\_core/transfer.c](https://codecov.io/gh/apache/qpid-dispatch/pull/425/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL3RyYW5zZmVyLmM=)
| `91.28% <100%> (+0.38%)` | :arrow_up: |
|
[src/router\_node.c](https://codecov.io/gh/apache/qpid-dispatch/pull/425/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9ub2RlLmM=)
| `94.21% <100%> (ø)` | :arrow_up: |
|
[src/router\_core/core\_timer.c](https://codecov.io/gh/apache/qpid-dispatch/pull/425/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2NvcmVfdGltZXIuYw==)
| `94.64% <0%> (-1.79%)` | :arrow_down: |
|
[src/container.c](https://codecov.io/gh/apache/qpid-dispatch/pull/425/diff?src=pr=tree#diff-c3JjL2NvbnRhaW5lci5j)
| `77.01% <0%> (-0.77%)` | :arrow_down: |
|
[src/router\_core/agent\_link.c](https://codecov.io/gh/apache/qpid-dispatch/pull/425/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2FnZW50X2xpbmsuYw==)
| `63.27% <0%> (-0.57%)` | :arrow_down: |
|
[src/parse.c](https://codecov.io/gh/apache/qpid-dispatch/pull/425/diff?src=pr=tree#diff-c3JjL3BhcnNlLmM=)
| `88.04% <0%> (-0.26%)` | :arrow_down: |
|
[src/router\_core/route\_tables.c](https://codecov.io/gh/apache/qpid-dispatch/pull/425/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL3JvdXRlX3RhYmxlcy5j)
| `76.36% <0%> (-0.25%)` | :arrow_down: |
|
[src/router\_core/connections.c](https://codecov.io/gh/apache/qpid-dispatch/pull/425/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2Nvbm5lY3Rpb25zLmM=)
| `95.2% <0%> (-0.13%)` | :arrow_down: |
|
[src/router\_core/modules/edge\_router/addr\_proxy.c](https://codecov.io/gh/apache/qpid-dispatch/pull/425/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL21vZHVsZXMvZWRnZV9yb3V0ZXIvYWRkcl9wcm94eS5j)
| `94.36% <0%> (+0.7%)` | :arrow_up: |
| ... and [2
more](https://codecov.io/gh/apache/qpid-dispatch/pull/425/diff?src=pr=tree-more)
| |
--
[Continue to review full report at
Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/425?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/425?src=pr=footer).
Last update
[2dde703...e8124dc](https://codecov.io/gh/apache/qpid-dispatch/pull/425?src=pr=lastupdated).
Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).
> Sender link sending pre-settled multi-frame deliveries can stall if
> receiver drops
> ---
>
> Key: DISPATCH-1213
> URL: https://issues.apache.org/jira/browse/DISPATCH-1213
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 1.4.1
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.5.0
>
>
> Steps to reproduce -
> # Start the router
> # Start a receiver and receive 10 messages.
> {noformat}
> python simple_recv.py --address 0.0.0.0/examples -m10{noformat}
> # Send 200 large presettled messages
> {noformat}
> python big_send_settled.py --address 0.0.0.0/examples -m200{noformat}
> # Look at the output of qdstat -g
> {noformat}
> [gmurthy@localhost ~]$ qdstat -g
> Router Statistics
> attr value
>
[GitHub] qpid-dispatch issue #425: DISPATCH-1213 - Prevent stalling of presettled lar...
Github user codecov-io commented on the issue: https://github.com/apache/qpid-dispatch/pull/425 # [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/425?src=pr=h1) Report > Merging [#425](https://codecov.io/gh/apache/qpid-dispatch/pull/425?src=pr=desc) into [master](https://codecov.io/gh/apache/qpid-dispatch/commit/2dde7030fb032a54fdefe5b7c5c4a39a4f1bfd6e?src=pr=desc) will **decrease** coverage by `<.01%`. > The diff coverage is `100%`. [](https://codecov.io/gh/apache/qpid-dispatch/pull/425?src=pr=tree) ```diff @@Coverage Diff @@ ## master #425 +/- ## == - Coverage 87.93% 87.92% -0.01% == Files 85 85 Lines 1823618243 +7 == + Hits1603516041 +6 - Misses 2201 2202 +1 ``` | [Impacted Files](https://codecov.io/gh/apache/qpid-dispatch/pull/425?src=pr=tree) | Coverage Π| | |---|---|---| | [src/router\_core/transfer.c](https://codecov.io/gh/apache/qpid-dispatch/pull/425/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL3RyYW5zZmVyLmM=) | `91.28% <100%> (+0.38%)` | :arrow_up: | | [src/router\_node.c](https://codecov.io/gh/apache/qpid-dispatch/pull/425/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9ub2RlLmM=) | `94.21% <100%> (ø)` | :arrow_up: | | [src/router\_core/core\_timer.c](https://codecov.io/gh/apache/qpid-dispatch/pull/425/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2NvcmVfdGltZXIuYw==) | `94.64% <0%> (-1.79%)` | :arrow_down: | | [src/container.c](https://codecov.io/gh/apache/qpid-dispatch/pull/425/diff?src=pr=tree#diff-c3JjL2NvbnRhaW5lci5j) | `77.01% <0%> (-0.77%)` | :arrow_down: | | [src/router\_core/agent\_link.c](https://codecov.io/gh/apache/qpid-dispatch/pull/425/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2FnZW50X2xpbmsuYw==) | `63.27% <0%> (-0.57%)` | :arrow_down: | | [src/parse.c](https://codecov.io/gh/apache/qpid-dispatch/pull/425/diff?src=pr=tree#diff-c3JjL3BhcnNlLmM=) | `88.04% <0%> (-0.26%)` | :arrow_down: | | [src/router\_core/route\_tables.c](https://codecov.io/gh/apache/qpid-dispatch/pull/425/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL3JvdXRlX3RhYmxlcy5j) | `76.36% <0%> (-0.25%)` | :arrow_down: | | [src/router\_core/connections.c](https://codecov.io/gh/apache/qpid-dispatch/pull/425/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2Nvbm5lY3Rpb25zLmM=) | `95.2% <0%> (-0.13%)` | :arrow_down: | | [src/router\_core/modules/edge\_router/addr\_proxy.c](https://codecov.io/gh/apache/qpid-dispatch/pull/425/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL21vZHVsZXMvZWRnZV9yb3V0ZXIvYWRkcl9wcm94eS5j) | `94.36% <0%> (+0.7%)` | :arrow_up: | | ... and [2 more](https://codecov.io/gh/apache/qpid-dispatch/pull/425/diff?src=pr=tree-more) | | -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/425?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/425?src=pr=footer). Last update [2dde703...e8124dc](https://codecov.io/gh/apache/qpid-dispatch/pull/425?src=pr=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments). --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #425: DISPATCH-1213 - Prevent stalling of presett...
GitHub user ganeshmurthy opened a pull request: https://github.com/apache/qpid-dispatch/pull/425 DISPATCH-1213 - Prevent stalling of presettled large message senders ⦠â¦by calling the AMQP_rx_handler which start emptying proton buffers again You can merge this pull request into a Git repository by running: $ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-1213 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/425.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 #425 commit e8124dced7a70f6126f643959cac4603dcae0fbb Author: Ganesh Murthy Date: 2018-12-06T20:00:30Z DISPATCH-1213 - Prevent stalling of presettled large message senders by calling the AMQP_rx_handler which start emptying proton buffers again --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1213) Sender link sending pre-settled multi-frame deliveries can stall if receiver drops
[
https://issues.apache.org/jira/browse/DISPATCH-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711970#comment-16711970
]
ASF GitHub Bot commented on DISPATCH-1213:
--
GitHub user ganeshmurthy opened a pull request:
https://github.com/apache/qpid-dispatch/pull/425
DISPATCH-1213 - Prevent stalling of presettled large message senders …
…by calling the AMQP_rx_handler which start emptying proton buffers again
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-1213
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/qpid-dispatch/pull/425.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 #425
commit e8124dced7a70f6126f643959cac4603dcae0fbb
Author: Ganesh Murthy
Date: 2018-12-06T20:00:30Z
DISPATCH-1213 - Prevent stalling of presettled large message senders by
calling the AMQP_rx_handler which start emptying proton buffers again
> Sender link sending pre-settled multi-frame deliveries can stall if
> receiver drops
> ---
>
> Key: DISPATCH-1213
> URL: https://issues.apache.org/jira/browse/DISPATCH-1213
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 1.4.1
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.5.0
>
>
> Steps to reproduce -
> # Start the router
> # Start a receiver and receive 10 messages.
> {noformat}
> python simple_recv.py --address 0.0.0.0/examples -m10{noformat}
> # Send 200 large presettled messages
> {noformat}
> python big_send_settled.py --address 0.0.0.0/examples -m200{noformat}
> # Look at the output of qdstat -g
> {noformat}
> [gmurthy@localhost ~]$ qdstat -g
> Router Statistics
> attr value
> =
> Version 1.5.0-SNAPSHOT
> Mode standalone
> Router Id Standalone_lPF38hMqjGI_iAO
> Area 0
> Link Routes 0
> Auto Links 0
> Links 3
> Nodes 0
> Addresses 5
> Connections 2
> Presettled Count 17
> Dropped Presettled Count 2
> Accepted Count 1
> Rejected Count 0
> Released Count 0
> Modified Count 0
> Ingress Count 19
> Egress Count 17
> Transit Count 0
> Deliveries from Route Container 0
> Deliveries to Route Container 0
> {noformat}
> The Ingress Count should be more than 200. We had all the credit we need to
> send 200 messages.
> # The messages are stuck inside the proton buffer. The router stopped
> fetching the messages from the proton buffer as soon as the q2_holdoff limit
> was hit.
--
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-1194) Asynchronous address lookup on attach for Edge to determine if there are link-route destinations
[ https://issues.apache.org/jira/browse/DISPATCH-1194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711925#comment-16711925 ] ASF subversion and git services commented on DISPATCH-1194: --- Commit 2dde7030fb032a54fdefe5b7c5c4a39a4f1bfd6e in qpid-dispatch's branch refs/heads/master from [~tr...@redhat.com] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=2dde703 ] DISPATCH-1194 - Added client-side module for link-route address lookup. WIP. > Asynchronous address lookup on attach for Edge to determine if there are > link-route destinations > > > Key: DISPATCH-1194 > URL: https://issues.apache.org/jira/browse/DISPATCH-1194 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Router Node >Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.5.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] [Updated] (DISPATCH-1213) Sender link sending pre-settled multi-frame deliveries can stall if receiver drops
[
https://issues.apache.org/jira/browse/DISPATCH-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy updated DISPATCH-1213:
Summary: Sender link sending pre-settled multi-frame deliveries can
stall if receiver drops(was: Sender link which is sending pre-settled
multi-frame deliveries can stall if receiver drops )
> Sender link sending pre-settled multi-frame deliveries can stall if
> receiver drops
> ---
>
> Key: DISPATCH-1213
> URL: https://issues.apache.org/jira/browse/DISPATCH-1213
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 1.4.1
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.5.0
>
>
> Steps to reproduce -
> # Start the router
> # Start a receiver and receive 10 messages.
> {noformat}
> python simple_recv.py --address 0.0.0.0/examples -m10{noformat}
> # Send 200 large presettled messages
> {noformat}
> python big_send_settled.py --address 0.0.0.0/examples -m200{noformat}
> # Look at the output of qdstat -g
> {noformat}
> [gmurthy@localhost ~]$ qdstat -g
> Router Statistics
> attr value
> =
> Version 1.5.0-SNAPSHOT
> Mode standalone
> Router Id Standalone_lPF38hMqjGI_iAO
> Area 0
> Link Routes 0
> Auto Links 0
> Links 3
> Nodes 0
> Addresses 5
> Connections 2
> Presettled Count 17
> Dropped Presettled Count 2
> Accepted Count 1
> Rejected Count 0
> Released Count 0
> Modified Count 0
> Ingress Count 19
> Egress Count 17
> Transit Count 0
> Deliveries from Route Container 0
> Deliveries to Route Container 0
> {noformat}
> The Ingress Count should be more than 200. We had all the credit we need to
> send 200 messages.
> # The messages are stuck inside the proton buffer. The router stopped
> fetching the messages from the proton buffer as soon as the q2_holdoff limit
> was hit.
--
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-1213) Sender link which is sending pre-settled multi-frame deliveries can stall if receiver drops
Ganesh Murthy created DISPATCH-1213:
---
Summary: Sender link which is sending pre-settled multi-frame
deliveries can stall if receiver drops
Key: DISPATCH-1213
URL: https://issues.apache.org/jira/browse/DISPATCH-1213
Project: Qpid Dispatch
Issue Type: Bug
Components: Container
Affects Versions: 1.4.1
Reporter: Ganesh Murthy
Assignee: Ganesh Murthy
Fix For: 1.5.0
Steps to reproduce -
# Start the router
# Start a receiver and receive 10 messages.
{noformat}
python simple_recv.py --address 0.0.0.0/examples -m10{noformat}
# Send 200 large presettled messages
{noformat}
python big_send_settled.py --address 0.0.0.0/examples -m200{noformat}
# Look at the output of qdstat -g
{noformat}
[gmurthy@localhost ~]$ qdstat -g
Router Statistics
attr value
=
Version 1.5.0-SNAPSHOT
Mode standalone
Router Id Standalone_lPF38hMqjGI_iAO
Area 0
Link Routes 0
Auto Links 0
Links 3
Nodes 0
Addresses 5
Connections 2
Presettled Count 17
Dropped Presettled Count 2
Accepted Count 1
Rejected Count 0
Released Count 0
Modified Count 0
Ingress Count 19
Egress Count 17
Transit Count 0
Deliveries from Route Container 0
Deliveries to Route Container 0
{noformat}
The Ingress Count should be more than 200. We had all the credit we need to
send 200 messages.
# The messages are stuck inside the proton buffer. The router stopped fetching
the messages from the proton buffer as soon as the q2_holdoff limit was hit.
--
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
Re: qpid-proton: migrating debian branch to ASF Git
Hey, Daniel. Thanks for reaching out about this. We'd love to have a more up to date Debian package. Some questions: On Thu, Dec 6, 2018 at 1:59 AM Daniel Pocock wrote: > > I notice that nobody has contributed to the repository[1] maintained in > > Debian and it may be easier to maintain the debian/sid branch in the > > main qpid-proton repository[2] > Out of curiosity, what is it that makes it easier to maintain in the Proton tree, versus at Debian? Is it a question of access for you? I ask because my own practice is to keep Fedora packaging metadata at Fedora, on the idea that the metadata is more closely bound to the target OS than it is to Proton. It's not a hard and fast rule. We do sometimes have stuff like distro-specific init scripts in the tree. If we do end up having it in the Proton tree, I propose we place it at /packaging/debian. That's the pattern we have used for some other Qpid components. > > Would you be happy to accept me as a committer in the project so I can > > push the branch and any future changes there? I only intend to commit > > on the branch and within the debian/ subdirectory. > I have a counteroffer ;). Would you be willing to work by pull request for a period of time? Once we have a record of your contributions, we can consider you for committership. This is generally how the Qpid community vets potential new committers. > > Debian will freeze for the next release very soon so I'm keen to ensure > > the package is well organized before that. > It would really be awesome to have your contribution here. I want to clear away obstacles if I can.
[jira] [Assigned] (QPID-8193) [Broker-J] Updating maximum / minimum TTL on a queue does not affect messages already in the queue (until restart)
[ https://issues.apache.org/jira/browse/QPID-8193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy reassigned QPID-8193: Assignee: Alex Rudyy > [Broker-J] Updating maximum / minimum TTL on a queue does not affect messages > already in the queue (until restart) > -- > > Key: QPID-8193 > URL: https://issues.apache.org/jira/browse/QPID-8193 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Rob Godfrey >Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > > Updating the maximum / minimum TTL on a queue does not change the calculated > expiration on queue entries (updateExpiration is only called from doEnqueue). > Expiration should be recalculated after minimum/maximum ttl is modified. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8193) [Broker-J] Updating maximum / minimum TTL on a queue does not affect messages already in the queue (until restart)
[ https://issues.apache.org/jira/browse/QPID-8193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8193: - Status: Reviewable (was: In Progress) > [Broker-J] Updating maximum / minimum TTL on a queue does not affect messages > already in the queue (until restart) > -- > > Key: QPID-8193 > URL: https://issues.apache.org/jira/browse/QPID-8193 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Rob Godfrey >Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > > Updating the maximum / minimum TTL on a queue does not change the calculated > expiration on queue entries (updateExpiration is only called from doEnqueue). > Expiration should be recalculated after minimum/maximum ttl is modified. -- 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-8193) [Broker-J] Updating maximum / minimum TTL on a queue does not affect messages already in the queue (until restart)
[ https://issues.apache.org/jira/browse/QPID-8193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711819#comment-16711819 ] ASF subversion and git services commented on QPID-8193: --- Commit 8f3f9b1c2a9586bc44889c5bb155ac16141ec093 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=8f3f9b1 ] QPID-8193: [Broker-J] Update queue entries expirations on change of queue attributes for maximum/minimum TTL > [Broker-J] Updating maximum / minimum TTL on a queue does not affect messages > already in the queue (until restart) > -- > > Key: QPID-8193 > URL: https://issues.apache.org/jira/browse/QPID-8193 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Rob Godfrey >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > > Updating the maximum / minimum TTL on a queue does not change the calculated > expiration on queue entries (updateExpiration is only called from doEnqueue). > Expiration should be recalculated after minimum/maximum ttl is modified. -- 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-1187) Allow router to be configured to log in UTC time
[ https://issues.apache.org/jira/browse/DISPATCH-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved DISPATCH-1187. -- Resolution: Fixed Fix Version/s: 1.5.0 > Allow router to be configured to log in UTC time > > > Key: DISPATCH-1187 > URL: https://issues.apache.org/jira/browse/DISPATCH-1187 > Project: Qpid Dispatch > Issue Type: Bug >Reporter: Gordon Sim >Assignee: Gordon Sim >Priority: Major > Fix For: 1.5.0 > > > This is a convenient way of aligning times in logs for different components > ina distributed system for easier correlation. -- 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-1187) Allow router to be configured to log in UTC time
[ https://issues.apache.org/jira/browse/DISPATCH-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711735#comment-16711735 ] ASF GitHub Bot commented on DISPATCH-1187: -- Github user grs closed the pull request at: https://github.com/apache/qpid-dispatch/pull/424 > Allow router to be configured to log in UTC time > > > Key: DISPATCH-1187 > URL: https://issues.apache.org/jira/browse/DISPATCH-1187 > Project: Qpid Dispatch > Issue Type: Bug >Reporter: Gordon Sim >Assignee: Gordon Sim >Priority: Major > > This is a convenient way of aligning times in logs for different components > ina distributed system for easier correlation. -- 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 #424: DISPATCH-1187: add options to log in UTC an...
Github user grs closed the pull request at: https://github.com/apache/qpid-dispatch/pull/424 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1187) Allow router to be configured to log in UTC time
[ https://issues.apache.org/jira/browse/DISPATCH-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711733#comment-16711733 ] ASF subversion and git services commented on DISPATCH-1187: --- Commit 81d2555db47ce02ccb31a0631956a23c5a0c7ab0 in qpid-dispatch's branch refs/heads/master from Gordon Sim [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=81d2555 ] DISPATCH-1187: add options to log in UTC and to give control over the precise format of the date/time logged > Allow router to be configured to log in UTC time > > > Key: DISPATCH-1187 > URL: https://issues.apache.org/jira/browse/DISPATCH-1187 > Project: Qpid Dispatch > Issue Type: Bug >Reporter: Gordon Sim >Assignee: Gordon Sim >Priority: Major > > This is a convenient way of aligning times in logs for different components > ina distributed system for easier correlation. -- 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-1212) Incorrect "Dropped Presettled Count " in output of qdstat -g when receiver drops off
[ https://issues.apache.org/jira/browse/DISPATCH-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711683#comment-16711683 ] Ganesh Murthy commented on DISPATCH-1212: - This fix will better account for Dropped Presettled deliveries although making an accurate count is very difficult since the deliveries are presettled and no one cares about them. > Incorrect "Dropped Presettled Count " in output of qdstat -g when receiver > drops off > - > > Key: DISPATCH-1212 > URL: https://issues.apache.org/jira/browse/DISPATCH-1212 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.4.1 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.5.0 > > > Steps to reproduce > # Start the router > # Start simple recv - python simple_recv.py --address 0.0.0.0/examples -m10 > # Start simple send - python simple_send_presettled.py --address > 0.0.0.0/examples -m300 > # 240 presettled messages were actually dropped by the router > # The output of qdstat shows Dropped Presettled Count = 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-1212) Incorrect "Dropped Presettled Count " in output of qdstat -g when receiver drops off
[ https://issues.apache.org/jira/browse/DISPATCH-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-1212. - Resolution: Fixed > Incorrect "Dropped Presettled Count " in output of qdstat -g when receiver > drops off > - > > Key: DISPATCH-1212 > URL: https://issues.apache.org/jira/browse/DISPATCH-1212 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.4.1 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.5.0 > > > Steps to reproduce > # Start the router > # Start simple recv - python simple_recv.py --address 0.0.0.0/examples -m10 > # Start simple send - python simple_send_presettled.py --address > 0.0.0.0/examples -m300 > # 240 presettled messages were actually dropped by the router > # The output of qdstat shows Dropped Presettled Count = 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] [Updated] (QPID-8114) [Broker-J] Attempting to use an unknown filter type incorrectly causes connection closure with a decode error
[
https://issues.apache.org/jira/browse/QPID-8114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8114:
-
Status: Reviewable (was: In Progress)
> [Broker-J] Attempting to use an unknown filter type incorrectly causes
> connection closure with a decode error
> -
>
> Key: QPID-8114
> URL: https://issues.apache.org/jira/browse/QPID-8114
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Reporter: Rob Godfrey
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0
>
> Attachments:
> QPID-8114___[Broker-J]_Attempting_to_use_an_unknown_filter_type_incorrectly_causes_connect.patch
>
>
> As discovered in QPID-8113 if a client attempts to attach to a source using
> an unknown filter type (i.e. an unrecognised descriptor) the broker responds
> with a decode error similar to
> {{[0x555941994670]:0 <- @close(24) [error=@error(29)
> [condition=:"amqp:decode-error", description="Expected key type is 'Filter'
> but got 'DescribedType'"]]}}
> Instead the broker should simply fail to attach (i.e. attach with
> source=null) and then immediately detach with a {{not-implemented}} error.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1212) Incorrect "Dropped Presettled Count " in output of qdstat -g when receiver drops off
[ https://issues.apache.org/jira/browse/DISPATCH-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711681#comment-16711681 ] ASF subversion and git services commented on DISPATCH-1212: --- Commit f080baabd1a5eb37f94178b0b54a7a70c6271e73 in qpid-dispatch's branch refs/heads/master from [~ganeshmurthy] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=f080baa ] DISPATCH-1212 - When a receiver drops off, increment the core->dropped_presettled_deliveries if there are presettled deliveries in the undelivered list. > Incorrect "Dropped Presettled Count " in output of qdstat -g when receiver > drops off > - > > Key: DISPATCH-1212 > URL: https://issues.apache.org/jira/browse/DISPATCH-1212 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.4.1 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.5.0 > > > Steps to reproduce > # Start the router > # Start simple recv - python simple_recv.py --address 0.0.0.0/examples -m10 > # Start simple send - python simple_send_presettled.py --address > 0.0.0.0/examples -m300 > # 240 presettled messages were actually dropped by the router > # The output of qdstat shows Dropped Presettled Count = 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] [Assigned] (QPID-8114) [Broker-J] Attempting to use an unknown filter type incorrectly causes connection closure with a decode error
[
https://issues.apache.org/jira/browse/QPID-8114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy reassigned QPID-8114:
Assignee: Alex Rudyy
> [Broker-J] Attempting to use an unknown filter type incorrectly causes
> connection closure with a decode error
> -
>
> Key: QPID-8114
> URL: https://issues.apache.org/jira/browse/QPID-8114
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Reporter: Rob Godfrey
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0
>
> Attachments:
> QPID-8114___[Broker-J]_Attempting_to_use_an_unknown_filter_type_incorrectly_causes_connect.patch
>
>
> As discovered in QPID-8113 if a client attempts to attach to a source using
> an unknown filter type (i.e. an unrecognised descriptor) the broker responds
> with a decode error similar to
> {{[0x555941994670]:0 <- @close(24) [error=@error(29)
> [condition=:"amqp:decode-error", description="Expected key type is 'Filter'
> but got 'DescribedType'"]]}}
> Instead the broker should simply fail to attach (i.e. attach with
> source=null) and then immediately detach with a {{not-implemented}} error.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8114) [Broker-J] Attempting to use an unknown filter type incorrectly causes connection closure with a decode error
[
https://issues.apache.org/jira/browse/QPID-8114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711665#comment-16711665
]
ASF subversion and git services commented on QPID-8114:
---
Commit 489a7b85ca0335732595f701b49883ea4ed751c7 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=489a7b8 ]
QPID-8114: [Broker-J] Detach link with not-implemented error when unsupported
filter is supplied among source filters
> [Broker-J] Attempting to use an unknown filter type incorrectly causes
> connection closure with a decode error
> -
>
> Key: QPID-8114
> URL: https://issues.apache.org/jira/browse/QPID-8114
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Reporter: Rob Godfrey
>Priority: Major
> Fix For: qpid-java-broker-7.1.0
>
> Attachments:
> QPID-8114___[Broker-J]_Attempting_to_use_an_unknown_filter_type_incorrectly_causes_connect.patch
>
>
> As discovered in QPID-8113 if a client attempts to attach to a source using
> an unknown filter type (i.e. an unrecognised descriptor) the broker responds
> with a decode error similar to
> {{[0x555941994670]:0 <- @close(24) [error=@error(29)
> [condition=:"amqp:decode-error", description="Expected key type is 'Filter'
> but got 'DescribedType'"]]}}
> Instead the broker should simply fail to attach (i.e. attach with
> source=null) and then immediately detach with a {{not-implemented}} error.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7694) [Broker-J] Add 0-8..0-10 wire queue declare argument for holds on publish
[ https://issues.apache.org/jira/browse/QPID-7694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711258#comment-16711258 ] ASF subversion and git services commented on QPID-7694: --- Commit 10557c73e1201a1603fe070f315bce73e476eb7b 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=10557c7 ] QPID-7694: [Broker-J][Python Tests] Exclude test SequenceNumberTests.test_create_sequence_queue due to unsupported queue declare argument > [Broker-J] Add 0-8..0-10 wire queue declare argument for holds on publish > - > > Key: QPID-7694 > URL: https://issues.apache.org/jira/browse/QPID-7694 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > > From an ADDR address, I ought to be able to specify that the queue is > declared with holdOnPublishEnabled enabled.Currently > Queue#holdOnPublishEnabled is not mapped to a wire argument, so this is not > possible, -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8230) [Broker-J] Virtual Host children can be partially recovered and left in memory on failed Virtual Host startup
[ https://issues.apache.org/jira/browse/QPID-8230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8230: - Status: Reviewable (was: In Progress) > [Broker-J] Virtual Host children can be partially recovered and left in > memory on failed Virtual Host startup > - > > Key: QPID-8230 > URL: https://issues.apache.org/jira/browse/QPID-8230 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.6 >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > > When startup of stopped Virtual Host fails (for example, due to defect > QPID-8229) some of its children could be recovered and stored in virtual host > internal data structures. The subsequent virtual host restarts can fail with > another error "409 - Child of type already exists with id of ". This > error masks the original error causing virtual host failure in first place. > No error is reported into the broker logs. If original error causing first > virtual host startup failure can be fixed, the VHN restart or Broker restart > can give "409 - Child of type already exists with id of " -- 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] (QPID-8230) [Broker-J] Virtual Host children can be partially recovered and left in memory on failed Virtual Host startup
[ https://issues.apache.org/jira/browse/QPID-8230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy reassigned QPID-8230: Assignee: Alex Rudyy > [Broker-J] Virtual Host children can be partially recovered and left in > memory on failed Virtual Host startup > - > > Key: QPID-8230 > URL: https://issues.apache.org/jira/browse/QPID-8230 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.6 >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > > When startup of stopped Virtual Host fails (for example, due to defect > QPID-8229) some of its children could be recovered and stored in virtual host > internal data structures. The subsequent virtual host restarts can fail with > another error "409 - Child of type already exists with id of ". This > error masks the original error causing virtual host failure in first place. > No error is reported into the broker logs. If original error causing first > virtual host startup failure can be fixed, the VHN restart or Broker restart > can give "409 - Child of type already exists with id of " -- 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
Re: qpid-proton: migrating debian branch to ASF Git
Following up on this request, can anybody comment on this please? I'd like to get the existing 0.22.0-1 package into Git and then proceed to prepare a package of the latest version. On 22/11/2018 15:04, Daniel Pocock wrote: > > Hi everybody, > > I notice that nobody has contributed to the repository[1] maintained in > Debian and it may be easier to maintain the debian/sid branch in the > main qpid-proton repository[2] > > Would you be happy to accept me as a committer in the project so I can > push the branch and any future changes there? I only intend to commit > on the branch and within the debian/ subdirectory. > > Debian will freeze for the next release very soon so I'm keen to ensure > the package is well organized before that. > > I've also found that updating from 0.14.0 to 0.22.0 resolved issues we > were having in reSIProcate, thanks to those who provided feedback about > that. > > Regards, > > Daniel > > > 1. https://salsa.debian.org/middleware-team/qpid-proton/tree/debian/sid > 2. https://git1-us-west.apache.org/repos/asf?p=qpid-proton.git > - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
