Re: QPID Proton 0.19 connection.close() does not close remote connection

2018-02-21 Thread andi welchlin
Hello Gordon, thank you for the hint. This was exactly what I needed. Now I call close and in the method on_connection_closed() I stop the container. The connection is then closed remotely. Would be nice to reflect this in the Proton examples. Kind Regards, Andreas On Wed, Feb 21, 2018 at

Re: [VOTE] Release Qpid Dispatch Router 1.0.1 (RC1)

2018-02-21 Thread Jakub Scholz
+1 ... I built it from source on CentOS 7 and run it against different AMQP clients. On Tue, Feb 20, 2018 at 9:27 PM, Ted Ross wrote: > Please vote on this thread to release qpid-dispatch 1.0.1-rc1 as the > official 1.0.1. > > The release can be found here: > >

Re: QPID Proton 0.19 connection.close() does not close remote connection

2018-02-21 Thread Gordon Sim
On 21/02/18 21:33, andi welchlin wrote: Hello all, I connected a Proton MessagingHandler (Python3) to a QPID C++ Broker 0.37. I want to close the handler gracefully but I could not manage to do so. When I call connection.close() the state is afterwards: LOCAL_UNINIT, REMOTE_ACTIVE So it does

QPID Proton 0.19 connection.close() does not close remote connection

2018-02-21 Thread andi welchlin
Hello all, I connected a Proton MessagingHandler (Python3) to a QPID C++ Broker 0.37. I want to close the handler gracefully but I could not manage to do so. When I call connection.close() the state is afterwards: LOCAL_UNINIT, REMOTE_ACTIVE So it does not close the remote connection (or the

FINAL REMINDER: CFP for Apache EU Roadshow Closes 25th February

2018-02-21 Thread Sharan F
Hello Apache Supporters and Enthusiasts This is your FINAL reminder that the Call for Papers (CFP) for the Apache EU Roadshow is closing soon. Our Apache EU Roadshow will focus on Cloud, IoT, Apache Tomcat, Apache Http and will run from 13-14 June 2018 in Berlin. Note that the CFP deadline

Re: [VOTE] Release Qpid Dispatch Router 1.0.1 (RC1)

2018-02-21 Thread Ken Giusti
+1 Built and ran in Ubuntu Xenial container Ran ombt2 rpc and notification tests - no evidence of memory growth On Tue, Feb 20, 2018 at 3:27 PM, Ted Ross wrote: > Please vote on this thread to release qpid-dispatch 1.0.1-rc1 as the > official 1.0.1. > > The release can be

Re: [VOTE] Release Qpid Dispatch Router 1.0.1 (RC1)

2018-02-21 Thread Chuck Rolke
+1 * Verified signatures * Passed self tests using today's master proton b6b3dd6 - Original Message - > From: "Ted Ross" > To: users@qpid.apache.org > Sent: Tuesday, February 20, 2018 3:27:38 PM > Subject: [VOTE] Release Qpid Dispatch Router 1.0.1 (RC1) > > Please

Re: [VOTE] Release Qpid Dispatch Router 1.0.1 (RC1)

2018-02-21 Thread Ganesh Murthy
+1 * Validated signatures and checksums * Checked for presence of LICENSE and NOTICE files * Ran mvn apache-rat:check, no missing license headers found. * Built from source against Proton 0.20.0 in Fedora 27 and ran system tests. All tests passed On Tue, Feb 20, 2018 at 3:27 PM, Ted Ross

Re: [VOTE] Release Qpid Dispatch Router 1.0.1 (RC1)

2018-02-21 Thread Michael Goulish
+1 did throughput and latency tests and got good results. On Tue, Feb 20, 2018 at 3:27 PM, Ted Ross wrote: > Please vote on this thread to release qpid-dispatch 1.0.1-rc1 as the > official 1.0.1. > > The release can be found here: > >

Re: qpid-broker-j-7.0.0 failover is slow

2018-02-21 Thread Keith W
Bryan Thanks for reporting the problem. This is a defect in Broker-J 7.0.0 and 7.0.1. The defect will cause startup to be delayed as you have observed (5 seconds (cumulative) per queue or exchange using an alternate binding). The synchronous/asynchronous recoverer and existence or not of

Re: C++ Broker Performance with large messages

2018-02-21 Thread Robbie Gemmell
The warning is mainly just the result that Proton 0.19.0 was released after qpid-cpp 1.37.0 was. They were verified together when 0.19.0 was released, and I dont think there is any known issue using them together. Given the latter is released less often that warning should probably be made less

Re: C++ Broker Performance with large messages

2018-02-21 Thread andi welchlin
I used the current broker 1.37.0 now and wanted to use proton 0.19 but cmake complains that is is only tested with 0.18.1. So I tried this and the results became worse than with 1.36.0 / 0.16. Now a 300 MB message takes about 151 seconds, before it was 126. AMQP 1.0 is used Since you mentioned

Re: C++ Broker Performance with large messages

2018-02-21 Thread andi welchlin
Hi Gordon, hi Chuck, thank you for the information. I tested using Proton Python clients (python3) version 0.16 and qpidd c++ version 1.36.0. I will take the newest versions of both and retest. Will come back with the results. Thank you, Andreas On Tue, Feb 20, 2018 at 10:15 PM, Chuck Rolke