Heads Up: Updated minimum software versions for Qpid Proton

I've committed some changes to the minimum versions of software needed to build Qpid Proton from the 0.40 release onwards. This is partly motivated by PROTON-2810 which requires us to build the C++ bits as at least C++ 14 to be able to use Open Telemetry. But also partly just keeping up with the e

Re: Qpid Proton Cpp ready to use under Windows 11

Can you say a bit more about the dependencies? You should be able to build Qpid Proton for windows without any library dependencies at all. However this will limit certain functionality. Off the top of my head the C++ dependencies are json-cpp which is only required if you want to specify connect p

Re: Is SASL_SSL enforced with qpid-proton when CyrusSASL dependency is used

On Wed, Jun 12, 2024 at 9:02 AM Andrew North wrote: > Just a curiosity, are we able to build/use CyrusSASL on windows? > In theory I think you could use Cyrus SASL built with vcpkg, but I think someone tried that and there were some specific issues with building the proton cyrus sasl code becaus

Re: Is SASL_SSL enforced with qpid-proton when CyrusSASL dependency is used

I'm not entirely clear from your description how you've been configuring SASL. Usually the CMake configure phase will choose the SASL configuration depending on the libraries it detects on the system you are running on. If you only want to use PLAIN and EXTERNAL (over TLS presumably) then you don't

Re: Client Abruptly Disconnects (python-qpid-proton 0.38.0)

There's really not enough information in this email to let us help you find the problem! - Firstly: please don't use screenshots to send textual information - many people (myself included) do not load images from unknown sources in emails for security reasons, also many mailing lists will

Re: on_connection_open never called

I'm afraid that it's going to be very difficult to diagnose the issue here without a solid reproducer. One approach might be to turn frame level logging on at one end of the connection or other using the PN_LOG environment variable. Set if to "frame" (PN_LOG=frame) to get an output on stderr of th

Re: Unable to build Win32 since Qpid.Proton 0.34

Also have you tried the most recent release which is 0.38 rather than 0.34 which is actually fairly old? On Fri, Mar 3, 2023 at 4:18 PM Andrew Stitcher wrote: > Hmm, This certainly is supposed to work. It's very suspicious that your > build fails trying to link pthreads.dll -

Re: Unable to build Win32 since Qpid.Proton 0.34

Hmm, This certainly is supposed to work. It's very suspicious that your build fails trying to link pthreads.dll - that isn't expected to be linked in windows at all. Is it possible that you have openssl detected and linked? That might force pthreads. Currently the TLS support for windows is provid

Re: Building Qpid C++ Broker for macOS

The Proton C++ binding is supported on MacOS and our CI does indeed test it there. The Qpid broker relies on a threading abstraction that can be changed to target different platforms. Using modern C++ this abstraction should now use the standard C++ library threading primitives for maximum portabi

Heads Up: Changes to the Python binding build/install process for proton-c 0.38.0

The recent proton-c 0.38.0 release contains significant changes to the way that the python bindings to the proton library build and install. They are now more consistent with the usual packaging standards in the python community: - The build process will now build a python source package compat

Re: VS / MSVC memory addressing in Debug

You don't say where you are getting the proton cpp library but I'm assuming you're building it yourself. Are you building and using debug versions of the proton libraries? I'm not sure how familiar you are with Windows development, so sorry if you already know this, but the Windows Visual studio e

Re: Addressing for Azure Event Hubs

It might be worth adding that the Proton C++ examples *include* an example that talks to Azure Service Bus (called service_bus.cpp). As far as I know this example still works, so could be used as a template to write client code that talks to Azure Service Bus. Andrew On Tue, 2022-08-09 at 09:22 +

Re: Trouble with golang electron package

I completely agree with Robbie that if you are starting some new work with go and amqp you might look elsewhere. Having said that, I think the issue here might be that your go build might be picking up older system header files for proton that don't define pn_tostring() which has only recently bee

Re: [VOTE] Release Apache Qpid Proton 0.37.0 (RC2)

+1 I compiled and tested the 0.37.0-rc2 git tag: Both with C++ and Python bindings. * FreeBSD 13.0-RELEASE x86_64 (clang 11.0.1) * Successfully Built RelWithDebInfo and tested with valgrind with no failures. * Successfully Build RelWithDebInfo with ASAN, but testing

Re: [VOTE] Release Apache Qpid Proton 0.37.0

This is interesting and may indicate an issue specific to Fedora (or the versions of dependent libraries on Fedora) as the Travis CI runs an ASAN job on Ubuntu 20.04 with the clang compiler which does not see any failure. It also runs a TSAN job but there the python tests are disabled for some reas

Re: AMQP 1.0 support in Qpid Messaging C++ 1.39.0

ntained currently). Andrew > > -Original Message- > From: Andrew Stitcher > Sent: Friday, February 18, 2022 11:53 AM > To: users@qpid.apache.org > Subject: Re: AMQP 1.0 support in Qpid Messaging C++ 1.39.0 > > I don't have time for a full reply, but it looks l

Re: AMQP 1.0 support in Qpid Messaging C++ 1.39.0

I don't have time for a full reply, but it looks like you didn't build qpid 1.39 with the qpid-proton library. The Proton library is what handles AMQP 1.0 so qpid needs to be able to find it when it is built. When built with Proton, qpid will create the modules for amqp 1.0 and you should be able

Re: pip installation fails with error C1083

If the issue is with a python 3.10 install the issue might be PROTON- 2458 https://issues.apache.org/jira/browse/PROTON-2458. Andrew On Fri, 2022-02-11 at 14:21 +, David van der Ent wrote: > Hi Panos, > > Thank you for your response. Didn’t use your suggestion though and > still got it worki

Re: python-qpid-proton 0.36.0 to pypi

On Sun, 2022-01-23 at 17:04 +0200, Marko Kohtala wrote: > Hello. > > Can we expect to receive Qpid Proton 0.36.0 at PyPi > https://pypi.org/project/python-qpid-proton/ any time soon? I've just uploaded the 0.36.0 package - sorry for the delay. Andrew ---

Re: [VOTE] Release Apache Qpid Proton 0.36.0

I've now found the causes of the caveats I mention below. They are actually small but harmless/irrelevant bugs in the release. I'll commit fixes for them to main today, but I don't think they should delay this. Andrew On Wed, 2021-11-03 at 17:30 +, Andrew Stitcher wrote:

Re: [VOTE] Release Apache Qpid Proton 0.36.0

+1 (with some caveats) Build (cmake+ninja) and build tested (ctest) on: * Fedora 34 tested with valgrind - python, ruby, go Complete success, no test failures * RPi4 with current Raspberry Pi OS - * Built Tested no valgrind (too slow), python only * Built/Tested with asan sanitizer No tes

Re: Bad random number seed for link names

On Wed, 2021-06-09 at 06:32 -0700, rherbert wrote: > ... > Is this something I should open a ticket for?  I don't have a patch > for > proton - I don't know if using std::mt19937_64 is acceptable for the > proton > code base. Thank you for isolating the cause of you problem - this is really useful

Re: [VOTE] Release Apache Qpid Proton 0.34.0

+1: Built from git tag: Raspberry Pi 4 (aarch64/armv8l - 32 bit userspace): Latest Raspbian (based on Debian 10.9); Built (RelWithDebInfo; gcc8.3, No go, no ruby) and tested (ctest) with no errors: built with no checking and with ASAN checking (valgrind seems to have problems on this platform).

Proton-c Heads up: Recent changes to the proactor raw connection API

I've just finished a recent round of improvements to the raw connection API (these should hit release with proton-c 0.34). The proactor raw connection API now supports 'half' closing: This is equivalent to calling the BSD shutdown(fd, SHUT_RD) or shutdown(fd, SHUT_WR). This adds 2 new API calls:

Re: Some (long awaited?) suggestions to deprecate Python 2 and C++ 03 support

On Wed, 2021-02-03 at 17:53 +, Fraser Adams wrote: > Can I just check something? > The implication from https://qpid.apache.org/download.html is that > the > Python Qpid Messaging API > is > Python2 > only and that same page says

Re: [Discuss] What's the status of -DSYSINSTALL_BINDINGS option in Qpid Proton (and other bindings?)

On Sun, 2021-01-31 at 11:39 +0100, Jiri Daněk wrote: > I remember hearing somewhere that the option  -DSYSINSTALL_BINDINGS > in > Proton is deprecated or should be considered deprecated. You may have heard that from me personally, but it's not been discussed here on the qpid user list! For those

Heads up: Proton Python reconnect changes and impacts

Recently I reworked how the Python binding reconnect logic works - this was in support of a PR raised to improve the Proton.util.BlockingConnection class which previously could not specify more than a single connection url to try. I have changed the reconnect/failover behaviour: Before, the reconn

Some details about Python version support changes (recent and planned)

* As of git sha: 2b64b9b2ece5 (2021-01-08) we've dropped support for Python 2.6. * We're starting to reformat the Python code to make it compliant with PEP8 so that we can run flake8 as part of the regular CI builds with as few suppressions as possible. Once we finish doing this we should requir

Some (long awaited?) suggestions to deprecate Python 2 and C++ 03 support

Python 2 has finally been declared dead (as in unsupported) by its upstream. And every platform that is widely used has a version of python 3 available. From what I can tell a reasonable earliest version of python would now be 3.6 as 3.9 is out and 3.10 is not too far off. C++11 is now 10 years ol

Re: Fwd: Advice sought regarding Pull Request

On Wed, 2020-12-16 at 11:48 +, Pete Fawcett wrote: > Dear Qpid Users > > I was advised to re-send the message below to this mailing list > rather than > the "dev" one - I hope this won't be seen as spamming :-) Just to note (in case you didn't see the PR itself yet) that I have reviewed the P

Re: [VOTE] Release Apache Qpid Proton 0.33.0 (RC3)

As rc1: +1 Built from git tag 0.33.0-rc3 on: FreeBSD 12.2-RELEASE * build; * ctest with valgrind and helgrind - threaderciser fails, but this is not a regression. - Other tests seem to fail but this seems to be a result of valgrind missing code to intercept syscall 570. Raspberyy Pi 4b (a

Re: [VOTE] Release Apache Qpid Proton 0.33.0

On Thu, 2020-11-12 at 15:21 +, Robbie Gemmell wrote: > Hi folks, > > I have put together a spin for a Qpid Proton 0.33.0 release, please > give it a test out and vote accordingly. > > The files can be grabbed from: > https://dist.apache.org/repos/dist/dev/qpid/proton/0.33.0-rc1/ > > The JIRA

Re: [VOTE] Release Apache Qpid Proton 0.32.0

On Tue, 2020-08-25 at 07:45 -0230, Roddie Kieley wrote: > ... > In testing the new examples, raw_echo and raw_connect I saw that > raw_echo > worked ok but raw_connect consistently reported: Neither of these examples actually work at all as raw sockets only works with the epoll proactor not the li

Re: [VOTE] Release Apache Qpid Proton 0.32.0

On Thu, 2020-08-20 at 11:29 +0100, Robbie Gemmell wrote: > Hi folks, > > I have put together a spin for a Qpid Proton 0.32.0 release, please > give it a test out and vote accordingly. +1 - Built and tested on Raspbian (Raspberry PI4) notwithstanding PROTON- 2272. - Built and tested on FreeBSD 12

Re: [VOTE] Release Apache Qpid Proton 0.32.0

On Thu, 2020-08-20 at 14:50 -0400, Chuck Rolke wrote: > -1 > > * checksum matches > * built debug build > * threaderciser self test fails hard with timeout > > Issues with the test: > > - test does not honor ctest --timeout switch. Test always uses 120 > seconds. > - test times out with Debug, R

Re: windows egg?

On Tue, 2020-08-18 at 04:55 +, Terry Rankine wrote: > Hi Guys > > I am having trouble installing python-qpid-proton via pip – nothing I > have tried seems to work, and I have the VS build tools installed, > and I am inside the “build prompt” and then inside that I have opened > the ‘anaconda p

Re: qpid C static build failed

On Tue, 2020-07-21 at 10:06 -0400, Andrew Stitcher wrote: > On Fri, 2020-07-17 at 08:56 -0700, waheed wrote: > > The build fails when built with "BUILD_STATIC_LIBS" option on. The > > branch is > > latest master. The default build is successful though. >

Re: qpid C static build failed

On Fri, 2020-07-17 at 08:56 -0700, waheed wrote: > The build fails when built with "BUILD_STATIC_LIBS" option on. The > branch is > latest master. The default build is successful though. Well spotted - this is the result of some recent changes I've made as a result of updating the minimum language

Re: Figuring out the reason for a delay before a message is sent

On Wed, 2020-07-08 at 08:32 +0200, Ivo Wever wrote: > ... > I figured it out via the C++ examples and documentation; the Ruby > examples miss an example for this and there is not yet a version of > the > general documentation for Ruby. So if you're using the Ruby client, > it's > advisable to also

Re: Qpid Dispatch Router With RabbitMQ and SASL

On Fri, 2020-06-19 at 22:17 +0100, Gordon Sim wrote: > On 19/06/2020 9:40 pm, Andrew Stitcher wrote: > > On Fri, 2020-06-19 at 13:59 +0100, Gordon Sim wrote: > > > ... > > > > > > Looks like it changed back for cyrus-sasl anyway: > > >

Re: Sending a ulong message id via Ruby

On Tue, 2020-06-16 at 17:44 +0200, Ivo Wever wrote: > ... > [1] There is a bug there though: there's an incompatibility between > the > SWIG bindings and Ruby versions above 2.4. The SWIG bindings > assume > a distinction between 'Fixnum' and 'Bignum' types that no longer > exists at th

Re: Qpid Dispatch Router With RabbitMQ and SASL

Can yo just confirm that you are using PLAIN SASL auth - I'd guess that you will be using the cyrus sasl implementation, but if you can confirm that too it would help a little. Andrew On Thu, 2020-06-18 at 17:45 -0700, potato wrote: > Hi, > I'm attempting to use AMQ Inteconnect Router which I bel

Re: Qpid Dispatch Router With RabbitMQ and SASL

On Fri, 2020-06-19 at 13:59 +0100, Gordon Sim wrote: > ... > > Looks like it changed back for cyrus-sasl anyway: > https://github.com/apache/qpid-proton/commit/885d68aeaf522021a35b7b5cecb7c7c53663929b#diff-47e0b33a5461eff21e6cbbd017a969edL123 I don't exactly see where in that change any behaviou

Re: [VOTE] Release Apache Qpid Proton 0.31.0 (RC2)

On Wed, 2020-05-06 at 11:37 -0400, Ken Giusti wrote: > -1 > > My qdrouterd stress test [0] hangs as it runs out of file descriptors > with > 0.31.0-rc2. > The same test runs successfully using 0.30.0. Can you clarify if this test incidentally ran out of fds and then hung, or intentionally tests r

Changing the minimum supported versions of C compilers/python on windows for proton-c

Currently we support Visual Studio 2010 to compile the proton-c core library. The major reason to support earlier versions of Visual Studio compilers on Windows is that we need them to support the qpid-proton binding extension on python 2. I propose that we stop supporting Python 2 on Windows and

Re: [VOTE] Release Apache Qpid Proton 0.31.0 (RC2)

+1 (with some qualifications): Proton c/c++ build; ctest; with python 3 and tox Tested on: Fedora 32 (amd64): gcc 10; valgrind; asan tests - successful. clang 10; failed to compile (C99 issue PROTON-2207) Raspberry Pi 4, arm7 raspbian - Buster: gcc 8.3; asan tests - successful. FreeBSD 12.1p4 am

Re: [Proton-C] Discovery

On Fri, 2019-12-13 at 14:20 +, HADI Ali wrote: > Hello, > > Sorry for the late reply. Thank you for the dev, it allows us to > discover new endpoints when trying to reconnect. > > However there is one use case that we covered in Java with QPID-JMS > that we couldn’t handle in C++. > If at the

Re: [VOTE] Release Apache Qpid Proton 0.30.0

On Mon, 2019-12-09 at 15:59 +, Robbie Gemmell wrote: > Hi folks, > > I have put together a spin for a Qpid Proton 0.30.0 release, please > give it a test out and vote accordingly. > > The files can be grabbed from: > https://dist.apache.org/repos/dist/dev/qpid/proton/0.30.0-rc1/ > > The JIRA

Re: Python Proton Reactor get_connection_address attempts to call non-existent connection.get_address method

On Mon, 2019-12-09 at 14:34 +, Bourne, Mark wrote: > ... > Thanks for the quick confirmation and suggestions. > > As far as I can see from the API documentation, it looks like > Connection.connect_address was only added in version 0.28.0 - is that > correct? Yes, that is correct. > We may

Re: Python Proton Reactor get_connection_address attempts to call non-existent connection.get_address method

I've created PROTON-2153 for this. https://issues.apache.org/jira/projects/PROTON/issues/PROTON-2153 On Wed, 2019-12-04 at 11:38 -0500, Andrew Stitcher wrote: > On Tue, 2019-12-03 at 11:47 +, Bourne, Mark wrote: > > With Python Proton version 0.29.0, the `get_connection_addre

Re: Python Proton Reactor get_connection_address attempts to call non-existent connection.get_address method

On Tue, 2019-12-03 at 11:47 +, Bourne, Mark wrote: > With Python Proton version 0.29.0, the `get_connection_address` > method of `proton.reactor.Reactor` attempts to call > `connection.get_address()`. However, that method doesn't seem to > exist, leading to an exception. Code to reproduce thi

Re: [Qpid-proton-cpp] Performance regression found in 0.29.0

Please raise a JIRA with all this information and the reproducer - it is very hard to track fixes without this. Also you could attach your patch, but it is easier in this case to use a github PR with a reference to the JIRA. The Apache automation will tie them together and this makes it again easi

Re: [VOTE] Release Apache Qpid Proton 0.28.0

On Thu, 2019-05-09 at 17:11 +0100, Robbie Gemmell wrote: > A vote might be more compelling than a recommendation :) > > As things stand, no one has yet voted against releasing, and there > are > currently 3 binding +1 votes, so the vote would pass tomorrow as-is. > I'm thus far inclined to let it

Re: [VOTE] Release Apache Qpid Proton 0.28.0

On Wed, 2019-05-08 at 21:25 -0400, Andrew Stitcher wrote: > ... > > Whats the nature of the issue/fix? Is it only these examples that > > would > > be affected? > > I'll know when I find the fix! It's not entirely clear yet - but it > looks like the ex

Re: [VOTE] Release Apache Qpid Proton 0.28.0

On Wed, 2019-05-08 at 23:23 +0100, Gordon Sim wrote: > ... > > On the other hand it is a regression from 0.27, but not exactly a > > regression for some earlier releases (but with different problems). > > I've gone back through 0.27.1, 0.26.0, 0.25.0, 0.24.0 and 0.23.0 and > in > all those hellow

Re: [VOTE] Release Apache Qpid Proton 0.28.0

On Wed, 2019-05-08 at 10:41 -0400, Andrew Stitcher wrote: > On Wed, 2019-05-08 at 13:29 +0100, Gordon Sim wrote: > > ... > > * ran all python examples (against qpid-cpp broker for those that > >require a broker) > >- the helloworld_direct_tornado.py no longer w

Re: [VOTE] Release Apache Qpid Proton 0.28.0

On Wed, 2019-05-08 at 13:29 +0100, Gordon Sim wrote: > ... > * ran all python examples (against qpid-cpp broker for those that >require a broker) >- the helloworld_direct_tornado.py no longer works (it does work > with > 0.27.1) > Not sure whether this is deliberate or expected.

Re: migration from qpid 0.15 to 0.26

On Tue, 2019-04-09 at 16:30 +, Pam wrote: > Hello, > I was using qpid proton 0.15.The broker is updated and now my proton > stopped to work. It cannot send messages to new broker. > Now with the hope of that it will work "automagically" again, I try > to update qpid proton from 0.15 to 0.26.I s

Please just create the JIRA already... [Was proton cpp container.stop not fully thread safe]

As a matter of policy, it is much better to just create the Jira based on the symptoms and update it as more info becomes known than to front load the process before creating the jira. This is a general point and not restricted to this issue. Yes, I know that I'm as likely to fall foul of this as

Re: python proton reconnect broken on master?

On Wed, 2019-04-03 at 22:58 +0100, Gordon Sim wrote: > ... > I think the issue is that the loss of the socket no longer results in > a > transport_close event? (or that the socket.error is raised and > causes > the loop to exit before processing that event?) Hmm, I think that in the case of a co

Re: python proton reconnect broken on master?

On Wed, 2019-04-03 at 22:58 +0100, Gordon Sim wrote: > On 03/04/2019 10:50 pm, Andrew Stitcher wrote: > > On Wed, 2019-04-03 at 22:02 +0100, Gordon Sim wrote: > > > It looks like the reconnect capability in the python client is > > > broken > > > on

Re: Qpid proton cpp public API

On Wed, 2019-04-03 at 15:19 +0200, Rabih M wrote: > Hello, > > I am using the latest version of proton cpp 0.27.0. > > I have a suggestion for the signature of the messaging handler's > methods: > In my opinion, giving the parameters as references is error prone. > Because > it gives the user the

Re: python proton reconnect broken on master?

On Wed, 2019-04-03 at 22:02 +0100, Gordon Sim wrote: > It looks like the reconnect capability in the python client is broken > on > master. Is this a known issue? Any chance of some more details or a reproducer? The current python bindings *should* work the same (by design) as the previous implem

Re: How to use connection_driver

On Tue, 2019-03-19 at 23:15 -0400, Andrew Stitcher wrote: > ... > > > Can anyone tell me how to proceed? Are there examples that I > > > simply > > > haven't found yet? Or am I barking up entirely the wrong tree > > > here? > > > Any guidanc

Re: How to use connection_driver

On Tue, 2019-03-19 at 21:24 +, Gordon Sim wrote: > On 19/03/2019 8:33 am, Schaik, Jacco van wrote: > > Hello, > > > > > > Absolute beginner in the world of AMQP and Qpid here. > > > > > > I'm trying to set up a C application where the AMQP traffic takes > > place over a socket that is under

Heads Up: Planned merge of Qpid Proton Python IO work

Over the past months I've been reworking the Qpid Proton Python support to only use the Qpid Proton Core library APIs and to do all IO with the built in Python facilities. This work has been sitting in a PR [1] for a month now and I'm ready to merge it with the Qpid Proton master branch. I'll lea

Re: [qpid-cpp] Inconsistent handling of qpid::sys::TimerTask setUpNextFire() and restart() methods

On Fri, 2018-07-20 at 12:52 -0400, Andrew Stitcher wrote: > I've now looked at the actual code! > > Things are a bit more complicated than I remembered: I forgot one semi-important difference between setupNextFireTime() and restart(). setupNextFireTime() is intended to be use

Re: [qpid-cpp] Inconsistent handling of qpid::sys::TimerTask setUpNextFire() and restart() methods

I've now looked at the actual code! Things are a bit more complicated than I remembered: TimerTasks can have two different types of time to trigger them, a target absolute time ("at 3pm on 3 Jan 2016 UTC") and a relative time ("in 300ms"). You can only create one or the other of these TimerTask (

Re: [qpid-cpp] Inconsistent handling of qpid::sys::TimerTask setUpNextFire() and restart() methods

On Fri, 2018-07-20 at 11:27 -0400, Kim van der Riet wrote: > ... > I am using the timer in periodic mode, ie with period set to an > interval Thanks for describing what you are trying to do: As I mentioned earlier your case best matches the one-shot mode not the periodic mode. > ... > The idea i

Re: [qpid-cpp] Inconsistent handling of qpid::sys::TimerTask setUpNextFire() and restart() methods

On Fri, 2018-07-20 at 10:47 -0400, Andrew Stitcher wrote: > On Fri, 2018-07-20 at 15:44 +0100, Gordon Sim wrote: > > ... > > I believe Kim is using restart() but is debugging some issue where > > the > > task is postponed after it has already fired, which he does not

Re: [qpid-cpp] Inconsistent handling of qpid::sys::TimerTask setUpNextFire() and restart() methods

On Fri, 2018-07-20 at 15:44 +0100, Gordon Sim wrote: > ... > I believe Kim is using restart() but is debugging some issue where > the > task is postponed after it has already fired, which he does not want > (not sure why not). Is that right Kim? In that case I think you need to create a new Time

Re: [qpid-cpp] Inconsistent handling of qpid::sys::TimerTask setUpNextFire() and restart() methods

I think I can help shed some light on the original intention of these two methods: Essentially they are intended for different purposes: (As Gordon says) setUpNextFire() is intended only for use with periodic timers and is intended to be used to set up the next firing *after the time has just fire

Re: Problems Building Proton 0.24

If you want to simply build proton without the fuzz tests for whatever reason you should just run cmake with the following option: cmake ... -DENABLE_FUZZ_TESTING=OFF or use ccmake to toggle that option. You have no need to patch the source. Having said that, we do test building proton on RHEL 6

Re: Seeking opinions: Change to proton-c SASL mechanisms semantics

On Tue, 2018-06-19 at 21:45 +0100, Gordon Sim wrote: > ... > I do think perhaps the error handling/communication on the client > side > could be better in proton. > > With qpid::messaging you get an error that while not exactly clear > at > least indicates that the issue is with GSSAPI; the prot

Re: Seeking opinions: Change to proton-c SASL mechanisms semantics

On Tue, 2018-06-19 at 19:32 +0100, Gordon Sim wrote: > On 19/06/18 19:25, Alan Conway wrote: > > What do you think the default > > server configuration should be? Should we default to excluding the > > offending mechs on the server side by default? > To my mind the entire point of this change is

Re: Seeking opinions: Change to proton-c SASL mechanisms semantics

Thanks everyone for their thoughts: I've considered the feedback, especially Gordon's point that the server mechanisms are already configured using the SASL configuration file which you need in any case to set up the authenticatino db. I think the issue is still enough of a speed bump to new deve

Re: Seeking opinions: Change to proton-c SASL mechanisms semantics

mech installed. If you are implementing a server then you will have a config file, but equally you will know if you are inplementing kerberos so setting it up specificially isn't usually a problem either. Andrew On Fri, 2018-06-15 at 18:32 +0100, Gordon Sim wrote: > On 15/06/18 18:02, Andrew S

Re: Seeking opinions: Change to proton-c SASL mechanisms semantics

On Fri, 2018-06-15 at 16:52 +0100, Gordon Sim wrote: > ... > > This is recorded as a JIRA [1] which has been open for a couple of > > years. > > You can of course also specify a mech list in the cyrus sasl config. True, but this is fairly complex - involving a configuration file used for no other

Seeking opinions: Change to proton-c SASL mechanisms semantics

There is a long standing pain point with using cyrus SASL: If you have Kerberos set up in your environment; are authenticated with Kerberos; and have the GSSAPI mechanism installed; but you are not using the ambient Kerberos credential for AMQP. In this case (which is common, at least in Red Hat

Re: pip install python-qpid-proton

On Wed, 2018-05-16 at 18:51 +, Aleksandr Friedman wrote: > Hi, > > I am trying to install the library on Windows 7 with Python 2.7.12, > but the install fails with errors below, please advise? Am I missing > a prerequisite? No, at present "pip install python-qpid-proton" does not work on win

[Proton Python binding] Heads Up: Removing support for python versions before 2.6

I've been doing some work on the proton python code recently and I've noticed we're carrying around code to support python 2.5 and perhaps even 2.4. The only Python 2 version that is still maintained by python.org is 2.7. But RHEL 6/CentOS 6 still support Python 2.6. So I've started removing the

Re: Building proton from master fails on Red Hat Enterprise Linux Server release 7.3 Maipo with "fatal error: bits/c++config.h: No such file or directory"

On Tue, 2018-04-03 at 10:56 +0100, Keith W wrote: > ... > Thanks for the replies. The 7.3 Maipo image in question is > corporatised by our organisation, so it could be special in this > respect. "corporatised" sounds like an archaic swear word! A ---

Re: Building proton from master fails on Red Hat Enterprise Linux Server release 7.3 Maipo with "fatal error: bits/c++config.h: No such file or directory"

On Mon, 2018-04-02 at 17:15 +0100, Oleksandr Rudyy wrote: > Hi Andrew, > > In Red Hat Enterprise Linux Server release 7.3 I found file > /usr/include/c++/4.8.2/i686-redhat-linux/bits/c++config.h which was > installed as part of libstdc++-devel. > > rpm -qf /usr/include/c++/4.8.2/i686-redhat-linux

Re: Building proton from master fails on Red Hat Enterprise Linux Server release 7.3 Maipo with "fatal error: bits/c++config.h: No such file or directory"

On Fri, 2018-03-30 at 10:29 +0100, Oleksandr Rudyy wrote: > Hi, > > As per subject the master proton build fails with the error like > below: > > [ 44%] Building CXX object > proton-c/bindings/cpp/CMakeFiles/qpid-proton-cpp.dir/src/binary.cpp.o > In file included from > /home/alex/qpid-proton/pro

Re: AMQP map ordering guarantees on the C++ binding

On Thu, 2018-03-15 at 15:54 -0400, Kim van der Riet wrote: > When creating an AMQP map body, using > > std::map map; > > to represent the map, and once its values have been set, > > proton::message msg; > msg.body(map); > > is a convenient way to set the message body. However, in practice, I >

Initial results from reducing proton-c coding effort

I've now checked in my work to reduce some of the known coding overhead in proton-c. There were 3 parts to this: 1. Stop generating nulls at the end of described lists - if they are not there the decoder must assume they are null - defualt values. 2. Generate nulls instead of default values ever

Re: Issue building qpid-proton on Fedora

On a hunch I discovered the problem you are having: Reported as https://issues.apache.org/jira/browse/PROTON-1747 . For you the workaround is to make sure you have the openssl dev package installed - you will want that anyway to do encryption and maybe authentication - you might also want to have

Re: Issue building qpid-proton on Fedora

at 17:50 -0500, Andrew Stitcher wrote: > This is very puzzling: Fedora is a very common build platform for the > Proton-c developers and F26 and F27 are both heavily used. > > However, we've have had some problems like this before (but they > should > be fixed now) could you conf

Re: Issue building qpid-proton on Fedora

This is very puzzling: Fedora is a very common build platform for the Proton-c developers and F26 and F27 are both heavily used. However, we've have had some problems like this before (but they should be fixed now) could you confirm the version of source code you are using. It would also help to

Re: Proposed update to minimum tool requirements for proton-c

On Fri, 2017-10-20 at 22:22 +0100, Robbie Gemmell wrote: > ... > > While I have no objections to the change in general, it'd be a bit > > surprising to me as a user to have these sorts of changes go into > > an 0.18.1 > > release where I'd really be expecting only minor tweaks / bug fix > > type >

Proposed update to minimum tool requirements for proton-c

In the course of the 0.18 release process I've been looking at the minimum build tool versions supported - specifically CMake and C/C++ compilers. I've reached the following conclusions: We should move to a minimum supported cmake of 2.8.12.2, gcc 4.4.7 & Visual Studio 2010. - The oldest Linux d

Re: [VOTE] Release Apache Qpid Proton 0.18.0

Some more problems found on FreeBSD and building with a libuv proactor on Linux: PROTON-1642, PROTON-1643, PROTON-1644, PROTON-1645 Everything I've found today is all either on uncommon platforms (RPi, FreeBSD) or using the less tested libuv proactor. So despite finding these, it's actually not

Re: [VOTE] Release Apache Qpid Proton 0.18.0

Not a vote yet: Testing the rc on my RPi3: OS: Raspbian Stretch (very close to Debian 9) All goes well except for 2 failures in the ruby-data-spec test. It's not clear to me if this is a serious issue with the ruby binding or not. Raised as PROTON-1640 [1]. I suspect the issue is somehow to do

Re: [VOTE] Release Apache Qpid Proton 0.18.0

On Thu, 2017-10-19 at 13:57 -0400, Ted Ross wrote: > Adel, > > I saw the same error.  I then noticed that I had not installed the > cyrus-sasl packages.  Once I installed these packages, the pthread- > once > error went away.  Not that I understand why, but that's what I saw. Could you report thi

Re: [VOTE] Release Apache Qpid Proton 0.18.0

On Thu, 2017-10-19 at 17:36 +, Adel Boutros wrote: > If the fix is quick, I prefer to have it natively in 0.18.0. > Otherwise, I will have to have a local patch to disable it and thus > will have to build a custom version of proton. I don't think this test failure is a reason to respin. The o

Re: [VOTE] Release Apache Qpid Proton 0.18.0

On Thu, 2017-10-19 at 16:58 +, Adel Boutros wrote: > Hello Alan and Andrew, > > > Indeed, in the attached log, I am just showing you the latest failure > I had which is a unit test failing. As for the previous errors, I was > able to fix them by adding "-pthread"  and "-DBUILD_RUBY=NO" to my

Re: [VOTE] Release Apache Qpid Proton 0.18.0

On Thu, 2017-10-19 at 16:58 +, Adel Boutros wrote: > Hello Alan and Andrew, > > > Indeed, in the attached log, I am just showing you the latest failure > I had which is a unit test failing. As for the previous errors, I was > able to fix them by adding "-pthread"  and "-DBUILD_RUBY=NO" to my

Re: [VOTE] Release Apache Qpid Proton 0.18.0

On Thu, 2017-10-19 at 16:40 +, Adel Boutros wrote: > Re-attaching the log as it seems the mailing server rejected the > first one. The log isn't useful to me as you don't show the build failure. I guess you've added your patch. Just adding to CMAKE_C_FLAGS isn't a solution - it's a work around

Re: [VOTE] Release Apache Qpid Proton 0.18.0

On Thu, 2017-10-19 at 16:38 +, Adel Boutros wrote: > Hello Andrew, > > Yes, we are using a gcc which we built without any patching. Hmm, could you check that the system supplied gcc behaves differently from your own compiled version? That might give us a clue. > > Just note that we are usin

Re: [VOTE] Release Apache Qpid Proton 0.18.0

On Thu, 2017-10-19 at 16:25 +, Adel Boutros wrote: > Hello Robbie, > > > It is GCC 4.9.2 on Red Hat Enterprise Linux Server release 6.4 Are you using a custom compiler? As far as I know RHEL6 has gcc 4.4.7. Andrew - To un

  1   2   3   4   >