[jira] [Commented] (QPID-8165) [Broker-J][WMC] Validation of configured object names is too restrictive in Web Management Console

2018-05-02 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/QPID-8165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16461723#comment-16461723
 ] 

ASF subversion and git services commented on QPID-8165:
---

Commit c8fae15492a09155039a61d11bf7d2dbdc280c65 in qpid-broker-j's branch 
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=c8fae15 ]

QPID-8165: [Broker-J][WMC] Fix RegEx to allow more characters in configured 
object names


> [Broker-J][WMC] Validation of configured object names is too restrictive in 
> Web Management Console
> --
>
> Key: QPID-8165
> URL: https://issues.apache.org/jira/browse/QPID-8165
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3, 
> qpid-java-broker-7.0.2, qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2, 
> qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5, qpid-java-6.1, 
> qpid-java-6.0.6, qpid-java-6.1.1, qpid-java-6.1.2, qpid-java-6.0.7, 
> qpid-java-6.1.3, qpid-java-6.0.8, qpid-java-6.1.4, qpid-java-broker-7.0.0, 
> qpid-java-6.1.5, qpid-java-broker-7.0.1
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.4
>
>
> WMC only allows to create (or edit) configured objects with names consisting 
> only from any mixture of digits, letters, and underscores. This restriction 
> was added into Web Management Console to meet the requirements of AMQP 0-8 
> protocol. The queue and exchange names in  domain definition are defined as  
> name consisting only from digits, letters, and underscores.
> {quote}
> The queue name identifies the queue within the vhost.  Queue
> names may consist of any mixture of digits, letters, and
> underscores.
> {quote}
> {quote}
> The exchange name is a client-selected string that identifies
>   the exchange for publish methods.  Exchange names may consist
>   of any mixture of digits, letters, and underscores.  Exchange
>   names are scoped by the virtual host.
> {quote}
> However, in definitions of declare commands for queue and exchange  the AMQP 
> 0-8 specifies a regular expression for the names allowing more characters:
> {code}
> ^[a-zA-Z0-9-_.:]*$
> {code}
> The same regular expression is defined in specifications for AMQP 0-9 and 
> 0-9-1.
> The names of virtual hosts in specifications for AMQP 0-8 and AMQP 0-9 should 
> match regular expression (as per documentation of connection open)
> {code}
> ^[a-zA-Z0-9-_.:]*$
> {code}
> AMQP 0-10 allows more characters in queue name
> {quote}
>  Queue names must have a length
> of between 1 and 255 characters inclusive, must start with a digit, 
> letter or underscores
> ('_') character, and must be otherwise encoded in UTF-8.
> {quote}
> As a minimum, the Web Management Console should allow creation of queues, 
> exchanges with names matching {{^[a-zA-Z0-9-_.:]*$}}. The virtual host names 
> matching regular expression {{^[a-zA-Z0-9/-_]+$}} should be allowed . The 
> names of other configured objects can be unrestricted. 
> Alternatively, we can add some sort of AMQP compatibility modes to Web 
> Management Console and management API when required level compatibility can 
> be configured by the user and different validation rules can apply based on 
> required compatibility.



--
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-8167) [Broker-J] Broker command line option '-mmqv/--management-mode-quiesce-virtualhosts' does not quiesce virtual hosts

2018-05-02 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/QPID-8167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16461724#comment-16461724
 ] 

ASF subversion and git services commented on QPID-8167:
---

Commit b14319e30a0a09f8ce12a8d4e98e19a686c0c1ed in qpid-broker-j's branch 
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=b14319e ]

QPID-8167: [Broker-J] Fix quiescing virtualhosts in management mode


> [Broker-J] Broker command line option 
> '-mmqv/--management-mode-quiesce-virtualhosts' does not quiesce virtual hosts
> ---
>
> Key: QPID-8167
> URL: https://issues.apache.org/jira/browse/QPID-8167
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3, 0.26, 0.28, 
> 0.32, qpid-java-6.0.8
>Reporter: Alex Rudyy
>Priority: Major
>
> When command line option '-mmqv/--management-mode-quiesce-virtualhosts' is 
> set to true and management mode is requested to start the broker, the 
> existing virtual hosts are not  started in QUIESCED state. Their state remain 
> ACTIVE. 
> It seems this issue exists since introduction of virtual host nodes. 
> {{ManagementModeStoreHandler}} is looking for the entries of type 
> {{VirtualHost }} but such types are not stored in the broker configuration 
> store anymore.
> Either we need to re-purpose this option to quiesce virtual host nodes, or, 
> remove it completely.



--
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-8172) [Broker-J] OAuth2 authentication provider should not mandate setting of client secret

2018-05-02 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/QPID-8172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16461725#comment-16461725
 ] 

ASF subversion and git services commented on QPID-8172:
---

Commit d2589bf40a1bf352ddced315a4fd93c3560c0396 in qpid-broker-j's branch 
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=d2589bf ]

QPID-8172: [Broker-J] Fix failing test


> [Broker-J] OAuth2 authentication provider should not mandate setting of 
> client secret
> -
>
> Key: QPID-8172
> URL: https://issues.apache.org/jira/browse/QPID-8172
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3
>Reporter: Alex Rudyy
>Assignee: Keith Wall
>Priority: Major
>
> The current implementation of OAuth2 authentication provider requires 
> specifying "client secret". However, the client secret can be an empty string 
> and can even be omitted in the request if it is empty. As per 
> [RFC6749|https://tools.ietf.org/html/rfc6749], section "2.3.1.  Client 
> Password":
> {quote}
> client_secret
>  REQUIRED.  The client secret.  The client MAY omit the
>  parameter if the client secret is an empty string.
> {quote}
> Thus, OAuth2 authentication provider should not mandate setting of client 
> secret.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Closed] (PROTON-1638) Need to improve proton-c build tree layout

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed PROTON-1638.
---
   Resolution: Duplicate
Fix Version/s: (was: proton-c-0.23.0)

> Need to improve proton-c build tree layout
> --
>
> Key: PROTON-1638
> URL: https://issues.apache.org/jira/browse/PROTON-1638
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Andrew Stitcher
>Assignee: Justin Ross
>Priority: Major
>
> The proton-c tree layout is annoying in a number of ways:
> * Since the split with proton-j there is a superfluous top level
> * CMake build flags don't propagate properly because examples are not in the 
> correct subtree
> ** Examples should be in the binding subtree that they are examples
> ** Otherwise the information for a particular binding and its examples are 
> split into 2 different parts of the proton-c tree.
> ** This means that the installation for a binding is split
> ** It is unatural in CMake to split build flags like this - CMake is 
> hierarchical



--
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-1638) Need to improve proton-c build tree layout

2018-05-02 Thread Justin Ross (JIRA)

[ 
https://issues.apache.org/jira/browse/PROTON-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16461692#comment-16461692
 ] 

Justin Ross commented on PROTON-1638:
-

[~jdanek], regarding your comment above about C++ IDEs, would you double check 
as Andrew suggests, and if this remains an issue, raise it separately.  I'm 
going to close this one as a duplicate of PROTON-1728.

> Need to improve proton-c build tree layout
> --
>
> Key: PROTON-1638
> URL: https://issues.apache.org/jira/browse/PROTON-1638
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Andrew Stitcher
>Assignee: Justin Ross
>Priority: Major
> Fix For: proton-c-0.23.0
>
>
> The proton-c tree layout is annoying in a number of ways:
> * Since the split with proton-j there is a superfluous top level
> * CMake build flags don't propagate properly because examples are not in the 
> correct subtree
> ** Examples should be in the binding subtree that they are examples
> ** Otherwise the information for a particular binding and its examples are 
> split into 2 different parts of the proton-c tree.
> ** This means that the installation for a binding is split
> ** It is unatural in CMake to split build flags like this - CMake is 
> hierarchical



--
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] (PROTON-1638) Need to improve proton-c build tree layout

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1638:

Fix Version/s: proton-c-0.23.0

> Need to improve proton-c build tree layout
> --
>
> Key: PROTON-1638
> URL: https://issues.apache.org/jira/browse/PROTON-1638
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Andrew Stitcher
>Assignee: Justin Ross
>Priority: Major
> Fix For: proton-c-0.23.0
>
>
> The proton-c tree layout is annoying in a number of ways:
> * Since the split with proton-j there is a superfluous top level
> * CMake build flags don't propagate properly because examples are not in the 
> correct subtree
> ** Examples should be in the binding subtree that they are examples
> ** Otherwise the information for a particular binding and its examples are 
> split into 2 different parts of the proton-c tree.
> ** This means that the installation for a binding is split
> ** It is unatural in CMake to split build flags like this - CMake is 
> hierarchical



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Closed] (PROTON-1613) Default value for Messenger::recv is -1, not 2048

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross closed PROTON-1613.
---
Resolution: Won't Fix

> Default value for Messenger::recv is -1, not 2048
> -
>
> Key: PROTON-1613
> URL: https://issues.apache.org/jira/browse/PROTON-1613
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: examples
>Affects Versions: proton-c-0.17.0
>Reporter: Jiri Daněk
>Priority: Trivial
>  Labels: messenger, patch
>
> {code}
> diff --git a/tests/javascript/msgr-recv.js b/tests/javascript/msgr-recv.js
> index 24bdcae7..f1353685 100755
> --- a/tests/javascript/msgr-recv.js
> +++ b/tests/javascript/msgr-recv.js
> @@ -191,7 +191,7 @@ if (typeof process === 'object' && typeof require === 
> 'function') {
>  'Usage: msgr-recv [OPTIONS]\n' +
>  ' -a [,]* \tAddresses to listen on [amqp://~0.0.0.0]\n' +
>  ' -c # \tNumber of messages to receive before exiting [0=forever]\n' +
> -' -b # \tArgument to Messenger::recv(n) [2048]\n' +
> +' -b # \tArgument to Messenger::recv(n) [-1]\n' +
>  ' -w # \tSize for incoming window [0]\n' +
>  ' -e # \t# seconds to report statistics, 0 = end of test [0] *TBD*\n' +
>  ' -R \tSend reply if \'reply-to\' present\n' +
> diff --git a/tests/tools/apps/c/msgr-recv.c b/tests/tools/apps/c/msgr-recv.c
> index eff5820c..b87f29a8 100644
> --- a/tests/tools/apps/c/msgr-recv.c
> +++ b/tests/tools/apps/c/msgr-recv.c
> @@ -52,7 +52,7 @@ static void usage(int rc)
>  printf("Usage: msgr-recv [OPTIONS] \n"
> " -a [,]* \tAddresses to listen on 
> [amqp://~0.0.0.0]\n"
> " -c # \tNumber of messages to receive before exiting 
> [0=forever]\n"
> -   " -b # \tArgument to Messenger::recv(n) [2048]\n"
> +   " -b # \tArgument to Messenger::recv(n) [-1]\n"
> " -w # \tSize for incoming window [0]\n"
> " -t # \tInactivity timeout in seconds, -1 = no timeout [-1]\n"
> " -e # \t# seconds to report statistics, 0 = end of test [0] 
> *TBD*\n"
> diff --git a/tests/tools/apps/python/msgr-recv.py 
> b/tests/tools/apps/python/msgr-recv.py
> index 757b19c2..52fe69c3 100755
> --- a/tests/tools/apps/python/msgr-recv.py
> +++ b/tests/tools/apps/python/msgr-recv.py
> @@ -34,7 +34,7 @@ usage = """
>  Usage: msgr-recv [OPTIONS]
>   -a [,]* \tAddresses to listen on [amqp://~0.0.0.0]
>   -c # \tNumber of messages to receive before exiting [0=forever]
> - -b # \tArgument to Messenger::recv(n) [2048]
> + -b # \tArgument to Messenger::recv(n) [-1]
>   -w # \tSize for incoming window [0]
>   -t # \tInactivity timeout in seconds, -1 = no timeout [-1]
>   -e # \t# seconds to report statistics, 0 = end of test [0] *TBD*
> {code}
> There may possibly be more discrepancies, I spotted and then was able to find 
> only this single one. The function in various bindings is usually not called 
> Messenger::recv...



--
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] (PROTON-1798) Installable tests for proton

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1798:

Summary: Installable tests for proton  (was: installable tests for proton)

> Installable tests for proton
> 
>
> Key: PROTON-1798
> URL: https://issues.apache.org/jira/browse/PROTON-1798
> Project: Qpid Proton
>  Issue Type: Test
>Affects Versions: proton-c-0.21.0
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
>  Labels: testing
> Fix For: proton-c-0.23.0
>
>
> Install test scripts so that self-tests can be run on an installed package, 
> without access to the source tree. These tests will be a separate install 
> group.
>  
> Initially the tests will consist of automatically building and running 
> installed examples, in future we can add unit tests etc. to the installed set.



--
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] (PROTON-1798) installable tests for proton

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1798:

Labels: testing  (was: )

> installable tests for proton
> 
>
> Key: PROTON-1798
> URL: https://issues.apache.org/jira/browse/PROTON-1798
> Project: Qpid Proton
>  Issue Type: Test
>Affects Versions: proton-c-0.21.0
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
>  Labels: testing
> Fix For: proton-c-0.23.0
>
>
> Install test scripts so that self-tests can be run on an installed package, 
> without access to the source tree. These tests will be a separate install 
> group.
>  
> Initially the tests will consist of automatically building and running 
> installed examples, in future we can add unit tests etc. to the installed set.



--
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] (PROTON-1709) [python] ApplicationEvent causing memory growth

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1709:

Summary: [python] ApplicationEvent causing memory growth  (was: Python 
binding: ApplicationEvent causing memory growth)

> [python] ApplicationEvent causing memory growth
> ---
>
> Key: PROTON-1709
> URL: https://issues.apache.org/jira/browse/PROTON-1709
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Affects Versions: proton-c-0.18.1
>Reporter: Xin Chen
>Assignee: Justin Ross
>Priority: Major
>  Labels: leak
>
> ApplicationEvent creates a new EventType object in the constructor. The 
> EventType object adds itself to the TYPES dict always, even for the same 
> typename. There is no way for the application to avoid this by providing an 
> EventType object directly. Repro code below:
> {code:java}
> import threading
> from proton.reactor import Container, ApplicationEvent, EventInjector
> class Program:
> def __init__(self, injector):
> self.injector = injector
> def on_reactor_init(self, event):
> event.reactor.selectable(self.injector)
> def on_hello(self, event):
> print(event.subject)
> def on_done(self, event):
> event.subject.stop()
> e = EventInjector()
> r = Container(Program(e))
> t = threading.Thread(target=r.run)
> t.start()
> for i in range(1, 1000):
> e.trigger(ApplicationEvent("hello", subject=str(i)))
> e.trigger(ApplicationEvent("done", subject=r))
> t.join()
> {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] [Updated] (PROTON-1647) [go] support for crypto.tls connections

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1647:

Labels: tls  (was: )

> [go] support for crypto.tls connections
> ---
>
> Key: PROTON-1647
> URL: https://issues.apache.org/jira/browse/PROTON-1647
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: go-binding
>Affects Versions: proton-c-0.18.0
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
>  Labels: tls
>
> The electron and proton Go bindings do not expose proton's built-in SSL layer 
> because Go provides it's own TLS layer in the crypto.tls package which is 
> more portable, capable and familiar to Go programmers.
> You can already use a tls.Conn with proton or electron, but there are several 
> points that should be cleaned up:
> - when a TLS connection is in use set allow-insecure-mechs in proton-C 
> automatically
> - make sure the AMQP virtual-host matches the TLS virtual-host by default
> - provide access to the net.Conn used by an electron.Connection, which in 
> turn will give access to TLS details if the user needs them
> - provide an example of using TLS (maybe with SASL PLAIN auth?)



--
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] (PROTON-1764) Slow performance seen when running Go client

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1764:

Labels: perf  (was: )

> Slow performance seen when running Go client
> 
>
> Key: PROTON-1764
> URL: https://issues.apache.org/jira/browse/PROTON-1764
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: go-binding
>Affects Versions: proton-c-0.18.1
>Reporter: Aaron Smith
>Assignee: Alan Conway
>Priority: Major
>  Labels: perf
>
> Slower than expected message deliver rate seen while running simple 
> benchmarking test.  Setup:
>   Client(Go) Sender -> QPID Router -> Client Receiver(Go)
> Profiling of reveals that a large percentage of time is spent in wrapper call 
> from Go to c.
> Not sure if the call to C from Go is the issue.
>  
> Here's the pointer for sender/receiver (both uses qpid go-binding).
> Sender (with '-limit' option, it sends AMQP messages in 10sec for 
> benchmarking):
>  
> [https://github.com/redhat-nfvpe/service-assurance-poc/tree/master/tools/sa-bench]
> Receiver (based on electron sample):
>  [http://kagaribi.s1061123.net/receive.go]
> Here are the results:
> {noformat}
> [root@nfvha-comp-01 sa-bench]# ./sa-bench -mode limit 
> amqp://127.0.0.1:5672/collectd/telemetry
> sending AMQP in 10 seconds...Done!
> Total: 171908 sent (duration:10.000103521s, mesg/sec: 17190.62204096157)
> [root@nfvha-comp-01 electron_sample]# ./receive -prefetch 12 
> amqp://127.0.0.1:5672/collectd/telemetry
> Listening on 1 connections
> ^C2018/02/15 01:44:51 Total: 171908 received.
> 2018/02/15 01:44:51 captured interrupt, stopping profiler and exiting...
> {noformat}
> Both program can collect profile data using '-pprofile' option as following:
> {noformat}
> [root@nfvha-comp-01 sa-bench]# ./sa-bench -mode limit -pprofile profile.out 
> amqp://127.0.0.1:5672/collectd/telemetry
> sending AMQP in 10 seconds...Done!
> Total: 189305 sent (duration:10.000111611s, mesg/sec: 18930.2887171546)
> [root@nfvha-comp-01 sa-bench]# go tool pprof sa-bench profile.out 
> File: sa-bench
> Build ID: 7ffec7b98a532892d7b9932b70b7451866cd4e5e
> Type: cpu
> Time: Feb 15, 2018 at 1:49am (EST)
> Duration: 10.11s, Total samples = 15.75s (155.79%)
> Entering interactive mode (type "help" for commands, "o" for options)
> (pprof) top5
> Showing nodes accounting for 9990ms, 63.43% of 15750ms total
> Dropped 200 nodes (cum <= 78.75ms)
> Showing top 5 nodes out of 144
>   flat  flat%   sum%cum   cum%
> 6750ms 42.86% 42.86% 7080ms 44.95%  runtime.cgocall 
> /usr/local/go/src/runtime/cgocall.go
> 1570ms  9.97% 52.83% 1590ms 10.10%  syscall.Syscall 
> /usr/local/go/src/syscall/asm_linux_amd64.s
>  800ms  5.08% 57.90%  800ms  5.08%  runtime.futex 
> /usr/local/go/src/runtime/sys_linux_amd64.s
>  440ms  2.79% 60.70%  770ms  4.89%  runtime.runqgrab 
> /usr/local/go/src/runtime/proc.go
>  430ms  2.73% 63.43% 1070ms  6.79%  runtime.selectgo 
> /usr/local/go/src/runtime/select.go
> [root@nfvha-comp-01 electron_sample]# ./receive -prefetch 12 -pprofile 
> profile.out amqp://127.0.0.1:5672/collectd/telemetry
> Listening on 1 connections
> ^C2018/02/15 01:49:25 Total: 181422 received.
> 2018/02/15 01:49:25 captured interrupt, stopping profiler and exiting...
> [root@nfvha-comp-01 electron_sample]# go tool pprof receive profile.out 
> File: receive
> Build ID: 66addd89d429ca678cbd6e336872bc604406f83e
> Type: cpu
> Time: Feb 15, 2018 at 1:49am (EST)
> Duration: 14.78s, Total samples = 16.60s (112.31%)
> Entering interactive mode (type "help" for commands, "o" for options)
> (pprof) top 5
> Showing nodes accounting for 10620ms, 63.98% of 16600ms total
> Dropped 160 nodes (cum <= 83ms)
> Showing top 5 nodes out of 124
>   flat  flat%   sum%cum   cum%
> 5730ms 34.52% 34.52% 5960ms 35.90%  runtime.cgocall 
> /usr/local/go/src/runtime/cgocall.go
> 2190ms 13.19% 47.71% 2220ms 13.37%  syscall.Syscall 
> /usr/local/go/src/syscall/asm_linux_amd64.s
> 1070ms  6.45% 54.16% 1070ms  6.45%  runtime.epollwait 
> /usr/local/go/src/runtime/sys_linux_amd64.s
>  860ms  5.18% 59.34% 4430ms 26.69%  runtime.findrunnable 
> /usr/local/go/src/runtime/proc.go
>  770ms  4.64% 63.98% 1130ms  6.81%  runtime.runqgrab 
> /usr/local/go/src/runtime/proc.go
> (pprof) {noformat}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Updated] (PROTON-1824) [python] Use of proton.Array causes SIGSEGV in Proton encoder

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1824:

Labels: codec crash  (was: codec)

> [python] Use of proton.Array causes SIGSEGV in Proton encoder
> -
>
> Key: PROTON-1824
> URL: https://issues.apache.org/jira/browse/PROTON-1824
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Reporter: Kim van der Riet
>Assignee: Andrew Stitcher
>Priority: Major
>  Labels: codec, crash
> Fix For: proton-c-future
>
> Attachments: simple_send.py
>
>
> Using proton.Array as a message body in Python 2.7 causes a segmentation 
> fault in Proton.
> A reproducer which is based on the Python examples simple_send.py is 
> attached. The trace (last seven frames only) is as follows:
> {noformat}
> (gdb) bt
> #0 0x7f54f71b27de in pn_encoder_writef32 (encoder=0x55f61e8602f0, 
> value=512110782) at /home/kvdr/RedHat/qpid-proton/c/src/core/encoder.c:183
> #1 0x7f54f71b3369 in pni_encoder_exit (ctx=0x55f61e8602f0, 
> data=0x55f61e85fd70, node=0x55f61e863a98) at 
> /home/kvdr/RedHat/qpid-proton/c/src/core/encoder.c:381
> #2 0x7f54f71af26f in pni_data_traverse (data=0x55f61e85fd70, 
> enter=0x7f54f71b2b8f , exit=0x7f54f71b31bd 
> , ctx=0x55f61e8602f0)
> at /home/kvdr/RedHat/qpid-proton/c/src/core/codec.c:1264
> #3 0x7f54f71b3417 in pn_encoder_encode (encoder=0x55f61e8602f0, 
> src=0x55f61e85fd70, dst=0x55f61e8630a0 "", size=16) at 
> /home/kvdr/RedHat/qpid-proton/c/src/core/encoder.c:401
> #4 0x7f54f71af925 in pn_data_encode (data=0x55f61e85fd70, 
> bytes=0x55f61e8630a0 "", size=16) at 
> /home/kvdr/RedHat/qpid-proton/c/src/core/codec.c:1441
> #5 0x7f54f71c693d in pn_message_encode (msg=0x55f61e84ec40, 
> bytes=0x55f61e8630a0 "", size=0x7fff60a71d10) at 
> /home/kvdr/RedHat/qpid-proton/c/src/core/message.c:764
> #6 0x7f54f742071c in _wrap_pn_message_encode (self=0x0, 
> args=0x7f54f2a2a440) at 
> /home/kvdr/RedHat/qpid-proton/build/python/cprotonPYTHON_wrap.c:4098
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Updated] (PROTON-1824) [python] Use of proton.Array causes SIGSEGV in Proton encoder

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1824:

Labels: codec  (was: )

> [python] Use of proton.Array causes SIGSEGV in Proton encoder
> -
>
> Key: PROTON-1824
> URL: https://issues.apache.org/jira/browse/PROTON-1824
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Reporter: Kim van der Riet
>Assignee: Andrew Stitcher
>Priority: Major
>  Labels: codec, crash
> Fix For: proton-c-future
>
> Attachments: simple_send.py
>
>
> Using proton.Array as a message body in Python 2.7 causes a segmentation 
> fault in Proton.
> A reproducer which is based on the Python examples simple_send.py is 
> attached. The trace (last seven frames only) is as follows:
> {noformat}
> (gdb) bt
> #0 0x7f54f71b27de in pn_encoder_writef32 (encoder=0x55f61e8602f0, 
> value=512110782) at /home/kvdr/RedHat/qpid-proton/c/src/core/encoder.c:183
> #1 0x7f54f71b3369 in pni_encoder_exit (ctx=0x55f61e8602f0, 
> data=0x55f61e85fd70, node=0x55f61e863a98) at 
> /home/kvdr/RedHat/qpid-proton/c/src/core/encoder.c:381
> #2 0x7f54f71af26f in pni_data_traverse (data=0x55f61e85fd70, 
> enter=0x7f54f71b2b8f , exit=0x7f54f71b31bd 
> , ctx=0x55f61e8602f0)
> at /home/kvdr/RedHat/qpid-proton/c/src/core/codec.c:1264
> #3 0x7f54f71b3417 in pn_encoder_encode (encoder=0x55f61e8602f0, 
> src=0x55f61e85fd70, dst=0x55f61e8630a0 "", size=16) at 
> /home/kvdr/RedHat/qpid-proton/c/src/core/encoder.c:401
> #4 0x7f54f71af925 in pn_data_encode (data=0x55f61e85fd70, 
> bytes=0x55f61e8630a0 "", size=16) at 
> /home/kvdr/RedHat/qpid-proton/c/src/core/codec.c:1441
> #5 0x7f54f71c693d in pn_message_encode (msg=0x55f61e84ec40, 
> bytes=0x55f61e8630a0 "", size=0x7fff60a71d10) at 
> /home/kvdr/RedHat/qpid-proton/c/src/core/message.c:764
> #6 0x7f54f742071c in _wrap_pn_message_encode (self=0x0, 
> args=0x7f54f2a2a440) at 
> /home/kvdr/RedHat/qpid-proton/build/python/cprotonPYTHON_wrap.c:4098
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Updated] (PROTON-1824) [python] Use of proton.Array causes SIGSEGV in Proton encoder

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1824:

Component/s: (was: proton-c)

> [python] Use of proton.Array causes SIGSEGV in Proton encoder
> -
>
> Key: PROTON-1824
> URL: https://issues.apache.org/jira/browse/PROTON-1824
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Reporter: Kim van der Riet
>Assignee: Andrew Stitcher
>Priority: Major
>  Labels: codec, crash
> Fix For: proton-c-future
>
> Attachments: simple_send.py
>
>
> Using proton.Array as a message body in Python 2.7 causes a segmentation 
> fault in Proton.
> A reproducer which is based on the Python examples simple_send.py is 
> attached. The trace (last seven frames only) is as follows:
> {noformat}
> (gdb) bt
> #0 0x7f54f71b27de in pn_encoder_writef32 (encoder=0x55f61e8602f0, 
> value=512110782) at /home/kvdr/RedHat/qpid-proton/c/src/core/encoder.c:183
> #1 0x7f54f71b3369 in pni_encoder_exit (ctx=0x55f61e8602f0, 
> data=0x55f61e85fd70, node=0x55f61e863a98) at 
> /home/kvdr/RedHat/qpid-proton/c/src/core/encoder.c:381
> #2 0x7f54f71af26f in pni_data_traverse (data=0x55f61e85fd70, 
> enter=0x7f54f71b2b8f , exit=0x7f54f71b31bd 
> , ctx=0x55f61e8602f0)
> at /home/kvdr/RedHat/qpid-proton/c/src/core/codec.c:1264
> #3 0x7f54f71b3417 in pn_encoder_encode (encoder=0x55f61e8602f0, 
> src=0x55f61e85fd70, dst=0x55f61e8630a0 "", size=16) at 
> /home/kvdr/RedHat/qpid-proton/c/src/core/encoder.c:401
> #4 0x7f54f71af925 in pn_data_encode (data=0x55f61e85fd70, 
> bytes=0x55f61e8630a0 "", size=16) at 
> /home/kvdr/RedHat/qpid-proton/c/src/core/codec.c:1441
> #5 0x7f54f71c693d in pn_message_encode (msg=0x55f61e84ec40, 
> bytes=0x55f61e8630a0 "", size=0x7fff60a71d10) at 
> /home/kvdr/RedHat/qpid-proton/c/src/core/message.c:764
> #6 0x7f54f742071c in _wrap_pn_message_encode (self=0x0, 
> args=0x7f54f2a2a440) at 
> /home/kvdr/RedHat/qpid-proton/build/python/cprotonPYTHON_wrap.c:4098
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Updated] (PROTON-1824) [python] Use of proton.Array causes SIGSEGV in Proton encoder

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1824:

Fix Version/s: proton-c-future

> [python] Use of proton.Array causes SIGSEGV in Proton encoder
> -
>
> Key: PROTON-1824
> URL: https://issues.apache.org/jira/browse/PROTON-1824
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Reporter: Kim van der Riet
>Assignee: Andrew Stitcher
>Priority: Major
>  Labels: codec, crash
> Fix For: proton-c-future
>
> Attachments: simple_send.py
>
>
> Using proton.Array as a message body in Python 2.7 causes a segmentation 
> fault in Proton.
> A reproducer which is based on the Python examples simple_send.py is 
> attached. The trace (last seven frames only) is as follows:
> {noformat}
> (gdb) bt
> #0 0x7f54f71b27de in pn_encoder_writef32 (encoder=0x55f61e8602f0, 
> value=512110782) at /home/kvdr/RedHat/qpid-proton/c/src/core/encoder.c:183
> #1 0x7f54f71b3369 in pni_encoder_exit (ctx=0x55f61e8602f0, 
> data=0x55f61e85fd70, node=0x55f61e863a98) at 
> /home/kvdr/RedHat/qpid-proton/c/src/core/encoder.c:381
> #2 0x7f54f71af26f in pni_data_traverse (data=0x55f61e85fd70, 
> enter=0x7f54f71b2b8f , exit=0x7f54f71b31bd 
> , ctx=0x55f61e8602f0)
> at /home/kvdr/RedHat/qpid-proton/c/src/core/codec.c:1264
> #3 0x7f54f71b3417 in pn_encoder_encode (encoder=0x55f61e8602f0, 
> src=0x55f61e85fd70, dst=0x55f61e8630a0 "", size=16) at 
> /home/kvdr/RedHat/qpid-proton/c/src/core/encoder.c:401
> #4 0x7f54f71af925 in pn_data_encode (data=0x55f61e85fd70, 
> bytes=0x55f61e8630a0 "", size=16) at 
> /home/kvdr/RedHat/qpid-proton/c/src/core/codec.c:1441
> #5 0x7f54f71c693d in pn_message_encode (msg=0x55f61e84ec40, 
> bytes=0x55f61e8630a0 "", size=0x7fff60a71d10) at 
> /home/kvdr/RedHat/qpid-proton/c/src/core/message.c:764
> #6 0x7f54f742071c in _wrap_pn_message_encode (self=0x0, 
> args=0x7f54f2a2a440) at 
> /home/kvdr/RedHat/qpid-proton/build/python/cprotonPYTHON_wrap.c:4098
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Updated] (PROTON-1824) [python] Use of proton.Array causes SIGSEGV in Proton encoder

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1824:

Summary: [python] Use of proton.Array causes SIGSEGV in Proton encoder  
(was: [Python binding] Use of proton.Array causes SIGSEGV in Proton encoder)

> [python] Use of proton.Array causes SIGSEGV in Proton encoder
> -
>
> Key: PROTON-1824
> URL: https://issues.apache.org/jira/browse/PROTON-1824
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Reporter: Kim van der Riet
>Assignee: Andrew Stitcher
>Priority: Major
>  Labels: codec, crash
> Fix For: proton-c-future
>
> Attachments: simple_send.py
>
>
> Using proton.Array as a message body in Python 2.7 causes a segmentation 
> fault in Proton.
> A reproducer which is based on the Python examples simple_send.py is 
> attached. The trace (last seven frames only) is as follows:
> {noformat}
> (gdb) bt
> #0 0x7f54f71b27de in pn_encoder_writef32 (encoder=0x55f61e8602f0, 
> value=512110782) at /home/kvdr/RedHat/qpid-proton/c/src/core/encoder.c:183
> #1 0x7f54f71b3369 in pni_encoder_exit (ctx=0x55f61e8602f0, 
> data=0x55f61e85fd70, node=0x55f61e863a98) at 
> /home/kvdr/RedHat/qpid-proton/c/src/core/encoder.c:381
> #2 0x7f54f71af26f in pni_data_traverse (data=0x55f61e85fd70, 
> enter=0x7f54f71b2b8f , exit=0x7f54f71b31bd 
> , ctx=0x55f61e8602f0)
> at /home/kvdr/RedHat/qpid-proton/c/src/core/codec.c:1264
> #3 0x7f54f71b3417 in pn_encoder_encode (encoder=0x55f61e8602f0, 
> src=0x55f61e85fd70, dst=0x55f61e8630a0 "", size=16) at 
> /home/kvdr/RedHat/qpid-proton/c/src/core/encoder.c:401
> #4 0x7f54f71af925 in pn_data_encode (data=0x55f61e85fd70, 
> bytes=0x55f61e8630a0 "", size=16) at 
> /home/kvdr/RedHat/qpid-proton/c/src/core/codec.c:1441
> #5 0x7f54f71c693d in pn_message_encode (msg=0x55f61e84ec40, 
> bytes=0x55f61e8630a0 "", size=0x7fff60a71d10) at 
> /home/kvdr/RedHat/qpid-proton/c/src/core/message.c:764
> #6 0x7f54f742071c in _wrap_pn_message_encode (self=0x0, 
> args=0x7f54f2a2a440) at 
> /home/kvdr/RedHat/qpid-proton/build/python/cprotonPYTHON_wrap.c:4098
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Updated] (PROTON-1833) [cpp] Crash on Windows after calling container::stop()

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1833:

Summary: [cpp] Crash on Windows after calling container::stop()  (was: 
qpid-proton cpp windows : Crash)

> [cpp] Crash on Windows after calling container::stop()
> --
>
> Key: PROTON-1833
> URL: https://issues.apache.org/jira/browse/PROTON-1833
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.21.0
> Environment: Proton version : 0.21
> Windows 7 - 64 bits
> Visual studio 2010
>Reporter: Baptiste
>Assignee: Cliff Jansen
>Priority: Critical
>  Labels: crash, windows
> Fix For: proton-c-0.23.0
>
>
> Just creating a proton::container, listening locally on 
> [0.0.0.0:5672|http://0.0.0.0:5672/] and then call stop() on the container and 
> getting outside of the scope (object is then destroy) => the crash happen.
>   Where does it crash ? In *win_iocp.c*, the line in red
> void pn_proactor_free(pn_proactor_t *p)
> {  
> {color:#ff}DeleteTimerQueueEx(p->timer_queue, 
> INVALID_HANDLE_VALUE){color};
> DeleteCriticalSection(>timer_lock);  
> DeleteCriticalSection(>bind_lock);  
> proactor_shutdown(p);  
> delete p->reaper; 
> WSACleanup();  
> pn_collector_free(p->collector);  
> free(p);
> }
>  
> NOTE:
> A lot of tests failed on windows :
> 1>  The following tests FAILED:
> 1>        8 - cpp-container_test (Failed)
> 1>       10 - cpp-reconnect_test (Failed)
> 1>       21 - c-proactor-tests (Failed)
> 1>       23 - c-example-tests (Failed)
> 1>       24 - cpp-example-container (Failed)
> 1>       25 - cpp-example-container-ssl (Failed)



--
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] (PROTON-1833) qpid-proton cpp windows : Crash

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1833:

Labels: crash windows  (was: )

> qpid-proton cpp windows : Crash
> ---
>
> Key: PROTON-1833
> URL: https://issues.apache.org/jira/browse/PROTON-1833
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.21.0
> Environment: Proton version : 0.21
> Windows 7 - 64 bits
> Visual studio 2010
>Reporter: Baptiste
>Assignee: Cliff Jansen
>Priority: Critical
>  Labels: crash, windows
> Fix For: proton-c-0.23.0
>
>
> Just creating a proton::container, listening locally on 
> [0.0.0.0:5672|http://0.0.0.0:5672/] and then call stop() on the container and 
> getting outside of the scope (object is then destroy) => the crash happen.
>   Where does it crash ? In *win_iocp.c*, the line in red
> void pn_proactor_free(pn_proactor_t *p)
> {  
> {color:#ff}DeleteTimerQueueEx(p->timer_queue, 
> INVALID_HANDLE_VALUE){color};
> DeleteCriticalSection(>timer_lock);  
> DeleteCriticalSection(>bind_lock);  
> proactor_shutdown(p);  
> delete p->reaper; 
> WSACleanup();  
> pn_collector_free(p->collector);  
> free(p);
> }
>  
> NOTE:
> A lot of tests failed on windows :
> 1>  The following tests FAILED:
> 1>        8 - cpp-container_test (Failed)
> 1>       10 - cpp-reconnect_test (Failed)
> 1>       21 - c-proactor-tests (Failed)
> 1>       23 - c-example-tests (Failed)
> 1>       24 - cpp-example-container (Failed)
> 1>       25 - cpp-example-container-ssl (Failed)



--
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] (PROTON-1813) [c] Session delivery-id sequence does not allow an arbitrary initial sequence value after reconnect

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1813:

Summary: [c] Session delivery-id sequence does not allow an arbitrary 
initial sequence value after reconnect  (was: Session delivery-id sequence does 
not allow an arbitrary initial sequence value after reconnect.)

> [c] Session delivery-id sequence does not allow an arbitrary initial sequence 
> value after reconnect
> ---
>
> Key: PROTON-1813
> URL: https://issues.apache.org/jira/browse/PROTON-1813
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.21.0
>Reporter: Chris Morgan
>Priority: Major
>
> The session->state.incoming_init flag is not reset when the 
> session->state.incoming delivery map is cleared on reconnect/failover. This 
> causes errors in the transport on incoming transfer frames when the remote 
> broker begins its delivery-id sequence at a value other then 0. This prevents 
> a broker which begins its delivery-id sequence at 1 to not be able to 
> reconnect. 



--
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] (PROTON-1834) [cpp] equality operator used on nested lists causes SIGABRT

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1834:

Summary: [cpp] equality operator used on nested lists causes SIGABRT  (was: 
[C++ binding] equality operator used on nested lists causes SIGABRT)

> [cpp] equality operator used on nested lists causes SIGABRT
> ---
>
> Key: PROTON-1834
> URL: https://issues.apache.org/jira/browse/PROTON-1834
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Reporter: Kim van der Riet
>Priority: Major
>  Labels: codec
> Attachments: test1.cpp
>
>
> Checking the equality of nested list {{[[], [3, "hello"]]}} causes a core 
> dump. However, if the list (as a {{proton::value}}) is created and checked 
> against itself, it works fine. However, if the list is assigned to a message 
> body and then compared with the original, then the equality cores. The 
> following is dumped from the attached reproducer:
> {noformat}
> #0  0x7f37f7bc7660 in raise () from /lib64/libc.so.6
> #1  0x7f37f7bc8c41 in abort () from /lib64/libc.so.6
> #2  0x7f37f853d025 in __gnu_cxx::__verbose_terminate_handler() () from 
> /lib64/libstdc++.so.6
> #3  0x7f37f853ac16 in __cxxabiv1::__terminate(void (*)()) () from 
> /lib64/libstdc++.so.6
> #4  0x7f37f853ac61 in std::terminate() () from /lib64/libstdc++.so.6
> #5  0x7f37f853aea4 in __cxa_throw () from /lib64/libstdc++.so.6
> #6  0x7f37f8caaa2b in proton::codec::decoder::pre_get 
> (this=this@entry=0x7fff4b7a6340) at 
> /home/kvdr/RedHat/qpid-proton/cpp/src/decoder.cpp:76
> #7  0x7f37f8c7 in proton::codec::decoder::next_type 
> (this=this@entry=0x7fff4b7a6340) at 
> /home/kvdr/RedHat/qpid-proton/cpp/src/decoder.cpp:104
> #8  0x7f37f8cbce39 in proton::(anonymous namespace)::compare_next (a=..., 
> b=...) at /home/kvdr/RedHat/qpid-proton/cpp/src/value.cpp:113
> #9  0x7f37f8cbd79b in proton::(anonymous namespace)::compare_container 
> (b=..., a=...) at /home/kvdr/RedHat/qpid-proton/cpp/src/value.cpp:97
> #10 proton::(anonymous namespace)::compare_next (a=..., b=...) at 
> /home/kvdr/RedHat/qpid-proton/cpp/src/value.cpp:123
> #11 0x7f37f8cbd937 in proton::(anonymous namespace)::compare (x=..., 
> y=...) at /home/kvdr/RedHat/qpid-proton/cpp/src/value.cpp:163
> #12 0x7f37f8cbdda7 in proton::operator== (x=..., y=...) at 
> /home/kvdr/RedHat/qpid-proton/cpp/src/value.cpp:176
> #13 0x0040169d in main ()
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Updated] (PROTON-1834) [C++ binding] equality operator used on nested lists causes SIGABRT

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1834:

Labels: codec  (was: )

> [C++ binding] equality operator used on nested lists causes SIGABRT
> ---
>
> Key: PROTON-1834
> URL: https://issues.apache.org/jira/browse/PROTON-1834
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Reporter: Kim van der Riet
>Priority: Major
>  Labels: codec
> Attachments: test1.cpp
>
>
> Checking the equality of nested list {{[[], [3, "hello"]]}} causes a core 
> dump. However, if the list (as a {{proton::value}}) is created and checked 
> against itself, it works fine. However, if the list is assigned to a message 
> body and then compared with the original, then the equality cores. The 
> following is dumped from the attached reproducer:
> {noformat}
> #0  0x7f37f7bc7660 in raise () from /lib64/libc.so.6
> #1  0x7f37f7bc8c41 in abort () from /lib64/libc.so.6
> #2  0x7f37f853d025 in __gnu_cxx::__verbose_terminate_handler() () from 
> /lib64/libstdc++.so.6
> #3  0x7f37f853ac16 in __cxxabiv1::__terminate(void (*)()) () from 
> /lib64/libstdc++.so.6
> #4  0x7f37f853ac61 in std::terminate() () from /lib64/libstdc++.so.6
> #5  0x7f37f853aea4 in __cxa_throw () from /lib64/libstdc++.so.6
> #6  0x7f37f8caaa2b in proton::codec::decoder::pre_get 
> (this=this@entry=0x7fff4b7a6340) at 
> /home/kvdr/RedHat/qpid-proton/cpp/src/decoder.cpp:76
> #7  0x7f37f8c7 in proton::codec::decoder::next_type 
> (this=this@entry=0x7fff4b7a6340) at 
> /home/kvdr/RedHat/qpid-proton/cpp/src/decoder.cpp:104
> #8  0x7f37f8cbce39 in proton::(anonymous namespace)::compare_next (a=..., 
> b=...) at /home/kvdr/RedHat/qpid-proton/cpp/src/value.cpp:113
> #9  0x7f37f8cbd79b in proton::(anonymous namespace)::compare_container 
> (b=..., a=...) at /home/kvdr/RedHat/qpid-proton/cpp/src/value.cpp:97
> #10 proton::(anonymous namespace)::compare_next (a=..., b=...) at 
> /home/kvdr/RedHat/qpid-proton/cpp/src/value.cpp:123
> #11 0x7f37f8cbd937 in proton::(anonymous namespace)::compare (x=..., 
> y=...) at /home/kvdr/RedHat/qpid-proton/cpp/src/value.cpp:163
> #12 0x7f37f8cbdda7 in proton::operator== (x=..., y=...) at 
> /home/kvdr/RedHat/qpid-proton/cpp/src/value.cpp:176
> #13 0x0040169d in main ()
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Updated] (PROTON-1835) [python] Use of Python dict for AMQP maps does not allow derived or related keys of the same value

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1835:

Summary: [python] Use of Python dict for AMQP maps does not allow derived 
or related keys of the same value  (was: [Python binding] Use of Python dict 
for AMQP maps does not allow derived or related keys of the same value)

> [python] Use of Python dict for AMQP maps does not allow derived or related 
> keys of the same value
> --
>
> Key: PROTON-1835
> URL: https://issues.apache.org/jira/browse/PROTON-1835
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Reporter: Kim van der Riet
>Priority: Major
>
> The AMQP map (expressed as a list) {{[binary(123), "hello", decimal128(123), 
> "world"]}} cannot be implemented in Python using the {{dict}} type. This 
> happens because {{proton.decimal}} is derived from {{bytes}}, and the 
> dictionary treats the keys as the same value and causes the first value to be 
> overwritten by the second:
> {noformat}
> >>> import proton
> >>> {b'123': 'hello', proton.decimal128(b'123'): 'world'}
> {'123': 'world'}
> {noformat}
> Using the {{[]}} operator to add the values one at a time to an empty 
> {{dict}} results in the same outcome. Even using related classes (ie both 
> derived from a common parent) don't work:
> {noformat}
> >>> import proton
> >>> class mybin(bytes):
> ... def __repr__(self):
> ... return 'mybin(%s)' % bytes.__repr__(self)
> ... 
> >>> {mybin(b'123'): 'hello', proton.decimal128(b'123'): 'world'}
> {mybin('123'): 'world'}
> {noformat}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Updated] (PROTON-1842) [c] Dispatch/Proton crashes when opening/closing connections

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1842:

Summary: [c] Dispatch/Proton crashes when opening/closing connections  
(was: Dispatch/Proton crashes when opening/closing connections)

> [c] Dispatch/Proton crashes when opening/closing connections
> 
>
> Key: PROTON-1842
> URL: https://issues.apache.org/jira/browse/PROTON-1842
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.22.0
>Reporter: Chuck Rolke
>Priority: Major
>
> Using proton cpp example code that is modified to open and close connections 
> by the thousands in the main loop and having the event loop short circuit any 
> messaging with:
> {{  void on_connection_open(proton::connection& c) {}}
> {{  c.close();}}
> {{  }}}
> and then directing this client example to a dispatch router 1.1.0. Eventually 
> (after 100,000 to 1,000,000 connection open/closes) the router crashes with:
> {{qdrouterd: /home/chug/git/qpid-proton/c/src/proactor/epoll.c:466: 
> wake_pop_front: Assertion `p->wakes_in_progress' failed.}}
> and with:
> {{qdrouterd: /home/chug/git/qpid-proton/c/src/proactor/epoll.c:2014: 
> proactor_do_epoll: Assertion `ee->type == PCONNECTION_TIMER' failed.}}
> This issue seems to happen only with qpid-dispatch accepting the open/close 
> event stream. Proton cpp example _server_direct_ and c example _direct_ work 
> properly with the same open/close event stream mounting into the 10s of 
> millions of connections.
> A core dump backtrace with the PCONNECTION_TIMER failure reads as:
> {{(gdb) bt}}
> {{#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51}}
> {{#1  0x7f795c712c41 in __GI_abort () at abort.c:79}}
> {{#2  0x7f795c709f7a in __assert_fail_base (fmt=0x7f795c85a260 
> "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", 
> assertion=assertion@entry=0x7f795d72e15a "ee->type == PCONNECTION_TIMER", }}
> {{    file=file@entry=0x7f795d72de98 
> "/home/chug/git/qpid-proton/c/src/proactor/epoll.c", line=line@entry=2014, }}
> {{    function=function@entry=0x7f795d72e320 <__PRETTY_FUNCTION__.6307> 
> "proactor_do_epoll") at assert.c:92}}
> {{#3  0x7f795c709ff2 in __GI___assert_fail (assertion=0x7f795d72e15a 
> "ee->type == PCONNECTION_TIMER", file=0x7f795d72de98 
> "/home/chug/git/qpid-proton/c/src/proactor/epoll.c", line=2014, }}
> {{    function=0x7f795d72e320 <__PRETTY_FUNCTION__.6307> "proactor_do_epoll") 
> at assert.c:101}}
> {{#4  0x7f795d72d29f in proactor_do_epoll (p=0x26b7310, can_block=true) 
> at /home/chug/git/qpid-proton/c/src/proactor/epoll.c:2014}}
> {{#5  0x7f795d72d30e in pn_proactor_wait (p=0x26b7310) at 
> /home/chug/git/qpid-proton/c/src/proactor/epoll.c:2030}}
> {{#6  0x7f795dbe89ad in thread_run (arg=0x26be750) at 
> /home/chug/git/qpid-dispatch/src/server.c:946}}
> {{#7  0x7f795d50e50b in start_thread (arg=0x7f794f486700) at 
> pthread_create.c:465}}
> {{#8  0x7f795c7d216f in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95}}
>  



--
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] (PROTON-1838) [python] proton.float32('inf') and proton.float32('-inf') fail during encoding on CentOS 7

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1838:

Fix Version/s: proton-c-future

> [python] proton.float32('inf') and proton.float32('-inf') fail during 
> encoding on CentOS 7
> --
>
> Key: PROTON-1838
> URL: https://issues.apache.org/jira/browse/PROTON-1838
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Reporter: Kim van der Riet
>Priority: Major
>  Labels: codec
> Fix For: proton-c-future
>
> Attachments: simple_send.py
>
>
> Using the special float values {{'inf'}} and {{'-inf'}} in a 
> {{proton.float32}} message body on CentOS 7 (both Python 2 and 3) result in 
> the following error:
> {noformat}
> [kvdr@rhm-x3550-05 ~]$ cat /etc/redhat-release 
> CentOS Linux release 7.4.1708 (Core) 
> [kvdr@rhm-x3550-05 ~]$ python --version
> Python 2.7.5
> [kvdr@rhm-x3550-05 ~]$ python3 --version
> Python 3.4.5
> [kvdr@rhm-x3550-05 ~]$ python simple_send.py -a localhost:8001/qit.examples
> Traceback (most recent call last):
>   File "simple_send.py", line 62, in 
> Container(Send(opts.address, opts.messages)).run()
>   File 
> "/var/lib/jenkins/workspace/install/lib64/proton/bindings/python/proton/reactor.py",
>  line 148, in run
> while self.process(): pass
>   File 
> "/var/lib/jenkins/workspace/install/lib64/proton/bindings/python/proton/reactor.py",
>  line 174, in process
> self._check_errors()
>   File 
> "/var/lib/jenkins/workspace/install/lib64/proton/bindings/python/proton/reactor.py",
>  line 170, in _check_errors
> _compat.raise_(exc, value, tb)
>   File 
> "/var/lib/jenkins/workspace/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 3478, in dispatch
> ev.dispatch(self.handler)
>   File 
> "/var/lib/jenkins/workspace/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 3390, in dispatch
> self.dispatch(h, type)
>   File 
> "/var/lib/jenkins/workspace/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 3387, in dispatch
> result = dispatch(handler, type.method, self)
>   File 
> "/var/lib/jenkins/workspace/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 3265, in dispatch
> return m(*args)
>   File 
> "/var/lib/jenkins/workspace/install/lib64/proton/bindings/python/proton/handlers.py",
>  line 41, in on_link_flow
> self.on_sendable(event)
>   File 
> "/var/lib/jenkins/workspace/install/lib64/proton/bindings/python/proton/handlers.py",
>  line 63, in on_sendable
> dispatch(self.delegate, 'on_sendable', event)
>   File 
> "/var/lib/jenkins/workspace/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 3265, in dispatch
> return m(*args)
>   File "simple_send.py", line 41, in on_sendable
> event.sender.send(msg)
>   File 
> "/var/lib/jenkins/workspace/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 2437, in send
> return obj.send(self, tag=tag)
>   File 
> "/var/lib/jenkins/workspace/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 540, in send
> encoded = self.encode()
>   File 
> "/var/lib/jenkins/workspace/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 523, in encode
> self._pre_encode()
>   File 
> "/var/lib/jenkins/workspace/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 267, in _pre_encode
> body.put_object(self.body)
>   File 
> "/var/lib/jenkins/workspace/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 1698, in put_object
> putter(self, obj)
>   File 
> "/var/lib/jenkins/workspace/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 1209, in put_float
> self._check(pn_data_put_float(self._data, f))
> OverflowError: in method 'pn_data_put_float', argument 2 of type 
> 'float'{noformat}
> and which can be observed by running the attached reproducer based on the 
> simple_send.py example. The use of float special value {{'NaN'}} does not 
> produce this error, however.
> This error does not occur on Fedora 27.



--
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] (PROTON-1838) [python] proton.float32('inf') and proton.float32('-inf') fail during encoding on CentOS 7

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1838:

Summary: [python] proton.float32('inf') and proton.float32('-inf') fail 
during encoding on CentOS 7  (was: [Python binding] proton.float32('inf') and 
proton.float32('-inf') fail during encoding on CentOS 7)

> [python] proton.float32('inf') and proton.float32('-inf') fail during 
> encoding on CentOS 7
> --
>
> Key: PROTON-1838
> URL: https://issues.apache.org/jira/browse/PROTON-1838
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Reporter: Kim van der Riet
>Priority: Major
>  Labels: codec
> Fix For: proton-c-future
>
> Attachments: simple_send.py
>
>
> Using the special float values {{'inf'}} and {{'-inf'}} in a 
> {{proton.float32}} message body on CentOS 7 (both Python 2 and 3) result in 
> the following error:
> {noformat}
> [kvdr@rhm-x3550-05 ~]$ cat /etc/redhat-release 
> CentOS Linux release 7.4.1708 (Core) 
> [kvdr@rhm-x3550-05 ~]$ python --version
> Python 2.7.5
> [kvdr@rhm-x3550-05 ~]$ python3 --version
> Python 3.4.5
> [kvdr@rhm-x3550-05 ~]$ python simple_send.py -a localhost:8001/qit.examples
> Traceback (most recent call last):
>   File "simple_send.py", line 62, in 
> Container(Send(opts.address, opts.messages)).run()
>   File 
> "/var/lib/jenkins/workspace/install/lib64/proton/bindings/python/proton/reactor.py",
>  line 148, in run
> while self.process(): pass
>   File 
> "/var/lib/jenkins/workspace/install/lib64/proton/bindings/python/proton/reactor.py",
>  line 174, in process
> self._check_errors()
>   File 
> "/var/lib/jenkins/workspace/install/lib64/proton/bindings/python/proton/reactor.py",
>  line 170, in _check_errors
> _compat.raise_(exc, value, tb)
>   File 
> "/var/lib/jenkins/workspace/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 3478, in dispatch
> ev.dispatch(self.handler)
>   File 
> "/var/lib/jenkins/workspace/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 3390, in dispatch
> self.dispatch(h, type)
>   File 
> "/var/lib/jenkins/workspace/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 3387, in dispatch
> result = dispatch(handler, type.method, self)
>   File 
> "/var/lib/jenkins/workspace/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 3265, in dispatch
> return m(*args)
>   File 
> "/var/lib/jenkins/workspace/install/lib64/proton/bindings/python/proton/handlers.py",
>  line 41, in on_link_flow
> self.on_sendable(event)
>   File 
> "/var/lib/jenkins/workspace/install/lib64/proton/bindings/python/proton/handlers.py",
>  line 63, in on_sendable
> dispatch(self.delegate, 'on_sendable', event)
>   File 
> "/var/lib/jenkins/workspace/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 3265, in dispatch
> return m(*args)
>   File "simple_send.py", line 41, in on_sendable
> event.sender.send(msg)
>   File 
> "/var/lib/jenkins/workspace/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 2437, in send
> return obj.send(self, tag=tag)
>   File 
> "/var/lib/jenkins/workspace/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 540, in send
> encoded = self.encode()
>   File 
> "/var/lib/jenkins/workspace/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 523, in encode
> self._pre_encode()
>   File 
> "/var/lib/jenkins/workspace/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 267, in _pre_encode
> body.put_object(self.body)
>   File 
> "/var/lib/jenkins/workspace/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 1698, in put_object
> putter(self, obj)
>   File 
> "/var/lib/jenkins/workspace/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 1209, in put_float
> self._check(pn_data_put_float(self._data, f))
> OverflowError: in method 'pn_data_put_float', argument 2 of type 
> 'float'{noformat}
> and which can be observed by running the attached reproducer based on the 
> simple_send.py example. The use of float special value {{'NaN'}} does not 
> produce this error, however.
> This error does not occur on Fedora 27.



--
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] (PROTON-1840) [cpp] Nested complex types fail compilation with "incomplete type" error

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1840:

Labels: codec  (was: )

> [cpp] Nested complex types fail compilation with "incomplete type" error
> 
>
> Key: PROTON-1840
> URL: https://issues.apache.org/jira/browse/PROTON-1840
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Reporter: Kim van der Riet
>Assignee: Alan Conway
>Priority: Major
>  Labels: codec
>
> When using nested complex types (for example, a list of maps or an array of 
> lists), the compiler fails to compile. For example, the following code 
> snippet (saved as {{ctt.cpp}}):
> {noformat}
> #include 
> #include 
> #include 
> int main(int, char**) {
> std::map m1 = {{uint8_t(0), "zero"}, 
> {uint8_t(1), "one"}};
> std::map m2 = {{true, "true"}, {false, 
> "false"}};
> std::vector > am = {m1, m2};
> proton::value pv = am;
> }{noformat}
> fails compilation with the following error:
> {noformat}
> In file included from install/include/proton/types.hpp:47:0,
> from ctt.cpp:3:
> install/include/proton/./codec/vector.hpp: In instantiation of 
> ‘proton::codec::encoder& proton::codec::operator<<(proton::codec::encoder&, 
> const std::vector<_Tp, _Alloc>&) [with T = std::map proton::value>; A = std::allocator >]’:
> install/include/proton/./value.hpp:84:11: required from ‘typename 
> proton::value::assignable::type 
> proton::value::operator=(const T&) [with T = 
> std::vector >; typename 
> proton::value::assignable::type = proton::value&]’
> install/include/proton/./value.hpp:79:85: required from 
> ‘proton::value::value(const T&, typename proton::value::assignable::type*) 
> [with T = std::vector >; typename 
> proton::value::assignable::type = void]’
> ctt.cpp:9:24: required from here
> install/include/proton/./codec/vector.hpp:39:31: error: incomplete type 
> ‘proton::internal::type_id_of >’ used 
> in nested name specifier
> return e << encoder::array(x, internal::type_id_of::value);
> ~~^~~
> {noformat}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Updated] (PROTON-1840) [cpp] Nested complex types fail compilation with "incomplete type" error

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1840:

Summary: [cpp] Nested complex types fail compilation with "incomplete type" 
error  (was: [C++ binding] Nested complex types fail compilation with 
"incomplete type" error)

> [cpp] Nested complex types fail compilation with "incomplete type" error
> 
>
> Key: PROTON-1840
> URL: https://issues.apache.org/jira/browse/PROTON-1840
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Reporter: Kim van der Riet
>Assignee: Alan Conway
>Priority: Major
>
> When using nested complex types (for example, a list of maps or an array of 
> lists), the compiler fails to compile. For example, the following code 
> snippet (saved as {{ctt.cpp}}):
> {noformat}
> #include 
> #include 
> #include 
> int main(int, char**) {
> std::map m1 = {{uint8_t(0), "zero"}, 
> {uint8_t(1), "one"}};
> std::map m2 = {{true, "true"}, {false, 
> "false"}};
> std::vector > am = {m1, m2};
> proton::value pv = am;
> }{noformat}
> fails compilation with the following error:
> {noformat}
> In file included from install/include/proton/types.hpp:47:0,
> from ctt.cpp:3:
> install/include/proton/./codec/vector.hpp: In instantiation of 
> ‘proton::codec::encoder& proton::codec::operator<<(proton::codec::encoder&, 
> const std::vector<_Tp, _Alloc>&) [with T = std::map proton::value>; A = std::allocator >]’:
> install/include/proton/./value.hpp:84:11: required from ‘typename 
> proton::value::assignable::type 
> proton::value::operator=(const T&) [with T = 
> std::vector >; typename 
> proton::value::assignable::type = proton::value&]’
> install/include/proton/./value.hpp:79:85: required from 
> ‘proton::value::value(const T&, typename proton::value::assignable::type*) 
> [with T = std::vector >; typename 
> proton::value::assignable::type = void]’
> ctt.cpp:9:24: required from here
> install/include/proton/./codec/vector.hpp:39:31: error: incomplete type 
> ‘proton::internal::type_id_of >’ used 
> in nested name specifier
> return e << encoder::array(x, internal::type_id_of::value);
> ~~^~~
> {noformat}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Updated] (PROTON-1800) BlockingConnection descriptor leak

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1800:

Fix Version/s: proton-c-future

> BlockingConnection descriptor leak
> --
>
> Key: PROTON-1800
> URL: https://issues.apache.org/jira/browse/PROTON-1800
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Affects Versions: proton-c-0.21.0
>Reporter: Andy Smith
>Priority: Major
>  Labels: leak, workaround
> Fix For: proton-c-future
>
> Attachments: sync_client.py
>
>
> Modified collectd python plugin from using persistent connection to 
> connection per read. Following change, detected descriptor leak.
> Attached modification to sync_client.py exhibits the issue.



--
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] (PROTON-1800) BlockingConnection descriptor leak

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1800:

Labels: leak workaround  (was: leak)

> BlockingConnection descriptor leak
> --
>
> Key: PROTON-1800
> URL: https://issues.apache.org/jira/browse/PROTON-1800
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Affects Versions: proton-c-0.21.0
>Reporter: Andy Smith
>Priority: Major
>  Labels: leak, workaround
> Attachments: sync_client.py
>
>
> Modified collectd python plugin from using persistent connection to 
> connection per read. Following change, detected descriptor leak.
> Attached modification to sync_client.py exhibits the issue.



--
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] (PROTON-1800) BlockingConnection descriptor leak

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1800:

Component/s: python-binding

> BlockingConnection descriptor leak
> --
>
> Key: PROTON-1800
> URL: https://issues.apache.org/jira/browse/PROTON-1800
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Affects Versions: proton-c-0.21.0
>Reporter: Andy Smith
>Priority: Major
>  Labels: leak, workaround
> Attachments: sync_client.py
>
>
> Modified collectd python plugin from using persistent connection to 
> connection per read. Following change, detected descriptor leak.
> Attached modification to sync_client.py exhibits the issue.



--
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] (PROTON-1800) BlockingConnection descriptor leak

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1800:

Labels: leak  (was: )

> BlockingConnection descriptor leak
> --
>
> Key: PROTON-1800
> URL: https://issues.apache.org/jira/browse/PROTON-1800
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Affects Versions: proton-c-0.21.0
>Reporter: Andy Smith
>Priority: Major
>  Labels: leak, workaround
> Attachments: sync_client.py
>
>
> Modified collectd python plugin from using persistent connection to 
> connection per read. Following change, detected descriptor leak.
> Attached modification to sync_client.py exhibits the issue.



--
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] (PROTON-1785) Port built-in performance tests to the proactor

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1785:

Component/s: proton-c

> Port built-in performance tests to the proactor
> ---
>
> Key: PROTON-1785
> URL: https://issues.apache.org/jira/browse/PROTON-1785
> Project: Qpid Proton
>  Issue Type: Task
>  Components: proton-c
>Reporter: Justin Ross
>Assignee: Cliff Jansen
>Priority: Major
>  Labels: testing
> Fix For: proton-c-future
>
>




--
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] (PROTON-1785) Port built-in performance tests to the proactor

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1785:

Fix Version/s: proton-c-future

> Port built-in performance tests to the proactor
> ---
>
> Key: PROTON-1785
> URL: https://issues.apache.org/jira/browse/PROTON-1785
> Project: Qpid Proton
>  Issue Type: Task
>  Components: proton-c
>Reporter: Justin Ross
>Assignee: Cliff Jansen
>Priority: Major
>  Labels: testing
> Fix For: proton-c-future
>
>




--
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] (PROTON-73) Server should force renegotiate when client authentication setting is changed on an active connection.

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-73:
--
Labels: security tls  (was: security ssl)

> Server should force renegotiate when client authentication setting is changed 
> on an active connection.
> --
>
> Key: PROTON-73
> URL: https://issues.apache.org/jira/browse/PROTON-73
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Minor
>  Labels: security, tls
> Fix For: proton-c-future
>
>
> If the server application changes the peer authentication setting from 
> 'anonymous' to 'verify-peer' while an SSL session is active, then the server 
> should force the client to re-negotiate (SSL handshake) to verify the 
> remote's identity.



--
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] (PROTON-890) adding subjectAltName (IP) support to proton-c 0.9.1

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-890:
---
Labels: patch tls  (was: patch ssl)

> adding subjectAltName (IP) support to proton-c 0.9.1
> 
>
> Key: PROTON-890
> URL: https://issues.apache.org/jira/browse/PROTON-890
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.9
> Environment: Ubuntu 12.04 x86-64
>Reporter: yanfeng liu
>Priority: Minor
>  Labels: patch, tls
> Fix For: proton-c-future
>
>
> Reproducing steps:
> 1) Run a broker with qpidd-cpp-0.32 runs SSL using a server certificate that 
> has IP type SAN like IP:192.168.164.130,IP:127.0.0.1 etc.
> 2) Run a qpid-0.32-cpp sample using SSL to connect to one of the broker's IP 
> address with trusted_certificate parameter specified. This works fine since 
> qpid-0.32-cpp samples can handle IP:x.x.x.x type SAN correctly.
> 3) Run a proton-c messenger API based sample with the same broker and 
> trusted_certificate and got error about SSL3 server certificate verification 
> failure due to specified server IP in AMQP URL doesn't appear in the SAN DNS 
> of the server certificate. 
> By checking the source code of verify_callback() in ssl/openssl.c, we can see 
> that only GEN_DNSNAME type is supported. With the code fragement below, we 
> can have GEN_IPADD supported as well:
> {code:title=ssl/openssl.c|borderStyle=solid}
>   if (name->type == GEN_IPADD) {
> ASN1_OCTET_STRING *asn1 = name->d.iPAddress;
> if (asn1 && asn1->data && asn1->length) {
>   unsigned char *str = (unsigned char *) asn1->data;
>   char ip[32];
>   int j=0;
>   while (jlength && strlen(ip) if (j==0) snprintf( ip, sizeof(ip), "%d" , str[j] );
> else snprintf( ip+strlen(ip), sizeof(ip)-strlen(ip),".%d",str[j] 
> );
> j++;
>   }
>   ssl_log(transport, "SubjectAltName (ip) from peer cert = '%s'", ip 
> );
>   matched = 
> (0==strcmp(ssl->peer_hostname,ip,strlen(ssl->peer_hostname)));
> }
>   }
> {code}
> Regards,
> yanfeng
>  
>   



--
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] (PROTON-523) Configurable SSLEngine

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-523:
---
Labels: tls  (was: ssl)

> Configurable SSLEngine
> --
>
> Key: PROTON-523
> URL: https://issues.apache.org/jira/browse/PROTON-523
> Project: Qpid Proton
>  Issue Type: New Feature
>  Components: proton-j
>Reporter: Piotr Kliczewski
>Priority: Major
>  Labels: tls
> Fix For: proton-j-future
>
>
> We need to configure SSLEngine using our own trust and key stores and 
> password for both.
> We propose following configuration options:
> - provide locations of stores and passwords
> - provide SSLContext
> - provide SSLEngine



--
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] (PROTON-162) SSL implementation does not support certification revocation

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-162:
---
Labels: security tls  (was: security ssl tls)

> SSL implementation does not support certification revocation
> 
>
> Key: PROTON-162
> URL: https://issues.apache.org/jira/browse/PROTON-162
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.3
>Reporter: Ken Giusti
>Priority: Major
>  Labels: security, tls
> Fix For: proton-c-future
>
>
> OpenSSL supports a means for configuring lists of revoked certificates.   The 
> SSL layer used by proton-c does not provide a means to configure this.



--
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] (PROTON-162) SSL implementation does not support certification revocation

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-162:
---
Labels: security ssl tls  (was: security ssl)

> SSL implementation does not support certification revocation
> 
>
> Key: PROTON-162
> URL: https://issues.apache.org/jira/browse/PROTON-162
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.3
>Reporter: Ken Giusti
>Priority: Major
>  Labels: security, tls
> Fix For: proton-c-future
>
>
> OpenSSL supports a means for configuring lists of revoked certificates.   The 
> SSL layer used by proton-c does not provide a means to configure this.



--
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] (PROTON-1674) [cpp] Container does no longer wait for planned scheduled tasks

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1674:

Labels: test testing  (was: test)

> [cpp] Container does no longer wait for planned scheduled tasks
> ---
>
> Key: PROTON-1674
> URL: https://issues.apache.org/jira/browse/PROTON-1674
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: proton-c-0.18.1
>Reporter: Jiri Daněk
>Assignee: Justin Ross
>Priority: Major
>  Labels: test, testing
>
> In the following test, what now seems to be happening is that the container 
> exits before the scheduled task is executed. Therefore, no exception is 
> thrown.
> {noformat}
> class MyException : public std::exception {};
> struct exception_from_scheduled_tester : public proton::messaging_handler {
> proton::listener listener;
> test_port port;
> bool should_stop;
> explicit exception_from_scheduled_tester(bool should_stop) : 
> should_stop(should_stop) {}
> void on_container_start(proton::container& c) PN_CPP_OVERRIDE {
> listener = c.listen(port.url());
> c.connect(port.url("localhost"));
> c.schedule(proton::duration(250), [this]() {
> throw MyException();
> });
> if (should_stop) {
> c.stop();
> }
> }
> };
> int test_container_scheduled_throws_exception() {
> exception_from_scheduled_tester t(/*should_stop*/ true);  // test would 
> pass if this is set to false
> proton::container c(t);
> try {
> c.run();
> FAIL("expected exception");
> } catch (proton::error ) {
> // expected
> }
> //t.listener.stop(); // uh, why am I not supposed to call this here?
> return 0;
> }
> {noformat}
> According to git bisect, the commit that changed the behavior (flipped the 
> test from pass to fail) is
> {noformat}
> % git bisect bad 
> 6e41df90023cfc06f4bc9ad7b972e9b39284980a is the first bad commit
> commit 6e41df90023cfc06f4bc9ad7b972e9b39284980a
> Author: Alan Conway 
> Date:   Mon Oct 23 17:24:10 2017 +0100
> PROTON-1628: [cpp] Stopping container in on_container_start will hang
> 
> Check if already stopping before entering the event loop in 
> container::impl::thread()
> :04 04 ffad13af832b4c8c9b15a75a146ba1cec302492f 
> 4bde1331bba40d477eefa383d78a95d49a291a90 M  proton-c
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Updated] (PROTON-1839) [cpp] Intermittent failure in container_test

2018-05-02 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1839:

Labels: testing  (was: )

> [cpp] Intermittent failure in container_test
> 
>
> Key: PROTON-1839
> URL: https://issues.apache.org/jira/browse/PROTON-1839
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Reporter: Justin Ross
>Priority: Major
>  Labels: testing
>
>  {noformat}
> 26/53 Test #26: cpp-value_test ... Passed 2.75 sec
> test 27 Start 27: cpp-container_test
> 27: Test command: /usr/bin/valgrind "--error-exitcode=42" "--quiet" 
> "--leak-check=full" "--trace-children=yes" 
> "--suppressions=/home/travis/build/apache/qpid-proton/c/tests/valgrind.supp" 
> "/home/travis/build/apache/qpid-proton/build/cpp/container_test" 
> 27: Test timeout computed to be: 1500 
> 27: TEST: test_container_default_container_id() 
> 27: TEST: test_container_vhost() 
> 27: TEST: test_container_default_vhost() 
> 27: TEST: test_container_no_vhost() 
> 27: TEST: test_container_bad_address() 
> 27: TEST: test_container_stop() 
> 27: TEST: test_container_schedule_nohang() 
> 27: TEST: test_container_immediate_stop() 
> 27: TEST: test_container_pre_stop() 
> 27: TEST: test_container_schedule_stop() 
> 27: TEST: test_container_mt_stop_empty() 
> 27: TEST: test_container_mt_stop() 
> 27: terminate called without an active exception
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Commented] (QPID-8141) [JMS AMQP 0-x] Cannot publish message with address based destinations falsely identified as resolved due to unset routing key and exchange name

2018-05-02 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/QPID-8141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16461651#comment-16461651
 ] 

ASF subversion and git services commented on QPID-8141:
---

Commit 6a5ffcf484c5bfab4b0e8ca3453baf9a7ba0c1c0 in qpid-jms-amqp-0-x's branch 
refs/heads/master from [~k-wall]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms-amqp-0-x.git;h=6a5ffcf ]

QPID-8141: [JMS AMQP 0-x] Avoid repeated exchange.declare when publishing when 
BURL address is in-use.


> [JMS AMQP 0-x] Cannot publish message with address based destinations falsely 
> identified as resolved due to unset routing key and exchange name
> ---
>
> Key: QPID-8141
> URL: https://issues.apache.org/jira/browse/QPID-8141
> Project: Qpid
>  Issue Type: Bug
>  Components: JMS AMQP 0-x
>Affects Versions: qpid-java-client-0-x-6.3.0
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-client-0-x-6.3.1
>
>
> Address based destination resolution functionality 
> {{AMQSession#resolveAddress}} sets a number of fields like {{routing key}}, 
> {{exchange name}}, etc as part of invocation of 
> {{AMQSession#setLegacyFieldsForQueueType}}. If destination object is 
> identified as resolved {{AMQSession#isResolved}} the essential fields are not 
> set on the destination object. As result, publishing attempts with such 
> destination objects will fail due to routing issues like the one reported 
> below:
> {noformat}
> Caused by: org.apache.qpid.AMQConnectionClosedException: Error: No route for 
> message with exchange 'null' and routing key 'null' [error code: 312(no 
> route)]
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>   at 
> org.apache.qpid.AMQException.cloneForCurrentThread(AMQException.java:81)
>   at 
> org.apache.qpid.AMQException.cloneForCurrentThread(AMQException.java:24)
>   at 
> org.apache.qpid.client.AMQProtocolHandler.writeCommandFrameAndWaitForReply(AMQProtocolHandler.java:638)
>   at 
> org.apache.qpid.client.AMQProtocolHandler.syncWrite(AMQProtocolHandler.java:675)
>   at 
> org.apache.qpid.client.AMQProtocolHandler.syncWrite(AMQProtocolHandler.java:669)
>   at 
> org.apache.qpid.client.AMQSession_0_8.commitImpl(AMQSession_0_8.java:271)
>   at org.apache.qpid.client.AMQSession.commit(AMQSession.java:913)
>   ... 6 more
> Caused by: org.apache.qpid.AMQConnectionClosedException: Error: No route for 
> message with exchange 'null' and routing key 'null' [error code: 312(no 
> route)]
>   at 
> org.apache.qpid.client.handler.ConnectionCloseMethodHandler.methodReceived(ConnectionCloseMethodHandler.java:90)
>   at 
> org.apache.qpid.client.handler.ClientMethodDispatcherImpl.dispatchConnectionClose(ClientMethodDispatcherImpl.java:227)
>   at 
> org.apache.qpid.framing.ConnectionCloseBody.execute(ConnectionCloseBody.java:105)
>   at 
> org.apache.qpid.client.state.AMQStateManager.methodReceived(AMQStateManager.java:118)
>   at 
> org.apache.qpid.client.AMQProtocolHandler.methodBodyReceived(AMQProtocolHandler.java:531)
>   at 
> org.apache.qpid.client.protocol.AMQProtocolSession.methodFrameReceived(AMQProtocolSession.java:460)
>   at 
> org.apache.qpid.framing.AMQMethodBodyImpl.handle(AMQMethodBodyImpl.java:66)
>   at 
> org.apache.qpid.client.AMQProtocolHandler.received(AMQProtocolHandler.java:480)
>   at 
> org.apache.qpid.client.AMQConnectionDelegate_8_0$ReceiverClosedWaiter.received(AMQConnectionDelegate_8_0.java:549)
>   at 
> org.apache.qpid.transport.network.io.IoReceiver.run(IoReceiver.java:164)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The clients applications creating new destination objects on every publishing 
> attempt using the same session are impacted by the issue.
> The following code snippet demonstrate the problem:
> {code}
> MessageProducer messageProducer = session.createProducer(null);
> for (int i=0;i {
> Message message = session.createTextMessage("Test");
> messageProducer.send(session.createQueue(String.format(
> 
> "ADDR:test;{\"create\":\"always\",\"node\":{\"type\":\"queue\",\"durable\":true}}")),
>  message);
> }
> session.commit();
> {code}
> The work around would be to avoid creation of destination objects every time. 
> For example, Qpid JNDI properties can be used to declare and cache the 
> destination 

[jira] [Commented] (QPID-8141) [JMS AMQP 0-x] Cannot publish message with address based destinations falsely identified as resolved due to unset routing key and exchange name

2018-05-02 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/QPID-8141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16461650#comment-16461650
 ] 

ASF subversion and git services commented on QPID-8141:
---

Commit a762b9d579dafb6c698a1d6076fb404ff1dfbe71 in qpid-jms-amqp-0-x's branch 
refs/heads/master from [~k-wall]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms-amqp-0-x.git;h=a762b9d ]

Revert "QPID-8141: [JMS AMQP 0-x] Return resolved destination from 
Session#createQueue/Session#createTopic if one exists"

This reverts commit e6657e12d7d99956a08d58181c7dd57e9521eb24.


> [JMS AMQP 0-x] Cannot publish message with address based destinations falsely 
> identified as resolved due to unset routing key and exchange name
> ---
>
> Key: QPID-8141
> URL: https://issues.apache.org/jira/browse/QPID-8141
> Project: Qpid
>  Issue Type: Bug
>  Components: JMS AMQP 0-x
>Affects Versions: qpid-java-client-0-x-6.3.0
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-client-0-x-6.3.1
>
>
> Address based destination resolution functionality 
> {{AMQSession#resolveAddress}} sets a number of fields like {{routing key}}, 
> {{exchange name}}, etc as part of invocation of 
> {{AMQSession#setLegacyFieldsForQueueType}}. If destination object is 
> identified as resolved {{AMQSession#isResolved}} the essential fields are not 
> set on the destination object. As result, publishing attempts with such 
> destination objects will fail due to routing issues like the one reported 
> below:
> {noformat}
> Caused by: org.apache.qpid.AMQConnectionClosedException: Error: No route for 
> message with exchange 'null' and routing key 'null' [error code: 312(no 
> route)]
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>   at 
> org.apache.qpid.AMQException.cloneForCurrentThread(AMQException.java:81)
>   at 
> org.apache.qpid.AMQException.cloneForCurrentThread(AMQException.java:24)
>   at 
> org.apache.qpid.client.AMQProtocolHandler.writeCommandFrameAndWaitForReply(AMQProtocolHandler.java:638)
>   at 
> org.apache.qpid.client.AMQProtocolHandler.syncWrite(AMQProtocolHandler.java:675)
>   at 
> org.apache.qpid.client.AMQProtocolHandler.syncWrite(AMQProtocolHandler.java:669)
>   at 
> org.apache.qpid.client.AMQSession_0_8.commitImpl(AMQSession_0_8.java:271)
>   at org.apache.qpid.client.AMQSession.commit(AMQSession.java:913)
>   ... 6 more
> Caused by: org.apache.qpid.AMQConnectionClosedException: Error: No route for 
> message with exchange 'null' and routing key 'null' [error code: 312(no 
> route)]
>   at 
> org.apache.qpid.client.handler.ConnectionCloseMethodHandler.methodReceived(ConnectionCloseMethodHandler.java:90)
>   at 
> org.apache.qpid.client.handler.ClientMethodDispatcherImpl.dispatchConnectionClose(ClientMethodDispatcherImpl.java:227)
>   at 
> org.apache.qpid.framing.ConnectionCloseBody.execute(ConnectionCloseBody.java:105)
>   at 
> org.apache.qpid.client.state.AMQStateManager.methodReceived(AMQStateManager.java:118)
>   at 
> org.apache.qpid.client.AMQProtocolHandler.methodBodyReceived(AMQProtocolHandler.java:531)
>   at 
> org.apache.qpid.client.protocol.AMQProtocolSession.methodFrameReceived(AMQProtocolSession.java:460)
>   at 
> org.apache.qpid.framing.AMQMethodBodyImpl.handle(AMQMethodBodyImpl.java:66)
>   at 
> org.apache.qpid.client.AMQProtocolHandler.received(AMQProtocolHandler.java:480)
>   at 
> org.apache.qpid.client.AMQConnectionDelegate_8_0$ReceiverClosedWaiter.received(AMQConnectionDelegate_8_0.java:549)
>   at 
> org.apache.qpid.transport.network.io.IoReceiver.run(IoReceiver.java:164)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The clients applications creating new destination objects on every publishing 
> attempt using the same session are impacted by the issue.
> The following code snippet demonstrate the problem:
> {code}
> MessageProducer messageProducer = session.createProducer(null);
> for (int i=0;i {
> Message message = session.createTextMessage("Test");
> messageProducer.send(session.createQueue(String.format(
> 
> "ADDR:test;{\"create\":\"always\",\"node\":{\"type\":\"queue\",\"durable\":true}}")),
>  message);
> }
> session.commit();
> {code}
> The work around would be to avoid creation of destination objects every time. 
> For 

[jira] [Created] (PROTON-1842) Dispatch/Proton crashes when opening/closing connections

2018-05-02 Thread Chuck Rolke (JIRA)
Chuck Rolke created PROTON-1842:
---

 Summary: Dispatch/Proton crashes when opening/closing connections
 Key: PROTON-1842
 URL: https://issues.apache.org/jira/browse/PROTON-1842
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Affects Versions: proton-c-0.22.0
Reporter: Chuck Rolke


Using proton cpp example code that is modified to open and close connections by 
the thousands in the main loop and having the event loop short circuit any 
messaging with:

{{  void on_connection_open(proton::connection& c) {}}
{{  c.close();}}
{{  }}}

and then directing this client example to a dispatch router 1.1.0. Eventually 
(after 100,000 to 1,000,000 connection open/closes) the router crashes with:

{{qdrouterd: /home/chug/git/qpid-proton/c/src/proactor/epoll.c:466: 
wake_pop_front: Assertion `p->wakes_in_progress' failed.}}

and with:

{{qdrouterd: /home/chug/git/qpid-proton/c/src/proactor/epoll.c:2014: 
proactor_do_epoll: Assertion `ee->type == PCONNECTION_TIMER' failed.}}

This issue seems to happen only with qpid-dispatch accepting the open/close 
event stream. Proton cpp example _server_direct_ and c example _direct_ work 
properly with the same open/close event stream mounting into the 10s of 
millions of connections.

A core dump backtrace with the PCONNECTION_TIMER failure reads as:

{{(gdb) bt}}
{{#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51}}
{{#1  0x7f795c712c41 in __GI_abort () at abort.c:79}}
{{#2  0x7f795c709f7a in __assert_fail_base (fmt=0x7f795c85a260 "%s%s%s:%u: 
%s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x7f795d72e15a 
"ee->type == PCONNECTION_TIMER", }}
{{    file=file@entry=0x7f795d72de98 
"/home/chug/git/qpid-proton/c/src/proactor/epoll.c", line=line@entry=2014, }}
{{    function=function@entry=0x7f795d72e320 <__PRETTY_FUNCTION__.6307> 
"proactor_do_epoll") at assert.c:92}}
{{#3  0x7f795c709ff2 in __GI___assert_fail (assertion=0x7f795d72e15a 
"ee->type == PCONNECTION_TIMER", file=0x7f795d72de98 
"/home/chug/git/qpid-proton/c/src/proactor/epoll.c", line=2014, }}
{{    function=0x7f795d72e320 <__PRETTY_FUNCTION__.6307> "proactor_do_epoll") 
at assert.c:101}}
{{#4  0x7f795d72d29f in proactor_do_epoll (p=0x26b7310, can_block=true) at 
/home/chug/git/qpid-proton/c/src/proactor/epoll.c:2014}}
{{#5  0x7f795d72d30e in pn_proactor_wait (p=0x26b7310) at 
/home/chug/git/qpid-proton/c/src/proactor/epoll.c:2030}}
{{#6  0x7f795dbe89ad in thread_run (arg=0x26be750) at 
/home/chug/git/qpid-dispatch/src/server.c:946}}
{{#7  0x7f795d50e50b in start_thread (arg=0x7f794f486700) at 
pthread_create.c:465}}
{{#8  0x7f795c7d216f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95}}

 



--
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] [Assigned] (PROTON-1841) [cpp] add missing ostream<< and to_string for proton::message

2018-05-02 Thread Alan Conway (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Conway reassigned PROTON-1841:
---

Assignee: Alan Conway

> [cpp] add missing ostream<< and to_string for proton::message
> -
>
> Key: PROTON-1841
> URL: https://issues.apache.org/jira/browse/PROTON-1841
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
> Fix For: proton-c-0.23.0
>
>
> proton::message lacks an ostream operator<< and to_string function, which are 
> provided for proton::value and most other types in the library. It can be 
> implemented using C pn_inspect.



--
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-1841) [cpp] add missing ostream<< and to_string for proton::message

2018-05-02 Thread Alan Conway (JIRA)
Alan Conway created PROTON-1841:
---

 Summary: [cpp] add missing ostream<< and to_string for 
proton::message
 Key: PROTON-1841
 URL: https://issues.apache.org/jira/browse/PROTON-1841
 Project: Qpid Proton
  Issue Type: Bug
  Components: cpp-binding
Affects Versions: proton-c-0.22.0
Reporter: Alan Conway
 Fix For: proton-c-0.23.0


proton::message lacks an ostream operator<< and to_string function, which are 
provided for proton::value and most other types in the library. It can be 
implemented using C pn_inspect.



--
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-8172) [Broker-J] OAuth2 authentication provider should not mandate setting of client secret

2018-05-02 Thread Alex Rudyy (JIRA)

 [ 
https://issues.apache.org/jira/browse/QPID-8172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8172:
-
Status: Reviewable  (was: In Progress)

> [Broker-J] OAuth2 authentication provider should not mandate setting of 
> client secret
> -
>
> Key: QPID-8172
> URL: https://issues.apache.org/jira/browse/QPID-8172
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
>
> The current implementation of OAuth2 authentication provider requires 
> specifying "client secret". However, the client secret can be an empty string 
> and can even be omitted in the request if it is empty. As per 
> [RFC6749|https://tools.ietf.org/html/rfc6749], section "2.3.1.  Client 
> Password":
> {quote}
> client_secret
>  REQUIRED.  The client secret.  The client MAY omit the
>  parameter if the client secret is an empty string.
> {quote}
> Thus, OAuth2 authentication provider should not mandate setting of client 
> secret.



--
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] [Assigned] (QPID-8172) [Broker-J] OAuth2 authentication provider should not mandate setting of client secret

2018-05-02 Thread Alex Rudyy (JIRA)

 [ 
https://issues.apache.org/jira/browse/QPID-8172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy reassigned QPID-8172:


Assignee: Keith Wall  (was: Alex Rudyy)

> [Broker-J] OAuth2 authentication provider should not mandate setting of 
> client secret
> -
>
> Key: QPID-8172
> URL: https://issues.apache.org/jira/browse/QPID-8172
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3
>Reporter: Alex Rudyy
>Assignee: Keith Wall
>Priority: Major
>
> The current implementation of OAuth2 authentication provider requires 
> specifying "client secret". However, the client secret can be an empty string 
> and can even be omitted in the request if it is empty. As per 
> [RFC6749|https://tools.ietf.org/html/rfc6749], section "2.3.1.  Client 
> Password":
> {quote}
> client_secret
>  REQUIRED.  The client secret.  The client MAY omit the
>  parameter if the client secret is an empty string.
> {quote}
> Thus, OAuth2 authentication provider should not mandate setting of client 
> secret.



--
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] [Assigned] (QPID-8172) [Broker-J] OAuth2 authentication provider should not mandate setting of client secret

2018-05-02 Thread Alex Rudyy (JIRA)

 [ 
https://issues.apache.org/jira/browse/QPID-8172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy reassigned QPID-8172:


Assignee: Alex Rudyy

> [Broker-J] OAuth2 authentication provider should not mandate setting of 
> client secret
> -
>
> Key: QPID-8172
> URL: https://issues.apache.org/jira/browse/QPID-8172
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
>
> The current implementation of OAuth2 authentication provider requires 
> specifying "client secret". However, the client secret can be an empty string 
> and can even be omitted in the request if it is empty. As per 
> [RFC6749|https://tools.ietf.org/html/rfc6749], section "2.3.1.  Client 
> Password":
> {quote}
> client_secret
>  REQUIRED.  The client secret.  The client MAY omit the
>  parameter if the client secret is an empty string.
> {quote}
> Thus, OAuth2 authentication provider should not mandate setting of client 
> secret.



--
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-8172) [Broker-J] OAuth2 authentication provider should not mandate setting of client secret

2018-05-02 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/QPID-8172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16461028#comment-16461028
 ] 

ASF subversion and git services commented on QPID-8172:
---

Commit 39bfa6a0c054bb746b0ea45402e8d8a2707895a1 in qpid-broker-j's branch 
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=39bfa6a ]

QPID-8172: [Broker-J] OAuth2 authentication provider should not mandate setting 
of client secret


> [Broker-J] OAuth2 authentication provider should not mandate setting of 
> client secret
> -
>
> Key: QPID-8172
> URL: https://issues.apache.org/jira/browse/QPID-8172
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3
>Reporter: Alex Rudyy
>Priority: Major
>
> The current implementation of OAuth2 authentication provider requires 
> specifying "client secret". However, the client secret can be an empty string 
> and can even be omitted in the request if it is empty. As per 
> [RFC6749|https://tools.ietf.org/html/rfc6749], section "2.3.1.  Client 
> Password":
> {quote}
> client_secret
>  REQUIRED.  The client secret.  The client MAY omit the
>  parameter if the client secret is an empty string.
> {quote}
> Thus, OAuth2 authentication provider should not mandate setting of client 
> secret.



--
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] (QPIDJMS-384) Add support for user user defined extensions to override client configuration

2018-05-02 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/QPIDJMS-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460993#comment-16460993
 ] 

ASF subversion and git services commented on QPIDJMS-384:
-

Commit b017a8ace187f215f954ac5dc5094265c2a7b804 in qpid-jms's branch 
refs/heads/master from [~gemmellr]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=b017a8a ]

QPIDJMS-384: push unsaved aspect of previous javadoc change


> Add support for user user defined extensions to override client configuration
> -
>
> Key: QPIDJMS-384
> URL: https://issues.apache.org/jira/browse/QPIDJMS-384
> Project: Qpid JMS
>  Issue Type: Improvement
>  Components: qpid-jms-client
>Affects Versions: 0.31.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Major
> Fix For: 0.32.0
>
>
> Implement a means of injecting user defined configuration overrides that 
> allow the client to query user code to obtain various configuration values 
> such as HTTP headers for WebSocket authentication of per connection login 
> credentials in failover scenarios. 



--
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] [Comment Edited] (QPID-8178) [Broker-J] [Websocket] Support authentication from bearer token carried by authentication header

2018-05-02 Thread Keith Wall (JIRA)

[ 
https://issues.apache.org/jira/browse/QPID-8178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460986#comment-16460986
 ] 

Keith Wall edited comment on QPID-8178 at 5/2/18 12:57 PM:
---

Yes, for the SASL case, I think presenting a EXTERNAL SASL is the appropriate 
choice.   I admit that I had rather conflated SASL EXTERNAL with SSL client 
auth, but having read the spec [1], I see that its use in this case would be an 
appropriate choice.

[1] https://tools.ietf.org/html/rfc4422#page-29


was (Author: k-wall):
Yes, for the SASL case, I think presenting a EXTERNAL SASL is the appropriate 
choice.   I admit that I had rather conflated SASL EXTERNAL with SSL client 
auth, but having read the spec, I see that its use in this case would be an 
appropriate choice.

> [Broker-J] [Websocket] Support authentication from bearer token carried by 
> authentication header
> 
>
> Key: QPID-8178
> URL: https://issues.apache.org/jira/browse/QPID-8178
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Minor
> Fix For: Future
>
>
> Broker-J's AMQP websocket support should be enhanced to accept a bearer token 
> from the websocket transport.  If present and the port is configured to use 
> an authentication provider that supports the XOAUTH-2 mechanism, the token 
> should be passed to the authentication provider so it can complete the 
> authentication process.



--
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-8178) [Broker-J] [Websocket] Support authentication from bearer token carried by authentication header

2018-05-02 Thread Keith Wall (JIRA)

[ 
https://issues.apache.org/jira/browse/QPID-8178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460986#comment-16460986
 ] 

Keith Wall commented on QPID-8178:
--

Yes, for the SASL case, I think presenting a EXTERNAL SASL is the appropriate 
choice.   I admit that I had rather conflated SASL EXTERNAL with SSL client 
auth, but having read the spec, I see that its use in this case would be an 
appropriate choice.

> [Broker-J] [Websocket] Support authentication from bearer token carried by 
> authentication header
> 
>
> Key: QPID-8178
> URL: https://issues.apache.org/jira/browse/QPID-8178
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Minor
> Fix For: Future
>
>
> Broker-J's AMQP websocket support should be enhanced to accept a bearer token 
> from the websocket transport.  If present and the port is configured to use 
> an authentication provider that supports the XOAUTH-2 mechanism, the token 
> should be passed to the authentication provider so it can complete the 
> authentication process.



--
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] [Comment Edited] (PROTON-1840) [C++ binding] Nested complex types fail compilation with "incomplete type" error

2018-05-02 Thread Robbie Gemmell (JIRA)

[ 
https://issues.apache.org/jira/browse/PROTON-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460854#comment-16460854
 ] 

Robbie Gemmell edited comment on PROTON-1840 at 5/2/18 10:42 AM:
-

Cloned from its original PROTON-1831 key as it was inadvertently spammed with 
unrelated commit and discussion comments for PROTON-1832 and so has now been 
updated to reflect its part of PROTON-1832


was (Author: gemmellr):
Cloned from its original reporting as PROTON-1831 as it was inadvertently 
spammed with unrelated commit and discussion comments for PROTON-1832.

> [C++ binding] Nested complex types fail compilation with "incomplete type" 
> error
> 
>
> Key: PROTON-1840
> URL: https://issues.apache.org/jira/browse/PROTON-1840
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Reporter: Kim van der Riet
>Assignee: Alan Conway
>Priority: Major
>
> When using nested complex types (for example, a list of maps or an array of 
> lists), the compiler fails to compile. For example, the following code 
> snippet (saved as {{ctt.cpp}}):
> {noformat}
> #include 
> #include 
> #include 
> int main(int, char**) {
> std::map m1 = {{uint8_t(0), "zero"}, 
> {uint8_t(1), "one"}};
> std::map m2 = {{true, "true"}, {false, 
> "false"}};
> std::vector > am = {m1, m2};
> proton::value pv = am;
> }{noformat}
> fails compilation with the following error:
> {noformat}
> In file included from install/include/proton/types.hpp:47:0,
> from ctt.cpp:3:
> install/include/proton/./codec/vector.hpp: In instantiation of 
> ‘proton::codec::encoder& proton::codec::operator<<(proton::codec::encoder&, 
> const std::vector<_Tp, _Alloc>&) [with T = std::map proton::value>; A = std::allocator >]’:
> install/include/proton/./value.hpp:84:11: required from ‘typename 
> proton::value::assignable::type 
> proton::value::operator=(const T&) [with T = 
> std::vector >; typename 
> proton::value::assignable::type = proton::value&]’
> install/include/proton/./value.hpp:79:85: required from 
> ‘proton::value::value(const T&, typename proton::value::assignable::type*) 
> [with T = std::vector >; typename 
> proton::value::assignable::type = void]’
> ctt.cpp:9:24: required from here
> install/include/proton/./codec/vector.hpp:39:31: error: incomplete type 
> ‘proton::internal::type_id_of >’ used 
> in nested name specifier
> return e << encoder::array(x, internal::type_id_of::value);
> ~~^~~
> {noformat}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Commented] (PROTON-1840) [C++ binding] Nested complex types fail compilation with "incomplete type" error

2018-05-02 Thread Robbie Gemmell (JIRA)

[ 
https://issues.apache.org/jira/browse/PROTON-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460854#comment-16460854
 ] 

Robbie Gemmell commented on PROTON-1840:


Cloned from its original reporting as PROTON-1831 as it was inadvertently 
spammed with unrelated commit and discussion comments for PROTON-1832.

> [C++ binding] Nested complex types fail compilation with "incomplete type" 
> error
> 
>
> Key: PROTON-1840
> URL: https://issues.apache.org/jira/browse/PROTON-1840
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Reporter: Kim van der Riet
>Assignee: Alan Conway
>Priority: Major
>
> When using nested complex types (for example, a list of maps or an array of 
> lists), the compiler fails to compile. For example, the following code 
> snippet (saved as {{ctt.cpp}}):
> {noformat}
> #include 
> #include 
> #include 
> int main(int, char**) {
> std::map m1 = {{uint8_t(0), "zero"}, 
> {uint8_t(1), "one"}};
> std::map m2 = {{true, "true"}, {false, 
> "false"}};
> std::vector > am = {m1, m2};
> proton::value pv = am;
> }{noformat}
> fails compilation with the following error:
> {noformat}
> In file included from install/include/proton/types.hpp:47:0,
> from ctt.cpp:3:
> install/include/proton/./codec/vector.hpp: In instantiation of 
> ‘proton::codec::encoder& proton::codec::operator<<(proton::codec::encoder&, 
> const std::vector<_Tp, _Alloc>&) [with T = std::map proton::value>; A = std::allocator >]’:
> install/include/proton/./value.hpp:84:11: required from ‘typename 
> proton::value::assignable::type 
> proton::value::operator=(const T&) [with T = 
> std::vector >; typename 
> proton::value::assignable::type = proton::value&]’
> install/include/proton/./value.hpp:79:85: required from 
> ‘proton::value::value(const T&, typename proton::value::assignable::type*) 
> [with T = std::vector >; typename 
> proton::value::assignable::type = void]’
> ctt.cpp:9:24: required from here
> install/include/proton/./codec/vector.hpp:39:31: error: incomplete type 
> ‘proton::internal::type_id_of >’ used 
> in nested name specifier
> return e << encoder::array(x, internal::type_id_of::value);
> ~~^~~
> {noformat}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Commented] (PROTON-1831) [c] duplicate link names cause invalid read in pn_transport_unbind_handles

2018-05-02 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/PROTON-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460849#comment-16460849
 ] 

ASF GitHub Bot commented on PROTON-1831:


Github user gemmellr commented on the issue:

https://github.com/apache/qpid-proton/pull/142
  
It seems you already committed this before Gordon and I commented, but 
neglected to close the PR with the commit or otherwise. It either needs 
closing, or the commit reverted, depending what your intent is after the 
comments.


> [c] duplicate link names cause invalid read in pn_transport_unbind_handles
> --
>
> Key: PROTON-1831
> URL: https://issues.apache.org/jira/browse/PROTON-1831
> Project: Qpid Proton
>  Issue Type: Bug
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
>
> See PROTON-1832 for the detail, this JIRA was inadvertently spammed with 
> comments for 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



[GitHub] qpid-proton issue #142: PROTON-1831: Incorrect open/close sequence for same ...

2018-05-02 Thread gemmellr
Github user gemmellr commented on the issue:

https://github.com/apache/qpid-proton/pull/142
  
It seems you already committed this before Gordon and I commented, but 
neglected to close the PR with the commit or otherwise. It either needs 
closing, or the commit reverted, depending what your intent is after the 
comments.


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Commented] (PROTON-1832) [c] duplicate link names cause invalid read in pn_transport_unbind_handles

2018-05-02 Thread Robbie Gemmell (JIRA)

[ 
https://issues.apache.org/jira/browse/PROTON-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460843#comment-16460843
 ] 

Robbie Gemmell commented on PROTON-1832:


Most of the commentary for this issue can actually be found on PROTON-1831.

> [c] duplicate link names cause invalid read in pn_transport_unbind_handles
> --
>
> Key: PROTON-1832
> URL: https://issues.apache.org/jira/browse/PROTON-1832
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.22.0
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
> Fix For: proton-c-0.23.0
>
>
> Proton has an invalid read error in pn_transport_unbind_handles under 
> specific circumstances where the same name is used to create 2 different 
> incoming links on the same session.
> This patch demonstrates
> {code:java}
> 1 file changed, 43 insertions(+), 2 deletions(-)
> c/tests/connection_driver.c | 45 +++--
> modified   c/tests/connection_driver.c
> @@ -48,6 +48,24 @@ static pn_event_type_t open_handler(test_handler_t *th, 
> pn_event_t *e) {
>    return PN_EVENT_NONE;
>  }
>  
> +/* Like open_handler but also reply to REMOTE_CLOSE */
> +static pn_event_type_t open_close_handler(test_handler_t *th, pn_event_t *e) 
> {
> +  switch (pn_event_type(e)) {
> +   case PN_CONNECTION_REMOTE_CLOSE:
> +    pn_connection_open(pn_event_connection(e));
> +    break;
> +   case PN_SESSION_REMOTE_CLOSE:
> +    pn_session_open(pn_event_session(e));
> +    break;
> +   case PN_LINK_REMOTE_CLOSE:
> +    pn_link_close(pn_event_link(e));
> +    break;
> +   default:
> +    return open_handler(th, e);
> +  }
> +  return PN_EVENT_NONE;
> +}
> +
>  /* Handler that returns control on PN_DELIVERY and stores the delivery on 
> the handler */
>  static pn_event_type_t delivery_handler(test_handler_t *th, pn_event_t *e) {
>    switch (pn_event_type(e)) {
> @@ -442,6 +458,30 @@ static void test_session_flow_control(test_t *t) {
>    test_connection_drivers_destroy(, );
>  }
>  
> +/* Regression test for crash caused by using the same name for multiple 
> links on same session. */
> +static void test_duplicate_link(test_t *t) {
> +  /* Set up the initial link */
> +  test_connection_driver_t client, server;
> +  test_connection_drivers_init(t, , open_close_handler, , 
> open_close_handler);
> +  pn_connection_open(client.driver.connection);
> +  pn_session_t *ssn = pn_session(client.driver.connection);
> +  pn_session_open(ssn);
> +  pn_link_t *x = pn_sender(ssn, "x");
> +  pn_link_open(x);
> +  /* Close the link and open a new link with same name.
> + NOTE: close and duplicate open must be in the same batch of events
> +  */
> +  pn_link_close(x);
> +  pn_link_open(pn_sender(ssn, "x"));
> +  test_connection_drivers_run(, );
> +  /* At this point the server has 2 handle map entries for the same link.
> + Freeing the link is correct, refcounting will keep it in memory,
> + but the extra handle map entry will cause a core dump in 
> pn_transport_unbind_handles
> +  */
> +  pn_link_free(server.handler.link);
> +  test_connection_drivers_destroy(, );
> +}
> +
>  int main(int argc, char **argv) {
>    int failed = 0;
>    RUN_ARGV_TEST(failed, t, test_message_transfer());
> @@ -449,5 +489,6 @@ int main(int argc, char **argv) {
>    RUN_ARGV_TEST(failed, t, test_message_abort());
>    RUN_ARGV_TEST(failed, t, test_message_abort_mixed());
>    RUN_ARGV_TEST(failed, t, test_session_flow_control());
> +  RUN_ARGV_TEST(failed, t, test_duplicate_link());
>    return failed;
>  }
> {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] [Resolved] (PROTON-1831) [c] duplicate link names cause invalid read in pn_transport_unbind_handles

2018-05-02 Thread Robbie Gemmell (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell resolved PROTON-1831.

Resolution: Done

> [c] duplicate link names cause invalid read in pn_transport_unbind_handles
> --
>
> Key: PROTON-1831
> URL: https://issues.apache.org/jira/browse/PROTON-1831
> Project: Qpid Proton
>  Issue Type: Bug
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
>
> See PROTON-1832 for the detail, this JIRA was inadvertently spammed with 
> comments for 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] [Updated] (PROTON-1831) [c] duplicate link names cause invalid read in pn_transport_unbind_handles

2018-05-02 Thread Robbie Gemmell (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-1831:
---
   Reporter: Alan Conway  (was: Kim van der Riet)
Description: See PROTON-1832 for the detail, this JIRA was inadvertently 
spammed with comments for it.  (was: When using nested complex types (for 
example, a list of maps or an array of lists), the compiler fails to compile. 
For example, the following code snippet (saved as {{ctt.cpp}}):
{noformat}
#include 
#include 
#include 

int main(int, char**) {
std::map m1 = {{uint8_t(0), "zero"}, 
{uint8_t(1), "one"}};
std::map m2 = {{true, "true"}, {false, 
"false"}};
std::vector > am = {m1, m2};
proton::value pv = am;
}{noformat}
fails compilation with the following error:
{noformat}
In file included from install/include/proton/types.hpp:47:0,
from ctt.cpp:3:
install/include/proton/./codec/vector.hpp: In instantiation of 
‘proton::codec::encoder& proton::codec::operator<<(proton::codec::encoder&, 
const std::vector<_Tp, _Alloc>&) [with T = std::map; A = std::allocator >]’:
install/include/proton/./value.hpp:84:11: required from ‘typename 
proton::value::assignable::type 
proton::value::operator=(const T&) [with T = 
std::vector >; typename 
proton::value::assignable::type = proton::value&]’
install/include/proton/./value.hpp:79:85: required from 
‘proton::value::value(const T&, typename proton::value::assignable::type*) 
[with T = std::vector >; typename 
proton::value::assignable::type = void]’
ctt.cpp:9:24: required from here
install/include/proton/./codec/vector.hpp:39:31: error: incomplete type 
‘proton::internal::type_id_of >’ used in 
nested name specifier
return e << encoder::array(x, internal::type_id_of::value);
~~^~~
{noformat}
 )

> [c] duplicate link names cause invalid read in pn_transport_unbind_handles
> --
>
> Key: PROTON-1831
> URL: https://issues.apache.org/jira/browse/PROTON-1831
> Project: Qpid Proton
>  Issue Type: Bug
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
>
> See PROTON-1832 for the detail, this JIRA was inadvertently spammed with 
> comments for 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] [Updated] (PROTON-1831) [c] duplicate link names cause invalid read in pn_transport_unbind_handles

2018-05-02 Thread Robbie Gemmell (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-1831:
---
Component/s: (was: cpp-binding)

> [c] duplicate link names cause invalid read in pn_transport_unbind_handles
> --
>
> Key: PROTON-1831
> URL: https://issues.apache.org/jira/browse/PROTON-1831
> Project: Qpid Proton
>  Issue Type: Bug
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
>
> See PROTON-1832 for the detail, this JIRA was inadvertently spammed with 
> comments for 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] [Updated] (PROTON-1831) [c] duplicate link names cause invalid read in pn_transport_unbind_handles

2018-05-02 Thread Robbie Gemmell (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-1831:
---
Summary: [c] duplicate link names cause invalid read in 
pn_transport_unbind_handles  (was: [C++ binding] Nested complex types fail 
compilation with "incomplete type" error)

> [c] duplicate link names cause invalid read in pn_transport_unbind_handles
> --
>
> Key: PROTON-1831
> URL: https://issues.apache.org/jira/browse/PROTON-1831
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Reporter: Kim van der Riet
>Assignee: Alan Conway
>Priority: Major
>
> When using nested complex types (for example, a list of maps or an array of 
> lists), the compiler fails to compile. For example, the following code 
> snippet (saved as {{ctt.cpp}}):
> {noformat}
> #include 
> #include 
> #include 
> int main(int, char**) {
> std::map m1 = {{uint8_t(0), "zero"}, 
> {uint8_t(1), "one"}};
> std::map m2 = {{true, "true"}, {false, 
> "false"}};
> std::vector > am = {m1, m2};
> proton::value pv = am;
> }{noformat}
> fails compilation with the following error:
> {noformat}
> In file included from install/include/proton/types.hpp:47:0,
> from ctt.cpp:3:
> install/include/proton/./codec/vector.hpp: In instantiation of 
> ‘proton::codec::encoder& proton::codec::operator<<(proton::codec::encoder&, 
> const std::vector<_Tp, _Alloc>&) [with T = std::map proton::value>; A = std::allocator >]’:
> install/include/proton/./value.hpp:84:11: required from ‘typename 
> proton::value::assignable::type 
> proton::value::operator=(const T&) [with T = 
> std::vector >; typename 
> proton::value::assignable::type = proton::value&]’
> install/include/proton/./value.hpp:79:85: required from 
> ‘proton::value::value(const T&, typename proton::value::assignable::type*) 
> [with T = std::vector >; typename 
> proton::value::assignable::type = void]’
> ctt.cpp:9:24: required from here
> install/include/proton/./codec/vector.hpp:39:31: error: incomplete type 
> ‘proton::internal::type_id_of >’ used 
> in nested name specifier
> return e << encoder::array(x, internal::type_id_of::value);
> ~~^~~
> {noformat}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Commented] (PROTON-1831) [C++ binding] Nested complex types fail compilation with "incomplete type" error

2018-05-02 Thread Robbie Gemmell (JIRA)

[ 
https://issues.apache.org/jira/browse/PROTON-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460834#comment-16460834
 ] 

Robbie Gemmell commented on PROTON-1831:


As the PR also had the wrong JIRA key in it and wasn't updated, none of the 
comments here relate to Kims originally reported issue.

I've cloned the original issue to PROTON-1840, look there instead for it.

> [C++ binding] Nested complex types fail compilation with "incomplete type" 
> error
> 
>
> Key: PROTON-1831
> URL: https://issues.apache.org/jira/browse/PROTON-1831
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Reporter: Kim van der Riet
>Assignee: Alan Conway
>Priority: Major
>
> When using nested complex types (for example, a list of maps or an array of 
> lists), the compiler fails to compile. For example, the following code 
> snippet (saved as {{ctt.cpp}}):
> {noformat}
> #include 
> #include 
> #include 
> int main(int, char**) {
> std::map m1 = {{uint8_t(0), "zero"}, 
> {uint8_t(1), "one"}};
> std::map m2 = {{true, "true"}, {false, 
> "false"}};
> std::vector > am = {m1, m2};
> proton::value pv = am;
> }{noformat}
> fails compilation with the following error:
> {noformat}
> In file included from install/include/proton/types.hpp:47:0,
> from ctt.cpp:3:
> install/include/proton/./codec/vector.hpp: In instantiation of 
> ‘proton::codec::encoder& proton::codec::operator<<(proton::codec::encoder&, 
> const std::vector<_Tp, _Alloc>&) [with T = std::map proton::value>; A = std::allocator >]’:
> install/include/proton/./value.hpp:84:11: required from ‘typename 
> proton::value::assignable::type 
> proton::value::operator=(const T&) [with T = 
> std::vector >; typename 
> proton::value::assignable::type = proton::value&]’
> install/include/proton/./value.hpp:79:85: required from 
> ‘proton::value::value(const T&, typename proton::value::assignable::type*) 
> [with T = std::vector >; typename 
> proton::value::assignable::type = void]’
> ctt.cpp:9:24: required from here
> install/include/proton/./codec/vector.hpp:39:31: error: incomplete type 
> ‘proton::internal::type_id_of >’ used 
> in nested name specifier
> return e << encoder::array(x, internal::type_id_of::value);
> ~~^~~
> {noformat}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Created] (PROTON-1840) [C++ binding] Nested complex types fail compilation with "incomplete type" error

2018-05-02 Thread Robbie Gemmell (JIRA)
Robbie Gemmell created PROTON-1840:
--

 Summary: [C++ binding] Nested complex types fail compilation with 
"incomplete type" error
 Key: PROTON-1840
 URL: https://issues.apache.org/jira/browse/PROTON-1840
 Project: Qpid Proton
  Issue Type: Bug
  Components: cpp-binding
Reporter: Kim van der Riet
Assignee: Alan Conway


When using nested complex types (for example, a list of maps or an array of 
lists), the compiler fails to compile. For example, the following code snippet 
(saved as {{ctt.cpp}}):
{noformat}
#include 
#include 
#include 

int main(int, char**) {
std::map m1 = {{uint8_t(0), "zero"}, 
{uint8_t(1), "one"}};
std::map m2 = {{true, "true"}, {false, 
"false"}};
std::vector > am = {m1, m2};
proton::value pv = am;
}{noformat}
fails compilation with the following error:
{noformat}
In file included from install/include/proton/types.hpp:47:0,
from ctt.cpp:3:
install/include/proton/./codec/vector.hpp: In instantiation of 
‘proton::codec::encoder& proton::codec::operator<<(proton::codec::encoder&, 
const std::vector<_Tp, _Alloc>&) [with T = std::map; A = std::allocator >]’:
install/include/proton/./value.hpp:84:11: required from ‘typename 
proton::value::assignable::type 
proton::value::operator=(const T&) [with T = 
std::vector >; typename 
proton::value::assignable::type = proton::value&]’
install/include/proton/./value.hpp:79:85: required from 
‘proton::value::value(const T&, typename proton::value::assignable::type*) 
[with T = std::vector >; typename 
proton::value::assignable::type = void]’
ctt.cpp:9:24: required from here
install/include/proton/./codec/vector.hpp:39:31: error: incomplete type 
‘proton::internal::type_id_of >’ used in 
nested name specifier
return e << encoder::array(x, internal::type_id_of::value);
~~^~~
{noformat}
 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Updated] (QPIDJMS-383) Utilize new proton-j APIs to eleminate copying delivery buffers

2018-05-02 Thread Robbie Gemmell (JIRA)

 [ 
https://issues.apache.org/jira/browse/QPIDJMS-383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated QPIDJMS-383:
---
Summary: Utilize new proton-j APIs to eleminate copying delivery buffers  
(was: Utilize new proton-j APIs to eleminate coping delivery buffers)

> Utilize new proton-j APIs to eleminate copying delivery buffers
> ---
>
> Key: QPIDJMS-383
> URL: https://issues.apache.org/jira/browse/QPIDJMS-383
> Project: Qpid JMS
>  Issue Type: Improvement
>  Components: qpid-jms-client
>Affects Versions: 0.31.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Major
> Fix For: 0.32.0
>
>
> Using newer send and receive APIs in proton-j 0.27.0 we can eliminate a copy 
> of the delivery bytes on both the send and receive side of delivery 
> processing.
>  



--
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-8178) [Broker-J] [Websocket] Support authentication from bearer token carried by authentication header

2018-05-02 Thread Rob Godfrey (JIRA)

[ 
https://issues.apache.org/jira/browse/QPID-8178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460690#comment-16460690
 ] 

Rob Godfrey commented on QPID-8178:
---

For this case, what would you expect the agreed SASL mechanism to be?  
Logically it is really EXTERNAL - the authentication context is carried 
external to the SASL exchange.  An OAUTH2 provider which offers EXTERNAL should 
therefore be looking for this token in the websocket transport rather than 
inspecting any client supplied cert.

> [Broker-J] [Websocket] Support authentication from bearer token carried by 
> authentication header
> 
>
> Key: QPID-8178
> URL: https://issues.apache.org/jira/browse/QPID-8178
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Minor
> Fix For: Future
>
>
> Broker-J's AMQP websocket support should be enhanced to accept a bearer token 
> from the websocket transport.  If present and the port is configured to use 
> an authentication provider that supports the XOAUTH-2 mechanism, the token 
> should be passed to the authentication provider so it can complete the 
> authentication process.



--
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] [Comment Edited] (QPID-8178) [Broker-J] [Websocket] Support authentication from bearer token carried by authentication header

2018-05-02 Thread Keith Wall (JIRA)

[ 
https://issues.apache.org/jira/browse/QPID-8178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460636#comment-16460636
 ] 

Keith Wall edited comment on QPID-8178 at 5/2/18 7:44 AM:
--

It could work in a similar way to the non-SASL external authentication 
(org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl#processProtocolHeader).
  In this case, the transport would provide the token rather than a peer 
principal. 


was (Author: k-wall):
It could work in a similar way to the external authentication 
(org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl#processProtocolHeader).
  In this case, the transport would provide the token rather than a peer 
principal. 

> [Broker-J] [Websocket] Support authentication from bearer token carried by 
> authentication header
> 
>
> Key: QPID-8178
> URL: https://issues.apache.org/jira/browse/QPID-8178
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Minor
> Fix For: Future
>
>
> Broker-J's AMQP websocket support should be enhanced to accept a bearer token 
> from the websocket transport.  If present and the port is configured to use 
> an authentication provider that supports the XOAUTH-2 mechanism, the token 
> should be passed to the authentication provider so it can complete the 
> authentication process.



--
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-8178) [Broker-J] [Websocket] Support authentication from bearer token carried by authentication header

2018-05-02 Thread Keith Wall (JIRA)

[ 
https://issues.apache.org/jira/browse/QPID-8178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460636#comment-16460636
 ] 

Keith Wall commented on QPID-8178:
--

It could work in a similar way to the external authentication 
(org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl#processProtocolHeader).
  In this case, the transport would provide the token rather than a peer 
principal. 

> [Broker-J] [Websocket] Support authentication from bearer token carried by 
> authentication header
> 
>
> Key: QPID-8178
> URL: https://issues.apache.org/jira/browse/QPID-8178
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Minor
> Fix For: Future
>
>
> Broker-J's AMQP websocket support should be enhanced to accept a bearer token 
> from the websocket transport.  If present and the port is configured to use 
> an authentication provider that supports the XOAUTH-2 mechanism, the token 
> should be passed to the authentication provider so it can complete the 
> authentication process.



--
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] (QPID-8178) [Broker-J] [Websocket] Support authentication from bearer token carried by authentication header

2018-05-02 Thread Keith Wall (JIRA)
Keith Wall created QPID-8178:


 Summary: [Broker-J] [Websocket] Support authentication from bearer 
token carried by authentication header
 Key: QPID-8178
 URL: https://issues.apache.org/jira/browse/QPID-8178
 Project: Qpid
  Issue Type: Improvement
  Components: Broker-J
Reporter: Keith Wall
 Fix For: Future


Broker-J's AMQP websocket support should be enhanced to accept a bearer token 
from the websocket transport.  If present and the port is configured to use an 
authentication provider that supports the XOAUTH-2 mechanism, the token should 
be passed to the authentication provider so it can complete the authentication 
process.




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