[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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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,
[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&focusedCommentId=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&focusedCommentId=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
[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&focusedCommentId=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 examp
[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&focusedCommentId=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 1
[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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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, > timeo
[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&focusedCommentId=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&focusedCommentId=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 > {n
[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. We're
[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&focusedCommentId=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 /home/lulf/git/qpid
[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 writable_
[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 /home/lulf/git
[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&focusedCommentId=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&focusedCommentId=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