@redhat.com> wrote:
>
> > On 01/05/2016 11:42 AM, Robbie Gemmell wrote:
> >
> > > On 4 January 2016 at 19:59, Gordon Sim <g...@redhat.com> wrote:
> > >
> > > > On 12/30/2015 06:37 PM, aconway wrote:
> > > >
> >
On Wed, 2015-12-30 at 12:12 -0500, aconway wrote:
> On Mon, 2015-12-14 at 15:29 -0500, Bradley P. Orner wrote:
> > In trying to build qpid-*cpp 0.34 (Red Hat Linux v. 7.1, gcc v
> > 4.8.3),
> > I get the following error. *I've built boost 1.59 and installed it
> > in
On Mon, 2015-12-14 at 15:29 -0500, Bradley P. Orner wrote:
> In trying to build qpid-*cpp 0.34 (Red Hat Linux v. 7.1, gcc v
> 4.8.3),
> I get the following error. *I've built boost 1.59 and installed it in
> a
> local directory /opt/ngwx/usr/local.
>
The boost headers are sadly not "warning
On Wed, 2015-12-30 at 10:22 +0100, Olivier Mallassi wrote:
> Hi all
>
> again, my apologies for all these questions.
>
> I am trying to clarify my understanding around transactions support
> within
> qpid and here is my current understanding (based on documentation &
> JIRA).
> I have to say I
On Wed, 2015-12-16 at 12:02 +, Gordon Sim wrote:
> On 12/15/2015 04:40 PM, Olivier Mallassi wrote:
> > Hi all
> >
> > I am still digging into the qpid technologies in order to better
> > understand
> > how all the pieces can be tied together.
> > switching to the C++ broker implementation, I
On Tue, 2015-12-15 at 19:32 +, Robbie Gemmell wrote:
> Hi all,
>
> I have put up an RC for 0.11.1, please test it and vote accordingly.
+1
>
> The release archive and sig/checksums can be grabbed from:
> https://dist.apache.org/repos/dist/dev/qpid/proton/0.11.1-rc1/
>
> Maven artifacts
On Mon, 2015-12-14 at 18:11 +, Robbie Gemmell wrote:
> I have a candidate proton-j change that I'd like to see in a JMS
> client release, https://issues.apache.org/jira/browse/PROTON-1077, so
> I'd be onboard with doing a 0.11.1 to get that too. Anyone else have
> things warranting inclusion
On Fri, 2015-12-04 at 15:19 -0500, Ted Ross wrote:
> Olivier,
>
> Please be advised that the Messenger API in proton is not getting a
> lot
> of developer attention. The development effort has shifted to the
> reactive APIs and it's likely that the reactive interfaces are what
> are
> going
On Thu, 2015-11-26 at 09:27 -0500, Chuck Rolke wrote:
> Qpid C++ applications are multi-threaded. When you single step in a
> breakpoint all the threads may run and then you get issues as you
> describe.
>
> Read section 'Stopping and Starting Multi-thread Programs' in the gdb
> docs. The
The ruby binding was broken in the 0.11 release by a mistake that was
not caught in automated testing. I've fixed the problem and improved
the automated tests, I think this might deserve a 0.11.1 as ruby is
unusable in the 0.11 release which is a severe regression.
The fix is on the 0.11.x
[Continuing a discussion from
https://github.com/astitcher/qpid-proton/pull/4#issuecomment-158207053
but it has become a discussion of the C library which is separate from
the original C++ issue so new thread]
On Thu, 2015-11-19 at 14:28 -0800, Andrew Stitcher wrote:
> So actually we should be
On Fri, 2015-11-20 at 04:03 +, Noel OConnor wrote:
> Thanks guys, I think this explains it nicely but I'll play around
> with
> waypoints some more to ensure I fully understand it. Having read your
> description I think that it's a nomenclature issue.
>
> To me prefixing "waypoints" and
On Sun, 2015-11-15 at 10:51 +, Noel OConnor wrote:
> Hi,
> I've struggling with understanding the context of phases in waypoints
> and
> how you would use them.
> Are phases an AMQP or dispatch routes concept ?
Dispatch only, more below...
> I've taken a look at the code and found the
Agreed with all Ted says below about waypoints. I think we currently
lack a clear overview of all the dispatch concepts - the implementation
is on track, we just need to improve the explanation. Here's a quick
thinking-out-loud attempt to summarize:
The key to dispatch's flexibility is the
On Wed, 2015-11-11 at 07:53 -0500, Justin Ross wrote:
> The artifacts proposed for release are here:
>
> https://dist.apache.org/repos/dist/dev/qpid/proton/0.11.0-rc2/
>
> Please indicate your vote below. If you favor releasing the 0.11.0
> RC 2
> bits as 0.11.0 GA, vote +1. If you have
ou mean by "anonymous sender handling".
On Mon, Nov 2, 2015 at 6:23 PM, aconway <acon...@redhat.com> wrote:
> > I have added an "engine" class to the C++ binding to simplify
> > integration with external IO. Interested in feedback.
> >
> > https:/
On Mon, 2015-11-09 at 17:12 +0530, Sanny wrote:
> Hi,
>
> Using Proton C library.
>
> I am following the demo example "send.c" shared in the archive.
> Currently
> using the mqx OS.
>
>
> 1. I have following function in *pn_error_code*(messenger->error);
> always
> returning *-2*. while
On Mon, 2015-11-09 at 17:12 +0530, Sanny wrote:
> Hi,
>
> Using Proton C library.
>
> I am following the demo example "send.c" shared in the archive.
> Currently
> using the mqx OS.
>
>
> 1. I have following function in *pn_error_code*(messenger->error);
> always
> returning *-2*. while
I have added an "engine" class to the C++ binding to simplify
integration with external IO. Interested in feedback.
https://issues.apache.org/jira/browse/PROTON-1036
There is an example select-based broker using the new API. I split the
broker code into a common part shared by all the example
On Tue, 2015-10-27 at 12:09 +0300, Michael Ivanov wrote:
> Hallo,
>
> Is this an error:
>
> if (messenger->flags | PN_FLAGS_CHECK_ROUTES) {
> . . . .
> }
>
> (line 1498 in messenger.c)?
>
> Shouldn't it be:
>
> if (messenger->flags & PN_FLAGS_CHECK_ROUTES) {
>
> Or do I miss
amework, and if your framework is not
select-like (e.g. the go net package) then the reactor integration
points make no sense at all.
>
> Cliff
>
> On Thu, Oct 22, 2015 at 2:33 PM, aconway <acon...@redhat.com> wrote:
> > The proton reactor provides a complete soluti
hat instead of driving everything in a
single thread from the Container's run() method, each connection can be
driven independently (and concurrently) by your IO framework.
I'll try to get something out in the next few days.
Cheers,
Alan.
> Best regards,
>
>
> 22.10.2015 21:36, aconway
On Thu, 2015-10-22 at 18:20 +0300, Michael Ivanov wrote:
> Hallo,
>
> What kind of communication error recovery is available in proton
> library (if at all)?
> I am using proton messenger in passive mode and I noticed very
> unpleasant behaviour:
> wherever the connection to qpidd is broken (eg.
The Go binding for proton provides 2 alternate APIs, `proton` is an
exact analogue of the event-driven proton C API and `electron` which is
a more go-oriented, procedural API. The differences were motivated by
the concurrency features of the Go language but there may be lessons to
learn for other
The proton reactor provides a complete solution for integrating foreign
IO into a single threaded proton event loop. This is useful in
situations where proton is being used in isolation, there is no other
IO handling framework available and everything is single threaded.
However often that is not
I have spent a fruitless day trying to get the go binding to work on
windows. Here's the scoop.
cgo (the Go/C integration) requires gcc to work on windows.
gcc will not link with libraries produced by Visual Studio C++
compiler.
most proton users will be using the Visual Studio compiler.
So I
I've updated the proton Go API, read about it at
https://github.com/apache/qpid-proton/blob/master/proton-c/bindings/go/
src/qpid.apache.org/README.md
There are 2 distinct APIs: the "proton" API is a straightforward
mapping of the proton C library. The "electron" API is a procedural
(not
On Fri, 2015-10-02 at 10:51 -0400, Ted Ross wrote:
> https://netprototalk.wordpress.com/2015/10/01/amqp-as-a-network-proto
> col
>
> This is the first of a planned series of articles about AMQP, message
> routing, and distributed-system use cases.
>
> -Ted
>
>
>
For the proton C++ binding there are a bunch of features in modern C++
(c++11) that are relevant (lambdas, std::function, threading and async
support etc. etc.) The binding to date is written to work with c++03.
In terms of strategy going forward I would like to suggest the
following:
1. We
I've pushed the Go binding to master, read all about it at
https://github.com/apache/qpid-proton/blob/master/proton-c/bindings/go/
README.md
The documentation needs a lot of work but you can check the examples
and start playing with the code now.
Please ignore the packages go/amqp,
On Fri, 2015-09-11 at 07:24 -0400, Justin Ross wrote:
> I wasn't subscribed before, so I'll have to address Alan's notes in a
> new
> thread.
>
> My reading of the internet suggests that "using namespace" is awfully
> common. Is it really anathema?
It is common, and normal in .cpp files,
I have been reminded that we actually had a discussion and put together
an API layout proposal for proton APIs, and the C++ binding does not
conform (nor does the coming-soon Go binding)
https://cwiki.apache.org/confluence/display/qpid/Proton+API+layout+prop
osal
I probably agreed to this at the
I have committed the C++ binding for proton to the master branch. This
is a roll-up of the cjansen-cpp-client branch. Outstanding work is
listed inproton-c/bindings/cpp/README.md. The documentation is at
http://qpid.apache.org/releases/qpid-proton-master/index.html
Here's the info from the
On Thu, 2015-09-03 at 11:57 -0400, Ted Ross wrote:
> Jack,
>
> We have not implemented any form of notification in the management
> agent
> yet. This is something we are interested in providing and also
> contributing to the in-progress management specification at OASIS.
>
> -Ted
>
> On
nt for programmatic notifications where you want
to take action rather than just log, but it's a useful step.
>
>
> Jack
>
>
> On 9/3/15, 1:53 PM, "aconway" <acon...@redhat.com> wrote:
>
>
> > On Thu, 2015-09-03 at 11:57 -0400, Ted Ross wrote:
>
I have updated the C++ proton binding, for details see:
http://people.apache.org/~aconway/proton/c-and-cpp.html
http://people.apache.org/~aconway/proton
The highlights of the change:
- 0 overhead C++ facade classes, facade pointers point directly at C structs.
- proton::counted_ptr
On Fri, 2015-08-28 at 06:46 +, Aschenbrenner, Erik wrote:
Hi Paolo, hi Chuck!
Nice to see some other AMQP experts here on the user list.
In your blogs you deal with Wireshark to trace and dissect AMPQ
traffic. Did you ever try to dissect encrypted AMQP traffic with
Wireshark?
On Thu, 2015-08-20 at 10:46 +0300, Michael Ivanov wrote:
Sorry,
A couple of months ago I discovered a case in proton that prevented
using more than 32767 nodes in message data. One of our applications
created large messages and wherever it exceeded this limit it just
crashed. The data type
On Mon, 2015-08-24 at 09:58 -0500, jjw tectec wrote:
We have the need to set up broker federation between qpid broker and
Azure
Service Bus. I'm aware of the following discussion thread, and had
tried
similar steps:
https://mail-archives.apache.org/mod_mbox/qpid-users/201403.mbox/%3C5
+1
Tested with dispatch router.
On Tue, 2015-08-11 at 21:08 +0100, Robbie Gemmell wrote:
Hi all,
I have put up a third cut for 0.10, please test it and vote
accordingly.
Since RC2 there have been fixes for PROTON-978, PROTON-975, and
PROTON-899.
The release archive and
On Sun, 2015-07-12 at 09:14 +0100, Fraser Adams wrote:
As I say I think that ActiveMQ Apollo started out because of scaling
limitations of the original ActiveMQ and has evolved to a reactor
based
threading model built on hawt-dispatch (Java implementation of Grand
Central Dispatch
On Tue, 2015-06-23 at 17:48 +0200, Flavio Percoco wrote:
On 22/06/15 14:14 -0400, aconway wrote:
On Tue, 2015-06-16 at 23:38 -0400, Rafael Schloming wrote:
I'd like to get the proton-j-reactor branch into 0.10 also. It
should
be
ready soon, so if py3k can be sorted and merged
On Tue, 2015-06-16 at 23:38 -0400, Rafael Schloming wrote:
I'd like to get the proton-j-reactor branch into 0.10 also. It should
be
ready soon, so if py3k can be sorted and merged in a similar
timeframe we
could target a release for the end of the month.
The C++ and Go bindings are also
43 matches
Mail list logo
