[jira] [Commented] (PROTON-1900) Enabling the proton logs from a daemon process
[ https://issues.apache.org/jira/browse/PROTON-1900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16566308#comment-16566308 ] Praveen Bodke commented on PROTON-1900: --- Thank you Allan. We really appreciate it. I will test it my daemon application and will update the ticket. Regards Praveen > Enabling the proton logs from a daemon process > -- > > Key: PROTON-1900 > URL: https://issues.apache.org/jira/browse/PROTON-1900 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Reporter: Praveen Bodke >Priority: Minor > Attachments: log_hack.cpp > > > Is there a way to enable the proton logs from a daemon process. > As of now, we are able to get the proton logs from PN_TRACE_FRM and other > environment variables for non-daemon process. > We looked into the proton library specially the CPP binding and could not > find any specific API's. We are using the proton version 0.16. > It would be very helpful if we can get the logs from a daemon process. > Thanks. -- 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-1093) adding connectors dynamically causes extra connections for existing connectors
[
https://issues.apache.org/jira/browse/DISPATCH-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16565985#comment-16565985
]
ASF GitHub Bot commented on DISPATCH-1093:
--
Github user codecov-io commented on the issue:
https://github.com/apache/qpid-dispatch/pull/350
#
[Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/350?src=pr=h1)
Report
> Merging
[#350](https://codecov.io/gh/apache/qpid-dispatch/pull/350?src=pr=desc) into
[master](https://codecov.io/gh/apache/qpid-dispatch/commit/7285a47dcdd255af5ecc8d9c95fe8bdd28fb981d?src=pr=desc)
will **decrease** coverage by `0.01%`.
> The diff coverage is `100%`.
[](https://codecov.io/gh/apache/qpid-dispatch/pull/350?src=pr=tree)
```diff
@@Coverage Diff@@
## master#350 +/- ##
=
- Coverage 84.32% 84.3% -0.02%
=
Files 69 69
Lines 15670 15676 +6
=
+ Hits13214 13216 +2
- Misses 24562460 +4
```
| [Impacted
Files](https://codecov.io/gh/apache/qpid-dispatch/pull/350?src=pr=tree) |
Coverage Δ | |
|---|---|---|
|
[src/connection\_manager.c](https://codecov.io/gh/apache/qpid-dispatch/pull/350/diff?src=pr=tree#diff-c3JjL2Nvbm5lY3Rpb25fbWFuYWdlci5j)
| `75.05% <100%> (+0.15%)` | :arrow_up: |
|
[src/server.c](https://codecov.io/gh/apache/qpid-dispatch/pull/350/diff?src=pr=tree#diff-c3JjL3NlcnZlci5j)
| `84.35% <100%> (ø)` | :arrow_up: |
|
[src/router\_core/router\_core.c](https://codecov.io/gh/apache/qpid-dispatch/pull/350/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL3JvdXRlcl9jb3JlLmM=)
| `98.89% <0%> (-0.37%)` | :arrow_down: |
|
[src/parse.c](https://codecov.io/gh/apache/qpid-dispatch/pull/350/diff?src=pr=tree#diff-c3JjL3BhcnNlLmM=)
| `85.83% <0%> (-0.24%)` | :arrow_down: |
|
[src/message.c](https://codecov.io/gh/apache/qpid-dispatch/pull/350/diff?src=pr=tree#diff-c3JjL21lc3NhZ2UuYw==)
| `87.44% <0%> (-0.19%)` | :arrow_down: |
--
[Continue to review full report at
Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/350?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/350?src=pr=footer).
Last update
[7285a47...1f806ab](https://codecov.io/gh/apache/qpid-dispatch/pull/350?src=pr=lastupdated).
Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).
> adding connectors dynamically causes extra connections for existing connectors
> --
>
> Key: DISPATCH-1093
> URL: https://issues.apache.org/jira/browse/DISPATCH-1093
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.3.0
>
>
> Every time a new connector is created dynamically, the router will create a
> new connection for any existing connector. E.g. with some amqp server
> listening on ports 5673 and 5674:
> {noformat}
> $ echo '{"host":"localhost","port":5673}' | qdmanage CREATE --type=connector
> --name=foo --stdin
> {
> "verifyHostname": true,
> "stripAnnotations": "both",
> "name": "foo",
> "idleTimeoutSeconds": 16,
> "allowRedirect": true,
> "messageLoggingComponents": "none",
> "maxFrameSize": 16384,
> "host": "localhost",
> "cost": 1,
> "role": "normal",
> "failoverUrls": "amqp://localhost:5673",
> "maxSessions": 32768,
> "type": "org.apache.qpid.dispatch.connector",
> "port": "5673",
> "identity": "connector/localhost:5673:foo"
> }
> ]$ qdstat -c
> Connections
> id host container roledir
> security authentication tenant
>
> =
> 2 localhost:5673 a6022696-2483-49f5-8ea6-a6f50db0e7ae normal out
> no-security anonymous-user
> 3 127.0.0.1:56024 d964573c-297f-499c-a1f5-fed7d8e74f9c normal in
> no-security no-auth
> $ echo '{"host":"localhost","port":5674}' | qdmanage CREATE --type=connector
> --name=bar --stdin
> {
> "verifyHostname": true,
> "stripAnnotations": "both",
> "name": "bar",
> "idleTimeoutSeconds": 16,
> "allowRedirect": true,
>
[GitHub] qpid-dispatch issue #350: DISPATCH-1093 - Prevent additional connections fro...
Github user codecov-io commented on the issue: https://github.com/apache/qpid-dispatch/pull/350 # [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/350?src=pr=h1) Report > Merging [#350](https://codecov.io/gh/apache/qpid-dispatch/pull/350?src=pr=desc) into [master](https://codecov.io/gh/apache/qpid-dispatch/commit/7285a47dcdd255af5ecc8d9c95fe8bdd28fb981d?src=pr=desc) will **decrease** coverage by `0.01%`. > The diff coverage is `100%`. [](https://codecov.io/gh/apache/qpid-dispatch/pull/350?src=pr=tree) ```diff @@Coverage Diff@@ ## master#350 +/- ## = - Coverage 84.32% 84.3% -0.02% = Files 69 69 Lines 15670 15676 +6 = + Hits13214 13216 +2 - Misses 24562460 +4 ``` | [Impacted Files](https://codecov.io/gh/apache/qpid-dispatch/pull/350?src=pr=tree) | Coverage Π| | |---|---|---| | [src/connection\_manager.c](https://codecov.io/gh/apache/qpid-dispatch/pull/350/diff?src=pr=tree#diff-c3JjL2Nvbm5lY3Rpb25fbWFuYWdlci5j) | `75.05% <100%> (+0.15%)` | :arrow_up: | | [src/server.c](https://codecov.io/gh/apache/qpid-dispatch/pull/350/diff?src=pr=tree#diff-c3JjL3NlcnZlci5j) | `84.35% <100%> (ø)` | :arrow_up: | | [src/router\_core/router\_core.c](https://codecov.io/gh/apache/qpid-dispatch/pull/350/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL3JvdXRlcl9jb3JlLmM=) | `98.89% <0%> (-0.37%)` | :arrow_down: | | [src/parse.c](https://codecov.io/gh/apache/qpid-dispatch/pull/350/diff?src=pr=tree#diff-c3JjL3BhcnNlLmM=) | `85.83% <0%> (-0.24%)` | :arrow_down: | | [src/message.c](https://codecov.io/gh/apache/qpid-dispatch/pull/350/diff?src=pr=tree#diff-c3JjL21lc3NhZ2UuYw==) | `87.44% <0%> (-0.19%)` | :arrow_down: | -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/350?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/350?src=pr=footer). Last update [7285a47...1f806ab](https://codecov.io/gh/apache/qpid-dispatch/pull/350?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 #350: DISPATCH-1093 - Prevent additional connecti...
GitHub user ganeshmurthy opened a pull request: https://github.com/apache/qpid-dispatch/pull/350 DISPATCH-1093 - Prevent additional connections from being created fro⦠â¦m connectors when calling qd_connection_manager_start You can merge this pull request into a Git repository by running: $ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-1093 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/350.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 #350 commit 1f806aba46bb0ddcd49b098dbaae134143955e21 Author: Ganesh Murthy Date: 2018-08-01T20:33:11Z DISPATCH-1093 - Prevent additional connections from being created from connectors when calling qd_connection_manager_start --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1093) adding connectors dynamically causes extra connections for existing connectors
[
https://issues.apache.org/jira/browse/DISPATCH-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16565967#comment-16565967
]
ASF GitHub Bot commented on DISPATCH-1093:
--
GitHub user ganeshmurthy opened a pull request:
https://github.com/apache/qpid-dispatch/pull/350
DISPATCH-1093 - Prevent additional connections from being created fro…
…m connectors when calling qd_connection_manager_start
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-1093
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/qpid-dispatch/pull/350.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 #350
commit 1f806aba46bb0ddcd49b098dbaae134143955e21
Author: Ganesh Murthy
Date: 2018-08-01T20:33:11Z
DISPATCH-1093 - Prevent additional connections from being created from
connectors when calling qd_connection_manager_start
> adding connectors dynamically causes extra connections for existing connectors
> --
>
> Key: DISPATCH-1093
> URL: https://issues.apache.org/jira/browse/DISPATCH-1093
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.3.0
>
>
> Every time a new connector is created dynamically, the router will create a
> new connection for any existing connector. E.g. with some amqp server
> listening on ports 5673 and 5674:
> {noformat}
> $ echo '{"host":"localhost","port":5673}' | qdmanage CREATE --type=connector
> --name=foo --stdin
> {
> "verifyHostname": true,
> "stripAnnotations": "both",
> "name": "foo",
> "idleTimeoutSeconds": 16,
> "allowRedirect": true,
> "messageLoggingComponents": "none",
> "maxFrameSize": 16384,
> "host": "localhost",
> "cost": 1,
> "role": "normal",
> "failoverUrls": "amqp://localhost:5673",
> "maxSessions": 32768,
> "type": "org.apache.qpid.dispatch.connector",
> "port": "5673",
> "identity": "connector/localhost:5673:foo"
> }
> ]$ qdstat -c
> Connections
> id host container roledir
> security authentication tenant
>
> =
> 2 localhost:5673 a6022696-2483-49f5-8ea6-a6f50db0e7ae normal out
> no-security anonymous-user
> 3 127.0.0.1:56024 d964573c-297f-499c-a1f5-fed7d8e74f9c normal in
> no-security no-auth
> $ echo '{"host":"localhost","port":5674}' | qdmanage CREATE --type=connector
> --name=bar --stdin
> {
> "verifyHostname": true,
> "stripAnnotations": "both",
> "name": "bar",
> "idleTimeoutSeconds": 16,
> "allowRedirect": true,
> "messageLoggingComponents": "none",
> "maxFrameSize": 16384,
> "host": "localhost",
> "cost": 1,
> "role": "normal",
> "failoverUrls": "amqp://localhost:5674",
> "maxSessions": 32768,
> "type": "org.apache.qpid.dispatch.connector",
> "port": "5674",
> "identity": "connector/localhost:5674:bar"
> }
> $ qdstat -c
> Connections
> id host container roledir
> security authentication tenant
>
> =
> 2 localhost:5673 a6022696-2483-49f5-8ea6-a6f50db0e7ae normal out
> no-security anonymous-user
> 6 localhost:5673 a6022696-2483-49f5-8ea6-a6f50db0e7ae normal out
> no-security anonymous-user
> 5 localhost:5674 48fefab4-7df0-5244-b491-ad85278b22dc normal out
> no-security anonymous-user
> 7 127.0.0.1:56074 c4ddfd00-2ef5-473f-9687-28ee4bae4def normal in
> no-security no-auth
> $ echo '{"host":"localhost","port":5675}' | qdmanage CREATE --type=connector
> --name=baz --stdin
> {
> "verifyHostname": true,
> "stripAnnotations": "both",
> "name": "baz",
> "idleTimeoutSeconds": 16,
> "allowRedirect": true,
> "messageLoggingComponents": "none",
> "maxFrameSize": 16384,
> "host": "localhost",
> "cost": 1,
> "role": "normal",
> "failoverUrls": "amqp://localhost:5675",
> "maxSessions": 32768,
> "type": "org.apache.qpid.dispatch.connector",
> "port": "5675",
> "identity": "connector/localhost:5675:baz"
> }
> $ qdstat -c
> Connections
> id host container roledir
> security authentication tenant
>
>
[jira] [Commented] (DISPATCH-1094) Log file messages out of order according to time stamps
[
https://issues.apache.org/jira/browse/DISPATCH-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16565905#comment-16565905
]
Chuck Rolke commented on DISPATCH-1094:
---
The log file in question had several backwards steps in time. These
measurements were only for AMQP performatives and not for general log lines.
The largest backward step in time was *6.084 mS*.
{{new a_b. a: 2018-08-01 10:45:25.207209 b: 2018-08-01 10:45:25.206902 diff:
0:00:00.000307 a-lineno: 1440}}
{{2018-08-01 10:45:25.207209 -0400 SERVER (trace) [7]:0 <- @disposition(21)
[role=true, first=5, last=7, settled=true,}}
{{2018-08-01 10:45:25.206902 -0400 SERVER (trace) [6]:0 -> @transfer(20)
[handle=0, delivery-id=60,}}
{{new a_b. a: 2018-08-01 10:45:25.214388 b: 2018-08-01 10:45:25.213739 diff:
0:00:00.000649 a-lineno: 2040}}
{{2018-08-01 10:45:25.214388 -0400 SERVER (trace) [5]:0 <- @transfer(20)
[handle=0, delivery-id=37,}}
{{2018-08-01 10:45:25.213739 -0400 SERVER (trace) [7]:0 -> @transfer(20)
[handle=0, delivery-id=18,}}
{{new a_b. a: 2018-08-01 10:45:25.220572 b: 2018-08-01 10:45:25.214488 diff:
0:00:00.006084 a-lineno: 2093}}
{{2018-08-01 10:45:25.220572 -0400 SERVER (trace) [6]:0 <- @disposition(21)
[role=true, first=0, last=4, settled=true}}
{{2018-08-01 10:45:25.214488 -0400 SERVER (trace) [7]:0 -> @transfer(20)
[handle=0, delivery-id=19,}}
> Log file messages out of order according to time stamps
> ---
>
> Key: DISPATCH-1094
> URL: https://issues.apache.org/jira/browse/DISPATCH-1094
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.2.0
> Environment: Fedora 27
>Reporter: Chuck Rolke
>Priority: Major
>
> In a recent run with trace logging turned on the trace file had 5,335 lines
> with several hundred instances of non-increasing timestamps.
> {{2018-08-01 10:45:25.198173}}
> {{2018-08-01 10:45:25.198187}}
> {{2018-08-01 10:45:25.197941}}
> {{2018-08-01 10:45:25.197727}}
> {{2018-08-01 10:45:25.198238}}
> Log file readers need to know to SORT the log file before scrutinizing it too
> carefully.
--
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 #349: DISPATCH-1092: clear the cached session poi...
GitHub user kgiusti opened a pull request: https://github.com/apache/qpid-dispatch/pull/349 DISPATCH-1092: clear the cached session pointer when the session closes You can merge this pull request into a Git repository by running: $ git pull https://github.com/kgiusti/dispatch DISPATCH-1092 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/349.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 #349 commit ecfd325276cadc8c5da3e81159e30aa8ed582fef Author: Kenneth Giusti Date: 2018-07-31T18:44:42Z DISPATCH-1092: clear the cached session pointer when the session closes --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1092) in some cases qdrouterd crashes due to stale pn_session_t
[ https://issues.apache.org/jira/browse/DISPATCH-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16565824#comment-16565824 ] ASF GitHub Bot commented on DISPATCH-1092: -- GitHub user kgiusti opened a pull request: https://github.com/apache/qpid-dispatch/pull/349 DISPATCH-1092: clear the cached session pointer when the session closes You can merge this pull request into a Git repository by running: $ git pull https://github.com/kgiusti/dispatch DISPATCH-1092 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/349.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 #349 commit ecfd325276cadc8c5da3e81159e30aa8ed582fef Author: Kenneth Giusti Date: 2018-07-31T18:44:42Z DISPATCH-1092: clear the cached session pointer when the session closes > in some cases qdrouterd crashes due to stale pn_session_t > - > > Key: DISPATCH-1092 > URL: https://issues.apache.org/jira/browse/DISPATCH-1092 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.2.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.3.0 > > > The qd_connection_t stashes a reference to the connection's pn_session_t in > its pn_sess field, however once the pn_session_t is freed the stale reference > hangs around causing mayhem. -- 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-1094) Log file messages out of order according to time stamps
Chuck Rolke created DISPATCH-1094:
-
Summary: Log file messages out of order according to time stamps
Key: DISPATCH-1094
URL: https://issues.apache.org/jira/browse/DISPATCH-1094
Project: Qpid Dispatch
Issue Type: Bug
Affects Versions: 1.2.0
Environment: Fedora 27
Reporter: Chuck Rolke
In a recent run with trace logging turned on the trace file had 5,335 lines
with several hundred instances of non-increasing timestamps.
{{2018-08-01 10:45:25.198173}}
{{2018-08-01 10:45:25.198187}}
{{2018-08-01 10:45:25.197941}}
{{2018-08-01 10:45:25.197727}}
{{2018-08-01 10:45:25.198238}}
Log file readers need to know to SORT the log file before scrutinizing it too
carefully.
--
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-8134) qpid::client::Message::send multiple memory leaks
[ https://issues.apache.org/jira/browse/QPID-8134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16565546#comment-16565546 ] dan clark commented on QPID-8134: - Note also that "quid-stat \-m" continues to show growth at the qpid-cpp-server. Perhaps this problem manifests on both sides of the application. qpid-stat -m Broker Memory Statistics: Statistic Value malloc_arena 4,399,104 malloc_keepcost 3,104 malloc_ordblks 289 malloc_uordblks 1,808,272 malloc_hblkhd 0 malloc_fordblks 2,590,832 malloc_hblks 0 A few days later... qpid-stat -m Broker Memory Statistics: Statistic Value = malloc_arena 16,633,856 malloc_keepcost 133,552 malloc_ordblks 229 malloc_uordblks 1,980,240 malloc_hblkhd 0 malloc_fordblks 14,653,616 malloc_hblks 0 > qpid::client::Message::send multiple memory leaks > - > > Key: QPID-8134 > URL: https://issues.apache.org/jira/browse/QPID-8134 > Project: Qpid > Issue Type: Bug > Components: C++ Client >Affects Versions: qpid-cpp-1.37.0, qpid-cpp-1.38.0 > Environment: *CentOS* Linux release 7.4.1708 (Core) > Linux localhost.novalocal 3.10.0-327.el7.x86_64 #1 SMP Thu Nov 19 22:10:57 > UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > *qpid*-qmf-1.37.0-1.el7.x86_64 > *qpid*-dispatch-debuginfo-1.0.0-1.el7.x86_64 > python-*qpid*-1.37.0-1.el7.noarch > *qpid*-proton-c-0.18.1-1.el7.x86_64 > python-*qpid*-qmf-1.37.0-1.el7.x86_64 > *qpid*-proton-debuginfo-0.18.1-1.el7.x86_64 > *qpid*-cpp-debuginfo-1.37.0-1.el7.x86_64 > *qpid*-cpp-client-devel-1.37.0-1.el7.x86_64 > *qpid*-cpp-server-1.37.0-1.el7.x86_64 > *qpid*-cpp-client-1.37.0-1.el7.x86_64 > >Reporter: dan clark >Priority: Blocker > Labels: maven > Attachments: drain.cpp, godrain.sh, gospout.sh, qpid-stat.out, > spout.cpp, spout.log > > Original Estimate: 40h > Remaining Estimate: 40h > > There may be multiple leaks of the outgoing message structure and associated > fields when using the qpid::client::amqp0_10::SenderImpl::send function to > publish messages under certain setups. I will concede that there may be > options that are beyond my ken to ameliorate the leak of messages structures, > especially since there is an indication that under prolonged runs (a > demonized version of an application like spout) that the statistics for quidd > indicate increased acquires with zero releases. > The basic notion is illustrated with the test application spout (and drain). > Consider a long running daemon reducing the overhead of open/send/close by > keeping the message connection open for long periods of time. Then the logic > would be: start application/open connection. In a loop send data (and never > reach a close). Thus the drain application illustrates the behavior and > demonstrates the leak using valgrind by sending the data followed by an > exit(0). > Note also the lack of 'releases' associated with the 'acquires' in the stats > output. > Capturing the leaks using the test applications spout/drain required adding > an 'exit()' prior to the close, as during normal operations of a daemon, the > connection remains open for a sustained period of time, thus the leak of > structures within the c++ client library are found as structures still > tracked by the library and cleaned up on 'connection.close()', but they > should be cleaned up as a result of the completion of the send/receive ack or > the termination of the life of the message based on the TTL of the message, > which ever comes first. I have witnessed growth of the leaked structures > into the millions of messages lasting more than 24hours with short (300sec) > TTL of the messages based on scenarios attached using spout/drain as test > vehicle. > The attached spout.log uses a short 10message test and the spout.log contains > 5 sets of different structures leaked (found with the 'bytes in 10 blocks are > still reachable' lines, that are in line with much more sustained leaks when > running the application for multiple days with millions of messages. > The leaks seem to be associated with structures allocation 'stdstrings' to > save the "subject" and the "payload" for string based messages using send for > amq.topic output. > Suggested work arounds are welcome based on application level changes to > spout/drain (if they are missing key components) or changes to the > address/setup of the queues for amq.topic messages (see the 'gospout.sh and > godrain.sh' test drivers providing the specific address structures being used. > For example, the following is one of the 5 different categories of leaked > data from 'spout.log' on a valgrind analysis of the output post the
[jira] [Updated] (QPID-8134) qpid::client::Message::send multiple memory leaks
[ https://issues.apache.org/jira/browse/QPID-8134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dan clark updated QPID-8134: Affects Version/s: qpid-cpp-1.38.0 > qpid::client::Message::send multiple memory leaks > - > > Key: QPID-8134 > URL: https://issues.apache.org/jira/browse/QPID-8134 > Project: Qpid > Issue Type: Bug > Components: C++ Client >Affects Versions: qpid-cpp-1.37.0, qpid-cpp-1.38.0 > Environment: *CentOS* Linux release 7.4.1708 (Core) > Linux localhost.novalocal 3.10.0-327.el7.x86_64 #1 SMP Thu Nov 19 22:10:57 > UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > *qpid*-qmf-1.37.0-1.el7.x86_64 > *qpid*-dispatch-debuginfo-1.0.0-1.el7.x86_64 > python-*qpid*-1.37.0-1.el7.noarch > *qpid*-proton-c-0.18.1-1.el7.x86_64 > python-*qpid*-qmf-1.37.0-1.el7.x86_64 > *qpid*-proton-debuginfo-0.18.1-1.el7.x86_64 > *qpid*-cpp-debuginfo-1.37.0-1.el7.x86_64 > *qpid*-cpp-client-devel-1.37.0-1.el7.x86_64 > *qpid*-cpp-server-1.37.0-1.el7.x86_64 > *qpid*-cpp-client-1.37.0-1.el7.x86_64 > >Reporter: dan clark >Priority: Blocker > Labels: maven > Attachments: drain.cpp, godrain.sh, gospout.sh, qpid-stat.out, > spout.cpp, spout.log > > Original Estimate: 40h > Remaining Estimate: 40h > > There may be multiple leaks of the outgoing message structure and associated > fields when using the qpid::client::amqp0_10::SenderImpl::send function to > publish messages under certain setups. I will concede that there may be > options that are beyond my ken to ameliorate the leak of messages structures, > especially since there is an indication that under prolonged runs (a > demonized version of an application like spout) that the statistics for quidd > indicate increased acquires with zero releases. > The basic notion is illustrated with the test application spout (and drain). > Consider a long running daemon reducing the overhead of open/send/close by > keeping the message connection open for long periods of time. Then the logic > would be: start application/open connection. In a loop send data (and never > reach a close). Thus the drain application illustrates the behavior and > demonstrates the leak using valgrind by sending the data followed by an > exit(0). > Note also the lack of 'releases' associated with the 'acquires' in the stats > output. > Capturing the leaks using the test applications spout/drain required adding > an 'exit()' prior to the close, as during normal operations of a daemon, the > connection remains open for a sustained period of time, thus the leak of > structures within the c++ client library are found as structures still > tracked by the library and cleaned up on 'connection.close()', but they > should be cleaned up as a result of the completion of the send/receive ack or > the termination of the life of the message based on the TTL of the message, > which ever comes first. I have witnessed growth of the leaked structures > into the millions of messages lasting more than 24hours with short (300sec) > TTL of the messages based on scenarios attached using spout/drain as test > vehicle. > The attached spout.log uses a short 10message test and the spout.log contains > 5 sets of different structures leaked (found with the 'bytes in 10 blocks are > still reachable' lines, that are in line with much more sustained leaks when > running the application for multiple days with millions of messages. > The leaks seem to be associated with structures allocation 'stdstrings' to > save the "subject" and the "payload" for string based messages using send for > amq.topic output. > Suggested work arounds are welcome based on application level changes to > spout/drain (if they are missing key components) or changes to the > address/setup of the queues for amq.topic messages (see the 'gospout.sh and > godrain.sh' test drivers providing the specific address structures being used. > For example, the following is one of the 5 different categories of leaked > data from 'spout.log' on a valgrind analysis of the output post the send and > session.sync but prior connection.close(): > > ==3388== 3,680 bytes in 10 blocks are still reachable in loss record 233 of > 234 > ==3388== at 0x4C2A203: operator new(unsigned long) > (vg_replace_malloc.c:334) > ==3388== by 0x4EB046C: qpid::client::Message::Message(std::string const&, > std::string const&) (Message.cpp:31) > ==3388== by 0x51742C1: > qpid::client::amqp0_10::OutgoingMessage::OutgoingMessage() > (OutgoingMessage.cpp:167) > ==3388== by 0x5186200: > qpid::client::amqp0_10::SenderImpl::sendImpl(qpid::messaging::Message const&) > (SenderImpl.cpp:140) > ==3388== by 0x5186485: operator() (SenderImpl.h:114) > ==3388== by 0x5186485: execute > (SessionImpl.h:102) > ==3388== by 0x5186485: >
[jira] [Updated] (QPID-8134) qpid::client::Message::send multiple memory leaks
[ https://issues.apache.org/jira/browse/QPID-8134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dan clark updated QPID-8134: Priority: Blocker (was: Major) > qpid::client::Message::send multiple memory leaks > - > > Key: QPID-8134 > URL: https://issues.apache.org/jira/browse/QPID-8134 > Project: Qpid > Issue Type: Bug > Components: C++ Client >Affects Versions: qpid-cpp-1.37.0 > Environment: *CentOS* Linux release 7.4.1708 (Core) > Linux localhost.novalocal 3.10.0-327.el7.x86_64 #1 SMP Thu Nov 19 22:10:57 > UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > *qpid*-qmf-1.37.0-1.el7.x86_64 > *qpid*-dispatch-debuginfo-1.0.0-1.el7.x86_64 > python-*qpid*-1.37.0-1.el7.noarch > *qpid*-proton-c-0.18.1-1.el7.x86_64 > python-*qpid*-qmf-1.37.0-1.el7.x86_64 > *qpid*-proton-debuginfo-0.18.1-1.el7.x86_64 > *qpid*-cpp-debuginfo-1.37.0-1.el7.x86_64 > *qpid*-cpp-client-devel-1.37.0-1.el7.x86_64 > *qpid*-cpp-server-1.37.0-1.el7.x86_64 > *qpid*-cpp-client-1.37.0-1.el7.x86_64 > >Reporter: dan clark >Priority: Blocker > Labels: maven > Attachments: drain.cpp, godrain.sh, gospout.sh, qpid-stat.out, > spout.cpp, spout.log > > Original Estimate: 40h > Remaining Estimate: 40h > > There may be multiple leaks of the outgoing message structure and associated > fields when using the qpid::client::amqp0_10::SenderImpl::send function to > publish messages under certain setups. I will concede that there may be > options that are beyond my ken to ameliorate the leak of messages structures, > especially since there is an indication that under prolonged runs (a > demonized version of an application like spout) that the statistics for quidd > indicate increased acquires with zero releases. > The basic notion is illustrated with the test application spout (and drain). > Consider a long running daemon reducing the overhead of open/send/close by > keeping the message connection open for long periods of time. Then the logic > would be: start application/open connection. In a loop send data (and never > reach a close). Thus the drain application illustrates the behavior and > demonstrates the leak using valgrind by sending the data followed by an > exit(0). > Note also the lack of 'releases' associated with the 'acquires' in the stats > output. > Capturing the leaks using the test applications spout/drain required adding > an 'exit()' prior to the close, as during normal operations of a daemon, the > connection remains open for a sustained period of time, thus the leak of > structures within the c++ client library are found as structures still > tracked by the library and cleaned up on 'connection.close()', but they > should be cleaned up as a result of the completion of the send/receive ack or > the termination of the life of the message based on the TTL of the message, > which ever comes first. I have witnessed growth of the leaked structures > into the millions of messages lasting more than 24hours with short (300sec) > TTL of the messages based on scenarios attached using spout/drain as test > vehicle. > The attached spout.log uses a short 10message test and the spout.log contains > 5 sets of different structures leaked (found with the 'bytes in 10 blocks are > still reachable' lines, that are in line with much more sustained leaks when > running the application for multiple days with millions of messages. > The leaks seem to be associated with structures allocation 'stdstrings' to > save the "subject" and the "payload" for string based messages using send for > amq.topic output. > Suggested work arounds are welcome based on application level changes to > spout/drain (if they are missing key components) or changes to the > address/setup of the queues for amq.topic messages (see the 'gospout.sh and > godrain.sh' test drivers providing the specific address structures being used. > For example, the following is one of the 5 different categories of leaked > data from 'spout.log' on a valgrind analysis of the output post the send and > session.sync but prior connection.close(): > > ==3388== 3,680 bytes in 10 blocks are still reachable in loss record 233 of > 234 > ==3388== at 0x4C2A203: operator new(unsigned long) > (vg_replace_malloc.c:334) > ==3388== by 0x4EB046C: qpid::client::Message::Message(std::string const&, > std::string const&) (Message.cpp:31) > ==3388== by 0x51742C1: > qpid::client::amqp0_10::OutgoingMessage::OutgoingMessage() > (OutgoingMessage.cpp:167) > ==3388== by 0x5186200: > qpid::client::amqp0_10::SenderImpl::sendImpl(qpid::messaging::Message const&) > (SenderImpl.cpp:140) > ==3388== by 0x5186485: operator() (SenderImpl.h:114) > ==3388== by 0x5186485: execute > (SessionImpl.h:102) > ==3388== by 0x5186485: >
[jira] [Commented] (QPID-8134) qpid::client::Message::send multiple memory leaks
[ https://issues.apache.org/jira/browse/QPID-8134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16565534#comment-16565534 ] dan clark commented on QPID-8134: - Is the qpid cpp-client library an active project? This is a severity one bug memory leak in the send logic of the library. The leak is verified in version: 37 proton version 18. *qpid*-cpp-client-1.37.0-1.el7.x86_64 *qpid*-proton-c-0.18.1-1.el7.x86_64 *qpid*-cpp-server-1.37.0-1.el7.x86_64 Are there options to the sender or receiver that would work around the problem based on the formats provided in the examples? ==6139== 294,400 bytes in 4,600 blocks are still reachable in loss record 329 of 332 ==6139== at 0x4C2A203: operator new(unsigned long) (vg_replace_malloc.c:334) ==6139== by 0x848B529: qpid::client::no_keyword::AsyncSession_0_10::messageTransfer(std::string const&, unsigned char, unsigned char, qpid::client::Message const&, bool) (AsyncSession_0_10.cpp:63) ==6139== by 0x8791A8D: messageTransfer_with_named_params, boost::parameter::aux::arg_list >, boost::parameter::aux::empty_arg_list> > > (AsyncSession_0_10.h:306) ==6139== by 0x8791A8D: messageTransfer >, boost::parameter::aux::tagged_argument > (AsyncSession_0_10.h:300) ==6139== by 0x8791A8D: qpid::client::amqp0_10::OutgoingMessage::send(qpid::client::AsyncSession_0_10&, std::string const&, std::string const&) (OutgoingMessage.cpp:133) ==6139== by 0x87722E4: qpid::client::amqp0_10::ExchangeSink::send(qpid::client::AsyncSession_0_10&, std::string const&, qpid::client::amqp0_10::OutgoingMessage&) (AddressResolution.cpp:651) ==6139== by 0x87A22A1: qpid::client::amqp0_10::SenderImpl::sendImpl(qpid::messaging::Message const&) (SenderImpl.cpp:144) ==6139== by 0x87A2485: operator() (SenderImpl.h:114) ==6139== by 0x87A2485: execute (SessionImpl.h:102) ==6139== by 0x87A2485: qpid::client::amqp0_10::SenderImpl::send(qpid::messaging::Message const&, bool) (SenderImpl.cpp:49) > qpid::client::Message::send multiple memory leaks > - > > Key: QPID-8134 > URL: https://issues.apache.org/jira/browse/QPID-8134 > Project: Qpid > Issue Type: Bug > Components: C++ Client >Affects Versions: qpid-cpp-1.37.0 > Environment: *CentOS* Linux release 7.4.1708 (Core) > Linux localhost.novalocal 3.10.0-327.el7.x86_64 #1 SMP Thu Nov 19 22:10:57 > UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > *qpid*-qmf-1.37.0-1.el7.x86_64 > *qpid*-dispatch-debuginfo-1.0.0-1.el7.x86_64 > python-*qpid*-1.37.0-1.el7.noarch > *qpid*-proton-c-0.18.1-1.el7.x86_64 > python-*qpid*-qmf-1.37.0-1.el7.x86_64 > *qpid*-proton-debuginfo-0.18.1-1.el7.x86_64 > *qpid*-cpp-debuginfo-1.37.0-1.el7.x86_64 > *qpid*-cpp-client-devel-1.37.0-1.el7.x86_64 > *qpid*-cpp-server-1.37.0-1.el7.x86_64 > *qpid*-cpp-client-1.37.0-1.el7.x86_64 > >Reporter: dan clark >Priority: Major > Labels: maven > Attachments: drain.cpp, godrain.sh, gospout.sh, qpid-stat.out, > spout.cpp, spout.log > > Original Estimate: 40h > Remaining Estimate: 40h > > There may be multiple leaks of the outgoing message structure and associated > fields when using the qpid::client::amqp0_10::SenderImpl::send function to > publish messages under certain setups. I will concede that there may be > options that are beyond my ken to ameliorate the leak of messages structures, > especially since there is an indication that under prolonged runs (a > demonized version of an application like spout) that the statistics for quidd > indicate increased acquires with zero releases. > The basic notion is illustrated with the test application spout (and drain). > Consider a long running daemon reducing the overhead of open/send/close by > keeping the message connection open for long periods of time. Then the logic > would be: start application/open connection. In a loop send data (and never > reach a close). Thus the drain application illustrates the behavior and > demonstrates the leak using valgrind by sending the data followed by an > exit(0). > Note also the lack of 'releases' associated with the 'acquires' in the stats > output. > Capturing the leaks using the test applications spout/drain required adding > an 'exit()' prior to the close, as during normal operations of a daemon, the > connection remains open for a sustained period of time, thus the leak of > structures within the c++ client library are found as structures still > tracked by the library and cleaned up on 'connection.close()', but they > should be cleaned up as a result of the completion of the send/receive ack or > the termination of the life of the message based on the TTL of the message, > which ever comes first. I have witnessed growth of the leaked structures > into the millions of messages lasting more than
[jira] [Updated] (DISPATCH-1093) adding connectors dynamically causes extra connections for existing connectors
[
https://issues.apache.org/jira/browse/DISPATCH-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated DISPATCH-1093:
---
Priority: Major (was: Critical)
> adding connectors dynamically causes extra connections for existing connectors
> --
>
> Key: DISPATCH-1093
> URL: https://issues.apache.org/jira/browse/DISPATCH-1093
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.3.0
>
>
> Every time a new connector is created dynamically, the router will create a
> new connection for any existing connector. E.g. with some amqp server
> listening on ports 5673 and 5674:
> {noformat}
> $ echo '{"host":"localhost","port":5673}' | qdmanage CREATE --type=connector
> --name=foo --stdin
> {
> "verifyHostname": true,
> "stripAnnotations": "both",
> "name": "foo",
> "idleTimeoutSeconds": 16,
> "allowRedirect": true,
> "messageLoggingComponents": "none",
> "maxFrameSize": 16384,
> "host": "localhost",
> "cost": 1,
> "role": "normal",
> "failoverUrls": "amqp://localhost:5673",
> "maxSessions": 32768,
> "type": "org.apache.qpid.dispatch.connector",
> "port": "5673",
> "identity": "connector/localhost:5673:foo"
> }
> ]$ qdstat -c
> Connections
> id host container roledir
> security authentication tenant
>
> =
> 2 localhost:5673 a6022696-2483-49f5-8ea6-a6f50db0e7ae normal out
> no-security anonymous-user
> 3 127.0.0.1:56024 d964573c-297f-499c-a1f5-fed7d8e74f9c normal in
> no-security no-auth
> $ echo '{"host":"localhost","port":5674}' | qdmanage CREATE --type=connector
> --name=bar --stdin
> {
> "verifyHostname": true,
> "stripAnnotations": "both",
> "name": "bar",
> "idleTimeoutSeconds": 16,
> "allowRedirect": true,
> "messageLoggingComponents": "none",
> "maxFrameSize": 16384,
> "host": "localhost",
> "cost": 1,
> "role": "normal",
> "failoverUrls": "amqp://localhost:5674",
> "maxSessions": 32768,
> "type": "org.apache.qpid.dispatch.connector",
> "port": "5674",
> "identity": "connector/localhost:5674:bar"
> }
> $ qdstat -c
> Connections
> id host container roledir
> security authentication tenant
>
> =
> 2 localhost:5673 a6022696-2483-49f5-8ea6-a6f50db0e7ae normal out
> no-security anonymous-user
> 6 localhost:5673 a6022696-2483-49f5-8ea6-a6f50db0e7ae normal out
> no-security anonymous-user
> 5 localhost:5674 48fefab4-7df0-5244-b491-ad85278b22dc normal out
> no-security anonymous-user
> 7 127.0.0.1:56074 c4ddfd00-2ef5-473f-9687-28ee4bae4def normal in
> no-security no-auth
> $ echo '{"host":"localhost","port":5675}' | qdmanage CREATE --type=connector
> --name=baz --stdin
> {
> "verifyHostname": true,
> "stripAnnotations": "both",
> "name": "baz",
> "idleTimeoutSeconds": 16,
> "allowRedirect": true,
> "messageLoggingComponents": "none",
> "maxFrameSize": 16384,
> "host": "localhost",
> "cost": 1,
> "role": "normal",
> "failoverUrls": "amqp://localhost:5675",
> "maxSessions": 32768,
> "type": "org.apache.qpid.dispatch.connector",
> "port": "5675",
> "identity": "connector/localhost:5675:baz"
> }
> $ qdstat -c
> Connections
> id host container roledir
> security authentication tenant
>
> =
> 2 localhost:5673 a6022696-2483-49f5-8ea6-a6f50db0e7ae normal out
> no-security anonymous-user
> 6 localhost:5673 a6022696-2483-49f5-8ea6-a6f50db0e7ae normal out
> no-security anonymous-user
> 5 localhost:5674 48fefab4-7df0-5244-b491-ad85278b22dc normal out
> no-security anonymous-user
> 11 localhost:5673 a6022696-2483-49f5-8ea6-a6f50db0e7ae normal out
> no-security anonymous-user
> 10 localhost:5674 48fefab4-7df0-5244-b491-ad85278b22dc normal out
> no-security anonymous-user
> {noformat}
--
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-1093) adding connectors dynamically causes extra connections for existing connectors
[
https://issues.apache.org/jira/browse/DISPATCH-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated DISPATCH-1093:
---
Fix Version/s: 1.3.0
> adding connectors dynamically causes extra connections for existing connectors
> --
>
> Key: DISPATCH-1093
> URL: https://issues.apache.org/jira/browse/DISPATCH-1093
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
>Priority: Critical
> Fix For: 1.3.0
>
>
> Every time a new connector is created dynamically, the router will create a
> new connection for any existing connector. E.g. with some amqp server
> listening on ports 5673 and 5674:
> {noformat}
> $ echo '{"host":"localhost","port":5673}' | qdmanage CREATE --type=connector
> --name=foo --stdin
> {
> "verifyHostname": true,
> "stripAnnotations": "both",
> "name": "foo",
> "idleTimeoutSeconds": 16,
> "allowRedirect": true,
> "messageLoggingComponents": "none",
> "maxFrameSize": 16384,
> "host": "localhost",
> "cost": 1,
> "role": "normal",
> "failoverUrls": "amqp://localhost:5673",
> "maxSessions": 32768,
> "type": "org.apache.qpid.dispatch.connector",
> "port": "5673",
> "identity": "connector/localhost:5673:foo"
> }
> ]$ qdstat -c
> Connections
> id host container roledir
> security authentication tenant
>
> =
> 2 localhost:5673 a6022696-2483-49f5-8ea6-a6f50db0e7ae normal out
> no-security anonymous-user
> 3 127.0.0.1:56024 d964573c-297f-499c-a1f5-fed7d8e74f9c normal in
> no-security no-auth
> $ echo '{"host":"localhost","port":5674}' | qdmanage CREATE --type=connector
> --name=bar --stdin
> {
> "verifyHostname": true,
> "stripAnnotations": "both",
> "name": "bar",
> "idleTimeoutSeconds": 16,
> "allowRedirect": true,
> "messageLoggingComponents": "none",
> "maxFrameSize": 16384,
> "host": "localhost",
> "cost": 1,
> "role": "normal",
> "failoverUrls": "amqp://localhost:5674",
> "maxSessions": 32768,
> "type": "org.apache.qpid.dispatch.connector",
> "port": "5674",
> "identity": "connector/localhost:5674:bar"
> }
> $ qdstat -c
> Connections
> id host container roledir
> security authentication tenant
>
> =
> 2 localhost:5673 a6022696-2483-49f5-8ea6-a6f50db0e7ae normal out
> no-security anonymous-user
> 6 localhost:5673 a6022696-2483-49f5-8ea6-a6f50db0e7ae normal out
> no-security anonymous-user
> 5 localhost:5674 48fefab4-7df0-5244-b491-ad85278b22dc normal out
> no-security anonymous-user
> 7 127.0.0.1:56074 c4ddfd00-2ef5-473f-9687-28ee4bae4def normal in
> no-security no-auth
> $ echo '{"host":"localhost","port":5675}' | qdmanage CREATE --type=connector
> --name=baz --stdin
> {
> "verifyHostname": true,
> "stripAnnotations": "both",
> "name": "baz",
> "idleTimeoutSeconds": 16,
> "allowRedirect": true,
> "messageLoggingComponents": "none",
> "maxFrameSize": 16384,
> "host": "localhost",
> "cost": 1,
> "role": "normal",
> "failoverUrls": "amqp://localhost:5675",
> "maxSessions": 32768,
> "type": "org.apache.qpid.dispatch.connector",
> "port": "5675",
> "identity": "connector/localhost:5675:baz"
> }
> $ qdstat -c
> Connections
> id host container roledir
> security authentication tenant
>
> =
> 2 localhost:5673 a6022696-2483-49f5-8ea6-a6f50db0e7ae normal out
> no-security anonymous-user
> 6 localhost:5673 a6022696-2483-49f5-8ea6-a6f50db0e7ae normal out
> no-security anonymous-user
> 5 localhost:5674 48fefab4-7df0-5244-b491-ad85278b22dc normal out
> no-security anonymous-user
> 11 localhost:5673 a6022696-2483-49f5-8ea6-a6f50db0e7ae normal out
> no-security anonymous-user
> 10 localhost:5674 48fefab4-7df0-5244-b491-ad85278b22dc normal out
> no-security anonymous-user
> {noformat}
--
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-1093) adding connectors dynamically causes extra connections for existing connectors
[
https://issues.apache.org/jira/browse/DISPATCH-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated DISPATCH-1093:
---
Priority: Critical (was: Major)
> adding connectors dynamically causes extra connections for existing connectors
> --
>
> Key: DISPATCH-1093
> URL: https://issues.apache.org/jira/browse/DISPATCH-1093
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
>Priority: Critical
>
> Every time a new connector is created dynamically, the router will create a
> new connection for any existing connector. E.g. with some amqp server
> listening on ports 5673 and 5674:
> {noformat}
> $ echo '{"host":"localhost","port":5673}' | qdmanage CREATE --type=connector
> --name=foo --stdin
> {
> "verifyHostname": true,
> "stripAnnotations": "both",
> "name": "foo",
> "idleTimeoutSeconds": 16,
> "allowRedirect": true,
> "messageLoggingComponents": "none",
> "maxFrameSize": 16384,
> "host": "localhost",
> "cost": 1,
> "role": "normal",
> "failoverUrls": "amqp://localhost:5673",
> "maxSessions": 32768,
> "type": "org.apache.qpid.dispatch.connector",
> "port": "5673",
> "identity": "connector/localhost:5673:foo"
> }
> ]$ qdstat -c
> Connections
> id host container roledir
> security authentication tenant
>
> =
> 2 localhost:5673 a6022696-2483-49f5-8ea6-a6f50db0e7ae normal out
> no-security anonymous-user
> 3 127.0.0.1:56024 d964573c-297f-499c-a1f5-fed7d8e74f9c normal in
> no-security no-auth
> $ echo '{"host":"localhost","port":5674}' | qdmanage CREATE --type=connector
> --name=bar --stdin
> {
> "verifyHostname": true,
> "stripAnnotations": "both",
> "name": "bar",
> "idleTimeoutSeconds": 16,
> "allowRedirect": true,
> "messageLoggingComponents": "none",
> "maxFrameSize": 16384,
> "host": "localhost",
> "cost": 1,
> "role": "normal",
> "failoverUrls": "amqp://localhost:5674",
> "maxSessions": 32768,
> "type": "org.apache.qpid.dispatch.connector",
> "port": "5674",
> "identity": "connector/localhost:5674:bar"
> }
> $ qdstat -c
> Connections
> id host container roledir
> security authentication tenant
>
> =
> 2 localhost:5673 a6022696-2483-49f5-8ea6-a6f50db0e7ae normal out
> no-security anonymous-user
> 6 localhost:5673 a6022696-2483-49f5-8ea6-a6f50db0e7ae normal out
> no-security anonymous-user
> 5 localhost:5674 48fefab4-7df0-5244-b491-ad85278b22dc normal out
> no-security anonymous-user
> 7 127.0.0.1:56074 c4ddfd00-2ef5-473f-9687-28ee4bae4def normal in
> no-security no-auth
> $ echo '{"host":"localhost","port":5675}' | qdmanage CREATE --type=connector
> --name=baz --stdin
> {
> "verifyHostname": true,
> "stripAnnotations": "both",
> "name": "baz",
> "idleTimeoutSeconds": 16,
> "allowRedirect": true,
> "messageLoggingComponents": "none",
> "maxFrameSize": 16384,
> "host": "localhost",
> "cost": 1,
> "role": "normal",
> "failoverUrls": "amqp://localhost:5675",
> "maxSessions": 32768,
> "type": "org.apache.qpid.dispatch.connector",
> "port": "5675",
> "identity": "connector/localhost:5675:baz"
> }
> $ qdstat -c
> Connections
> id host container roledir
> security authentication tenant
>
> =
> 2 localhost:5673 a6022696-2483-49f5-8ea6-a6f50db0e7ae normal out
> no-security anonymous-user
> 6 localhost:5673 a6022696-2483-49f5-8ea6-a6f50db0e7ae normal out
> no-security anonymous-user
> 5 localhost:5674 48fefab4-7df0-5244-b491-ad85278b22dc normal out
> no-security anonymous-user
> 11 localhost:5673 a6022696-2483-49f5-8ea6-a6f50db0e7ae normal out
> no-security anonymous-user
> 10 localhost:5674 48fefab4-7df0-5244-b491-ad85278b22dc normal out
> no-security anonymous-user
> {noformat}
--
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
