Hi Justin,
The two issues I raised post 0.13.0 are already approved an on the 0.13.x
branch:
https://issues.apache.org/jira/browse/PROTON-1235
https://issues.apache.org/jira/browse/PROTON-1236
and the python setup has already been bumped to 0.13.1.
Long way to say I've got no outstanding issues
+1
Tested:
pyngus unit tests (python 2.7 and 3.4)
oslo.messaging unit and functional tests for AMQP 1.0 driver
rsyslog output module
- Original Message -
> From: "Justin Ross"
> To: users@qpid.apache.org
> Sent: Friday, July 1, 2016 10:20:01 PM
> Subject: [VOTE] Release Qpid Proton 0
See https://pypi.python.org/pypi/python-qpid-proton/0.13.1
Email this list with any feedback you have - thanks!
--
-K
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid
Sorry for the late reply...
+1 to a 0.6.1 update
- Original Message -
> From: "Robbie Gemmell"
> To: users@qpid.apache.org
> Sent: Tuesday, July 26, 2016 10:15:16 AM
> Subject: Re: Dispatch Router 0.6.1 release?
>
> It there are fixes available, it makes sense to release them. If they
>
+1
- passes oslo functional tests, simulator, and test clients
- Original Message -
> From: "Ted Ross"
> To: users@qpid.apache.org
> Sent: Tuesday, August 2, 2016 9:17:20 AM
> Subject: [VOTE] Release Qpid Dispatch Router 0.6.1
>
> This is the vote thread for Qpid Dispatch Router 0.6.1
+1
Tested:
pyngus unit tests (python 2.7 and 3.4)
oslo.messaging unit and functional tests for AMQP 1.0 driver
rsyslog output module
- Original Message -
> From: "Justin Ross"
> To: users@qpid.apache.org
> Sent: Wednesday, August 17, 2016 10:06:39 AM
> Subject: [VOTE] Release Qpid Pro
+1 - verified against the openstack oslo.messaging functional tests w/pyngus
2.1.1 and proton 0.14.0
- Original Message -
> From: "Justin Ross"
> To: users@qpid.apache.org
> Sent: Friday, August 26, 2016 7:18:40 PM
> Subject: [VOTE] Release Qpid C++ 1.35.0
>
> The artifacts proposed fo
I've packaged up the 0.14.0 python bindings and uploaded them to PyPi:
https://pypi.python.org/pypi/python-qpid-proton
-K
- Original Message -
> From: "Justin Ross"
> To: annou...@apache.org
> Cc: users@qpid.apache.org
> Sent: Tuesday, August 30, 2016 8:25:03 AM
> Subject: [ANNOUNCE] A
Hi Volker,
I would recommend you use the python-qpid-proton package available at the pypi
repository:
https://pypi.python.org/pypi/python-qpid-proton/0.14.0
The package setup script will automagically check to see if the proton-c
library has been installed and will use it if available. Otherw
- Original Message -
> From: "Gordon Sim"
> To: users@qpid.apache.org
> Sent: Thursday, September 1, 2016 8:32:15 AM
> Subject: Re: Python support for AMQP 1.0?
>
> On 01/09/16 09:29, Volker Diels-Grabsch wrote:
> > So I have to switch from a pure-Python implementation to a C library
>
My bad - we've never exactly publicized that behavior.
:)
- Original Message -
> From: "Gordon Sim"
> To: users@qpid.apache.org
> Sent: Thursday, September 1, 2016 9:09:36 AM
> Subject: Re: Python support for AMQP 1.0?
>
> On 01/09/16 13:44, Ken Giusti
Folks,
Thought this might be of interest to those members of the community that deal
with Openstack. Otherwise... nevermind!
There is a project in Openstack that provides a high-level abstraction for
remote procedure call (RPC) and Pub-Sub messaging services in python [1]. This
abstraction i
> "advertised") guarantee - "I will expire the connection after X
> > > time
> > > without receiving a frame from you".
> > >
> > > We could also legitimately go the direction you suggest. *But* its
> > > name is
> > >
Robbie beat me to it...
In proton-c pn_transport_set_idle_timeout sets the actual local timeout
interval.
The value of the Open frame's idle-timeout field is 1/2 the value set by
pn_transport_set_idle_timeout, as suggested by the spec.
:/
https://git-wip-us.apache.org/repos/asf?p=qpid-proton.
Better late than never:
https://pypi.python.org/pypi/python-qpid-proton/0.15.0
--
-K
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
IIRC C reactor also uses the url parser.
- Original Message -
> From: "Justin Ross"
> To: users@qpid.apache.org
> Sent: Friday, November 11, 2016 3:02:40 PM
> Subject: Re: Heads-up: Splitting proton-c into multiple libraries [Was:
> Proton's road ahead]
>
> On Fri, Nov 11, 2016 at 8:46
Hi Ulf,
- Original Message -
> From: "Ulf Lilleengen"
> To: users@qpid.apache.org
> Sent: Monday, November 14, 2016 9:18:50 AM
> Subject: Qpid Proton SSL and SNI
>
> Hi all,
>
> I've been playing around with setting Server Name Indication (SNI)
> when using the qpid proton python bindi
+1
- Original Message -
> From: "Ted Ross"
> To: users@qpid.apache.org
> Sent: Thursday, November 10, 2016 1:26:31 PM
> Subject: [VOTE] Release Qpid Dispatch Router 0.7.0 (RC2)
>
> I have built RC2 for Qpid Dispatch Router 0.7.0. Please give it a test
> and cast your votes.
>
> The bui
FYI python people:
I've posted the 0.16.0 rc1 python bindings up at testpypi for evaluation.
To install, use the pip --pre option:
pip install --pre -i https://testpypi.python.org/pypi python-qpid-proton
- Original Message -
> From: "Robbie Gemmell"
> To: users@qpid.apache.org
> Sen
+1
* tested oslo.messaging driver (unit and functional tests)
* tested pyngus unit tests
* tested rsyslog omamqp1 plugin
- Original Message -
> From: "Robbie Gemmell"
> To: users@qpid.apache.org
> Sent: Thursday, December 8, 2016 12:26:01 PM
> Subject: [VOTE] Release Qpid Proton 0.1
FYI:
The python bindings are available via pypi:
https://pypi.python.org/pypi/python-qpid-proton/0.16.0
-K
- Original Message -
> From: "Robbie Gemmell"
> To: annou...@apache.org, d...@qpid.apache.org, users@qpid.apache.org
> Sent: Tuesday, December 13, 2016 1:57:06 PM
> Subject: [ANN
Adel -
I've hit this error before and it was due to a mix up with my library paths.
When I got that error my 2.7 python env was trying to load the .so built using
the python3 library.
Can you run strace on the test to see exactly which _cproton.so is being loaded?
-K
- Original Message
ing correctly and it is loading
> the correct _cproton.so using python 2.7.9.
>
>
> So init_cproton is generated correctly in the code and is present.
>
>
> Do you have some other advice? Could there be an #ifdef related to linux (if
> defined(__GNUC__)) which is not def
cproton.i to have nothing in it and I am still experiencing the
> issue.
>
>
> I honestly think it is a compiler issue as you said. I will try to use a
> different compiler or try to have a simpler "hello world" in swig and test
> it.
>
> Hopefully I will find somet
- Original Message -
> From: "Greg Oliver"
> To: users@qpid.apache.org
> Sent: Friday, January 20, 2017 6:56:08 PM
> Subject: filtering message stream
>
> Using Python. Proton 0.16.0.
>
> Would like to receive messages from an Azure Event Hub using proton. Need to
> set message filters
FYI if you're testing the RC1 python bindings:
I've built and uploaded pip packages from the 0.17.0rc1 tar file.
To install:
pip install --pre -vvv --no-cache -i https://testpypi.python.org/pypi
python-qpid-proton
-K
- Original Message -
> From: "Robbie Gemmell"
> To: users@qpid.apac
+1
Tested:
pyngus unit tests (py27 & py35) - fedora 24
oslo.messaging unit and functional (py27 & py35) - fedora 24
rsyslog plugin - centos7 docker image
-K
- Original Message -
> From: "Robbie Gemmell"
> To: users@qpid.apache.org
> Sent: Friday, February 3, 2017 12:35:47 PM
>
FYI:
I've posted the latest python packages up @ PyPi:
https://pypi.python.org/pypi/python-qpid-proton
enjoy!
--
-K
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.
- Original Message -
> From: "cqi"
> To: users@qpid.apache.org
> Sent: Monday, March 13, 2017 5:20:47 AM
> Subject: If not call set_trusted_ca_db, does proton attempt to read ca cert
> from somewhere?
>
> I need to connect a broker and peers need to be verified over SSL.
> set_trusted_
- Original Message -
> From: "Robbie Gemmell"
> To: users@qpid.apache.org
> Sent: Friday, March 17, 2017 11:08:20 AM
> Subject: Re: [HEADS UP] qpid-cpp 1.37.0
>
> I'm probably not going to get this started this week after all,
> https://issues.apache.org/jira/browse/QPID-7713 was notice
- Original Message -
> From: "Ted Ross"
> To: users@qpid.apache.org
> Sent: Wednesday, March 22, 2017 9:43:42 AM
> Subject: Qpid Dispatch Release Plans
>
> A couple of topics for discussion:
>
> Qpid Dispatch Router 0.8.0 release
> ==
>
> As of now, the
+1
oslo.messaging Call and Cast functional tests pass
ombt2 rpc call and notify tests show no change in performance wrt 0.7.0
-K
- Original Message -
> From: "Ted Ross"
> To: users@qpid.apache.org
> Sent: Thursday, April 6, 2017 4:30:18 PM
> Subject: Qpid Dispatch Router 0.8.0 Release C
+1
oslo.messaging Call and Cast functional tests pass
ombt2 rpc call and notify tests show no change in performance wrt 0.7.0
-K
- Original Message -
> From: "Ted Ross"
> To: users@qpid.apache.org
> Sent: Friday, April 7, 2017 10:34:28 AM
> Subject: [VOTE] Release Qpid Dispatch Route
Hi Guang,
Sorry I was away for a few days.
The 'good' news is that you didn't do anything wrong...
... the 'bad' news is that the proton packages do not build the C extension
correctly under windows.
I've opened a couple of bugs to track this issue:
https://issues.apache.org/jira/browse/PROTO
Hi Guang,
No, not all - you've got what is necessary for building the python extension.
However - if you need SSL encryption or SASL authentication over proton you'll
want to install lines 18 and/or 21. But those are optional features and are
not required for the basic functionality.
Good wor
- Original Message -
> From: "zhaogxd"
> To: users@qpid.apache.org
> Sent: Monday, May 1, 2017 7:22:50 PM
> Subject: Re: [Python] python-qpid-proton 0.17.0 packages
>
> Hi Kent,
>
> Glad to know that those are optional dependencies.
>
> By the way, do you know how to make a 64bit buil
Hi,
There is a PPA that includes more recent versions of Qpid stuff:
sudo apt-add-repository ppa:qpid/released
See https://launchpad.net/~qpid for all the gory details. The intent
is to provide the latest release of the upstream Qpid releases.
There's been efforts to get newer packages into t
Alan -
Hate cmake? Maybe you'd be interested in automake instead.
/me ducks
;)
On Wed, Sep 6, 2017 at 2:44 PM, Alan Conway wrote:
> On Wed, Sep 6, 2017 at 12:58 PM, Gordon Sim wrote:
>
>> It seems that the install directive for PROGRAMS in cmake somehow
>> evaluates and rewrites the interpre
Hi Philipp,
On Thu, Sep 14, 2017 at 9:16 AM, Philipp Eib wrote:
> Hi,
>
> what do I need to set to build the proton bindings for python3 instead of
> the default python2?
>
>
>
> Background:
>
> I need Proton with SSL support. Unfortunately, the python3-qpid-proton
> package for Ubuntu is not b
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f7780ece000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7f7780cb1000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f77808e7000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f77806e
hon module
will lack SSL support.
let us know if you hit any problems
-K
On Fri, Sep 15, 2017 at 3:50 AM, Philipp Eib wrote:
>> -Original Message-----
>> From: Ken Giusti [mailto:kgiu...@redhat.com]
>> Sent: Donnerstag, 14. September 2017 18:29
>> To: users
>>
On Tue, Sep 19, 2017 at 3:41 AM, Philipp Eib wrote:
>> -Original Message-
>> From: Ken Giusti [mailto:kgiu...@redhat.com]
>> Sent: Freitag, 15. September 2017 15:15
>> To: users
>> Subject: Re: Proton bindings for python3
>>
>> Hi Philipp,
>
At the moment the qpid dispatch router ignores all group related
message properties when computing the route for a destination.
I've opened a corresponding feature request against the router to
track support for message groups:
https://issues.apache.org/jira/browse/DISPATCH-843
On Fri, Sep 29,
Folks,
I've spun up the latest 0.18.0 python package for testing.
I've uploaded it to TestPyPI for now. If no problems are reported
I'll move it to the official PyPI server by the end of the week.
Try it out and let me know,
$ pip install --index-url https://test.pypi.org/simple/ python-qpid-p
+1
Ran pyngus and oslo.messaging smoke tests against the python binding
On Tue, Oct 31, 2017 at 9:49 AM, Robbie Gemmell
wrote:
> Hi folks,
>
> I have put together a spin for a Qpid Proton 0.18.1 release, please
> give it a test out and vote accordingly.
>
> The source archive can be grabbed from:
Folks,
I've built the proton python package from the latest 0.18.1rc1 release
and uploaded them to TestPyPI.
Use the following command to install them for testing:
$ pip install --pre --index-url https://test.pypi.org/simple/ python-qpid-proton
Note the --pre argument. This is necessary since
I've just published these packages to the official PyPI repository:
https://pypi.python.org/pypi/python-qpid-proton
enjoy,
On Mon, Oct 30, 2017 at 12:21 PM, Ken Giusti wrote:
> Folks,
>
> I've spun up the latest 0.18.0 python package for testing.
>
> I've upload
I've built a source release of the Python bindings for 0.18.1.
I've uploaded them to TestPyPI - you can pull them in using pip:
pip install -vvv --no-cache --index-url https://test.pypi.org/simple/
python-qpid-proton
Feel free to test. Post here if you hit a problem.
If all looks good I'll mo
Hi Andreas,
100% totally untested, but...
The Container.connect() method takes an SSLDomain object via the
ssl_domain parameter. You'll want to instantiate the
proton.SSLDomain, calling set_credentials to setup the CA to use to
validate the broker's cert.
connect() also takes a URL, the scheme
+1
Built & ctest on both fedora 27 and ubuntu xenial
Built & tested python bindings
Note: uploaded the RC2 bindings to testpypi. You can install it via pip by:
pip install -vvv --pre --no-cache --index-url
https://test.pypi.org/simple/ python-qpid-proton
On Wed, Dec 20, 2017 at 1:30 PM, Robb
In case you missed it I ported the coverage work done on proton to dispatch:
https://github.com/apache/qpid-dispatch/commit/802e4aa97f159c8464e9f21eabf11453c2688399
We can now check the coverage of our dispatch CI tests. This is a
useful tool when creating new unit tests (or updating the existin
I've just built and uploaded the python bindings for 0.19.0 to Pypi:
https://pypi.python.org/pypi/python-qpid-proton/0.19.0
enjoy!
On Sun, Dec 24, 2017 at 11:35 AM, Robbie Gemmell wrote:
> The Apache Qpid (http://qpid.apache.org) community is pleased to announce
> the immediate availability of
+1
Tested on Ubuntu 16.04 VM:
1) build and unit test pass
2) oslo.messaging unit and functional tests pass (qpidd and qdrouterd)
3) pyngus unit tests pass
On Thu, Jan 25, 2018 at 7:46 AM, Robbie Gemmell
wrote:
> Hi folks,
>
> I have put together a spin for a Qpid Proton 0.20.0 release, please
I've posted the corresponding python source package to Pypi:
https://pypi.python.org/pypi/python-qpid-proton/0.20.0
Holler if you find any issues, thanks
On Tue, Jan 30, 2018 at 7:04 AM, Robbie Gemmell wrote:
> The Apache Qpid (http://qpid.apache.org) community is pleased to announce
> the imm
Folks,
Can we get a fix release for qpid-dispatch containing the fix to
https://issues.apache.org/jira/browse/DISPATCH-881 ?
This fixes a per-delivery leak that's present in the 1.0.0 release. This
is a per-message leak that causes the router's memory use to climb linear
to the amount of traffic
Hi Yanislav
The python binding attempts to build the C module using the
development environment available on the system where the binding is
installed. The setup.py script does its best to figure out which C
libraries are available so it can avoid building optional features
when libraries are not
op-test 2-node test
> DISPATCH-914 - qd_connector_t leaks mutexes
> DISPATCH-920 - Enabled policy blocks inter-router links
>
> -Ted
>
> On Fri, Feb 9, 2018 at 8:03 AM, Ted Ross wrote:
>> I agree. Let's do a 1.0.1 with this fix.
>>
>> -Ted
>>
+1
Built and ran in Ubuntu Xenial container
Ran ombt2 rpc and notification tests - no evidence of memory growth
On Tue, Feb 20, 2018 at 3:27 PM, Ted Ross wrote:
> Please vote on this thread to release qpid-dispatch 1.0.1-rc1 as the
> official 1.0.1.
>
> The release can be found here:
>
> ht
We really should try to do something smarter in the case of unsettled
multicast rather than either of the current approaches.
What does an application/dev expect when it sends any message
unsettled? It expects to block until eventually it gets some
indication of whether or not the message was del
2018 at 9:49 AM, Ken Giusti wrote:
> We really should try to do something smarter in the case of unsettled
> multicast rather than either of the current approaches.
>
> What does an application/dev expect when it sends any message
> unsettled? It expects to block until eventually it get
M, Michael Goulish wrote:
> You mean your rules to be applied exclusively, and in that order, right?
> i.e.
>
> if ( anybody rejected )
> {
> disposition = rejected
> }
> *else*
> if ( anybody accepted )
> {
> disposition = accepted
> }
>
>
>
>
>
On Mon, Apr 16, 2018 at 12:11 PM, Alan Conway wrote:
> On Mon, Apr 16, 2018 at 11:00 AM, Ken Giusti wrote:
>
>> Yeah, exactly.
>>
>> It's as if you applied a priority to each disposition in the following
>> order (highest first):
>> REJECTED
>> AC
On Mon, Apr 16, 2018 at 1:06 PM, Alan Conway wrote:
> On Mon, Apr 16, 2018 at 12:39 PM, Ken Giusti wrote:
>
>> On Mon, Apr 16, 2018 at 12:11 PM, Alan Conway wrote:
>> > On Mon, Apr 16, 2018 at 11:00 AM, Ken Giusti wrote:
>> >
>> >> Yeah, exactly.
>
Apologies for thread-jacking Ted's original email thread.
After thinking about the comments on this thread and
spending some time researching various "reliable multicast" solutions
I've come to the conclusion that we *should* allow multicasting
unsettled messages by having the ingress router provi
No objection here.
Thanks,
On Fri, Apr 20, 2018 at 5:57 PM, Andrew Stitcher wrote:
> I've been doing some work on the proton python code recently and I've
> noticed we're carrying around code to support python 2.5 and perhaps
> even 2.4.
>
> The only Python 2 version that is still maintained by
-1
1.1.0 rc2 version of qdstat does not work against previous release of
dispatch router (1.0.1):
$ qdstat -b localhost:25672 -g
KeyError: 'presettledDeliveries'
presettledDeliveries (and some other) new attributes were added in
1.1.0 and qdstat -g should not error out if they are missing.
-K
+1 - totally agree with this proposal.
- Original Message -
> 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
Sorry for the late feedback...
+1 to renaming qpid-cpp-benchmark to qpid-benchmark. I think moving
qpid-benchmark into qpid/tools makes sense - it is a 'tool', even if it is not
exactly a management tool. :)
Is the intent also to install qpid-benchmark as part of the tool install, like
qpid-
Pavel - I agree that behavior is unexpected - the command should fail without
modifying the queue. Can you raise a JIRA and assign it to me?
thanks
-K
- Original Message -
> Hi,
> I realized one particular (for me) unexpected behavior when using
> filters in QMF methods (in C++ broker
I really like the refactor, and would rather see it sooner than later, so I'm
good with (a)!
-K
- Original Message -
> So, to follow up and summarise this thread so far, the only
> contentious
> point has been the loss of the 'flow to disk' functionality.
>
> Though the current solution
Hi Sean,
Like Darryl, I do most of my qpid work using the latest Fedora. However, I
was able to build the latest stable branch of qpid (0.18) successfully on my
Centos 6 x86_64 machine (fully up to date).
Can you cut and paste your build errors into an email?
thanks,
-K
- Original Me
configure: WARNING: Couldn't find Python developer libs - you
> >> probably
> >> don't have a python-dev or python-devel package installed
> >> checking for perl... perl
> >> checking for "/usr/lib64/perl5/CORE/perl.h"... yes
> >> chec
Hi Fraser,
>I expect I'm probably pushing the bounds of QMF with this stuff, though
>if I do:
>
>qpid-config bind amq.match test f1 all k1=v1
>qpid-config bind amq.match test f1 any k1=v1
>
>I don't get any errors from qpid-config, but the broker says
>
>2013-01-02 14:49:39 error Detected two mana
g my QMF objects back from an AJAX call
> to
> a REST implementation of the QMF2 API :-)
>
> Hopefully my Qpid GUI will be in a releasable state in the next
> couple
> of days, I'm currently going through some final bugs & snags and a
> little bit of work to get it looki
I'm in favor of combining them all into one.
If not that, then at least collapse the "proton" list. The level of traffic
on that list isn't unreasonable, and, frankly, keeping it separate probably
leads to some of the confusion we're seeing over the goals of this project.
-K
- Origina
k that needs to be done surrounding project structure, identity,
> documentation, communication, etc, and simply rearranging lists
> without
> doing the rest of that work is IMHO jumping the gun.
>
> --Rafael
>
> On Fri, Jan 18, 2013 at 1:14 PM, Ken Giusti
> wrote:
>
Hi Bruno,
Since federation routes are uni-directional, you'd need to create another route
to get from b2 back to b1 for the response.
Here's a simple example using the 'drain' and 'spout' clients:
If I have two brokers:
qpidd --auth no -p
qpidd --auth no -p
And set up two routes, on
m is with the default exchange, the server receives a queue
> from the other broker in the replyTo field with no exchange defined.
>
> Thank you,
> Regards.
>
> On Sex, 2013-02-01 at 10:43 -0500, Ken Giusti wrote:
> > Hi Bruno,
> >
> > Since federation routes are
Hi Fraser,
>There's been a lot of new additions to the Broker object which mostly
>look useful, but what's the intention of the get/set TimestampConfig?
>How would "timestamping received messages" be used?
That feature provides for the timestamp as described in AMQP 0.10
message.delivery-propert
Hi Fraser,
Missed this:
>I'm curious about the "query" method on the Broker object, what's the
>point of this?
Debug-ability. Its intent is to provide debug information for a given broker
object, not to substitute for the information already available in the schema.
The QMF schema for a Queue
Hmm... that would probably be caused by the new queue's management ID colliding
with the old queue's ID. The old queue ID is kept around by the management
agent so it can notify that the queue was deleted.
There was a bug like this that we fixed awhile back: QPID-3666. With the
current code,
Hi Scree,
I doubt that this bug will affect sending or receiving messages to that queue.
It may affect the management of the queue - like using qpid-stat or qpid-tool
to look at the state of the queue (messages queued, etc).
> I am using qpid 0-10 c++ apis.
The bug is/was in the broker daemon
- Original Message -
> From: "Gordon Sim"
> To: users@qpid.apache.org
> Sent: Monday, March 18, 2013 3:07:30 PM
> Subject: Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
>
> On 03/14/2013 01:08 PM, Gordon Sim wrote:
> > As an additional but separate step I'd like to add some b
s used
to specific a non-default broker address (? is it "-a", or "-b"?).
I'll stop grousing now... :)
- Original Message -
> From: "Gordon Sim"
> To: users@qpid.apache.org
> Sent: Tuesday, March 19, 2013 11:19:03 AM
> Subject: Re: [c++]: Prog
- Original Message -
> From: "Gordon Sim"
> To: users@qpid.apache.org
> Sent: Thursday, March 21, 2013 11:47:38 AM
> Subject: Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
>
> On 03/21/2013 01:19 PM, Ken Giusti wrote:
> > H... seems like t
Hi Bill (and Gordon) - sorry about not chiming in a bit earlier with this.
Bill - though you've probably already seen it, the management schema is the
definitive source for the format of all management objects made available via
QMF: qpid/specs/management-schema.xml. It also defines the keys
Hi Bill,
I've just tried to restrict my broker to using only qmf v2:
$ qpidd --auth no --mgmt-qmf1 no
and I no longer get update notifications from my console.py app! From the
looks of it, the console.py code is broken - the broker is generating the qmfv2
updates, but console.py is dropping
e -
> From: "Bill Freeman"
> To: users@qpid.apache.org
> Sent: Monday, April 1, 2013 5:21:46 PM
> Subject: Re: Questions from a novice
>
> Ken,
>
>
> On Mon, Apr 1, 2013 at 4:31 PM, Ken Giusti wrote:
>
> >
> > 2) uniquely identifying ob
- Original Message -
> From: "Bill Freeman"
> To: users@qpid.apache.org
> Sent: Monday, April 1, 2013 7:50:16 PM
> Subject: Re: Questions from a novice
>
> Ken,
>
>
> On Mon, Apr 1, 2013 at 5:58 PM, Ken Giusti wrote:
>
> > > That sou
t, we could probably simplify the
console.py code quite a bit. I find it's current form a bit squirrelly and
loaded with special cases in order to support both qmf versions.
-K
- Original Message -
> From: "Fraser Adams"
> To: users@qpid.apache.org
> Cc: users@q
ng how to select one protocol or the other
> via that API?
>
> Frase
>
> On 2 Apr 2013, at 14:26, Ken Giusti wrote:
>
> > Hi Frase,
> >
> > What I saw surprised me: when I disabled v1 (via --mgmt-qmf1 no) and I ran
> > qpid-tool, qpid-tool
- Original Message -
> From: "Bill Freeman"
> To: users@qpid.apache.org
> Sent: Wednesday, April 3, 2013 9:45:49 AM
> Subject: Re: Questions from a novice
>
> On Tue, Apr 2, 2013 at 5:22 PM, Ken Giusti wrote:
>
> > When console.py connects to a br
- Original Message -
> From: "Bill Freeman"
> To: users@qpid.apache.org
> Sent: Friday, April 5, 2013 12:45:02 PM
> Subject: Re: Questions from a novice
>
> Ken,
>
> Yes, with the patch in, I get callbacks to my qmf.console.Console sub-class
> instance's callback methods for both V1 an
Hi Frase
- Original Message -
> From: "Fraser Adams"
> To: users@qpid.apache.org
> Sent: Friday, April 5, 2013 2:09:12 PM
> Subject: Re: Questions from a novice
>
> Hi Guys,
> This thread has intrigued me a bit.
>
> I must admit that I had thought the qmf.console.Console,
> qmf.console.
- Original Message -
> From: "Bill Freeman"
> To: users@qpid.apache.org
> Sent: Friday, April 5, 2013 2:37:23 PM
> Subject: Re: Questions from a novice
>
> On Fri, Apr 5, 2013 at 2:09 PM, Ken Giusti wrote:
>
> >
> >
> > -
Good catch Bill - this is a bug, and I've entered a JIRA for it:
https://issues.apache.org/jira/browse/QPID-4732
That said, I would urge you not to use the QPID connection directly. The API
doesn't explicitly expose this, and we probably will be moving the QMF client
to use the client messagin
Hi D James,
I'm pretty sure the ssl options were added to qpid-config _after_ 0.18. I
think they first appeared in the 0.20 release.
Does "qpid-config --help" list them?
-K
- Original Message -
> From: "djames"
> To: users@qpid.apache.org
> Sent: Tuesday, April 9, 2013 5:41:35 PM
> S
- Original Message -
> From: "Bill Freeman"
> To: "users"
> Sent: Wednesday, April 10, 2013 11:23:04 AM
> Subject: Re: Maybe bug, maybe novice mistake, or maybe my python qpid library
> is too old.
>
> Ken,
>
>
> As long as I have your attention, does ;{mode:browse} affect the nee
pid.apache.org
> Sent: Monday, May 6, 2013 7:11:18 AM
> Subject: Plans for QMF v1 and v2 (was Re: QMFv2 object update bug [WAS Re:
> Questions from a novice])
>
> On 05/03/2013 04:51 PM, Ken Giusti wrote:
> > I want to know what the
> > QPID project's plan is for QM
Folks,
There's some old QMF-related code in our repo that appears to be quite dead.
If said code is in fact "pushing up the daisies", I'd like to see removed prior
to the 0.24 release.
First, there's stuff that I'm almost certain is stone cold dead. AFAIK, this
shouldn't be used by anyone. I
1 - 100 of 355 matches
Mail list logo
