[jira] [Commented] (DISPATCH-333) Add a chapter on policy to the Qpid Dispatch Router Book.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 
network
+** 

[GitHub] qpid-dispatch pull request #255: DISPATCH-333: Create new router policies do...

[dmuntima]

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 

[jira] [Commented] (DISPATCH-333) Add a chapter on policy to the Qpid Dispatch Router Book.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 
network
+** 

[GitHub] qpid-dispatch pull request #255: DISPATCH-333: Create new router policies do...

[dmuntima]

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

[Ganesh Murthy (JIRA)]

 [ 
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 

[jira] [Created] (DISPATCH-937) schema.validate(attributes) called 4 times before the router starts

[Ganesh Murthy (JIRA)]

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

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Alan Conway (JIRA)]

 [ 
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

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Andrew Stitcher (JIRA)]

 [ 
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, );
>  
> 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 (JIRA)]

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 (JIRA)]

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

[Andrew Stitcher (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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, );
>  
> 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) 
> 

[jira] [Resolved] (PROTON-1754) Ensure that AMQP NULLs are emitted in every place in the protocol that they are permitted

[Andrew Stitcher (JIRA)]

 [ 
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.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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, );
>  
> 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", 

[jira] [Commented] (PROTON-144) Reduce byte overhead for small payloads

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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, );
>  
> 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, 

[jira] [Commented] (PROTON-1754) Ensure that AMQP NULLs are emitted in every place in the protocol that they are permitted

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPIDIT-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Kim van der Riet (JIRA)]

 [ 
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 (JIRA)]

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 (JIRA)]

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

[Ted Ross (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chuck Rolke (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 (JIRA)]

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

[Jay Ghiya (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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...

[p32blo]

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

[Rob Godfrey (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-8114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Rob Godfrey (JIRA)]

 [ 
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.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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...

[dmuntima]

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