Re: Building Qpid C++ Broker for macOS

exploring the Qpid project yesterday and noticed that while it > > doesn’t officially support macOS, there have been some online discussions > in the past related to building Proton C++ and, the Dispatch Router for > macOS. I think some of the issues had been test compilation

Re: Building Qpid C++ Broker for macOS

hu, 19 Jan 2023 at 11:42, Emmett Brown wrote: >>> >>> Hello, >>> >>> I was exploring the Qpid project yesterday and noticed that while it >> doesn’t officially support macOS, there have been some online discussions >> in the past related to building Proto

Re: Building Qpid C++ Broker for macOS

it > doesn’t officially support macOS, there have been some online discussions > in the past related to building Proton C++ and, the Dispatch Router for > macOS. I think some of the issues had been test compilation failures. > > > > I haven’t noticed any such similar discussion

Re: Building Qpid C++ Broker for macOS

been test compilation failures. > > I haven’t noticed any such similar discussions related to building the C++ > Broker on macOS. I thought I’d run a quick build myself, to see how far I got. > > Unsurprisingly, the build failed (I’m on Monterey 12.6.2). It was a pthread > API issu

Building Qpid C++ Broker for macOS

. I haven’t noticed any such similar discussions related to building the C++ Broker on macOS. I thought I’d run a quick build myself, to see how far I got. Unsurprisingly, the build failed (I’m on Monterey 12.6.2). It was a pthread API issue. I’ll past the output below if anyone has any idea how

Re: qpid c++ broker status

I used C++ broker for about a decade, it was able to send/receive 85 messages / second (average 500 bytes, with lowest latency possible, near few milliseconds on high load) on a 8-core (16 threads) 64gb RAM SCSI 15k rpm disks, using non-persistent queues and AMQP 0-10. These performance we

Re: qpid c++ broker status

. -- Tom From: Daniil Kirilyuk Date: Monday, October 10, 2022 at 11:02 AM To: users@qpid.apache.org Subject: Re: qpid c++ broker status Broker-J is maintained, although not many people are currently working on it. Regarding the Java 17 compatibility, the issues you pointed out were fixed

Re: qpid c++ broker status

ctiveMQ Artemis is probably the most obvious choice as it has the > > most ongoing activity. > > > > The fact is, as you point out, the c++ broker is not being actively > > maintained. Unless there are people willing to put in some t

Re: qpid c++ broker status

worked with Java 11). Thanks, PGA On 10/10/2022 2:32 AM, Gordon Sim wrote: ActiveMQ Artemis is probably the most obvious choice as it has the most ongoing activity. The fact is, as you point out, the c++ broker is not being actively maintained. Unless there are people willing to put in some time

Re: qpid c++ broker status

The proton bindings will certainly work against activemq artemis. The brokers do have different semantic behaviours in some areas however, so it really depends on how your broker is configured and what behaviours you rely on. On Mon, Oct 10, 2022 at 1:24 PM Jonathan Schaeffer wrote: > > Hello, >

Re: qpid c++ broker status

Hello, would a migration from qpidd to artemis require changes on the clients ? Specifically, clients use python-qpid-proton bindings. Would we need to rewrite client's codes ? Cheers, On 10/10/22 10:32, Gordon Sim wrote: ActiveMQ Artemis -- Jonathan (ﾉ°益°)ﾉ 彡 [ɹǝɟɟǝɐɥɔS] Observatoire

Re: qpid c++ broker status

ActiveMQ Artemis is probably the most obvious choice as it has the most ongoing activity. The fact is, as you point out, the c++ broker is not being actively maintained. Unless there are people willing to put in some time to do that, I think it is better to be clear about how things stand

Re: qpid c++ broker status

the website etc that it is no longer maintained). On Sat, Oct 8, 2022 at 8:44 PM Michael Ivanov wrote: Hallo, Is qpid c++ broker still alive? I see that last release reported on apache page is 1.39.0 from 2018 and last redhat rpm package I can find is for centos7/redhat7 only. When I try to build

Re: qpid c++ broker status

wrote: > > Hallo, > > Is qpid c++ broker still alive? I see that last release reported on apache > page is 1.39.0 from 2018 and last redhat rpm package I can find is for > centos7/redhat7 only. When I try to build it on rocky9 it fails because > of missing python2 packa

qpid c++ broker status

Hallo, Is qpid c++ broker still alive? I see that last release reported on apache page is 1.39.0 from 2018 and last redhat rpm package I can find is for centos7/redhat7 only. When I try to build it on rocky9 it fails because of missing python2 packages. Best regards, -- Michael Ivanov

Re: Qpid C++ Broker Segfault

On Tue, Feb 8, 2022 at 8:11 PM Pete Fawcett wrote: > Would you prefer that I submit a Pull Request for the current fixes or wait > until further changes are made? Either way - To unsubscribe, e-mail:

Re: Qpid C++ Broker Segfault

On Fri, 14 Jan 2022 at 13:59, Gordon Sim wrote: > On Fri, Jan 14, 2022 at 10:36 AM Pete Fawcett wrote: > > I tried this but it didn't, initially, fix the problem. > > It turns out that the current exception handling is causing the link to > be > > closed from within Connection object

Re: Qpid C++ Broker Segfault

On Fri, Jan 14, 2022 at 10:36 AM Pete Fawcett wrote: > I tried this but it didn't, initially, fix the problem. > It turns out that the current exception handling is causing the link to be > closed from within Connection object doDeliveryUpdated >

Re: Qpid C++ Broker Segfault

On Tue, 11 Jan 2022 at 09:35, Pete Fawcett wrote: > Hi Gordon > > Thank you for the helpful response > > On Fri, 7 Jan 2022 at 11:18, Gordon Sim wrote: > >> On Thu, Jan 6, 2022 at 8:56 PM Pete Fawcett wrote: >> > *Questions:* >> > >> > Firstly, a simple work around is to check the link pointer

Re: Qpid C++ Broker Segfault

Hi Gordon Thank you for the helpful response On Fri, 7 Jan 2022 at 11:18, Gordon Sim wrote: > On Thu, Jan 6, 2022 at 8:56 PM Pete Fawcett wrote: > > *Questions:* > > > > Firstly, a simple work around is to check the link pointer when moving > > delivery pointers from 'pending' to completed

Re: Qpid C++ Broker Segfault

On Thu, Jan 6, 2022 at 8:56 PM Pete Fawcett wrote: > *Questions:* > > Firstly, a simple work around is to check the link pointer when moving > delivery pointers from 'pending' to completed and discarding them if the > 'link' is NULL . Does this suffice? I think that would probably work. However

Qpid C++ Broker Segfault

I have recently encountered a problem with the Qpid C++ broker failing due to a segfault. I have done some analysis and believe I have found the cause. I have a proposed workaround, but I also have a question about the desired behaviour and wanted to see what others thought before submitting

Re: visiblity of selectors im use on C++ broker

On Tue, Nov 30, 2021 at 12:26 PM Andy Gibson wrote: > My team are currently in the process of replacing header bindings with > selectors. We're using a python3 proton client and the C++ qpid broker. > We're used to being able to use the QMF console to see what header bindings > are being used

visiblity of selectors im use on C++ broker

Hi, My team are currently in the process of replacing header bindings with selectors. We're using a python3 proton client and the C++ qpid broker. We're used to being able to use the QMF console to see what header bindings are being used to understand the data being routed. Whilst selectors

RE: [EXTERNAL] Re: how to enable AMQP 1.0 and 0-10 for Qpid C++ broker

to amqp1.0. I hope that helps. -Original Message- From: Gordon Sim Sent: Tuesday, August 3, 2021 4:18 PM To: users@qpid.apache.org; Svrankovic11 Subject: [EXTERNAL] Re: how to enable AMQP 1.0 and 0-10 for Qpid C++ broker EXT email: be mindful of links/attachments. On Tue, Aug 3, 2021

Re: how to enable AMQP 1.0 and 0-10 for Qpid C++ broker

On Tue, Aug 3, 2021 at 9:15 PM Svrankovic11 wrote: > I would like to connect to Qpid C++ broker 1.39.0 using different clients > that run AMQP 1.0 and 0-10. How can I turn on both protocol versions for Qpid > C++ Broker? 0-10 is always on, whether you want it or not 1.0 is built as

how to enable AMQP 1.0 and 0-10 for Qpid C++ broker

Hi, I would like to connect to Qpid C++ broker 1.39.0 using different clients that run AMQP 1.0 and 0-10. How can I turn on both protocol versions for Qpid C++ Broker? Thanks for your help. svran

Re: Qpid C++ Broker 1.39 on RHEL 8 ?

On Thu, Jul 8, 2021 at 7:44 PM Steve Charbonneau wrote: > Can someone confirm if the Qpid C++ Broker (v1.39) is also supported for > running on RHEL 8 ? I can confirm it will build and run on RHEL8. However, work on that component has mostly stopped. Have you considered the java broker?

Qpid C++ Broker 1.39 on RHEL 8 ?

Hi, Can someone confirm if the Qpid C++ Broker (v1.39) is also supported for running on RHEL 8 ? Thank you Steve

Re: default limits of qpid-c++ broker, dispatch router, or proton?

It's been a while, but I did a test with just the proton C++ and QpidJMS clients and can get closer to Virgilio's numbers. I think the trouble I was running into was only in the Python Proton library. For whatever reason, it is far slower than the others. -- Sent from:

Re: default limits of qpid-c++ broker, dispatch router, or proton?

we've managed to do ~78 msg /s on qpid-1.36 on 3 qpid broker instances on a intel X5670, 64GB ram, 4x 1gb lan, 16 clients flooding, 16 clients receiving (~48000msg /s on each direction). on a test running on 2011. I'm pretty sure C++ broker is able to do a bit more than your numbers in AMQP-0

Re: default limits of qpid-c++ broker, dispatch router, or proton?

Thanks Chuck! -- Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org

Re: default limits of qpid-c++ broker, dispatch router, or proton?

it out. -Chuck - Original Message - > From: "tomt" > To: users@qpid.apache.org > Sent: Friday, July 10, 2020 3:49:19 PM > Subject: Re: default limits of qpid-c++ broker, dispatch router, or proton? > > You're right about the Python client. We hav

Re: default limits of qpid-c++ broker, dispatch router, or proton?

You're right about the Python client. We have a websocket client utility that connects to the apache webserver and then locally we have a port that opens that we connect the python client to that. I'll try the different combinations. Thanks -- Sent from:

Re: default limits of qpid-c++ broker, dispatch router, or proton?

On 10/07/2020 7:51 pm, tomt wrote: MY configuration is that I have my receivers connecting to the router (through an Apache web server) via websockets. The topics they subscribe to live in the broker. I have link routing configured for this, so I am getting real flow control (based on what I

Re: default limits of qpid-c++ broker, dispatch router, or proton?

MY configuration is that I have my receivers connecting to the router (through an Apache web server) via websockets. The topics they subscribe to live in the broker. I have link routing configured for this, so I am getting real flow control (based on what I read in the link above) -- Sent

Re: default limits of qpid-c++ broker, dispatch router, or proton?

On 10/07/2020 4:58 pm, Robbie Gemmell wrote: When you have the router in between the broker and producer/consumer clients, then what happens will depend on how things have been set up to operate I had assumed you were testing with the broker *or* the router, but re-reading after this I see I

Re: default limits of qpid-c++ broker, dispatch router, or proton?

On Fri, 10 Jul 2020 at 16:54, Gordon Sim wrote: > > On 10/07/2020 4:03 pm, tomt wrote: > > Thanks for the fast response. I spent a good part of the afternoon looking > > into the whole flow control system to understand better given what you had > > asked. > > > > I am using the Python client as

Re: default limits of qpid-c++ broker, dispatch router, or proton?

The behaviour is going to be dependent on how your components are actually configured, so it's hard to say specifics without more detail on how e.g your router and broker are actually configured to work together with the clients. Senders have no ability to control credit, it is granted by the

Re: default limits of qpid-c++ broker, dispatch router, or proton?

On 10/07/2020 4:03 pm, tomt wrote: Thanks for the fast response. I spent a good part of the afternoon looking into the whole flow control system to understand better given what you had asked. I am using the Python client as my receivers and the C++ API as my senders who each synchronously send

Re: default limits of qpid-c++ broker, dispatch router, or proton?

Thanks for the fast response. I spent a good part of the afternoon looking into the whole flow control system to understand better given what you had asked. I am using the Python client as my receivers and the C++ API as my senders who each synchronously send on their own threads as fast as

Re: default limits of qpid-c++ broker, dispatch router, or proton?

On 09/07/2020 3:43 pm, tomt wrote: Hello, I have been trying to determine the highest rate of messages that can be sent at any given time through my environment that includes the qpid-cpp broker and the dispatch router all using AMQP 1.0 (via Proton). There seems to be some maximum cap that

default limits of qpid-c++ broker, dispatch router, or proton?

Hello, I have been trying to determine the highest rate of messages that can be sent at any given time through my environment that includes the qpid-cpp broker and the dispatch router all using AMQP 1.0 (via Proton). There seems to be some maximum cap that only lets me send up to 2500

Re: C++ Broker

A-MQ > solution. > Just to be clear Artemis is part of the ActiveMQ project and not related to Qpid Broker-J -- Rob > With container and another new things happening, could be the new way. > But C++ broker still the fastest and best broker a

Re: C++ Broker

gs happening, could be the new way. > But C++ broker still the fastest and best broker around for me > > On Fri, Mar 6, 2020 at 1:33 PM Robbie Gemmell > wrote: > > > The C++ broker sees occasional bug fixes (some are probably overdue a > > release currently, its been

Re: C++ Broker

RHEL is pushing Dispatcher + Broker-J (Artemis based) as the new A-MQ solution. With container and another new things happening, could be the new way. But C++ broker still the fastest and best broker around for me On Fri, Mar 6, 2020 at 1:33 PM Robbie Gemmell wrote: > The C++ broker s

Re: C++ Broker

The C++ broker sees occasional bug fixes (some are probably overdue a release currently, its been a while), but there isnt active feature development around it. On Fri, 6 Mar 2020 at 15:39, Bruce Parr wrote: > > Hello, > > Is the C++ broker still under development/maintenance, or sho

C++ Broker

Hello, Is the C++ broker still under development/maintenance, or should we start thinking about switching to Broker-J? Thanks, Bruce - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e

Re: [External] Re: Force (C++) broker to drop connection and/or reset session

abled)" error while sending to or receiving from the C++ broker. In then "manually" reopens the connection after a slight delay. As parts of the reconnect logic, I also tend to get "'session-busy: Session detached by peer'". This is possibly triggered by the connect itsel

Re: [External] Re: Force (C++) broker to drop connection and/or reset session

AM Subject: Force (C++) broker to drop connection and/or reset session Another one related to issues I've mentioned in other recent posts: I'm doing some debugging related to undesired side effects in one of our applications after it gets a "Failed to connect (reconnect disabled)"

Re: Force (C++) broker to drop connection and/or reset session

receiving from the C++ broker. In then "manually" reopens the connection after a slight delay. As parts of the reconnect logic, I also tend to get "'session-busy: Session detached by peer'". This is possibly triggered by the connect itself, but it could also come from ot

Re: Force (C++) broker to drop connection and/or reset session

- > From: "Toralf Lund" > To: users@qpid.apache.org > Sent: Friday, March 29, 2019 8:26:21 AM > Subject: Force (C++) broker to drop connection and/or reset session > > Another one related to issues I've mentioned in other recent posts: > > I'm doing some d

Force (C++) broker to drop connection and/or reset session

Another one related to issues I've mentioned in other recent posts: I'm doing some debugging related to undesired side effects in one of our applications after it gets a "Failed to connect (reconnect disabled)" error while sending to or receiving from the C++ broker. In then

Re: C++ Broker - Limiting Connections based on ProcId

On 04/03/2019 10:59 pm, Weibel, David C wrote: Hi, I inherited an existing application leveraging the Apache QPid C++ broker. According to my those before me things have been working fine for years. Although I'm starting to suspect they were just lucky. Recently I was tasked to migrate

C++ Broker - Limiting Connections based on ProcId

Hi, I inherited an existing application leveraging the Apache QPid C++ broker. According to my those before me things have been working fine for years. Although I'm starting to suspect they were just lucky. Recently I was tasked to migrate this application to docker/swarm. The side

C++ broker JournalInactive couldn't setup next timer firing

Hi, I am evaluating C++ broker 1.37 to replace old RH MRG. During testing I found errors in the log: 2018-03-20 16:54:43 [System] error JournalInactive:mti.int.mti.queue couldn't setup next timer firing: -345201964ns[500ms] I googled for some clues but found nothing useful except fixed QPID

Re: qpidd C++ broker memory leak on Redhat 6.8?

Unfortunately, we only have 6.8 available. I will see if there is anyway to get a RHEL7 machine setup. -- Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html - To unsubscribe, e-mail:

Re: qpidd C++ broker memory leak on Redhat 6.8?

The problem that I'm familiar with is specific to RHEL6. I'm not aware of any available patch for this issue (if that's even what you are experiencing). Do you have the ability to test using RHEL7? On Mon, Mar 5, 2018 at 3:09 PM, jbelch wrote: > Any other thoughts? It

Re: qpidd C++ broker memory leak on Redhat 6.8?

Any other thoughts? It doesn't seem to be an issue on earlier versions of glibc. Is that correct? If so, is there an OS patch or something? We may have to abandon the qpid broker and go to something else if we can't figure this out. -- Sent from:

Re: qpidd C++ broker memory leak on Redhat 6.8?

I ran overnight and the leak still appears to be present after setting the MALLOC_ARENA_MAX environment variable. -- Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html - To unsubscribe, e-mail:

Re: qpidd C++ broker memory leak on Redhat 6.8?

I've used RHEL MRG (Qpid) in the last 8 years, and what I could say is that qpidd C++ broker never releases back memory to SO. I've found that the queue code use std::vector in some paths, and need to call vector.shrink_to_fit() because std::vector (and some other C++ STL container) never

Re: qpidd C++ broker memory leak on Redhat 6.8?

Hi, I have had a similar problem with a production QPID system, running Cento 6.8 for the past 14 months. I tried the good advice that Ted gave, using the malloc tuning environment variables, but unfortunately this made no difference to our environment. We would get about 5 days out of the

Re: qpidd C++ broker memory leak on Redhat 6.8?

Thanks. I will try it and let you know if it works. -- Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail:

Re: qpidd C++ broker memory leak on Redhat 6.8?

have used the qpidd C++ broker on several projects over the years. I > started using 0.7 about 6 years ago, used 0.20 about 4 years ago, and I am > currently using 0.34. I have noticed a memory leak when running on the > system. qpidd starts out at about 10mb resident memory and the

Re: C++ Broker Performance with large messages

Thank you for the hints. I can confirm that the throughput is far better with QPID Proton 0.20 (and the C++ Broker 0.37). The new results are: 15 seconds for a 300 MB message 23 seconds for a 500 MB message 47 seconds for a 800 MB message (all numbers are averages) Kind Regards, Andreas

Re: C++ Broker Performance with large messages

you, >> Andreas >> >> >> On Tue, Feb 20, 2018 at 10:15 PM, Chuck Rolke <cro...@redhat.com> wrote: >> >>> >>> >>> - Original Message - >>> > From: "Gordon Sim" <g...@redhat.com> >>> >

Re: C++ Broker Performance with large messages

From: "Gordon Sim" <g...@redhat.com> >> > To: users@qpid.apache.org >> > Sent: Tuesday, February 20, 2018 3:36:37 PM >> > Subject: Re: C++ Broker Performance with large messages >> > >> > On 20/02/18 16:51, andi welchlin wrote: >> >

Re: C++ Broker Performance with large messages

<cro...@redhat.com> wrote: > > > - Original Message - > > From: "Gordon Sim" <g...@redhat.com> > > To: users@qpid.apache.org > > Sent: Tuesday, February 20, 2018 3:36:37 PM > > Subject: Re: C++ Broker Performance with large

Re: C++ Broker Performance with large messages

- Original Message - > From: "Gordon Sim" <g...@redhat.com> > To: users@qpid.apache.org > Sent: Tuesday, February 20, 2018 3:36:37 PM > Subject: Re: C++ Broker Performance with large messages > > On 20/02/18 16:51, andi welchlin wrote: > >

Re: C++ Broker Performance with large messages

On 20/02/18 16:51, andi welchlin wrote: Hello all, I tested throughput of the Qpid C++ Broker (compiled as Release). It was tested on a virtual machine with 15 GB RAM. First I sent a 100 MB message into a persistent queue. From sender to receiver it took 16 seconds for one message

C++ Broker Performance with large messages

Hello all, I tested throughput of the Qpid C++ Broker (compiled as Release). It was tested on a virtual machine with 15 GB RAM. First I sent a 100 MB message into a persistent queue. From sender to receiver it took 16 seconds for one message. Afterwards I sent a 300 MB message, this one took

RE: C++ broker flow to disk

Thank you Gordon for the pointers, I have found some more documentation from Jakub Scholz in list archive. Kind regards, Jan > -Original Message- > From: Gordon Sim [mailto:g...@redhat.com] > Sent: Monday, January 22, 2018 4:42 PM > To: users@qpid.apache.org > Subject:

Re: C++ broker flow to disk

On 22/01/18 14:55, Jan Bares, WOOD & Co. wrote: I get qpid-config: error: option --limit-policy: invalid choice: 'flow-to-disk' (choose from 'none', 'reject', 'ring', 'ring-strict') with latest qpid c++ broker 1.37.0. Should I configure some module or is this feature no longer suppo

C++ broker flow to disk

Hi, I get qpid-config: error: option --limit-policy: invalid choice: 'flow-to-disk' (choose from 'none', 'reject', 'ring', 'ring-strict') with latest qpid c++ broker 1.37.0. Should I configure some module or is this feature no longer supported? As https://issues.apache.org/jira/browse/QPID

Re: C++ broker QMF GUI

On 18/01/18 10:27, Jan Bares, WOOD & Co. wrote: Hi, There used to be javascript single page QMF GUI for C++ broker some years ago, is it still in development? Where can I find it? The Java broker has its management console, but it seems to be baked into the broker. The last release I

Re: C++ broker QMF GUI

> wrote: > Hi, > > There used to be javascript single page QMF GUI for C++ broker some years > ago, is it still in development? Where can I find it? The Java broker has > its management console, but it seems to be baked into the broker. > > Kind regards, Jan > > Jan

C++ broker QMF GUI

Hi, There used to be javascript single page QMF GUI for C++ broker some years ago, is it still in development? Where can I find it? The Java broker has its management console, but it seems to be baked into the broker. Kind regards, Jan Jan Bares Calypso / Java Lead Developer Hradecka 10

Re: QPID C++ Broker: Message Routing

On 28/11/17 16:52, andi welchlin wrote: I could do it without a key like: qpid-route route add localhost:9001 localhost:9002 ex '' But will this lead to defined behaviour? With a key given which is empty? For a topic exchange that will I think only match where the routing key is also an

Re: QPID C++ Broker: Message Routing

On 28/11/17 16:48, andi welchlin wrote: Thank you, Gordon. It works. Is it possible to set the route without any key? I do not need it but I had to give it a key, otherwise the qpid-route utility exits with usage output: You could try with '#' (which means everything on a topic exchange). (If

Re: QPID C++ Broker: Message Routing

x --connection-option='{protocol:amqp1.0}' > --content-string "msg1" > > > > I would have expected to see the message with qid-receive but nothing > happened. Did I miss something? > > I am using the C++ broker 1.36.0. > > > Kind Regards, > Andreas > >

Re: QPID C++ Broker: Message Routing

Thank you, Gordon. It works. Is it possible to set the route without any key? I do not need it but I had to give it a key, otherwise the qpid-route utility exits with usage output: - qpid-route route add localhost:9001 localhost:9002 ex Usage: qpid-route

Re: QPID C++ Broker: Message Routing

On 28/11/17 16:19, andi welchlin wrote: Hello, I tried to create a route between exchanges. When I sent a message to the exchange on the first broker I did not get the message when I tried to read from the second broker. What I did is simple: - Startet two qpid daemons one on port 9001 and

QPID C++ Broker: Message Routing

ut 999 ... and sent a message using qpid-send: qpid-send -b localhost:9002 -a ex --connection-option='{protocol:amqp1.0}' --content-string "msg1" I would have expected to see the message with qid-receive but nothing happened. Did I miss something? I am using the C++ broker 1.36.0. Kind Regards, Andreas

Re: HA Cluster using Qpid C++ Broker 1.36.0

; > pointers on what is needed. > > > > On Wed, Nov 8, 2017 at 1:18 PM, Steve Huston <shus...@riverace.com> > wrote: > > > > > I have used the qpid C++ broker in clusters. On RHEL 6. Works very > well. > > > > > > > -Original Message-

Re: HA Cluster using Qpid C++ Broker 1.36.0

; > and > > > a couple of scripts to enable the cluster manager to start, stop and > > > promote Qpid brokers at the appropriate time - the cluster manager > > already > > > knows what the "appropriate time" is based on its liveness and > membership > &g

Re: HA Cluster using Qpid C++ Broker 1.36.0

terested in trying to make it work, I can give you > more > > pointers on what is needed. > > > > On Wed, Nov 8, 2017 at 1:18 PM, Steve Huston <shus...@riverace.com> > wrote: > > > > > I have used the qpid C++ broker in clusters. On RHEL 6. Works

Re: ACL rules for Qpid C++ Broker

Hi Andi, The ACLs for Qpid C++ are modeled after the AMQP 0-10 exchange-binding-queue (EBQ) design. See https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_MRG/1.1/html/Messaging_User_Guide/sect-Messaging_User_Guide-Introduction_to_RHM-The_AMQP_0_10_Model.html for pictures and

Re: ACL rules for Qpid C++ Broker

cd5ef9a11". But different clients might do > it differently. > > Hope this helps. > > Jakub > > > On Fri, Nov 10, 2017 at 3:46 PM, andi welchlin <andi.welch...@gmail.com> > wrote: > > > Hello everyone, > > > > I looked into ACL documentatio

Re: ACL rules for Qpid C++ Broker

f-d211-41c0-97cf-652cd5ef9a11". But different clients might do it differently. Hope this helps. Jakub On Fri, Nov 10, 2017 at 3:46 PM, andi welchlin <andi.welch...@gmail.com> wrote: > Hello everyone, > > I looked into ACL documentation of Qpid C++ broker (1.36.0) and tested i

ACL rules for Qpid C++ Broker

Hello everyone, I looked into ACL documentation of Qpid C++ broker (1.36.0) and tested it a bit. I would like to allow for one usergroup to write to a queue with a specific name, but deny it for all other users. But I saw that i can not do the following: acl allow group1 publish queue name

Re: HA Cluster using Qpid C++ Broker 1.36.0

> On Wed, Nov 8, 2017 at 1:18 PM, Steve Huston <shus...@riverace.com> wrote: > > > I have used the qpid C++ broker in clusters. On RHEL 6. Works very well. > > > > > -Original Message- > > > From: andi welchlin [mailto:andi.welch...@gmail.com] > > > Sen

Re: Solved: C++ Broker: combine bindings and routes

Hello All, I could solve the problem. qpid-send is using amqp 0.10 by default but it needs to use amqp 1.0. Then it works. Kind Regards, Andreas

C++ Broker: combine bindings and routes

Hello All, Please could you help me with a problem combining bindings and routes. I am running Qpid C++ Broker 1.36.0 on Ubuntu. What I want to reach: Producer P1 sends a durable message to a durable queue Q1 at broker B1. B1 sends the message to broker B2 where consumer C1 should read

Re: Possible to set source IP address in queue route setup in C++ broker?

On Wed, 2017-08-23 at 17:58 +0100, Gordon Sim wrote: > On 23/08/17 17:35, Steve Huston wrote: > > - Host A wants to set up a pull route to pull messages from Host B > > - Host A has two IP addresses assigned to it > > - When Host A connects to B, can A specify a particular source IP address > >

Re: Possible to set source IP address in queue route setup in C++ broker?

On 23/08/17 17:35, Steve Huston wrote: - Host A wants to set up a pull route to pull messages from Host B - Host A has two IP addresses assigned to it - When Host A connects to B, can A specify a particular source IP address that B will see it as? Ah, makes sense. Sorry for my confusion, your

RE: Possible to set source IP address in queue route setup in C++ broker?

Thanks for replying, Gordon - sorry for the confusing terms. > On 22/08/17 21:22, Steve Huston wrote: > > I'm using the C++ broker and I am setting up queue pull routes to > > another broker. I want to be able to have my local broker set a > > virtual IP address as the I

Re: Possible to set source IP address in queue route setup in C++ broker?

On 22/08/17 21:22, Steve Huston wrote: I'm using the C++ broker and I am setting up queue pull routes to another broker. I want to be able to have my local broker set a virtual IP address as the IP source address when connecting to the remote broker it will pull from. Is this possible using

Re: Qpid C++ Broker 1.36 Max Connections Per User Option not working

- Original Message - > From: "Chuck Rolke" <cro...@redhat.com> > To: users@qpid.apache.org > Sent: Wednesday, August 23, 2017 11:51:04 AM > Subject: Re: Qpid C++ Broker 1.36 Max Connections Per User Option not working > > > > - Origina

Re: Qpid C++ Broker 1.36 Max Connections Per User Option not working

- Original Message - > From: "Spud Strumpet" <spud.strum...@mail.com> > To: users@qpid.apache.org > Sent: Wednesday, August 23, 2017 11:33:28 AM > Subject: Qpid C++ Broker 1.36 Max Connections Per User Option not working > > Hi, > > I h

Qpid C++ Broker 1.36 Max Connections Per User Option not working

Hi, I have been trying to configure the maximum connections per user but none of the options seem to be having an affect. I have tried various combinations of setting: * --connection-limit-per-user N on the command line, and * quota connections N username in the acl file In the broker

  1   2   3   4   5   6   7   8   >