GS.Chandra N wrote:
Hi,
I'm trying to list stats or details of a particular element, using
qpid-tool, as shown in the C++ broker management tool page.
But something does not seem to work. Could someone tell me what i'm doing
wrong here?
Thanks
gs
qpid: list exchange
Objects of type
register wrote:
Hi all,
I am running Qpid C++ on Opensuse 10.2 and CentOS 5.2, then run the
command below
I have tried the command on both sides, same result
qpidc-0.4/python ./qpid-route -v link add
user/p...@192.168.20.133:5672 user/p...@localhost:5672
Exception in thread Thread-1:
That's a feature that is missing from qpid-config. You can raise a Jira
issue to request this feature, or better, provide a patch. It would be
very easy to add --if-empty and --if-unused options to the command.
-Ted
ffrenchm wrote:
How can I set this 'if-empty' parameters through
Shan Wang wrote:
My client program will declare the queue in the beginning, but there's
no point of redeclaring a queue if it already exists. Is there a API
call for clients to tell if a queue name is being used already?
There is a queue.query you could use for this purpose but it's easier
) and put them into one patch file (patch.diff in the above
example). It also has the benefit of being very readable by a reviewer.
-Ted
ffrenchm wrote:
Ok it's done ! :)
Ted Ross wrote:
You should be able to create an account on the Jira site that gives you
the ability to add issues
I think this is the relevant text from the AMQP specification (emphasis
mine):
If the server receives a declare, bind, consume or get request for a
queue that has been declared as exclusive by an _*existing client
session*_, it MUST raise an exception.
This means that a queue is
Perhaps you should look at the ACL (access control list) capability of
the broker. This allows you to restrict access to resources (i.e.
queues) based on the authentication identity of the client.
-Ted
ffrenchm wrote:
I have read this in the AMQP spec too and this is an interesting point.
Garrett Smith wrote:
I'm running into this error when I try to start a connection, which is
configured with what I believe to be a valid username and password:
connection failed (320, u'connection-forced: Authentication failed')
I'm using the default guest/guest account. Here's what I'm
Bryan Kearney wrote:
I am curious how folks are addressing using QMF in a web application
type model. Assume that I have a webapplication which can host n
users. If the users can access a backend service via QMF and I want to
track on the backend some notion of state and/or who the user is
Hi Greg,
Thanks for sharing this report. Your detailed results are interesting,
especially since this is a level of benchmarking that we haven't gotten
to ourselves.
I'll take a whack at some of your questions in-line below. Hopefully
others will chime in as well.
First or all, I'm
Pawe? Piers'cionek wrote:
Hi,
I am new to the MQ stuff. Tried parsing through AMQP specs and QPID
docs and still don't get how to code this little two scenarios:
I have a single producer sending msgs to a queue with dynamic number
of consumers.
scenario A - all consumers get all messages
Bryan,
The agent should send class-indication messages to the broker 1) at
startup and 2) whenever a new class is dynamically created/registered.
If the broker doesn't have that schema cached, it will send the agent a
schema-request.
If you are talking about new versions of the same
John Obaterspok wrote:
Hello,
Any hints on while the below program always crashes?
(qpidc-0.5.752600 on i686)
~
#include qpid/console/ConsoleListener.h
#include qpid/console/SessionManager.h
#include qpid/sys/Time.h
void initQPID()
{
Bill,
I'm not completely following your example. What is env.envMsg? If
you use messageData as the argument to .setData, then
.getData().length() should be the same as length.
Please be advised that the contents of dataStruct will be copied
octet-for-octet into the message payload. This
acacio.cent...@terra.com.br wrote:
*
*
*
Hi,
By what I’ve read on the AMQP specification,
should I have N consumers to a queue, for each message posted to it,
one of the consumers is going to be activated in round-robin. The
spec call this a
Rob Springer wrote:
All - we are considering using federation to ease
some of the load on our broker, but before starting that work, we had
a few questions about how message reliability intersects with
federation. We lean heavily on ACCEPT_MODE_EXPLICIT to ensure
reliability in case of a
Rob,
This is certainly not the intended behavior. Can you open a Jira so we
can track this issue? Are you running 0.5 or the trunk?
Thanks,
-Ted
Rob Springer wrote:
Hey everyone - I'm just starting to use the QMF console API via C++,
and I've noticed odd behavior, and I was wondering if
Which version of the software are you running?
-Ted
H. Charles Tang wrote:
Thanks folks for your help.
I think you're telling me that what we did for setting up two routes on a
single link as follows should not cause a msg loop:
qpid-route route add host1:5000 host2:5000 amq.topic topic.foo
Full SASL authentication/encryption capability for the Python client was
added to the trunk at revision 834975.
A new Python module qpidsasl implemented in C++ and wrapped for Python
using Swig was introduced. This wrapper provides a generalized binding
to the Cyrus SASL library. The Python
This is a re-send of the original message with the particulars updated
for the new location of the SASL wrapper. By popular demand, this
wrapper was moved out of the qpid/cpp area and moved to qpid/extras.
=
Full SASL
On 11/25/2009 01:14 PM, Leticia wrote:
On Wed, Nov 25, 2009 at 7:11 PM, Ted Rosstr...@redhat.com wrote:
On 11/25/2009 12:57 PM, Leticia wrote:
I would like that the sw that we are developing can manage with two or
more
federated qpid brokers. In order to obtain this, we need more
On 03/17/2010 01:39 PM, Gordon Sim wrote:
On 03/17/2010 04:43 PM, Robert Godfrey wrote:
On 16 March 2010 18:50, Gordon Simg...@redhat.com wrote:
On 03/15/2010 10:33 PM, Joan Bellver Faus wrote:
Exception in thread Thread-3
org.apache.qpid.console.ConsoleException:
On 03/22/2010 02:06 PM, Robert Godfrey wrote:
On 22 March 2010 14:36, Ted Rosstr...@redhat.com wrote:
On 03/17/2010 01:39 PM, Gordon Sim wrote:
On 03/17/2010 04:43 PM, Robert Godfrey wrote:
On 16 March 2010 18:50, Gordon Simg...@redhat.com wrote:
On 03/15/2010 10:33
On 06/29/2010 04:23 PM, Steve Huston wrote:
I'm working on some code that sends messages to a topic exchange. I
create a Receiver to get messages by key. When I use
Receiver::fetch(Message, Duration) all appears ok; when I use
Session::nextReceiver I never get a message. Here is some lines
On 07/20/2010 12:30 PM, QPID User wrote:
Hi Ken,
Thanks a lot for the response. In the debugger I see the code getting to the
ParentComponent.cpp doMethod...see below
--
if (methodName == create_child) {
ArgsParentComponentCreate_child ioArgs;
::qpid::types::Variant::Map::const_iterator _i;
On 10/01/2010 01:10 PM, qpid user 2 wrote:
Hi folks,
I am having an issue with C# binding dll when trying to connect to the
broker. This issue only happens in Release mode. I get an exception when
trying to instantiate a Connection object and pass on a connection url to
target the broker. the
On 10/07/2010 01:57 PM, Wolgemuth Greg wrote:
I'm working with a build from SVN trunk, and am trying to use the Python
QMFv2 bindings. I've been starting with the example provided (agent.py),
and then moving on to try and get a functional console, but have had
some difficulties.
First, the
On 11/17/2010 01:13 PM, Thomas Nguyen wrote:
Hello,
I am testing QPID for the first time and am having trouble with messages
being routed from an exchange to a queue. I am using a C++ broker and
the Java client to publish messages. First off here is my initial
exchange and queue setup:
Thomas,
You should look in the system logs to see if openais is logging any
helpful information. Also, people on this list might be better able to
help you if you provide the content of your openais.conf file (don't use
an attachment, the Apache mail server strips them).
-Ted
On
On 12/01/2010 08:58 AM, Lahiru Gunathilake wrote:
Hi Devs,
I am doing a load test with large messages and used Qpid Java client to do
the communication with the broker, and things are working fine for me. But I
can see following log in Qpid C++ broker side which is an error, since it's
an error
The broker does not implement persistence by itself. A store-plugin is
required to use persistence. You can find one for Linux at:
http://qpidcomponents.org/download.html
-Ted
On 12/01/2010 01:30 PM, Thomas Nguyen wrote:
I have specified a data-dir and also have created durable exchanges
On 12/22/2010 03:05 PM, qpid user 2 wrote:
Thanks Chuck,
The root cause of the issue I am facing is similar to the one mentioned in
the Jira you linked me to. I managed to make my sending procedure
indifferent from the status of the connection using a synchronization of the
messages and
On 01/25/2011 11:08 AM, sergey_zhemzhit...@troika.ru wrote:
Hi there,
According to following link
http://qpid.apache.org/books/0.8/Programming-In-Apache-Qpid/html/ch02s04.html#id3068029
subjects can be used to direct messages to different destinations. Routing
and binding keys can used for the
On 01/27/2011 12:15 PM, Adam Crain wrote:
Hi,
I'm trying to pilot our project on Fedora 14 desktop. There's no yum package
for qpid as described by the download wiki.
I can only find qpid-cpp-server and it comes in the 0.7 development release.
-Adam
There's a Qpid 0.8 package in Fedora 15.
Interesting... those messages must have already been delivered, but not
completed, to the other subscriber. That would explain why they didn't
purge and also why you wouldn't see them when consuming from the queue.
-Ted
On 02/02/2011 05:40 AM, sergey_zhemzhit...@troika.ru wrote:
The issue
Sanath,
Can you please provide us with more detailed information? Are you
running the broker and the clients on the same system or different
systems? Which OS are you running the broker on? Which .net client are
you using? Are you trying to run one of the .net examples or your own
Just FYI - There is a set of patches that will be committed to trunk
once 0.10 is approved that fix the mingw build problems (and a number of
other problems). For details, please refer to:
https://issues.apache.org/jira/browse/QPID-2905
https://issues.apache.org/jira/browse/QPID-3186
On 05/17/2011 08:59 AM, stoyan wrote:
all qpid tools seem to hang on my server (qpid-config, etc...).
i think this started after i accidentally killed a qpid-config process
(ctrl+\).
the broker on this server has been restarted, but the problem persists.
the strange thing is that all tools
On 05/24/2011 08:59 AM, Angus Salkeld wrote:
Hi
I am writing an application that needs to talk to a number of agents
(say 20+).
This Console needs to both receive events and make method calls to the
agent (I am doing it using the async API).
I had 2 ideas on how to do this:
1) create a
On 06/03/2011 02:02 PM, Anthony Foglia wrote:
What are the differences between the three Python APIs? There are (at
least) 3 APIs:
1. qpid package
This was the first API we used, based on some examples in a two year
old blog post.
2. qpid.messaging package
This one more closely
Brandon,
You can do this with a queue route (i.e. the downstream broker
subscribes to an existing queue).
Static exchange routes may be durable, meaning they will reappear after
a restart, but their queues are always transient. Furthermore, when the
route is down, there is no queue to hold
Did you use a large number for the --ack argument in the route? Try
using 1.
It appears that the ack-batching is quite literal and the downstream
broker *only* acks on modulo-N messages (i.e. it doesn't ack
gratuitously after a period of inactivity).
-Ted
On 09/20/2011 05:22 PM, Brandon
Frase,
I think you've uncovered a bug in the broker.
If a congested queue causes a flow-control stop (i.e. the broker
withholds acks to the producer until the queue reduces in size),
unbinding the queue from the exchange will not cause a flow-resume like
deleting the queue will. This is why
threshold
is crossed downward.
-Ted
On 12/07/2011 03:04 PM, Ted Ross wrote:
Frase,
I think you've uncovered a bug in the broker.
If a congested queue causes a flow-control stop (i.e. the broker
withholds acks to the producer until the queue reduces in size),
unbinding the queue from
Frase,
Sorry for my delayed response to this. I've fallen a little behind on
the users list.
Thank you for this contribution. From your description, it looks as
though it's a little ahead of the C++ counterpart! A Java
implementation of QMF2 is very desirable and valuable so it should
Users and Devs,
I'd like to make a proposal and start a discussion about the future of
QMF and Qpid broker management.
QMF (Qpid Management Framework) started out as a way to remotely manage
the Qpid C++ broker using AMQP messaging. There was an agent embedded
in the broker and a console
There was a major patch applied to trunk months ago that added support
for mingw32. It should build without that patch.
-Ted
On 02/20/2012 01:41 PM, Steve Huston wrote:
-Original Message-
From: joseluis [mailto:jleah...@gmail.com]
Sent: Monday, February 20, 2012 12:14 PM
To:
Virgilio,
Not verbatim, but VS2010 support has been committed as of December 6th
and will be in the 0.16 release.
-Ted
On 02/22/2012 10:41 AM, Virgilio Fornazin wrote:
Ted
The patches for Microsoft VS2010 I've sent to you months ago are on latest
releases?
On Mon, Feb 20, 2012 at 17:10,
Sinduja,
There are a couple of example agents in the source tree
(qpid/cpp/bindings/qmf2/examples) that you can reference. You first
create and open a normal messaging connection and then pass it to the
newly created qmf agent. Agents are not able to communicate with each
other, they can
Hi Paul,
This aspect of ACL is the same in 0.16 as it is in 0.14. That matahari
web link is very up-to-date.
-Ted
On 05/30/2012 12:09 AM, Paul Colby wrote:
Hi,
I'm implementing an access control list (ACL) for an internal Qpid cluster.
Most of the ACL is nice and straight-forward.
On 07/22/2012 06:33 PM, Virgilio Fornazin wrote:
We use MRG-M here too, and we are running in trouble sometimes with this
confuse flow-to-disk implementation.
What we expect to have, to replace it, it's something like a real
'queue-on-disk' with parameters like current
implementation of
I'd like to start a discussion on how, from an API perspective,
applications can use the request/response pattern. If we get this
right, we will remove a significant barrier to adoption of AMQP.
Middleware messaging systems typically do a poor job of supporting this
pattern. The Qpid APIs
On 01/02/2013 02:39 PM, William Henry wrote:
- Original Message -
I'd like to start a discussion on how, from an API perspective,
applications can use the request/response pattern. If we get this
right, we will remove a significant barrier to adoption of AMQP.
Middleware messaging
+1
I think this is a real problem and I would be supportive of
consolidating all of the discussion into one list. We either exclude
people by sending to one list or, like this email, we include all lists
and everybody gets three copies.
-Ted
On 01/18/2013 12:21 PM, Gordon Sim wrote:
I
Frase,
I think you're mostly correct about the way that qpidtoollibs should
work with regard to object-ids. In QMFv1, the IDs were broker-assigned
and opaque. In v2, they are composed of the values of the referenced
object's index properties. This is why the id == name assumption
worked.
+1
As you point out, Justin, we've already taken this step with Proton
without too many difficulties. This looks like a major improvement to me.
It will be desirable for each library component to have a well-defined,
constrained, and stable API. This will be difficult if we separate the
Wes,
It seems that you are accumulating senders in the service process. You
create one per response but never close them. Try adding
sender.close() after the send in the service program.
-Ted
On 04/24/2013 11:50 AM, Wes Parish wrote:
I have been seeing some strange behavior with the 0.20
On 05/08/2013 02:42 PM, Fraser Adams wrote:
Hello,
I seem to recall that it's possible to set consumer flow control with
Qpid is that correct?
I can't see anything specific in the documentation relating to
consumer flow control, I thought that it had something to do with
message credits or
The qpid broker already does loop-suppression to prevent messages from
taking the same path more than once. The reason you get two messages is
because you have created a topology with redundant paths in it (i.e.
there are two distinct paths from each sender to each receiver). Your
receiver
On 09/12/2013 05:44 AM, Christian Fromme wrote:
Hi Gordon,
thanks again for your quick reply.
On Thu, Sep 12, 2013 at 11:25 AM, Gordon Sim g...@redhat.com wrote:
I think the drops are caused by management events. The broker will generate
events and route them to the management exchanges.
5672tcp Y Operational
On Sep 12, 2013, at 12:55 PM, Ted Ross [via Qpid]
ml-node+s2158936n7598136...@n2.nabble.com wrote:
If you use qpid-route link list broker do you see all of the links
being operational?
-Ted
On 09/12/2013 10:49 AM, bacon wrote:
Output of qpid
with using a topic exchange? Or
should B be telling A what it knows about C (but isn't)?
Thanks,
-Andrew
On Sep 11, 2013, at 5:18 PM, Ted Ross [via Qpid]
ml-node+s2158936n7598110...@n2.nabble.com wrote:
On 09/11/2013 04:39 PM, bacon wrote:
Let me start by saying that I am almost certainly
On 09/25/2013 09:20 AM, Gordon Sim wrote:
On 09/25/2013 02:14 PM, Ted Ross wrote:
Load-balanced fan-out is not currently implemented but is something that
I consider a key feature. I'd be interested to hear if you have
specific requirements for how it works.
What about selective
On 09/26/2013 12:03 AM, Mitsuru Oka wrote:
Another question on Dispatch router is there.
Could you show me an example of request-reply/response pattern via
Dispatch router using proton messenger based sender and receiver? I
tried proton client/server python example, but the client couldn't
On 09/26/2013 08:23 AM, Gordon Sim wrote:
On 09/26/2013 01:14 PM, Ted Ross wrote:
I'm putting a feature into Dispatch that allows a client to dynamically
obtain a routable reply-to address. This will involve changes in
Messenger as well.
I'd be interested in hearing a bit more about
I agree with Pavel and Jakub. Tying the bytes depth as closely as
possible to actual memory consumption is probably a good thing. We
could even consider counting the message overhead (the memory used that
is not part of the actual message).
-Ted
On 09/27/2013 08:01 AM, Pavel Moravec wrote:
Darryl,
I added Python Client (Wrapped) to the component list.
-Ted
On 09/27/2013 09:09 AM, Darryl L. Pierce wrote:
Now that the Swigged Python library is out in the wild, at least in
Fedora, can we add a new component for reporting features and bugs to
differentiate them from the pure Python
Hi Jack,
This is exactly the kind of use case that Dispatch is intended for.
With regard to reply-to semantics, Dispatch uses AMQP's dynamic-terminus
capability to assign routable addresses for use as reply-to values. By
'routable' I mean that any router in the network will know how to
For the record, Dispatch also uses this pattern to allocate a routable
address that exists for the lifetime of the Receiver/Link. This is
useful as a way to establish a receiver for replies to requests. The
assigned address can be used in the reply-to field of a request message
and the
On 09/27/2013 01:09 AM, Mitsuru Oka wrote:
2013/9/25 Ted Ross tr...@redhat.com:
Load-balanced fan-out is not currently implemented but is something that I
consider a key feature. I'd be interested to hear if you have specific
requirements for how it works.
One interesting request I've heard
to conform with the proposed management specification
for AMQP, nor does the document make any mention of how dispatch is
to be
managed.
Cheers,
Rob
On 9 October 2013 17:22, Ted Ross tr...@redhat.com wrote:
The AMQP Router project (Qpid Dispatch, announced previously on the
user
list
for AMQP, nor does the document make any mention of how dispatch is
to be
managed.
Cheers,
Rob
On 9 October 2013 17:22, Ted Ross tr...@redhat.com wrote:
The AMQP Router project (Qpid Dispatch, announced previously on the
user
list) is gaining in community interest and is nearing the point
On 10/10/2013 11:20 AM, Rob Godfrey wrote:
On 10 October 2013 15:35, Ted Ross tr...@redhat.com wrote:
On 10/10/2013 04:38 AM, Rob Godfrey wrote:
My main concern is that I believe that Qpid should be primarily directed
at implementing AMQP standards, and building resuable toolkits
On 10/17/2013 04:32 PM, Rajesh Khan wrote:
From the manual it states that you could read from multiple receivers and
you could do that:
by adding a receiver to a session as such:
Receiver receiver1 = session.createReceiver(address1);
Then you could simply read it:
Message message =
The initial release (0.1) of Qpid Dispatch Router has been created. The
RC1 artifacts may be found here:
http://people.apache.org/~tross/qpid-dispatch-0.1rc1/
A web page documenting the features, capabilities, and limitations of
this release can be found here:
out
as a solicitation for testing and feedback. I would like to put this,
or a subsequent release candidate forward for a vote in the PMC in the
near future.
Regards,
-Ted
On 10/25/2013 03:01 PM, Ted Ross wrote:
The initial release (0.1) of Qpid Dispatch Router has been created.
The RC1
Sam,
You may or may not be interested, but there's a new project in Qpid
called Qpid Dispatch that's a messaging router. You can learn more
about it here:
http://qpid.apache.org/components/dispatch-router/index.html
If you are interested, I can help you configure an equivalent topology
Frase,
This looks really interesting. Can you provide any details about the
WebSockets encapsulation (i.e. how WS messages and frames are used)?
Thanks,
-Ted
On 11/19/2013 02:56 PM, Fraser Adams wrote:
Hey all,
For the last couple of weekends I've been working on a Proof of
Concept
+1
I'd be very interested in seeing this checked in on a branch.
-Ted
On 11/19/2013 03:33 PM, Robbie Gemmell wrote:
I think its worth mentioning that branches are ideally suited to this sort
of workwhether it actually ends up on trunk or not in the end, theres
no need to keep things local
The qpid RPMs were moved from the base distribution to a layered-product
channel in RHEL 6.4. I can give you more details off-list if you need.
Or you can contact Red Hat sales.
-Ted
On 12/03/2013 12:25 PM, Sam Jones wrote:
Can anyone explain why the qpid RPMs are being deprecated starting
The 'qpid.fed.op' extension was adopted because of the lack of an
arguments field in the unbind command.
Dynamic binding needs to attach some metadata to the bind and unbind
commands. Since there was no standard way to attach metadata to an
unbind command, a bind command with a qpid.fed.op
I've seen things like that on a number of occasions. It almost always
turns out to be related to building from source when there are
binary/RPM packages installed.
-Ted
On 12/04/2013 03:11 PM, Fraser Adams wrote:
Hi all,
a colleague of mine is seeing this message caused by some of his code:
On 12/10/2013 05:54 AM, Gordon Sim wrote:
On 12/09/2013 06:50 PM, Marcelo Vieira wrote:
On 09-12-2013 16:22, Gordon Sim wrote:
On 12/09/2013 06:18 PM, Marcelo Vieira wrote:
In the script running as a daemon that read the messages, I'm using
'my_queue; {create:always,
QPID-439 seems to have reverted in this RC.
Here's my client code:
self.M.route(amqp:/*, amqp://%s/$1 % host)
self.subscription = self.M.subscribe(amqp:/#)
self.reply = self.subscription.address
print REPLY:, self.reply
The output is:
REPLY: None
yet
Digging further into this, I see that Messenger is providing the
subscription and the address before the dynamic-attach handshake is
completed. It was my understanding that one or both of those calls
would block until the name was resolved.
-Ted
On 12/18/2013 05:25 PM, Ted Ross wrote:
QPID
Yes, it's fixed on trunk. Thanks!
-Ted
On 12/19/2013 05:52 AM, Rafael Schloming wrote:
I believe I've fixed this on trunk. Let me know if you still see the
problem there.
--Rafael
On Wed, Dec 18, 2013 at 5:44 PM, Ted Ross tr...@redhat.com wrote:
Digging further into this, I see
Please find the Qpid Dispatch Router RC3here:
|
http://people.apache.org/~tross/qpid-dispatch-0.1rc3/
This release is dependent on the Proton 0.6 release (please see Rafael's
announcement from earlier today).
Numerous fixes and updates have been incorporated into this release
candidate.
This release has been updated to fix an issue related to RPM generation
(https://issues.apache.org/jira/browse/QPID-5436).
Please find the Qpid Dispatch Router RC4 here:
http://people.apache.org/~tross/qpid-dispatch-0.1rc4/
This release is dependent on the Proton 0.6 release
I am starting a vote on the initial release of the Qpid Dispatch message
router. This vote is to use RC4 as the official 0.1 release.
Source location:
http://people.apache.org/~tross/qpid-dispatch-0.1rc4/
Documentation:
http://qpid.apache.org/components/dispatch-router/index.html
On 01/03/2014 06:28 AM, Sascha Kattelmann wrote:
Hi,
I'm currently working on gathering logs from devices in a network via
AMQP. The dispatch router seems to be a good choice for this. I tried
the examples provided with
svn.apache.org/repos/asf/qpid/dispatch/trunk/doc/book/release-0.1.md
I will put up a new RC to address the problem Darryl found. The vote
will be re-started next week if all goes well with RC5.
-Ted
On 01/03/2014 09:50 AM, Darryl L. Pierce wrote:
On Thu, Jan 02, 2014 at 03:28:53PM -0500, Ted Ross wrote:
I am starting a vote on the initial release of the Qpid
Please find the Qpid Dispatch Router RC5 here at the following link.
This contains the fix for QPID-5448
(https://issues.apache.org/jira/browse/QPID-5448).
http://people.apache.org/~tross/qpid-dispatch-0.1rc5/
This release is dependent on the Proton 0.6 release
On 01/03/2014 01:52 PM, Crinklaw-Vogt, Matthew wrote:
Since qpid 0.14 and 0.24 both support the same version of the AMQP spec, should
I expect a qpid 0.24 java client to work with the qpid 0.14 C++ broker?
Though we probably haven't tested that specific combination as part of
the release, I
I am re-starting the vote on the initial release of the Qpid Dispatch
message router. This vote is to use RC5 as the official 0.1 release.
Source location:
http://people.apache.org/~tross/qpid-dispatch-0.1rc5/
Documentation:
http://qpid.apache.org/components/dispatch-router/index.html
Sascha,
The Python bindings for Proton are only needed for running the tests and
for running the qdstat utility. Since qdstat uses AMQP, it can be
installed on a separate system and used to manage/monitor dispatch over
the network. So the Python Proton bindings are not needed to run
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 to the client via the
address
On 01/10/2014 02:03 PM, Davin Shearer wrote:
Sent from my iPhone
On Jan 10, 2014, at 13:49, Ted 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
This vote has passed with four +1 votes and no -1 votes. Three of the
+1 votes are binding. I will create the tag in the code repo and
release the artifacts as soon as Proton 0.6 closes and releases.
Thanks,
-Ted
On 01/07/2014 09:42 AM, Ted Ross wrote:
I am re-starting the vote
Release artifacts are now on the website:
http://qpid.apache.org/components/dispatch-router/index.html
-Ted
On 01/13/2014 03:19 PM, Ted Ross wrote:
This vote has passed with four +1 votes and no -1 votes. Three of the
+1 votes are binding. I will create the tag in the code repo
+1
On 02/02/2014 05:48 PM, Justin Ross wrote:
Hello, all. RC4 [1][2] contains the proposed final bits for Qpid 0.26.
If you favor releasing the RC4 bits as our official release, vote +1.
If you have reason to believe RC4 is not ready for release, vote -1.
I will close this vote on Friday, 7
1 - 100 of 394 matches
Mail list logo
