[jira] [Resolved] (QPID-8248) qpid-config lists deleted exchange
[
https://issues.apache.org/jira/browse/QPID-8248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim resolved QPID-8248.
--
Resolution: Fixed
> qpid-config lists deleted exchange
> --
>
> Key: QPID-8248
> URL: https://issues.apache.org/jira/browse/QPID-8248
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
>Affects Versions: qpid-cpp-1.38.0
>Reporter: Gordon Sim
>Assignee: Gordon Sim
>Priority: Major
> Fix For: qpid-cpp-1.39.0
>
>
> In AMQP 0-10, the last exchange to which a message is sent is cached for
> improved performance. However this means that the exchange object will not be
> freed when deleted from the registry until all references to it are freed.
> To reproduce:
> {noformat}
> 1. qpid-config add exchange foo
> 2. qpid-send -a foo --content-stdin
> 3. enter some text to send a message
> 4. in another console qpid-config dell exchange foo
> 5. qpid-config exchanges
> {noformat}
> Should not see the deleted exchange in step 5.
--
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-8248) qpid-config lists deleted exchange
[
https://issues.apache.org/jira/browse/QPID-8248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645572#comment-16645572
]
Gordon Sim commented on QPID-8248:
--
Fixed by
https://git1-us-west.apache.org/repos/asf/qpid-proton/repo?p=qpid-cpp.git;a=commit;h=07673b0b3b5e902f3b6784cdb1ff29a3418f234b
> qpid-config lists deleted exchange
> --
>
> Key: QPID-8248
> URL: https://issues.apache.org/jira/browse/QPID-8248
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
>Affects Versions: qpid-cpp-1.38.0
>Reporter: Gordon Sim
>Assignee: Gordon Sim
>Priority: Major
> Fix For: qpid-cpp-1.39.0
>
>
> In AMQP 0-10, the last exchange to which a message is sent is cached for
> improved performance. However this means that the exchange object will not be
> freed when deleted from the registry until all references to it are freed.
> To reproduce:
> {noformat}
> 1. qpid-config add exchange foo
> 2. qpid-send -a foo --content-stdin
> 3. enter some text to send a message
> 4. in another console qpid-config dell exchange foo
> 5. qpid-config exchanges
> {noformat}
> Should not see the deleted exchange in step 5.
--
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] (QPID-8248) qpid-config lists deleted exchange
Gordon Sim created QPID-8248:
Summary: qpid-config lists deleted exchange
Key: QPID-8248
URL: https://issues.apache.org/jira/browse/QPID-8248
Project: Qpid
Issue Type: Bug
Components: C++ Broker
Affects Versions: qpid-cpp-1.38.0
Reporter: Gordon Sim
Assignee: Gordon Sim
Fix For: qpid-cpp-1.39.0
In AMQP 0-10, the last exchange to which a message is sent is cached for
improved performance. However this means that the exchange object will not be
freed when deleted from the registry until all references to it are freed.
To reproduce:
{noformat}
1. qpid-config add exchange foo
2. qpid-send -a foo --content-stdin
3. enter some text to send a message
4. in another console qpid-config dell exchange foo
5. qpid-config exchanges
{noformat}
Should not see the deleted exchange in step 5.
--
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-1142) Edge Router Module - Connection manager to select the active uplink
Ted Ross created DISPATCH-1142: -- Summary: Edge Router Module - Connection manager to select the active uplink Key: DISPATCH-1142 URL: https://issues.apache.org/jira/browse/DISPATCH-1142 Project: Qpid Dispatch Issue Type: New Feature Components: Router Node Reporter: Ted Ross Assignee: Ted Ross Fix For: Backlog An edge router may have multiple "edge-uplink" connections to interior routers. The edge router must designate exactly one of these connections as the active uplink and leave the others unused but ready as alternates to serve as the new active if the current active is lost. -- 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-1110) Intermittent router hang while running QIT's AMQP large content test
[ https://issues.apache.org/jira/browse/DISPATCH-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645321#comment-16645321 ] ASF GitHub Bot commented on DISPATCH-1110: -- Github user codecov-io commented on the issue: https://github.com/apache/qpid-dispatch/pull/390 # [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/390?src=pr=h1) Report > Merging [#390](https://codecov.io/gh/apache/qpid-dispatch/pull/390?src=pr=desc) into [master](https://codecov.io/gh/apache/qpid-dispatch/commit/d1d6e92df2d3adbba5d86e650e0d44a0ffc0b33e?src=pr=desc) will **decrease** coverage by `0.03%`. > The diff coverage is `90%`. [](https://codecov.io/gh/apache/qpid-dispatch/pull/390?src=pr=tree) ```diff @@Coverage Diff @@ ## master #390 +/- ## == - Coverage 85.06% 85.03% -0.04% == Files 73 73 Lines 1652316534 +11 == + Hits1405514059 +4 - Misses 2468 2475 +7 ``` | [Impacted Files](https://codecov.io/gh/apache/qpid-dispatch/pull/390?src=pr=tree) | Coverage Δ | | |---|---|---| | [src/message.c](https://codecov.io/gh/apache/qpid-dispatch/pull/390/diff?src=pr=tree#diff-c3JjL21lc3NhZ2UuYw==) | `88.09% <100%> (+0.02%)` | :arrow_up: | | [src/container.c](https://codecov.io/gh/apache/qpid-dispatch/pull/390/diff?src=pr=tree#diff-c3JjL2NvbnRhaW5lci5j) | `76.96% <100%> (+0.22%)` | :arrow_up: | | [src/router\_node.c](https://codecov.io/gh/apache/qpid-dispatch/pull/390/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9ub2RlLmM=) | `93.39% <82.35%> (-0.36%)` | :arrow_down: | | [src/router\_core/core\_timer.c](https://codecov.io/gh/apache/qpid-dispatch/pull/390/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2NvcmVfdGltZXIuYw==) | `94.64% <0%> (-1.79%)` | :arrow_down: | | [src/router\_core/transfer.c](https://codecov.io/gh/apache/qpid-dispatch/pull/390/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL3RyYW5zZmVyLmM=) | `90.07% <0%> (-0.46%)` | :arrow_down: | | [src/router\_core/connections.c](https://codecov.io/gh/apache/qpid-dispatch/pull/390/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2Nvbm5lY3Rpb25zLmM=) | `92.92% <0%> (-0.22%)` | :arrow_down: | | [src/parse.c](https://codecov.io/gh/apache/qpid-dispatch/pull/390/diff?src=pr=tree#diff-c3JjL3BhcnNlLmM=) | `86.1% <0%> (+0.27%)` | :arrow_up: | | [src/router\_core/agent\_link.c](https://codecov.io/gh/apache/qpid-dispatch/pull/390/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2FnZW50X2xpbmsuYw==) | `63.79% <0%> (+0.57%)` | :arrow_up: | -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/390?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/390?src=pr=footer). Last update [d1d6e92...568aad3](https://codecov.io/gh/apache/qpid-dispatch/pull/390?src=pr=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments). > Intermittent router hang while running QIT's AMQP large content test > > > Key: DISPATCH-1110 > URL: https://issues.apache.org/jira/browse/DISPATCH-1110 > Project: Qpid Dispatch > Issue Type: Bug > Environment: Standard QIT environment. > Once QIT is built and installed, the environment is set using the config.sh > file. See QUICKSTART for details. >Reporter: Kim van der Riet >Assignee: Ganesh Murthy >Priority: Major > Attachments: qdrouterd.conf > > > When running the Qpid Interop Test's AMQP large content test, a stand-alone > router will intermittently hang and cause the test to time out. > The failure appears to be limited to either the AMQP list or map types, and > usually with the C++ client as the message sender. The C++, Python2 and > Python3 as receiver clients have all seen this failure, but the Python2 > receiver client seems to reproduce more readily on my hardware. > In all cases, the test fails when the router sends what I suppose is the > final transfer of a large message (I have not added up/counted the bytes of > the many preceding transfers) to the consumer. The consumer then sends a > disposition, but the router does not respond again until the test times out. > The consumer can be seen to send
[GitHub] qpid-dispatch issue #390: DISPATCH-1110 - Added code to synchronously call A...
Github user codecov-io commented on the issue: https://github.com/apache/qpid-dispatch/pull/390 # [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/390?src=pr=h1) Report > Merging [#390](https://codecov.io/gh/apache/qpid-dispatch/pull/390?src=pr=desc) into [master](https://codecov.io/gh/apache/qpid-dispatch/commit/d1d6e92df2d3adbba5d86e650e0d44a0ffc0b33e?src=pr=desc) will **decrease** coverage by `0.03%`. > The diff coverage is `90%`. [](https://codecov.io/gh/apache/qpid-dispatch/pull/390?src=pr=tree) ```diff @@Coverage Diff @@ ## master #390 +/- ## == - Coverage 85.06% 85.03% -0.04% == Files 73 73 Lines 1652316534 +11 == + Hits1405514059 +4 - Misses 2468 2475 +7 ``` | [Impacted Files](https://codecov.io/gh/apache/qpid-dispatch/pull/390?src=pr=tree) | Coverage Π| | |---|---|---| | [src/message.c](https://codecov.io/gh/apache/qpid-dispatch/pull/390/diff?src=pr=tree#diff-c3JjL21lc3NhZ2UuYw==) | `88.09% <100%> (+0.02%)` | :arrow_up: | | [src/container.c](https://codecov.io/gh/apache/qpid-dispatch/pull/390/diff?src=pr=tree#diff-c3JjL2NvbnRhaW5lci5j) | `76.96% <100%> (+0.22%)` | :arrow_up: | | [src/router\_node.c](https://codecov.io/gh/apache/qpid-dispatch/pull/390/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9ub2RlLmM=) | `93.39% <82.35%> (-0.36%)` | :arrow_down: | | [src/router\_core/core\_timer.c](https://codecov.io/gh/apache/qpid-dispatch/pull/390/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2NvcmVfdGltZXIuYw==) | `94.64% <0%> (-1.79%)` | :arrow_down: | | [src/router\_core/transfer.c](https://codecov.io/gh/apache/qpid-dispatch/pull/390/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL3RyYW5zZmVyLmM=) | `90.07% <0%> (-0.46%)` | :arrow_down: | | [src/router\_core/connections.c](https://codecov.io/gh/apache/qpid-dispatch/pull/390/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2Nvbm5lY3Rpb25zLmM=) | `92.92% <0%> (-0.22%)` | :arrow_down: | | [src/parse.c](https://codecov.io/gh/apache/qpid-dispatch/pull/390/diff?src=pr=tree#diff-c3JjL3BhcnNlLmM=) | `86.1% <0%> (+0.27%)` | :arrow_up: | | [src/router\_core/agent\_link.c](https://codecov.io/gh/apache/qpid-dispatch/pull/390/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2FnZW50X2xpbmsuYw==) | `63.79% <0%> (+0.57%)` | :arrow_up: | -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/390?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/390?src=pr=footer). Last update [d1d6e92...568aad3](https://codecov.io/gh/apache/qpid-dispatch/pull/390?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 #390: DISPATCH-1110 - Added code to synchronously...
GitHub user ganeshmurthy opened a pull request: https://github.com/apache/qpid-dispatch/pull/390 DISPATCH-1110 - Added code to synchronously call AMQP-rx_handler to p⦠â¦ull in all data from the proton buffers at once. Also introduced link level flag to continue receiving without boundaries upon link detach arrival You can merge this pull request into a Git repository by running: $ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-1110 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/390.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 #390 commit 568aad33dc89e621bdfc7168dcc433137b3a6bc9 Author: Ganesh Murthy Date: 2018-10-10T17:29:41Z DISPATCH-1110 - Added code to synchronously call AMQP-rx_handler to pull in all data from the proton buffers at once. Also introduced link level flag to continue receiving without boundaries upon link detach arrival --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1110) Intermittent router hang while running QIT's AMQP large content test
[
https://issues.apache.org/jira/browse/DISPATCH-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645312#comment-16645312
]
ASF GitHub Bot commented on DISPATCH-1110:
--
GitHub user ganeshmurthy opened a pull request:
https://github.com/apache/qpid-dispatch/pull/390
DISPATCH-1110 - Added code to synchronously call AMQP-rx_handler to p…
…ull in all data from the proton buffers at once. Also introduced link
level flag to continue receiving without boundaries upon link detach arrival
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-1110
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/qpid-dispatch/pull/390.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 #390
commit 568aad33dc89e621bdfc7168dcc433137b3a6bc9
Author: Ganesh Murthy
Date: 2018-10-10T17:29:41Z
DISPATCH-1110 - Added code to synchronously call AMQP-rx_handler to pull in
all data from the proton buffers at once. Also introduced link level flag to
continue receiving without boundaries upon link detach arrival
> Intermittent router hang while running QIT's AMQP large content test
>
>
> Key: DISPATCH-1110
> URL: https://issues.apache.org/jira/browse/DISPATCH-1110
> Project: Qpid Dispatch
> Issue Type: Bug
> Environment: Standard QIT environment.
> Once QIT is built and installed, the environment is set using the config.sh
> file. See QUICKSTART for details.
>Reporter: Kim van der Riet
>Assignee: Ganesh Murthy
>Priority: Major
> Attachments: qdrouterd.conf
>
>
> When running the Qpid Interop Test's AMQP large content test, a stand-alone
> router will intermittently hang and cause the test to time out.
> The failure appears to be limited to either the AMQP list or map types, and
> usually with the C++ client as the message sender. The C++, Python2 and
> Python3 as receiver clients have all seen this failure, but the Python2
> receiver client seems to reproduce more readily on my hardware.
> In all cases, the test fails when the router sends what I suppose is the
> final transfer of a large message (I have not added up/counted the bytes of
> the many preceding transfers) to the consumer. The consumer then sends a
> disposition, but the router does not respond again until the test times out.
> The consumer can be seen to send heartbeats to the router, but the router
> does not send any of its own.
> {noformat}
> ... (plenty of 65550-sized frames R->C)
> R->C 5976 3.454766::1 ::1 AMQP65550
> R->C 5977 3.454775::1 ::1 AMQP65550
> R->C 5978 3.454783::1 ::1 AMQP48171
> C->R 5982 3.529881::1 ::1 AMQP115 disposition
> C->R 5984 7.530704::1 ::1 AMQP94 (empty)
> C->R 5986 11.532306 ::1 ::1 AMQP94 (empty)
> ...{noformat}
> There are no errors to be seen in the router logs other than when the
> consuming client is killed owing to the test timeout.
> {noformat}
> ...
> 2018-08-29 12:50:23.191754 -0400 SERVER (info) [14]: Accepted connection to
> ::1:amqp from ::1:37262
> 2018-08-29 12:51:19.562695 -0400 SERVER (info) [14]: Connection from
> ::1:37262 (to ::1:amqp) failed: amqp:connection:framing-error connection
> aborted
> {noformat}
> The reproducer is not very tight on this, and the error occurs about 50% of
> the time on my hardware.
--
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-1141) Add an event API in the router core to more cleanly support module interactions
Ted Ross created DISPATCH-1141: -- Summary: Add an event API in the router core to more cleanly support module interactions Key: DISPATCH-1141 URL: https://issues.apache.org/jira/browse/DISPATCH-1141 Project: Qpid Dispatch Issue Type: Improvement Components: Router Node Reporter: Ted Ross Assignee: Ted Ross Fix For: Backlog Router core modules are reactive and respond to changes in connection, link, and address state. This improvement provides an event API that can be used by modules to register for events that are of interest. -- 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-1132) Cleanup and memory reduction in the message module
[ https://issues.apache.org/jira/browse/DISPATCH-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-1132. Resolution: Fixed There's more work to be done here, but another Jira can be raised for later work. > Cleanup and memory reduction in the message module > -- > > Key: DISPATCH-1132 > URL: https://issues.apache.org/jira/browse/DISPATCH-1132 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Reporter: Ted Ross >Assignee: Ted Ross >Priority: Minor > Fix For: 1.4.0 > > > The message content record contains components that are either never used or > are seldom used (supporting message logging). This issue is for cleanup and > improving the efficiency of this module. > -- 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-1118) Fix Valgrind errors in the tests
[ https://issues.apache.org/jira/browse/DISPATCH-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-1118. Resolution: Fixed > Fix Valgrind errors in the tests > > > Key: DISPATCH-1118 > URL: https://issues.apache.org/jira/browse/DISPATCH-1118 > Project: Qpid Dispatch > Issue Type: Bug >Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.4.0 > > > The following valgrind errors are being flagged while running the > system_tests_multi_tenancy tests: > ==16718== Conditional jump or move depends on uninitialised value(s) > ==16718== Conditional jump or move depends on uninitialised value(s) > ==16718== Conditional jump or move depends on uninitialised value(s) > ==16718== Conditional jump or move depends on uninitialised value(s) > ==16718== Conditional jump or move depends on uninitialised value(s) > ==16718== Conditional jump or move depends on uninitialised value(s) > ==16718== Conditional jump or move depends on uninitialised value(s) > ==16718== Syscall param write(buf) points to uninitialised byte(s) -- 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-1123) Add a link-endpoint API for in-core modules that need to terminate links
[ https://issues.apache.org/jira/browse/DISPATCH-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-1123. Resolution: Fixed > Add a link-endpoint API for in-core modules that need to terminate links > > > Key: DISPATCH-1123 > URL: https://issues.apache.org/jira/browse/DISPATCH-1123 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node >Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.4.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-1133) Router core modules for Core extensions
[ https://issues.apache.org/jira/browse/DISPATCH-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-1133. Resolution: Fixed > Router core modules for Core extensions > --- > > Key: DISPATCH-1133 > URL: https://issues.apache.org/jira/browse/DISPATCH-1133 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Router Node >Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.4.0 > > > Introduce a formal notion of Router Core Module. Such a module is an > extension to the router core engine. The purpose of establishing core > modules is to isolate new functionality into a separate module file, rather > than embed it into the heart of the core files (which has happened too much). > The first core module is the test-hooks module used to aid in the testing of > the various core APIs (like the core_endpoint API). Modules shall be used in > the core extensions related to the Edge Router feature. > In the future, existing capabilities can be moved into modules to provide > better code organization in the core. The management agent is a good > candidate for this. Link-routing can also be moved out to a core module. > -- 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-417) Reduce GC pressure while using BytesMessage
[ https://issues.apache.org/jira/browse/QPIDJMS-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645131#comment-16645131 ] ASF GitHub Bot commented on QPIDJMS-417: Github user franz1981 commented on the issue: https://github.com/apache/qpid-jms/pull/22 @gemmellr > Can you elaborate on the benefits you measured here? I'd like to understand the extent to consider against the downside of exposing dep impl types throughout the code base. Fair enough :+1: I will come up with a test to measure the reduction of GC (with 100 bytes message) >The existing bits worked the way it did at least a small part because BytesMessage specified thats where it gets its behaviours from. Are we sure ByteBuf streams behave the same? Looking at the tests on Netty (where I have put recently a PR re some of these classes) it seems the case, but it is not part of Java util classes so thay can be wrong on it. Do we have some tests to verify the impact on the client of it? > Reduce GC pressure while using BytesMessage > --- > > Key: QPIDJMS-417 > URL: https://issues.apache.org/jira/browse/QPIDJMS-417 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.37.0 >Reporter: Francesco Nigro >Priority: Trivial > Fix For: 0.38.0 > > > JmsBytesMessage::initializeReading() creates DataInputStream that allocates > several byte[] and char[] even when no methods need them. > Using directly the underline ByteBufInputStream would reduce the amount of > garbage created while reducing the indirections needed to hit the underline > ByteBuf that hold the data. -- 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-jms issue #22: QPIDJMS-417 Reduce GC pressure while using BytesMessage
Github user franz1981 commented on the issue: https://github.com/apache/qpid-jms/pull/22 @gemmellr > Can you elaborate on the benefits you measured here? I'd like to understand the extent to consider against the downside of exposing dep impl types throughout the code base. Fair enough :+1: I will come up with a test to measure the reduction of GC (with 100 bytes message) >The existing bits worked the way it did at least a small part because BytesMessage specified thats where it gets its behaviours from. Are we sure ByteBuf streams behave the same? Looking at the tests on Netty (where I have put recently a PR re some of these classes) it seems the case, but it is not part of Java util classes so thay can be wrong on it. Do we have some tests to verify the impact on the client of it? --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-417) Reduce GC pressure while using BytesMessage
[ https://issues.apache.org/jira/browse/QPIDJMS-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645094#comment-16645094 ] ASF GitHub Bot commented on QPIDJMS-417: Github user gemmellr commented on the issue: https://github.com/apache/qpid-jms/pull/22 Can you elaborate on the benefits you measured here? I'd like to understand the extent to consider against the downside of exposing dep impl types throughout the code base. The existing bits worked the way it did at least a small part because BytesMessage specified thats where it gets its behaviours from. Are we sure ByteBuf streams behave the same? > Reduce GC pressure while using BytesMessage > --- > > Key: QPIDJMS-417 > URL: https://issues.apache.org/jira/browse/QPIDJMS-417 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.37.0 >Reporter: Francesco Nigro >Priority: Trivial > Fix For: 0.38.0 > > > JmsBytesMessage::initializeReading() creates DataInputStream that allocates > several byte[] and char[] even when no methods need them. > Using directly the underline ByteBufInputStream would reduce the amount of > garbage created while reducing the indirections needed to hit the underline > ByteBuf that hold the data. -- 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-jms issue #22: QPIDJMS-417 Reduce GC pressure while using BytesMessage
Github user gemmellr commented on the issue: https://github.com/apache/qpid-jms/pull/22 Can you elaborate on the benefits you measured here? I'd like to understand the extent to consider against the downside of exposing dep impl types throughout the code base. The existing bits worked the way it did at least a small part because BytesMessage specified thats where it gets its behaviours from. Are we sure ByteBuf streams behave the same? --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-417) Reduce GC pressure while using BytesMessage
[ https://issues.apache.org/jira/browse/QPIDJMS-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644992#comment-16644992 ] ASF GitHub Bot commented on QPIDJMS-417: Github user franz1981 commented on the issue: https://github.com/apache/qpid-jms/pull/22 @gemmellr @tabish121 I'm not very proud to have exposed directly the ByteBuf streams, but I have tried to use the right type on the facade and it makes the code really unreadable (and confuse the mocking framework too!!) :( ``` I getInputStream() throws JMSException; ``` > Reduce GC pressure while using BytesMessage > --- > > Key: QPIDJMS-417 > URL: https://issues.apache.org/jira/browse/QPIDJMS-417 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.37.0 >Reporter: Francesco Nigro >Priority: Trivial > Fix For: 0.38.0 > > > JmsBytesMessage::initializeReading() creates DataInputStream that allocates > several byte[] and char[] even when no methods need them. > Using directly the underline ByteBufInputStream would reduce the amount of > garbage created while reducing the indirections needed to hit the underline > ByteBuf that hold the data. -- 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-jms issue #22: QPIDJMS-417 Reduce GC pressure while using BytesMessage
Github user franz1981 commented on the issue: https://github.com/apache/qpid-jms/pull/22 @gemmellr @tabish121 I'm not very proud to have exposed directly the ByteBuf streams, but I have tried to use the right type on the facade and it makes the code really unreadable (and confuse the mocking framework too!!) :( ``` I getInputStream() throws JMSException; ``` --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-417) Reduce GC pressure while using BytesMessage
[ https://issues.apache.org/jira/browse/QPIDJMS-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644988#comment-16644988 ] ASF GitHub Bot commented on QPIDJMS-417: GitHub user franz1981 opened a pull request: https://github.com/apache/qpid-jms/pull/22 QPIDJMS-417 Reduce GC pressure while using BytesMessage Using directly ByteBuf-based streams allows to avoid unnecessary creations of intermediate instances to operate on the underline ByteBuf content You can merge this pull request into a Git repository by running: $ git pull https://github.com/franz1981/qpid-jms QPIDJMS-417 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-jms/pull/22.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 #22 commit e58904ad28dca3d0f9ca3ff7f2c8b01f29a33b4d Author: Francesco Nigro Date: 2018-10-10T13:35:56Z QPIDJMS-417 Reduce GC pressure while using BytesMessage Using directly ByteBuf-based streams allows to avoid unnecessary creations of intermediate instances to operate on the underline ByteBuf content > Reduce GC pressure while using BytesMessage > --- > > Key: QPIDJMS-417 > URL: https://issues.apache.org/jira/browse/QPIDJMS-417 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.37.0 >Reporter: Francesco Nigro >Priority: Trivial > Fix For: 0.38.0 > > > JmsBytesMessage::initializeReading() creates DataInputStream that allocates > several byte[] and char[] even when no methods need them. > Using directly the underline ByteBufInputStream would reduce the amount of > garbage created while reducing the indirections needed to hit the underline > ByteBuf that hold the data. -- 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-jms pull request #22: QPIDJMS-417 Reduce GC pressure while using BytesM...
GitHub user franz1981 opened a pull request: https://github.com/apache/qpid-jms/pull/22 QPIDJMS-417 Reduce GC pressure while using BytesMessage Using directly ByteBuf-based streams allows to avoid unnecessary creations of intermediate instances to operate on the underline ByteBuf content You can merge this pull request into a Git repository by running: $ git pull https://github.com/franz1981/qpid-jms QPIDJMS-417 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-jms/pull/22.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 #22 commit e58904ad28dca3d0f9ca3ff7f2c8b01f29a33b4d Author: Francesco Nigro Date: 2018-10-10T13:35:56Z QPIDJMS-417 Reduce GC pressure while using BytesMessage Using directly ByteBuf-based streams allows to avoid unnecessary creations of intermediate instances to operate on the underline ByteBuf content --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-417) Reduce GC pressure while using BytesMessage
Francesco Nigro created QPIDJMS-417: --- Summary: Reduce GC pressure while using BytesMessage Key: QPIDJMS-417 URL: https://issues.apache.org/jira/browse/QPIDJMS-417 Project: Qpid JMS Issue Type: Improvement Components: qpid-jms-client Affects Versions: 0.37.0 Reporter: Francesco Nigro Fix For: 0.38.0 JmsBytesMessage::initializeReading() creates DataInputStream that allocates several byte[] and char[] even when no methods need them. Using directly the underline ByteBufInputStream would reduce the amount of garbage created while reducing the indirections needed to hit the underline ByteBuf that hold the data. -- 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-1130) Expose which message priority is being handled by an inter-router link
[ https://issues.apache.org/jira/browse/DISPATCH-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644933#comment-16644933 ] ASF GitHub Bot commented on DISPATCH-1130: -- Github user ganeshmurthy commented on the issue: https://github.com/apache/qpid-dispatch/pull/389 @ErnieAllen This change looks good. As part of this PR, can you also please add a test to system_tests_qdstat to verify that the correct link priority is showing up? Thanks. > Expose which message priority is being handled by an inter-router link > -- > > Key: DISPATCH-1130 > URL: https://issues.apache.org/jira/browse/DISPATCH-1130 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Routing Engine >Affects Versions: 1.3.0 >Reporter: Ernest Allen >Priority: Major > > There is now an inter-router link for each message priority. Which priority a > link is handling should be exposed in the management call to retrieve link > information. > Once that is done, qdstat -l should be changed to display the priority. > -- 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 #389: DISPATCH-1130 Expose link priority
Github user ganeshmurthy commented on the issue: https://github.com/apache/qpid-dispatch/pull/389 @ErnieAllen This change looks good. As part of this PR, can you also please add a test to system_tests_qdstat to verify that the correct link priority is showing up? Thanks. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1130) Expose which message priority is being handled by an inter-router link
[ https://issues.apache.org/jira/browse/DISPATCH-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644864#comment-16644864 ] ASF GitHub Bot commented on DISPATCH-1130: -- Github user codecov-io commented on the issue: https://github.com/apache/qpid-dispatch/pull/389 # [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/389?src=pr=h1) Report > Merging [#389](https://codecov.io/gh/apache/qpid-dispatch/pull/389?src=pr=desc) into [master](https://codecov.io/gh/apache/qpid-dispatch/commit/d1d6e92df2d3adbba5d86e650e0d44a0ffc0b33e?src=pr=desc) will **decrease** coverage by `0.03%`. > The diff coverage is `100%`. [](https://codecov.io/gh/apache/qpid-dispatch/pull/389?src=pr=tree) ```diff @@Coverage Diff @@ ## master #389 +/- ## == - Coverage 85.06% 85.02% -0.04% == Files 73 73 Lines 1652316525 +2 == - Hits1405514051 -4 - Misses 2468 2474 +6 ``` | [Impacted Files](https://codecov.io/gh/apache/qpid-dispatch/pull/389?src=pr=tree) | Coverage Δ | | |---|---|---| | [src/router\_core/agent\_link.c](https://codecov.io/gh/apache/qpid-dispatch/pull/389/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2FnZW50X2xpbmsuYw==) | `63.63% <100%> (+0.41%)` | :arrow_up: | | [src/router\_core/core\_timer.c](https://codecov.io/gh/apache/qpid-dispatch/pull/389/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2NvcmVfdGltZXIuYw==) | `94.64% <0%> (-1.79%)` | :arrow_down: | | [src/router\_core/modules/core\_test\_hooks.c](https://codecov.io/gh/apache/qpid-dispatch/pull/389/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL21vZHVsZXMvY29yZV90ZXN0X2hvb2tzLmM=) | `89.54% <0%> (-1.37%)` | :arrow_down: | | [src/router\_core/router\_core.c](https://codecov.io/gh/apache/qpid-dispatch/pull/389/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL3JvdXRlcl9jb3JlLmM=) | `92.05% <0%> (-0.34%)` | :arrow_down: | | [src/container.c](https://codecov.io/gh/apache/qpid-dispatch/pull/389/diff?src=pr=tree#diff-c3JjL2NvbnRhaW5lci5j) | `76.55% <0%> (-0.2%)` | :arrow_down: | -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/389?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/389?src=pr=footer). Last update [d1d6e92...a81784b](https://codecov.io/gh/apache/qpid-dispatch/pull/389?src=pr=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments). > Expose which message priority is being handled by an inter-router link > -- > > Key: DISPATCH-1130 > URL: https://issues.apache.org/jira/browse/DISPATCH-1130 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Routing Engine >Affects Versions: 1.3.0 >Reporter: Ernest Allen >Priority: Major > > There is now an inter-router link for each message priority. Which priority a > link is handling should be exposed in the management call to retrieve link > information. > Once that is done, qdstat -l should be changed to display the priority. > -- 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 #389: DISPATCH-1130 Expose link priority
Github user codecov-io commented on the issue: https://github.com/apache/qpid-dispatch/pull/389 # [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/389?src=pr=h1) Report > Merging [#389](https://codecov.io/gh/apache/qpid-dispatch/pull/389?src=pr=desc) into [master](https://codecov.io/gh/apache/qpid-dispatch/commit/d1d6e92df2d3adbba5d86e650e0d44a0ffc0b33e?src=pr=desc) will **decrease** coverage by `0.03%`. > The diff coverage is `100%`. [](https://codecov.io/gh/apache/qpid-dispatch/pull/389?src=pr=tree) ```diff @@Coverage Diff @@ ## master #389 +/- ## == - Coverage 85.06% 85.02% -0.04% == Files 73 73 Lines 1652316525 +2 == - Hits1405514051 -4 - Misses 2468 2474 +6 ``` | [Impacted Files](https://codecov.io/gh/apache/qpid-dispatch/pull/389?src=pr=tree) | Coverage Π| | |---|---|---| | [src/router\_core/agent\_link.c](https://codecov.io/gh/apache/qpid-dispatch/pull/389/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2FnZW50X2xpbmsuYw==) | `63.63% <100%> (+0.41%)` | :arrow_up: | | [src/router\_core/core\_timer.c](https://codecov.io/gh/apache/qpid-dispatch/pull/389/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2NvcmVfdGltZXIuYw==) | `94.64% <0%> (-1.79%)` | :arrow_down: | | [src/router\_core/modules/core\_test\_hooks.c](https://codecov.io/gh/apache/qpid-dispatch/pull/389/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL21vZHVsZXMvY29yZV90ZXN0X2hvb2tzLmM=) | `89.54% <0%> (-1.37%)` | :arrow_down: | | [src/router\_core/router\_core.c](https://codecov.io/gh/apache/qpid-dispatch/pull/389/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL3JvdXRlcl9jb3JlLmM=) | `92.05% <0%> (-0.34%)` | :arrow_down: | | [src/container.c](https://codecov.io/gh/apache/qpid-dispatch/pull/389/diff?src=pr=tree#diff-c3JjL2NvbnRhaW5lci5j) | `76.55% <0%> (-0.2%)` | :arrow_down: | -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/389?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/389?src=pr=footer). Last update [d1d6e92...a81784b](https://codecov.io/gh/apache/qpid-dispatch/pull/389?src=pr=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments). --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1130) Expose which message priority is being handled by an inter-router link
[ https://issues.apache.org/jira/browse/DISPATCH-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644838#comment-16644838 ] ASF GitHub Bot commented on DISPATCH-1130: -- GitHub user ErnieAllen opened a pull request: https://github.com/apache/qpid-dispatch/pull/389 DISPATCH-1130 Expose link priority Adds priority to router.link management entity in the schema. Connects link.priority to schema attribute. Adds priority column to qdstat -l You can merge this pull request into a Git repository by running: $ git pull https://github.com/ErnieAllen/qpid-dispatch ernie-DISPATCH-1130 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/389.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 #389 commit a81784b9bcb98c9c46795bff8055ccb73b5fc4d1 Author: Ernest Allen Date: 2018-10-10T11:16:00Z DISPATCH-1130 Expose link priority > Expose which message priority is being handled by an inter-router link > -- > > Key: DISPATCH-1130 > URL: https://issues.apache.org/jira/browse/DISPATCH-1130 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Routing Engine >Affects Versions: 1.3.0 >Reporter: Ernest Allen >Priority: Major > > There is now an inter-router link for each message priority. Which priority a > link is handling should be exposed in the management call to retrieve link > information. > Once that is done, qdstat -l should be changed to display the priority. > -- 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 #389: DISPATCH-1130 Expose link priority
GitHub user ErnieAllen opened a pull request: https://github.com/apache/qpid-dispatch/pull/389 DISPATCH-1130 Expose link priority Adds priority to router.link management entity in the schema. Connects link.priority to schema attribute. Adds priority column to qdstat -l You can merge this pull request into a Git repository by running: $ git pull https://github.com/ErnieAllen/qpid-dispatch ernie-DISPATCH-1130 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/389.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 #389 commit a81784b9bcb98c9c46795bff8055ccb73b5fc4d1 Author: Ernest Allen Date: 2018-10-10T11:16:00Z DISPATCH-1130 Expose link priority --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-8238) [Broker-J] Improve performance of asynchronous publishing of transient messages into topic exchange having queues bound using non-overlapping selectors
[
https://issues.apache.org/jira/browse/QPID-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644766#comment-16644766
]
Alex Rudyy edited comment on QPID-8238 at 10/10/18 10:09 AM:
-
Apart from lower throughput of NIO layer, there is another aspect to the
performance issues I had failed to notice before. When running my performance
tests for longer amount of time I started to see long GC pauses on cleaning of
JVM Metaspace:
{noformat}
2018-10-10T05:32:11.250-0400: 1918.070: [GC (Allocation Failure)
2018-10-10T05:32:11.250-0400: 1918.071: [ParNew: 3145728K->3145728K(3145728K),
0.665 secs]2018-10-10T05:32:11.250-0400: 1918.071:
[CMS2018-10-10T05:32:11.363-0400: 1918.183: [CMS-concurrent-mark: 1.696/1.700
secs] [Times: user=51.70 sys=1.93, real=1.70 secs]
(concurrent mode failure): 6418793K->5067015K(6990528K), 43.9299868 secs]
9564521K->5067015K(10136256K), [Metaspace: 37679K->37679K(1083392K)],
43.9303498 secs] [Times: user=45.39 sys=0.00, real=43.92 secs]
2018-10-10T05:32:55.181-0400: 1962.001: Total time for which application
threads were stopped: 43.9323704 seconds, Stopping threads took: 0.0004930
seconds
2018-10-10T05:33:01.804-0400: 1968.624: [GC (Allocation Failure)
2018-10-10T05:33:01.804-0400: 1968.624: [ParNew: 3145728K->349504K(3145728K),
1.1281568 secs] 8881780K->6564365K(10136256K), 1.1284601 secs] [Times:
user=47.24 sys=0.01, real=1.13 secs]
2018-10-10T05:33:02.933-0400: 1969.753: Total time for which application
threads were stopped: 1.1302133 seconds, Stopping threads took: 0.0003888
seconds
2018-10-10T05:33:04.515-0400: 1971.335: [GC (Allocation Failure)
2018-10-10T05:33:04.515-0400: 1971.335: [ParNew: 3145728K->349504K(3145728K),
1.1778553 secs] 9360589K->7056409K(10136256K), 1.1781560 secs] [Times:
user=50.64 sys=0.00, real=1.18 secs]
2018-10-10T05:33:05.693-0400: 1972.513: Total time for which application
threads were stopped: 1.1804099 seconds, Stopping threads took: 0.0007907
seconds
2018-10-10T05:33:07.300-0400: 1974.120: [GC (Allocation Failure)
2018-10-10T05:33:07.300-0400: 1974.120: [ParNew: 3145728K->3145728K(3145728K),
0.554 secs]2018-10-10T05:33:07.300-0400: 1974.120:
[CMS2018-10-10T05:33:13.021-0400: 1979.841: [CMS-concurrent-preclean:
8.160/9.850 secs] [Times: user=110.86 sys=3.14, real=9.85 secs]
(concurrent mode failure): 6706905K->5608432K(6990528K), 48.4980083 secs]
9852633K->5608432K(10136256K), [Metaspace: 37689K->37689K(1083392K)],
48.4983623 secs] [Times: user=48.53 sys=0.00, real=48.49 secs]
2018-10-10T05:33:55.798-0400: 2022.619: Total time for which application
threads were stopped: 48.5008915 seconds, Stopping threads took: 0.0008321
seconds
2018-10-10T05:33:59.596-0400: 2026.417: [GC (Allocation Failure)
2018-10-10T05:33:59.596-0400: 2026.417: [ParNew: 3145728K->349504K(3145728K),
1.2127988 secs] 8892795K->6665263K(10136256K), 1.2130993 secs] [Times:
user=46.20 sys=0.10, real=1.21 secs]
2018-10-10T05:34:00.810-0400: 2027.630: Total time for which application
threads were stopped: 1.2151635 seconds, Stopping threads took: 0.0006465
seconds
2018-10-10T05:34:02.374-0400: 2029.194: [GC (Allocation Failure)
2018-10-10T05:34:02.374-0400: 2029.194: [ParNew: 3145728K->3145728K(3145728K),
0.684 secs]2018-10-10T05:34:02.374-0400: 2029.195:
[CMS2018-10-10T05:34:04.462-0400: 2031.282: [CMS-concurrent-mark: 3.616/3.626
secs] [Times: user=63.40 sys=3.03, real=3.62 secs]
(concurrent mode failure): 6315759K->5859983K(6990528K), 44.3028251 secs]
9461487K->5859983K(10136256K), [Metaspace: 37695K->37695K(1083392K)],
44.3032096 secs] [Times: user=60.53 sys=0.71, real=44.30 secs]
2018-10-10T05:34:46.678-0400: 2073.498: Total time for which application
threads were stopped: 44.3052052 seconds, Stopping threads took: 0.0005032
seconds
{noformat}
The nature of the pauses is not clear to me at the moment. I need to
investigate this further.
was (Author: alex.rufous):
Apart from lover throughput of NIO layer, there is another aspect to the
performance issues I had failed to notice before. When running my performance
tests for longer amount of time I started to see long GC pauses on cleaning of
JVM Metaspace:
{noformat}
2018-10-10T05:32:11.250-0400: 1918.070: [GC (Allocation Failure)
2018-10-10T05:32:11.250-0400: 1918.071: [ParNew: 3145728K->3145728K(3145728K),
0.665 secs]2018-10-10T05:32:11.250-0400: 1918.071:
[CMS2018-10-10T05:32:11.363-0400: 1918.183: [CMS-concurrent-mark: 1.696/1.700
secs] [Times: user=51.70 sys=1.93, real=1.70 secs]
(concurrent mode failure): 6418793K->5067015K(6990528K), 43.9299868 secs]
9564521K->5067015K(10136256K), [Metaspace: 37679K->37679K(1083392K)],
43.9303498 secs] [Times: user=45.39 sys=0.00, real=43.92 secs]
2018-10-10T05:32:55.181-0400: 1962.001: Total time for which application
threads were stopped: 43.9323704 seconds, Stopping threads took: 0.0004930
seconds
[jira] [Commented] (QPID-8238) [Broker-J] Improve performance of asynchronous publishing of transient messages into topic exchange having queues bound using non-overlapping selectors
[
https://issues.apache.org/jira/browse/QPID-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644766#comment-16644766
]
Alex Rudyy commented on QPID-8238:
--
Apart from lover throughput of NIO layer, there is another aspect to the
performance issues I had failed to notice before. When running my performance
tests for longer amount of time I started to see long GC pauses on cleaning of
JVM Metaspace:
{noformat}
2018-10-10T05:32:11.250-0400: 1918.070: [GC (Allocation Failure)
2018-10-10T05:32:11.250-0400: 1918.071: [ParNew: 3145728K->3145728K(3145728K),
0.665 secs]2018-10-10T05:32:11.250-0400: 1918.071:
[CMS2018-10-10T05:32:11.363-0400: 1918.183: [CMS-concurrent-mark: 1.696/1.700
secs] [Times: user=51.70 sys=1.93, real=1.70 secs]
(concurrent mode failure): 6418793K->5067015K(6990528K), 43.9299868 secs]
9564521K->5067015K(10136256K), [Metaspace: 37679K->37679K(1083392K)],
43.9303498 secs] [Times: user=45.39 sys=0.00, real=43.92 secs]
2018-10-10T05:32:55.181-0400: 1962.001: Total time for which application
threads were stopped: 43.9323704 seconds, Stopping threads took: 0.0004930
seconds
2018-10-10T05:33:01.804-0400: 1968.624: [GC (Allocation Failure)
2018-10-10T05:33:01.804-0400: 1968.624: [ParNew: 3145728K->349504K(3145728K),
1.1281568 secs] 8881780K->6564365K(10136256K), 1.1284601 secs] [Times:
user=47.24 sys=0.01, real=1.13 secs]
2018-10-10T05:33:02.933-0400: 1969.753: Total time for which application
threads were stopped: 1.1302133 seconds, Stopping threads took: 0.0003888
seconds
2018-10-10T05:33:04.515-0400: 1971.335: [GC (Allocation Failure)
2018-10-10T05:33:04.515-0400: 1971.335: [ParNew: 3145728K->349504K(3145728K),
1.1778553 secs] 9360589K->7056409K(10136256K), 1.1781560 secs] [Times:
user=50.64 sys=0.00, real=1.18 secs]
2018-10-10T05:33:05.693-0400: 1972.513: Total time for which application
threads were stopped: 1.1804099 seconds, Stopping threads took: 0.0007907
seconds
2018-10-10T05:33:07.300-0400: 1974.120: [GC (Allocation Failure)
2018-10-10T05:33:07.300-0400: 1974.120: [ParNew: 3145728K->3145728K(3145728K),
0.554 secs]2018-10-10T05:33:07.300-0400: 1974.120:
[CMS2018-10-10T05:33:13.021-0400: 1979.841: [CMS-concurrent-preclean:
8.160/9.850 secs] [Times: user=110.86 sys=3.14, real=9.85 secs]
(concurrent mode failure): 6706905K->5608432K(6990528K), 48.4980083 secs]
9852633K->5608432K(10136256K), [Metaspace: 37689K->37689K(1083392K)],
48.4983623 secs] [Times: user=48.53 sys=0.00, real=48.49 secs]
2018-10-10T05:33:55.798-0400: 2022.619: Total time for which application
threads were stopped: 48.5008915 seconds, Stopping threads took: 0.0008321
seconds
2018-10-10T05:33:59.596-0400: 2026.417: [GC (Allocation Failure)
2018-10-10T05:33:59.596-0400: 2026.417: [ParNew: 3145728K->349504K(3145728K),
1.2127988 secs] 8892795K->6665263K(10136256K), 1.2130993 secs] [Times:
user=46.20 sys=0.10, real=1.21 secs]
2018-10-10T05:34:00.810-0400: 2027.630: Total time for which application
threads were stopped: 1.2151635 seconds, Stopping threads took: 0.0006465
seconds
2018-10-10T05:34:02.374-0400: 2029.194: [GC (Allocation Failure)
2018-10-10T05:34:02.374-0400: 2029.194: [ParNew: 3145728K->3145728K(3145728K),
0.684 secs]2018-10-10T05:34:02.374-0400: 2029.195:
[CMS2018-10-10T05:34:04.462-0400: 2031.282: [CMS-concurrent-mark: 3.616/3.626
secs] [Times: user=63.40 sys=3.03, real=3.62 secs]
(concurrent mode failure): 6315759K->5859983K(6990528K), 44.3028251 secs]
9461487K->5859983K(10136256K), [Metaspace: 37695K->37695K(1083392K)],
44.3032096 secs] [Times: user=60.53 sys=0.71, real=44.30 secs]
2018-10-10T05:34:46.678-0400: 2073.498: Total time for which application
threads were stopped: 44.3052052 seconds, Stopping threads took: 0.0005032
seconds
{noformat}
The nature of the pauses is not clear to me at the moment. I need to
investigate this further.
> [Broker-J] Improve performance of asynchronous publishing of transient
> messages into topic exchange having queues bound using non-overlapping
> selectors
>
>
> Key: QPID-8238
> URL: https://issues.apache.org/jira/browse/QPID-8238
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.7
>
> Attachments:
> 0001-QPID-8238-Use-java.lang.String-for-keys-and-values-i.patch
>
>
> The performance of asynchronous publishing of transient messages into topic
> exchange which routes messages into queues bound using non-overlapping
> selectors is 2-3 times slower than performance of 0.32 broker. The
> performance degradation is observed
