On Wed, Jan 28, 2015 at 3:36 PM, Justin Ross wrote:
> https://cwiki.apache.org/confluence/display/qpid/Proton+API+layout+proposal
>
> Please take a look. The intention:
>
> - Organize the API consistently across languages, allowing for deliberate
> exceptions
>
> - Put more frequently used ite
On Tue, 2015-01-27 at 10:33 -0500, Ted Ross wrote:
> +1. I like this change.
>
> -Ted
>
> On 01/27/2015 09:53 AM, Gordon Sim wrote:
> > The current engine examples in python make use of an
> > OutgoingMessageHandler, that arranges for a callback to be made when the
> > sender has credit. At pres
On Tue, 2015-01-27 at 09:44 -0500, Michael Goulish wrote:
> I use this field in my 'topologist' gadget that reads topology
> information from a network of qdrouters.
>
> I only have a connection to router A, but I am able to make topo
> requests of the other routers (after I learn their names) by
Ah, sorry... yeah, it also is the C++-Broker. Will try the PN_TRACE_RAW
tomorrow at work & send you the details then.
2015-01-28 20:45 GMT+01:00 Gordon Sim :
> On 01/28/2015 07:42 PM, Gordon Sim wrote:
>
>> On 01/28/2015 06:39 PM, Chuck Rolke wrote:
>>
>>> It looks like the C++ broker from the tr
https://cwiki.apache.org/confluence/display/qpid/Proton+API+layout+proposal
Please take a look. The intention:
- Organize the API consistently across languages, allowing for deliberate
exceptions
- Put more frequently used items closer to hand, and less frequently used
ones out of the way
-
On 01/28/2015 07:42 PM, Gordon Sim wrote:
On 01/28/2015 06:39 PM, Chuck Rolke wrote:
It looks like the C++ broker from the trap address
qpid-0.28/cpp/src/qpid/messaging/amqp/ConnectionContext.cpp:717
That's the client. Is it also using the Qpid c++ broker? Or is it some
other broker?
From th
On 01/28/2015 06:39 PM, Chuck Rolke wrote:
It looks like the C++ broker from the trap address
qpid-0.28/cpp/src/qpid/messaging/amqp/ConnectionContext.cpp:717
That's the client. Is it also using the Qpid c++ broker? Or is it some
other broker?
From the error, it looks like the proton library
I'm creating the messages using the C++-API v0.28 (v0.30 respectively); at
first, the content was a variant map (containing some metadata as well as
the actual content which is a JSON string); I moved the metadata to message
properties (it belongs there anyway...) & stored the JSON as text/plain;
t
It looks like the C++ broker from the trap address
qpid-0.28/cpp/src/qpid/messaging/amqp/ConnectionContext.cpp:717
What client are you using to generate the messages?
- Original Message -
> From: "Gordon Sim"
> To: users@qpid.apache.org
> Sent: Wednesday, January 28, 2015 1:13:31 PM
> Su
On 01/28/2015 04:36 PM, Daniel Wenske wrote:
Hi again,
I just removed qpid 0.28 and replaced it with 0.30; the error persists.
Furthermore, in the last mail I forgot to say that I am using AMQP 1.0.
What broker are you using?
--
Hi Hamid,
Have you tried it without the brackets? E.g.
respAddress = "'ResQueue; {link:{selector:\"uniqueAppID='"+
uniqueAppID+"'\"}}"
That is the way how the selectors for custom properties worked for me when
I was playing with them.
Regards
Jakub
On Wed, Jan 28, 2015 at 5:24 PM, Hamid.Shahid
Hi again,
I just removed qpid 0.28 and replaced it with 0.30; the error persists.
Furthermore, in the last mail I forgot to say that I am using AMQP 1.0.
Cheers,
Daniel
2015-01-28 17:04 GMT+01:00 Daniel Wenske :
> Hi everyone,
>
> currently I am running into a rather weird error: For some mess
Hi,
Is there any equivalent of JMS 'messageSelector' in QPID 0.28 C++ client API
using AMQP 1.0 protocol?
For example in JMS we can create a message receiver like this;
consumer = session.createConsumer(consumerDestination, uniqueAppID)
I want to create a similar one in C++ and this is how I am
Hi everyone,
currently I am running into a rather weird error: For some messages, the
following happens. When I send the message to my broker, in some cases it
comes out as planned at the receiver, while sometimes I run into an
connection error:
Caught exception in state: 3 with event: 1: Error o
On 01/28/2015 10:09 AM, Francois Menard wrote:
Folks,
Is there any intent on qpid obsoleting use of RabiitMQ in openstack ?
Like Gordon said, The OpenStack community will use whatever messaging
solution that they decide meets their needs.
That said, several of us are working on a hybrid br
On 01/28/2015 03:09 PM, Francois Menard wrote:
Is there any intent on qpid obsoleting use of RabiitMQ in openstack ?
No. Decisions about OpenStack should really be discussed in the
OpenStack community, but as someone from the Qpid community who has
spent a little time on an alternate 'driver'
Folks,
Is there any intent on qpid obsoleting use of RabiitMQ in openstack ?
F.
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
Ok, here are the missing details:
I'm using the Java Qpid JMS client for AMQP 1.0 (version 0.30).
The broker I'm connecting to also uses AMQP 1.0 and is from Red Hat (as far
as I know). Actually I don't have other informations about the broker than
the AMQP version.
To make the problem clearer
Hi Erik
Can you tell us a little more about your software stack?
Which Broker/version are you using (Qpid Cpp, Qpid Java, something else
non-Qpid)?
There are two distinct Qpid JMS clients at the moment, the 0-8..0-10 client
(i.e. qpid-client-x.xx-bin.tar.gz) and the AMQP 1.0 client (i.e.
qpid-amq
Justin,
That all sounds sensible to me.
Once the 0.32 cross-component release is done, I am happy to take on the
release manager role of the Java components.
cheers, Keith
On 27 January 2015 at 17:21, Justin Ross wrote:
> Based on what we've discussed so far, here's what I propose:
>
> We
20 matches
Mail list logo
