[ANNOUNCE] Apache Qpid Dispatch 1.11.0 released
The Apache Qpid (http://qpid.apache.org) community is pleased to announce the immediate availability of Apache Qpid Dispatch 1.11.0 Qpid Dispatch is a router for the Advanced Message Queuing Protocol 1.0 (AMQP 1.0, ISO/IEC 19464, http://www.amqp.org). It provides a flexible and scalable interconnect between AMQP endpoints, whether they be clients, brokers, or other AMQP-enabled services. The release is available now from our website: http://qpid.apache.org/download.html Release notes can be found at: http://qpid.apache.org/releases/qpid-dispatch-1.11.0/release-notes.html Thanks to all involved. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8430) [qpid-cpp] Excessive memory use when rerouting messages
[ https://issues.apache.org/jira/browse/QPID-8430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet resolved QPID-8430. Resolution: Fixed > [qpid-cpp] Excessive memory use when rerouting messages > --- > > Key: QPID-8430 > URL: https://issues.apache.org/jira/browse/QPID-8430 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > When a message is rerouted several times, the broker's used memory increases > rapidly. This is counter-intuitive, considering that the messages themselves > are only passing from one queue to another. There is no evidence of a leak, > however, only a large growth in consumed memory. > An investigation has shown that the process of clearing traces from the > message when rerouting (whether they exist or not) causes the message and its > frames to be copied (for reasons of avoiding locks on the message, which can > affect performance). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8430) [qpid-cpp] Excessive memory use when rerouting messages
[ https://issues.apache.org/jira/browse/QPID-8430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17063404#comment-17063404 ] ASF subversion and git services commented on QPID-8430: --- Commit 8b1a3dc1c9f0708685a9a515536f2ae2e4d37807 in qpid-cpp's branch refs/heads/master from Kim van der Riet [ https://gitbox.apache.org/repos/asf?p=qpid-cpp.git;h=8b1a3dc ] QPID-8430: Excessive memory use when rerouting messages > [qpid-cpp] Excessive memory use when rerouting messages > --- > > Key: QPID-8430 > URL: https://issues.apache.org/jira/browse/QPID-8430 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > When a message is rerouted several times, the broker's used memory increases > rapidly. This is counter-intuitive, considering that the messages themselves > are only passing from one queue to another. There is no evidence of a leak, > however, only a large growth in consumed memory. > An investigation has shown that the process of clearing traces from the > message when rerouting (whether they exist or not) causes the message and its > frames to be copied (for reasons of avoiding locks on the message, which can > affect performance). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1607) [test] one_router test_48 ConnectionUptimeLastDlvTest intermittent fail
[ https://issues.apache.org/jira/browse/DISPATCH-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17063402#comment-17063402 ] ASF GitHub Bot commented on DISPATCH-1607: -- asfgit commented on pull request #706: DISPATCH-1607: Fix system_tests_one_router timing edge case URL: https://github.com/apache/qpid-dispatch/pull/706 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > [test] one_router test_48 ConnectionUptimeLastDlvTest intermittent fail > --- > > Key: DISPATCH-1607 > URL: https://issues.apache.org/jira/browse/DISPATCH-1607 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.10.0 >Reporter: Charles E. Rolke >Priority: Major > Fix For: 1.12.0 > > > This test fails with a dubious indication that delivery arrived before a > predicted delivery time. > There is some uncertainty with respect to the test timing declarations based > on event.reactor.schedule calls with integer timing granularity and the > connection statistics gathered with Node queries, also with integer timing > granularity. > If the connection takes only a few hundred microseconds to start up then the > router's internal uptime and last delivery times may appear to be a full > second behind the test times. The router uptime may be 1.00 S and the > external test expects >= 2.00 S and so the test fails. This is normal for > systems where the times are rounded down to the nearest whole second. > The fix for this test is to relax the timing limits by one second. > h6. Normal Test > ||conn/iter||self.uptime||self.lastDlv||conn uptime||conn lastDlv|| > |send/1|5|None|5|None| > |recv/1|5|None|5|None| > |send/1|7|2|7|2| > |recv/1|7|2|7|2| > h6. Failing Test > ||conn/iter||self.uptime||self.lastDlv||conn uptime||conn lastDlv|| > |send/1|5|None|6|None| > |recv/1|5|None|6|None| > |send/1|7|2|7|1| > |recv/1|7|2|7|1| -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1607) [test] one_router test_48 ConnectionUptimeLastDlvTest intermittent fail
[ https://issues.apache.org/jira/browse/DISPATCH-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17063401#comment-17063401 ] ASF subversion and git services commented on DISPATCH-1607: --- Commit 4ce0d49c34464e1c0fbc47afa2096f191cb904c2 in qpid-dispatch's branch refs/heads/master from Charles E. Rolke [ https://gitbox.apache.org/repos/asf?p=qpid-dispatch.git;h=4ce0d49 ] DISPATCH-1607: Fix system_tests_one_router timing edge case * Add allowance for integer scheduling and reporting intervals * Reduce test time from 7 to 3 seconds This closes #706 > [test] one_router test_48 ConnectionUptimeLastDlvTest intermittent fail > --- > > Key: DISPATCH-1607 > URL: https://issues.apache.org/jira/browse/DISPATCH-1607 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.10.0 >Reporter: Charles E. Rolke >Priority: Major > Fix For: 1.12.0 > > > This test fails with a dubious indication that delivery arrived before a > predicted delivery time. > There is some uncertainty with respect to the test timing declarations based > on event.reactor.schedule calls with integer timing granularity and the > connection statistics gathered with Node queries, also with integer timing > granularity. > If the connection takes only a few hundred microseconds to start up then the > router's internal uptime and last delivery times may appear to be a full > second behind the test times. The router uptime may be 1.00 S and the > external test expects >= 2.00 S and so the test fails. This is normal for > systems where the times are rounded down to the nearest whole second. > The fix for this test is to relax the timing limits by one second. > h6. Normal Test > ||conn/iter||self.uptime||self.lastDlv||conn uptime||conn lastDlv|| > |send/1|5|None|5|None| > |recv/1|5|None|5|None| > |send/1|7|2|7|2| > |recv/1|7|2|7|2| > h6. Failing Test > ||conn/iter||self.uptime||self.lastDlv||conn uptime||conn lastDlv|| > |send/1|5|None|6|None| > |recv/1|5|None|6|None| > |send/1|7|2|7|1| > |recv/1|7|2|7|1| -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] asfgit closed pull request #706: DISPATCH-1607: Fix system_tests_one_router timing edge case
asfgit closed pull request #706: DISPATCH-1607: Fix system_tests_one_router timing edge case URL: https://github.com/apache/qpid-dispatch/pull/706 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8430) [qpid-cpp] Excessive memory use when rerouting messages
Kim van der Riet created QPID-8430: -- Summary: [qpid-cpp] Excessive memory use when rerouting messages Key: QPID-8430 URL: https://issues.apache.org/jira/browse/QPID-8430 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: Kim van der Riet Assignee: Kim van der Riet When a message is rerouted several times, the broker's used memory increases rapidly. This is counter-intuitive, considering that the messages themselves are only passing from one queue to another. There is no evidence of a leak, however, only a large growth in consumed memory. An investigation has shown that the process of clearing traces from the message when rerouting (whether they exist or not) causes the message and its frames to be copied (for reasons of avoiding locks on the message, which can affect performance). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8425) [qpid-cpp] Channel leak on federation links
[
https://issues.apache.org/jira/browse/QPID-8425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet resolved QPID-8425.
Resolution: Fixed
> [qpid-cpp] Channel leak on federation links
> ---
>
> Key: QPID-8425
> URL: https://issues.apache.org/jira/browse/QPID-8425
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Major
> Attachments: BZ1748054.patch, channel_test.sh
>
>
> If a broker is repeatedly killed and restarted when it is federated to
> another broker, the second broker will run out of channels with a "channel
> pool is empty" message. The channel being used for the federation link is not
> being returned to the channel pool, and eventually (after ~32k restarts), the
> channel pool becomes exhausted.
> A reproducer is contained in the attached file "channel_test.sh". If a small
> change is made to the Link.cpp constructor which shrinks the channel pool to
> 5 (see the diff below), then this test will show the error without having to
> wait hours for ~32k restarts. The test does 10 restarts.
> {noformat}
> diff --git a/src/qpid/broker/Link.cpp b/src/qpid/broker/Link.cpp
> index 14737e730..790c8ac5e 100644
> --- a/src/qpid/broker/Link.cpp
> +++ b/src/qpid/broker/Link.cpp
> @@ -149,7 +149,7 @@ Link::Link(const string& _name,
> currentInterval(1),
> reconnectNext(0), // Index of next address for reconnecting in url.
> nextFreeChannel(1),
> - freeChannels(1, framing::CHANNEL_MAX),
> + freeChannels(1, 6),
> connection(0),
> agent(0),
> listener(l),
> {noformat}
> Running the test with the above temporary patch, the following is observed:
> {noformat}
> Channel allocations from broker 6001:
> 3377:2020-03-06 13:29:36 [Broker] debug Link qpid.tcp:localhost:5001
> allocates channel: 1
> 3538:2020-03-06 13:29:36 [Broker] debug Link qpid.tcp:localhost:5001
> allocates channel: 2
> 3739:2020-03-06 13:29:39 [Broker] debug Link qpid.tcp:localhost:5001
> allocates channel: 3
> 3934:2020-03-06 13:29:43 [Broker] debug Link qpid.tcp:localhost:5001
> allocates channel: 4
> 4022:2020-03-06 13:29:47 [Broker] debug Link qpid.tcp:localhost:5001
> allocates channel: 5
> 4110:2020-03-06 13:29:51 [System] debug Exception constructed: Link
> qpid.tcp:localhost:5001 channel pool is empty
> 4111:2020-03-06 13:29:51 [System] error Link qpid.tcp:localhost:5001 channel
> pool is empty
> 4154:2020-03-06 13:29:52 [System] debug Exception constructed: Link
> qpid.tcp:localhost:5001 channel pool is empty
> 4155:2020-03-06 13:29:52 [System] error Link qpid.tcp:localhost:5001 channel
> pool is empty
> 4253:2020-03-06 13:29:55 [System] debug Exception constructed: Link
> qpid.tcp:localhost:5001 channel pool is empty
> 4254:2020-03-06 13:29:55 [System] error Link qpid.tcp:localhost:5001 channel
> pool is empty
> 4297:2020-03-06 13:29:56 [System] debug Exception constructed: Link
> qpid.tcp:localhost:5001 channel pool is empty
> 4298:2020-03-06 13:29:56 [System] error Link qpid.tcp:localhost:5001 channel
> pool is empty
> ...
> (repeated several times more)
> {noformat}
>
> A fix which returns the channels on links that are closing to the channel
> pool is suggested in attached patch BZ1748054.patch. With this patch applied
> (together with the temporary pool-shrink patch above), the following is now
> observed:
> {noformat}
> Channel allocations from broker 6001:
> 2020-03-06 12:20:59 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 1
> 2020-03-06 12:20:59 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 2
> 2020-03-06 12:21:02 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 3
> 2020-03-06 12:21:06 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 4
> 2020-03-06 12:21:10 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 5
> 2020-03-06 12:21:14 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 1
> 2020-03-06 12:21:18 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 3
> 2020-03-06 12:21:22 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 4
> 2020-03-06 12:21:26 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 5
> 2020-03-06 12:21:30 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 1
> 2020-03-06 12:21:34 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 3
> 2020-03-06 12:21:38 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 4
> {noformat}
> Channel 2 is used by a bridge which remains open
> (qpid.bridge_session_amq.fanout). The channels are re-used in a cyclical
> pattern, which I think is the intention.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (QPID-8425) [qpid-cpp] Channel leak on federation links
[
https://issues.apache.org/jira/browse/QPID-8425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17063385#comment-17063385
]
Kim van der Riet commented on QPID-8425:
Fix commit on master:
[https://gitbox.apache.org/repos/asf?p=qpid-cpp.git;a=commit;h=79234737332c4605e2b5bd1e8e31ead45f81deca]
> [qpid-cpp] Channel leak on federation links
> ---
>
> Key: QPID-8425
> URL: https://issues.apache.org/jira/browse/QPID-8425
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Major
> Attachments: BZ1748054.patch, channel_test.sh
>
>
> If a broker is repeatedly killed and restarted when it is federated to
> another broker, the second broker will run out of channels with a "channel
> pool is empty" message. The channel being used for the federation link is not
> being returned to the channel pool, and eventually (after ~32k restarts), the
> channel pool becomes exhausted.
> A reproducer is contained in the attached file "channel_test.sh". If a small
> change is made to the Link.cpp constructor which shrinks the channel pool to
> 5 (see the diff below), then this test will show the error without having to
> wait hours for ~32k restarts. The test does 10 restarts.
> {noformat}
> diff --git a/src/qpid/broker/Link.cpp b/src/qpid/broker/Link.cpp
> index 14737e730..790c8ac5e 100644
> --- a/src/qpid/broker/Link.cpp
> +++ b/src/qpid/broker/Link.cpp
> @@ -149,7 +149,7 @@ Link::Link(const string& _name,
> currentInterval(1),
> reconnectNext(0), // Index of next address for reconnecting in url.
> nextFreeChannel(1),
> - freeChannels(1, framing::CHANNEL_MAX),
> + freeChannels(1, 6),
> connection(0),
> agent(0),
> listener(l),
> {noformat}
> Running the test with the above temporary patch, the following is observed:
> {noformat}
> Channel allocations from broker 6001:
> 3377:2020-03-06 13:29:36 [Broker] debug Link qpid.tcp:localhost:5001
> allocates channel: 1
> 3538:2020-03-06 13:29:36 [Broker] debug Link qpid.tcp:localhost:5001
> allocates channel: 2
> 3739:2020-03-06 13:29:39 [Broker] debug Link qpid.tcp:localhost:5001
> allocates channel: 3
> 3934:2020-03-06 13:29:43 [Broker] debug Link qpid.tcp:localhost:5001
> allocates channel: 4
> 4022:2020-03-06 13:29:47 [Broker] debug Link qpid.tcp:localhost:5001
> allocates channel: 5
> 4110:2020-03-06 13:29:51 [System] debug Exception constructed: Link
> qpid.tcp:localhost:5001 channel pool is empty
> 4111:2020-03-06 13:29:51 [System] error Link qpid.tcp:localhost:5001 channel
> pool is empty
> 4154:2020-03-06 13:29:52 [System] debug Exception constructed: Link
> qpid.tcp:localhost:5001 channel pool is empty
> 4155:2020-03-06 13:29:52 [System] error Link qpid.tcp:localhost:5001 channel
> pool is empty
> 4253:2020-03-06 13:29:55 [System] debug Exception constructed: Link
> qpid.tcp:localhost:5001 channel pool is empty
> 4254:2020-03-06 13:29:55 [System] error Link qpid.tcp:localhost:5001 channel
> pool is empty
> 4297:2020-03-06 13:29:56 [System] debug Exception constructed: Link
> qpid.tcp:localhost:5001 channel pool is empty
> 4298:2020-03-06 13:29:56 [System] error Link qpid.tcp:localhost:5001 channel
> pool is empty
> ...
> (repeated several times more)
> {noformat}
>
> A fix which returns the channels on links that are closing to the channel
> pool is suggested in attached patch BZ1748054.patch. With this patch applied
> (together with the temporary pool-shrink patch above), the following is now
> observed:
> {noformat}
> Channel allocations from broker 6001:
> 2020-03-06 12:20:59 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 1
> 2020-03-06 12:20:59 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 2
> 2020-03-06 12:21:02 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 3
> 2020-03-06 12:21:06 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 4
> 2020-03-06 12:21:10 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 5
> 2020-03-06 12:21:14 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 1
> 2020-03-06 12:21:18 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 3
> 2020-03-06 12:21:22 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 4
> 2020-03-06 12:21:26 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 5
> 2020-03-06 12:21:30 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 1
> 2020-03-06 12:21:34 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 3
> 2020-03-06 12:21:38 [Broker] debug Link qpid.tcp:localhost:5001 allocates
> channel: 4
> {noformat}
> Channel 2 is used by a bridge which remains open
> (qpid.bridge_session_amq.fanout). The channels are re-used in a cyclical
>
[jira] [Resolved] (DISPATCH-1608) Display workerThreads in the output of qdstat -g and qdmanage query --type=router
[ https://issues.apache.org/jira/browse/DISPATCH-1608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-1608. - Fix Version/s: 1.12.0 Resolution: Fixed > Display workerThreads in the output of qdstat -g and qdmanage query > --type=router > - > > Key: DISPATCH-1608 > URL: https://issues.apache.org/jira/browse/DISPATCH-1608 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 1.10.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.12.0 > > > It would be useful to show the number of worker threads in the output of > qdstat -g and qdmanage. Currently the only way to find out the number of > worker threads used by the router is to look at the router config file which > is inconvenient. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1608) Display workerThreads in the output of qdstat -g and qdmanage query --type=router
[ https://issues.apache.org/jira/browse/DISPATCH-1608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17063354#comment-17063354 ] ASF subversion and git services commented on DISPATCH-1608: --- Commit 51e1a358375e847f1b8ab3751f50ad7f4bd34ff4 in qpid-dispatch's branch refs/heads/master from Ganesh Murthy [ https://gitbox.apache.org/repos/asf?p=qpid-dispatch.git;h=51e1a35 ] DISPATCH-1608 - Display worker threads to the output of qdstat and qdmanage. This closes #707 > Display workerThreads in the output of qdstat -g and qdmanage query > --type=router > - > > Key: DISPATCH-1608 > URL: https://issues.apache.org/jira/browse/DISPATCH-1608 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 1.10.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > > It would be useful to show the number of worker threads in the output of > qdstat -g and qdmanage. Currently the only way to find out the number of > worker threads used by the router is to look at the router config file which > is inconvenient. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] asfgit closed pull request #707: DISPATCH-1608 - Display worker threads to the output of qdstat and qd…
asfgit closed pull request #707: DISPATCH-1608 - Display worker threads to the output of qdstat and qd… URL: https://github.com/apache/qpid-dispatch/pull/707 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1608) Display workerThreads in the output of qdstat -g and qdmanage query --type=router
[ https://issues.apache.org/jira/browse/DISPATCH-1608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17063355#comment-17063355 ] ASF GitHub Bot commented on DISPATCH-1608: -- asfgit commented on pull request #707: DISPATCH-1608 - Display worker threads to the output of qdstat and qd… URL: https://github.com/apache/qpid-dispatch/pull/707 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Display workerThreads in the output of qdstat -g and qdmanage query > --type=router > - > > Key: DISPATCH-1608 > URL: https://issues.apache.org/jira/browse/DISPATCH-1608 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 1.10.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > > It would be useful to show the number of worker threads in the output of > qdstat -g and qdmanage. Currently the only way to find out the number of > worker threads used by the router is to look at the router config file which > is inconvenient. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
