[jira] [Commented] (DISPATCH-333) Add a chapter on policy to the Qpid Dispatch Router Book.
[ https://issues.apache.org/jira/browse/DISPATCH-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16383176#comment-16383176 ] ASF GitHub Bot commented on DISPATCH-333: - Github user dmuntima commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/255#discussion_r171513534 --- Diff: doc/new-book/configuration-security.adoc --- @@ -412,3 +414,356 @@ listener { For more information about these attributes, see xref:adding_sasl_authentication_to_incoming_connection[]. -- + +== Authorizing Access to Messaging Resources + +You can restrict the number of user connections, and control access to AMQP messaging resources by configuring _policies_. + +=== Types of Policies + +You can configure two different types of policies: _global policies_ and _vhost policies_. + +Global policies:: +Settings for the router. A global policy defines the maximum number of incoming user connections for the router (across all vhost policies), and defines how the router should use vhost policies. + +Vhost policies:: +Connection and AMQP resource limits for a messaging endpoint (called an AMQP virtual host, or _vhost_). A vhost policy defines what a client can access on a messaging endpoint over a particular connection. ++ +[NOTE] + +A vhost is typically the name of the host to which the client connection is directed. For example, if a client application opens a connection to the `amqp://mybroker.example.com:5672/queue01` URL, the vhost would be `mybroker.example.com`. + + +The resource limits defined in global and vhost policies are applied to user connections only. The limits do not affect inter-router connections or router connections that are outbound to waypoints. + +=== How {RouterName} Applies Policies + +When a client connects to a router, the router determines whether to permit the connection based on the global and vhost policies, and the following properties of the connection: + +* The host to which the connection is directed (the vhost) +* The connection's authenticated user name +* The host from which the client is connecting (the remote host) + +If the connection is permitted, then the router applies a vhost policy that matches the vhost to which the connection is directed. The vhost policy limits are enforced for the lifetime of the connection. + +=== Configuring Global Policies + +You can set the incoming connection limit for the router and define how it should use vhost policies by configuring a global policy. + +.Procedure + +* In the router configuration file, add a `policy` section. ++ +-- +[options="nowrap",subs="+quotes"] + +policy = { +maxConnections: 1 // <1> +enableVhostPolicy: true // <2> +policyDir: /etc/qpid-dispatch/policies/ // <3> +defaultVhost: $default // <4> +} + +<1> The maximum number of concurrent client connections allowed for this router. This limit is always enforced, even if no other policy settings have been defined. The limit is applied to all incoming connections regardless of remote host, authenticated user, or targeted vhost. The default value is `65535`. + +<2> Enables the router to enforce the connection denials and resource limits defined in the configured vhost policies. The default is `false`, which means that the router will not enforce any vhost policies. ++ +[NOTE] + +Setting `enableVhostPolicy` to `false` improves the router's performance. + + +<3> The absolute path to a directory that holds vhost policy definition files in JSON format (`*.json`). The router processes all of the vhost policies in each JSON file that is in this directory. For more information, see xref:configuring-vhost-policies-json[]. + +<4> The name of the default vhost policy, which is applied to any connection for which a vhost policy has not been configured. The default is `$default`. If `defaultVhost` is not defined, then default vhost processing is disabled. +-- + +=== Configuring Vhost Policies + +You configure vhost policies to define the connection limits and AMQP resource limits for a messaging endpoint. + +A vhost policy consists of the following: + +* Connection limits ++ +These limits control the number of users that can be connected to the vhost simultaneously. + +* User groups ++ +A user group defines the messaging resources that the group members are permitted to access. Each user group defines the following: + +** A set of users that can connect to the vhost (the group members) +** The remote hosts from which the group members may connect to the router ne
[GitHub] qpid-dispatch pull request #255: DISPATCH-333: Create new router policies do...
Github user dmuntima commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/255#discussion_r171513534 --- Diff: doc/new-book/configuration-security.adoc --- @@ -412,3 +414,356 @@ listener { For more information about these attributes, see xref:adding_sasl_authentication_to_incoming_connection[]. -- + +== Authorizing Access to Messaging Resources + +You can restrict the number of user connections, and control access to AMQP messaging resources by configuring _policies_. + +=== Types of Policies + +You can configure two different types of policies: _global policies_ and _vhost policies_. + +Global policies:: +Settings for the router. A global policy defines the maximum number of incoming user connections for the router (across all vhost policies), and defines how the router should use vhost policies. + +Vhost policies:: +Connection and AMQP resource limits for a messaging endpoint (called an AMQP virtual host, or _vhost_). A vhost policy defines what a client can access on a messaging endpoint over a particular connection. ++ +[NOTE] + +A vhost is typically the name of the host to which the client connection is directed. For example, if a client application opens a connection to the `amqp://mybroker.example.com:5672/queue01` URL, the vhost would be `mybroker.example.com`. + + +The resource limits defined in global and vhost policies are applied to user connections only. The limits do not affect inter-router connections or router connections that are outbound to waypoints. + +=== How {RouterName} Applies Policies + +When a client connects to a router, the router determines whether to permit the connection based on the global and vhost policies, and the following properties of the connection: + +* The host to which the connection is directed (the vhost) +* The connection's authenticated user name +* The host from which the client is connecting (the remote host) + +If the connection is permitted, then the router applies a vhost policy that matches the vhost to which the connection is directed. The vhost policy limits are enforced for the lifetime of the connection. + +=== Configuring Global Policies + +You can set the incoming connection limit for the router and define how it should use vhost policies by configuring a global policy. + +.Procedure + +* In the router configuration file, add a `policy` section. ++ +-- +[options="nowrap",subs="+quotes"] + +policy = { +maxConnections: 1 // <1> +enableVhostPolicy: true // <2> +policyDir: /etc/qpid-dispatch/policies/ // <3> +defaultVhost: $default // <4> +} + +<1> The maximum number of concurrent client connections allowed for this router. This limit is always enforced, even if no other policy settings have been defined. The limit is applied to all incoming connections regardless of remote host, authenticated user, or targeted vhost. The default value is `65535`. + +<2> Enables the router to enforce the connection denials and resource limits defined in the configured vhost policies. The default is `false`, which means that the router will not enforce any vhost policies. ++ +[NOTE] + +Setting `enableVhostPolicy` to `false` improves the router's performance. + + +<3> The absolute path to a directory that holds vhost policy definition files in JSON format (`*.json`). The router processes all of the vhost policies in each JSON file that is in this directory. For more information, see xref:configuring-vhost-policies-json[]. + +<4> The name of the default vhost policy, which is applied to any connection for which a vhost policy has not been configured. The default is `$default`. If `defaultVhost` is not defined, then default vhost processing is disabled. +-- + +=== Configuring Vhost Policies + +You configure vhost policies to define the connection limits and AMQP resource limits for a messaging endpoint. + +A vhost policy consists of the following: + +* Connection limits ++ +These limits control the number of users that can be connected to the vhost simultaneously. + +* User groups ++ +A user group defines the messaging resources that the group members are permitted to access. Each user group defines the following: + +** A set of users that can connect to the vhost (the group members) +** The remote hosts from which the group members may connect to the router network +** The AMQP resources that the group members are permitted to access on the vhost + +You can configure vhost policies directly in the router configuration file, or create them as JSON files. --- End diff -- Add links to the text
[jira] [Commented] (DISPATCH-333) Add a chapter on policy to the Qpid Dispatch Router Book.
[ https://issues.apache.org/jira/browse/DISPATCH-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16383177#comment-16383177 ] ASF GitHub Bot commented on DISPATCH-333: - Github user dmuntima commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/255#discussion_r171765659 --- Diff: doc/new-book/configuration-security.adoc --- @@ -412,3 +414,356 @@ listener { For more information about these attributes, see xref:adding_sasl_authentication_to_incoming_connection[]. -- + +== Authorizing Access to Messaging Resources + +You can restrict the number of user connections, and control access to AMQP messaging resources by configuring _policies_. + +=== Types of Policies + +You can configure two different types of policies: _global policies_ and _vhost policies_. + +Global policies:: +Settings for the router. A global policy defines the maximum number of incoming user connections for the router (across all vhost policies), and defines how the router should use vhost policies. + +Vhost policies:: +Connection and AMQP resource limits for a messaging endpoint (called an AMQP virtual host, or _vhost_). A vhost policy defines what a client can access on a messaging endpoint over a particular connection. ++ +[NOTE] + +A vhost is typically the name of the host to which the client connection is directed. For example, if a client application opens a connection to the `amqp://mybroker.example.com:5672/queue01` URL, the vhost would be `mybroker.example.com`. + + +The resource limits defined in global and vhost policies are applied to user connections only. The limits do not affect inter-router connections or router connections that are outbound to waypoints. + +=== How {RouterName} Applies Policies + +When a client connects to a router, the router determines whether to permit the connection based on the global and vhost policies, and the following properties of the connection: + +* The host to which the connection is directed (the vhost) +* The connection's authenticated user name +* The host from which the client is connecting (the remote host) + +If the connection is permitted, then the router applies a vhost policy that matches the vhost to which the connection is directed. The vhost policy limits are enforced for the lifetime of the connection. + +=== Configuring Global Policies + +You can set the incoming connection limit for the router and define how it should use vhost policies by configuring a global policy. + +.Procedure + +* In the router configuration file, add a `policy` section. ++ +-- +[options="nowrap",subs="+quotes"] + +policy = { +maxConnections: 1 // <1> +enableVhostPolicy: true // <2> +policyDir: /etc/qpid-dispatch/policies/ // <3> +defaultVhost: $default // <4> +} + +<1> The maximum number of concurrent client connections allowed for this router. This limit is always enforced, even if no other policy settings have been defined. The limit is applied to all incoming connections regardless of remote host, authenticated user, or targeted vhost. The default value is `65535`. + +<2> Enables the router to enforce the connection denials and resource limits defined in the configured vhost policies. The default is `false`, which means that the router will not enforce any vhost policies. ++ +[NOTE] + +Setting `enableVhostPolicy` to `false` improves the router's performance. + + +<3> The absolute path to a directory that holds vhost policy definition files in JSON format (`*.json`). The router processes all of the vhost policies in each JSON file that is in this directory. For more information, see xref:configuring-vhost-policies-json[]. + +<4> The name of the default vhost policy, which is applied to any connection for which a vhost policy has not been configured. The default is `$default`. If `defaultVhost` is not defined, then default vhost processing is disabled. +-- + +=== Configuring Vhost Policies + +You configure vhost policies to define the connection limits and AMQP resource limits for a messaging endpoint. + +A vhost policy consists of the following: + +* Connection limits ++ +These limits control the number of users that can be connected to the vhost simultaneously. + +* User groups ++ +A user group defines the messaging resources that the group members are permitted to access. Each user group defines the following: + +** A set of users that can connect to the vhost (the group members) +** The remote hosts from which the group members may connect to the router ne
[GitHub] qpid-dispatch pull request #255: DISPATCH-333: Create new router policies do...
Github user dmuntima commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/255#discussion_r171765659 --- Diff: doc/new-book/configuration-security.adoc --- @@ -412,3 +414,356 @@ listener { For more information about these attributes, see xref:adding_sasl_authentication_to_incoming_connection[]. -- + +== Authorizing Access to Messaging Resources + +You can restrict the number of user connections, and control access to AMQP messaging resources by configuring _policies_. + +=== Types of Policies + +You can configure two different types of policies: _global policies_ and _vhost policies_. + +Global policies:: +Settings for the router. A global policy defines the maximum number of incoming user connections for the router (across all vhost policies), and defines how the router should use vhost policies. + +Vhost policies:: +Connection and AMQP resource limits for a messaging endpoint (called an AMQP virtual host, or _vhost_). A vhost policy defines what a client can access on a messaging endpoint over a particular connection. ++ +[NOTE] + +A vhost is typically the name of the host to which the client connection is directed. For example, if a client application opens a connection to the `amqp://mybroker.example.com:5672/queue01` URL, the vhost would be `mybroker.example.com`. + + +The resource limits defined in global and vhost policies are applied to user connections only. The limits do not affect inter-router connections or router connections that are outbound to waypoints. + +=== How {RouterName} Applies Policies + +When a client connects to a router, the router determines whether to permit the connection based on the global and vhost policies, and the following properties of the connection: + +* The host to which the connection is directed (the vhost) +* The connection's authenticated user name +* The host from which the client is connecting (the remote host) + +If the connection is permitted, then the router applies a vhost policy that matches the vhost to which the connection is directed. The vhost policy limits are enforced for the lifetime of the connection. + +=== Configuring Global Policies + +You can set the incoming connection limit for the router and define how it should use vhost policies by configuring a global policy. + +.Procedure + +* In the router configuration file, add a `policy` section. ++ +-- +[options="nowrap",subs="+quotes"] + +policy = { +maxConnections: 1 // <1> +enableVhostPolicy: true // <2> +policyDir: /etc/qpid-dispatch/policies/ // <3> +defaultVhost: $default // <4> +} + +<1> The maximum number of concurrent client connections allowed for this router. This limit is always enforced, even if no other policy settings have been defined. The limit is applied to all incoming connections regardless of remote host, authenticated user, or targeted vhost. The default value is `65535`. + +<2> Enables the router to enforce the connection denials and resource limits defined in the configured vhost policies. The default is `false`, which means that the router will not enforce any vhost policies. ++ +[NOTE] + +Setting `enableVhostPolicy` to `false` improves the router's performance. + + +<3> The absolute path to a directory that holds vhost policy definition files in JSON format (`*.json`). The router processes all of the vhost policies in each JSON file that is in this directory. For more information, see xref:configuring-vhost-policies-json[]. + +<4> The name of the default vhost policy, which is applied to any connection for which a vhost policy has not been configured. The default is `$default`. If `defaultVhost` is not defined, then default vhost processing is disabled. +-- + +=== Configuring Vhost Policies + +You configure vhost policies to define the connection limits and AMQP resource limits for a messaging endpoint. + +A vhost policy consists of the following: + +* Connection limits ++ +These limits control the number of users that can be connected to the vhost simultaneously. + +* User groups ++ +A user group defines the messaging resources that the group members are permitted to access. Each user group defines the following: + +** A set of users that can connect to the vhost (the group members) +** The remote hosts from which the group members may connect to the router network +** The AMQP resources that the group members are permitted to access on the vhost + +You can configure vhost policies directly in the router configuration file, or create them as JSON files. + +[[configuring-vhost-policies-router]]
[jira] [Updated] (DISPATCH-937) schema.validate(attributes) called 4 times before the router starts
[ https://issues.apache.org/jira/browse/DISPATCH-937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy updated DISPATCH-937: --- Description: Start the router with the config file etc/qdrouterd.conf. This config file has one router entity {noformat} router { mode: interior id: Router.A }{noformat} The schema.validate is called 4 times on the router entity. It should be called only once Here is the traceback of the 4 times it was called - {noformat} {'type': u'org.apache.qpid.dispatch.router', u'mode': u'standalone', u'id': u'Router.A'} File "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py", line 142, in configure_dispatch config = Config(filename) File "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py", line 41, in __init__ self.load(filename, raw_json) File "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py", line 112, in load self.load(f, raw_json) File "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py", line 120, in load self.schema.validate_all(entities) File "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py", line 576, in validate_all self.validate_add(a, entities) File "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/qdrouter.py", line 53, in validate_add super(QdSchema, self).validate_add(attributes, entities) File "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py", line 585, in validate_add self.validate_entity(attributes) File "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py", line 568, in validate_entity entity_type.validate(attributes) File "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py", line 396, in validate for line in traceback.format_stack(): File "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py", line 164, in configure_dispatch configure(config.by_type('router')[0]) File "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py", line 151, in configure agent.configure(attributes) File "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py", line 855, in configure self._create(attributes) File "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py", line 828, in _create self.add_entity(entity) File "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py", line 859, in add_entity self.entities.add(entity) File "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py", line 519, in add entity.validate() # Fill in defaults etc. File "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py", line 171, in validate super(EntityAdapter, self).validate(**kwargs) File "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py", line 639, in validate self.entity_type.validate(self.attributes) File "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py", line 396, in validate for line in traceback.format_stack(): File "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py", line 164, in configure_dispatch configure(config.by_type('router')[0]) File "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py", line 151, in configure agent.configure(attributes) File "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py", line 855, in configure self._create(attributes) File "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py", line 828, in _create self.add_entity(entity) File "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py", line 859, in add_entity self.entities.add(entity) File "/home/gmurthy/opensource/qpid-dispatch/install/lib
[jira] [Created] (DISPATCH-937) schema.validate(attributes) called 4 times before the router starts
Ganesh Murthy created DISPATCH-937: -- Summary: schema.validate(attributes) called 4 times before the router starts Key: DISPATCH-937 URL: https://issues.apache.org/jira/browse/DISPATCH-937 Project: Qpid Dispatch Issue Type: Bug Components: Management Agent Affects Versions: 1.0.1 Reporter: Ganesh Murthy Assignee: Ganesh Murthy Fix For: 1.2.0 Start the router with the config file etc/qdrouterd.conf. This config file has one router entity {noformat} router { mode: interior id: Router.A }{noformat} The schema.validate is called 4 times on the router entity. It should be called only once -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-918) Improve router config consistency and metadata
[ https://issues.apache.org/jira/browse/DISPATCH-918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16382562#comment-16382562 ] ASF subversion and git services commented on DISPATCH-918: -- Commit 75d8b76631b96272f967cb613a05e109b883488f in qpid-dispatch's branch refs/heads/master from [~chug] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=75d8b76 ] DISPATCH-918: Deprecate vhost:id in favor of vhost:hostname > Improve router config consistency and metadata > -- > > Key: DISPATCH-918 > URL: https://issues.apache.org/jira/browse/DISPATCH-918 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Justin Ross >Assignee: Ganesh Murthy >Priority: Major > > Proposed changes from review. The items marked PRIO1 are more important. > All changes must be backward-compatible. > [https://docs.google.com/spreadsheets/d/14ugjxlc-ETYZXwN9eWD-D1YWrRAfydj9EJNmyUaZrD0/edit?usp=sharing] > This also includes flags we'd like to get added to the metadata so we can > generate better docs from it. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1696) Go test of anonymous SASL fails if it can't find saslpasswd2
[ https://issues.apache.org/jira/browse/PROTON-1696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved PROTON-1696. - Resolution: Fixed Fix Version/s: proton-c-0.22.0 > Go test of anonymous SASL fails if it can't find saslpasswd2 > > > Key: PROTON-1696 > URL: https://issues.apache.org/jira/browse/PROTON-1696 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Affects Versions: proton-c-0.18.1 >Reporter: Andrew Stitcher >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.22.0 > > > Even if extended SASL is not being tested. In this case it shouldn't even be > using saslpasswd2 to create an authentication database. Anonymous by its very > nature doesn't use an authentication db. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1696) Go test of anonymous SASL fails if it can't find saslpasswd2
[ https://issues.apache.org/jira/browse/PROTON-1696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16382539#comment-16382539 ] ASF subversion and git services commented on PROTON-1696: - Commit 817609a5476aea7219e432a04962e8ba194a8ad0 in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=817609a ] PROTON-1696 [go] reliable SASL config and test initialization - lock access to global SASL config variables to ensure no races. - panic if SASL config is called too late (lost config) - do SASL init before starting tests to avoid ordering and parallel test problems with on-demand initialization. > Go test of anonymous SASL fails if it can't find saslpasswd2 > > > Key: PROTON-1696 > URL: https://issues.apache.org/jira/browse/PROTON-1696 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Affects Versions: proton-c-0.18.1 >Reporter: Andrew Stitcher >Assignee: Alan Conway >Priority: Major > > Even if extended SASL is not being tested. In this case it shouldn't even be > using saslpasswd2 to create an authentication database. Anonymous by its very > nature doesn't use an authentication db. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-144) Reduce byte overhead for small payloads
[ https://issues.apache.org/jira/browse/PROTON-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-144. Resolution: Fixed Fix Version/s: proton-c-0.22.0 I have resolved this issue as I believe over 100 bytes to 15 bytes is sufficient for this report. I have opened PROTON-1779 & PROTON-1780 for the remaining large issues in reducing the bytes overhead generally in proton-c. > Reduce byte overhead for small payloads > --- > > Key: PROTON-144 > URL: https://issues.apache.org/jira/browse/PROTON-144 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.2, 0.3 >Reporter: Affan Dar >Assignee: Andrew Stitcher >Priority: Major > Labels: codec, perf > Fix For: proton-c-0.22.0 > > > In constrained bandwidth scenarios (e.g. on a cellular data network) any byte > overhead is very costly. > From the traces for a simple app, we are seeing a large overhead (>100 bytes) > in the message payload for sending a two byte message. It seems like there > are some default properties like the to and reply-to addresses that the > proton client stamps onto a message and also there is padding on the actual > two byte payload itself. > To be able to successfully embed the proton lib in such resource constrained > devices the byte overhead needs to be trimmed down as much as the protocol > allows. > --- > Details of test app > --- > The testing environment is OpenSUSE 11.4 64bit, the AMQP library is from SVN > updated usually once a day although commits have slowed since the push for > 0.2 and libopenssl version 1.0.0e-34.17.1. > The debugging output is all from proton, to get the debugging output set the > Env variable "PN_TRACE_FRM=1" > The test is done connecting to localhost and sending a message across as > simply as possible: > client: > pn_messenger_t *messenger = pn_messenger("b"); > pn_messenger_start(messenger); > pn_message_t *message = pn_message(); > pn_message_set_address(message, "amqps://0.0.0.0/a"); > char data[2] = {(unsigned char)0xff, (unsigned char)0xff}; > pn_message_load_data(message, data, 2); > pn_messenger_put(messenger, message); > pn_messenger_send(messenger); > > server code: > pn_messenger_t *messenger = pn_messenger("a"); > pn_messenger_start(messenger); > pn_messenger_subscribe(messenger, "amqps://~0.0.0.0"); > pn_message_t *message = pn_message(); > pn_messenger_recv(messenger, 1); > pn_messenger_get(messenger, message); > size_t size = 2; > char data[2]; > pn_message_save_data(message, data, &size); > > server output: > Accepted from localhost.localdomain:36331 > -> SASL > [0x622180:0] -> SASL-MECHANISMS @64 [@PN_SYMBOL[:ANONYMOUS]] > [0x622180:0] -> SASL-OUTCOME @68 [0] > -> AMQP > [0x61c7c0:0] -> OPEN @16 ["a", null, null, null, null, null, null, null, null] > <- SASL > [0x622180:0] <- SASL-INIT @65 [:ANONYMOUS, b""] > <- AMQP > [0x61c7c0:0] <- OPEN @16 ["b", "0.0.0.0", null, null, null, null, null, null, > null] > [0x61c7c0:1] <- BEGIN @17 [null, 0, 1024, 1024] > [0x61c7c0:1] <- ATTACH @18 ["sender-xxx", 1, false, null, null, @40 ["a", 0, > null, 0, false, null, null, null, null, null, null], @41 ["a", 0, null, 0, > false, null, null], null, null, 0] > [0x61c7c0:1] -> BEGIN @17 [1, 0, 1024, 1024] > [0x61c7c0:1] -> ATTACH @18 ["sender-xxx", 1, true, null, null, @40 ["a", 0, > null, 0, false, null, null, null, null, null, null], @41 ["a", 0, null, 0, > false, null, null], null, null, 0] > [0x61c7c0:1] -> FLOW @19 [0, 1024, 0, 1024, 1, 0, 1, null, false] > [0x61c7c0:1] <- TRANSFER @20 [1, 0, b"\x00\x00\x00\x00\x00\x00\x00\x00", 0, > true, false] (133) > "\x00\x80\x00\x00\x00\x00\x00\x00\x00p\xd0\x00\x00\x00\x10\x00\x00\x00\x05V\x00P\x04@V\x00p\x00\x00\x00\x00\x00\x80\x00\x00\x00\x00\x00\x00\x00s\xd0\x00\x00\x00F\x00\x00\x00\x0d@@\xb1\x00\x00\x00\x11amqps://0.0.0.0/a@\xb1\x00\x00\x00\x08amqp://b@@@\x83\x00\x00\x00\x00\x00\x00\x00\x00\x83\x00\x00\x00\x00\x00\x00\x00\x00@p\x00\x00\x00\x00@\x00\x80\x00\x00\x00\x00\x00\x00\x00w\xb0\x00\x00\x00\x02\xff\xff" > > client output: > Connected to 0.0.0.0:5671 > -> SASL > [0x620020:0] -> SASL-INIT @65 [:ANONYMOUS, b""] > <- SASL > [0x620020:0] <- SASL-MECHANISMS @64 [@PN_SYMBOL[:ANONYMOUS]] > [0x620020:0] <- SASL-OUTCOME @68 [0] > <- AMQP > [0x61a840:0] <- OPEN @16 ["a", null, null, null, null, null, null, null, null] > -> AMQP > [0x61a840:0] -> OPEN @16 ["b", "0.0.0.0", null, null, null, null, null, null, > null] > [0x61a840:1] -> BEGIN @17 [null, 0, 1024, 1024] > [0x61a840:1] -> ATTACH @18 ["sender-xxx", 1, false, null, null, @40 ["a", 0, > null, 0, false, null, null, null, null, null, null], @41 ["a", 0, null, 0, > false, null, null], null, null, 0] > [
[jira] [Created] (PROTON-1780) AMQP lists and maps should be enocded as LIST8 and MAP8 if possible
Andrew Stitcher created PROTON-1780: --- Summary: AMQP lists and maps should be enocded as LIST8 and MAP8 if possible Key: PROTON-1780 URL: https://issues.apache.org/jira/browse/PROTON-1780 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: proton-c-0.22.0 Reporter: Andrew Stitcher The current proton-c 0.22 encoder always encodes maps and lists using the LIST32 and MAP32 types. Much of the data exchanged using these types (especially AMQP frames themselves) would fit into 255 bytes and so fit into LIST8 or MAP8 types. This would save 6 bytes - the 32 variants take 9 bytes whereas the 8 variants take 3 bytes. This will be noticed most in short exchanges and using small messages. -- 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-1779) Completely omit default HEADER and PROPERTIES sections from message payload
Andrew Stitcher created PROTON-1779: --- Summary: Completely omit default HEADER and PROPERTIES sections from message payload Key: PROTON-1779 URL: https://issues.apache.org/jira/browse/PROTON-1779 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: proton-c-0.22.0 Reporter: Andrew Stitcher The current proton-c 0.22 still emits HEADER and PROPERTIES sections for messages when they have entirely default values. It soed encode these as LIST0 types which each only take 4 bytes. But as the sections are optional we can save another 8 bytes a message by leaving them out altogether. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-144) Reduce byte overhead for small payloads
[ https://issues.apache.org/jira/browse/PROTON-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16382486#comment-16382486 ] Andrew Stitcher commented on PROTON-144: With the previous 2 commits and PROTON-1754 an empty message is now only 8 bytes in 0.22 down from 43 bytes in 0.21. In theory it could be 0 bytes because as Ted says above there is no need to encode the HEADER and PROPERTIES sections at all, but at least they are now encoded in 4 bytes each. Running the simple_send.cpp example sending 100 messages to a broker (message payload approx 20 bytes) reduces the total bytes sent/received from approx 12100 to approx 9000 bytes giving a rough saving of 31 bytes a message. Note that this case isn't as good as the possible maximum (35 bytes) because there are some non default values in the message payload - however the transfer frame itself has also got shorter due to eliminating some nulls. Also some other frames have also got a little shorter too (especially flow and disposition frames). For the example of a 2 byte message as in the original issue report I'd expect the message payload now to be 15 bytes - the minimum would seem to be 7 bytes. > Reduce byte overhead for small payloads > --- > > Key: PROTON-144 > URL: https://issues.apache.org/jira/browse/PROTON-144 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.2, 0.3 >Reporter: Affan Dar >Assignee: Andrew Stitcher >Priority: Major > Labels: codec, perf > > In constrained bandwidth scenarios (e.g. on a cellular data network) any byte > overhead is very costly. > From the traces for a simple app, we are seeing a large overhead (>100 bytes) > in the message payload for sending a two byte message. It seems like there > are some default properties like the to and reply-to addresses that the > proton client stamps onto a message and also there is padding on the actual > two byte payload itself. > To be able to successfully embed the proton lib in such resource constrained > devices the byte overhead needs to be trimmed down as much as the protocol > allows. > --- > Details of test app > --- > The testing environment is OpenSUSE 11.4 64bit, the AMQP library is from SVN > updated usually once a day although commits have slowed since the push for > 0.2 and libopenssl version 1.0.0e-34.17.1. > The debugging output is all from proton, to get the debugging output set the > Env variable "PN_TRACE_FRM=1" > The test is done connecting to localhost and sending a message across as > simply as possible: > client: > pn_messenger_t *messenger = pn_messenger("b"); > pn_messenger_start(messenger); > pn_message_t *message = pn_message(); > pn_message_set_address(message, "amqps://0.0.0.0/a"); > char data[2] = {(unsigned char)0xff, (unsigned char)0xff}; > pn_message_load_data(message, data, 2); > pn_messenger_put(messenger, message); > pn_messenger_send(messenger); > > server code: > pn_messenger_t *messenger = pn_messenger("a"); > pn_messenger_start(messenger); > pn_messenger_subscribe(messenger, "amqps://~0.0.0.0"); > pn_message_t *message = pn_message(); > pn_messenger_recv(messenger, 1); > pn_messenger_get(messenger, message); > size_t size = 2; > char data[2]; > pn_message_save_data(message, data, &size); > > server output: > Accepted from localhost.localdomain:36331 > -> SASL > [0x622180:0] -> SASL-MECHANISMS @64 [@PN_SYMBOL[:ANONYMOUS]] > [0x622180:0] -> SASL-OUTCOME @68 [0] > -> AMQP > [0x61c7c0:0] -> OPEN @16 ["a", null, null, null, null, null, null, null, null] > <- SASL > [0x622180:0] <- SASL-INIT @65 [:ANONYMOUS, b""] > <- AMQP > [0x61c7c0:0] <- OPEN @16 ["b", "0.0.0.0", null, null, null, null, null, null, > null] > [0x61c7c0:1] <- BEGIN @17 [null, 0, 1024, 1024] > [0x61c7c0:1] <- ATTACH @18 ["sender-xxx", 1, false, null, null, @40 ["a", 0, > null, 0, false, null, null, null, null, null, null], @41 ["a", 0, null, 0, > false, null, null], null, null, 0] > [0x61c7c0:1] -> BEGIN @17 [1, 0, 1024, 1024] > [0x61c7c0:1] -> ATTACH @18 ["sender-xxx", 1, true, null, null, @40 ["a", 0, > null, 0, false, null, null, null, null, null, null], @41 ["a", 0, null, 0, > false, null, null], null, null, 0] > [0x61c7c0:1] -> FLOW @19 [0, 1024, 0, 1024, 1, 0, 1, null, false] > [0x61c7c0:1] <- TRANSFER @20 [1, 0, b"\x00\x00\x00\x00\x00\x00\x00\x00", 0, > true, false] (133) > "\x00\x80\x00\x00\x00\x00\x00\x00\x00p\xd0\x00\x00\x00\x10\x00\x00\x00\x05V\x00P\x04@V\x00p\x00\x00\x00\x00\x00\x80\x00\x00\x00\x00\x00\x00\x00s\xd0\x00\x00\x00F\x00\x00\x00\x0d@@\xb1\x00\x00\x00\x11amqps://0.0.0.0/a@\xb1\x00\x00\x00\x08amqp://b@@@\x83\x00\x00\x00\x00\x00\x00\x00\x00\x83\x00\x00\x00\x00\x00\x00\x00\x00@p\x00\x00\x00\x00@\x
[jira] [Resolved] (PROTON-1754) Ensure that AMQP NULLs are emitted in every place in the protocol that they are permitted
[ https://issues.apache.org/jira/browse/PROTON-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-1754. - Resolution: Fixed Fix Version/s: proton-c-0.22.0 There may be a very places left where default values are still emitted, but the bulk of the work is done now. > Ensure that AMQP NULLs are emitted in every place in the protocol that they > are permitted > - > > Key: PROTON-1754 > URL: https://issues.apache.org/jira/browse/PROTON-1754 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Major > Labels: codec, perf > Fix For: proton-c-0.22.0 > > > Proton-c produces much larger protocol frames than the protocol allows. As a > start to trimming this down we should go through every performative and > embedded described list and ensure that every non mandatory field is emitted > as null when it can be. > This should enable further work to trim these described lists to omit implied > AMQP NULLs at the end of the described lists. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-209) Three+ router test is needed in the system test suite.
[ https://issues.apache.org/jira/browse/DISPATCH-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16382456#comment-16382456 ] ASF subversion and git services commented on DISPATCH-209: -- Commit 5691122fc23588e9a8d02db561f154fc4f4ed155 in qpid-dispatch's branch refs/heads/master from [~mgoulish] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=5691122 ] DISPATCH-209 : ensure no dispositions lost > Three+ router test is needed in the system test suite. > -- > > Key: DISPATCH-209 > URL: https://issues.apache.org/jira/browse/DISPATCH-209 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Tests >Reporter: Ted Ross >Assignee: michael goulish >Priority: Major > Fix For: 1.0.0 > > > There have arisen some issues that would have been caught had there been a > three-router test in the regression suite. This test should be 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] [Commented] (PROTON-144) Reduce byte overhead for small payloads
[ https://issues.apache.org/jira/browse/PROTON-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16382452#comment-16382452 ] ASF subversion and git services commented on PROTON-144: Commit bd6b9719d55162e43851f1bafa6c104b7d37df4c in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=bd6b971 ] PROTON-144: Don't encode nulls at the end of described lists - They represent default values and so don't need to actually be there > Reduce byte overhead for small payloads > --- > > Key: PROTON-144 > URL: https://issues.apache.org/jira/browse/PROTON-144 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.2, 0.3 >Reporter: Affan Dar >Assignee: Andrew Stitcher >Priority: Major > Labels: codec, perf > > In constrained bandwidth scenarios (e.g. on a cellular data network) any byte > overhead is very costly. > From the traces for a simple app, we are seeing a large overhead (>100 bytes) > in the message payload for sending a two byte message. It seems like there > are some default properties like the to and reply-to addresses that the > proton client stamps onto a message and also there is padding on the actual > two byte payload itself. > To be able to successfully embed the proton lib in such resource constrained > devices the byte overhead needs to be trimmed down as much as the protocol > allows. > --- > Details of test app > --- > The testing environment is OpenSUSE 11.4 64bit, the AMQP library is from SVN > updated usually once a day although commits have slowed since the push for > 0.2 and libopenssl version 1.0.0e-34.17.1. > The debugging output is all from proton, to get the debugging output set the > Env variable "PN_TRACE_FRM=1" > The test is done connecting to localhost and sending a message across as > simply as possible: > client: > pn_messenger_t *messenger = pn_messenger("b"); > pn_messenger_start(messenger); > pn_message_t *message = pn_message(); > pn_message_set_address(message, "amqps://0.0.0.0/a"); > char data[2] = {(unsigned char)0xff, (unsigned char)0xff}; > pn_message_load_data(message, data, 2); > pn_messenger_put(messenger, message); > pn_messenger_send(messenger); > > server code: > pn_messenger_t *messenger = pn_messenger("a"); > pn_messenger_start(messenger); > pn_messenger_subscribe(messenger, "amqps://~0.0.0.0"); > pn_message_t *message = pn_message(); > pn_messenger_recv(messenger, 1); > pn_messenger_get(messenger, message); > size_t size = 2; > char data[2]; > pn_message_save_data(message, data, &size); > > server output: > Accepted from localhost.localdomain:36331 > -> SASL > [0x622180:0] -> SASL-MECHANISMS @64 [@PN_SYMBOL[:ANONYMOUS]] > [0x622180:0] -> SASL-OUTCOME @68 [0] > -> AMQP > [0x61c7c0:0] -> OPEN @16 ["a", null, null, null, null, null, null, null, null] > <- SASL > [0x622180:0] <- SASL-INIT @65 [:ANONYMOUS, b""] > <- AMQP > [0x61c7c0:0] <- OPEN @16 ["b", "0.0.0.0", null, null, null, null, null, null, > null] > [0x61c7c0:1] <- BEGIN @17 [null, 0, 1024, 1024] > [0x61c7c0:1] <- ATTACH @18 ["sender-xxx", 1, false, null, null, @40 ["a", 0, > null, 0, false, null, null, null, null, null, null], @41 ["a", 0, null, 0, > false, null, null], null, null, 0] > [0x61c7c0:1] -> BEGIN @17 [1, 0, 1024, 1024] > [0x61c7c0:1] -> ATTACH @18 ["sender-xxx", 1, true, null, null, @40 ["a", 0, > null, 0, false, null, null, null, null, null, null], @41 ["a", 0, null, 0, > false, null, null], null, null, 0] > [0x61c7c0:1] -> FLOW @19 [0, 1024, 0, 1024, 1, 0, 1, null, false] > [0x61c7c0:1] <- TRANSFER @20 [1, 0, b"\x00\x00\x00\x00\x00\x00\x00\x00", 0, > true, false] (133) > "\x00\x80\x00\x00\x00\x00\x00\x00\x00p\xd0\x00\x00\x00\x10\x00\x00\x00\x05V\x00P\x04@V\x00p\x00\x00\x00\x00\x00\x80\x00\x00\x00\x00\x00\x00\x00s\xd0\x00\x00\x00F\x00\x00\x00\x0d@@\xb1\x00\x00\x00\x11amqps://0.0.0.0/a@\xb1\x00\x00\x00\x08amqp://b@@@\x83\x00\x00\x00\x00\x00\x00\x00\x00\x83\x00\x00\x00\x00\x00\x00\x00\x00@p\x00\x00\x00\x00@\x00\x80\x00\x00\x00\x00\x00\x00\x00w\xb0\x00\x00\x00\x02\xff\xff" > > client output: > Connected to 0.0.0.0:5671 > -> SASL > [0x620020:0] -> SASL-INIT @65 [:ANONYMOUS, b""] > <- SASL > [0x620020:0] <- SASL-MECHANISMS @64 [@PN_SYMBOL[:ANONYMOUS]] > [0x620020:0] <- SASL-OUTCOME @68 [0] > <- AMQP > [0x61a840:0] <- OPEN @16 ["a", null, null, null, null, null, null, null, null] > -> AMQP > [0x61a840:0] -> OPEN @16 ["b", "0.0.0.0", null, null, null, null, null, null, > null] > [0x61a840:1] -> BEGIN @17 [null, 0, 1024, 1024] > [0x61a840:1] -> ATTACH @18 ["sender-xxx", 1, false, null, null, @40 ["a", 0, > null, 0, false, null, null, null, null, n
[jira] [Commented] (PROTON-144) Reduce byte overhead for small payloads
[ https://issues.apache.org/jira/browse/PROTON-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16382454#comment-16382454 ] ASF subversion and git services commented on PROTON-144: Commit 1b9c095828a00fb9a2206c8fe455bc88a1fb9490 in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=1b9c095 ] PROTON-144: Encode zore length lists as LIST0 type - Fix some interop tests to expect this - Fix message overflow test to use an smaller buffer - The previous size no longer overfows > Reduce byte overhead for small payloads > --- > > Key: PROTON-144 > URL: https://issues.apache.org/jira/browse/PROTON-144 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.2, 0.3 >Reporter: Affan Dar >Assignee: Andrew Stitcher >Priority: Major > Labels: codec, perf > > In constrained bandwidth scenarios (e.g. on a cellular data network) any byte > overhead is very costly. > From the traces for a simple app, we are seeing a large overhead (>100 bytes) > in the message payload for sending a two byte message. It seems like there > are some default properties like the to and reply-to addresses that the > proton client stamps onto a message and also there is padding on the actual > two byte payload itself. > To be able to successfully embed the proton lib in such resource constrained > devices the byte overhead needs to be trimmed down as much as the protocol > allows. > --- > Details of test app > --- > The testing environment is OpenSUSE 11.4 64bit, the AMQP library is from SVN > updated usually once a day although commits have slowed since the push for > 0.2 and libopenssl version 1.0.0e-34.17.1. > The debugging output is all from proton, to get the debugging output set the > Env variable "PN_TRACE_FRM=1" > The test is done connecting to localhost and sending a message across as > simply as possible: > client: > pn_messenger_t *messenger = pn_messenger("b"); > pn_messenger_start(messenger); > pn_message_t *message = pn_message(); > pn_message_set_address(message, "amqps://0.0.0.0/a"); > char data[2] = {(unsigned char)0xff, (unsigned char)0xff}; > pn_message_load_data(message, data, 2); > pn_messenger_put(messenger, message); > pn_messenger_send(messenger); > > server code: > pn_messenger_t *messenger = pn_messenger("a"); > pn_messenger_start(messenger); > pn_messenger_subscribe(messenger, "amqps://~0.0.0.0"); > pn_message_t *message = pn_message(); > pn_messenger_recv(messenger, 1); > pn_messenger_get(messenger, message); > size_t size = 2; > char data[2]; > pn_message_save_data(message, data, &size); > > server output: > Accepted from localhost.localdomain:36331 > -> SASL > [0x622180:0] -> SASL-MECHANISMS @64 [@PN_SYMBOL[:ANONYMOUS]] > [0x622180:0] -> SASL-OUTCOME @68 [0] > -> AMQP > [0x61c7c0:0] -> OPEN @16 ["a", null, null, null, null, null, null, null, null] > <- SASL > [0x622180:0] <- SASL-INIT @65 [:ANONYMOUS, b""] > <- AMQP > [0x61c7c0:0] <- OPEN @16 ["b", "0.0.0.0", null, null, null, null, null, null, > null] > [0x61c7c0:1] <- BEGIN @17 [null, 0, 1024, 1024] > [0x61c7c0:1] <- ATTACH @18 ["sender-xxx", 1, false, null, null, @40 ["a", 0, > null, 0, false, null, null, null, null, null, null], @41 ["a", 0, null, 0, > false, null, null], null, null, 0] > [0x61c7c0:1] -> BEGIN @17 [1, 0, 1024, 1024] > [0x61c7c0:1] -> ATTACH @18 ["sender-xxx", 1, true, null, null, @40 ["a", 0, > null, 0, false, null, null, null, null, null, null], @41 ["a", 0, null, 0, > false, null, null], null, null, 0] > [0x61c7c0:1] -> FLOW @19 [0, 1024, 0, 1024, 1, 0, 1, null, false] > [0x61c7c0:1] <- TRANSFER @20 [1, 0, b"\x00\x00\x00\x00\x00\x00\x00\x00", 0, > true, false] (133) > "\x00\x80\x00\x00\x00\x00\x00\x00\x00p\xd0\x00\x00\x00\x10\x00\x00\x00\x05V\x00P\x04@V\x00p\x00\x00\x00\x00\x00\x80\x00\x00\x00\x00\x00\x00\x00s\xd0\x00\x00\x00F\x00\x00\x00\x0d@@\xb1\x00\x00\x00\x11amqps://0.0.0.0/a@\xb1\x00\x00\x00\x08amqp://b@@@\x83\x00\x00\x00\x00\x00\x00\x00\x00\x83\x00\x00\x00\x00\x00\x00\x00\x00@p\x00\x00\x00\x00@\x00\x80\x00\x00\x00\x00\x00\x00\x00w\xb0\x00\x00\x00\x02\xff\xff" > > client output: > Connected to 0.0.0.0:5671 > -> SASL > [0x620020:0] -> SASL-INIT @65 [:ANONYMOUS, b""] > <- SASL > [0x620020:0] <- SASL-MECHANISMS @64 [@PN_SYMBOL[:ANONYMOUS]] > [0x620020:0] <- SASL-OUTCOME @68 [0] > <- AMQP > [0x61a840:0] <- OPEN @16 ["a", null, null, null, null, null, null, null, null] > -> AMQP > [0x61a840:0] -> OPEN @16 ["b", "0.0.0.0", null, null, null, null, null, null, > null] > [0x61a840:1] -> BEGIN @17 [null, 0, 1024, 1024] > [0x61a840:1] -> ATTACH @18 ["sender-xxx", 1, false, null, null, @40
[jira] [Commented] (PROTON-1754) Ensure that AMQP NULLs are emitted in every place in the protocol that they are permitted
[ https://issues.apache.org/jira/browse/PROTON-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16382453#comment-16382453 ] ASF subversion and git services commented on PROTON-1754: - Commit edb3aaa1587206b58842ccff843db71d4edf222d in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=edb3aaa ] PROTON-1754: Make AMQP frames have a lot more nulls where they can > Ensure that AMQP NULLs are emitted in every place in the protocol that they > are permitted > - > > Key: PROTON-1754 > URL: https://issues.apache.org/jira/browse/PROTON-1754 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Major > Labels: codec, perf > > Proton-c produces much larger protocol frames than the protocol allows. As a > start to trimming this down we should go through every performative and > embedded described list and ensure that every non mandatory field is emitted > as null when it can be. > This should enable further work to trim these described lists to omit implied > AMQP NULLs at the end of the described lists. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-918) Improve router config consistency and metadata
[ https://issues.apache.org/jira/browse/DISPATCH-918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16382341#comment-16382341 ] ASF subversion and git services commented on DISPATCH-918: -- Commit bb0093e92ce9bf184dc7c42e241e2169a6f8383e in qpid-dispatch's branch refs/heads/master from [~ganeshmurthy] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=bb0093e ] DISPATCH-918 - Modified schema code to allow the 'dir' attribute of autoLink and linkRoute to be used from qdmanage > Improve router config consistency and metadata > -- > > Key: DISPATCH-918 > URL: https://issues.apache.org/jira/browse/DISPATCH-918 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Justin Ross >Assignee: Ganesh Murthy >Priority: Major > > Proposed changes from review. The items marked PRIO1 are more important. > All changes must be backward-compatible. > [https://docs.google.com/spreadsheets/d/14ugjxlc-ETYZXwN9eWD-D1YWrRAfydj9EJNmyUaZrD0/edit?usp=sharing] > This also includes flags we'd like to get added to the metadata so we can > generate better docs from it. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDIT-61) Condense common code from the Python tests into a test module.
[ https://issues.apache.org/jira/browse/QPIDIT-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16382331#comment-16382331 ] ASF subversion and git services commented on QPIDIT-61: --- Commit 4b1c194aaa0053025943b01a117bbd87319796e6 in qpid-interop-test's branch refs/heads/master from [~kpvdr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-interop-test.git;h=4b1c194 ] QPIDIT-61: This is more of a renaming of modules so that all common libs have a name starting with qit_. This makes it easier to see the common lib modules in a file list. > Condense common code from the Python tests into a test module. > -- > > Key: QPIDIT-61 > URL: https://issues.apache.org/jira/browse/QPIDIT-61 > Project: Apache QPID Interoperability Test Suite > Issue Type: Task > Components: AMQP Large Content Test, AMQP Types Test, JMS Headers > and Properties Test, JMS Message Test >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > Fix For: 0.2.0 > > > Each test was written independently of the others. While this is a quick way > to start, it has not lead to a lot of duplicated code and common patterns. It > would help maintenance and readability of the code if the common bits were > placed into a test library. -- 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] (QPIDIT-117) Comprehensive test logging
[ https://issues.apache.org/jira/browse/QPIDIT-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-117: Affects Version/s: 0.1.0 > Comprehensive test logging > -- > > Key: QPIDIT-117 > URL: https://issues.apache.org/jira/browse/QPIDIT-117 > Project: Apache QPID Interoperability Test Suite > Issue Type: Improvement >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > Only xUnit logging is currently supported provided it is enabled in the > command-line options. > It would be helpful to implement a more comprehensive logging strategy so > that the client and broker logs may also be captured. Additionally, a more > comprehensive test log may be used which captures more detailed information > than is currently placed into the xUnit log. > For each test, capture: > * Detailed test log and output > * Broker logs (including logs for each node in multi-node tests) > * Additional client logs > An ability to scale up or down the verbosity of logging messages would also > be helpful. -- 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] (QPIDIT-117) Comprehensive test logging
Kim van der Riet created QPIDIT-117: --- Summary: Comprehensive test logging Key: QPIDIT-117 URL: https://issues.apache.org/jira/browse/QPIDIT-117 Project: Apache QPID Interoperability Test Suite Issue Type: Improvement Reporter: Kim van der Riet Assignee: Kim van der Riet Only xUnit logging is currently supported provided it is enabled in the command-line options. It would be helpful to implement a more comprehensive logging strategy so that the client and broker logs may also be captured. Additionally, a more comprehensive test log may be used which captures more detailed information than is currently placed into the xUnit log. For each test, capture: * Detailed test log and output * Broker logs (including logs for each node in multi-node tests) * Additional client logs An ability to scale up or down the verbosity of logging messages would also be helpful. -- 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] [Commented] (DISPATCH-935) Configuring the dispatch with lots of addresses and autolinks cause a long startup time
[ https://issues.apache.org/jira/browse/DISPATCH-935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16382115#comment-16382115 ] Ted Ross commented on DISPATCH-935: --- Whereas I'm sure we can make the configuration-file-processing operation more efficient, I claim that this scenario is a bit of an anti-pattern. If you need to maintain thousands of addresses and autolinks, it's likely that the set will be changing frequently. A better approach would be to use the management protocol to maintain the configuration. In this case, the router operates normally while the configuration is built up and modified over time. > 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 >Priority: Major > > 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] [Commented] (DISPATCH-918) Improve router config consistency and metadata
[ https://issues.apache.org/jira/browse/DISPATCH-918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16382044#comment-16382044 ] ASF subversion and git services commented on DISPATCH-918: -- Commit 7a306e7a60667db62b1fbf28b0b8c1462d54af91 in qpid-dispatch's branch refs/heads/master from [~chug] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=7a306e7 ] DISPATCH-918: allow blank strings as legal values in deprecationName processing > Improve router config consistency and metadata > -- > > Key: DISPATCH-918 > URL: https://issues.apache.org/jira/browse/DISPATCH-918 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Justin Ross >Assignee: Ganesh Murthy >Priority: Major > > Proposed changes from review. The items marked PRIO1 are more important. > All changes must be backward-compatible. > [https://docs.google.com/spreadsheets/d/14ugjxlc-ETYZXwN9eWD-D1YWrRAfydj9EJNmyUaZrD0/edit?usp=sharing] > This also includes flags we'd like to get added to the metadata so we can > generate better docs from it. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-918) Improve router config consistency and metadata
[ https://issues.apache.org/jira/browse/DISPATCH-918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16382035#comment-16382035 ] Chuck Rolke commented on DISPATCH-918: -- Commit 257321d has an issue where the deprecated attribute names do not work with qdmanage commands. This issue kills backward compatibility. {noformat} > qdmanage -b anonymous@127.0.0.1:23039 CREATE --type=autoLink addr=xyz > direction=out phase=2 { "addr": "xyz", "direction": "out", "name": null, "linkRef": null, "type": "org.apache.qpid.dispatch.router.config.autoLink", "operStatus": "inactive", "connection": null, "phase": 2, "lastError": null, "externalAddr": null, "identity": "3", "containerId": null } > qdmanage -b anonymous@127.0.0.1:23039 CREATE --type=autoLink addr=xyz2 > dir=out phase=2 KeyError: u'dir'{noformat} > Improve router config consistency and metadata > -- > > Key: DISPATCH-918 > URL: https://issues.apache.org/jira/browse/DISPATCH-918 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Justin Ross >Assignee: Ganesh Murthy >Priority: Major > > Proposed changes from review. The items marked PRIO1 are more important. > All changes must be backward-compatible. > [https://docs.google.com/spreadsheets/d/14ugjxlc-ETYZXwN9eWD-D1YWrRAfydj9EJNmyUaZrD0/edit?usp=sharing] > This also includes flags we'd like to get added to the metadata so we can > generate better docs from it. -- 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] [Commented] (QPID-7926) [c++ broker] Windows PODMutex is not a POD
[ https://issues.apache.org/jira/browse/QPID-7926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16381830#comment-16381830 ] Jay Ghiya commented on QPID-7926: - It also affects version qpid_c++ 1.37 ->Environment : Visual Studio 2010 x86 -> Operating System : Windows Can we get a stable past release of the code base? > [c++ broker] Windows PODMutex is not a POD > -- > > Key: QPID-7926 > URL: https://issues.apache.org/jira/browse/QPID-7926 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.36.0 > Environment: Windows Server 2012 R2, Visual Studio 2012, x64 build > Today's master branch >Reporter: Chuck Rolke >Priority: Major > > {noformat} > 1>-- Build started: Project: qpidcommon, Configuration: Debug x64 -- > 1> Logger.cpp > 1>D:\Users\crolke\git\qpid-cpp\src\qpid\log\Logger.cpp(48): error C2440: > 'initializing' : cannot convert from 'int' to 'qpid::sys::PODMutex' > 1> No constructor could take the source type, or constructor > overload resolution was ambiguous > {noformat} > The issue is with the definition of QPID_MUTEX_INITIALIZER. > In Linux it is defined as PTHREAD_MUTEX_INITIALIZER which is a complex > structure initializer. > In Windows it is a naked 0. > In a stand-alone windows program > {noformat} > std::is_pod::value > {noformat} > returns false. In Linux the same statement in qpidd broker returns true. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-proton pull request #137: [cpp] Fix update method missing 'name' variab...
GitHub user p32blo opened a pull request: https://github.com/apache/qpid-proton/pull/137 [cpp] Fix update method missing 'name' variable The `name` property in the sender and receiver is not being updated correctly when passed to the `open_sender` and `open_receiver`. Here is a simple example demonstrating the problem: ```cpp #include #include #include #include int main() { proton::container c; proton::sender_options so; proton::receiver_options ro; so.name("qpid"); ro.name("qpid"); proton::sender sender = c.open_sender("", so); proton::receiver receiver = c.open_receiver("", ro); std::cout << sender.name() << std::endl; std::cout << receiver.name() << std::endl; } ``` The output is currently a random uuid, but it should be "qpid" in both cases. You can merge this pull request into a Git repository by running: $ git pull https://github.com/p32blo/qpid-proton master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-proton/pull/137.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #137 commit 69a9f91627ccc997337cab5f191f2d1c80ca10f3 Author: André Oliveira Date: 2018-03-01T10:15:30Z [cpp] Fix update method missing 'name' variable --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8114) [Broker-J] Attempting to use an unknown filter type incorrectly causes connection closure with a decode error
[ https://issues.apache.org/jira/browse/QPID-8114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16381738#comment-16381738 ] Rob Godfrey commented on QPID-8114: --- Attached a patch which I think would address this particular instance of the problem; however it is a more general thing that we are handling unknown described types as a decoding error, rather than higher up in the stack. The patch provides the outlines of a generalized mechanism for this, but we would need to go through all the "specialized" described types and fix them, along with all the places in the codec where this sort of thing may occur > [Broker-J] Attempting to use an unknown filter type incorrectly causes > connection closure with a decode error > - > > Key: QPID-8114 > URL: https://issues.apache.org/jira/browse/QPID-8114 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Reporter: Rob Godfrey >Priority: Major > Attachments: > QPID-8114___[Broker-J]_Attempting_to_use_an_unknown_filter_type_incorrectly_causes_connect.patch > > > As discovered in QPID-8113 if a client attempts to attach to a source using > an unknown filter type (i.e. an unrecognised descriptor) the broker responds > with a decode error similar to > {{[0x555941994670]:0 <- @close(24) [error=@error(29) > [condition=:"amqp:decode-error", description="Expected key type is 'Filter' > but got 'DescribedType'"]]}} > Instead the broker should simply fail to attach (i.e. attach with > source=null) and then immediately detach with a {{not-implemented}} error. -- 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] (QPID-8114) [Broker-J] Attempting to use an unknown filter type incorrectly causes connection closure with a decode error
[ https://issues.apache.org/jira/browse/QPID-8114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-8114: -- Attachment: QPID-8114___[Broker-J]_Attempting_to_use_an_unknown_filter_type_incorrectly_causes_connect.patch > [Broker-J] Attempting to use an unknown filter type incorrectly causes > connection closure with a decode error > - > > Key: QPID-8114 > URL: https://issues.apache.org/jira/browse/QPID-8114 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Reporter: Rob Godfrey >Priority: Major > Attachments: > QPID-8114___[Broker-J]_Attempting_to_use_an_unknown_filter_type_incorrectly_causes_connect.patch > > > As discovered in QPID-8113 if a client attempts to attach to a source using > an unknown filter type (i.e. an unrecognised descriptor) the broker responds > with a decode error similar to > {{[0x555941994670]:0 <- @close(24) [error=@error(29) > [condition=:"amqp:decode-error", description="Expected key type is 'Filter' > but got 'DescribedType'"]]}} > Instead the broker should simply fail to attach (i.e. attach with > source=null) and then immediately detach with a {{not-implemented}} error. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-333) Add a chapter on policy to the Qpid Dispatch Router Book.
[ https://issues.apache.org/jira/browse/DISPATCH-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16381712#comment-16381712 ] ASF GitHub Bot commented on DISPATCH-333: - Github user dmuntima commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/255#discussion_r171498477 --- Diff: doc/new-book/configuration-security.adoc --- @@ -412,3 +414,356 @@ listener { For more information about these attributes, see xref:adding_sasl_authentication_to_incoming_connection[]. -- + +== Authorizing Access to Messaging Resources + +You can restrict the number of user connections, and control access to AMQP messaging resources by configuring _policies_. + +=== Types of Policies + +You can configure two different types of policies: _global policies_ and _vhost policies_. + +Global policies:: +Settings for the router. A global policy defines the maximum number of incoming user connections for the router (across all vhost policies), and defines how the router should use vhost policies. + +Vhost policies:: +Connection and AMQP resource limits for a messaging endpoint (called an AMQP virtual host, or _vhost_). A vhost policy defines what a client can access on a messaging endpoint over a particular connection. ++ +[NOTE] + +A vhost is typically the name of the host to which the client connection is directed. For example, if a client application opens a connection to the `amqp://mybroker.example.com:5672/queue01` URL, the vhost would be `mybroker.example.com`. + + +The resource limits defined in global and vhost policies are applied to user connections only. The limits do not affect inter-router connections or router connections that are outbound to waypoints. + +=== How {RouterName} Applies Policies + +When a client connects to a router, the router determines whether to permit the connection based on the global and vhost policies, and the following properties of the connection: + +* The host to which the connection is directed (the vhost) +* The connection's authenticated user name +* The host from which the client is connecting (the remote host) + +If the connection is permitted, then the router applies a vhost policy that matches the vhost to which the connection is directed. The vhost policy limits are enforced for the lifetime of the connection. + +=== Configuring Global Policies + +You can set the incoming connection limit for the router and define how it should use vhost policies by configuring a global policy. + +.Procedure + +* In the router configuration file, add a `policy` section. ++ +-- +[options="nowrap",subs="+quotes"] + +policy = { +maxConnections: 1 // <1> +enableVhostPolicy: true // <2> +policyDir: /etc/qpid-dispatch/policies/ // <3> +defaultVhost: $default // <4> +} + +<1> The maximum number of concurrent client connections allowed for this router. This limit is always enforced, even if no other policy settings have been defined. The limit is applied to all incoming connections regardless of remote host, authenticated user, or targeted vhost. The default value is `65535`. --- End diff -- If possible, please provide the minimum and maximum values for this element. > Add a chapter on policy to the Qpid Dispatch Router Book. > - > > Key: DISPATCH-333 > URL: https://issues.apache.org/jira/browse/DISPATCH-333 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Documentation >Affects Versions: 0.7.0 >Reporter: Ganesh Murthy >Assignee: Ben Hardesty >Priority: Minor > > Add a new chapter containing details on how policy works and how to setup > policy to the Qpid Dispatch Router Book -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #255: DISPATCH-333: Create new router policies do...
Github user dmuntima commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/255#discussion_r171498477 --- Diff: doc/new-book/configuration-security.adoc --- @@ -412,3 +414,356 @@ listener { For more information about these attributes, see xref:adding_sasl_authentication_to_incoming_connection[]. -- + +== Authorizing Access to Messaging Resources + +You can restrict the number of user connections, and control access to AMQP messaging resources by configuring _policies_. + +=== Types of Policies + +You can configure two different types of policies: _global policies_ and _vhost policies_. + +Global policies:: +Settings for the router. A global policy defines the maximum number of incoming user connections for the router (across all vhost policies), and defines how the router should use vhost policies. + +Vhost policies:: +Connection and AMQP resource limits for a messaging endpoint (called an AMQP virtual host, or _vhost_). A vhost policy defines what a client can access on a messaging endpoint over a particular connection. ++ +[NOTE] + +A vhost is typically the name of the host to which the client connection is directed. For example, if a client application opens a connection to the `amqp://mybroker.example.com:5672/queue01` URL, the vhost would be `mybroker.example.com`. + + +The resource limits defined in global and vhost policies are applied to user connections only. The limits do not affect inter-router connections or router connections that are outbound to waypoints. + +=== How {RouterName} Applies Policies + +When a client connects to a router, the router determines whether to permit the connection based on the global and vhost policies, and the following properties of the connection: + +* The host to which the connection is directed (the vhost) +* The connection's authenticated user name +* The host from which the client is connecting (the remote host) + +If the connection is permitted, then the router applies a vhost policy that matches the vhost to which the connection is directed. The vhost policy limits are enforced for the lifetime of the connection. + +=== Configuring Global Policies + +You can set the incoming connection limit for the router and define how it should use vhost policies by configuring a global policy. + +.Procedure + +* In the router configuration file, add a `policy` section. ++ +-- +[options="nowrap",subs="+quotes"] + +policy = { +maxConnections: 1 // <1> +enableVhostPolicy: true // <2> +policyDir: /etc/qpid-dispatch/policies/ // <3> +defaultVhost: $default // <4> +} + +<1> The maximum number of concurrent client connections allowed for this router. This limit is always enforced, even if no other policy settings have been defined. The limit is applied to all incoming connections regardless of remote host, authenticated user, or targeted vhost. The default value is `65535`. --- End diff -- If possible, please provide the minimum and maximum values for this element. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org