[jira] [Commented] (DISPATCH-1585) Allow defining address prefix shared by different multitenant listeners
[
https://issues.apache.org/jira/browse/DISPATCH-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17154032#comment-17154032
]
Ulf Lilleengen commented on DISPATCH-1585:
--
[~chug] I think i can see the issue then. I used aliases as a json array,
whereas it is just a comma-separated string. If I add multiple aliases this
way, I'm able to send to internal.example.com and receive from
external.example.com, as I wanted. Thanks!
{code:java}
[
["router", { "defaultDistribution": "unavailable"}],
["listener", { "host": "0.0.0.0", "port": 5672, "authenticatePeer": false,
"saslMechanisms": "ANONYMOUS", "multiTenant": true }],
["policy", {"enableVhostPolicy": true, "defaultVhost": "$default" }],
["vhost", { "hostname": "myprefix", "aliases":"internal.example.com,
external.example.com", "allowUnknownUser": true,
"groups":{"$default":{"remoteHosts":"*","sources":"*","targets":"*","allowDynamicSource":true,"allowAnonymousSender":true}}}],
["address", { "prefix": "myprefix/foo" }],
["log", {"module": "POLICY", "enable": "trace+"}]
]
{code}
> Allow defining address prefix shared by different multitenant listeners
> ---
>
> Key: DISPATCH-1585
> URL: https://issues.apache.org/jira/browse/DISPATCH-1585
> Project: Qpid Dispatch
> Issue Type: Wish
>Reporter: Ulf Lilleengen
>Assignee: Charles E. Rolke
>Priority: Major
> Fix For: 1.13.0
>
>
> At present, a multitenant router listener will prefix addresses with the
> hostname in the AMQP Open. However, given a configuration where it is
> desirable to expose a router address space for multiple DNS names, any
> address, linkRoute and autoLink configuration will need to be duplicated for
> each DNS name. This complicates router configuration significantly.
>
> Instead, having a way to specify which prefix to apply for a multitenant
> listener would allow reusing the same address, autoLink and linkRoute
> configuration for multiple listeners.
--
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] [Comment Edited] (DISPATCH-1585) Allow defining address prefix shared by different multitenant listeners
[
https://issues.apache.org/jira/browse/DISPATCH-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17153870#comment-17153870
]
Ulf Lilleengen edited comment on DISPATCH-1585 at 7/8/20, 7:26 PM:
---
[~chug] I just tried a fresh build of master, and I'm not able to get it
working. I have the following config:
{code:java}
[
["router", { "defaultDistribution": "unavailable"}],
["listener", { "host": "0.0.0.0", "port": 5672, "authenticatePeer": false,
"saslMechanisms": "ANONYMOUS", "multiTenant": true }],
["policy", {"enableVhostPolicy": true, "defaultVhost": "$default" }],
["vhost", { "hostname": "myprefix", "aliases":["internal.example.com"],
"allowUnknownUser": true,
"groups":{"$default":{"remoteHosts":"*","sources":"*","targets":"*","allowDynamicSource":true,"allowAnonymousSender":true}}}],
["address", { "prefix": "myprefix/foo" }]
]
{code}
I then try to connect the sender as follows:
{code:java}
PN_TRACE_FRM=1 python /usr/share/proton/examples/python/simple_recv.py -a
amqp://internal.example.com:5672/foo {code}
And I'm getting this in the router log
{code:java}
2020-07-08 19:20:11.292964 + POLICY (info) DENY AMQP Open for user
'anonymous', rhost '127.0.0.1', vhost 'internal.example.com': No policy defined
for vhost{code}
Is there something wrong in my config, or is there some additional change
needed in the router?
was (Author: lulf):
[~chug] I just tried a fresh build of master, and I'm not able to get it
working. I have the following config:
{code:java}
[
["router", { "defaultDistribution": "unavailable"}],
["listener", { "host": "0.0.0.0", "port": 5672, "authenticatePeer": false,
"saslMechanisms": "ANONYMOUS", "multiTenant": true }],
["policy", {"enableVhostPolicy": true, "defaultVhost": "$default" }],
["vhost", { "hostname": "myprefix", "aliases":["internal.example.com"],
"allowUnknownUser": true,
"groups":{"$default":{"remoteHosts":"*","sources":"*","targets":"*","allowDynamicSource":true,"allowAnonymousSender":true}}}],
["address", { "prefix": "myprefix/foo" }]
]
{code}
I then try to connect the sender as follows:
{code:java}
PN_TRACE_FRM=1 python /usr/share/proton/examples/python/simple_recv.py -a
amqp://internal.example.com:5672/foo {code}
And I'm getting this in the router log
{code:java}
2020-07-08 19:20:11.292964 + POLICY (info) DENY AMQP Open for user
'anonymous', rhost '127.0.0.1', vhost 'internal.example.com': No policy defined
for vhost{code}
> Allow defining address prefix shared by different multitenant listeners
> ---
>
> Key: DISPATCH-1585
> URL: https://issues.apache.org/jira/browse/DISPATCH-1585
> Project: Qpid Dispatch
> Issue Type: Wish
>Reporter: Ulf Lilleengen
>Assignee: Charles E. Rolke
>Priority: Major
> Fix For: 1.13.0
>
>
> At present, a multitenant router listener will prefix addresses with the
> hostname in the AMQP Open. However, given a configuration where it is
> desirable to expose a router address space for multiple DNS names, any
> address, linkRoute and autoLink configuration will need to be duplicated for
> each DNS name. This complicates router configuration significantly.
>
> Instead, having a way to specify which prefix to apply for a multitenant
> listener would allow reusing the same address, autoLink and linkRoute
> configuration for multiple listeners.
--
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-1585) Allow defining address prefix shared by different multitenant listeners
[
https://issues.apache.org/jira/browse/DISPATCH-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17153870#comment-17153870
]
Ulf Lilleengen commented on DISPATCH-1585:
--
[~chug] I just tried a fresh build of master, and I'm not able to get it
working. I have the following config:
{code:java}
[
["router", { "defaultDistribution": "unavailable"}],
["listener", { "host": "0.0.0.0", "port": 5672, "authenticatePeer": false,
"saslMechanisms": "ANONYMOUS", "multiTenant": true }],
["policy", {"enableVhostPolicy": true, "defaultVhost": "$default" }],
["vhost", { "hostname": "myprefix", "aliases":["internal.example.com"],
"allowUnknownUser": true,
"groups":{"$default":{"remoteHosts":"*","sources":"*","targets":"*","allowDynamicSource":true,"allowAnonymousSender":true}}}],
["address", { "prefix": "myprefix/foo" }]
]
{code}
I then try to connect the sender as follows:
{code:java}
PN_TRACE_FRM=1 python /usr/share/proton/examples/python/simple_recv.py -a
amqp://internal.example.com:5672/foo {code}
And I'm getting this in the router log
{code:java}
2020-07-08 19:20:11.292964 + POLICY (info) DENY AMQP Open for user
'anonymous', rhost '127.0.0.1', vhost 'internal.example.com': No policy defined
for vhost{code}
> Allow defining address prefix shared by different multitenant listeners
> ---
>
> Key: DISPATCH-1585
> URL: https://issues.apache.org/jira/browse/DISPATCH-1585
> Project: Qpid Dispatch
> Issue Type: Wish
>Reporter: Ulf Lilleengen
>Assignee: Charles E. Rolke
>Priority: Major
> Fix For: 1.13.0
>
>
> At present, a multitenant router listener will prefix addresses with the
> hostname in the AMQP Open. However, given a configuration where it is
> desirable to expose a router address space for multiple DNS names, any
> address, linkRoute and autoLink configuration will need to be duplicated for
> each DNS name. This complicates router configuration significantly.
>
> Instead, having a way to specify which prefix to apply for a multitenant
> listener would allow reusing the same address, autoLink and linkRoute
> configuration for multiple listeners.
--
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-1656) Allow user-configured connection properties in the Open performative
[
https://issues.apache.org/jira/browse/DISPATCH-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17118990#comment-17118990
]
Ulf Lilleengen commented on DISPATCH-1656:
--
I think it looks great [~kgiusti] !
> Allow user-configured connection properties in the Open performative
>
>
> Key: DISPATCH-1656
> URL: https://issues.apache.org/jira/browse/DISPATCH-1656
> Project: Qpid Dispatch
> Issue Type: New Feature
> Components: Router Node
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Major
> Fix For: 1.13.0
>
>
> This feature would add a new "openProperties" map attribute to the
> org.apache.qpid.dispatch.connector and org.apache.qpid.dispatch.listener
> management entities. This new attribute is optional.
> The contents of the map are expected to be specified in JSON. The keys must
> be restricted to ASCII characters only in order to be encoded as AMQP 1.0
> Symbol types on the wire.
> Key values that start with the prefixes *qd.* or *x-opt-qd.* are reserved and
> must not be used.
> In addition, the following keys are reserved and must not be used:
> product
> version
> failover-server-list
> network-host
> port
> scheme
> hostname
> The openProperties keys and values will be merged into the connection
> properties field of the outgoing Open performative when establishing or
> accepting connections.
> The openProperties attribute is NOT allowed on connector or listener entities
> with roles of either "inter-router" or "edge".
> The openProperties attribute is NOT allowed on listener entities than enable
> http, i.e. http: true.
> Example:
> {{connector {}}
> {{ name: broker}}
> {{ role: route-container}}
> {{ host: 127.0.0.1}}
> {{ port: 22180}}
> {{ saslMechanisms: ANONYMOUS}}
> {{ *openProperties: {*}}
> {{ *"foo": "bar",*}}
> {{ *"integer": 7,*}}
> {{*"list": ["a", 1, "b", -9, true],*}}
> {{*"map": \{"key1": null, "key2": [1, 2, 3]\},*}}
> {{*}*}}
> {{ cost: 10}}
> {{}}}
> The resulting connection properties in the outgoing Open performative would
> include the following map entries:
> {{Symbol(foo): String(bar),}}
> {{Symbol(integer): Int(7),}}
> {{Symbol(list): List(String(a), Int(1), String(b), Int(-9), Boolean),}}
> {{Symbol(map): Map(String(key1): Null, String(key2): List(Int(1), Int(2),
> Int(3)))}}
>
--
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-1585) Allow defining address prefix shared by different multitenant listeners
[ https://issues.apache.org/jira/browse/DISPATCH-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17115045#comment-17115045 ] Ulf Lilleengen commented on DISPATCH-1585: -- [~chug] That would solve our use case, and seems like an approach its easy to work with and understand. Keeping accounting and statistics per vhost is fine as well. Upon mutating the aliases, it would be good if it checked aliases of other vhosts and reported a conflict, though I think we could potentially handle that in our Kubernetes operator. Thanks! > Allow defining address prefix shared by different multitenant listeners > --- > > Key: DISPATCH-1585 > URL: https://issues.apache.org/jira/browse/DISPATCH-1585 > Project: Qpid Dispatch > Issue Type: Wish >Reporter: Ulf Lilleengen >Priority: Major > > At present, a multitenant router listener will prefix addresses with the > hostname in the AMQP Open. However, given a configuration where it is > desirable to expose a router address space for multiple DNS names, any > address, linkRoute and autoLink configuration will need to be duplicated for > each DNS name. This complicates router configuration significantly. > > Instead, having a way to specify which prefix to apply for a multitenant > listener would allow reusing the same address, autoLink and linkRoute > configuration for multiple listeners. -- 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-1656) Allow user-configured connection properties in the Open performative
[
https://issues.apache.org/jira/browse/DISPATCH-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17107951#comment-17107951
]
Ulf Lilleengen commented on DISPATCH-1656:
--
(Tangent response :D)
[~jross] you can already use JSON for the whole router config file. The format
is a bit ... special, but it works. Example:
{code:java}
[
["listener", { "host": "0.0.0.0", "port": 56721, "authenticatePeer": false,
"saslMechanisms": "ANONYMOUS", "multiTenant": true }],
["policy", {"enableVhostPolicy": true, "defaultVhost": "$default" }],
]
{code}
[~kgiusti] In this case though, will the config element be a JSON string
within this struct, or a JSON "native" object?
> Allow user-configured connection properties in the Open performative
>
>
> Key: DISPATCH-1656
> URL: https://issues.apache.org/jira/browse/DISPATCH-1656
> Project: Qpid Dispatch
> Issue Type: New Feature
> Components: Router Node
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Major
> Fix For: 1.13.0
>
>
> This feature would add a new "openProperties" attribute to the
> org.apache.qpid.dispatch.connector and org.apache.qpid.dispatch.listener
> management entities. This new attribute is type string and is optional.
> If supplied it will consist of a series of one or more field entries
> separated by commas. A field entry is text in the form "key: value", where
> "key" that can be encoded as a valid AMQP 1.0 Symbol type. Value will be
> encoded as an AMQP 1.0 String type.
> The key or value text may contain spaces, colons or commas but must be
> enclosed in single quotes (see example below) if it does.
> Duplicate keys are NOT allowed.
> Key values that start with *qd.* or *x-opt-qd.* are reserved and must not be
> used.
> In addition, the following keys are reserved and must not be used:
> product
> version
> failover-server-list
> network-host
> port
> scheme
> hostname
> The openProperties keys and values will be merged into the connection
> properties field of the outgoing Open performative when establishing or
> accepting connections.
> The openProperties attribute is NOT allowed on connector or listener entities
> with roles of either "inter-router" or "edge".
> The openProperties attribute is NOT allowed on listener entities than enable
> http, i.e. http: true.
> Example:
> {{connector {}}
> {{ name: broker}}
> {{ role: route-container}}
> {{ host: 127.0.0.1}}
> {{ port: 22180}}
> {{ saslMechanisms: ANONYMOUS}}
> {{ *openProperties: "foo: bar,baz:foo, bar: 'Hello: you big, wonderful
> world!'"*}}
> {{}}}
>
> The resulting connection properties in the outgoing Open performative would
> include the following map entries:
> {{Symbol(foo): String(bar),}}
> {{Symbol(baz): String(foo),}}
> {{Symbol(bar): String(Hello: you big, wonderful world!)}}
--
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] [Comment Edited] (DISPATCH-1656) Allow user-configured connection properties in the Open performative
[
https://issues.apache.org/jira/browse/DISPATCH-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17107951#comment-17107951
]
Ulf Lilleengen edited comment on DISPATCH-1656 at 5/15/20, 5:22 AM:
(Tangent response :D)
[~jross] you can already use JSON for the whole router config file. The format
is a bit ... special IMHO, but it works. Example:
{code:java}
[
["listener", { "host": "0.0.0.0", "port": 56721, "authenticatePeer": false,
"saslMechanisms": "ANONYMOUS", "multiTenant": true }],
["policy", {"enableVhostPolicy": true, "defaultVhost": "$default" }],
]
{code}
[~kgiusti] In this case though, will the config element be a JSON string
within this struct, or a JSON "native" object?
was (Author: lulf):
(Tangent response :D)
[~jross] you can already use JSON for the whole router config file. The format
is a bit ... special, but it works. Example:
{code:java}
[
["listener", { "host": "0.0.0.0", "port": 56721, "authenticatePeer": false,
"saslMechanisms": "ANONYMOUS", "multiTenant": true }],
["policy", {"enableVhostPolicy": true, "defaultVhost": "$default" }],
]
{code}
[~kgiusti] In this case though, will the config element be a JSON string
within this struct, or a JSON "native" object?
> Allow user-configured connection properties in the Open performative
>
>
> Key: DISPATCH-1656
> URL: https://issues.apache.org/jira/browse/DISPATCH-1656
> Project: Qpid Dispatch
> Issue Type: New Feature
> Components: Router Node
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Major
> Fix For: 1.13.0
>
>
> This feature would add a new "openProperties" attribute to the
> org.apache.qpid.dispatch.connector and org.apache.qpid.dispatch.listener
> management entities. This new attribute is type string and is optional.
> If supplied it will consist of a series of one or more field entries
> separated by commas. A field entry is text in the form "key: value", where
> "key" that can be encoded as a valid AMQP 1.0 Symbol type. Value will be
> encoded as an AMQP 1.0 String type.
> The key or value text may contain spaces, colons or commas but must be
> enclosed in single quotes (see example below) if it does.
> Duplicate keys are NOT allowed.
> Key values that start with *qd.* or *x-opt-qd.* are reserved and must not be
> used.
> In addition, the following keys are reserved and must not be used:
> product
> version
> failover-server-list
> network-host
> port
> scheme
> hostname
> The openProperties keys and values will be merged into the connection
> properties field of the outgoing Open performative when establishing or
> accepting connections.
> The openProperties attribute is NOT allowed on connector or listener entities
> with roles of either "inter-router" or "edge".
> The openProperties attribute is NOT allowed on listener entities than enable
> http, i.e. http: true.
> Example:
> {{connector {}}
> {{ name: broker}}
> {{ role: route-container}}
> {{ host: 127.0.0.1}}
> {{ port: 22180}}
> {{ saslMechanisms: ANONYMOUS}}
> {{ *openProperties: "foo: bar,baz:foo, bar: 'Hello: you big, wonderful
> world!'"*}}
> {{}}}
>
> The resulting connection properties in the outgoing Open performative would
> include the following map entries:
> {{Symbol(foo): String(bar),}}
> {{Symbol(baz): String(foo),}}
> {{Symbol(bar): String(Hello: you big, wonderful world!)}}
--
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-1656) Allow user-configured connection properties in the Open performative
[
https://issues.apache.org/jira/browse/DISPATCH-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17107538#comment-17107538
]
Ulf Lilleengen commented on DISPATCH-1656:
--
+1 to use JSON, it makes it a lot easier to generate the router config than
writing a generator specifically for this format.
> Allow user-configured connection properties in the Open performative
>
>
> Key: DISPATCH-1656
> URL: https://issues.apache.org/jira/browse/DISPATCH-1656
> Project: Qpid Dispatch
> Issue Type: New Feature
> Components: Router Node
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Major
> Fix For: 1.13.0
>
>
> This feature would add a new "openProperties" attribute to the
> org.apache.qpid.dispatch.connector and org.apache.qpid.dispatch.listener
> management entities. This new attribute is type string and is optional.
> If supplied it will consist of a series of one or more field entries
> separated by commas. A field entry is text in the form "key: value", where
> "key" that can be encoded as a valid AMQP 1.0 Symbol type. Value will be
> encoded as an AMQP 1.0 String type.
> The key or value text may contain spaces, colons or commas but must be
> enclosed in single quotes (see example below) if it does.
> Duplicate keys are NOT allowed.
> Key values that start with *qd.* or *x-opt-qd.* are reserved and must not be
> used.
> In addition, the following keys are reserved and must not be used:
> product
> version
> failover-server-list
> network-host
> port
> scheme
> hostname
> The openProperties keys and values will be merged into the connection
> properties field of the outgoing Open performative when establishing or
> accepting connections.
> The openProperties attribute is NOT allowed on connector or listener entities
> with roles of either "inter-router" or "edge".
> The openProperties attribute is NOT allowed on listener entities than enable
> http, i.e. http: true.
> Example:
> {{connector {}}
> {{ name: broker}}
> {{ role: route-container}}
> {{ host: 127.0.0.1}}
> {{ port: 22180}}
> {{ saslMechanisms: ANONYMOUS}}
> {{ *openProperties: "foo: bar,baz:foo, bar: 'Hello: you big, wonderful
> world!'"*}}
> {{}}}
>
> The resulting connection properties in the outgoing Open performative would
> include the following map entries:
> {{Symbol(foo): String(bar),}}
> {{Symbol(baz): String(foo),}}
> {{Symbol(bar): String(Hello: you big, wonderful world!)}}
--
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] [Created] (DISPATCH-1647) Listener with invalid sslProfile reference can be created
Ulf Lilleengen created DISPATCH-1647: Summary: Listener with invalid sslProfile reference can be created Key: DISPATCH-1647 URL: https://issues.apache.org/jira/browse/DISPATCH-1647 Project: Qpid Dispatch Issue Type: Improvement Reporter: Ulf Lilleengen If you create a listener using AMQP management and it refers to a non-existing sslProfile, or the sslProfile does not contain the certificate files referenced by the sslProfile, there is no error returned. When you try to create a client to the router with an invalid configuration, the router fails to retrieve the sslProfile, and writes a log message 'Cannot set SSL credentials' in the log, which makes it a bit hard to understand whats going on. Related to this, if you create a listener before the sslProfile it references, clients will get the same error. Having the router validate the listener sslProfile that is referenced, as well as the sslProfile itself when being created would make it easier to detect errors. -- 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] [Created] (DISPATCH-1646) Unable to delete listener with http enabled
Ulf Lilleengen created DISPATCH-1646: Summary: Unable to delete listener with http enabled Key: DISPATCH-1646 URL: https://issues.apache.org/jira/browse/DISPATCH-1646 Project: Qpid Dispatch Issue Type: Improvement Reporter: Ulf Lilleengen I'm running into an issue when trying to delete a listener which has 'http: true' set. The router returns the error message "HTTP listeners cannot be deleted". I can see that there is a test for this in the router code as well. However, in order for EnMasse to be able to create and delete listeners that are used to handle websocket connections for different tenants, we need a way to delete listeners with http: true set through AMQP management without restarting the router. -- 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] [Updated] (DISPATCH-1585) Allow defining address prefix shared by different multitenant listeners
[ https://issues.apache.org/jira/browse/DISPATCH-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ulf Lilleengen updated DISPATCH-1585: - Summary: Allow defining address prefix shared by different multitenant listeners (was: Allow specifying address/source/target to be used for a multitenant listener) > Allow defining address prefix shared by different multitenant listeners > --- > > Key: DISPATCH-1585 > URL: https://issues.apache.org/jira/browse/DISPATCH-1585 > Project: Qpid Dispatch > Issue Type: Wish >Reporter: Ulf Lilleengen >Priority: Major > > At present, a multitenant router listener will prefix addresses with the > hostname in the AMQP Open. However, given a configuration where it is > desirable to expose a router address space for multiple DNS names, any > address, linkRoute and autoLink configuration will need to be duplicated for > each DNS name. This complicates router configuration significantly. > > Instead, having a way to specify which prefix to apply for a multitenant > listener would allow reusing the same address, autoLink and linkRoute > configuration for multiple listeners. -- 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] [Comment Edited] (DISPATCH-1585) Allow specifying address/source/target to be used for a multitenant listener
[
https://issues.apache.org/jira/browse/DISPATCH-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17072650#comment-17072650
]
Ulf Lilleengen edited comment on DISPATCH-1585 at 4/18/20, 7:05 AM:
[~tross]
Lets say you have a service suporting multiple tenants, but a single tenant can
have applications running in 2 separate networks (but they belong to the same
'tenant', i.e. they have the same addresses), so the client applications
connect to the router via 2 different hosts, lets say internal.example.com and
public.example.com. Today, I would need to model it this way (omitting the
broker connector and simplified some details):
{code:java}
[
["listener", { "host": "0.0.0.0", "port": 56721, "authenticatePeer": false,
"saslMechanisms": "ANONYMOUS", "multiTenant": true }],
["policy", {"enableVhostPolicy": true, "defaultVhost": "$default" }],
["vhost", { "hostname": "internal.example.com", "allowUnknownUser": true,
// ... }],
["address", { "waypoint": true, "prefix": "internal.example.com/foo" }],
["autoLink", { "address": "internal.example.com/foo", "direction": "out",
"connection": "broker", "externalAddress": "t1/foo" }],
["autoLink", { "address": "internal.example.com/foo", "direction": "in",
"connection": "broker", "externalAddress": "t1/foo" }],
["vhost", { "hostname": "public.example.com", "allowUnknownUser": true, //
... }],
["address", { "waypoint": true, "prefix": "public.example.com/foo" }],
["autoLink", { "address": "public.example.com/foo", "direction": "out",
"connection": "broker", "externalAddress": "t1/foo" }],
["autoLink", { "address": "public.example.com/foo", "direction": "in",
"connection": "broker", "externalAddress": "t1/foo" }],
]
{code}
So, for every host to expose for this tenant, a lot of configuration is needed.
There is only one address in this example, but when you have 10k addresses, its
starting to be a lot of work reconfiguring the router just to expose on a new
host.
So, what would be very useful for this case is to have some way to specify a
mapping from virtual host to an internal host that can be used in address
prefixes. I.e
{code:java}
[
["listener", { "host": "0.0.0.0", "port": 56721, "authenticatePeer": false,
"saslMechanisms": "ANONYMOUS", "multiTenant": true }],
["policy", {"enableVhostPolicy": true, "defaultVhost": "$default" }],
// List of hostnames that this vhost should apply to, and a prefix that
hostnames should be replaced with when doing routing.
["vhost", { "hostnames": ["internal.example.com", "public.example.com"],
"internalHost": "tenant1", "allowUnknownUser": true, // ... }],
["address", { "waypoint": true, "prefix": "tenant1/foo" }],
["autoLink", { "address": "tenant1/foo", "direction": "out", "connection":
"broker" }],
["autoLink", { "address": "tenant1/foo", "direction": "in", "connection":
"broker" }],
]{code}
This means the amount of configuration to change would be a lot less if you
have many addresses. There are probably better ways to model this than my
example, but hopefully it shows the reason for raising this issue.
was (Author: lulf):
[~tross]
Lets say you have a service suporting multiple tenants, but a single tenant can
have applications running in 2 separate networks (but they belong to the same
'tenant', i.e. they have the same addresses), so the client applications
connect to the router via 2 different hosts, lets say internal.example.com and
public.example.com. Today, I would need to model it this way (omitting the
broker connector and simplified some details):
{code:java}
[
["listener", { "host": "0.0.0.0", "port": 56721, "authenticatePeer": false,
"saslMechanisms": "ANONYMOUS", "multiTenant": true }],
["policy", {"enableVhostPolicy": true, "defaultVhost": "$default" }],
["vhost", { "hostname": "internal.example.com", "allowUnknownUser": true,
// ... }],
["address", { "waypoint": true, "prefix": "internal.example.com/foo" }],
["autoLink", { "address": "internal.example.com/foo", "direction": "out",
"connection": "broker", "externalAddress": "t1/foo" }],
["autoLink", { "address": "internal.example.com/foo", "direction": "in",
"connection": "broker", "externalAddress": "t1/foo" }],
["vhost", { "hostname": "public.example.com", "allowUnknownUser": true, //
... }],
["address", { "waypoint": true, "prefix": "public.example.com/foo" }],
["autoLink", { "address": "public.example.com/foo", "direction": "out",
"connection": "broker", "externalAddress": "t1/foo" }],
["autoLink", { "address": "public.example.com/foo", "direction": "in",
"connection": "broker", "externalAddress": "t1/foo" }],
]
{code}
So, for every host to expose for this tenant, a lot of configuration is needed.
There is only one address in this example, but when you have 10k addresses, its
starting
[jira] [Commented] (DISPATCH-1585) Allow specifying address/source/target to be used for a multitenant listener
[ https://issues.apache.org/jira/browse/DISPATCH-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17086347#comment-17086347 ] Ulf Lilleengen commented on DISPATCH-1585: -- [~tross] I think I have found another issue related to this. Although my initial example above shows how this can be configured for queues on a broker where you 'map' addresses to the same broker queue, I don't think there is a way to do this for anycast or multicast addresses without something like the proposed config. > Allow specifying address/source/target to be used for a multitenant listener > > > Key: DISPATCH-1585 > URL: https://issues.apache.org/jira/browse/DISPATCH-1585 > Project: Qpid Dispatch > Issue Type: Wish >Reporter: Ulf Lilleengen >Priority: Major > > At present, a multitenant router listener will prefix addresses with the > hostname in the AMQP Open. However, given a configuration where it is > desirable to expose a router address space for multiple DNS names, any > address, linkRoute and autoLink configuration will need to be duplicated for > each DNS name. This complicates router configuration significantly. > > Instead, having a way to specify which prefix to apply for a multitenant > listener would allow reusing the same address, autoLink and linkRoute > configuration for multiple listeners. -- 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] [Comment Edited] (DISPATCH-1585) Allow specifying address/source/target to be used for a multitenant listener
[
https://issues.apache.org/jira/browse/DISPATCH-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17072650#comment-17072650
]
Ulf Lilleengen edited comment on DISPATCH-1585 at 4/18/20, 7:04 AM:
[~tross]
Lets say you have a service suporting multiple tenants, but a single tenant can
have applications running in 2 separate networks (but they belong to the same
'tenant', i.e. they have the same addresses), so the client applications
connect to the router via 2 different hosts, lets say internal.example.com and
public.example.com. Today, I would need to model it this way (omitting the
broker connector and simplified some details):
{code:java}
[
["listener", { "host": "0.0.0.0", "port": 56721, "authenticatePeer": false,
"saslMechanisms": "ANONYMOUS", "multiTenant": true }],
["policy", {"enableVhostPolicy": true, "defaultVhost": "$default" }],
["vhost", { "hostname": "internal.example.com", "allowUnknownUser": true,
// ... }],
["address", { "waypoint": true, "prefix": "internal.example.com/foo" }],
["autoLink", { "address": "internal.example.com/foo", "direction": "out",
"connection": "broker", "externalAddress": "t1/foo" }],
["autoLink", { "address": "internal.example.com/foo", "direction": "in",
"connection": "broker", "externalAddress": "t1/foo" }],
["vhost", { "hostname": "public.example.com", "allowUnknownUser": true, //
... }],
["address", { "waypoint": true, "prefix": "public.example.com/foo" }],
["autoLink", { "address": "public.example.com/foo", "direction": "out",
"connection": "broker", "externalAddress": "t1/foo" }],
["autoLink", { "address": "public.example.com/foo", "direction": "in",
"connection": "broker", "externalAddress": "t1/foo" }],
]
{code}
So, for every host to expose for this tenant, a lot of configuration is needed.
There is only one address in this example, but when you have 10k addresses, its
starting to be a lot of work reconfiguring the router just to expose on a new
host.
So, what would be very useful for this case is to have some way to specify a
mapping from virtual host to an internal host that can be used in address
prefixes. I.e
{code:java}
[
["listener", { "host": "0.0.0.0", "port": 56721, "authenticatePeer": false,
"saslMechanisms": "ANONYMOUS", "multiTenant": true }],
["policy", {"enableVhostPolicy": true, "defaultVhost": "$default" }],
// List of hostnames that this vhost should apply to, and a prefix that
hostnames should be replaced with when doing routing.
["vhost", { "hostnames": ["internal.example.com", "public.example.com"],
"internalHost": "tenant1", "allowUnknownUser": true, // ... }],
["address", { "waypoint": true, "prefix": "tenant1/foo" }],
["autoLink", { "address": "tenant1/foo", "direction": "out", "connection":
"broker", "externalAddress": "t1/foo" }],
["autoLink", { "address": "tenant1/foo", "direction": "in", "connection":
"broker", "externalAddress": "t1/foo" }],
]{code}
This means the amount of configuration to change would be a lot less if you
have many addresses. There are probably better ways to model this than my
example, but hopefully it shows the reason for raising this issue.
was (Author: lulf):
[~tross]
Lets say you have a service suporting multiple tenants, but a single tenant can
have applications running in 2 separate networks (but they belong to the same
'tenant', i.e. they have the same addresses), so the client applications
connect to the router via 2 different hosts, lets say internal.example.com and
public.example.com. Today, I would need to model it this way (omitting the
broker connector and simplified some details):
{code:java}
[
["listener", { "host": "0.0.0.0", "port": 56721, "authenticatePeer": false,
"saslMechanisms": "ANONYMOUS", "multiTenant": true }],
["policy", {"enableVhostPolicy": true, "defaultVhost": "$default" }],
["vhost", { "hostname": "internal.example.com", "allowUnknownUser": true,
// ... }],
["address", { "waypoint": true, "prefix": "internal.example.com/foo" }],
["autoLink", { "address": "internal.example.com/foo", "direction": "out",
"connection": "broker", "externalAddress": "t1/foo" }],
["autoLink", { "address": "internal.example.com/foo", "direction": "in",
"connection": "broker", "externalAddress": "t1/foo" }],
["vhost", { "hostname": "public.example.com", "allowUnknownUser": true, //
... }],
["address", { "waypoint": true, "prefix": "public.example.com/foo" }],
["autoLink", { "address": "public.example.com/foo", "direction": "out",
"connection": "broker", "externalAddress": "t1/foo" }],
["autoLink", { "address": "public.example.com/foo", "direction": "in",
"connection": "broker", "externalAddress": "t1/foo" }],
]
{code}
So, for every host to expose for this tenant, a lot of configuration is needed.
There is only one address in this
[jira] [Comment Edited] (DISPATCH-1585) Allow specifying address/source/target to be used for a multitenant listener
[
https://issues.apache.org/jira/browse/DISPATCH-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17072650#comment-17072650
]
Ulf Lilleengen edited comment on DISPATCH-1585 at 4/18/20, 7:03 AM:
[~tross]
Lets say you have a service suporting multiple tenants, but a single tenant can
have applications running in 2 separate networks (but they belong to the same
'tenant', i.e. they have the same addresses), so the client applications
connect to the router via 2 different hosts, lets say internal.example.com and
public.example.com. Today, I would need to model it this way (omitting the
broker connector and simplified some details):
{code:java}
[
["listener", { "host": "0.0.0.0", "port": 56721, "authenticatePeer": false,
"saslMechanisms": "ANONYMOUS", "multiTenant": true }],
["policy", {"enableVhostPolicy": true, "defaultVhost": "$default" }],
["vhost", { "hostname": "internal.example.com", "allowUnknownUser": true,
// ... }],
["address", { "waypoint": true, "prefix": "internal.example.com/foo" }],
["autoLink", { "address": "internal.example.com/foo", "direction": "out",
"connection": "broker", "externalAddress": "t1/foo" }],
["autoLink", { "address": "internal.example.com/foo", "direction": "in",
"connection": "broker", "externalAddress": "t1/foo" }],
["vhost", { "hostname": "public.example.com", "allowUnknownUser": true, //
... }],
["address", { "waypoint": true, "prefix": "public.example.com/foo" }],
["autoLink", { "address": "public.example.com/foo", "direction": "out",
"connection": "broker", "externalAddress": "t1/foo" }],
["autoLink", { "address": "public.example.com/foo", "direction": "in",
"connection": "broker", "externalAddress": "t1/foo" }],
]
{code}
So, for every host to expose for this tenant, a lot of configuration is needed.
There is only one address in this example, but when you have 10k addresses, its
starting to be a lot of work reconfiguring the router just to expose on a new
host.
So, what would be very useful for this case is to have some way to specify a
mapping from virtual host to the prefix matched for addresses. I.e
{code:java}
[
["listener", { "host": "0.0.0.0", "port": 56721, "authenticatePeer": false,
"saslMechanisms": "ANONYMOUS", "multiTenant": true }],
["policy", {"enableVhostPolicy": true, "defaultVhost": "$default" }],
// List of hostnames that this vhost should apply to, and a prefix that
hostnames should be replaced with when doing routing.
["vhost", { "hostnames": ["internal.example.com", "public.example.com"],
"internalHost": "tenant1", "allowUnknownUser": true, // ... }],
["address", { "waypoint": true, "prefix": "tenant1/foo" }],
["autoLink", { "address": "tenant1/foo", "direction": "out", "connection":
"broker", "externalAddress": "t1/foo" }],
["autoLink", { "address": "tenant1/foo", "direction": "in", "connection":
"broker", "externalAddress": "t1/foo" }],
]{code}
This means the amount of configuration to change would be a lot less if you
have many addresses. There are probably better ways to model this than my
example, but hopefully it shows the reason for raising this issue.
was (Author: lulf):
[~tross]
Lets say you have a service suporting multiple tenants, but a single tenant can
have applications running in 2 separate networks (but they belong to the same
'tenant', i.e. they have the same addresses), so the client applications
connect to the router via 2 different hosts, lets say internal.example.com and
public.example.com. Today, I would need to model it this way (omitting the
broker connector and simplified some details):
{code:java}
[
["listener", { "host": "0.0.0.0", "port": 56721, "authenticatePeer": false,
"saslMechanisms": "ANONYMOUS", "multiTenant": true }],
["policy", {"enableVhostPolicy": true, "defaultVhost": "$default" }],
["vhost", { "hostname": "internal.example.com", "allowUnknownUser": true,
// ... }],
["address", { "waypoint": true, "prefix": "internal.example.com/foo" }],
["autoLink", { "address": "internal.example.com/foo", "direction": "out",
"connection": "broker", "externalAddress": "t1/foo" }],
["autoLink", { "address": "internal.example.com/foo", "direction": "in",
"connection": "broker", "externalAddress": "t1/foo" }],
["vhost", { "hostname": "public.example.com", "allowUnknownUser": true, //
... }],
["address", { "waypoint": true, "prefix": "public.example.com/foo" }],
["autoLink", { "address": "public.example.com/foo", "direction": "out",
"connection": "broker", "externalAddress": "t1/foo" }],
["autoLink", { "address": "public.example.com/foo", "direction": "in",
"connection": "broker", "externalAddress": "t1/foo" }],
]
{code}
So, for every host to expose for this tenant, a lot of configuration is needed.
There is only one address in this example, but when you
[jira] [Comment Edited] (DISPATCH-1585) Allow specifying address/source/target to be used for a multitenant listener
[
https://issues.apache.org/jira/browse/DISPATCH-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17072650#comment-17072650
]
Ulf Lilleengen edited comment on DISPATCH-1585 at 4/1/20, 11:04 AM:
[~tross]
Lets say you have a service suporting multiple tenants, but a single tenant can
have applications running in 2 separate networks (but they belong to the same
'tenant', i.e. they have the same addresses), so the client applications
connect to the router via 2 different hosts, lets say internal.example.com and
public.example.com. Today, I would need to model it this way (omitting the
broker connector and simplified some details):
{code:java}
[
["listener", { "host": "0.0.0.0", "port": 56721, "authenticatePeer": false,
"saslMechanisms": "ANONYMOUS", "multiTenant": true }],
["policy", {"enableVhostPolicy": true, "defaultVhost": "$default" }],
["vhost", { "hostname": "internal.example.com", "allowUnknownUser": true,
// ... }],
["address", { "waypoint": true, "prefix": "internal.example.com/foo" }],
["autoLink", { "address": "internal.example.com/foo", "direction": "out",
"connection": "broker", "externalAddress": "t1/foo" }],
["autoLink", { "address": "internal.example.com/foo", "direction": "in",
"connection": "broker", "externalAddress": "t1/foo" }],
["vhost", { "hostname": "public.example.com", "allowUnknownUser": true, //
... }],
["address", { "waypoint": true, "prefix": "public.example.com/foo" }],
["autoLink", { "address": "public.example.com/foo", "direction": "out",
"connection": "broker", "externalAddress": "t1/foo" }],
["autoLink", { "address": "public.example.com/foo", "direction": "in",
"connection": "broker", "externalAddress": "t1/foo" }],
]
{code}
So, for every host to expose for this tenant, a lot of configuration is needed.
There is only one address in this example, but when you have 10k addresses, its
starting to be a lot of work reconfiguring the router just to expose on a new
host.
So, what would be very useful for this case is to have some way to specify a
mapping from virtual host to the prefix matched for addresses. I.e
{code:java}
[
["listener", { "host": "0.0.0.0", "port": 56721, "authenticatePeer": false,
"saslMechanisms": "ANONYMOUS", "multiTenant": true }],
["policy", {"enableVhostPolicy": true, "defaultVhost": "$default" }],
// List of hostnames that this vhost should apply to, and a prefix that
hostnames should be replaced with when doing routing.
["vhost", { "hostnames": ["internal.example.com", "public.example.com"],
"prefix": "tenant1", "allowUnknownUser": true, // ... }],
["address", { "waypoint": true, "prefix": "tenant1/foo" }],
["autoLink", { "address": "tenant1/foo", "direction": "out", "connection":
"broker", "externalAddress": "t1/foo" }],
["autoLink", { "address": "tenant1/foo", "direction": "in", "connection":
"broker", "externalAddress": "t1/foo" }],
]{code}
This means the amount of configuration to change would be a lot less if you
have many addresses. There are probably better ways to model this than my
example, but hopefully it shows the reason for raising this issue.
was (Author: lulf):
Lets say you have a service suporting multiple tenants, but a single tenant can
have applications running in 2 separate networks (but they belong to the same
'tenant', i.e. they have the same addresses), so the client applications
connect to the router via 2 different hosts, lets say internal.example.com and
public.example.com. Today, I would need to model it this way (omitting the
broker connector and unneeded details):
{code:java}
[
["listener", { "host": "0.0.0.0", "port": 56721, "authenticatePeer": false,
"saslMechanisms": "ANONYMOUS", "multiTenant": true }],
["policy", {"enableVhostPolicy": true, "defaultVhost": "$default" }],
["vhost", { "hostname": "internal.example.com", "allowUnknownUser": true,
// ... }],
["address", { "waypoint": true, "prefix": "internal.example.com/foo" }],
["autoLink", { "address": "internal.example.com/foo", "direction": "out",
"connection": "broker", "externalAddress": "t1/foo" }],
["autoLink", { "address": "internal.example.com/foo", "direction": "in",
"connection": "broker", "externalAddress": "t1/foo" }],
["vhost", { "hostname": "public.example.com", "allowUnknownUser": true, //
... }],
["address", { "waypoint": true, "prefix": "public.example.com/foo" }],
["autoLink", { "address": "public.example.com/foo", "direction": "out",
"connection": "broker", "externalAddress": "t1/foo" }],
["autoLink", { "address": "public.example.com/foo", "direction": "in",
"connection": "broker", "externalAddress": "t1/foo" }],
]
{code}
So, for every host to expose for this tenant, a lot of configuration is needed.
There is only one address in this example, but when you have 10k addresses,
[jira] [Commented] (DISPATCH-1585) Allow specifying address/source/target to be used for a multitenant listener
[
https://issues.apache.org/jira/browse/DISPATCH-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17072650#comment-17072650
]
Ulf Lilleengen commented on DISPATCH-1585:
--
Lets say you have a service suporting multiple tenants, but a single tenant can
have applications running in 2 separate networks (but they belong to the same
'tenant', i.e. they have the same addresses), so the client applications
connect to the router via 2 different hosts, lets say internal.example.com and
public.example.com. Today, I would need to model it this way (omitting the
broker connector and unneeded details):
{code:java}
[
["listener", { "host": "0.0.0.0", "port": 56721, "authenticatePeer": false,
"saslMechanisms": "ANONYMOUS", "multiTenant": true }],
["policy", {"enableVhostPolicy": true, "defaultVhost": "$default" }],
["vhost", { "hostname": "internal.example.com", "allowUnknownUser": true,
// ... }],
["address", { "waypoint": true, "prefix": "internal.example.com/foo" }],
["autoLink", { "address": "internal.example.com/foo", "direction": "out",
"connection": "broker", "externalAddress": "t1/foo" }],
["autoLink", { "address": "internal.example.com/foo", "direction": "in",
"connection": "broker", "externalAddress": "t1/foo" }],
["vhost", { "hostname": "public.example.com", "allowUnknownUser": true, //
... }],
["address", { "waypoint": true, "prefix": "public.example.com/foo" }],
["autoLink", { "address": "public.example.com/foo", "direction": "out",
"connection": "broker", "externalAddress": "t1/foo" }],
["autoLink", { "address": "public.example.com/foo", "direction": "in",
"connection": "broker", "externalAddress": "t1/foo" }],
]
{code}
So, for every host to expose for this tenant, a lot of configuration is needed.
There is only one address in this example, but when you have 10k addresses, its
starting to be a lot of work reconfiguring the router just to expose on a new
host.
So, what would be very useful for this case is to have some way to specify a
mapping from virtual host to the prefix matched for addresses. I.e
{code:java}
[
["listener", { "host": "0.0.0.0", "port": 56721, "authenticatePeer": false,
"saslMechanisms": "ANONYMOUS", "multiTenant": true }],
["policy", {"enableVhostPolicy": true, "defaultVhost": "$default" }],
// List of hostnames that this vhost should apply to, and a prefix that
hostnames should be replaced with when doing routing.
["vhost", { "hostnames": ["internal.example.com", "public.example.com"],
"prefix": "tenant1", "allowUnknownUser": true, // ... }],
["address", { "waypoint": true, "prefix": "tenant1/foo" }],
["autoLink", { "address": "tenant1/foo", "direction": "out", "connection":
"broker", "externalAddress": "t1/foo" }],
["autoLink", { "address": "tenant1/foo", "direction": "in", "connection":
"broker", "externalAddress": "t1/foo" }],
]{code}
This means the amount of configuration to change would be a lot less if you
have many addresses. There are probably better ways to model this than my
example, but hopefully it shows the reason for raising this issue.
> Allow specifying address/source/target to be used for a multitenant listener
>
>
> Key: DISPATCH-1585
> URL: https://issues.apache.org/jira/browse/DISPATCH-1585
> Project: Qpid Dispatch
> Issue Type: Wish
>Reporter: Ulf Lilleengen
>Priority: Major
>
> At present, a multitenant router listener will prefix addresses with the
> hostname in the AMQP Open. However, given a configuration where it is
> desirable to expose a router address space for multiple DNS names, any
> address, linkRoute and autoLink configuration will need to be duplicated for
> each DNS name. This complicates router configuration significantly.
>
> Instead, having a way to specify which prefix to apply for a multitenant
> listener would allow reusing the same address, autoLink and linkRoute
> configuration for multiple listeners.
--
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] [Updated] (DISPATCH-1585) Allow specifying address/source/target to be used for a multitenant listener
[ https://issues.apache.org/jira/browse/DISPATCH-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ulf Lilleengen updated DISPATCH-1585: - Summary: Allow specifying address/source/target to be used for a multitenant listener (was: Allow specifying address/source/target to be used for a vhost) > Allow specifying address/source/target to be used for a multitenant listener > > > Key: DISPATCH-1585 > URL: https://issues.apache.org/jira/browse/DISPATCH-1585 > Project: Qpid Dispatch > Issue Type: Wish >Reporter: Ulf Lilleengen >Priority: Major > > At present, a multitenant router listener will prefix addresses with the > hostname in the AMQP Open. However, given a configuration where it is > desirable to expose a router address space for multiple DNS names, any > address, linkRoute and autoLink configuration will need to be duplicated for > each DNS name. This complicates router configuration significantly. > > Instead, having a way to specify which prefix to apply for a multitenant > listener would allow reusing the same address, autoLink and linkRoute > configuration for multiple listeners. -- 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] [Created] (DISPATCH-1585) Allow specifying address/source/target to be used for a vhost
Ulf Lilleengen created DISPATCH-1585: Summary: Allow specifying address/source/target to be used for a vhost Key: DISPATCH-1585 URL: https://issues.apache.org/jira/browse/DISPATCH-1585 Project: Qpid Dispatch Issue Type: Wish Reporter: Ulf Lilleengen At present, a multitenant router listener will prefix addresses with the hostname in the AMQP Open. However, given a configuration where it is desirable to expose a router address space for multiple DNS names, any address, linkRoute and autoLink configuration will need to be duplicated for each DNS name. This complicates router configuration significantly. Instead, having a way to specify which prefix to apply for a multitenant listener would allow reusing the same address, autoLink and linkRoute configuration for multiple listeners. -- 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] [Created] (DISPATCH-1573) Connector status is not updated if disconnected
Ulf Lilleengen created DISPATCH-1573: Summary: Connector status is not updated if disconnected Key: DISPATCH-1573 URL: https://issues.apache.org/jira/browse/DISPATCH-1573 Project: Qpid Dispatch Issue Type: Bug Affects Versions: 1.10.0 Reporter: Ulf Lilleengen The connectionStatus field on connectors (added in https://issues.apache.org/jira/browse/DISPATCH-1419 ) does not reflect disconnection of the remote host. If the remote host is disconnected, the connectionMsg field is updated with some information about the disconnection event, but the connectionStatus is still 'SUCCESS'. This affects the upstream -- 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-1439) Expose create time/last transfer time through the Connection management entity
[ https://issues.apache.org/jira/browse/DISPATCH-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16962098#comment-16962098 ] Ulf Lilleengen commented on DISPATCH-1439: -- [~kwall] seconds since is probably enough, as thats what we want to compute for alerts anyway I think. > Expose create time/last transfer time through the Connection management entity > -- > > Key: DISPATCH-1439 > URL: https://issues.apache.org/jira/browse/DISPATCH-1439 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Keith Wall >Priority: Major > > Having these two additional attributes: > * connection create time > * connection last transfer time > would aid fault finding activities. > It would also serve as useful input to external tooling wishing to say, > balance connections to a router network. -- 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] (PROTON-2105) Support Go modules
[
https://issues.apache.org/jira/browse/PROTON-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942683#comment-16942683
]
Ulf Lilleengen commented on PROTON-2105:
[~rkieley] thanks for looking at this. I'm thinking the problem with using
github.com in the module URL is that this has not been the authorative module
name in the past, so changing that I'm not sure is something we should do (i'm
a bit confused after reading go/src/qpid.apache.org/readme-go-get.md).
After your first comment, I thought how it should be is that the following file
should go into the go/src/qpid.apache.org folder:
{code:java}
module qpid.apache.org
go 1.13{code}
However, I don't see a way to properly test this without actually publishing
the go module, because with go modules you're not supposed to use $GOPATH to
look up dependencies, but I'm not sure how one can test it locally then. Maybe
[~aconway] can shed some light on how the go artifacts are published?
> Support Go modules
> --
>
> Key: PROTON-2105
> URL: https://issues.apache.org/jira/browse/PROTON-2105
> Project: Qpid Proton
> Issue Type: Bug
> Components: go-binding
>Reporter: Ulf Lilleengen
>Assignee: Roddie Kieley
>Priority: Major
>
> As of Go 1.12, go module support is available. In order to manage
> dependencies using go modules, dependencies must also be using go modules.
> Therefore, adding a go.mod file to each module would allow qpid proton go
> bindings to be managed as a go module.
--
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] [Created] (DISPATCH-1432) Support adding reconnect timeout for connectors
Ulf Lilleengen created DISPATCH-1432: Summary: Support adding reconnect timeout for connectors Key: DISPATCH-1432 URL: https://issues.apache.org/jira/browse/DISPATCH-1432 Project: Qpid Dispatch Issue Type: Wish Reporter: Ulf Lilleengen At present there seems to be a hard-coded timeout of ~2 minutes if the router cannot make a connector TCP connection to a remote endpoint. Making this configurable would be useful in situations where the starting order of components cannot be controlled and shorten the system startup time signlficantly. -- 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] [Updated] (PROTON-2106) Make link properties available in Go
[ https://issues.apache.org/jira/browse/PROTON-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ulf Lilleengen updated PROTON-2106: --- Description: It is currently not possible to set link properties using the go client. I couldn't even find them settable in the C api, so I guess it would be more than just exposing them via the wrapper. (was: It is currently not possible to set link properties using the go client. I couldn't even find them settable in the C api, so I guess it would be more than just exposing the interface.) > Make link properties available in Go > > > Key: PROTON-2106 > URL: https://issues.apache.org/jira/browse/PROTON-2106 > Project: Qpid Proton > Issue Type: Wish > Components: go-binding >Reporter: Ulf Lilleengen >Assignee: Alan Conway >Priority: Major > > It is currently not possible to set link properties using the go client. I > couldn't even find them settable in the C api, so I guess it would be more > than just exposing them via the wrapper. -- 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] [Updated] (PROTON-2106) Make link properties available in Go
[ https://issues.apache.org/jira/browse/PROTON-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ulf Lilleengen updated PROTON-2106: --- Description: It is currently not possible to set link properties using the go client. I couldn't even find them settable in the C api, so I guess it would be more than just exposing the interface. (was: It is currently not possible to set link properties using the go client.) > Make link properties available in Go > > > Key: PROTON-2106 > URL: https://issues.apache.org/jira/browse/PROTON-2106 > Project: Qpid Proton > Issue Type: Wish > Components: go-binding >Reporter: Ulf Lilleengen >Assignee: Alan Conway >Priority: Major > > It is currently not possible to set link properties using the go client. I > couldn't even find them settable in the C api, so I guess it would be more > than just exposing the interface. -- 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] [Updated] (PROTON-2105) Support Go modules
[ https://issues.apache.org/jira/browse/PROTON-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ulf Lilleengen updated PROTON-2105: --- Component/s: go-binding > Support Go modules > -- > > Key: PROTON-2105 > URL: https://issues.apache.org/jira/browse/PROTON-2105 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Reporter: Ulf Lilleengen >Priority: Major > > As of Go 1.12, go module support is available. In order to manage > dependencies using go modules, dependencies must also be using go modules. > Therefore, adding a go.mod file to each module would allow qpid proton go > bindings to be managed as a go module. -- 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] [Created] (PROTON-2106) Make link properties available in Go
Ulf Lilleengen created PROTON-2106: -- Summary: Make link properties available in Go Key: PROTON-2106 URL: https://issues.apache.org/jira/browse/PROTON-2106 Project: Qpid Proton Issue Type: Wish Components: go-binding Reporter: Ulf Lilleengen Assignee: Alan Conway It is currently not possible to set link properties using the go client. -- 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] [Created] (PROTON-2105) Support Go modules
Ulf Lilleengen created PROTON-2105: -- Summary: Support Go modules Key: PROTON-2105 URL: https://issues.apache.org/jira/browse/PROTON-2105 Project: Qpid Proton Issue Type: Bug Reporter: Ulf Lilleengen As of Go 1.12, go module support is available. In order to manage dependencies using go modules, dependencies must also be using go modules. Therefore, adding a go.mod file to each module would allow qpid proton go bindings to be managed as a go module. -- 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] [Updated] (DISPATCH-1429) Autolink with address starting with double underscores gets converted to single underscore
[
https://issues.apache.org/jira/browse/DISPATCH-1429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ulf Lilleengen updated DISPATCH-1429:
-
Summary: Autolink with address starting with double underscores gets
converted to single underscore (was: Creating autolink with address starting
with double underscores gets converted to single underscore)
> Autolink with address starting with double underscores gets converted to
> single underscore
> --
>
> Key: DISPATCH-1429
> URL: https://issues.apache.org/jira/browse/DISPATCH-1429
> Project: Qpid Dispatch
> Issue Type: Bug
>Reporter: Ulf Lilleengen
>Priority: Major
>
> I have the following in qdrouterd.conf:
>
> {code:java}
> address {
> prefix: __myqueue
> waypoint: true
> }
> autoLink {
> address: __myqueue
> direction: in
> containerId: c2
> }{code}
>
> Running the following command shows that address field gets converted from
> '__myqueue' to '_myqueue':
> {code:java}
> [lulf@pteppic ~]$ qdmanage QUERY --type=autoLink
> [
> {
> "name": "autoLink/0",
> "identity": "3",
> "type": "org.apache.qpid.dispatch.router.config.autoLink",
> "address": "_myqueue",
> "addr": "_myqueue",
> "direction": "in",
> "dir": "in",
> "phase": 1,
> "containerId": "c2",
> "operStatus": "inactive",
> "fallback": false
> }
> ]{code}
>
>
--
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] [Created] (DISPATCH-1429) Creating autolink with address starting with double underscores gets converted to single underscore
Ulf Lilleengen created DISPATCH-1429:
Summary: Creating autolink with address starting with double
underscores gets converted to single underscore
Key: DISPATCH-1429
URL: https://issues.apache.org/jira/browse/DISPATCH-1429
Project: Qpid Dispatch
Issue Type: Bug
Reporter: Ulf Lilleengen
I have the following in qdrouterd.conf:
{code:java}
address {
prefix: __myqueue
waypoint: true
}
autoLink {
address: __myqueue
direction: in
containerId: c2
}{code}
Running the following command shows that address field gets converted from
'__myqueue' to '_myqueue':
{code:java}
[lulf@pteppic ~]$ qdmanage QUERY --type=autoLink
[
{
"name": "autoLink/0",
"identity": "3",
"type": "org.apache.qpid.dispatch.router.config.autoLink",
"address": "_myqueue",
"addr": "_myqueue",
"direction": "in",
"dir": "in",
"phase": 1,
"containerId": "c2",
"operStatus": "inactive",
"fallback": false
}
]{code}
--
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-1421) Attaching link to unavailable address sets source address to null in attach reply
[
https://issues.apache.org/jira/browse/DISPATCH-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16932145#comment-16932145
]
Ulf Lilleengen commented on DISPATCH-1421:
--
[~ganeshmurthy] for EnMasse, the consequence is that ActiveMQ Artemis does not
handle this situation well and will cause spurious log errors. See
https://issues.apache.org/jira/browse/ARTEMIS-2488 for more details on that.
There is a proposed PR to fix the Artemis handling, but it seemed like a
strange behavior on the router side also.
> Attaching link to unavailable address sets source address to null in attach
> reply
> -
>
> Key: DISPATCH-1421
> URL: https://issues.apache.org/jira/browse/DISPATCH-1421
> Project: Qpid Dispatch
> Issue Type: Bug
>Reporter: Ulf Lilleengen
>Priority: Major
>
> An AMQP client attaches to an address with source address set to 'bar' and
> target address 'remote/foo1' (which the router does not know about):
>
> {code:java}
> [425203913:0] -> Attach{name='space2.bar.fwd2.out', handle=0, role=SENDER,
> sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='bar',
> durable=UNSETTLED_STATE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> dynamicNodeProperties=null, distributionMode=null, filter=null,
> defaultOutcome=null, outcomes=null, capabilities=null},
> target=Target{address='remote1/foo1', durable=NONE, expiryPolicy=SESSION_END,
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
> properties=null} {code}
>
> As the router does not know about 'remote/foo1', it sets target=null, but
> also source address to 'null' (this is actually null, not the string 'null',
> proton-j is doing the formatting):
> {code:java}
> [425203913:0] <- Attach{name='space2.bar.fwd2.out', handle=0, role=RECEIVER,
> sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='null',
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> dynamicNodeProperties=null, distributionMode=null, filter=null,
> defaultOutcome=null, outcomes=null, capabilities=null}, target=null,
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> [425203913:0] <- Detach{handle=0, closed=true,
> error=Error{condition=qd:no-route-to-dest, description='No route to the
> destination node', info=null}} {code}
>
> This can be handled in client code, but the question is if the router should
> keep address='bar' in the replied attach or not.
>
> Possibly related: https://issues.apache.org/jira/browse/DISPATCH-962 (CC
> [~robbie])
--
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] [Updated] (DISPATCH-1421) Attaching link to unavailable address sets source address to null in attach reply
[
https://issues.apache.org/jira/browse/DISPATCH-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ulf Lilleengen updated DISPATCH-1421:
-
Description:
An AMQP client attaches to an address with source address set to 'bar' and
target address 'remote/foo1' (which the router does not know about):
{code:java}
[425203913:0] -> Attach{name='space2.bar.fwd2.out', handle=0, role=SENDER,
sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='bar',
durable=UNSETTLED_STATE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=null, capabilities=null},
target=Target{address='remote1/foo1', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
properties=null} {code}
As the router does not know about 'remote/foo1', it sets target=null, but also
source address to 'null' (this is actually null, not the string 'null',
proton-j is doing the formatting):
{code:java}
[425203913:0] <- Attach{name='space2.bar.fwd2.out', handle=0, role=RECEIVER,
sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='null',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=null, capabilities=null}, target=null,
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null,
properties=null}
[425203913:0] <- Detach{handle=0, closed=true,
error=Error{condition=qd:no-route-to-dest, description='No route to the
destination node', info=null}} {code}
This can be handled in client code, but the question is if the router should
keep address='bar' in the replied attach or not.
Possibly related: https://issues.apache.org/jira/browse/DISPATCH-962 (CC
[~robbie])
was:
An AMQP client attaches to an address with source address set to 'bar':
{code:java}
[425203913:0] -> Attach{name='space2.bar.fwd2.out', handle=0, role=SENDER,
sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='bar',
durable=UNSETTLED_STATE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=null, capabilities=null},
target=Target{address='remote1/foo1', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
properties=null} {code}
As the router does not know about 'bar', it sets source address to 'null' (this
is actually null, not the string 'null', proton-j is doing the formatting):
{code:java}
[425203913:0] <- Attach{name='space2.bar.fwd2.out', handle=0, role=RECEIVER,
sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='null',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=null, capabilities=null}, target=null,
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null,
properties=null}
[425203913:0] <- Detach{handle=0, closed=true,
error=Error{condition=qd:no-route-to-dest, description='No route to the
destination node', info=null}} {code}
This can be handled in client code, but the question is if the router should
keep address='bar' in the replied attach or not.
Possibly related: https://issues.apache.org/jira/browse/DISPATCH-962 (CC
[~robbie])
> Attaching link to unavailable address sets source address to null in attach
> reply
> -
>
> Key: DISPATCH-1421
> URL: https://issues.apache.org/jira/browse/DISPATCH-1421
> Project: Qpid Dispatch
> Issue Type: Bug
>Reporter: Ulf Lilleengen
>Priority: Major
>
> An AMQP client attaches to an address with source address set to 'bar' and
> target address 'remote/foo1' (which the router does not know about):
>
> {code:java}
> [425203913:0] -> Attach{name='space2.bar.fwd2.out', handle=0, role=SENDER,
> sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='bar',
> durable=UNSETTLED_STATE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> dynamicNodeProperties=null, distributionMode=null, filter=null,
> defaultOutcome=null, outcomes=null, capabilities=null},
> target=Target{address='remote1/foo1', durable=NONE, expiryPolicy=SESSION_END,
>
[jira] [Created] (DISPATCH-1421) Attaching link to unavailable address sets source address to null in attach reply
Ulf Lilleengen created DISPATCH-1421:
Summary: Attaching link to unavailable address sets source address
to null in attach reply
Key: DISPATCH-1421
URL: https://issues.apache.org/jira/browse/DISPATCH-1421
Project: Qpid Dispatch
Issue Type: Bug
Reporter: Ulf Lilleengen
An AMQP client attaches to an address with source address set to 'bar':
{code:java}
[425203913:0] -> Attach{name='space2.bar.fwd2.out', handle=0, role=SENDER,
sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='bar',
durable=UNSETTLED_STATE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=null, capabilities=null},
target=Target{address='remote1/foo1', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
properties=null} {code}
As the router does not know about 'bar', it sets source address to 'null' (this
is actually null, not the string 'null', proton-j is doing the formatting):
{code:java}
[425203913:0] <- Attach{name='space2.bar.fwd2.out', handle=0, role=RECEIVER,
sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='null',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=null, capabilities=null}, target=null,
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null,
properties=null}
[425203913:0] <- Detach{handle=0, closed=true,
error=Error{condition=qd:no-route-to-dest, description='No route to the
destination node', info=null}} {code}
This can be handled in client code, but the question is if the router should
keep address='bar' in the replied attach or not.
Possibly related: https://issues.apache.org/jira/browse/DISPATCH-962 (CC
[~robbie])
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1420) Support server side filtering of entities
Ulf Lilleengen created DISPATCH-1420: Summary: Support server side filtering of entities Key: DISPATCH-1420 URL: https://issues.apache.org/jira/browse/DISPATCH-1420 Project: Qpid Dispatch Issue Type: Improvement Reporter: Ulf Lilleengen In order to inspect a specific connection or a specific link on a connection, one has to query all connections and all links and do the filtering client side. For deployments with a lot of entities, this consumes an unnecessary amount of bandwith as well as complexity for clients. This load could be reduced if the router management had the capability to specify filters along with the query, and the ability to do the filtering in the router before returning the result. Depending on the underlying datastructure, it could be possible to query more efficiently doing lookup by id for instance. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2037) [PATCH] IndexOutOfBoundException when decoding message using multiple buffers
[ https://issues.apache.org/jira/browse/PROTON-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ulf Lilleengen updated PROTON-2037: --- Description: It is possible to trigger an IndexOutOfBoundException when using the CompositeReadableBuffer and invoking some decode methods at array boundaries. Patch: https://github.com/apache/qpid-proton-j/pull/32 was:It is possible to trigger an IndexOutOfBoundException when using the CompositeReadableBuffer and invoking some decode methods at array boundaries. > [PATCH] IndexOutOfBoundException when decoding message using multiple buffers > - > > Key: PROTON-2037 > URL: https://issues.apache.org/jira/browse/PROTON-2037 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: proton-j-0.32.0 >Reporter: Ulf Lilleengen >Priority: Major > > It is possible to trigger an IndexOutOfBoundException when using the > CompositeReadableBuffer and invoking some decode methods at array boundaries. > > Patch: https://github.com/apache/qpid-proton-j/pull/32 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2037) [PATCH] IndexOutOfBoundException when decoding message using multiple buffers
Ulf Lilleengen created PROTON-2037: -- Summary: [PATCH] IndexOutOfBoundException when decoding message using multiple buffers Key: PROTON-2037 URL: https://issues.apache.org/jira/browse/PROTON-2037 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: proton-j-0.32.0 Reporter: Ulf Lilleengen It is possible to trigger an IndexOutOfBoundException when using the CompositeReadableBuffer and invoking some decode methods at array boundaries. -- 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-1122) Authenticated username not printed
[
https://issues.apache.org/jira/browse/DISPATCH-1122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ulf Lilleengen updated DISPATCH-1122:
-
Flags: Patch
PR https://github.com/apache/qpid-dispatch/pull/379
> Authenticated username not printed
> --
>
> Key: DISPATCH-1122
> URL: https://issues.apache.org/jira/browse/DISPATCH-1122
> Project: Qpid Dispatch
> Issue Type: Bug
>Reporter: Ulf Lilleengen
>Priority: Major
>
> When using the remote authentication service, the username that was
> authenticated is not printed due to a incorrect format string.
>
> Currently the output is:
>
> {{2018-09-17 00:08:32.899183 + AUTHSERVICE (info) authenticated as }}
>
> without the username added.
--
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-1122) Authenticated username not printed
Ulf Lilleengen created DISPATCH-1122:
Summary: Authenticated username not printed
Key: DISPATCH-1122
URL: https://issues.apache.org/jira/browse/DISPATCH-1122
Project: Qpid Dispatch
Issue Type: Bug
Reporter: Ulf Lilleengen
When using the remote authentication service, the username that was
authenticated is not printed due to a incorrect format string.
Currently the output is:
{{2018-09-17 00:08:32.899183 + AUTHSERVICE (info) authenticated as }}
without the username added.
--
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-1028) requireSsl:true not working for http listeners
Ulf Lilleengen created DISPATCH-1028:
Summary: requireSsl:true not working for http listeners
Key: DISPATCH-1028
URL: https://issues.apache.org/jira/browse/DISPATCH-1028
Project: Qpid Dispatch
Issue Type: Bug
Reporter: Ulf Lilleengen
With the following router config, a client will be rejected even if it is
connecting using TLS. The wireshark trace indicates that the TLS handshake
completes successfully, but the router closes the connection and prints in the
log 'amqp:connection:policy-error Client connection unencrypted - forbidden'.
If i set requireSsl: false , the client is able to connect both with and
without TLS.
{code:java}
router {
mode: standalone
id: Router.A
}
sslProfile {
name: ssl_details
certFile: /etc/qpid-dispatch/tls.crt
privateKeyFile: /etc/qpid-dispatch/tls.key
}
listener {
host: 127.0.0.1
port: 8443
http: true
sslProfile: ssl_details
requireSsl: true
}
address {
prefix: q1
}
{code}
Example client:
{code:java}
sudo npm install -g cli-rhea
cli-rhea-sender --broker 127.0.0.1:8443 --address q1 --count 1
--conn-web-socket true --conn-ws-protocols binary --log-lib TRANSPORT_FRM{code}
--
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-936) Configure sender/receiver count limits per address
Ulf Lilleengen created DISPATCH-936: --- Summary: Configure sender/receiver count limits per address Key: DISPATCH-936 URL: https://issues.apache.org/jira/browse/DISPATCH-936 Project: Qpid Dispatch Issue Type: Wish Reporter: Ulf Lilleengen At present, it seems sender and receiver limits can be set per connection. It would be very useful to be able to set this per address. That way, it would be possible to associate a cost/quota with a given address and ensure that it is enforced by the router. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-935) Configuring the dispatch with lots of addresses and autolinks cause a long startup time
Ulf Lilleengen created DISPATCH-935:
---
Summary: Configuring the dispatch with lots of addresses and
autolinks cause a long startup time
Key: DISPATCH-935
URL: https://issues.apache.org/jira/browse/DISPATCH-935
Project: Qpid Dispatch
Issue Type: Bug
Affects Versions: 1.0.0
Reporter: Ulf Lilleengen
I made a simple script to generate a router config with a lot of addresses:
{code:java}
#!/bin/bash
cat< router.conf
router {
mode: standalone
id: Router.A
defaultDistribution: balanced
}
listener {
name: main
host: 127.0.0.1
port: 5672
authenticatePeer: no
}
EOF
for i in `seq 1 5000`
do
echo "address {" >> router.conf
echo " prefix: addr$i" >> router.conf
echo " waypoint: true" >> router.conf
echo "}" >> router.conf
echo "" >> router.conf
echo "autoLink {" >> router.conf
echo " addr: addr$i" >> router.conf
echo " name: linkIn$i" >> router.conf
echo " dir: in" >> router.conf
echo "}" >> router.conf
echo "" >> router.conf
echo "autoLink {" >> router.conf
echo " addr: addr$i" >> router.conf
echo " name: linkOut$i" >> router.conf
echo " dir: out" >> router.conf
echo "}" >> router.conf
echo "" >> router.conf
done
{code}
Although configuring 5000 addresses statically might not be a normal use case,
it seems to cause the router to spend "forever" reading config and initializing.
Doing a pstack reveals a lot of time spent in reading config:
{code:java}
#0 0x7fd2ef8cdbf9 in lookdict_string () from /lib64/libpython2.7.so.1.0
2018-03-01 13:23:21.379050 +0100 ROUTER_CORE (info) Router Core thread exited
│#1 0x7fd2ef968a26 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
│#2 0x7fd2ef969df9 in PyEval_EvalFrameEx (){code}
And
{code:java}
#0 0x7fd2ef8cdbf9 in lookdict_string () from /lib64/libpython2.7.so.1.0 #1
0x7fd2ef968a26 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0 #2
0x7fd2ef969df9 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0 #3
0x7fd2ef969df9 in PyEval_EvalFrameEx () from
/lib64/libpython2.7.so.1.0{code}
And
{code:java}
#0 0x7ff5cbd0184e in PyObject_RichCompare () from
/lib64/libpython2.7.so.1.0 #1 0x7ff5cbd017ef in PyObject_RichCompareBool ()
from /lib64/libpython2.7.so.1.0 #2 0x7ff5cbd13784 in tuplecontains () from
/lib64/libpython2.7.so.1.0 #3 0x7ff5cbd99cba in PyEval_EvalFrameEx () from
/lib64/libpython2.7.so.1.0 #4 0x7ff5cbd98df9 in PyEval_EvalFrameEx () from
/lib64/libpython2.7.so.1.0 #5 0x7ff5cbd98df9 in PyEval_EvalFrameEx () from
/lib64/libpython2.7.so.1.0{code}
--
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] [Closed] (DISPATCH-853) Print more information about transport handle
[ https://issues.apache.org/jira/browse/DISPATCH-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ulf Lilleengen closed DISPATCH-853. --- Resolution: Won't Fix This is already available by enabling trace in router log config. > Print more information about transport handle > - > > Key: DISPATCH-853 > URL: https://issues.apache.org/jira/browse/DISPATCH-853 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Ulf Lilleengen >Priority: Minor > > When debugging connection issues in EnMasse, we found it very useful to > enable PN_TRACE_FRM on the router to print the frame trace. However, having > multiple connections established at once, it's not clear which connection a > given trace belongs to. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-853) Print more information about transport handle
[ https://issues.apache.org/jira/browse/DISPATCH-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16194330#comment-16194330 ] Ulf Lilleengen commented on DISPATCH-853: - Pull request: https://github.com/apache/qpid-dispatch/pull/207 > Print more information about transport handle > - > > Key: DISPATCH-853 > URL: https://issues.apache.org/jira/browse/DISPATCH-853 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Ulf Lilleengen >Priority: Minor > > When debugging connection issues in EnMasse, we found it very useful to > enable PN_TRACE_FRM on the router to print the frame trace. However, having > multiple connections established at once, it's not clear which connection a > given trace belongs to. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-853) Print more information about transport handle
Ulf Lilleengen created DISPATCH-853: --- Summary: Print more information about transport handle Key: DISPATCH-853 URL: https://issues.apache.org/jira/browse/DISPATCH-853 Project: Qpid Dispatch Issue Type: Improvement Reporter: Ulf Lilleengen Priority: Minor When debugging connection issues in EnMasse, we found it very useful to enable PN_TRACE_FRM on the router to print the frame trace. However, having multiple connections established at once, it's not clear which connection a given trace belongs to. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1555) SASL External and missing initial-response
Ulf Lilleengen created PROTON-1555: -- Summary: SASL External and missing initial-response Key: PROTON-1555 URL: https://issues.apache.org/jira/browse/PROTON-1555 Project: Qpid Proton Issue Type: Bug Reporter: Ulf Lilleengen Attachments: sasl-external-reproducer.tar.gz We're facing an issue where the router or proton seems to require the initial-response in the sasl-init frame to be set. I've attached a reproducer that reproduces the error. It contains a router config which you can start the router with. It also contains a qdmanage.sh script that shows the exchange when using qdmanage. The router log trace looks like this (initial-response is an empty string) 2017-08-25 10:17:21.500716 +0200 SERVER (info) Accepted connection to 0.0.0.0:55671 from 127.0.0.1:53196 [0x7fd630042480]: <- SASL [0x7fd630042480]: -> SASL [0x7fd630042480]:0 -> @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:EXTERNAL]] [0x7fd630042480]:0 <- @sasl-init(65) [mechanism=:EXTERNAL, initial-response=b""] [0x7fd630042480]:0 -> @sasl-outcome(68) [code=0] The error occurs when connecting with a client that doesnt set the initial-response at all. The router log: 2017-08-25 10:16:59.851029 +0200 SERVER (info) Accepted connection to 0.0.0.0:55671 from 127.0.0.1:53192 [0x7fd630014740]: <- SASL [0x7fd630014740]: -> SASL [0x7fd630014740]:0 -> @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:EXTERNAL]] [0x7fd630014740]:0 <- @sasl-init(65) [mechanism=:EXTERNAL] [0x7fd630014740]:0 -> @sasl-challenge(66) [challenge=b""] The rhea client will crash with the following error: events.js:160 throw er; // Unhandled 'error' event ^ TypeError: this.mechanism.step is not a function at SaslClient.on_sasl_challenge (/home/lulf/git/enmasse/enmasse/reproducer/node_modules/rhea/lib/sasl.js:214:35) at c.dispatch (/home/lulf/git/enmasse/enmasse/reproducer/node_modules/rhea/lib/types.js:902:33) at Transport.read (/home/lulf/git/enmasse/enmasse/reproducer/node_modules/rhea/lib/transport.js:95:36) at SaslClient.read (/home/lulf/git/enmasse/enmasse/reproducer/node_modules/rhea/lib/sasl.js:245:31) at Connection.input (/home/lulf/git/enmasse/enmasse/reproducer/node_modules/rhea/lib/connection.js:420:35) at emitOne (events.js:96:13) at TLSSocket.emit (events.js:188:7) at readableAddChunk (_stream_readable.js:176:18) at TLSSocket.Readable.push (_stream_readable.js:134:10) at TLSWrap.onread (net.js:547:20) Rob tells me that the router response is not what you'd expect and that it should handle a sasl init without an initial-response. If we ExternalClient.prototype.start in rhea sasl.js to return an empty string instead of null, the exchange goes well. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-808) Setting defaultDistribution: unavailable blocks qdmanage
Ulf Lilleengen created DISPATCH-808:
---
Summary: Setting defaultDistribution: unavailable blocks qdmanage
Key: DISPATCH-808
URL: https://issues.apache.org/jira/browse/DISPATCH-808
Project: Qpid Dispatch
Issue Type: Bug
Environment:
Reporter: Ulf Lilleengen
Priority: Minor
If I specify defaultDistribution: unavailable in the router {} block, qdmanage
prints
LinkDetached: sender 2dc356e7-d1cc-45d4-b5f2-2c76023a5e52-$management to
$management closed due to: Condition('amqp:not-found', 'Node not found')
If I add
{code}
address {
prefix: $management
}
{code}
to the config, it works. As a default, I would expect that an implicit address
such as '$management' should just work without any extra config even if the
default distribution is unavailable.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-628) [PATCH] Multiple connections per autoLink and linkRoute overwrites connection handle
Ulf Lilleengen created DISPATCH-628: --- Summary: [PATCH] Multiple connections per autoLink and linkRoute overwrites connection handle Key: DISPATCH-628 URL: https://issues.apache.org/jira/browse/DISPATCH-628 Project: Qpid Dispatch Issue Type: Bug Reporter: Ulf Lilleengen When implementing https://github.com/apache/qpid-dispatch/pull/111 I stumbled across an issue with an autoLink or linkRoute only being able to refer to more than 1 connection, which I assumed would originaly cause an assert in route_control.c:350 to trigger when I configured an autoLink to trigger on a containerId and use the same container id when sharding a queue. Since the assert didn't trigger, I assumed that I must have misread the code, but nontheless as part of the patch I made it possible for a linkRoute/autoLink to be associated with multiple connections. Recently, I have seen some router crashes when scaling up and down queues in EnMasse, and I just figured that the reason for this assert not triggering is that it is disabled in the RelWithDebInfo configuration. If built without optimizations (Debug), I'm able to trigger the issue with the configuration in http://people.redhat.com/~ulilleen/bugs/routerconn/ To trigger, I startup the router and broker as so: qdrouterd -c router_incoming.conf export MESSAGING_SERVICE_HOST=localhost export MESSAGING_SERVICE_PORT_INTERNAL=55673 export QUEUE_NAME=myqueue export CONTAINER_ID=myqueue ./br/bin/simplebroker & ./br/bin/simplebroker I have extracted the patch from DISPATCH-476 and will create a PR with it. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-593) Balance traffic across multiple connections between routers
Ulf Lilleengen created DISPATCH-593: --- Summary: Balance traffic across multiple connections between routers Key: DISPATCH-593 URL: https://issues.apache.org/jira/browse/DISPATCH-593 Project: Qpid Dispatch Issue Type: New Feature Reporter: Ulf Lilleengen It is possible to configure multiple inter-router connectors between two routers, but the traffic does not seem to be balanced across them. Being able to scale the number of connections between routers is useful for the router to scale with throughput when a single connection is contended. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-478) Dispatch hung in shutdown due to multiple concurrent signal handlers
[ https://issues.apache.org/jira/browse/DISPATCH-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ulf Lilleengen resolved DISPATCH-478. - Resolution: Fixed Assignee: Ulf Lilleengen Fix Version/s: 0.7.0 > Dispatch hung in shutdown due to multiple concurrent signal handlers > > > Key: DISPATCH-478 > URL: https://issues.apache.org/jira/browse/DISPATCH-478 > Project: Qpid Dispatch > Issue Type: Bug >Reporter: Ulf Lilleengen >Assignee: Ulf Lilleengen >Priority: Minor > Fix For: 0.7.0 > > > When I ran qdrouterd with perf and pressed Ctrl+C, perf would send SIGTERM as > well as SIGINT right after each other to the router. > Scenario: > The first thread would pick up and handle the first signal in > handle_signals_LH(). However, within the function, it unlocks the > qd_server->lock before calling the registered handler. > When it unlocks this lock, some other thread will pick up the second signal > and jump into the qd_server_pause() code, where it will wait indefinitely for > threads to pause (I saw this in GDB, where 1 thread was 'missing', and all > others marked as canceled). The original handler will have canceled the > thread trying to pause all others, but it is not able to jump out. > Patch: https://github.com/apache/qpid-dispatch/pull/95 > This patch ensures that only 1 signal handler can run at a time, which fixes > the issue for me. Note that it will still potentially mask signals while > handling a signal, but the current set of signals (SIGHUP, SIGQUIT, SIGINT, > SIGTERM) either shutdown the router or do nothing. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1355) Allow controlling peer_hostname independently of connection url
Ulf Lilleengen created PROTON-1355: -- Summary: Allow controlling peer_hostname independently of connection url Key: PROTON-1355 URL: https://issues.apache.org/jira/browse/PROTON-1355 Project: Qpid Proton Issue Type: Improvement Components: python-binding Reporter: Ulf Lilleengen Priority: Minor I've made a patch that sets SSL peer_hostname to virtual_host if set, and falls back to the url hostname if not. On 15. nov. 2016 17:38, Alan Conway wrote: > On Mon, 2016-11-14 at 23:51 +, Gordon Sim wrote: >> > On 14/11/16 14:18, Ulf Lilleengen wrote: >>> > > >>> > > I've been playing around with setting Server Name Indication (SNI) >>> > > when using the qpid proton python bindings. >>> > > >>> > > For configuring SSL, it seems to be expected that configuration >>> > > parameters come from a SSLDomain python object, which maps to the >>> > > underlying pn_ssl_domain_t in proton-c. >>> > > >>> > > Today, setting SNI is done through the pn_ssl_t instance using >>> > > 'pn_ssl_set_peer_hostname'. The pn_ssl_t instance does not seem to >>> > > be >>> > > exposed in the end APIs in the same way as pn_ssl_domain_t, at >>> > > least >>> > > not in the python bindings. I tried to work around this in the >>> > > python >>> > > bindings by passing an extra parameter in addition to the >>> > > ssl_domain >>> > > instance on connect(), but it didn't seem like a good approach. >> > >> > There is already a virtual_host keyword argument for connect(). This >> > is >> > used to control the hostname field in the AMQP open frame. That is >> > similar to SNI in TLS. The AMQP spec says: >> > >> > The TLS client peer SHOULD use the server name indication >> > extension as described in RFC-4366 [RFC4366]. >> > >> > If it does so, then it is undefined what happens if this >> > differs from hostname in the sasl-init and open frame >> > frames. >> > >> > So perhaps using the virtual_host, if specified, for the >> > peer_hostname >> > would make sense. (If not specified it could fallback to the hostname >> > in >> > the url). > I think that is what we did with virtual_host a while back, but I am > not sure exactly what was completed and what was discussed. IIRC the > discussion was that AMQP hostname/peer_host should be set to > virtual_host if that is set, or fall-back to the URL hostname if not. > The idea was exactly to avoid the need to muck about with ssl_domains > and whatnot, and set the "virtual" hostname in just one -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-502) Seeing unexpected values in management query response
[
https://issues.apache.org/jira/browse/DISPATCH-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15487830#comment-15487830
]
Ulf Lilleengen commented on DISPATCH-502:
-
Ouch! Great catch [~gsim]!
> Seeing unexpected values in management query response
> -
>
> Key: DISPATCH-502
> URL: https://issues.apache.org/jira/browse/DISPATCH-502
> Project: Qpid Dispatch
> Issue Type: Bug
>Reporter: Ulf Lilleengen
> Attachments: router.log
>
>
> We've been debugging an issue where we are getting some strange results from
> a management query for the router addresses.
> We've been able to capture the offending (we think) frame, maybe you can tell
> whether this is a correct frame or not:
> {noformat}
> [0x7f1cb8025ea0]:0 -> @transfer(20) [handle=1, delivery-id=9,
> delivery-tag=b"\x09\x00\x00\x00\x00\x00\x00\x00", message-format=0,
> settled=true, more=false] (547)
> "\x00Ss\xd0\x00\x00\x00G\x00\x00\x00\x06@@\xa19amqp:/_topo/0/Router.qdrouterd-3ysq1/temp.CKP6RovAXu+Q6mB@@\xa1\x0210\x00St\xd1\x00\x00\x00)\x00\x00\x00\x04\xa1\x11statusDescription\xa1\x02OK\xa1\x0astatusCodeR\xc8\x00Sw\xd1\x00\x00\x01\x9b\x00\x00\x00\x04\xa1\x0eattributeNames\xd0\x00\x00\x00U\x00\x00\x00\x08\xa1\x04name\xa1\x08identity\xa1\x04type\xa1\x06prefix\xa1\x0cdistribution\xa1\x08waypoint\xa1\x0cingressPhase\xa1\x0begressPhase\xa1\x07results\xd0\x00\x00\x01\x1f\x00\x00\x00\x03\xd0\x00\x00\x00X\x00\x00\x00\x08\xa1\x07myqueue\xa1\x013\xa1.org.apache.qpid.dispatch.router.config.address\xa1\x07myqueue\xa1\x08balancedAT\x00T\x01\xd0\x00\x00\x00W\x00\x00\x00\x08\xa1\x06CREATE\xa1\x014\xa1.org.apache.qpid.dispatch.router.config.address\xa1\x07anycast\xa1\x08balancedBT\x00T\x00\xd0\x00\x00\x00]\x00\x00\x00\x08\xa1\x09broadcast\xa1\x015\xa1.org.apache.qpid.dispatch.router.config.address\xa1\x09broadcast\xa1\x09multicastBT\x00T\x00
> {noformat}
> I'll attach the full log. We're working on a reproducer. Right now, we see
> this 1/5 times when deploying the router, so it seems to be a bit timing
> dependent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-502) Seeing unexpected values in management query response
[
https://issues.apache.org/jira/browse/DISPATCH-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ulf Lilleengen updated DISPATCH-502:
Attachment: router.log
200 lines of router log
> Seeing unexpected values in management query response
> -
>
> Key: DISPATCH-502
> URL: https://issues.apache.org/jira/browse/DISPATCH-502
> Project: Qpid Dispatch
> Issue Type: Bug
>Reporter: Ulf Lilleengen
> Attachments: router.log
>
>
> We've been debugging an issue where we are getting some strange results from
> a management query for the router addresses.
> We've been able to capture the offending (we think) frame, maybe you can tell
> whether this is a correct frame or not:
> {noformat}
> [0x7f1cb8025ea0]:0 -> @transfer(20) [handle=1, delivery-id=9,
> delivery-tag=b"\x09\x00\x00\x00\x00\x00\x00\x00", message-format=0,
> settled=true, more=false] (547)
> "\x00Ss\xd0\x00\x00\x00G\x00\x00\x00\x06@@\xa19amqp:/_topo/0/Router.qdrouterd-3ysq1/temp.CKP6RovAXu+Q6mB@@\xa1\x0210\x00St\xd1\x00\x00\x00)\x00\x00\x00\x04\xa1\x11statusDescription\xa1\x02OK\xa1\x0astatusCodeR\xc8\x00Sw\xd1\x00\x00\x01\x9b\x00\x00\x00\x04\xa1\x0eattributeNames\xd0\x00\x00\x00U\x00\x00\x00\x08\xa1\x04name\xa1\x08identity\xa1\x04type\xa1\x06prefix\xa1\x0cdistribution\xa1\x08waypoint\xa1\x0cingressPhase\xa1\x0begressPhase\xa1\x07results\xd0\x00\x00\x01\x1f\x00\x00\x00\x03\xd0\x00\x00\x00X\x00\x00\x00\x08\xa1\x07myqueue\xa1\x013\xa1.org.apache.qpid.dispatch.router.config.address\xa1\x07myqueue\xa1\x08balancedAT\x00T\x01\xd0\x00\x00\x00W\x00\x00\x00\x08\xa1\x06CREATE\xa1\x014\xa1.org.apache.qpid.dispatch.router.config.address\xa1\x07anycast\xa1\x08balancedBT\x00T\x00\xd0\x00\x00\x00]\x00\x00\x00\x08\xa1\x09broadcast\xa1\x015\xa1.org.apache.qpid.dispatch.router.config.address\xa1\x09broadcast\xa1\x09multicastBT\x00T\x00
> {noformat}
> I'll attach the full log. We're working on a reproducer. Right now, we see
> this 1/5 times when deploying the router, so it seems to be a bit timing
> dependent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-502) Seeing unexpected values in management query response
[
https://issues.apache.org/jira/browse/DISPATCH-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ulf Lilleengen updated DISPATCH-502:
Description:
We've been debugging an issue where we are getting some strange results from a
management query for the router addresses.
We've been able to capture the offending (we think) frame, maybe you can tell
whether this is a correct frame or not:
{noformat}
[0x7f1cb8025ea0]:0 -> @transfer(20) [handle=1, delivery-id=9,
delivery-tag=b"\x09\x00\x00\x00\x00\x00\x00\x00", message-format=0,
settled=true, more=false] (547)
"\x00Ss\xd0\x00\x00\x00G\x00\x00\x00\x06@@\xa19amqp:/_topo/0/Router.qdrouterd-3ysq1/temp.CKP6RovAXu+Q6mB@@\xa1\x0210\x00St\xd1\x00\x00\x00)\x00\x00\x00\x04\xa1\x11statusDescription\xa1\x02OK\xa1\x0astatusCodeR\xc8\x00Sw\xd1\x00\x00\x01\x9b\x00\x00\x00\x04\xa1\x0eattributeNames\xd0\x00\x00\x00U\x00\x00\x00\x08\xa1\x04name\xa1\x08identity\xa1\x04type\xa1\x06prefix\xa1\x0cdistribution\xa1\x08waypoint\xa1\x0cingressPhase\xa1\x0begressPhase\xa1\x07results\xd0\x00\x00\x01\x1f\x00\x00\x00\x03\xd0\x00\x00\x00X\x00\x00\x00\x08\xa1\x07myqueue\xa1\x013\xa1.org.apache.qpid.dispatch.router.config.address\xa1\x07myqueue\xa1\x08balancedAT\x00T\x01\xd0\x00\x00\x00W\x00\x00\x00\x08\xa1\x06CREATE\xa1\x014\xa1.org.apache.qpid.dispatch.router.config.address\xa1\x07anycast\xa1\x08balancedBT\x00T\x00\xd0\x00\x00\x00]\x00\x00\x00\x08\xa1\x09broadcast\xa1\x015\xa1.org.apache.qpid.dispatch.router.config.address\xa1\x09broadcast\xa1\x09multicastBT\x00T\x00
{noformat}
I'll attach the full log. We're working on a reproducer. Right now, we see this
1/5 times when deploying the router, so it seems to be a bit timing dependent.
was:
We've been debugging an issue where we are getting some strange results from a
management query for the router addresses.
We've been able to capture the offending (we think) frame, maybe you can tell
whether this is a correct frame or not:
[0x7f1cb8025ea0]:0 -> @transfer(20) [handle=1, delivery-id=9,
delivery-tag=b"\x09\x00\x00\x00\x00\x00\x00\x00", message-format=0,
settled=true, more=false] (547)
"\x00Ss\xd0\x00\x00\x00G\x00\x00\x00\x06@@\xa19amqp:/_topo/0/Router.qdrouterd-3ysq1/temp.CKP6RovAXu+Q6mB@@\xa1\x0210\x00St\xd1\x00\x00\x00)\x00\x00\x00\x04\xa1\x11statusDescription\xa1\x02OK\xa1\x0astatusCodeR\xc8\x00Sw\xd1\x00\x00\x01\x9b\x00\x00\x00\x04\xa1\x0eattributeNames\xd0\x00\x00\x00U\x00\x00\x00\x08\xa1\x04name\xa1\x08identity\xa1\x04type\xa1\x06prefix\xa1\x0cdistribution\xa1\x08waypoint\xa1\x0cingressPhase\xa1\x0begressPhase\xa1\x07results\xd0\x00\x00\x01\x1f\x00\x00\x00\x03\xd0\x00\x00\x00X\x00\x00\x00\x08\xa1\x07myqueue\xa1\x013\xa1.org.apache.qpid.dispatch.router.config.address\xa1\x07myqueue\xa1\x08balancedAT\x00T\x01\xd0\x00\x00\x00W\x00\x00\x00\x08\xa1\x06CREATE\xa1\x014\xa1.org.apache.qpid.dispatch.router.config.address\xa1\x07anycast\xa1\x08balancedBT\x00T\x00\xd0\x00\x00\x00]\x00\x00\x00\x08\xa1\x09broadcast\xa1\x015\xa1.org.apache.qpid.dispatch.router.config.address\xa1\x09broadcast\xa1\x09multicastBT\x00T\x00
I'll attach the full log. We're working on a reproducer. Right now, we see this
1/5 times when deploying the router, so it seems to be a bit timing dependent.
> Seeing unexpected values in management query response
> -
>
> Key: DISPATCH-502
> URL: https://issues.apache.org/jira/browse/DISPATCH-502
> Project: Qpid Dispatch
> Issue Type: Bug
>Reporter: Ulf Lilleengen
>
> We've been debugging an issue where we are getting some strange results from
> a management query for the router addresses.
> We've been able to capture the offending (we think) frame, maybe you can tell
> whether this is a correct frame or not:
> {noformat}
> [0x7f1cb8025ea0]:0 -> @transfer(20) [handle=1, delivery-id=9,
> delivery-tag=b"\x09\x00\x00\x00\x00\x00\x00\x00", message-format=0,
> settled=true, more=false] (547)
> "\x00Ss\xd0\x00\x00\x00G\x00\x00\x00\x06@@\xa19amqp:/_topo/0/Router.qdrouterd-3ysq1/temp.CKP6RovAXu+Q6mB@@\xa1\x0210\x00St\xd1\x00\x00\x00)\x00\x00\x00\x04\xa1\x11statusDescription\xa1\x02OK\xa1\x0astatusCodeR\xc8\x00Sw\xd1\x00\x00\x01\x9b\x00\x00\x00\x04\xa1\x0eattributeNames\xd0\x00\x00\x00U\x00\x00\x00\x08\xa1\x04name\xa1\x08identity\xa1\x04type\xa1\x06prefix\xa1\x0cdistribution\xa1\x08waypoint\xa1\x0cingressPhase\xa1\x0begressPhase\xa1\x07results\xd0\x00\x00\x01\x1f\x00\x00\x00\x03\xd0\x00\x00\x00X\x00\x00\x00\x08\xa1\x07myqueue\xa1\x013\xa1.org.apache.qpid.dispatch.router.config.address\xa1\x07myqueue\xa1\x08balancedAT\x00T\x01\xd0\x00\x00\x00W\x00\x00\x00\x08\xa1\x06CREATE\xa1\x014\xa1.org.apache.qpid.dispatch.router.config.address\xa1\x07anycast\xa1\x08balancedBT\x00T\x00\xd0\x00\x00\x00]\x00\x00\x00\x08\xa1\x09broadcast\xa1\x015\xa1.org.apache.qpid.dispatch.router.config.address\xa1\x09broadcast\xa1\x09multicastBT\x00T\x00
>
[jira] [Updated] (DISPATCH-502) Seeing unexpected values in management query response
[ https://issues.apache.org/jira/browse/DISPATCH-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ulf Lilleengen updated DISPATCH-502: Description: We've been debugging an issue where we are getting some strange results from a management query for the router addresses. We've been able to capture the offending (we think) frame, maybe you can tell whether this is a correct frame or not: [0x7f1cb8025ea0]:0 -> @transfer(20) [handle=1, delivery-id=9, delivery-tag=b"\x09\x00\x00\x00\x00\x00\x00\x00", message-format=0, settled=true, more=false] (547) "\x00Ss\xd0\x00\x00\x00G\x00\x00\x00\x06@@\xa19amqp:/_topo/0/Router.qdrouterd-3ysq1/temp.CKP6RovAXu+Q6mB@@\xa1\x0210\x00St\xd1\x00\x00\x00)\x00\x00\x00\x04\xa1\x11statusDescription\xa1\x02OK\xa1\x0astatusCodeR\xc8\x00Sw\xd1\x00\x00\x01\x9b\x00\x00\x00\x04\xa1\x0eattributeNames\xd0\x00\x00\x00U\x00\x00\x00\x08\xa1\x04name\xa1\x08identity\xa1\x04type\xa1\x06prefix\xa1\x0cdistribution\xa1\x08waypoint\xa1\x0cingressPhase\xa1\x0begressPhase\xa1\x07results\xd0\x00\x00\x01\x1f\x00\x00\x00\x03\xd0\x00\x00\x00X\x00\x00\x00\x08\xa1\x07myqueue\xa1\x013\xa1.org.apache.qpid.dispatch.router.config.address\xa1\x07myqueue\xa1\x08balancedAT\x00T\x01\xd0\x00\x00\x00W\x00\x00\x00\x08\xa1\x06CREATE\xa1\x014\xa1.org.apache.qpid.dispatch.router.config.address\xa1\x07anycast\xa1\x08balancedBT\x00T\x00\xd0\x00\x00\x00]\x00\x00\x00\x08\xa1\x09broadcast\xa1\x015\xa1.org.apache.qpid.dispatch.router.config.address\xa1\x09broadcast\xa1\x09multicastBT\x00T\x00 I'll attach the full log. We're working on a reproducer. Right now, we see this 1/5 times when deploying the router, so it seems to be a bit timing dependent. was: We've been debugging an issue where we are getting some strange results from a management query for the router addresses. We've been able to capture the offending (we think) frame, maybe you can tell whether this is a correct frame or not: [0x7f1cb8025ea0]:0 -> @transfer(20) [handle=1, delivery-id=9, delivery-tag=b"\x09\x00\x00\x00\x00\x00\x00\x00", message-format=0, settled=true, more=false] (547) "\x00Ss\xd0\x00\x00\x00G\x00\x00\x00\x06@@\xa19amqp:/_topo/0/Router.qdrouterd-3ysq1/temp.CKP6RovAXu+Q6mB@@\xa1\x0210\x00St\xd1\x00\x00\x00)\x00\x00\x00\x04\xa1\x11statusDescription\xa1\x02OK\xa1\x0astatusCodeR\xc8\x00Sw\xd1\x00\x00\x01\x9b\x00\x00\x00\x04\xa1\x0eattributeNames\xd0\x00\x00\x00U\x00\x00\x00\x08\xa1\x04name\xa1\x08identity\xa1\x04type\xa1\x06prefix\xa1\x0cdistribution\xa1\x08waypoint\xa1\x0cingressPhase\xa1\x0begressPhase\xa1\x07results\xd0\x00\x00\x01\x1f\x00\x00\x00\x03\xd0\x00\x00\x00X\x00\x00\x00\x08\xa1\x07myqueue\xa1\x013\xa1.org.apache.qpid.dispatch.router.config.address\xa1\x07myqueue\xa1\x08balancedAT\x00T\x01\xd0\x00\x00\x00W\x00\x00\x00\x08\xa1\x06CREATE\xa1\x014\xa1.org.apache.qpid.dispatch.router.config.address\xa1\x07anycast\xa1\x08balancedBT\x00T\x00\xd0\x00\x00\x00]\x00\x00\x00\x08\xa1\x09broadcast\xa1\x015\xa1.org.apache.qpid.dispatch.router.config.address\xa1\x09broadcast\xa1\x09multicastBT\x00T\x00 I'll attach the full log. We're working on a reproducer. Right now, we see this 1/5 times when deploying the router, so it seems to be a bit timing dependent. > Seeing unexpected values in management query response > - > > Key: DISPATCH-502 > URL: https://issues.apache.org/jira/browse/DISPATCH-502 > Project: Qpid Dispatch > Issue Type: Bug >Reporter: Ulf Lilleengen > > We've been debugging an issue where we are getting some strange results from > a management query for the router addresses. > We've been able to capture the offending (we think) frame, maybe you can tell > whether this is a correct frame or not: > > [0x7f1cb8025ea0]:0 -> @transfer(20) [handle=1, delivery-id=9, > delivery-tag=b"\x09\x00\x00\x00\x00\x00\x00\x00", message-format=0, > settled=true, more=false] (547) > "\x00Ss\xd0\x00\x00\x00G\x00\x00\x00\x06@@\xa19amqp:/_topo/0/Router.qdrouterd-3ysq1/temp.CKP6RovAXu+Q6mB@@\xa1\x0210\x00St\xd1\x00\x00\x00)\x00\x00\x00\x04\xa1\x11statusDescription\xa1\x02OK\xa1\x0astatusCodeR\xc8\x00Sw\xd1\x00\x00\x01\x9b\x00\x00\x00\x04\xa1\x0eattributeNames\xd0\x00\x00\x00U\x00\x00\x00\x08\xa1\x04name\xa1\x08identity\xa1\x04type\xa1\x06prefix\xa1\x0cdistribution\xa1\x08waypoint\xa1\x0cingressPhase\xa1\x0begressPhase\xa1\x07results\xd0\x00\x00\x01\x1f\x00\x00\x00\x03\xd0\x00\x00\x00X\x00\x00\x00\x08\xa1\x07myqueue\xa1\x013\xa1.org.apache.qpid.dispatch.router.config.address\xa1\x07myqueue\xa1\x08balancedAT\x00T\x01\xd0\x00\x00\x00W\x00\x00\x00\x08\xa1\x06CREATE\xa1\x014\xa1.org.apache.qpid.dispatch.router.config.address\xa1\x07anycast\xa1\x08balancedBT\x00T\x00\xd0\x00\x00\x00]\x00\x00\x00\x08\xa1\x09broadcast\xa1\x015\xa1.org.apache.qpid.dispatch.router.config.address\xa1\x09broadcast\xa1\x09multicastBT\x00T\x00 > > I'll attach the full log.
[jira] [Created] (DISPATCH-502) Seeing unexpected values in management query response
Ulf Lilleengen created DISPATCH-502: --- Summary: Seeing unexpected values in management query response Key: DISPATCH-502 URL: https://issues.apache.org/jira/browse/DISPATCH-502 Project: Qpid Dispatch Issue Type: Bug Reporter: Ulf Lilleengen We've been debugging an issue where we are getting some strange results from a management query for the router addresses. We've been able to capture the offending (we think) frame, maybe you can tell whether this is a correct frame or not: [0x7f1cb8025ea0]:0 -> @transfer(20) [handle=1, delivery-id=9, delivery-tag=b"\x09\x00\x00\x00\x00\x00\x00\x00", message-format=0, settled=true, more=false] (547) "\x00Ss\xd0\x00\x00\x00G\x00\x00\x00\x06@@\xa19amqp:/_topo/0/Router.qdrouterd-3ysq1/temp.CKP6RovAXu+Q6mB@@\xa1\x0210\x00St\xd1\x00\x00\x00)\x00\x00\x00\x04\xa1\x11statusDescription\xa1\x02OK\xa1\x0astatusCodeR\xc8\x00Sw\xd1\x00\x00\x01\x9b\x00\x00\x00\x04\xa1\x0eattributeNames\xd0\x00\x00\x00U\x00\x00\x00\x08\xa1\x04name\xa1\x08identity\xa1\x04type\xa1\x06prefix\xa1\x0cdistribution\xa1\x08waypoint\xa1\x0cingressPhase\xa1\x0begressPhase\xa1\x07results\xd0\x00\x00\x01\x1f\x00\x00\x00\x03\xd0\x00\x00\x00X\x00\x00\x00\x08\xa1\x07myqueue\xa1\x013\xa1.org.apache.qpid.dispatch.router.config.address\xa1\x07myqueue\xa1\x08balancedAT\x00T\x01\xd0\x00\x00\x00W\x00\x00\x00\x08\xa1\x06CREATE\xa1\x014\xa1.org.apache.qpid.dispatch.router.config.address\xa1\x07anycast\xa1\x08balancedBT\x00T\x00\xd0\x00\x00\x00]\x00\x00\x00\x08\xa1\x09broadcast\xa1\x015\xa1.org.apache.qpid.dispatch.router.config.address\xa1\x09broadcast\xa1\x09multicastBT\x00T\x00 I'll attach the full log. We're working on a reproducer. Right now, we see this 1/5 times when deploying the router, so it seems to be a bit timing dependent. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-479) Use atomic operations for ref counts
[ https://issues.apache.org/jira/browse/DISPATCH-479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ulf Lilleengen updated DISPATCH-479: Description: I ran some profiling using perf, and on the test server hardware, the locking related to ref counts on delivery and message was most contended. The benchmark is basically send unsettled messages as fast as it can. It would be nice to have this reviewed for correctness, as I am quite new to dispatch code and probably are making some bad assumptions. I'm seeing ~10% improvement in throughput with this patch on the test server at least, but there was no noticable improvement on my laptop. It might be that the cost of locking is much less on newer hardware. [~mwagner] It would be great if you could test the patch to see if it has any effect for your tests. Another question is if/how to use atomic instructions in dispatch. If c11 is preferred, I can change to that, but it appears it is not available for older RHEL versions, so the patch uses GCC extensions. was: I ran some profiling using perf, and on the test server hardware, the locking related to ref counts on delivery and message was most contended. The benchmark is basically send unsettled messages as fast as it can. I'm seeing ~10% improvement in throughput with this patch on the test server at least, but there was no noticable improvement on my laptop. It might be that the cost of locking is much less on newer hardware. [~mwagner] It would be great if you could test the patch to see if it has any effect for your tests. Another question is if/how to use atomic instructions in dispatch. If c11 is preferred, I can change to that, but it appears it is not available for older RHEL versions, so the patch uses GCC extensions. > Use atomic operations for ref counts > > > Key: DISPATCH-479 > URL: https://issues.apache.org/jira/browse/DISPATCH-479 > Project: Qpid Dispatch > Issue Type: Bug >Reporter: Ulf Lilleengen >Priority: Minor > > I ran some profiling using perf, and on the test server hardware, the locking > related to ref counts on delivery and message was most contended. The > benchmark is basically send unsettled messages as fast as it can. It would be > nice to have this reviewed for correctness, as I am quite new to dispatch > code and probably are making some bad assumptions. > I'm seeing ~10% improvement in throughput with this patch on the test server > at least, but there was no noticable improvement on my laptop. It might be > that the cost of locking is much less on newer hardware. [~mwagner] It would > be great if you could test the patch to see if it has any effect for your > tests. > Another question is if/how to use atomic instructions in dispatch. If c11 is > preferred, I can change to that, but it appears it is not available for older > RHEL versions, so the patch uses GCC extensions. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-479) Use atomic operations for ref counts
Ulf Lilleengen created DISPATCH-479: --- Summary: Use atomic operations for ref counts Key: DISPATCH-479 URL: https://issues.apache.org/jira/browse/DISPATCH-479 Project: Qpid Dispatch Issue Type: Bug Reporter: Ulf Lilleengen Priority: Minor I ran some profiling using perf, and on the test server hardware, the locking related to ref counts on delivery and message was most contended. The benchmark is basically send unsettled messages as fast as it can. I'm seeing ~10% improvement in throughput with this patch on the test server at least, but there was no noticable improvement on my laptop. It might be that the cost of locking is much less on newer hardware. [~mwagner] It would be great if you could test the patch to see if it has any effect for your tests. Another question is if/how to use atomic instructions in dispatch. If c11 is preferred, I can change to that, but it appears it is not available for older RHEL versions, so the patch uses GCC extensions. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-478) Dispatch hung in shutdown due to multiple concurrent signal handlers
Ulf Lilleengen created DISPATCH-478: --- Summary: Dispatch hung in shutdown due to multiple concurrent signal handlers Key: DISPATCH-478 URL: https://issues.apache.org/jira/browse/DISPATCH-478 Project: Qpid Dispatch Issue Type: Bug Reporter: Ulf Lilleengen Priority: Minor When I ran qdrouterd with perf and pressed Ctrl+C, perf would send SIGTERM as well as SIGINT right after each other to the router. Scenario: The first thread would pick up and handle the first signal in handle_signals_LH(). However, within the function, it unlocks the qd_server->lock before calling the registered handler. When it unlocks this lock, some other thread will pick up the second signal and jump into the qd_server_pause() code, where it will wait indefinitely for threads to pause (I saw this in GDB, where 1 thread was 'missing', and all others marked as canceled). The original handler will have canceled the thread trying to pause all others, but it is not able to jump out. Patch: https://github.com/apache/qpid-dispatch/pull/95 This patch ensures that only 1 signal handler can run at a time, which fixes the issue for me. Note that it will still potentially mask signals while handling a signal, but the current set of signals (SIGHUP, SIGQUIT, SIGINT, SIGTERM) either shutdown the router or do nothing. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-387) Router core dumps with misbehaving client
[ https://issues.apache.org/jira/browse/DISPATCH-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15329302#comment-15329302 ] Ulf Lilleengen commented on DISPATCH-387: - Yes, it is reproducible, but only if I restrict the receiver with --messages 1000 or some other number. It seems to crash when the receiver exits. > Router core dumps with misbehaving client > - > > Key: DISPATCH-387 > URL: https://issues.apache.org/jira/browse/DISPATCH-387 > Project: Qpid Dispatch > Issue Type: Bug >Reporter: Ulf Lilleengen > Attachments: simple_direct.conf > > > I have a simple setup with a router, a sender and a receiver. > The receiver is qpid-receiver from qpid-cpp-client-devel. The sender is a > modified version of https://github.com/orpiske/msg-perf-tool, and I've pushed > my modifications that made the router crash here: > https://github.com/lulf/msg-perf-tool/tree/lulf/dispatch-crash-sender > Using router built from master. > Invoking the receiver: qpid-receive --broker 127.0.0.1:5674 --address > amqp-test --ack-frequency 1 --messages 1 --report-total -f > --print-content false > Invoking the sender: ./bin/mpt-sender -b amqp://127.0.0.1:5674/amqp-test -p 1 > -d 1 -s 128 > The client might not behaving appropriately, so its entirely possible that I > don't know what I'm doing! But I was thinking that the router should probably > not crash due to misbehaving clients anyway. The core dump can be found here: > http://lulf.no/stuff/qdrouterd_dispatch_387.core > (gdb) where > #0 qd_link_pn (link=0x0) at /home/lulf/git/qpid-dispatch/src/container.c:862 > #1 0x7fbf4fc34e0c in CORE_link_push (context=0x1c5e3c0, link=0x1c84b80) > at /home/lulf/git/qpid-dispatch/src/router_node.c:808 > #2 0x7fbf4fc2b27e in qdr_connection_process (conn=0x7fbf380194a0) > at /home/lulf/git/qpid-dispatch/src/router_core/connections.c:175 > #3 0x7fbf4fc19528 in writable_handler (container=0x1b7b510, > container=0x1b7b510, conn=, > qd_conn=0x7fbf3800e4f0) at > /home/lulf/git/qpid-dispatch/src/container.c:353 > #4 handler (handler_context=0x1b7b510, conn_context=, > event=, qd_conn=0x7fbf3800e4f0) > at /home/lulf/git/qpid-dispatch/src/container.c:590 > #5 0x7fbf4fc389c5 in process_connector (cxtr=0x7fbf38000950, > qd_server=0x1c17ef0) > at /home/lulf/git/qpid-dispatch/src/server.c:744 > #6 thread_run (arg=) at > /home/lulf/git/qpid-dispatch/src/server.c:964 > #7 0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0 > #8 0x7fbf4ecf859d in clone () from /lib64/libc.so.6 > (gdb) thread apply all bt > Thread 5 (Thread 0x7fbf41fc1700 (LWP 13316)): > #0 0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x7fbf4fc24c8f in sys_cond_wait (cond=, > held_mutex=0x1b939c0) > at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107 > #2 0x7fbf4fc38764 in thread_run (arg=) at > /home/lulf/git/qpid-dispatch/src/server.c:846 > #3 0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0 > #4 0x7fbf4ecf859d in clone () from /lib64/libc.so.6 > Thread 4 (Thread 0x7fbf50041180 (LWP 13314)): > #0 0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x7fbf4fc24c8f in sys_cond_wait (cond=, > held_mutex=0x1b939c0) > at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107 > #2 0x7fbf4fc38764 in thread_run (arg=) at > /home/lulf/git/qpid-dispatch/src/server.c:846 > #3 0x7fbf4fc38eb0 in qd_server_run (qd=0x1944030) at > /home/lulf/git/qpid-dispatch/src/server.c:1371 > #4 0x00401aa7 in main_process ( > config_path=config_path@entry=0x7fffe5d8fdf0 > "../../qpid-examples/simple_direct.conf", > python_pkgdir=python_pkgdir@entry=0x402420 > "../../qpid-install/lib/qpid-dispatch/python", fd=fd@entry=2) > at /home/lulf/git/qpid-dispatch/router/src/main.c:145 > #5 0x00401797 in main (argc=3, argv=0x7fffe5d8f348) at > /home/lulf/git/qpid-dispatch/router/src/main.c:345 > Thread 3 (Thread 0x7fbf429d4700 (LWP 13315)): > #0 0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x7fbf4fc24c8f in sys_cond_wait (cond=, > held_mutex=0x1c637c0) > at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107 > #2 0x7fbf4fc2ffdd in router_core_thread (arg=0x1c63490) > at /home/lulf/git/qpid-dispatch/src/router_core/router_core_thread.c:54 > #3 0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0 > #4 0x7fbf4ecf859d in clone () from /lib64/libc.so.6 > Thread 2 (Thread 0x7fbf417c0700 (LWP 13317)): > #0 0x7fbf4ececb1d in poll () from /lib64/libc.so.6 > #1 0x7fbf4fc246e0 in qdpn_driver_wait_2 (d=0x1b2e270, timeout= out>, timeout@entry=397) > at
[jira] [Updated] (DISPATCH-387) Router core dumps with misbehaving client
[ https://issues.apache.org/jira/browse/DISPATCH-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ulf Lilleengen updated DISPATCH-387: Description: I have a simple setup with a router, a sender and a receiver. The receiver is qpid-receiver from qpid-cpp-client-devel. The sender is a modified version of https://github.com/orpiske/msg-perf-tool, and I've pushed my modifications that made the router crash here: https://github.com/lulf/msg-perf-tool/tree/lulf/dispatch-crash-sender Using router built from master. Invoking the receiver: qpid-receive --broker 127.0.0.1:5674 --address amqp-test --ack-frequency 1 --messages 1 --report-total -f --print-content false Invoking the sender: ./bin/mpt-sender -b amqp://127.0.0.1:5674/amqp-test -p 1 -d 1 -s 128 The client might not behaving appropriately, so its entirely possible that I don't know what I'm doing! But I was thinking that the router should probably not crash due to misbehaving clients anyway. The core dump can be found here: http://lulf.no/stuff/qdrouterd_dispatch_387.core (gdb) where #0 qd_link_pn (link=0x0) at /home/lulf/git/qpid-dispatch/src/container.c:862 #1 0x7fbf4fc34e0c in CORE_link_push (context=0x1c5e3c0, link=0x1c84b80) at /home/lulf/git/qpid-dispatch/src/router_node.c:808 #2 0x7fbf4fc2b27e in qdr_connection_process (conn=0x7fbf380194a0) at /home/lulf/git/qpid-dispatch/src/router_core/connections.c:175 #3 0x7fbf4fc19528 in writable_handler (container=0x1b7b510, container=0x1b7b510, conn=, qd_conn=0x7fbf3800e4f0) at /home/lulf/git/qpid-dispatch/src/container.c:353 #4 handler (handler_context=0x1b7b510, conn_context=, event=, qd_conn=0x7fbf3800e4f0) at /home/lulf/git/qpid-dispatch/src/container.c:590 #5 0x7fbf4fc389c5 in process_connector (cxtr=0x7fbf38000950, qd_server=0x1c17ef0) at /home/lulf/git/qpid-dispatch/src/server.c:744 #6 thread_run (arg=) at /home/lulf/git/qpid-dispatch/src/server.c:964 #7 0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0 #8 0x7fbf4ecf859d in clone () from /lib64/libc.so.6 (gdb) thread apply all bt Thread 5 (Thread 0x7fbf41fc1700 (LWP 13316)): #0 0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7fbf4fc24c8f in sys_cond_wait (cond=, held_mutex=0x1b939c0) at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107 #2 0x7fbf4fc38764 in thread_run (arg=) at /home/lulf/git/qpid-dispatch/src/server.c:846 #3 0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0 #4 0x7fbf4ecf859d in clone () from /lib64/libc.so.6 Thread 4 (Thread 0x7fbf50041180 (LWP 13314)): #0 0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7fbf4fc24c8f in sys_cond_wait (cond=, held_mutex=0x1b939c0) at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107 #2 0x7fbf4fc38764 in thread_run (arg=) at /home/lulf/git/qpid-dispatch/src/server.c:846 #3 0x7fbf4fc38eb0 in qd_server_run (qd=0x1944030) at /home/lulf/git/qpid-dispatch/src/server.c:1371 #4 0x00401aa7 in main_process ( config_path=config_path@entry=0x7fffe5d8fdf0 "../../qpid-examples/simple_direct.conf", python_pkgdir=python_pkgdir@entry=0x402420 "../../qpid-install/lib/qpid-dispatch/python", fd=fd@entry=2) at /home/lulf/git/qpid-dispatch/router/src/main.c:145 #5 0x00401797 in main (argc=3, argv=0x7fffe5d8f348) at /home/lulf/git/qpid-dispatch/router/src/main.c:345 Thread 3 (Thread 0x7fbf429d4700 (LWP 13315)): #0 0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7fbf4fc24c8f in sys_cond_wait (cond=, held_mutex=0x1c637c0) at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107 #2 0x7fbf4fc2ffdd in router_core_thread (arg=0x1c63490) at /home/lulf/git/qpid-dispatch/src/router_core/router_core_thread.c:54 #3 0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0 #4 0x7fbf4ecf859d in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x7fbf417c0700 (LWP 13317)): #0 0x7fbf4ececb1d in poll () from /lib64/libc.so.6 #1 0x7fbf4fc246e0 in qdpn_driver_wait_2 (d=0x1b2e270, timeout=, timeout@entry=397) at /home/lulf/git/qpid-dispatch/src/posix/driver.c:964 #2 0x7fbf4fc38249 in thread_run (arg=) at /home/lulf/git/qpid-dispatch/src/server.c:872 #3 0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0 #4 0x7fbf4ecf859d in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7fbf40fbf700 (LWP 13318)): #0 qd_link_pn (link=0x0) at /home/lulf/git/qpid-dispatch/src/container.c:862 #1 0x7fbf4fc34e0c in CORE_link_push (context=0x1c5e3c0, link=0x1c84b80) at /home/lulf/git/qpid-dispatch/src/router_node.c:808 #2 0x7fbf4fc2b27e in qdr_connection_process (conn=0x7fbf380194a0) at /home/lulf/git/qpid-dispatch/src/router_core/connections.c:175 #3 0x7fbf4fc19528 in
[jira] [Updated] (DISPATCH-387) Router core dumps with misbehaving client
[ https://issues.apache.org/jira/browse/DISPATCH-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ulf Lilleengen updated DISPATCH-387: Description: I have a simple setup with a router, a sender and a receiver. The receiver is qpid-receiver from qpid-cpp-client-devel. The sender is a modified version of https://github.com/orpiske/msg-perf-tool, and I've pushed my modifications that made the router crash here: https://github.com/lulf/msg-perf-tool/tree/lulf/dispatch-crash-sender Using router built from master. The client might not behaving appropriately, so its entirely possible that I don't know what I'm doing! But I was thinking that the router should probably not crash due to misbehaving clients anyway. The core dump can be found here: http://lulf.no/stuff/qdrouterd_dispatch_387.core (gdb) where #0 qd_link_pn (link=0x0) at /home/lulf/git/qpid-dispatch/src/container.c:862 #1 0x7fbf4fc34e0c in CORE_link_push (context=0x1c5e3c0, link=0x1c84b80) at /home/lulf/git/qpid-dispatch/src/router_node.c:808 #2 0x7fbf4fc2b27e in qdr_connection_process (conn=0x7fbf380194a0) at /home/lulf/git/qpid-dispatch/src/router_core/connections.c:175 #3 0x7fbf4fc19528 in writable_handler (container=0x1b7b510, container=0x1b7b510, conn=, qd_conn=0x7fbf3800e4f0) at /home/lulf/git/qpid-dispatch/src/container.c:353 #4 handler (handler_context=0x1b7b510, conn_context=, event=, qd_conn=0x7fbf3800e4f0) at /home/lulf/git/qpid-dispatch/src/container.c:590 #5 0x7fbf4fc389c5 in process_connector (cxtr=0x7fbf38000950, qd_server=0x1c17ef0) at /home/lulf/git/qpid-dispatch/src/server.c:744 #6 thread_run (arg=) at /home/lulf/git/qpid-dispatch/src/server.c:964 #7 0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0 #8 0x7fbf4ecf859d in clone () from /lib64/libc.so.6 (gdb) thread apply all bt Thread 5 (Thread 0x7fbf41fc1700 (LWP 13316)): #0 0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7fbf4fc24c8f in sys_cond_wait (cond=, held_mutex=0x1b939c0) at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107 #2 0x7fbf4fc38764 in thread_run (arg=) at /home/lulf/git/qpid-dispatch/src/server.c:846 #3 0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0 #4 0x7fbf4ecf859d in clone () from /lib64/libc.so.6 Thread 4 (Thread 0x7fbf50041180 (LWP 13314)): #0 0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7fbf4fc24c8f in sys_cond_wait (cond=, held_mutex=0x1b939c0) at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107 #2 0x7fbf4fc38764 in thread_run (arg=) at /home/lulf/git/qpid-dispatch/src/server.c:846 #3 0x7fbf4fc38eb0 in qd_server_run (qd=0x1944030) at /home/lulf/git/qpid-dispatch/src/server.c:1371 #4 0x00401aa7 in main_process ( config_path=config_path@entry=0x7fffe5d8fdf0 "../../qpid-examples/simple_direct.conf", python_pkgdir=python_pkgdir@entry=0x402420 "../../qpid-install/lib/qpid-dispatch/python", fd=fd@entry=2) at /home/lulf/git/qpid-dispatch/router/src/main.c:145 #5 0x00401797 in main (argc=3, argv=0x7fffe5d8f348) at /home/lulf/git/qpid-dispatch/router/src/main.c:345 Thread 3 (Thread 0x7fbf429d4700 (LWP 13315)): #0 0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7fbf4fc24c8f in sys_cond_wait (cond=, held_mutex=0x1c637c0) at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107 #2 0x7fbf4fc2ffdd in router_core_thread (arg=0x1c63490) at /home/lulf/git/qpid-dispatch/src/router_core/router_core_thread.c:54 #3 0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0 #4 0x7fbf4ecf859d in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x7fbf417c0700 (LWP 13317)): #0 0x7fbf4ececb1d in poll () from /lib64/libc.so.6 #1 0x7fbf4fc246e0 in qdpn_driver_wait_2 (d=0x1b2e270, timeout=, timeout@entry=397) at /home/lulf/git/qpid-dispatch/src/posix/driver.c:964 #2 0x7fbf4fc38249 in thread_run (arg=) at /home/lulf/git/qpid-dispatch/src/server.c:872 #3 0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0 #4 0x7fbf4ecf859d in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7fbf40fbf700 (LWP 13318)): #0 qd_link_pn (link=0x0) at /home/lulf/git/qpid-dispatch/src/container.c:862 #1 0x7fbf4fc34e0c in CORE_link_push (context=0x1c5e3c0, link=0x1c84b80) at /home/lulf/git/qpid-dispatch/src/router_node.c:808 #2 0x7fbf4fc2b27e in qdr_connection_process (conn=0x7fbf380194a0) at /home/lulf/git/qpid-dispatch/src/router_core/connections.c:175 #3 0x7fbf4fc19528 in writable_handler (container=0x1b7b510, container=0x1b7b510, conn=, qd_conn=0x7fbf3800e4f0) at /home/lulf/git/qpid-dispatch/src/container.c:353 #4 handler (handler_context=0x1b7b510, conn_context=, event=, qd_conn=0x7fbf3800e4f0) at
[jira] [Updated] (DISPATCH-387) Router core dumps with misbehaving client
[ https://issues.apache.org/jira/browse/DISPATCH-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ulf Lilleengen updated DISPATCH-387: Attachment: simple_direct.conf Router config > Router core dumps with misbehaving client > - > > Key: DISPATCH-387 > URL: https://issues.apache.org/jira/browse/DISPATCH-387 > Project: Qpid Dispatch > Issue Type: Bug >Reporter: Ulf Lilleengen > Attachments: simple_direct.conf > > > I have a simple setup with a router, a sender and a receiver. > The receiver is qpid-receiver from qpid-cpp-client-devel. The sender is a > modified version of https://github.com/orpiske/msg-perf-tool, and I've pushed > my modifications that made the router crash here: > https://github.com/lulf/msg-perf-tool/tree/lulf/dispatch-crash-sender > The client might not behaving appropriately, so its entirely possible that I > don't know what I'm doing! But I was thinking that the router should probably > not crash due to misbehaving clients anyway. > (gdb) where > #0 qd_link_pn (link=0x0) at /home/lulf/git/qpid-dispatch/src/container.c:862 > #1 0x7fbf4fc34e0c in CORE_link_push (context=0x1c5e3c0, link=0x1c84b80) > at /home/lulf/git/qpid-dispatch/src/router_node.c:808 > #2 0x7fbf4fc2b27e in qdr_connection_process (conn=0x7fbf380194a0) > at /home/lulf/git/qpid-dispatch/src/router_core/connections.c:175 > #3 0x7fbf4fc19528 in writable_handler (container=0x1b7b510, > container=0x1b7b510, conn=, > qd_conn=0x7fbf3800e4f0) at > /home/lulf/git/qpid-dispatch/src/container.c:353 > #4 handler (handler_context=0x1b7b510, conn_context=, > event=, qd_conn=0x7fbf3800e4f0) > at /home/lulf/git/qpid-dispatch/src/container.c:590 > #5 0x7fbf4fc389c5 in process_connector (cxtr=0x7fbf38000950, > qd_server=0x1c17ef0) > at /home/lulf/git/qpid-dispatch/src/server.c:744 > #6 thread_run (arg=) at > /home/lulf/git/qpid-dispatch/src/server.c:964 > #7 0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0 > #8 0x7fbf4ecf859d in clone () from /lib64/libc.so.6 > (gdb) thread apply all bt > Thread 5 (Thread 0x7fbf41fc1700 (LWP 13316)): > #0 0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x7fbf4fc24c8f in sys_cond_wait (cond=, > held_mutex=0x1b939c0) > at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107 > #2 0x7fbf4fc38764 in thread_run (arg=) at > /home/lulf/git/qpid-dispatch/src/server.c:846 > #3 0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0 > #4 0x7fbf4ecf859d in clone () from /lib64/libc.so.6 > Thread 4 (Thread 0x7fbf50041180 (LWP 13314)): > #0 0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x7fbf4fc24c8f in sys_cond_wait (cond=, > held_mutex=0x1b939c0) > at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107 > #2 0x7fbf4fc38764 in thread_run (arg=) at > /home/lulf/git/qpid-dispatch/src/server.c:846 > #3 0x7fbf4fc38eb0 in qd_server_run (qd=0x1944030) at > /home/lulf/git/qpid-dispatch/src/server.c:1371 > #4 0x00401aa7 in main_process ( > config_path=config_path@entry=0x7fffe5d8fdf0 > "../../qpid-examples/simple_direct.conf", > python_pkgdir=python_pkgdir@entry=0x402420 > "../../qpid-install/lib/qpid-dispatch/python", fd=fd@entry=2) > at /home/lulf/git/qpid-dispatch/router/src/main.c:145 > #5 0x00401797 in main (argc=3, argv=0x7fffe5d8f348) at > /home/lulf/git/qpid-dispatch/router/src/main.c:345 > Thread 3 (Thread 0x7fbf429d4700 (LWP 13315)): > #0 0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x7fbf4fc24c8f in sys_cond_wait (cond=, > held_mutex=0x1c637c0) > at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107 > #2 0x7fbf4fc2ffdd in router_core_thread (arg=0x1c63490) > at /home/lulf/git/qpid-dispatch/src/router_core/router_core_thread.c:54 > #3 0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0 > #4 0x7fbf4ecf859d in clone () from /lib64/libc.so.6 > Thread 2 (Thread 0x7fbf417c0700 (LWP 13317)): > #0 0x7fbf4ececb1d in poll () from /lib64/libc.so.6 > #1 0x7fbf4fc246e0 in qdpn_driver_wait_2 (d=0x1b2e270, timeout= out>, timeout@entry=397) > at /home/lulf/git/qpid-dispatch/src/posix/driver.c:964 > #2 0x7fbf4fc38249 in thread_run (arg=) at > /home/lulf/git/qpid-dispatch/src/server.c:872 > #3 0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0 > #4 0x7fbf4ecf859d in clone () from /lib64/libc.so.6 > Thread 1 (Thread 0x7fbf40fbf700 (LWP 13318)): > #0 qd_link_pn (link=0x0) at /home/lulf/git/qpid-dispatch/src/container.c:862 > #1 0x7fbf4fc34e0c in CORE_link_push (context=0x1c5e3c0, link=0x1c84b80) > at /home/lulf/git/qpid-dispatch/src/router_node.c:808 > #2
[jira] [Created] (DISPATCH-387) Router core dumps with misbehaving client
Ulf Lilleengen created DISPATCH-387: --- Summary: Router core dumps with misbehaving client Key: DISPATCH-387 URL: https://issues.apache.org/jira/browse/DISPATCH-387 Project: Qpid Dispatch Issue Type: Bug Reporter: Ulf Lilleengen I have a simple setup with a router, a sender and a receiver. The receiver is qpid-receiver from qpid-cpp-client-devel. The sender is a modified version of https://github.com/orpiske/msg-perf-tool, and I've pushed my modifications that made the router crash here: https://github.com/lulf/msg-perf-tool/tree/lulf/dispatch-crash-sender The client might not behaving appropriately, so its entirely possible that I don't know what I'm doing! But I was thinking that the router should probably not crash due to misbehaving clients anyway. (gdb) where #0 qd_link_pn (link=0x0) at /home/lulf/git/qpid-dispatch/src/container.c:862 #1 0x7fbf4fc34e0c in CORE_link_push (context=0x1c5e3c0, link=0x1c84b80) at /home/lulf/git/qpid-dispatch/src/router_node.c:808 #2 0x7fbf4fc2b27e in qdr_connection_process (conn=0x7fbf380194a0) at /home/lulf/git/qpid-dispatch/src/router_core/connections.c:175 #3 0x7fbf4fc19528 in writable_handler (container=0x1b7b510, container=0x1b7b510, conn=, qd_conn=0x7fbf3800e4f0) at /home/lulf/git/qpid-dispatch/src/container.c:353 #4 handler (handler_context=0x1b7b510, conn_context=, event=, qd_conn=0x7fbf3800e4f0) at /home/lulf/git/qpid-dispatch/src/container.c:590 #5 0x7fbf4fc389c5 in process_connector (cxtr=0x7fbf38000950, qd_server=0x1c17ef0) at /home/lulf/git/qpid-dispatch/src/server.c:744 #6 thread_run (arg=) at /home/lulf/git/qpid-dispatch/src/server.c:964 #7 0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0 #8 0x7fbf4ecf859d in clone () from /lib64/libc.so.6 (gdb) thread apply all bt Thread 5 (Thread 0x7fbf41fc1700 (LWP 13316)): #0 0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7fbf4fc24c8f in sys_cond_wait (cond=, held_mutex=0x1b939c0) at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107 #2 0x7fbf4fc38764 in thread_run (arg=) at /home/lulf/git/qpid-dispatch/src/server.c:846 #3 0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0 #4 0x7fbf4ecf859d in clone () from /lib64/libc.so.6 Thread 4 (Thread 0x7fbf50041180 (LWP 13314)): #0 0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7fbf4fc24c8f in sys_cond_wait (cond=, held_mutex=0x1b939c0) at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107 #2 0x7fbf4fc38764 in thread_run (arg=) at /home/lulf/git/qpid-dispatch/src/server.c:846 #3 0x7fbf4fc38eb0 in qd_server_run (qd=0x1944030) at /home/lulf/git/qpid-dispatch/src/server.c:1371 #4 0x00401aa7 in main_process ( config_path=config_path@entry=0x7fffe5d8fdf0 "../../qpid-examples/simple_direct.conf", python_pkgdir=python_pkgdir@entry=0x402420 "../../qpid-install/lib/qpid-dispatch/python", fd=fd@entry=2) at /home/lulf/git/qpid-dispatch/router/src/main.c:145 #5 0x00401797 in main (argc=3, argv=0x7fffe5d8f348) at /home/lulf/git/qpid-dispatch/router/src/main.c:345 Thread 3 (Thread 0x7fbf429d4700 (LWP 13315)): #0 0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7fbf4fc24c8f in sys_cond_wait (cond=, held_mutex=0x1c637c0) at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107 #2 0x7fbf4fc2ffdd in router_core_thread (arg=0x1c63490) at /home/lulf/git/qpid-dispatch/src/router_core/router_core_thread.c:54 #3 0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0 #4 0x7fbf4ecf859d in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x7fbf417c0700 (LWP 13317)): #0 0x7fbf4ececb1d in poll () from /lib64/libc.so.6 #1 0x7fbf4fc246e0 in qdpn_driver_wait_2 (d=0x1b2e270, timeout=, timeout@entry=397) at /home/lulf/git/qpid-dispatch/src/posix/driver.c:964 #2 0x7fbf4fc38249 in thread_run (arg=) at /home/lulf/git/qpid-dispatch/src/server.c:872 #3 0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0 #4 0x7fbf4ecf859d in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7fbf40fbf700 (LWP 13318)): #0 qd_link_pn (link=0x0) at /home/lulf/git/qpid-dispatch/src/container.c:862 #1 0x7fbf4fc34e0c in CORE_link_push (context=0x1c5e3c0, link=0x1c84b80) at /home/lulf/git/qpid-dispatch/src/router_node.c:808 #2 0x7fbf4fc2b27e in qdr_connection_process (conn=0x7fbf380194a0) at /home/lulf/git/qpid-dispatch/src/router_core/connections.c:175 #3 0x7fbf4fc19528 in writable_handler (container=0x1b7b510, container=0x1b7b510, conn=, qd_conn=0x7fbf3800e4f0) at /home/lulf/git/qpid-dispatch/src/container.c:353 #4 handler (handler_context=0x1b7b510, conn_context=, event=, qd_conn=0x7fbf3800e4f0) at
[jira] [Comment Edited] (DISPATCH-343) Router stops accepting connections after load from parallel senders
[ https://issues.apache.org/jira/browse/DISPATCH-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15300052#comment-15300052 ] Ulf Lilleengen edited comment on DISPATCH-343 at 5/25/16 1:43 PM: -- Vishal, If you have not already done so, it might be an idea to check /var/log/mcelog for hardware issues as well. Not sure if it exists on debian. was (Author: lulf): Vishal, If you have not already done so, it might be an idea to check /var/log/mcelog for hardware issues as well. > Router stops accepting connections after load from parallel senders > --- > > Key: DISPATCH-343 > URL: https://issues.apache.org/jira/browse/DISPATCH-343 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 >Reporter: Vishal Sharda >Priority: Blocker > Attachments: Connection_aborted.png, Connection_aborted_1.png, > Crash.png, Crash_10S_2R.png, R1.conf, R2.conf, R3.conf, > Sender_router_crash.png, bt_qd_dealloc.png, bt_qdr_link_cleanup_CT.png, > bt_sasl.png, bt_sys_mutex_lock.png, config1_nossl.conf, config2_nossl.conf, > resource-limit-exceeded.png > > > We ran 2 parallel senders and 2 receivers with each sender sending 5 > messages. After a while we saw that router stopped accepting connections > even from qdstat. We saw various errors in the logs (screenshots attached). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-343) Router stops accepting connections after load from parallel senders
[ https://issues.apache.org/jira/browse/DISPATCH-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15300052#comment-15300052 ] Ulf Lilleengen commented on DISPATCH-343: - Vishal, If you have not already done so, it might be an idea to check /var/log/mcelog for hardware issues as well. > Router stops accepting connections after load from parallel senders > --- > > Key: DISPATCH-343 > URL: https://issues.apache.org/jira/browse/DISPATCH-343 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 >Reporter: Vishal Sharda >Priority: Blocker > Attachments: Connection_aborted.png, Connection_aborted_1.png, > Crash.png, Crash_10S_2R.png, R1.conf, R2.conf, R3.conf, > Sender_router_crash.png, bt_qd_dealloc.png, bt_qdr_link_cleanup_CT.png, > bt_sasl.png, bt_sys_mutex_lock.png, config1_nossl.conf, config2_nossl.conf, > resource-limit-exceeded.png > > > We ran 2 parallel senders and 2 receivers with each sender sending 5 > messages. After a while we saw that router stopped accepting connections > even from qdstat. We saw various errors in the logs (screenshots attached). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
