Re: The fate of the qpid-cpp-client-devel pacakge on CentOS6

lem for us. We've sent word on their mailing list. On Thu, Mar 13, 2014 at 9:57 AM, Darryl L. Pierce wrote: > On Thu, Mar 13, 2014 at 09:50:29AM -0400, Shearer, Davin wrote: > > And to compound things, a yum update which included qpid updates removed > > the incompatible developmen

Re: The fate of the qpid-cpp-client-devel pacakge on CentOS6

And to compound things, a yum update which included qpid updates removed the incompatible development packages that were installed previously causing our builds to crash and burn. On Thu, Mar 13, 2014 at 9:41 AM, Darryl L. Pierce wrote: > On Wed, Mar 12, 2014 at 02:56:44PM -0400, Shearer, Da

The fate of the qpid-cpp-client-devel pacakge on CentOS6

Anyone know why the qpid-cpp-client-devel package went MIA for CentOS6?

Re: Transaction safety in AMQP 1.0 via proton

Hi Rafael, Duplicates are acceptable, message loss is not. I'll handle any duplicates outside of messaging.

Re: Transaction safety in AMQP 1.0 via proton

Ok, I think I've found the solution to this. I want to treat the period from recv to send to be transactional. So here's what I've got: pn_messenger_t * pMessenger... pn_message_t * pMessage(pn_message()); ... recv side ... /* Set incoming window to 1 message */ pn_messenger_set_incoming_windo

Transaction safety in AMQP 1.0 via proton

Hello, I have two queues and a few services that receive from one queue (call it "inbox") process the data received, then sends the processed data to the other queue (call it "outbox"). Is there a sane way using proton to fetch the content of the message from the "inbox", process the data, send t

Re: [VOTE] Release Qpid 0.26

+1 -- Dynamic queue getting "delete on close" attribute set is working. Tested using proton v0.6 Messenger using both Python and C clients. -- Davin Shearer

Proton v0.6 on Fedora 19 - tool aborts when given --help

Did a yum update today on my Fedora 19 machine and was happy to see that proton v0.6 is now available on the system. Package Arch VersionRepository Size =

Re: QMF REST API - was Re: How to use lifetime policies

By having this transport and messaging layer, I can swap out the broker management implementations (hopefully) without changing the API. If my customers demand that I support a different AMQP 1.0 vendor, then I can load in a different management module. If they have a REST API, then I take on no

Re: QMF REST API - was Re: How to use lifetime policies

On Tue, Jan 28, 2014 at 1:39 PM, Fraser Adams wrote: > Glad that I was able to help out. > I'm a little bit curious why you're choosing to go with the REST interface > directly? What language are you programming in. > I am programming this piece in C (messaging and transport layer of a larger sy

Re: QMF REST API - was Re: How to use lifetime policies

m and it created a queue called "davin_test2", so I think what > I've just said is accurate, yay!! > > > The available properties for Queues and exchanges isn't brilliantly > documented in the QMF Management Schema > (or anywhere really) and I kind of "reverse

Re: Qpid's move to CMake and effect on performance.

Right, it will create a *separate RPM* with symbols, so if folks need to debug, they use the debuginfo-install tool and if you ship a debuginfo RPM, it will install the symbols. For most folks, this arrangement is fine. ​

Re: Qpid's move to CMake and effect on performance.

FYI -- by default rpmbuild strips symbols, effectively making Release and RelWIthDebinfo the same thing. On Mon, Jan 27, 2014 at 10:06 AM, Andrew Stitcher wrote: > On Sat, 2014-01-25 at 16:05 +, Fraser Adams wrote: > > > ... > > One of my colleagues mentioned to me that he reckons that there

Re: How to use lifetime policies

Thanks for filling me in! Is there any documentation on the C++ REST API? On Thu, Jan 23, 2014 at 6:12 PM, Robbie Gemmell wrote: > On 23 January 2014 22:25, Shearer, Davin wrote: > > > Ah, OK, I thought they'd both use the same REST API as documented here > > >

Re: How to use lifetime policies

Ah, OK, I thought they'd both use the same REST API as documented here http://qpid.apache.org/releases/qpid-0.24/java-broker/book/Java-Broker-Configuring-And-Managing-HTTP-Management.html. To me the language that the broker is written in is an implementation detail. Would it not make sense to laye

Re: No transports are listening for incoming connections

I think I'll stick with moving the compiled executables to libexec/{bin,sbin} and putting a little shell script executer in bin or sbin with the same name. The java tools follow this same strategy for their CLASSPATH management. Patching up .so files as a post install hook seems gross to me. BTW

Re: How to use lifetime policies

I've got the rest API up and attached to my broker. I can log into it using my browser and even create new queues using the web app. What I can't seem to use is curl for doing REST interactions. For instance, I fire up the C++ broker on 127.0.0.1 on port 5673, then startup the REST API using the

Re: No transports are listening for incoming connections

Sorry, missed an important word in my question above: How does RPATH *work* with relocatable RPMs? These are RPMs where the installer can change the install prefix. With the shell scripts I can discover the location since the path will be relative to the script itself. ​

Re: No transports are listening for incoming connections

Good suggestions Andrew. How does RPATH with with relocatable RPMs? ​

Re: No transports are listening for incoming connections

Andrew, Thanks for the help. Your explanation is on the mark. I'm disappointed that I wasn't able to link the broker against static versions of the qpid libraries, but its clear that they were never really designed to support static linking (as we've discovered). Instead of having to maintain a

Re: No transports are listening for incoming connections

This further confirms that there are no transports loaded: [davin@laptop24 qpid]$ gdb usr/local/sbin/qpidd GNU gdb (GDB) Fedora 7.6.1-46.fc19 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you

Re: No transports are listening for incoming connections

Andrew, here is a copy of my debugging session, setting the breakpoint on the method you asked me to set it on: [davin@laptop24 qpid]$ gdb usr/local/sbin/qpidd GNU gdb (GDB) Fedora 7.6.1-46.fc19 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later

Re: No transports are listening for incoming connections

Ah, do you suspect it's an initialization ordering issue? I'll add the break point and try it out!

Re: No transports are listening for incoming connections

Let's check the broker to see if it is loading a system library that it shouldn't be: [davin@laptop24 qpid]$ ldd usr/local/sbin/qpidd linux-vdso.so.1 => (0x7fff713fe000) libuuid.so.1 => /lib64/libuuid.so.1 (0x0037d000) libsasl2.so.3 => /lib64/libsasl2.so.3 (0x0

Re: My experience building proton v0.6 statically

Believe me, I tried several different ways of adding the flags without resorting to the "nuclear" option of patching the build. IMHO, the most kosher way would be to support something like -DCMAKE_C_FLAGS:STRING="-fPIC -DPIC". I didn't try defining CC with the flag there. That seems a little gro

Re: No transports are listening for incoming connections

Another data point: If I use the one that comes with Fedora19, it comes up fine: [davin@laptop24 qpid]$ which qpidd /usr/sbin/qpidd [davin@laptop24 qpid]$ /usr/sbin/qpidd --log-enable=info+ --auth=no --port=5673 --interface=127.0.0.1 2014-01-21 12:55:48 [Broker] info Management enabled 2014-01-21

Re: No transports are listening for incoming connections

In this case it could be that the address 127.0.0.1 is not actually set > up on any interface. > Ok, let's check that: [davin@laptop24 qpid]$ ifconfig em1: flags=4099 mtu 1500 ether f0:1f:af:2e:d8:94 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0

Re: My experience building proton v0.6 statically

> Ok, I see your need now - clearly this sort of use will remain a patch > you will need to apply by yourself (although the facility to make a > correct non PIC static library will be generally useful). > > If we support a static proton build, at least provide an option for PIC, like some auto{conf

Re: My experience building proton v0.6 statically

ot be able to link libqpid-proton.a into amqp.so. I didn't mention security implications because it wasn't the reason for needing the PIC. Hope it helps! On Tue, Jan 21, 2014 at 10:03 AM, Shearer, Davin wrote: > Hi Andrew, thanks for your reply! > > The PIC is because

Re: My experience building proton v0.6 statically

wrote: > On Mon, 2014-01-20 at 12:09 -0500, Shearer, Davin wrote: > > I would like to share my experience with building proton version 0.6 as a > > static library. > > ... > > > and since we'll want to support linking this against > > modules and/or

Re: void qpid::sys::Mutex::lock(): Assertion `0' failed

also fail the same assertion. That gives us a little more to go on. On Tue, Jan 21, 2014 at 8:32 AM, Gordon Sim wrote: > On 01/20/2014 02:50 PM, Shearer, Davin wrote: > >> Just loading the amqp.so and asking for help causes an assertion failure. >> > > I assume this wi

Re: void qpid::sys::Mutex::lock(): Assertion `0' failed

Here's the last bit of an strace of the same command: ... write(1, " --topic-patterns PATTERN Patt"..., 57 --topic-patterns PATTERN Pattern for on-demand topics ) = 57 write(1, "\n", 1 ) = 1 dup(2) = 3 fcntl(3, F_GETFL)

Re: request for 0.26 (was Re: How to use lifetime policies)

I appreciate it immensely, thanks guys! On Mon, Jan 20, 2014 at 4:23 PM, Gordon Sim wrote: > On 01/20/2014 05:13 PM, Shearer, Davin wrote: > >> I know it's late in the cycle and I just realized this AM that the fix was >> not included, but it would be really helpful to

Re: request for 0.26 (was Re: How to use lifetime policies)

I know it's late in the cycle and I just realized this AM that the fix was not included, but it would be really helpful to me if it were included. On Mon, Jan 20, 2014 at 10:52 AM, Gordon Sim wrote: > On 01/20/2014 03:09 PM, Shearer, Davin wrote: > >> Any chance for this patc

My experience building proton v0.6 statically

I would like to share my experience with building proton version 0.6 as a static library. First create a directory somewhere sensible to put the code and do the build. I put mine in $HOME/external/proton. Lets call that BUILD_HOME. Unarchive the proton v0.6 source code into that directory. expo

How the experts build and package releases

I need to build and package qpid with amqp 1.0 support with dynamic queue creation and auto-delete on close. Target platforms are RHEL6 and RHEL5 (OpenSuSe is a nice bonus) which are all RPM-based. These systems come with their own versions of qpid and boost, so the package will need to live in h

Re: How to use lifetime policies

Any chance for this patch to make it into the upcoming 0.26 release?

No transports are listening for incoming connections

[davin@laptop24 qpid]$ usr/local/sbin/qpidd --log-enable=info+ --auth=no --port=5673 --interface=127.0.0.1 2014-01-20 09:54:31 [Broker] info Management enabled 2014-01-20 09:54:31 [Management] info ManagementAgent restored broker ID: c792c487-cc25-46aa-805a-5260ca7b8a81 2014-01-20 09:54:31 [Broker]

void qpid::sys::Mutex::lock(): Assertion `0' failed

Just loading the amqp.so and asking for help causes an assertion failure. [davin@laptop24 qpid]$ usr/local/sbin/qpidd --load-module=/home/davin/stash/exit2xx/external/qpid/qpid/usr/local/lib64/qpid/daemon/amqp.so --help Usage: qpidd [OPTIONS] Options: -h [ --help ] Disp

Re: How to use lifetime policies

Happy to report that I've built the java tools. Frase nailed it. QPID_HOME was set wrong. I had it set at the top level qpid directory instead of src/java/build. So all I needed to build was to set: QPID_HOME=/home/davin/external/qpid/src/java/build CLASSPATH=/home/davin/external/qpid/src/java/

Re: How to use lifetime policies

Hi Frase, So still no dice. What jar file has javax.jms.* (like javax.jms.Connection)? I put qpid-all.jar in my CLASSPATH, failed, then explicitly added all the jar files in qpid/src/java/build/lib: export CLASSPATH=$(for j in /home/davin/external/qpid/src/java/build/lib/*.jar; do echo -n "$j:"

Re: How to use lifetime policies

Hi Frase, I'm very interested in the REST API for the C++ broker and I've got git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@155854913f79535-47bb-0310-9956-ffa450edef68 checked out. I went into the qpid/java directory and ran: ant -f build.xml build BUILD SUCCESSFUL Cool, so then I w

Re: How to build qpid with proton v0.5, boost v1.55.0 statically on fedora19

OK, got it built and I'm pleased that ldd on the executables and modules reports nothing about qpid, proton and boost and I have a nice set of libqpid*.a files available for static linking. What I had to do was expand all the -lqpid-proton to /path/to/lib/libqpid-proton.a in all the link.txt files

Re: How to build qpid with proton v0.5, boost v1.55.0 statically on fedora19

bqpid-proton_PREFIX:INTERNAL= 920:PROTON_libqpid-proton_VERSION:INTERNAL= Hope it helps. On Wed, Jan 15, 2014 at 10:10 AM, Shearer, Davin wrote: > The HA section in the CMakeLists.txt file is straightforward. I suspect > that the issue isn't with the HA build itself, but with the flags of its > depe

Re: How to build qpid with proton v0.5, boost v1.55.0 statically on fedora19

ton.pc. On Wed, Jan 15, 2014 at 9:51 AM, Shearer, Davin wrote: > Hi Gordon, > > I put my changes off into a separate branch, switched back to trunk and > re-ran the build on the unmodified source and I've still got the same > problem (HA trying to link proton without the -L

Re: How to build qpid with proton v0.5, boost v1.55.0 statically on fedora19

re suspicion about HA not needing proton (nor ssl nor crypto) is correct and should be removed from the HA build. BTW, if I remove them by hand (-lqpid-proton -lssl -lcrypto), the ha.so module is linked successfully. On Wed, Jan 15, 2014 at 4:47 AM, Gordon Sim wrote: > On 01/14/2014 09:48 PM,

Re: How to build qpid with proton v0.5, boost v1.55.0 statically on fedora19

with that before it is properly distributed you can currently > find it here: http://people.apache.org/~rhs/qpid-proton-0.6rc3/ > > Hopefully someone who can actually help will be along next... > > Robbie > > On 14 January 2014 20:56, Shearer, Davin wrote: > > > Want to cre

Re: How to build qpid with proton v0.5, boost v1.55.0 statically on fedora19

me/davin/external/proton-0.5/lib64 argument that is emitted via pkg-config --libs libqpid-proton. On Tue, Jan 14, 2014 at 3:56 PM, Shearer, Davin wrote: > Want to create all libraries statically and boost statically, so updated > the CMakeLists.txt to make that happen (I'm not an expe

How to build qpid with proton v0.5, boost v1.55.0 statically on fedora19

Want to create all libraries statically and boost statically, so updated the CMakeLists.txt to make that happen (I'm not an expert on cmake, so let me know if this is the wrong way to build static libraries): - diff --git a/qpid/cpp/src/CMakeLists.txt b/qpid/cpp/src/CMakeLists.txt index c77b75

Re: How to use lifetime policies

t;> On Jan 10, 2014, at 13:49, Ted Ross wrote: >>> >>> >>> On 01/10/2014 01:34 PM, Shearer, Davin wrote: >>>> I actually _prefer_ the C++ broker. I was using the java one for the >>>> web >>>> management. >>>> >&g

Re: How to use lifetime policies

s that the qpid broker does not set auto-del on the newly created dynamic queue. If/When that's fixed, I'm golden. Thanks so much! On Fri, Jan 10, 2014 at 11:51 AM, Gordon Sim wrote: > On 01/10/2014 02:26 PM, Shearer, Davin wrote: > >> I took some python code from Apache Di

Re: # node name and other addressing stuff - was Re: How to use lifetime policies

grepping around proton-c for '#' comes up dry. If # isn't sent over the wire, I'd expect to see it dealt with somewhere in the source code. [davin@centos6 proton-c]$ grep '#' src/*.c include/proton/*.h | grep -v ':#' On Fri, Jan 10, 2014 at 10:02 AM, Gordon Sim wrote: > On 01/10/2014 02:45

Re: How to use lifetime policies

I think the behaviour of qpid::messaging is correct. I don't think its out of the question to expect the same behaviour in proton messenger. On Fri, Jan 10, 2014 at 10:11 AM, Gordon Sim wrote: > On 01/10/2014 03:05 PM, Shearer, Davin wrote: > >> If I'm subscribing to a

Re: How to use lifetime policies

g against. On Fri, Jan 10, 2014 at 10:08 AM, Gordon Sim wrote: > On 01/10/2014 02:26 PM, Shearer, Davin wrote: > >> A couple of things... being able to configure lifetime policies on the >> broker based on the name of the node is a wonderful idea and I look >> forward

Re: How to use lifetime policies

If I'm subscribing to a node named "#" doesn't it make sense that the terminus be marked dynamic automagically? On Fri, Jan 10, 2014 at 9:26 AM, Shearer, Davin wrote: > Thanks for the help. > > A couple of things... being able to configure lifetime policies on the

Re: How to use lifetime policies

Thanks for the help. A couple of things... being able to configure lifetime policies on the broker based on the name of the node is a wonderful idea and I look forward to that in qpid 0.26. Problem is that I need to have the solution work on RHEL6 (which ships with qpid 0.14) if possible. I too

How to use lifetime policies

Hello, Is there a way, using proton and QMF to create a queue that has a lifetime policy other than permanent? If so, how? I am trying to build a transport library in C using proton with support for a qpid broker. What I need to do is create a reply queue. The AMQP 1.0 spec covers creating Dyn