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
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
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 dshea...@novetta.comwrote:
Thanks for the help.
A couple of things... being able to configure lifetime policies on the
broker based
...@redhat.com 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
to that in qpid 0.26. Problem is that I need to have the solution work on
RHEL6
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 g...@redhat.com wrote:
On 01/10/2014 03:05 PM, Shearer, Davin wrote:
If I'm subscribing to a node named
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 g...@redhat.com wrote:
On
is 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 g...@redhat.com wrote:
On 01/10/2014 02:26 PM, Shearer, Davin wrote:
I took some python code from Apache Dispatch Router
Ross tr...@redhat.com 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.
So to get this straight... proton sends '#' to the qpid broker, which
in
turn generates a node name which it then sends back
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
/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 dshea...@novetta.comwrote:
Want to create all libraries statically and boost statically, so updated
the CMakeLists.txt to make that happen (I'm not an expert
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 dshea...@novetta.com wrote:
Want to create all libraries statically and boost
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 g...@redhat.com wrote:
On 01/14/2014 09:48 PM, Shearer, Davin wrote:
Thanks
at 9:51 AM, Shearer, Davin dshea...@novetta.comwrote:
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 argument). In my
CMakeLists.txt in cpp
-proton_PREFIX:INTERNAL=
920:PROTON_libqpid-proton_VERSION:INTERNAL=
Hope it helps.
On Wed, Jan 15, 2014 at 10:10 AM, Shearer, Davin dshea...@novetta.comwrote:
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
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
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
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
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
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 ]
Any chance for this patch to make it into the upcoming 0.26 release?
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
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.
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 g...@redhat.com wrote:
On 01/20/2014 03:09 PM, Shearer, Davin wrote:
Any chance for this patch
I appreciate it immensely, thanks guys!
On Mon, Jan 20, 2014 at 4:23 PM, Gordon Sim g...@redhat.com 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 me if it were
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)
fail the same assertion.
That gives us a little more to go on.
On Tue, Jan 21, 2014 at 8:32 AM, Gordon Sim g...@redhat.com 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 with the static linking
astitc...@redhat.comwrote:
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 dynamic libraries, we want to build using
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
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=4099UP,BROADCAST,MULTICAST mtu 1500
ether f0:1f:af:2e:d8:94 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
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
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 gross,
Ah, do you suspect it's an initialization ordering issue? I'll add the
break point and try it out!
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
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
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 http://gnu.org/licenses/gpl.html
This is free software: you
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
Good suggestions Andrew. How does RPATH with with relocatable RPMs?
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.
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
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.
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
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 robbie.gemm...@gmail.comwrote:
On 23 January 2014 22:25, Shearer, Davin dshea...@novetta.com wrote:
Ah, OK, I thought they'd both use the same REST API as documented
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.
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 astitc...@redhat.comwrote:
On Sat, 2014-01-25 at 16:05 +, Fraser Adams wrote:
...
One of my colleagues mentioned to me that he
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
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
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 to the
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 */
Hi Rafael,
Duplicates are acceptable, message loss is not. I'll handle any duplicates
outside of messaging.
Anyone know why the qpid-cpp-client-devel package went MIA for CentOS6?
-0400, Shearer, Davin wrote:
Anyone know why the qpid-cpp-client-devel package went MIA for CentOS6?
Strange. I just checked their repo [1] and see that all of the Qpid
devel packages are gone. I don't know why, though.
[1] http://mirror.centos.org/centos/6/os/x86_64/Packages/
--
Darryl L
. We've sent word on their mailing list.
On Thu, Mar 13, 2014 at 9:57 AM, Darryl L. Pierce dpie...@redhat.comwrote:
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 development packages
52 matches
Mail list logo
