date:20170919

[jira] [Updated] (QPID-6641) [Windows C++] WinSDK scripts do not suppport VS2013 and recent Boost releases

2017-09-19 Thread Justin Ross (JIRA)


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

Justin Ross updated QPID-6641:
--
Labels: windows  (was: )

> [Windows C++] WinSDK scripts do not suppport VS2013 and recent Boost releases
> -
>
> Key: QPID-6641
> URL: https://issues.apache.org/jira/browse/QPID-6641
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Build
>Affects Versions: qpid-cpp-0.34
> Environment: Windows, WinSDK
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>  Labels: windows
>
> WinSDK build scripts need an update:
>  * VS2013
>  * Boost 1.58 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (QPID-7860) [cpp] Build produces deprecation warnings on recent Fedora

2017-09-19 Thread Justin Ross (JIRA)


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

Justin Ross updated QPID-7860:
--
Fix Version/s: (was: 1.37.0)
   qpid-cpp-1.37.0

> [cpp] Build produces deprecation warnings on recent Fedora
> --
>
> Key: QPID-7860
> URL: https://issues.apache.org/jira/browse/QPID-7860
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker, C++ Client
>Affects Versions: qpid-cpp-1.36.0
> Environment: Fedora 25
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Minor
>  Labels: patch
> Fix For: qpid-cpp-1.37.0
>
> Attachments: swig-deprecation.patch
>
>
> {noformat}
> -- Found SWIG: /usr/bin/swig (found version "3.0.11") 
> -- Found PythonLibs: /usr/lib64/libpython2.7.so (found version "2.7.13") 
> -- Found Perl: /usr/bin/perl (found version "5.24.1") 
> -- Found PerlLibs: /usr/lib64/libperl.so (found version "5.24.1") 
> -- Building Python bindings
> CMake Deprecation Warning at /usr/share/cmake/Modules/UseSWIG.cmake:226 
> (message):
>   SWIG_ADD_MODULE is deprecated.  Use SWIG_ADD_LIBRARY instead.
> Call Stack (most recent call first):
>   bindings/qpid/python/CMakeLists.txt:35 (swig_add_module)
> CMake Deprecation Warning at /usr/share/cmake/Modules/UseSWIG.cmake:226 
> (message):
>   SWIG_ADD_MODULE is deprecated.  Use SWIG_ADD_LIBRARY instead.
> Call Stack (most recent call first):
>   bindings/qmf2/python/CMakeLists.txt:35 (swig_add_module)
> -- Building Ruby bindings
> CMake Deprecation Warning at /usr/share/cmake/Modules/UseSWIG.cmake:226 
> (message):
>   SWIG_ADD_MODULE is deprecated.  Use SWIG_ADD_LIBRARY instead.
> Call Stack (most recent call first):
>   bindings/qpid/ruby/CMakeLists.txt:48 (swig_add_module)
> CMake Deprecation Warning at /usr/share/cmake/Modules/UseSWIG.cmake:226 
> (message):
>   SWIG_ADD_MODULE is deprecated.  Use SWIG_ADD_LIBRARY instead.
> Call Stack (most recent call first):
>   bindings/qmf2/ruby/CMakeLists.txt:39 (swig_add_module)
> -- Building Perl bindings
> CMake Deprecation Warning at /usr/share/cmake/Modules/UseSWIG.cmake:226 
> (message):
>   SWIG_ADD_MODULE is deprecated.  Use SWIG_ADD_LIBRARY instead.
> Call Stack (most recent call first):
>   bindings/qpid/perl/CMakeLists.txt:31 (swig_add_module)
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/jross/code/qpid-cpp/bld
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (QPID-6490) Configure SSL ciphers

2017-09-19 Thread Justin Ross (JIRA)


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

Justin Ross updated QPID-6490:
--
Issue Type: Improvement  (was: Bug)

> Configure SSL ciphers
> -
>
> Key: QPID-6490
> URL: https://issues.apache.org/jira/browse/QPID-6490
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Broker
>Affects Versions: 0.30
> Environment: Linux
>Reporter: Brant Knudson
>  Labels: security
>
> qpid-cpp must allow an admin to set the SSL ciphers / protocols that they 
> want the server to allow. The default should be ciphers / protocols that 
> don't have known security vulnerabilities like SSLv3 (POODLE) and RC4 ciphers 
> (Bar Mitzvah)
> With CVE-2015-2808 (a.k.a. Bar Mitzvah affecting RC4 ciphers) and other 
> recent vulnerabilities found in different ciphers / protocols, we need to be 
> able to disable ciphers / protocols easily.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (QPID-7895) [linearstore] Excessive CPU utilization for some kernel clocksources

2017-09-19 Thread Justin Ross (JIRA)


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

Justin Ross updated QPID-7895:
--
Fix Version/s: qpid-cpp-1.37.0

> [linearstore] Excessive CPU utilization for some kernel clocksources
> 
>
> Key: QPID-7895
> URL: https://issues.apache.org/jira/browse/QPID-7895
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
> Fix For: qpid-cpp-1.37.0
>
>
> For some kernel clocksources (eg acpi_pm), it has been observed that there is 
> an excessively high CPU utilization which correlates with the linearstore's 
> flush timeout being set to a very low value (100us).  This is a problem for 
> some customers which require almost instant flush to obtain 
> pseudo-synchronous store behavior (hence the 100us flush timer) and run many 
> brokers (up to hundreds) on a single machine.  In these cases, the CPU is 
> 100% utilized.
> A check of the source shows that the flush timer is firing continuously, 
> irrespective of whether any disk I/O has taken place.
> It is proposed that a change to linearstore be made which will only run the 
> timer when needed (ie while there is content in the write buffers that needs 
> flushing).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-7895) [linearstore] Excessive CPU utilization for some kernel clocksources

2017-09-19 Thread Justin Ross (JIRA)


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

Justin Ross commented on QPID-7895:
---

[~kpvdr], what's the status of this?

> [linearstore] Excessive CPU utilization for some kernel clocksources
> 
>
> Key: QPID-7895
> URL: https://issues.apache.org/jira/browse/QPID-7895
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
> Fix For: qpid-cpp-1.37.0
>
>
> For some kernel clocksources (eg acpi_pm), it has been observed that there is 
> an excessively high CPU utilization which correlates with the linearstore's 
> flush timeout being set to a very low value (100us).  This is a problem for 
> some customers which require almost instant flush to obtain 
> pseudo-synchronous store behavior (hence the 100us flush timer) and run many 
> brokers (up to hundreds) on a single machine.  In these cases, the CPU is 
> 100% utilized.
> A check of the source shows that the flush timer is firing continuously, 
> irrespective of whether any disk I/O has taken place.
> It is proposed that a change to linearstore be made which will only run the 
> timer when needed (ie while there is content in the write buffers that needs 
> flushing).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (QPID-4280) clock_gettime not available on Mac OS X

2017-09-19 Thread Justin Ross (JIRA)


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

Justin Ross updated QPID-4280:
--
Labels: osx patch  (was: )

> clock_gettime not available on Mac OS X
> ---
>
> Key: QPID-4280
> URL: https://issues.apache.org/jira/browse/QPID-4280
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Affects Versions: 0.18
> Environment: Mac OS X
>Reporter: Nadilson Ferreira
>Priority: Critical
>  Labels: osx, patch
>
> Hi, 
> The clock_gettime is not provided in Mac OS X.
> Affected files:
> + src/qpid/sys/posix/Time.cpp



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-1556) [proton-cpp] ssl_client_options is not self-assignable

2017-09-19 Thread Justin Ross (JIRA)


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

Justin Ross updated PROTON-1556:

Fix Version/s: proton-c-0.18.0

> [proton-cpp] ssl_client_options is not self-assignable
> --
>
> Key: PROTON-1556
> URL: https://issues.apache.org/jira/browse/PROTON-1556
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Danek
>Assignee: Cliff Jansen
>Priority: Trivial
> Fix For: proton-c-0.18.0
>
> Attachments: report-7646dc.html
>
>
> {{ssl_client_options}} probably cannot be self-assigned. See the attached 
> report from clang-analyzer, which looks very plausible.
> The problem is that assuming {{x == *this}}, the assignment operator will 
> decref and then incref the same value. Assuming the reference count was {{1}} 
> to start with, there will be use-after-free.
> This probably does not matter that much in real-world code, but I found some 
> quotations that making self assignment work is really important in C++...
> {noformat}
> 58ssl_domain& internal::ssl_domain::operator=(const ssl_domain) {
> 59if (impl_) impl_->decref();
> 60impl_ = x.impl_;
> 61server_type_ = x.server_type_;
> 62if (impl_) impl_->incref();
> 63return *this;
> 64}
> {noformat}
> I believe the static analyzer is correct, because when I do not make any 
> changes to the {{examples/cpp/ssl}} example, Valgrind does not report errors 
> concerning the class, but if I add a {{ssl_cli = ssl_cli;}}, then I get
> {noformat}
> $ valgrind ./ssl -c 
> /home/jdanek/Work/repos/qpid-proton/examples/cpp/ssl_certs/
> ==4950== Memcheck, a memory error detector
> ==4950== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
> ==4950== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
> ==4950== Command: ./ssl -c 
> /home/jdanek/Work/repos/qpid-proton/examples/cpp/ssl_certs/
> ==4950== 
> ==4950== Invalid read of size 4
> ==4950==at 0x4E715CC: incref (ssl_domain.cpp:37)
> ==4950==by 0x4E715CC: 
> proton::internal::ssl_domain::operator=(proton::internal::ssl_domain const&) 
> (ssl_domain.cpp:62)
> ==4950==by 0x4032F0: operator= (ssl.hpp:172)
> ==4950==by 0x4032F0: main (ssl.cpp:176)
> ==4950==  Address 0x766a3c0 is 0 bytes inside a block of size 16 free'd
> ==4950==at 0x4C2D2EB: operator delete(void*) (in 
> /nix/store/gv9x2j31hvn0wf37h4jmb9xz6vgc3vvv-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==4950==by 0x4E715FA: decref (ssl_domain.cpp:40)
> ==4950==by 0x4E715FA: 
> proton::internal::ssl_domain::operator=(proton::internal::ssl_domain const&) 
> (ssl_domain.cpp:59)
> ==4950==by 0x4032F0: operator= (ssl.hpp:172)
> ==4950==by 0x4032F0: main (ssl.cpp:176)
> ==4950==  Block was alloc'd at
> ==4950==at 0x4C2C22F: operator new(unsigned long) (in 
> /nix/store/gv9x2j31hvn0wf37h4jmb9xz6vgc3vvv-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==4950==by 0x4E7166C: proton::internal::ssl_domain::pn_domain() 
> (ssl_domain.cpp:72)
> ==4950==by 0x4E7195C: 
> proton::ssl_client_options::ssl_client_options(std::__cxx11::basic_string  std::char_traits, std::allocator > const&, 
> proton::ssl::verify_mode) (ssl_domain.cpp:120)
> ==4950==by 0x4032B9: main (ssl.cpp:175)
> ==4950== 
> ==4950== Invalid read of size 4
> ==4950==at 0x4E71619: decref (ssl_domain.cpp:39)
> ==4950==by 0x4E71619: proton::internal::ssl_domain::~ssl_domain() 
> (ssl_domain.cpp:66)
> ==4950==by 0x4032F8: ~ssl_client_options (ssl.hpp:172)
> ==4950==by 0x4032F8: main (ssl.cpp:175)
> ==4950==  Address 0x766a3c0 is 0 bytes inside a block of size 16 free'd
> ==4950==at 0x4C2D2EB: operator delete(void*) (in 
> /nix/store/gv9x2j31hvn0wf37h4jmb9xz6vgc3vvv-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==4950==by 0x4E715FA: decref (ssl_domain.cpp:40)
> ==4950==by 0x4E715FA: 
> proton::internal::ssl_domain::operator=(proton::internal::ssl_domain const&) 
> (ssl_domain.cpp:59)
> ==4950==by 0x4032F0: operator= (ssl.hpp:172)
> ==4950==by 0x4032F0: main (ssl.cpp:176)
> ==4950==  Block was alloc'd at
> ==4950==at 0x4C2C22F: operator new(unsigned long) (in 
> /nix/store/gv9x2j31hvn0wf37h4jmb9xz6vgc3vvv-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==4950==by 0x4E7166C: proton::internal::ssl_domain::pn_domain() 
> (ssl_domain.cpp:72)
> ==4950==by 0x4E7195C: 
> proton::ssl_client_options::ssl_client_options(std::__cxx11::basic_string  std::char_traits, std::allocator > const&, 
> proton::ssl::verify_mode) (ssl_domain.cpp:120)
> ==4950==by 0x4032B9: main (ssl.cpp:175)
> ==4950== 
> ==4950== Invalid read of

[jira] [Created] (PROTON-1596) Add Cppcheck to standard build tooling

2017-09-19 Thread Justin Ross (JIRA)

Justin Ross created PROTON-1596:
---

 Summary: Add Cppcheck to standard build tooling
 Key: PROTON-1596
 URL: https://issues.apache.org/jira/browse/PROTON-1596
 Project: Qpid Proton
  Issue Type: Improvement
  Components: proton-c
Reporter: Justin Ross
 Fix For: proton-c-0.19.0


http://cppcheck.sourceforge.net/



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (PROTON-1595) Run Coverity against Proton C 0.18.0 release candidates

2017-09-19 Thread Justin Ross (JIRA)

Justin Ross created PROTON-1595:
---

 Summary: Run Coverity against Proton C 0.18.0 release candidates
 Key: PROTON-1595
 URL: https://issues.apache.org/jira/browse/PROTON-1595
 Project: Qpid Proton
  Issue Type: Task
  Components: proton-c
Reporter: Justin Ross
 Fix For: proton-c-0.18.0






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (PROTON-1594) Expose remote host and port on transport

2017-09-19 Thread Justin Ross (JIRA)

Justin Ross created PROTON-1594:
---

 Summary: Expose remote host and port on transport
 Key: PROTON-1594
 URL: https://issues.apache.org/jira/browse/PROTON-1594
 Project: Qpid Proton
  Issue Type: Improvement
  Components: cpp-binding
Affects Versions: proton-c-0.18.0
Reporter: Justin Ross
Assignee: Cliff Jansen
 Fix For: proton-c-0.19.0


So you can, for instance, log where you are connected to.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (PROTON-1593) Add timestamps to trace output

2017-09-19 Thread Justin Ross (JIRA)

Justin Ross created PROTON-1593:
---

 Summary: Add timestamps to trace output
 Key: PROTON-1593
 URL: https://issues.apache.org/jira/browse/PROTON-1593
 Project: Qpid Proton
  Issue Type: Improvement
  Components: proton-c
Affects Versions: proton-c-0.18.0
Reporter: Justin Ross
 Fix For: proton-c-0.19.0


The timestamps need not be wall clock time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-1587) failure on one SSL connection causes error:140E0197:SSL routines:SSL_shutdown:shutdown while in init

2017-09-19 Thread Justin Ross (JIRA)


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

Justin Ross updated PROTON-1587:

Labels: tls  (was: )

> failure on one SSL connection causes error:140E0197:SSL 
> routines:SSL_shutdown:shutdown while in init
> 
>
> Key: PROTON-1587
> URL: https://issues.apache.org/jira/browse/PROTON-1587
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: Gordon Sim
>Assignee: Andrew Stitcher
>  Labels: tls
> Fix For: proton-c-0.18.0
>
> Attachments: proton-1587.tgz
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Reopened] (PROTON-1512) Expose the "aborted" flag for transferred deliveries

2017-09-19 Thread Chuck Rolke (JIRA)


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

Chuck Rolke reopened PROTON-1512:
-

In practice the current implementation doesn't work well.

> Expose the "aborted" flag for transferred deliveries
> 
>
> Key: PROTON-1512
> URL: https://issues.apache.org/jira/browse/PROTON-1512
> Project: Qpid Proton
>  Issue Type: New Feature
>  Components: proton-c
>Reporter: Ted Ross
>Assignee: Alan Conway
>  Labels: api
> Fix For: proton-c-0.18.0
>
>
> As we develop support for message streaming in Qpid Dispatch Router (i.e. 
> frames for large multi-frame messages are forwarded to destinations as they 
> arrive, before the complete message is received), there is a need to handle 
> the case where a received message is never completed.
> The AMQP protocol has a provision for this in the "aborted" flag in the 
> transfer performative.  If the router is in the process of streaming a large 
> message from sender to receiver and the sender drops before completing the 
> delivery, the router can send a transfer to the downstream receivers with the 
> "aborted" flag set.  This would indicate that the message should not be 
> processed and would not cause any framing errors on the link.
> Proton does not currently expose this capability in its API (There is a 
> pn_link_abort in the C header file, but it is commented out and not 
> implemented).
> In order to properly handle the failure cases for message streaming, this 
> feature must be usable in Proton.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PROTON-1512) Expose the "aborted" flag for transferred deliveries

2017-09-19 Thread Chuck Rolke (JIRA)


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

Chuck Rolke commented on PROTON-1512:
-

Testing this feature there is an issue with how it is implemented. If a 
single-frame message comes in with abort=true in the header then pn_link_recv 
does not deliver any of the message. Instead it just delivery the -5 state 
error. In the case where the second message is aborted pn_link_recv returns:
{noformat}
125 - some length 1
-1 - EOS
-5 - STATE_ERROR
{noformat}

When two normal, short messages are received pn_link_recv returns:
{noformat}
125 - some length 1
-1 - EOS
125 - some length 2
-1 - EOS
{noformat}

In order for the router to have some message header to send down the line 
proton must deliver the content of the header that had the abort=true.
{noformat}
125 - some length 1
-1 - EOS
125 - some length 2
-5 - STATE_ERROR
{noformat}


> Expose the "aborted" flag for transferred deliveries
> 
>
> Key: PROTON-1512
> URL: https://issues.apache.org/jira/browse/PROTON-1512
> Project: Qpid Proton
>  Issue Type: New Feature
>  Components: proton-c
>Reporter: Ted Ross
>Assignee: Alan Conway
>  Labels: api
> Fix For: proton-c-0.18.0
>
>
> As we develop support for message streaming in Qpid Dispatch Router (i.e. 
> frames for large multi-frame messages are forwarded to destinations as they 
> arrive, before the complete message is received), there is a need to handle 
> the case where a received message is never completed.
> The AMQP protocol has a provision for this in the "aborted" flag in the 
> transfer performative.  If the router is in the process of streaming a large 
> message from sender to receiver and the sender drops before completing the 
> delivery, the router can send a transfer to the downstream receivers with the 
> "aborted" flag set.  This would indicate that the message should not be 
> processed and would not cause any framing errors on the link.
> Proton does not currently expose this capability in its API (There is a 
> pn_link_abort in the C header file, but it is commented out and not 
> implemented).
> In order to properly handle the failure cases for message streaming, this 
> feature must be usable in Proton.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-1542) hostname should be set on sasl-init

2017-09-19 Thread Justin Ross (JIRA)


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

Justin Ross updated PROTON-1542:

Issue Type: Improvement  (was: Bug)

> hostname should be set on sasl-init
> ---
>
> Key: PROTON-1542
> URL: https://issues.apache.org/jira/browse/PROTON-1542
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding, go-binding, proton-c, python-binding, 
> ruby-binding
>Reporter: Gordon Sim
> Fix For: proton-c-0.18.0
>
>
> For a multi-tenant service/server, where each tenant has its own user base, 
> the hostname in the sasl-init frame provides a convenient way of determining 
> the correct tenant to authenticate for.
> At present this is not set for any proton-c based client. It is similar to 
> the SNI information included in the TLS layer initiation (if such a layer is 
> in use).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (PROTON-1590) Segfaults when compiling C++03 clients with a C++11 compiled proton-cpp library

2017-09-19 Thread Andrew Stitcher (JIRA)


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

Andrew Stitcher resolved PROTON-1590.
-
Resolution: Fixed

> Segfaults when compiling C++03 clients with a C++11 compiled proton-cpp 
> library
> ---
>
> Key: PROTON-1590
> URL: https://issues.apache.org/jira/browse/PROTON-1590
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Reporter: Jiri Danek
>Assignee: Andrew Stitcher
> Fix For: proton-c-0.18.0
>
>
> Compile the proton library as usual.
> {noformat}
> cmake .. -DBUILD_GO=OFF -DCMAKE_INSTALL_PREFIX=../install -GNinja
> ninja install
> {noformat}
> Now compile an application that uses container.schedule() function. An 
> example should work fine.
> {noformat}
> g++ -std=c++03 scheduled_send_03.cpp -I ../../install/include -L 
> ../../install/lib64 -l qpid-proton-cpp -l qpid-proton-core -l 
> qpid-proton-proactor
> {noformat}
> Run this and observe the segfault
> {noformat}
> LD_LIBRARY_PATH=../../install/lib64 ./a.out  
> Segmentation fault
> {noformat}
> {noformat}
> $ LD_LIBRARY_PATH=../../install/lib64 gdb --args ./a.out
> GNU gdb (GDB) 8.0
> Copyright (C) 2017 Free Software Foundation, Inc.
> [...]
> Reading symbols from ./a.out...done.
> (gdb) run
> Starting program: /home/jdanek/Work/repos/qpid-proton/examples/cpp/a.out 
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library 
> "/nix/store/l48biijfr1j6d5kdg911051x2phfjrz7-glibc-2.25/lib/libthread_db.so.1".
> Program received signal SIGSEGV, Segmentation fault.
> 0x7fffae20 in ?? ()
> (gdb) bt
> #0  0x7fffae20 in ?? ()
> #1  0x77bb09d4 in std::function::function(std::function ()> const&) (this=0x7ffface0, __x=...)
> at 
> /nix/store/pdidaf83cvkrgx8xjgjdnl5m1naqjbfk-gcc-7.1.0/include/c++/7.1.0/bits/std_function.h:677
> #2  0x77bc714a in proton::work::work (this=0x7ffface0) at 
> ../proton-c/bindings/cpp/include/proton/work_queue.hpp:47
> #3  proton::work_queue::schedule (this=, d=..., f=...) at 
> ../proton-c/bindings/cpp/src/work_queue.cpp:49
> #4  0x00405ade in void proton::schedule_work void (scheduled_sender::*)(proton::sender), scheduled_sender*, 
> proton::sender>(proton::work_queue*, proton::duration, void 
> (scheduled_sender::*)(proton::sender), scheduled_sender*, proton::sender) ()
> #5  0x00405bfb in scheduled_sender::on_sender_open(proton::sender&) ()
> #6  0x77bb8f3d in proton::(anonymous namespace)::on_link_remote_open 
> (event=0x7fffb1a0, handler=warning: RTTI symbol not found for class 
> 'scheduled_sender'
> ...)
> at ../proton-c/bindings/cpp/src/messaging_adapter.cpp:267
> #7  proton::messaging_adapter::dispatch (handler=warning: RTTI symbol not 
> found for class 'scheduled_sender'
> ..., event=event@entry=0x61dcd0)
> at ../proton-c/bindings/cpp/src/messaging_adapter.cpp:309
> #8  0x77bafa2e in proton::container::impl::handle 
> (this=this@entry=0x61d030, event=0x61dcd0)
> at ../proton-c/bindings/cpp/src/proactor_container_impl.cpp:601
> #9  0x77bb006b in proton::container::impl::thread 
> (this=this@entry=0x61d030)
> at ../proton-c/bindings/cpp/src/proactor_container_impl.cpp:613
> #10 0x77bb0413 in proton::container::impl::run (this=0x61d030, 
> threads=1)
> at ../proton-c/bindings/cpp/src/proactor_container_impl.cpp:651
> #11 0x00404166 in main ()
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PROTON-1481) Improve the capability to inject work into serialised contexts

2017-09-19 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on PROTON-1481:
-

Commit 80d76d64893a4fe3d540b5927c32952a3133f348 in qpid-proton's branch 
refs/heads/master from [~astitcher]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=80d76d6 ]

PROTON-1481/PROTON-1590: [C++ binding] Fix ABI problems with mixed C++03/C++11 
compilations
- Different versions of the proton::work class exist in different
  namespaces.
- When the library is compiled as C++11 both versions of the work APIs are 
compiled
- However when client programs are compiled only one version of the work APIs
  (either 03 or 11, but not both) are available.
- This is hacky but should work as none of these APIs are virtual so don't 
affect ABI layout


> Improve the capability to inject work into serialised contexts
> --
>
> Key: PROTON-1481
> URL: https://issues.apache.org/jira/browse/PROTON-1481
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
> Fix For: proton-c-0.18.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PROTON-1590) Segfaults when compiling C++03 clients with a C++11 compiled proton-cpp library

2017-09-19 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on PROTON-1590:
-

Commit cdd86bcfe748bb979d7f7f1a07a73ed81b0acabe in qpid-proton's branch 
refs/heads/master from [~astitcher]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=cdd86bc ]

PROTON-1590: [C++ binding] Make sasl and ssl objects copyable and assignable
- Only ensure that they can't be default constructed (as that makes little 
sense)
- In retrospect only allowing these objects to be copied/assigned is harmless
- This fixes some issues when mixing C++03 and C++11 compilation


> Segfaults when compiling C++03 clients with a C++11 compiled proton-cpp 
> library
> ---
>
> Key: PROTON-1590
> URL: https://issues.apache.org/jira/browse/PROTON-1590
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Reporter: Jiri Danek
>Assignee: Andrew Stitcher
> Fix For: proton-c-0.18.0
>
>
> Compile the proton library as usual.
> {noformat}
> cmake .. -DBUILD_GO=OFF -DCMAKE_INSTALL_PREFIX=../install -GNinja
> ninja install
> {noformat}
> Now compile an application that uses container.schedule() function. An 
> example should work fine.
> {noformat}
> g++ -std=c++03 scheduled_send_03.cpp -I ../../install/include -L 
> ../../install/lib64 -l qpid-proton-cpp -l qpid-proton-core -l 
> qpid-proton-proactor
> {noformat}
> Run this and observe the segfault
> {noformat}
> LD_LIBRARY_PATH=../../install/lib64 ./a.out  
> Segmentation fault
> {noformat}
> {noformat}
> $ LD_LIBRARY_PATH=../../install/lib64 gdb --args ./a.out
> GNU gdb (GDB) 8.0
> Copyright (C) 2017 Free Software Foundation, Inc.
> [...]
> Reading symbols from ./a.out...done.
> (gdb) run
> Starting program: /home/jdanek/Work/repos/qpid-proton/examples/cpp/a.out 
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library 
> "/nix/store/l48biijfr1j6d5kdg911051x2phfjrz7-glibc-2.25/lib/libthread_db.so.1".
> Program received signal SIGSEGV, Segmentation fault.
> 0x7fffae20 in ?? ()
> (gdb) bt
> #0  0x7fffae20 in ?? ()
> #1  0x77bb09d4 in std::function::function(std::function ()> const&) (this=0x7ffface0, __x=...)
> at 
> /nix/store/pdidaf83cvkrgx8xjgjdnl5m1naqjbfk-gcc-7.1.0/include/c++/7.1.0/bits/std_function.h:677
> #2  0x77bc714a in proton::work::work (this=0x7ffface0) at 
> ../proton-c/bindings/cpp/include/proton/work_queue.hpp:47
> #3  proton::work_queue::schedule (this=, d=..., f=...) at 
> ../proton-c/bindings/cpp/src/work_queue.cpp:49
> #4  0x00405ade in void proton::schedule_work void (scheduled_sender::*)(proton::sender), scheduled_sender*, 
> proton::sender>(proton::work_queue*, proton::duration, void 
> (scheduled_sender::*)(proton::sender), scheduled_sender*, proton::sender) ()
> #5  0x00405bfb in scheduled_sender::on_sender_open(proton::sender&) ()
> #6  0x77bb8f3d in proton::(anonymous namespace)::on_link_remote_open 
> (event=0x7fffb1a0, handler=warning: RTTI symbol not found for class 
> 'scheduled_sender'
> ...)
> at ../proton-c/bindings/cpp/src/messaging_adapter.cpp:267
> #7  proton::messaging_adapter::dispatch (handler=warning: RTTI symbol not 
> found for class 'scheduled_sender'
> ..., event=event@entry=0x61dcd0)
> at ../proton-c/bindings/cpp/src/messaging_adapter.cpp:309
> #8  0x77bafa2e in proton::container::impl::handle 
> (this=this@entry=0x61d030, event=0x61dcd0)
> at ../proton-c/bindings/cpp/src/proactor_container_impl.cpp:601
> #9  0x77bb006b in proton::container::impl::thread 
> (this=this@entry=0x61d030)
> at ../proton-c/bindings/cpp/src/proactor_container_impl.cpp:613
> #10 0x77bb0413 in proton::container::impl::run (this=0x61d030, 
> threads=1)
> at ../proton-c/bindings/cpp/src/proactor_container_impl.cpp:651
> #11 0x00404166 in main ()
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PROTON-1590) Segfaults when compiling C++03 clients with a C++11 compiled proton-cpp library

2017-09-19 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on PROTON-1590:
-

Commit 80d76d64893a4fe3d540b5927c32952a3133f348 in qpid-proton's branch 
refs/heads/master from [~astitcher]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=80d76d6 ]

PROTON-1481/PROTON-1590: [C++ binding] Fix ABI problems with mixed C++03/C++11 
compilations
- Different versions of the proton::work class exist in different
  namespaces.
- When the library is compiled as C++11 both versions of the work APIs are 
compiled
- However when client programs are compiled only one version of the work APIs
  (either 03 or 11, but not both) are available.
- This is hacky but should work as none of these APIs are virtual so don't 
affect ABI layout


> Segfaults when compiling C++03 clients with a C++11 compiled proton-cpp 
> library
> ---
>
> Key: PROTON-1590
> URL: https://issues.apache.org/jira/browse/PROTON-1590
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Reporter: Jiri Danek
>Assignee: Andrew Stitcher
> Fix For: proton-c-0.18.0
>
>
> Compile the proton library as usual.
> {noformat}
> cmake .. -DBUILD_GO=OFF -DCMAKE_INSTALL_PREFIX=../install -GNinja
> ninja install
> {noformat}
> Now compile an application that uses container.schedule() function. An 
> example should work fine.
> {noformat}
> g++ -std=c++03 scheduled_send_03.cpp -I ../../install/include -L 
> ../../install/lib64 -l qpid-proton-cpp -l qpid-proton-core -l 
> qpid-proton-proactor
> {noformat}
> Run this and observe the segfault
> {noformat}
> LD_LIBRARY_PATH=../../install/lib64 ./a.out  
> Segmentation fault
> {noformat}
> {noformat}
> $ LD_LIBRARY_PATH=../../install/lib64 gdb --args ./a.out
> GNU gdb (GDB) 8.0
> Copyright (C) 2017 Free Software Foundation, Inc.
> [...]
> Reading symbols from ./a.out...done.
> (gdb) run
> Starting program: /home/jdanek/Work/repos/qpid-proton/examples/cpp/a.out 
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library 
> "/nix/store/l48biijfr1j6d5kdg911051x2phfjrz7-glibc-2.25/lib/libthread_db.so.1".
> Program received signal SIGSEGV, Segmentation fault.
> 0x7fffae20 in ?? ()
> (gdb) bt
> #0  0x7fffae20 in ?? ()
> #1  0x77bb09d4 in std::function::function(std::function ()> const&) (this=0x7ffface0, __x=...)
> at 
> /nix/store/pdidaf83cvkrgx8xjgjdnl5m1naqjbfk-gcc-7.1.0/include/c++/7.1.0/bits/std_function.h:677
> #2  0x77bc714a in proton::work::work (this=0x7ffface0) at 
> ../proton-c/bindings/cpp/include/proton/work_queue.hpp:47
> #3  proton::work_queue::schedule (this=, d=..., f=...) at 
> ../proton-c/bindings/cpp/src/work_queue.cpp:49
> #4  0x00405ade in void proton::schedule_work void (scheduled_sender::*)(proton::sender), scheduled_sender*, 
> proton::sender>(proton::work_queue*, proton::duration, void 
> (scheduled_sender::*)(proton::sender), scheduled_sender*, proton::sender) ()
> #5  0x00405bfb in scheduled_sender::on_sender_open(proton::sender&) ()
> #6  0x77bb8f3d in proton::(anonymous namespace)::on_link_remote_open 
> (event=0x7fffb1a0, handler=warning: RTTI symbol not found for class 
> 'scheduled_sender'
> ...)
> at ../proton-c/bindings/cpp/src/messaging_adapter.cpp:267
> #7  proton::messaging_adapter::dispatch (handler=warning: RTTI symbol not 
> found for class 'scheduled_sender'
> ..., event=event@entry=0x61dcd0)
> at ../proton-c/bindings/cpp/src/messaging_adapter.cpp:309
> #8  0x77bafa2e in proton::container::impl::handle 
> (this=this@entry=0x61d030, event=0x61dcd0)
> at ../proton-c/bindings/cpp/src/proactor_container_impl.cpp:601
> #9  0x77bb006b in proton::container::impl::thread 
> (this=this@entry=0x61d030)
> at ../proton-c/bindings/cpp/src/proactor_container_impl.cpp:613
> #10 0x77bb0413 in proton::container::impl::run (this=0x61d030, 
> threads=1)
> at ../proton-c/bindings/cpp/src/proactor_container_impl.cpp:651
> #11 0x00404166 in main ()
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-1590) Segfaults when compiling C++03 clients with a C++11 compiled proton-cpp library

2017-09-19 Thread Andrew Stitcher (JIRA)


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

Andrew Stitcher updated PROTON-1590:

Summary: Segfaults when compiling C++03 clients with a C++11 compiled 
proton-cpp library  (was: Segfault in proton-c++ when compiled with GCC 7.1.0 
without any options and then used from project compiled with -stc=c++03)

> Segfaults when compiling C++03 clients with a C++11 compiled proton-cpp 
> library
> ---
>
> Key: PROTON-1590
> URL: https://issues.apache.org/jira/browse/PROTON-1590
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Reporter: Jiri Danek
>Assignee: Andrew Stitcher
> Fix For: proton-c-0.18.0
>
>
> Compile the proton library as usual.
> {noformat}
> cmake .. -DBUILD_GO=OFF -DCMAKE_INSTALL_PREFIX=../install -GNinja
> ninja install
> {noformat}
> Now compile an application that uses container.schedule() function. An 
> example should work fine.
> {noformat}
> g++ -std=c++03 scheduled_send_03.cpp -I ../../install/include -L 
> ../../install/lib64 -l qpid-proton-cpp -l qpid-proton-core -l 
> qpid-proton-proactor
> {noformat}
> Run this and observe the segfault
> {noformat}
> LD_LIBRARY_PATH=../../install/lib64 ./a.out  
> Segmentation fault
> {noformat}
> {noformat}
> $ LD_LIBRARY_PATH=../../install/lib64 gdb --args ./a.out
> GNU gdb (GDB) 8.0
> Copyright (C) 2017 Free Software Foundation, Inc.
> [...]
> Reading symbols from ./a.out...done.
> (gdb) run
> Starting program: /home/jdanek/Work/repos/qpid-proton/examples/cpp/a.out 
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library 
> "/nix/store/l48biijfr1j6d5kdg911051x2phfjrz7-glibc-2.25/lib/libthread_db.so.1".
> Program received signal SIGSEGV, Segmentation fault.
> 0x7fffae20 in ?? ()
> (gdb) bt
> #0  0x7fffae20 in ?? ()
> #1  0x77bb09d4 in std::function::function(std::function ()> const&) (this=0x7ffface0, __x=...)
> at 
> /nix/store/pdidaf83cvkrgx8xjgjdnl5m1naqjbfk-gcc-7.1.0/include/c++/7.1.0/bits/std_function.h:677
> #2  0x77bc714a in proton::work::work (this=0x7ffface0) at 
> ../proton-c/bindings/cpp/include/proton/work_queue.hpp:47
> #3  proton::work_queue::schedule (this=, d=..., f=...) at 
> ../proton-c/bindings/cpp/src/work_queue.cpp:49
> #4  0x00405ade in void proton::schedule_work void (scheduled_sender::*)(proton::sender), scheduled_sender*, 
> proton::sender>(proton::work_queue*, proton::duration, void 
> (scheduled_sender::*)(proton::sender), scheduled_sender*, proton::sender) ()
> #5  0x00405bfb in scheduled_sender::on_sender_open(proton::sender&) ()
> #6  0x77bb8f3d in proton::(anonymous namespace)::on_link_remote_open 
> (event=0x7fffb1a0, handler=warning: RTTI symbol not found for class 
> 'scheduled_sender'
> ...)
> at ../proton-c/bindings/cpp/src/messaging_adapter.cpp:267
> #7  proton::messaging_adapter::dispatch (handler=warning: RTTI symbol not 
> found for class 'scheduled_sender'
> ..., event=event@entry=0x61dcd0)
> at ../proton-c/bindings/cpp/src/messaging_adapter.cpp:309
> #8  0x77bafa2e in proton::container::impl::handle 
> (this=this@entry=0x61d030, event=0x61dcd0)
> at ../proton-c/bindings/cpp/src/proactor_container_impl.cpp:601
> #9  0x77bb006b in proton::container::impl::thread 
> (this=this@entry=0x61d030)
> at ../proton-c/bindings/cpp/src/proactor_container_impl.cpp:613
> #10 0x77bb0413 in proton::container::impl::run (this=0x61d030, 
> threads=1)
> at ../proton-c/bindings/cpp/src/proactor_container_impl.cpp:651
> #11 0x00404166 in main ()
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (DISPATCH-830) Message reception must account for in-flight rx wakeup callbacks

2017-09-19 Thread Chuck Rolke (JIRA)

Chuck Rolke created DISPATCH-830:


 Summary: Message reception must account for in-flight rx wakeup 
callbacks
 Key: DISPATCH-830
 URL: https://issues.apache.org/jira/browse/DISPATCH-830
 Project: Qpid Dispatch
  Issue Type: Bug
Reporter: Chuck Rolke
Assignee: Chuck Rolke


Recent changes from DISPATCH-807 introduce calls into AMQP_rx_handler that are 
not created by proton events. The current design does not protect from having a 
proton event complete and dispose of a message while a callback for that 
message is in flight.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (DISPATCH-824) Remove deprecated entities and attributes from the router schema.

2017-09-19 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/DISPATCH-824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16172084#comment-16172084
 ] 

ASF GitHub Bot commented on DISPATCH-824:
-

GitHub user ganeshmurthy opened a pull request:

https://github.com/apache/qpid-dispatch/pull/199

DISPATCH-824 - Remove deprecated entities and attributes from the rou…

…ter schema and related code changes

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-824-1

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/qpid-dispatch/pull/199.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #199


commit 8d0a2dde02b7cdbddf69019c345c13c6b930b9d6
Author: Ganesh Murthy 
Date:   2017-09-19T13:51:47Z

DISPATCH-824 - Remove deprecated entities and attributes from the router 
schema and related code changes




> Remove deprecated entities and attributes from the router schema.
> -
>
> Key: DISPATCH-824
> URL: https://issues.apache.org/jira/browse/DISPATCH-824
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 0.8.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Blocker
> Fix For: 1.0.0
>
>
> As Dispatch is coming up on a major 1.0 release, the following deprecated 
> entities/attributes must be removed from the schema
> routerId, mobileAddrMaxAge attributes from the router entity
> {noformat}
> "routerId": {
> "description":"(DEPRECATED) Router's unique identity. 
> This attribute has been deprecated. Use id instead",
> "type": "string",
> "required": false,
> "deprecated": true,
> "create": true
> },
> "mobileAddrMaxAge": {
> "type": "integer",
> "default": 60,
> "deprecated": true,
> "description": "(DEPRECATED) This value is no longer used 
> in the router.",
> "create": true
> },
> {noformat}
> addr, allowUnsecured, allowNoSasl, requirePeerAuth  attributes in listener 
> entity
> {noformat}
> "addr": {
> "description":"(DEPRECATED)IP address: ipv4 or ipv6 
> literal or a host name. This attribute has been deprecated. Use host instead",
> "deprecated": true,
> "type": "string",
> "default": "",
> "create": true
> },
> "allowNoSasl": {
> "type": "boolean",
> "create": true,
> "deprecated": true,
> "description": "(DEPRECATED) This attribute is now 
> controlled by the authenticatePeer attribute."
> },
> "requirePeerAuth": {
> "type": "boolean",
> "create": true,
> "deprecated": true,
> "description": "(DEPRECATED) This attribute is now 
> controlled by the authenticatePeer attribute."
> },
> "allowUnsecured": {
> "type": "boolean",
> "create": true,
> "deprecated": true,
> "description": "(DEPRECATED) This attribute is now 
> controlled by the requireEncryption attribute."
> },
> {noformat}
> addr  attribute in connector entity
> {noformat}
> "addr": {
> "description":"(DEPRECATED)IP address: ipv4 or ipv6 
> literal or a host name. This attribute has been deprecated. Use host instead",
> "deprecated": true,
> "type": "string",
> "default": "127.0.0.1",
> "create": true
> },
> {noformat}
> Remove the container entity
> {noformat}
> "container": {
> "description":"(DEPRECATED)Attributes related to the AMQP 
> container. This entity has been deprecated. Use the router entity instead.",
> "extends": "configurationEntity",
> "deprecated": true,
> "singleton": true,
> "attributes": {
> "containerName": {
> "type": "string",
> "description": "The  name of the AMQP container.  If not 
> specified, the container name will be set to a value of the container's 
> choosing.  The automatically assigned container name

[GitHub] qpid-dispatch pull request #199: DISPATCH-824 - Remove deprecated entities a...

2017-09-19 Thread ganeshmurthy

GitHub user ganeshmurthy opened a pull request:

https://github.com/apache/qpid-dispatch/pull/199

DISPATCH-824 - Remove deprecated entities and attributes from the rouâ¦

â¦ter schema and related code changes

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-824-1

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/qpid-dispatch/pull/199.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #199


commit 8d0a2dde02b7cdbddf69019c345c13c6b930b9d6
Author: Ganesh Murthy 
Date:   2017-09-19T13:51:47Z

DISPATCH-824 - Remove deprecated entities and attributes from the router 
schema and related code changes




---

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

[jira] [Commented] (DISPATCH-824) Remove deprecated entities and attributes from the router schema.

2017-09-19 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/DISPATCH-824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16172080#comment-16172080
 ] 

ASF GitHub Bot commented on DISPATCH-824:
-

Github user ganeshmurthy closed the pull request at:

https://github.com/apache/qpid-dispatch/pull/198


> Remove deprecated entities and attributes from the router schema.
> -
>
> Key: DISPATCH-824
> URL: https://issues.apache.org/jira/browse/DISPATCH-824
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 0.8.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Blocker
> Fix For: 1.0.0
>
>
> As Dispatch is coming up on a major 1.0 release, the following deprecated 
> entities/attributes must be removed from the schema
> routerId, mobileAddrMaxAge attributes from the router entity
> {noformat}
> "routerId": {
> "description":"(DEPRECATED) Router's unique identity. 
> This attribute has been deprecated. Use id instead",
> "type": "string",
> "required": false,
> "deprecated": true,
> "create": true
> },
> "mobileAddrMaxAge": {
> "type": "integer",
> "default": 60,
> "deprecated": true,
> "description": "(DEPRECATED) This value is no longer used 
> in the router.",
> "create": true
> },
> {noformat}
> addr, allowUnsecured, allowNoSasl, requirePeerAuth  attributes in listener 
> entity
> {noformat}
> "addr": {
> "description":"(DEPRECATED)IP address: ipv4 or ipv6 
> literal or a host name. This attribute has been deprecated. Use host instead",
> "deprecated": true,
> "type": "string",
> "default": "",
> "create": true
> },
> "allowNoSasl": {
> "type": "boolean",
> "create": true,
> "deprecated": true,
> "description": "(DEPRECATED) This attribute is now 
> controlled by the authenticatePeer attribute."
> },
> "requirePeerAuth": {
> "type": "boolean",
> "create": true,
> "deprecated": true,
> "description": "(DEPRECATED) This attribute is now 
> controlled by the authenticatePeer attribute."
> },
> "allowUnsecured": {
> "type": "boolean",
> "create": true,
> "deprecated": true,
> "description": "(DEPRECATED) This attribute is now 
> controlled by the requireEncryption attribute."
> },
> {noformat}
> addr  attribute in connector entity
> {noformat}
> "addr": {
> "description":"(DEPRECATED)IP address: ipv4 or ipv6 
> literal or a host name. This attribute has been deprecated. Use host instead",
> "deprecated": true,
> "type": "string",
> "default": "127.0.0.1",
> "create": true
> },
> {noformat}
> Remove the container entity
> {noformat}
> "container": {
> "description":"(DEPRECATED)Attributes related to the AMQP 
> container. This entity has been deprecated. Use the router entity instead.",
> "extends": "configurationEntity",
> "deprecated": true,
> "singleton": true,
> "attributes": {
> "containerName": {
> "type": "string",
> "description": "The  name of the AMQP container.  If not 
> specified, the container name will be set to a value of the container's 
> choosing.  The automatically assigned container name is not guaranteed to be 
> persistent across restarts of the container.",
> "create": true
> },
> "workerThreads": {
> "type": "integer",
> "default": 4,
> "description": "The number of threads that will be 
> created to process message traffic and other application work (timers, 
> non-amqp file descriptors, etc.) .",
> "create": true
> },
> "debugDump": {
> "type": "path",
> "description": "A file to dump debugging information that 
> can't be logged normally.",
> "create": true
> },
> "saslConfigPath": {
>

[GitHub] qpid-dispatch pull request #198: DISPATCH-824 - Remove deprecated entities a...

2017-09-19 Thread ganeshmurthy

Github user ganeshmurthy closed the pull request at:

https://github.com/apache/qpid-dispatch/pull/198


---

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

[jira] [Commented] (DISPATCH-818) Honor failoverList provided by connected brokers

2017-09-19 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/DISPATCH-818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16172070#comment-16172070
 ] 

ASF GitHub Bot commented on DISPATCH-818:
-

Github user ganeshmurthy closed the pull request at:

https://github.com/apache/qpid-dispatch/pull/195


> Honor failoverList provided by connected brokers
> 
>
> Key: DISPATCH-818
> URL: https://issues.apache.org/jira/browse/DISPATCH-818
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 0.8.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> When a router makes a connection to a broker (using a configured connector), 
> the broker may provide alternate connection information for use in a failure 
> scenario. The router must honor this alternate connection data when the 
> primary connection is lost.
> For example, if the router opens a connection to the broker and the broker 
> responds with an open frame like the following - 
> {noformat}
> [0x7fc8b000a3e0]:0 <- @open(16) [container-id="Router.A", 
> max-frame-size=16384, channel-max=32767, idle-time-out=8000, 
> offered-capabilities=:"ANONYMOUS-RELAY", 
> properties={:product="qpid-dispatch-router", :version="1.0.0", 
> :"failover-server-list"=[{:"network-host"="second-host", :port="25000"}, 
> {:"network-host"="third-host", :port="5671", :scheme="amqps"}]}]
> {noformat}
> notice that the broker sends a failover-server-list of 
> {noformat}
> "failover-server-list"=[{:"network-host"="second-host", :port="25000"}, 
> {:"network-host"="third-host", :port="5671", :scheme="amqps"}]
> {noformat}
> The router should store this alternate connection information and retry these 
> hosts when the original connection goes down.
> The following should be the order of operations
>  - The original connection goes down, try connecting with the original 
> connection information one more time. If that failed, try connecting with the 
> alternate connection information. If the original and the alternate failed, 
> keep going round robin between alternate and original until you get a 
> successful hit.
> - If there is no alternate connection information, keep on trying to connect 
> using the original connection information (which is what is currently 
> happening).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[GitHub] qpid-dispatch pull request #195: DISPATCH-818 - Added connection info list t...

2017-09-19 Thread ganeshmurthy

Github user ganeshmurthy closed the pull request at:

https://github.com/apache/qpid-dispatch/pull/195


---

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

[jira] [Commented] (DISPATCH-818) Honor failoverList provided by connected brokers

2017-09-19 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/DISPATCH-818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16172064#comment-16172064
 ] 

ASF subversion and git services commented on DISPATCH-818:
--

Commit af96b23fefe0076391db35d31d612a1ab5e6f4a2 in qpid-dispatch's branch 
refs/heads/master from [~ganeshmurthy]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=af96b23 ]

DISPATCH-818 - Added connection info list to the connector which stores the 
initial connection information and the backup connection information
1. If the primary connection goes down, the primary and the backup connections 
will be tried in quick succession
2. If the new backup connection does not provide failover-server-list, the list 
on the server is cleaned up to contain only the one pertinent connection info.
3. The connection info list always has at least one element in it which 
represents the initial successful connection information

(cherry picked from commit 2fc9e285f92d96f7d6c5a4e9e36bf356ab7cc256)


> Honor failoverList provided by connected brokers
> 
>
> Key: DISPATCH-818
> URL: https://issues.apache.org/jira/browse/DISPATCH-818
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 0.8.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> When a router makes a connection to a broker (using a configured connector), 
> the broker may provide alternate connection information for use in a failure 
> scenario. The router must honor this alternate connection data when the 
> primary connection is lost.
> For example, if the router opens a connection to the broker and the broker 
> responds with an open frame like the following - 
> {noformat}
> [0x7fc8b000a3e0]:0 <- @open(16) [container-id="Router.A", 
> max-frame-size=16384, channel-max=32767, idle-time-out=8000, 
> offered-capabilities=:"ANONYMOUS-RELAY", 
> properties={:product="qpid-dispatch-router", :version="1.0.0", 
> :"failover-server-list"=[{:"network-host"="second-host", :port="25000"}, 
> {:"network-host"="third-host", :port="5671", :scheme="amqps"}]}]
> {noformat}
> notice that the broker sends a failover-server-list of 
> {noformat}
> "failover-server-list"=[{:"network-host"="second-host", :port="25000"}, 
> {:"network-host"="third-host", :port="5671", :scheme="amqps"}]
> {noformat}
> The router should store this alternate connection information and retry these 
> hosts when the original connection goes down.
> The following should be the order of operations
>  - The original connection goes down, try connecting with the original 
> connection information one more time. If that failed, try connecting with the 
> alternate connection information. If the original and the alternate failed, 
> keep going round robin between alternate and original until you get a 
> successful hit.
> - If there is no alternate connection information, keep on trying to connect 
> using the original connection information (which is what is currently 
> happening).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (DISPATCH-818) Honor failoverList provided by connected brokers

2017-09-19 Thread Ganesh Murthy (JIRA)


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

Ganesh Murthy resolved DISPATCH-818.

Resolution: Fixed

> Honor failoverList provided by connected brokers
> 
>
> Key: DISPATCH-818
> URL: https://issues.apache.org/jira/browse/DISPATCH-818
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 0.8.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> When a router makes a connection to a broker (using a configured connector), 
> the broker may provide alternate connection information for use in a failure 
> scenario. The router must honor this alternate connection data when the 
> primary connection is lost.
> For example, if the router opens a connection to the broker and the broker 
> responds with an open frame like the following - 
> {noformat}
> [0x7fc8b000a3e0]:0 <- @open(16) [container-id="Router.A", 
> max-frame-size=16384, channel-max=32767, idle-time-out=8000, 
> offered-capabilities=:"ANONYMOUS-RELAY", 
> properties={:product="qpid-dispatch-router", :version="1.0.0", 
> :"failover-server-list"=[{:"network-host"="second-host", :port="25000"}, 
> {:"network-host"="third-host", :port="5671", :scheme="amqps"}]}]
> {noformat}
> notice that the broker sends a failover-server-list of 
> {noformat}
> "failover-server-list"=[{:"network-host"="second-host", :port="25000"}, 
> {:"network-host"="third-host", :port="5671", :scheme="amqps"}]
> {noformat}
> The router should store this alternate connection information and retry these 
> hosts when the original connection goes down.
> The following should be the order of operations
>  - The original connection goes down, try connecting with the original 
> connection information one more time. If that failed, try connecting with the 
> alternate connection information. If the original and the alternate failed, 
> keep going round robin between alternate and original until you get a 
> successful hit.
> - If there is no alternate connection information, keep on trying to connect 
> using the original connection information (which is what is currently 
> happening).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-1591) [proton-cpp] Scheduling task from a scheduled task will deadlock

2017-09-19 Thread Justin Ross (JIRA)


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

Justin Ross updated PROTON-1591:

Fix Version/s: proton-c-0.18.0

> [proton-cpp] Scheduling task from a scheduled task will deadlock
> 
>
> Key: PROTON-1591
> URL: https://issues.apache.org/jira/browse/PROTON-1591
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
> Environment: commit 6a57a8c986fbf86ad8ad109d673a89a5ae84c544 
> (upstream/master)
> Author: Cliff Jansen 
> Date:   Thu Sep 14 23:29:14 2017 -0700
> PROTON-1349: completed and improved implementation, but still fails many 
> tests
>Reporter: Jiri Danek
>Assignee: Cliff Jansen
> Fix For: proton-c-0.18.0
>
>
> Modify the {{cpp/simple_send.cpp}} example the following way
> {code}
> diff --git a/examples/cpp/simple_send.cpp b/examples/cpp/simple_send.cpp
> index a4c2272d..92e60ee0 100644
> --- a/examples/cpp/simple_send.cpp
> +++ b/examples/cpp/simple_send.cpp
> @@ -29,9 +29,11 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> +#include 
>  
>  #include "fake_cpp11.hpp"
>  
> @@ -45,15 +47,28 @@ class simple_send : public proton::messaging_handler {
>  int confirmed;
>  int total;
>  
> +std::function callback;
> +
>public:
>  simple_send(const std::string , const std::string , const 
> std::string , int c) :
> -url(s), user(u), password(p), sent(0), confirmed(0), total(c) {}
> +url(s), user(u), password(p), sent(0), confirmed(0), total(c) {
> +callback = [this]() {
> +std::cout << "Entering callback" << std::endl;
> +//TODO: uncomment one of the two commands below
> +//
> +//sender.container().stop();
> +//sender.container().schedule(1 * proton::duration::SECOND, 
> proton::work(callback));
> +//
> +std::cout << "Leaving callback" << std::endl;
> +};
> +}
>  
>  void on_container_start(proton::container ) OVERRIDE {
>  proton::connection_options co;
>  if (!user.empty()) co.user(user);
>  if (!password.empty()) co.password(password);
>  sender = c.open_sender(url, co);
> +c.schedule(1 * proton::duration::SECOND, proton::work(callback));
>  }
>  
>  void on_sendable(proton::sender ) OVERRIDE {
> {code}
> Now uncomment one of the two commented out commands. Either to stop the 
> container from the inside scheduled task, or to schedule new task from inside 
> the scheduled task. When executed, the program will deadlock.
> {noformat}
> Program received signal SIGINT, Interrupt.
> 0x768ef6dc in __lll_lock_wait () from 
> /nix/store/l48biijfr1j6d5kdg911051x2phfjrz7-glibc-2.25/lib/libpthread.so.0
> (gdb) bt
> #0  0x768ef6dc in __lll_lock_wait () from 
> /nix/store/l48biijfr1j6d5kdg911051x2phfjrz7-glibc-2.25/lib/libpthread.so.0
> #1  0x768e88e5 in pthread_mutex_lock () from 
> /nix/store/l48biijfr1j6d5kdg911051x2phfjrz7-glibc-2.25/lib/libpthread.so.0
> #2  0x77baf1e8 in __gthread_mutex_lock (__mutex=0x61e148) at 
> /nix/store/pdidaf83cvkrgx8xjgjdnl5m1naqjbfk-gcc-7.1.0/include/c++/7.1.0/x86_64-pc-linux-gnu/bits/gthr-default.h:748
> #3  std::mutex::lock (this=0x61e148) at 
> /nix/store/pdidaf83cvkrgx8xjgjdnl5m1naqjbfk-gcc-7.1.0/include/c++/7.1.0/bits/std_mutex.h:103
> #4  std::lock_guard::lock_guard (__m=..., this= pointer>) at 
> /nix/store/pdidaf83cvkrgx8xjgjdnl5m1naqjbfk-gcc-7.1.0/include/c++/7.1.0/bits/std_mutex.h:162
> #5  proton::container::impl::schedule (this=this@entry=0x61e140, delay=..., 
> delay@entry=..., f=...) at 
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/src/proactor_container_impl.cpp:399
> #6  0x77baccc8 in proton::container::schedule 
> (this=this@entry=0x7fffc668, d=..., f=...) at 
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/src/container.cpp:109
> #7  0x004065f9 in 
> simple_send::simple_send(std::__cxx11::basic_string std::char_traits, std::allocator > const&, 
> std::__cxx11::basic_string > const&, std::__cxx11::basic_string std::allocator > const&, int)::{lambda()#1}::operator()() const 
> (__closure=) at 
> /home/jdanek/Work/repos/qpid-proton/examples/cpp/simple_send.cpp:58
> #8  std::_Function_handler simple_send::simple_send(std::__cxx11::basic_string std::char_traits, std::allocator > const&, 
> std::__cxx11::basic_string > const&,

[jira] [Updated] (PROTON-1592) [proton-python] accessing properties of event.receiver in on_link_opened throws exception

2017-09-19 Thread Justin Ross (JIRA)


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

Justin Ross updated PROTON-1592:

Fix Version/s: proton-c-0.18.0

> [proton-python] accessing properties of event.receiver in on_link_opened 
> throws exception
> -
>
> Key: PROTON-1592
> URL: https://issues.apache.org/jira/browse/PROTON-1592
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Reporter: Jiri Danek
>  Labels: regression
> Fix For: proton-c-0.18.0
>
>
> Apply the following patch to the {{tx-recv.py}} example
> {code}
> diff --git a/examples/python/tx_recv.py b/examples/python/tx_recv.py
> index 4baddcf5..54f3b489 100755
> --- a/examples/python/tx_recv.py
> +++ b/examples/python/tx_recv.py
> @@ -40,6 +40,9 @@ class TxRecv(MessagingHandler, TransactionHandler):
>  self.container.declare_transaction(self.conn, handler=self)
>  self.transaction = None
>  
> +def on_link_opened(self, event):
> +event.receiver.drain_mode = True
> +
>  def on_message(self, event):
>  print(event.message.body)
>  self.transaction.accept(event.delivery)
> {code}
> Now run first {{tx_send.py}}, then this {{tx_recv.py}}. The second command 
> throws exception
> {noformat}
> $ LD_LIBRARY_PATH=`pwd`/lib64 PYTHONPATH=`pwd`/lib64/proton/bindings/python 
> python ../examples/python/tx_recv.py
> Traceback (most recent call last):
>   File "../examples/python/tx_recv.py", line 79, in 
> Container(TxRecv(opts.address, opts.messages, opts.batch_size)).run()
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
>  line 148, in run
> while self.process(): pass
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
>  line 174, in process
> self._check_errors()
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
>  line 170, in _check_errors
> _compat.raise_(exc, value, tb)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 4068, in dispatch
> ev.dispatch(self.handler)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 3977, in dispatch
> result = dispatch(handler, type.method, self)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 3857, in dispatch
> return handler.on_unhandled(method, *args)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
>  line 876, in on_unhandled
> event.dispatch(handler)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 3980, in dispatch
> self.dispatch(h, type)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 3977, in dispatch
> result = dispatch(handler, type.method, self)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 3855, in dispatch
> return m(*args)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/handlers.py",
>  line 298, in on_link_remote_open
> self.on_link_opened(event)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/handlers.py",
>  line 313, in on_link_opened
> dispatch(self.delegate, 'on_link_opened', event)
>   File 
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
>  line 3855, in dispatch
> return m(*args)
>   File "../examples/python/tx_recv.py", line 44, in on_link_opened
> event.receiver.drain_mode = True
> AttributeError: 'NoneType' object has no attribute 'drain_mode'
> {noformat}
> To see this is a regression, repeat now with python-qpid-proton 0.17.0 from 
> Pypi. With this previous release, there is success.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (PROTON-1591) [proton-cpp] Scheduling task from a scheduled task will deadlock

2017-09-19 Thread Justin Ross (JIRA)


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

Justin Ross reassigned PROTON-1591:
---

Assignee: Andrew Stitcher  (was: Cliff Jansen)

> [proton-cpp] Scheduling task from a scheduled task will deadlock
> 
>
> Key: PROTON-1591
> URL: https://issues.apache.org/jira/browse/PROTON-1591
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
> Environment: commit 6a57a8c986fbf86ad8ad109d673a89a5ae84c544 
> (upstream/master)
> Author: Cliff Jansen 
> Date:   Thu Sep 14 23:29:14 2017 -0700
> PROTON-1349: completed and improved implementation, but still fails many 
> tests
>Reporter: Jiri Danek
>Assignee: Andrew Stitcher
> Fix For: proton-c-0.18.0
>
>
> Modify the {{cpp/simple_send.cpp}} example the following way
> {code}
> diff --git a/examples/cpp/simple_send.cpp b/examples/cpp/simple_send.cpp
> index a4c2272d..92e60ee0 100644
> --- a/examples/cpp/simple_send.cpp
> +++ b/examples/cpp/simple_send.cpp
> @@ -29,9 +29,11 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> +#include 
>  
>  #include "fake_cpp11.hpp"
>  
> @@ -45,15 +47,28 @@ class simple_send : public proton::messaging_handler {
>  int confirmed;
>  int total;
>  
> +std::function callback;
> +
>public:
>  simple_send(const std::string , const std::string , const 
> std::string , int c) :
> -url(s), user(u), password(p), sent(0), confirmed(0), total(c) {}
> +url(s), user(u), password(p), sent(0), confirmed(0), total(c) {
> +callback = [this]() {
> +std::cout << "Entering callback" << std::endl;
> +//TODO: uncomment one of the two commands below
> +//
> +//sender.container().stop();
> +//sender.container().schedule(1 * proton::duration::SECOND, 
> proton::work(callback));
> +//
> +std::cout << "Leaving callback" << std::endl;
> +};
> +}
>  
>  void on_container_start(proton::container ) OVERRIDE {
>  proton::connection_options co;
>  if (!user.empty()) co.user(user);
>  if (!password.empty()) co.password(password);
>  sender = c.open_sender(url, co);
> +c.schedule(1 * proton::duration::SECOND, proton::work(callback));
>  }
>  
>  void on_sendable(proton::sender ) OVERRIDE {
> {code}
> Now uncomment one of the two commented out commands. Either to stop the 
> container from the inside scheduled task, or to schedule new task from inside 
> the scheduled task. When executed, the program will deadlock.
> {noformat}
> Program received signal SIGINT, Interrupt.
> 0x768ef6dc in __lll_lock_wait () from 
> /nix/store/l48biijfr1j6d5kdg911051x2phfjrz7-glibc-2.25/lib/libpthread.so.0
> (gdb) bt
> #0  0x768ef6dc in __lll_lock_wait () from 
> /nix/store/l48biijfr1j6d5kdg911051x2phfjrz7-glibc-2.25/lib/libpthread.so.0
> #1  0x768e88e5 in pthread_mutex_lock () from 
> /nix/store/l48biijfr1j6d5kdg911051x2phfjrz7-glibc-2.25/lib/libpthread.so.0
> #2  0x77baf1e8 in __gthread_mutex_lock (__mutex=0x61e148) at 
> /nix/store/pdidaf83cvkrgx8xjgjdnl5m1naqjbfk-gcc-7.1.0/include/c++/7.1.0/x86_64-pc-linux-gnu/bits/gthr-default.h:748
> #3  std::mutex::lock (this=0x61e148) at 
> /nix/store/pdidaf83cvkrgx8xjgjdnl5m1naqjbfk-gcc-7.1.0/include/c++/7.1.0/bits/std_mutex.h:103
> #4  std::lock_guard::lock_guard (__m=..., this= pointer>) at 
> /nix/store/pdidaf83cvkrgx8xjgjdnl5m1naqjbfk-gcc-7.1.0/include/c++/7.1.0/bits/std_mutex.h:162
> #5  proton::container::impl::schedule (this=this@entry=0x61e140, delay=..., 
> delay@entry=..., f=...) at 
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/src/proactor_container_impl.cpp:399
> #6  0x77baccc8 in proton::container::schedule 
> (this=this@entry=0x7fffc668, d=..., f=...) at 
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/src/container.cpp:109
> #7  0x004065f9 in 
> simple_send::simple_send(std::__cxx11::basic_string std::char_traits, std::allocator > const&, 
> std::__cxx11::basic_string > const&, std::__cxx11::basic_string std::allocator > const&, int)::{lambda()#1}::operator()() const 
> (__closure=) at 
> /home/jdanek/Work/repos/qpid-proton/examples/cpp/simple_send.cpp:58
> #8  std::_Function_handler simple_send::simple_send(std::__cxx11::basic_string std::char_traits, std::allocator > const&, 
> std::__cxx11::basic_string

[jira] [Commented] (QPID-7904) [Java Broker] ensure ACLs work with AMQP 1.0

2017-09-19 Thread ASF subversion and git services (JIRA)


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

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

Commit 15d21c47210e6bb41805a4e0d38314594fde25bf 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=15d21c4 ]

QPID-7904: [System Tests] Refactor messaging ACL tests to allow running them 
with AMQP 1.0 JMS Client


> [Java Broker] ensure ACLs work with AMQP 1.0
> 
>
> Key: QPID-7904
> URL: https://issues.apache.org/jira/browse/QPID-7904
> Project: Qpid
>  Issue Type: Task
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-broker-7.0.0
>
>
> Currently the {{ExternalACLTest}} and {{ExhaustiveACLTEst}} are excluded in 
> the {{Jav10UninvestigatedTestsExcludes}}.
> Enabling and fixing the first cause of failure (use {{ConnectionBuilder}} 
> instead of assuming {{AMQConnection}}) reveals that at least one test 
> genuinely fails  ({{testClientCreateTemporaryQueueFailed}} because we create 
> the temp queue in {{Session_1_0}} with the SystemPrinciple. See QPID-7625).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PROTON-1589) How can I handle invalid SASL PLAIN credentials error when reconnect is on?

2017-09-19 Thread Alan Conway (JIRA)


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

Alan Conway commented on PROTON-1589:
-

For reconnect we really need to identify authentication failure exceptions and 
treat them differently from other failures and *not* attempt to reconnect. That 
might mean some refactoring of our exception hierarchy so such exceptions can 
be clearly marked.

> How can I handle invalid SASL PLAIN credentials error when reconnect is on?
> ---
>
> Key: PROTON-1589
> URL: https://issues.apache.org/jira/browse/PROTON-1589
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Danek
>Assignee: Cliff Jansen
>
> Apply the following patch to the simple_send.cpp example
> {code}
> diff --git a/examples/cpp/simple_send.cpp b/examples/cpp/simple_send.cpp
> index a4c2272d..053da34f 100644
> --- a/examples/cpp/simple_send.cpp
> +++ b/examples/cpp/simple_send.cpp
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -53,6 +54,12 @@ class simple_send : public proton::messaging_handler {
>  proton::connection_options co;
>  if (!user.empty()) co.user(user);
>  if (!password.empty()) co.password(password);
> +co.sasl_enabled(true);
> +co.sasl_allow_insecure_mechs(true);
> +std::string sasl_mechanisms("PLAIN");
> +co.sasl_allowed_mechs(sasl_mechanisms);
> +proton::reconnect_options ro;
> +co.reconnect(ro);
>  sender = c.open_sender(url, co);
>  }
> {code}
> Now attempt to connect to AMQP broker, for example ActiveMQ Artemis instance, 
> which was created with {{--require-login}}. The client gets stuck if you use 
> invalid credentials.
> {noformat}
> PN_TRACE_FRM=1 examples/cpp/simple_send -a amqp://127.0.0.1:5672 -u nosuch -p 
> user
> [0xed9980]:  -> SASL
> [0xed9980]:  <- SASL
> [0xed9980]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0xed9980]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
> initial-response=b"\x00nosuch\x00user"]
> [0xed9980]:0 <- @sasl-outcome(68) [code=1]
> [0xed9980]:  -> EOS
> [0xee7290]:  -> SASL
> [0xee7290]:  <- SASL
> [0xee7290]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0xee7290]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
> initial-response=b"\x00nosuch\x00user"]
> [0xee7290]:0 <- @sasl-outcome(68) [code=1]
> [0xee7290]:  -> EOS
> [0xeee6b0]:  -> SASL
> [0xeee6b0]:  <- SASL
> [0xeee6b0]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0xeee6b0]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
> initial-response=b"\x00nosuch\x00user"]
> [0xeee6b0]:0 <- @sasl-outcome(68) [code=1]
> [0xeee6b0]:  -> EOS
> {noformat}
> As you can see, the client keeps reconnecting. The previous behavior, if I 
> recall correctly, was to execute error handler in this case. To be exact, it 
> would run {{on_transport_error}} handler.
> I think that it is reasonable for the client to stop reconnecting and run 
> this handler if the reason for failed connection are wrong credentials. This 
> condition is unlikely to resolve itself on multiple retries.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (DISPATCH-814) Killing qdrouterd process takes a long time

2017-09-19 Thread Alan Conway (JIRA)


[ 
https://issues.apache.org/jira/browse/DISPATCH-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16171925#comment-16171925
 ] 

Alan Conway commented on DISPATCH-814:
--

I can reproduce this easily with qpid-dispatch-0.8.0-3.fc26.src.rpm on fedora 
26, script and stack trace below. I have not been able to reproduce it on 
master, and the 0.8 stack trace refers to functions that don't exist on master 
anyore (qd_server_pause) so I suspect it may be fixed already on master, unless 
someone has reproduced it there.

{code}
#!/bin/sh
pkill qdrouterd
while true; do
qdrouterd&
sleep .1
qdstat -c
kill %%
wait
done
{code}
{code}
Thread 5 (Thread 0x7fd029774700 (LWP 4435)):
#0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1  0x7fd0388c3e23 in __GI___pthread_mutex_lock (mutex=0x5587cdfc8480) at 
../nptl/pthread_mutex_lock.c:80
#2  0x7fd038d55659 in sys_mutex_lock () from 
/usr/lib/qpid-dispatch/libqpid-dispatch.so
#3  0x7fd038d6cb84 in thread_run () from 
/usr/lib/qpid-dispatch/libqpid-dispatch.so
#4  0x7fd0388c136d in start_thread (arg=0x7fd029774700) at 
pthread_create.c:456
#5  0x7fd037b82bbf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97
Thread 4 (Thread 0x7fd029fc5700 (LWP 4434)):
#0  0x7fd0388c8836 in futex_wait (private=, 
expected=, futex_word=0x5587cdfc62e0) at 
../sysdeps/unix/sysv/linux/futex-internal.h:61
#1  futex_wait_simple (private=, expected=, 
futex_word=0x5587cdfc62e0) at ../sysdeps/nptl/futex-internal.h:135
#2  __condvar_acquire_lock (private=, cond=0x5587cdfc62c0) at 
pthread_cond_common.c:281
#3  __pthread_cond_broadcast (cond=0x5587cdfc62c0) at 
pthread_cond_broadcast.c:48
#4  0x7fd038d557d9 in sys_cond_signal_all () from 
/usr/lib/qpid-dispatch/libqpid-dispatch.so
#5  0x7fd038d6c391 in qd_server_pause () from 
/usr/lib/qpid-dispatch/libqpid-dispatch.so
#6  0x5587cc5fe8ef in server_signal_handler ()
#7  0x7fd038d6c7d8 in thread_run () from 
/usr/lib/qpid-dispatch/libqpid-dispatch.so
#8  0x7fd0388c136d in start_thread (arg=0x7fd029fc5700) at 
pthread_create.c:456
#9  0x7fd037b82bbf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97
Thread 3 (Thread 0x7fd02a816700 (LWP 4433)):
#0  0x7fd0388c790b in futex_wait_cancelable (private=, 
expected=0, futex_word=0x5587cdfc62e8) at 
../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0x5587cdfc8480, 
cond=0x5587cdfc62c0) at pthread_cond_wait.c:502
#2  __pthread_cond_wait (cond=0x5587cdfc62c0, mutex=0x5587cdfc8480) at 
pthread_cond_wait.c:655
#3  0x7fd038d55759 in sys_cond_wait () from 
/usr/lib/qpid-dispatch/libqpid-dispatch.so
#4  0x7fd038d6c9bb in thread_run () from 
/usr/lib/qpid-dispatch/libqpid-dispatch.so
#5  0x7fd0388c136d in start_thread (arg=0x7fd02a816700) at 
pthread_create.c:456
#6  0x7fd037b82bbf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97
Thread 2 (Thread 0x7fd02b482700 (LWP 4430)):
#0  0x7fd0388c790b in futex_wait_cancelable (private=, 
expected=0, futex_word=0x5587cded00ec) at 
../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0x5587cdfc8d80, 
cond=0x5587cded00c0) at pthread_cond_wait.c:502
#2  __pthread_cond_wait (cond=0x5587cded00c0, mutex=0x5587cdfc8d80) at 
pthread_cond_wait.c:655
#3  0x7fd038d55759 in sys_cond_wait () from 
/usr/lib/qpid-dispatch/libqpid-dispatch.so
#4  0x7fd038d63345 in router_core_thread () from 
/usr/lib/qpid-dispatch/libqpid-dispatch.so
#5  0x7fd0388c136d in start_thread (arg=0x7fd02b482700) at 
pthread_create.c:456
#6  0x7fd037b82bbf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97
Thread 1 (Thread 0x7fd0391841c0 (LWP 4428)):
#0  0x7fd0388c8836 in futex_wait (private=, 
expected=, futex_word=0x5587cdfc62e0) at 
../sysdeps/unix/sysv/linux/futex-internal.h:61
#1  futex_wait_simple (private=, expected=, 
futex_word=0x5587cdfc62e0) at ../sysdeps/nptl/futex-internal.h:135
#2  __condvar_acquire_lock (private=, cond=0x5587cdfc62c0) at 
pthread_cond_common.c:281
#3  __pthread_cond_broadcast (cond=0x5587cdfc62c0) at 
pthread_cond_broadcast.c:48
#4  0x7fd038d557d9 in sys_cond_signal_all () from 
/usr/lib/qpid-dispatch/libqpid-dispatch.so
#5  0x7fd038d6c348 in qd_server_signal () from 
/usr/lib/qpid-dispatch/libqpid-dispatch.so
#6  
#7  0x7fd0388c8662 in futex_wait (private=, expected=5, 
futex_word=0x5587cdfc62d4) at ../sysdeps/unix/sysv/linux/futex-internal.h:61
#8  futex_wait_simple (private=, expected=5, 
futex_word=0x5587cdfc62d4) at ../sysdeps/nptl/futex-internal.h:135
#9  __condvar_quiesce_and_switch_g1 (private=, 
g1index=, wseq=, cond=0x5587cdfc62c0) at 
pthread_cond_common.c:413
#10 __pthread_cond_broadcast (cond=0x5587cdfc62c0) at 
pthread_cond_broadcast.c:73
#11 0x7fd038d557d9 in sys_cond_signal_all () from

[jira] [Commented] (DISPATCH-814) Killing qdrouterd process takes a long time

2017-09-19 Thread Chuck Rolke (JIRA)


[ 
https://issues.apache.org/jira/browse/DISPATCH-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16171842#comment-16171842
 ] 

Chuck Rolke commented on DISPATCH-814:
--

I've seen qdrouterd processes stuck in ** state. This issue suggests 
an error in the testing framework where the router has exited but its process 
is still in the process table.

I do not have a decent reproducer for getting the qdrouterd into this state. It 
happens most for me when I run a bash script that starts one or more routers 
and then type ^C to exit the script.


> Killing qdrouterd process takes a long time
> ---
>
> Key: DISPATCH-814
> URL: https://issues.apache.org/jira/browse/DISPATCH-814
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Routing Engine
> Environment: This test runs in fedora 26 container.
>Reporter: Irina Boverman
>
> Often killing router fails to complete:
> ++ ps -C qdrouterd -o pid=
> + pid=' 1455'
> + kill 1455
> + set +e
> + wait 1455
> Build timed out (after 30 minutes). Marking the build as failed.
> Build was aborted



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (DISPATCH-814) Killing qdrouterd process takes a long time

2017-09-19 Thread Chuck Rolke (JIRA)


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

Chuck Rolke updated DISPATCH-814:
-
Summary: Killing qdrouterd process takes a long time  (was: Killing 
drouterd process takes a long time)

> Killing qdrouterd process takes a long time
> ---
>
> Key: DISPATCH-814
> URL: https://issues.apache.org/jira/browse/DISPATCH-814
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Routing Engine
> Environment: This test runs in fedora 26 container.
>Reporter: Irina Boverman
>
> Often killing router fails to complete:
> ++ ps -C qdrouterd -o pid=
> + pid=' 1455'
> + kill 1455
> + set +e
> + wait 1455
> Build timed out (after 30 minutes). Marking the build as failed.
> Build was aborted



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (DISPATCH-824) Remove deprecated entities and attributes from the router schema.

2017-09-19 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/DISPATCH-824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16171747#comment-16171747
 ] 

ASF GitHub Bot commented on DISPATCH-824:
-

GitHub user ganeshmurthy opened a pull request:

https://github.com/apache/qpid-dispatch/pull/198

DISPATCH-824 - Remove deprecated entities and attributes from the rou…

…ter schema and related code changes

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-824

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/qpid-dispatch/pull/198.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #198


commit bde915579d35170f3699e8d8927ad57fb805bfeb
Author: Ganesh Murthy 
Date:   2017-09-19T13:51:47Z

DISPATCH-824 - Remove deprecated entities and attributes from the router 
schema and related code changes




> Remove deprecated entities and attributes from the router schema.
> -
>
> Key: DISPATCH-824
> URL: https://issues.apache.org/jira/browse/DISPATCH-824
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 0.8.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Blocker
> Fix For: 1.0.0
>
>
> As Dispatch is coming up on a major 1.0 release, the following deprecated 
> entities/attributes must be removed from the schema
> routerId, mobileAddrMaxAge attributes from the router entity
> {noformat}
> "routerId": {
> "description":"(DEPRECATED) Router's unique identity. 
> This attribute has been deprecated. Use id instead",
> "type": "string",
> "required": false,
> "deprecated": true,
> "create": true
> },
> "mobileAddrMaxAge": {
> "type": "integer",
> "default": 60,
> "deprecated": true,
> "description": "(DEPRECATED) This value is no longer used 
> in the router.",
> "create": true
> },
> {noformat}
> addr, allowUnsecured, allowNoSasl, requirePeerAuth  attributes in listener 
> entity
> {noformat}
> "addr": {
> "description":"(DEPRECATED)IP address: ipv4 or ipv6 
> literal or a host name. This attribute has been deprecated. Use host instead",
> "deprecated": true,
> "type": "string",
> "default": "",
> "create": true
> },
> "allowNoSasl": {
> "type": "boolean",
> "create": true,
> "deprecated": true,
> "description": "(DEPRECATED) This attribute is now 
> controlled by the authenticatePeer attribute."
> },
> "requirePeerAuth": {
> "type": "boolean",
> "create": true,
> "deprecated": true,
> "description": "(DEPRECATED) This attribute is now 
> controlled by the authenticatePeer attribute."
> },
> "allowUnsecured": {
> "type": "boolean",
> "create": true,
> "deprecated": true,
> "description": "(DEPRECATED) This attribute is now 
> controlled by the requireEncryption attribute."
> },
> {noformat}
> addr  attribute in connector entity
> {noformat}
> "addr": {
> "description":"(DEPRECATED)IP address: ipv4 or ipv6 
> literal or a host name. This attribute has been deprecated. Use host instead",
> "deprecated": true,
> "type": "string",
> "default": "127.0.0.1",
> "create": true
> },
> {noformat}
> Remove the container entity
> {noformat}
> "container": {
> "description":"(DEPRECATED)Attributes related to the AMQP 
> container. This entity has been deprecated. Use the router entity instead.",
> "extends": "configurationEntity",
> "deprecated": true,
> "singleton": true,
> "attributes": {
> "containerName": {
> "type": "string",
> "description": "The  name of the AMQP container.  If not 
> specified, the container name will be set to a value of the container's 
> choosing.  The automatically assigned container name is

[GitHub] qpid-dispatch pull request #198: DISPATCH-824 - Remove deprecated entities a...

2017-09-19 Thread ganeshmurthy

GitHub user ganeshmurthy opened a pull request:

https://github.com/apache/qpid-dispatch/pull/198

DISPATCH-824 - Remove deprecated entities and attributes from the rouâ¦

â¦ter schema and related code changes

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-824

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/qpid-dispatch/pull/198.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #198


commit bde915579d35170f3699e8d8927ad57fb805bfeb
Author: Ganesh Murthy 
Date:   2017-09-19T13:51:47Z

DISPATCH-824 - Remove deprecated entities and attributes from the router 
schema and related code changes




---

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

[jira] [Commented] (DISPATCH-209) Three+ router test is needed in the system test suite.

2017-09-19 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/DISPATCH-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16171625#comment-16171625
 ] 

ASF subversion and git services commented on DISPATCH-209:
--

Commit 233f23f158e334ed14345892307773205b6395fb in qpid-dispatch's branch 
refs/heads/master from [~mgoulish]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=233f23f ]

DISPATCH-209 : linkroute 3-mesh failover test


> Three+ router test is needed in the system test suite.
> --
>
> Key: DISPATCH-209
> URL: https://issues.apache.org/jira/browse/DISPATCH-209
> Project: Qpid Dispatch
>  Issue Type: New Feature
>  Components: Tests
>Reporter: Ted Ross
>Assignee: michael goulish
> Fix For: 1.0.0
>
>
> There have arisen some issues that would have been caught had there been a 
> three-router test in the regression suite.  This test should be added.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (DISPATCH-775) allow authentication against a remote server

2017-09-19 Thread Ted Ross (JIRA)


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

Ted Ross updated DISPATCH-775:
--
Fix Version/s: 1.0.0

> allow authentication against a remote server
> 
>
> Key: DISPATCH-775
> URL: https://issues.apache.org/jira/browse/DISPATCH-775
> Project: Qpid Dispatch
>  Issue Type: New Feature
>Reporter: Gordon Sim
>Assignee: Gordon Sim
> Fix For: 1.0.0
>
>
> When running lots of routers, it would be handy to be able to have them all 
> authenticate against some centralized, external auth service. This can be 
> done by relaying the AMQP SASL frames to that remote service.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (DISPATCH-773) Implement a 2-phase start in the Dispatch Router

2017-09-19 Thread Ted Ross (JIRA)


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

Ted Ross reassigned DISPATCH-773:
-

Assignee: Ted Ross

> Implement a 2-phase start in the Dispatch Router
> 
>
> Key: DISPATCH-773
> URL: https://issues.apache.org/jira/browse/DISPATCH-773
> Project: Qpid Dispatch
>  Issue Type: New Feature
>  Components: Routing Engine
>Reporter: Adel Boutros
>Assignee: Ted Ross
>
> All the needed information could be found here:
> http://qpid.2158936.n2.nabble.com/Dispatch-router-2-phase-start-td7663118.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PROTON-522) Apache Qpid Proton on Mac/OSX - C/Objective-C

2017-09-19 Thread Roddie Kieley (JIRA)


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

Roddie Kieley commented on PROTON-522:
--

The libuv now builds and runs successfully with the updates required on my 
PROTON-522 [branch|https://github.com/RoddieKieley/qpid-proton/tree/PROTON-522] 
at github. There's also an OSX focused Travis CI 
[project|https://travis-ci.org/RoddieKieley/qpid-proton/branches] which is a 
work in progress as there are sporadic failures in go-test and c-proactor-tests 
that I do not see locally.

Locally cmake -G "Unix Makefiles" will result in 100% test pass, with very 
infrequent failures in test_ipv4_ipv6 while the cmake -G "Xcode" builds but 
doesn't actually run all the tests yet.

> Apache Qpid Proton on Mac/OSX - C/Objective-C
> -
>
> Key: PROTON-522
> URL: https://issues.apache.org/jira/browse/PROTON-522
> Project: Qpid Proton
>  Issue Type: New Feature
>Reporter: Guy Dillen
>  Labels: osx
>
> I would like using Apache Qpid Proton-C from a C or Objective-C application 
> on Mac/OSX to connect as a client to Windows Azure Service Bus.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (PROTON-1592) [proton-python] accessing properties of event.receiver in on_link_opened throws exception

2017-09-19 Thread Jiri Danek (JIRA)

Jiri Danek created PROTON-1592:
--

 Summary: [proton-python] accessing properties of event.receiver in 
on_link_opened throws exception
 Key: PROTON-1592
 URL: https://issues.apache.org/jira/browse/PROTON-1592
 Project: Qpid Proton
  Issue Type: Bug
  Components: python-binding
Reporter: Jiri Danek


Apply the following patch to the {{tx-recv.py}} example

{code}
diff --git a/examples/python/tx_recv.py b/examples/python/tx_recv.py
index 4baddcf5..54f3b489 100755
--- a/examples/python/tx_recv.py
+++ b/examples/python/tx_recv.py
@@ -40,6 +40,9 @@ class TxRecv(MessagingHandler, TransactionHandler):
 self.container.declare_transaction(self.conn, handler=self)
 self.transaction = None
 
+def on_link_opened(self, event):
+event.receiver.drain_mode = True
+
 def on_message(self, event):
 print(event.message.body)
 self.transaction.accept(event.delivery)
{noformat}

Now run first {{tx_send.py}}, then this {{tx_recv.py}}. The second command 
throws exception

{noformat}
$ LD_LIBRARY_PATH=`pwd`/lib64 PYTHONPATH=`pwd`/lib64/proton/bindings/python 
python ../examples/python/tx_recv.py
Traceback (most recent call last):
  File "../examples/python/tx_recv.py", line 79, in 
Container(TxRecv(opts.address, opts.messages, opts.batch_size)).run()
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
 line 148, in run
while self.process(): pass
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
 line 174, in process
self._check_errors()
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
 line 170, in _check_errors
_compat.raise_(exc, value, tb)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
 line 4068, in dispatch
ev.dispatch(self.handler)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
 line 3977, in dispatch
result = dispatch(handler, type.method, self)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
 line 3857, in dispatch
return handler.on_unhandled(method, *args)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
 line 876, in on_unhandled
event.dispatch(handler)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
 line 3980, in dispatch
self.dispatch(h, type)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
 line 3977, in dispatch
result = dispatch(handler, type.method, self)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
 line 3855, in dispatch
return m(*args)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/handlers.py",
 line 298, in on_link_remote_open
self.on_link_opened(event)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/handlers.py",
 line 313, in on_link_opened
dispatch(self.delegate, 'on_link_opened', event)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
 line 3855, in dispatch
return m(*args)
  File "../examples/python/tx_recv.py", line 44, in on_link_opened
event.receiver.drain_mode = True
AttributeError: 'NoneType' object has no attribute 'drain_mode'
{noformat}

To see this is a regression, repeat now with python-qpid-proton 0.17.0 from 
Pypi. With this previous release, there is success.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-1592) [proton-python] accessing properties of event.receiver in on_link_opened throws exception

2017-09-19 Thread Jiri Danek (JIRA)


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

Jiri Danek updated PROTON-1592:
---
Description: 
Apply the following patch to the {{tx-recv.py}} example

{code}
diff --git a/examples/python/tx_recv.py b/examples/python/tx_recv.py
index 4baddcf5..54f3b489 100755
--- a/examples/python/tx_recv.py
+++ b/examples/python/tx_recv.py
@@ -40,6 +40,9 @@ class TxRecv(MessagingHandler, TransactionHandler):
 self.container.declare_transaction(self.conn, handler=self)
 self.transaction = None
 
+def on_link_opened(self, event):
+event.receiver.drain_mode = True
+
 def on_message(self, event):
 print(event.message.body)
 self.transaction.accept(event.delivery)
{code}

Now run first {{tx_send.py}}, then this {{tx_recv.py}}. The second command 
throws exception

{noformat}
$ LD_LIBRARY_PATH=`pwd`/lib64 PYTHONPATH=`pwd`/lib64/proton/bindings/python 
python ../examples/python/tx_recv.py
Traceback (most recent call last):
  File "../examples/python/tx_recv.py", line 79, in 
Container(TxRecv(opts.address, opts.messages, opts.batch_size)).run()
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
 line 148, in run
while self.process(): pass
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
 line 174, in process
self._check_errors()
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
 line 170, in _check_errors
_compat.raise_(exc, value, tb)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
 line 4068, in dispatch
ev.dispatch(self.handler)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
 line 3977, in dispatch
result = dispatch(handler, type.method, self)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
 line 3857, in dispatch
return handler.on_unhandled(method, *args)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
 line 876, in on_unhandled
event.dispatch(handler)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
 line 3980, in dispatch
self.dispatch(h, type)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
 line 3977, in dispatch
result = dispatch(handler, type.method, self)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
 line 3855, in dispatch
return m(*args)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/handlers.py",
 line 298, in on_link_remote_open
self.on_link_opened(event)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/handlers.py",
 line 313, in on_link_opened
dispatch(self.delegate, 'on_link_opened', event)
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
 line 3855, in dispatch
return m(*args)
  File "../examples/python/tx_recv.py", line 44, in on_link_opened
event.receiver.drain_mode = True
AttributeError: 'NoneType' object has no attribute 'drain_mode'
{noformat}

To see this is a regression, repeat now with python-qpid-proton 0.17.0 from 
Pypi. With this previous release, there is success.

  was:
Apply the following patch to the {{tx-recv.py}} example

{code}
diff --git a/examples/python/tx_recv.py b/examples/python/tx_recv.py
index 4baddcf5..54f3b489 100755
--- a/examples/python/tx_recv.py
+++ b/examples/python/tx_recv.py
@@ -40,6 +40,9 @@ class TxRecv(MessagingHandler, TransactionHandler):
 self.container.declare_transaction(self.conn, handler=self)
 self.transaction = None
 
+def on_link_opened(self, event):
+event.receiver.drain_mode = True
+
 def on_message(self, event):
 print(event.message.body)
 self.transaction.accept(event.delivery)
{noformat}

Now run first {{tx_send.py}}, then this {{tx_recv.py}}. The second command 
throws exception

{noformat}
$ LD_LIBRARY_PATH=`pwd`/lib64 PYTHONPATH=`pwd`/lib64/proton/bindings/python 
python ../examples/python/tx_recv.py
Traceback (most recent call last):
  File "../examples/python/tx_recv.py", line 79, in 
Container(TxRecv(opts.address, opts.messages, opts.batch_size)).run()
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
 line 148, in run
while self.process(): pass
  File 
"/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
 line 174, in process
self._check_errors()
  File

45 matches

Mail list logo