On 23 January 2014 23:54, Fraser Adams wrote:
> Hey Davin,
> Robbie has hit the nail on the head. One somewhat unfortunate thing that
> you probably ought to be aware of is that the management and monitoring for
> the Qpid C++ and Java Brokers got somewhat erm "fragmented" for various
> reasons ba
As one small example: one of your URLs had a
virtualhost name in it, but the C++ broker doesnt use named/multiple
virtualhosts and thus that part just doesnt map particularly nicely between
the two.
Robbie
FWIW I did actually make an attempt to do something useful wrt.
virtualhosts (though "
Hey Davin,
Robbie has hit the nail on the head. One somewhat unfortunate thing that
you probably ought to be aware of is that the management and monitoring
for the Qpid C++ and Java Brokers got somewhat erm "fragmented" for
various reasons back in the mists of time.
The C++ Broker uses Qpid M
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
> >
> >
> http://qpid.apache.org/relea
On 23 January 2014 22:25, Shearer, Davin wrote:
> 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
> .
>
Alas no, as per the URL those are the docs for t
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
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
On Thu, 2014-01-23 at 15:23 -0500, Andrew Stitcher wrote:
> ...
> Another possibility would be to rewrite the rpaths on installation - I
> also don't know if rpm does that automatically, but it would be possible
> to use readelf/elfedit or objcopy to edit the rpath.
Actually there are a couple of
On Thu, 2014-01-23 at 13:46 -0500, Shearer, Davin wrote:
> 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 pat
Thats a little hard to parse, and all the more difficult to reason about
without additional detail hehe. Regardless, it does sound like anything
workable using groups would involve more change to your systems than you
want.
One last thing to note which occurred to me. You mention listeners, which
On 23 January 2014 19:27, Shearer, Davin wrote:
> 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 1
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
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.
Good suggestions Andrew. How does RPATH with with relocatable RPMs?
Sorry for the goose chase about grepping for symbols.
Amqp1.0 support is supplied by library qpid-proton.dll.
This is a dependent of qpidmessaging.dll.
If qpid-proton.dll is a dependent and your executable refuses to run without it
then amqp1.0 support is enabled.
X:\>dumpbin /dependents qpidm
On Thu, 2014-01-23 at 11:21 -0500, Shearer, Davin wrote:
> 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
> s
On 01/22/2014 05:14 PM, m4tthall wrote:
Chuck Rolke wrote
From a Visual Studio (version of which matches your build) command prompt:
dumpbin /all qpidcommond.dll| findstr /i charsequence
dumpbin /all qpidmessagingd.dll | findstr /i charsequence
If any symbols are listed then amqp1.0 sup
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
Hi
I'm trying to enable "full" logging in a QPid C++ 0.14 application via
export QPID_LOG_ENABLE="trace+"
but I don't really get a lot of extra information. I'm wondering,
though, if the reason is that I also set up for somewhat more limited
logging in the application, like this:
qpid::
So, assuming that dump means that AMQP 1.0 support is included, any thoughts
on what is going wrong?
Thanks,
Matt
--
View this message in context:
http://qpid.2158936.n2.nabble.com/Connecting-to-RabbitMQ-using-Qpid-Messaging-API-and-NET-using-AMQP-1-0-tp7603069p7603154.html
Sent from the Apac
On 01/23/2014 03:37 AM, Xiong Zou wrote:
I can see that QPID supports my design target. If all messages published
will be persistent by default in C++ APIs as well, then that will be
perfect.
In the c++ client messages are not durable by default. However you can
set them to be durable using th
21 matches
Mail list logo
